El problema es la responsabilidad, no la capacidad técnica
Las organizaciones rara vez tienen dificultades para encontrar un caso de uso. Las tienen para llevarlo de la demostración a la operación habitual. Se aprueba un piloto, se contrata a un proveedor, alguien interno logra un resultado convincente y la iniciativa se detiene en el espacio entre la prueba de concepto y el proceso que debía cambiar.
En muchos casos, el problema de fondo es estructural. El piloto tiene patrocinador pero no un responsable de la ejecución. Tiene presupuesto pero no línea base. Toca datos de un área, un proceso de otra y un riesgo de una tercera, y nadie responde por conciliarlos. Cuando el piloto funciona, la organización descubre que el éxito era la parte fácil.
Gobernar una implementación de IA comienza, entonces, por una decisión poco vistosa: nombrar a la persona responsable de la ejecución y definir de qué responde. Todo lo demás se deriva de ahí.
Priorizar casos de uso por costo de implementación, no por novedad
Un portafolio creíble se prioriza en dos ejes: el valor operativo del resultado y el costo real de implementarlo — acceso a datos, cambio de proceso, integración, capacitación y supervisión. La novedad no es un criterio.
En la práctica implica evaluar cada candidato con pocas preguntas honestas: qué tarea o decisión cambia; quién es dueño de los datos requeridos; cómo queda el proceso después de la adopción; quién revisa el resultado; y qué ocurre cuando el modelo se equivoca. Los casos de uso que no pueden responder las dos últimas preguntas no están listos, por impresionante que haya sido la demostración.
- Qué tarea o decisión concreta cambia
- Quién es dueño de los datos y autoriza su uso
- Cómo queda el proceso después de la adopción
- Quién revisa y acepta el resultado
- Cuál es el modo de falla y quién lo asume
Ejecutar pilotos con una condición de salida
Un piloto sin condición de salida se vuelve permanente. Antes de comenzar conviene acordar qué resultado justificaría escalar, qué resultado justificaría detenerse y para cuándo se emitirá ese juicio. Ambas respuestas deben ser aceptables: un piloto que solo puede tener éxito no es una evaluación, es una decisión ya tomada.
La condición de salida debe expresarse en términos operativos — tiempo de ciclo, tasa de error, costo por caso, volumen, calidad de la revisión — y medirse contra la línea base actual. Si esa línea base nunca se midió, medirla forma parte del piloto.
Tratar los datos y los accesos como ruta crítica
En muchas implementaciones de IA, el acceso a los datos, la integración y la titularidad operativa resultan más críticos que el desempeño del modelo por sí solo. Lo determinante es el acceso: qué sistemas contienen los datos, quién autoriza su uso, cómo se depuran y actualizan y qué restricciones contractuales o regulatorias aplican.
Esas dependencias pertenecen al plan como elementos con responsable y fecha, no como supuestos. Un piloto que funcionó discretamente sobre una planilla exportada no demostró que la versión productiva pueda funcionar. Hacer explícitas las dependencias de datos desde el inicio puede reducir de forma significativa demoras evitables.
Planificar la adopción como ejecución, no como comunicación
La adopción falla cuando se trata como un anuncio. Las personas cuyo trabajo cambia necesitan saber qué se espera que hagan distinto, de qué siguen siendo responsables y dónde su criterio sigue prevaleciendo sobre el sistema.
Eso exige trabajo concreto: procedimientos actualizados, responsabilidades de revisión, capacitación, un canal de soporte para las primeras semanas y un circuito de retroalimentación que llegue a quienes mantienen la solución. También exige una posición clara sobre la supervisión: qué resultados se controlan, quién los controla y cómo se registran las excepciones.
Reportar a la dirección en el mismo formato que cualquier otro proyecto
Las iniciativas de IA se benefician de un reporte idéntico al de cualquier otra entrega: posición actual, avance contra hitos, riesgos abiertos, decisiones requeridas y dependencias en riesgo. El vocabulario especializado no debe entrar en el reporte ejecutivo; el patrocinador necesita saber si la iniciativa está en plazo y qué se le está pidiendo.
Un estado breve y de ciclo fijo logra algo que una demostración no puede: le da a la dirección una base continua para decidir si acelerar, sostener o detener, mientras la decisión todavía cuesta poco.
La gobernanza mínima
Para la mayoría de las organizaciones, una estructura adecuada es pequeña: un responsable de la ejecución, una lista priorizada de casos de uso, un piloto con condición de salida, un registro de dependencias que incluya datos y accesos, un plan de adopción y un estado de una página cada quince días. Nada de eso es específico de la IA. Precisamente por eso funciona.
Gobernanza de proyectos de IA para empresasServicios: PMO y gobernanza
Este artículo ofrece comentarios generales sobre la ejecución de proyectos.