La mayoría de los proyectos de IA empresarial no fracasan en producción. Fracasan en el camino hacia allá — en algún punto del silencioso vacío entre un demo que deslumbró a una sala y un sistema que nadie confía lo suficiente como para lanzar. El modelo nunca fue el problema. El proceso a su alrededor sí.
El demo es la parte fácil. Un ingeniero capaz puede armar algo impresionante en una semana. Lo difícil es todo lo que el demo se salta: si es correcto, cuánto cuesta, quién es su dueño y cómo sobrevive al contacto con un usuario real. Sáltate eso y tu proyecto se une 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 las preguntas de los clientes con precisión" no es una evaluación. Es un deseo. ¿Preciso comparado con qué? ¿En qué preguntas? ¿En qué umbral lanzas y en qué umbral te detienes? 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 declara la victoria. Otra persona encuentra una respuesta mala y declara el fracaso. Ambos son ruido.
Define la evaluación primero. Construye un set de prueba de 50 a 200 casos reales — preguntas reales, documentos reales, casos límite reales — con resultados esperados. Decide tu umbral de aprobación antes de ver los resultados, para no poder mover la portería. Ahora "¿está funcionando?" tiene una respuesta en lugar de una discusión. Esto no es rigor académico. Es la diferencia entre un proyecto que puede tomar decisiones y uno que discute para siempre.
Ningún usuario real lo tocó hasta el final
El demo se construyó para las partes interesadas, no para los usuarios. Responde las preguntas que el equipo imaginó, en el tono que al equipo le gusta, por el camino feliz que el equipo recorre.
Entonces aparece un usuario real. Pega un correo de 4.000 palabras. Hace dos preguntas a la vez. Usa jerga interna que nadie puso en el prompt. Confía en la respuesta equivocada pero segura y actúa en base a ella. Cada uno de estos casos es sobrevivible si lo encuentras en la segunda semana. Descubierto en la semana doce, después de que la arquitectura está fija, cada uno es una reconstrucción.
Pon a un usuario real — no un sustituto, no un gerente de producto fingiendo — frente a la cosa dentro de las primeras dos semanas. Míralo usarla sin ayudarlo. El objetivo no es el aplauso. El objetivo es recolectar las formas en que se rompe mientras romperse todavía es barato.
Nadie midió el costo
El piloto corrió con 40 consultas de prueba y todos quedaron encantados. Nadie multiplicó por 40.000 consultas al día. Nadie contó los tokens quemados por un prompt que mete toda la base de conocimiento en el contexto en cada llamada. Nadie le puso precio al patrón de "llamemos al modelo dos veces por seguridad" que silenciosamente duplicó la factura.
El costo es una restricción de diseño, no algo que se piensa después. Un flujo de trabajo que cuesta cuarenta centavos por ejecución podría ser una ganga o una bancarrota según el volumen, y deberías saber cuál antes de construir la versión cara. Mide el costo por tarea desde el primer prototipo funcional. Rastréalo como la latencia. Cuando suba, quieres notarlo a escala de prototipo — donde el arreglo es un cambio de prompt — no a escala de producción, donde es un incidente.
La cosa no tenía dueño
Este mata proyectos que por lo demás estaban bien. El consultor se va, el promotor cambia de equipo, y el sistema queda ahí pudriéndose lentamente. Los prompts se desactualizan. Una dependencia lanza un cambio que rompe todo. La calidad se degrada en silencio y ningún tablero lo nota porque nadie construyó el tablero.
La IA empresarial no es un entregable que instalas y del que te vas. Es un sistema vivo que necesita un dueño con un nombre, una línea de presupuesto y la autoridad para cambiarlo. Antes de construir, responde una pregunta: dentro de seis meses, ¿a quién se le avisa cuando la precisión cae? Si la respuesta es "no está claro", no tienes un proyecto. Tienes un futuro huérfano.
La seguridad y la integración se agregaron al final
El prototipo leía de un CSV en la laptop de alguien y publicaba en un canal de Slack. Funcionaba de maravilla en ese entorno de prueba. Entonces alguien hizo las preguntas reales: ¿Cómo se autentica ante el CRM? ¿Qué pasa cuando necesita datos que el usuario no tiene permiso de ver? ¿A dónde van los logs, y el prompt filtra datos personales en ellos? ¿Quién aprobó enviar registros de clientes a un modelo de terceros?
Estos no son detalles de la semana del lanzamiento. Son decisiones arquitectónicas, y responderlas tarde normalmente significa reconstruir. Trae la seguridad y la integración al diseño desde el principio. Las preguntas poco glamorosas — permisos, límites de datos, registros de auditoría, modos de fallo — son exactamente las que deciden si un prototipo funcional llega a ser alguna vez un producto lanzado.
El purgatorio del piloto
Todo lo anterior se suma al estado final donde la mayoría de los proyectos de IA empresarial van a morir: el piloto permanente. Técnicamente funciona. Todos están técnicamente contentos. Y nunca, jamás, se lanza.
Los pilotos se estancan porque el éxito nunca se definió, así que nada puede declararse terminado. Arregla eso desde el inicio y el piloto tiene una salida: un umbral de aprobación que supera o no, un dueño con nombre que lo asume, un costo que se conoce, 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 un demo que correrá para siempre y no 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 la evaluación que falta, el dueño ausente, el costo no medido y las preguntas de seguridad mientras todavía son baratas de arreglar. Es mucho más fácil mitigar el riesgo de esto en papel que descubrirlo en el mes doce.