· 3 min de lectura
La IA en producción no muere en el modelo. Muere en la segunda semana.
El prototipo funciona en la demo y se traba cuando encuentra el sistema real de la empresa. Los cuatro lugares donde eso pasa — y qué debe existir antes del modelo.
Todo proyecto de IA tiene una demo que funciona.
El modelo responde bien, el flujo tiene sentido, la sala aprueba. Casi nunca el problema está ahí. Aparece cuando el piloto encuentra el sistema real de la empresa — y eso rara vez ocurre el primer día. Ocurre en la segunda semana.
Los cuatro lugares donde muere
El código heredado
La demo corre sobre un caso limpio. La operación real corre sobre años de decisiones acumuladas: reglas de negocio que solo existen dentro de una función de 800 líneas, excepciones que nadie recuerda por qué se crearon, un campo con tres significados distintos según el flujo.
Ningún modelo entiende eso por su cuenta. Necesita contexto que no está en el código — está en la historia del código.
La integración que nadie documentó
Todo sistema en producción tiene al menos una. El endpoint que solo funciona si mandas los headers en cierto orden. El job que corre a las 3am y asume que la tabla ya fue poblada. La cola que se atraganta con un payload por encima de cierto tamaño.
El piloto no la toca. La implementación real, sí — y ahí es donde el cronograma se duplica.
El costo que nadie midió
En la demo, cada llamada cuesta fracciones de centavo y nadie mira. En producción — volumen real, reintentos, contexto grande y un agente que decide llamar al modelo caro porque la tarea "pareció difícil" — la cuenta cambia de orden de magnitud.
El costo de IA no es una línea de presupuesto. Es una decisión de arquitectura: quién puede llamar a qué, con qué techo, y qué pasa cuando ese techo se alcanza.
El contexto que se pierde
Entre una conversación y otra, el sistema olvida. Lo que se decidió ayer no influye en lo que propone hoy. Cada interacción empieza de cero — y la persona del otro lado paga el costo de volver a explicarlo todo.
Eso es tolerable en una demo de cinco minutos. Es inviable en una operación que corre todos los días.
Qué debe existir antes del modelo
La pregunta correcta no es "qué modelo usar". Es qué debe estar en pie para que cualquier modelo sea útil:
- Arquitectura — dónde entra la IA en el flujo, qué puede y qué no puede decidir sola, y qué pasa cuando se equivoca.
- Contexto — una forma de que el sistema sepa lo que ya se decidió, no solo lo que está en pantalla ahora.
- Gobernanza de costo — techo por llamada, por tarea y por agente, medido antes de volverse factura.
- Determinismo donde importa — no todo paso puede ser improvisación del modelo. Algunos deben ser flujo, con control explícito.
Nada de eso es glamoroso. Es lo que separa un piloto de un sistema.
Día 200
La pregunta que hacemos en cada proyecto no es "¿esto funciona en la demo?". Es: ¿esto va a seguir funcionando en el día 200?
Porque en el día 200 el equipo que lo construyó ya cambió de foco, el volumen se triplicó, aparecieron tres casos borde que nadie previó y alguien necesita entender por qué el sistema tomó la decisión que tomó.
Ahí es exactamente donde entramos. No construimos demos — construimos sistemas que siguen funcionando después de que pasa la novedad.