El problema de las primeras 12 semanas
La mayoría de los programas de IA empresarial fracasan en las primeras doce semanas, no en el modelo. Fracasan porque el alcance se mueve, los datos no están donde se creía y el comité de cumplimiento descubre obligaciones que nadie había mapeado al inicio. Esta hoja de ruta organiza esas doce semanas en cuatro fases con hitos verificables.
Semanas 1 a 3: alcance y auditoría de preparación
Antes de tocar un modelo, hay que responder cinco preguntas. Cuál es el caso de uso medible. Qué datos lo alimentan y dónde residen físicamente. Qué decisiones automatiza y con qué efecto jurídico. Qué obligaciones aplican (Ley de IA, RGPD, DORA, normativa sectorial). Quién firma cada decisión.
El entregable es un documento de alcance de cinco a ocho páginas con: descripción del caso, fuentes de datos con clasificación, mapa de obligaciones regulatorias, riesgos identificados con dueños y criterios de aceptación cuantitativos. Sin este documento, el resto del programa se construye sobre arena.
Semanas 4 a 6: arquitectura de referencia y DPIA
La arquitectura de referencia define dónde corre el modelo, dónde se almacenan los datos, qué subprocesadores intervienen y cómo se traza cada decisión. Para sistemas de alto riesgo bajo la Ley de IA, esto se hace antes del primer prototipo, no después.
En paralelo, el DPO arranca la DPIA si el tratamiento implica datos personales con perfilado o decisiones automatizadas. La DPIA y la documentación del Anexo IV de la Ley de IA comparten el 60% al 80% del trabajo, así que conviene hacerlas en paralelo.
Semanas 7 a 9: prototipo con harness de evaluación
El prototipo no es la demo bonita; es la versión más simple del sistema con un harness de evaluación que mide precisión, exhaustividad, latencia y coste por caso. El conjunto dorado se construye con expertos del dominio, no con datos sintéticos.
El criterio de salida es cuantitativo. Si el sistema no supera el umbral de calidad acordado en el documento de alcance, no avanza. La tentación de pasar a producción para enseñar progreso es la causa más común de fracasos posteriores.
Semanas 10 a 12: piloto controlado y gobierno operativo
El piloto se ejecuta con un conjunto limitado de usuarios, con supervisión humana en cada decisión de impacto significativo y con registros automáticos de cada llamada. El equipo de operaciones acuerda los umbrales que disparan escalado a humano y los procedimientos de incidente.
El entregable final de las doce semanas es un sistema en piloto medible, con documentación reutilizable como evidencia ante el regulador, con DPIA aprobada y con un plan de escalado a producción. Si lo único que se entrega es código, el programa no está listo para auditoría.
Lo que no funciona
Tres patrones recurrentes hunden programas. Primero, empezar con la herramienta antes que con el caso de uso. Segundo, no documentar la justificación de las decisiones de diseño, lo que rompe la trazabilidad cuando llega el auditor. Tercero, tratar el cumplimiento como capa final en lugar de como entrada del diseño. La regla de TRACE es simple: la confianza, los datos y la evidencia se diseñan antes que la arquitectura.