Un consejo compra las licencias, un equipo hace tres pilotos, las demostraciones salen bien, y un año después nada ha cambiado en las cifras que reporta la compañía. Es la situación a la que más me llaman ahora mismo, y el diagnóstico es casi siempre el mismo.

Los pilotos no están fallando. Están acertando en el paso equivocado.

Mide una cosa antes que nada

Antes de cualquier debate sobre modelos, plataformas o gobierno, mide qué porcentaje del tiempo total se consume antes de que nadie escriba código. Coge veinte iniciativas que hayan llegado a producción en el último año. Para cada una, anota la fecha en que se propuso la idea, la fecha en que existió una especificación con la que alguien podía construir, y la fecha en que salió a producción.

En las organizaciones tecnológicas que he pasado por este ejercicio, el primer tramo es sistemáticamente mayor que el segundo, y no por poco. Decidir, discutir de quién es y definirlo con precisión suficiente para arrancar se lleva de forma habitual bastante más de la mitad del tiempo transcurrido, a veces mucho más.

Esa cifra es toda la historia. Una herramienta que acelera la construcción está operando sobre la mitad pequeña. Y como abarata construir, invita a entrar más trabajo a medio definir en un sistema que ya llevaba más de lo que podía terminar.

Qué suele destapar la medición

Nunca se mata nada. El caso de negocio funciona como entrada al circo. El retorno no se revisa jamás, ninguna iniciativa se para por rendir poco, y la cartera crece hasta que lo que hay en vuelo multiplica varias veces la capacidad real. Entonces todo va despacio, y eso se lee como un problema de entrega en lugar de como un problema de cartera.

Nadie responde de nada de principio a fin. Cada área optimiza su tramo y entrega una fecha en lugar de un resultado que funcione. Pregunta quién responde de si una capacidad concreta generó de verdad el ingreso que prometía, y la respuesta es un comité.

La definición ocurre durante el desarrollo. Los requisitos llegan tarde y sin precisión, y se resuelven con desarrolladores adivinando. Con personas eso se sobrevive, porque preguntan y aplican criterio. Con un agente no se sobrevive: construirá con toda confianza lo que describiste, no lo que querías decir.

La capacidad de revisión no se planificó nunca. La generación sube un orden de magnitud. El número de personas capaces de juzgar bien si lo generado está bien se queda exactamente igual. La cola no desaparece: se traslada de escribir a esperar, y ahora la atienden tus perfiles más sénior.

Los controles solo se acumulan. Cada incidente de la última década añadió un filtro. Ninguno se retiró. Cada uno era razonable el día que se puso. Juntos hacen que sacar algo pequeño cueste casi lo mismo que sacar algo grande, que es la razón de que nunca salga nada pequeño.

La implicación incómoda

Ninguno de los cinco es un problema de IA, y ninguno se resuelve con un modelo mejor, otro proveedor o un centro de excelencia. Los cinco son decisiones sobre cómo funciona la organización, lo que significa que son lentos, políticos y tienen dueños que no pidieron un programa de IA.

Por eso tantas iniciativas de IA acaban discretamente mudándose a la capa de herramientas. La herramienta se compra, se enseña y no obliga a nadie a cambiar de comportamiento. Tampoco funciona, y dieciocho meses después el consejo vuelve a hacer la pregunta con menos paciencia.

Qué cambiar primero

Empieza por la cartera, porque es lo más rápido de mover y desbloquea todo lo demás. Recorta el trabajo en curso con dureza, hasta algo parecido a la capacidad real. Es impopular y es la palanca con más apalancamiento que hay disponible, porque cualquier otra mejora es invisible mientras todo esté encolado detrás de todo.

Después convierte la definición en un trabajo con nombre y con dueño. No recuperar la figura del analista funcional por nostalgia, sino tratar la especificación como la disciplina que determina la calidad del resultado, hecha por gente cercana al negocio y asistida por los mismos modelos que tanto entusiasman. Una organización que no sabe escribir con precisión lo que quiere no tiene mecanismo para convertir un agente en valor, y ninguna cantidad de herramienta se lo va a dar.

Después planifica la capacidad de revisión de forma explícita, como una cifra, igual que planificarías capacidad de construcción. Si la generación se multiplica por diez, la restricción pasa a ser el criterio, y el criterio hay que desarrollarlo a propósito porque antes se adquiría como subproducto de escribir el código que ya nadie escribe.

Y después, solo después, preocúpate de qué modelo estás usando.

Una prueba razonable

Cuando alguien proponga una iniciativa de IA, haz dos preguntas. ¿Sobre qué especificación va a actuar el agente, y quién la ha escrito? ¿Quién va a revisar el resultado, y tiene el tiempo asignado?

Una iniciativa que no sepa contestar a las dos es un piloto. Enseñará muy bien, no llegará a producción, y el motivo no tendrá nada que ver con la tecnología.