La demo fue perfecta. El agente respondió todo, el comité aplaudió, se aprobó el presupuesto. Seis meses después, el piloto está congelado: respuestas inconsistentes, un par de errores vergonzosos frente a un cliente, y nadie sabe decir si la versión de hoy es mejor o peor que la del mes pasado. No falló el modelo. Falló algo más básico: nadie estaba midiendo.
La cifra que da título a este artículo la usamos en nuestras propias presentaciones: alrededor del 73% de los proyectos de IA nunca llega a producción. Y tras varios años construyendo agentes para empresas mexicanas, en SISCON tenemos claro el patrón: casi nunca muere el proyecto por falta de tecnología. Muere por falta de evidencia. Sin una forma sistemática de medir calidad, cada cambio es una apuesta, cada error es una crisis y cada junta de seguimiento es una discusión de opiniones.
La demo no es el producto
Toda demo se construye sobre casos felices: las diez preguntas que el equipo ya sabe que funcionan bien. Producción es otra cosa — es la distribución completa de lo que tus usuarios reales preguntan, con faltas de ortografía, contexto incompleto, casos límite y mala fe ocasional. Un sistema de IA que se ve brillante en veinte casos puede tener 60% de precisión sobre mil casos reales, y nadie lo sabrá hasta que el error caro aparezca.
Los sistemas tradicionales de software tienen una red de seguridad que damos por sentada: los tests. Nadie despliega un sistema de facturación sin pruebas automatizadas. Pero con la IA, por alguna razón, las empresas aceptan desplegar sistemas probabilísticos — que por definición se equivocan a veces — sin ninguna batería de pruebas equivalente. Es exactamente al revés de como debería ser: mientras menos determinista es un sistema, más necesita medición sistemática.
Qué significa "medir" un sistema de IA
Medir no es "lo probamos un rato y se ve bien". La disciplina — que Chip Huyen sistematiza en su libro Ingeniería de IA (O'Reilly, 2025), la referencia actual del campo — se apoya en tres piezas:
- Golden sets. Un conjunto curado de casos reales con la respuesta correcta esperada, validado por tu equipo de negocio — no por el proveedor. Cien casos bien elegidos valen más que mil inventados. Es tu vara de medir: fija, versionada y compartida.
- Jueces automáticos (LLM-as-judge). Un modelo evaluador, calibrado contra criterio humano, que califica cada respuesta del sistema: ¿es correcta?, ¿está fundamentada en los documentos?, ¿respetó el formato y el tono? Esto permite evaluar cientos de casos en minutos, no en semanas de revisión manual.
- Pruebas de regresión. Cada cambio — un prompt ajustado, un modelo actualizado, un documento nuevo en la base de conocimiento — corre contra el golden set completo antes de llegar a producción. Si la calidad baja del umbral acordado, el cambio no pasa. Igual que un pipeline de CI/CD, pero para comportamiento.
El costo de no medir es silencioso (hasta que no lo es)
Lo traicionero de operar IA sin evals es que las regresiones no avisan. Cambias una línea del prompt para arreglar un caso y, sin saberlo, rompes otros doce. Tu proveedor actualiza el modelo detrás de la API — algo que pasa varias veces al año — y el comportamiento de tu sistema cambia de un día para otro sin que nadie haya tocado nada. Un agente que llevaba tres meses respondiendo bien empieza a inventar cifras en un caso límite que nunca estuvo en las pruebas manuales.
Sin medición, cada uno de estos eventos se descubre en producción, frente a un usuario o un cliente. Y ahí el costo ya no es técnico: es de confianza. Un solo error visible ante el comité directivo puede congelar un programa completo de IA — no porque el sistema sea malo, sino porque nadie puede demostrar con datos que es bueno.
Evaluar no es un proyecto: es una disciplina
El error común es tratar la evaluación como un entregable único: "hicimos el benchmark inicial, ya quedó". Los evals valiosos son los que viven en tu pipeline: corren en cada cambio, corren de noche contra el tráfico del día, y alimentan un tablero donde negocio y tecnología ven la misma verdad. Así se responde en segundos la pregunta que mata pilotos: "¿está mejorando o empeorando?"
Esa misma batería, además, es la que te permite tomar decisiones mayores con evidencia y no con marketing: ¿conviene cambiar de modelo?, ¿la versión open source alcanza la calidad de la API comercial a una fracción del costo?, ¿un fine-tuning mejoraría lo suficiente para justificarse? Sin evals, esas preguntas se contestan con corazonadas. Con evals, se contestan con números de tus casos y tus datos.
Por dónde empezar esta semana
- Junta 50–100 casos reales de tu operación (tickets, correos, consultas) con la respuesta que consideras correcta. Ese es tu primer golden set.
- Corre tu sistema actual contra ellos y anota el resultado. Ese número — el que hoy no tienes — es tu línea base.
- Define el umbral de despliegue: ningún cambio pasa a producción si el resultado baja de X%. Escríbelo y comunícalo.
- Automatiza la corrida en tu pipeline con herramientas como Langfuse o promptfoo, para que medir no dependa de que alguien se acuerde.
- Revisa los fallos cada semana y convierte los nuevos errores reales en casos del golden set. El conjunto crece con tu operación.
Este es exactamente el tipo de trabajo que formalizamos en nuestro nuevo servicio de Evaluación y Auditoría de IA: construir la batería con tus casos, calibrar jueces automáticos contra tu criterio y dejarla corriendo en tu pipeline — como parte del harness que hace confiable a un agente. Porque la conclusión de años viendo pilotos morir es simple: la IA que no se mide, no se puede defender. Y la que no se puede defender, no sobrevive al comité.