Modelo operativo
Por qué los pilotos de IA no llegan a producción
El problema casi nunca está en el modelo.
6 min de lectura
Hay un patrón que se repite. Alguien del equipo prueba una herramienta, arma algo que funciona sorprendentemente bien, lo muestra, y la organización decide avanzar. Seis meses después el proyecto sigue siendo una prueba, o desapareció.
La explicación habitual es que la tecnología todavía no está madura. En nuestra experiencia eso casi nunca es cierto. Lo que falla está antes y después del modelo, no en él.
1. La demo se hizo con datos que el sistema no va a tener
La prueba de concepto se construye con material que alguien cargó a mano: tres contratos de ejemplo, unas minutas, un par de planillas. Funciona porque el contexto es limpio, reciente y pequeño.
En producción ese material vive en una carpeta compartida con quince años de sedimento, en la casilla de una persona, en un sistema al que solo entra un área. La distancia entre las dos situaciones no es de grado: es la mayor parte del trabajo real, y no aparece en la demo.
2. Nadie autorizó el acceso, y nadie lo va a autorizar así
Este es el punto donde mueren más proyectos. Para pasar de la prueba a la operación, el sistema necesita leer información real. Y la información real tiene dueños, clasificaciones y obligaciones.
Un área de riesgo no rechaza estos proyectos por desconfianza hacia la IA. Los rechaza porque no puede responder tres preguntas: qué exactamente va a leer el sistema, quién aprueba lo que produce, y cómo se reconstruye después lo que ocurrió. Si el proyecto llega a esa conversación sin respuestas, la respuesta es no. Y es la respuesta correcta.
Nota
Esas tres preguntas se pueden responder desde el diseño. Cuestan poco al principio del proyecto y son casi imposibles de añadir al final, cuando ya hay un sistema funcionando que nadie documentó.
3. La salida no entra a ningún flujo
Un asistente que produce un texto excelente que después alguien copia a mano a un documento, y de ahí a un sistema, no ahorra tanto como parece. Cada traspaso manual consume parte del beneficio y añade una oportunidad de error.
La diferencia entre una herramienta útil y un cambio operativo está en si la salida llega sola a donde tiene que llegar: el CRM, el reporte, la carpeta del deal, la casilla del destinatario. Eso exige integración, y la integración es trabajo de infraestructura, no de prompt.
4. Se entregó y se abandonó
Un flujo agéntico no es un software que se instala. Depende de fuentes que cambian, de formatos que se actualizan, de personas que se van y de modelos que se reemplazan. Sin mantenimiento se degrada en meses, y la degradación es silenciosa: las salidas siguen llegando, solo que peores.
Cuando alguien nota la caída, la confianza ya se perdió, y recuperarla cuesta más que haberla mantenido.
Qué tienen en común los cuatro
Ninguno se arregla cambiando de modelo. Los cuatro son problemas de modelo operativo: de dónde vienen los datos, quién autoriza, dónde aterriza la salida y quién sostiene el sistema.
Eso explica por qué firmas que compraron la misma tecnología obtienen resultados tan distintos. La tecnología era la parte disponible para todos. El resto había que construirlo.
Los controles se diseñan antes que las capacidades.