Casi ningún proyecto de IA empresarial fracasa en producción. Fracasa de camino, en algún punto del vacío silencioso entre una demo que deslumbró a una sala y un sistema en el que nadie confía lo suficiente como para lanzarlo. El modelo nunca fue el problema. El proceso a su alrededor sí.
La demo es la parte fácil: un ingeniero competente monta algo impresionante en una semana. Lo difícil es todo lo que la demo se salta: si es correcto, cuánto cuesta, de quién es y cómo sobrevive al contacto con un usuario real. Sáltate eso y tu proyecto se suma a la mayoría que muere en silencio durante el piloto.
Nunca definiste qué significa «bueno»
Este es el fallo más común, y ocurre el primer día: nadie escribió cómo sabrías que el sistema funciona.
«Debería responder con precisión a las preguntas de los clientes» no es un eval. Es un deseo. ¿Preciso comparado con qué? ¿En qué preguntas? ¿Con qué umbral lanzas y con cuál paras? Sin esos números, cada reunión de revisión se convierte en una prueba de sensaciones. Alguien escribe tres prompts, obtiene una respuesta que se ve bien y canta victoria. Otro encuentra una respuesta mala y declara el fracaso. Los dos son ruido.
Define el eval primero. Monta un set de prueba de 50 a 200 casos reales —preguntas reales, documentos reales, casos límite reales— con sus resultados esperados. Decide el umbral de aprobación antes de ver los resultados, para que no puedas mover la portería. Ahora «¿esto está funcionando?» tiene respuesta en lugar de debate. No es rigor académico: es la diferencia entre un proyecto capaz de decidir y uno que discute para siempre.
Ningún usuario real lo tocó hasta el final
La demo se construyó para las partes interesadas, no para los usuarios. Responde las preguntas que el equipo imaginó, en el tono que le gusta al equipo, por el happy path que recorre el equipo.
Y entonces llega un usuario real. Pega un correo de 4.000 palabras. Hace dos preguntas a la vez. Usa jerga interna que nadie metió en el prompt. Se cree la respuesta equivocada pero convincente y actúa en consecuencia. Cualquiera de estos casos se sobrevive si lo encuentras en la segunda semana. Descubierto en la semana doce, con la arquitectura ya fijada, cada uno es una reconstrucción.
Pon a un usuario real —no un sustituto, no un product manager haciendo de usuario— delante del sistema en las dos primeras semanas. Mírale usarlo sin ayudarle. El objetivo no es el aplauso: es recoger las maneras en que se rompe mientras romperse todavía sale barato.
Nadie midió el costo
El piloto corrió con 40 consultas de prueba y todo el mundo encantado. Nadie multiplicó por 40.000 consultas diarias. Nadie contó los tokens que quema un prompt que mete la base de conocimiento entera en el contexto en cada llamada. Nadie le puso precio al patrón de «llamemos al modelo dos veces por si acaso» que dobló la factura en silencio.
El costo es una restricción de diseño, no algo que se piensa después. Un workflow que cuesta cuarenta céntimos por ejecución puede ser una ganga o una quiebra según el volumen, y deberías saber cuál de las dos antes de construir la versión cara. Mide el costo por tarea desde el primer prototipo que funcione. Síguelo como sigues la latencia. Cuando suba, quieres notarlo a escala de prototipo —donde el arreglo es un cambio de prompt— y no a escala de producción, donde es un incidente.
El sistema no tenía dueño
Este mata proyectos que por lo demás iban bien. El consultor se va, el promotor cambia de equipo y el sistema se queda ahí, pudriéndose despacio. Los prompts se quedan obsoletos. Una dependencia publica un cambio que lo rompe todo. La calidad se degrada en silencio y ningún dashboard lo detecta, porque nadie construyó el dashboard.
La IA empresarial no es un entregable que instalas y abandonas. Es un sistema vivo que necesita un dueño con nombre, una línea de presupuesto y autoridad para cambiarlo. Antes de construir, responde una pregunta: dentro de seis meses, ¿a quién se le avisa cuando cae la precisión? Si la respuesta es «no está claro», no tienes un proyecto. Tienes un huérfano con fecha.
La seguridad y la integración se dejaron para el final
El prototipo leía de un CSV en el portátil de alguien y publicaba en un canal de Slack. En ese entorno de pruebas funcionaba de maravilla. Y entonces llegaron las preguntas de verdad: ¿cómo se autentica contra el CRM?, ¿qué pasa cuando necesita datos que el usuario no tiene permiso de ver?, ¿adónde van los logs, y el prompt filtra datos personales en ellos?, ¿quién aprobó mandar registros de clientes a un modelo de terceros?
No son detalles de la semana del lanzamiento. Son decisiones de arquitectura, y responderlas tarde suele significar reconstruir. Mete la seguridad y la integración en el diseño desde el principio. Las preguntas poco glamurosas —permisos, límites de datos, registros de auditoría, modos de fallo— son exactamente las que deciden si un prototipo que funciona llega alguna vez a ser un producto lanzado.
El purgatorio del piloto
Todo lo anterior desemboca en el estado final donde va a morir la mayoría de los proyectos de IA empresarial: el piloto permanente. Técnicamente funciona. Todo el mundo está técnicamente contento. Y no se lanza jamás.
Los pilotos se estancan porque nunca se definió el éxito, así que nada puede declararse terminado. Arregla eso desde el principio y el piloto tiene salida: un umbral de aprobación que supera o no supera, un dueño con nombre que lo asume, un costo conocido y un usuario real que ya lo rompió y te vio arreglarlo. Un piloto con esas cuatro cosas es un lanzamiento esperando a ocurrir. Sin ellas es una demo que va a correr para siempre sin cambiar nada.
Ninguno de estos fallos tiene que ver con el modelo. Tienen que ver con las decisiones tomadas antes de la primera línea de código. Para eso existe exactamente una Evaluación de Preparación para IA: sacar a la luz el eval que falta, el dueño ausente, el costo sin medir y las preguntas de seguridad mientras arreglarlos todavía es barato. Mitigar este riesgo sobre el papel es muchísimo más fácil que descubrirlo en el mes doce.