En 2025, desarrollamos un sistema que facilitaba la consulta de datos complejos con solo escribir preguntas en lenguaje natural. Usuarios como analistas, gestores de cuentas y líderes operativos solicitaban informes que antes requerían acceder manualmente a varios paneles y herramientas de inteligencia de negocio. Por ejemplo, una petición tipo «Genera un informe del volumen de ventas de enero a marzo de 2026 para la región noreste, desglosado por ciudad» era traducida automáticamente en una llamada API con un objeto JSON estructurado.
El sistema usaba un modelo de lenguaje (LLM) Claude Sonnet, inicialmente en versión 3.5, con sucesivas actualizaciones sin problemas hasta la 4.0. Este modelo transformaba las preguntas en llamadas API específicas que el backend procesaba para enviar respuestas vía email, documento en Drive o gráficos interactivos.
Para mediados de 2025, la herramienta emitía cientos de informes mensuales, convirtiéndose en la forma estándar en la que los equipos obtenían datos ad hoc. La comunicación entre el LLM y el sistema estaba basada en un contrato claro: un JSON estructurado con campos bien definidos, como «description», «api_call» y «post_body» con parámetros para la consulta. 
Sin embargo, la llegada de Sonnet 4.5 cambió radicalmente esta estabilidad. El modelo comenzó a introducir el contenido destinado a «post_body» dentro del campo «description» y, además, generaba preguntas aclaratorias en lugar de devolver siempre el objeto esperado. Como el sistema no contemplaba estos casos —no había intervención humana ni almacenamiento de solicitudes incompletas— las llamadas API se realizaban sin los parámetros críticos, devolviendo respuestas erróneas o fallos del servidor.
La vuelta a la versión 4.0 fue necesaria, pero compleja. Entre las dos versiones se habían añadido nuevas integraciones API, todas probadas con la 4.5 y que tuvieron que ser reevaluadas para la reversión bajo presión.
Por qué la ingeniería tradicional no funciona con LLMs
Los sistemas de software clásicos permiten prever y limitar el impacto de una actualización mediante notas de versión, pruebas unitarias y un entorno determinista. Sin embargo, los modelos de lenguaje rompen este paradigma: al ser cajas negras cuyo comportamiento no es predecible ni fácilmente testeable en todas sus variantes, cualquier cambio puede generar efectos colaterales imprevisibles, lo que se denomina un «radio de impacto infinito».
Anatomía del fallo
Tras un análisis exhaustivo, se descubrió que la indicación o prompt entregada al modelo estaba incompleta: aunque se definían los campos que debía devolver, no se especificaba claramente que «description» debía ser una cadena en lenguaje natural sin contener fragmentos serializados de otros campos. Las versiones anteriores deducían esta regla implícitamente, pero Sonnet 4.5 adoptó un enfoque más «útil» que violaba el contrato, incluyendo información estructurada y formulando preguntas. El error no estaba en el modelo, sino en asumir que comportamientos no explicitados se mantendrían siempre.
El uso de esquemas estructurados podría haber evitado ciertos problemas sintácticos, pero no garantiza la corrección semántica ni la adecuación a flujos sin interacción humana para aclarar dudas. De ahí la importancia de métodos adicionales para controlar el comportamiento.
Arquitectura basada en evaluaciones continuas
La solución es tratar el conjunto de pruebas o evals como la verdadera especificación formal del sistema, no solo el prompt. El modelo actúa como un intérprete y el conjunto de evals debe validar que cualquier cambio en el modelo o prompt cumple con los criterios establecidos, sirviendo como una barrera para detectar regresiones.
Por ejemplo, una prueba clave para nuestro sistema validaba que el campo «description» no incluyera comandos curl ni fragmentos de «post_body». Este tipo de evals, combinados con otras pruebas manuales o generadas automáticamente y evaluadas incluso con ayuda de modelos LLM para aspectos subjetivos, aseguran que las actualizaciones no rompan invariantes críticas.
No obstante, estas evaluaciones son costosas de desarrollar y mantener, además de no cubrir fallos no previstos. Nuestra experiencia demostró que lo que no se testea explícitamente es un posible punto de fallo.
Horizonte y desafíos en el desarrollo de IA en producción
Actualmente, la comunidad de ingeniería aún carece de estándares para definir coberturas de pruebas en espacios de entrada de lenguaje natural y para manejar resultados probabilísticos en entornos de integración continua. A medida que las IA asumen tareas autónomas más complejas, desde programar hasta gestionar finanzas o infraestructura, se vuelve fundamental estrechar la brecha entre «la IA pasó las pruebas básicas» y «conocemos exactamente su comportamiento en producción».
Quienes consigan establecer procesos rigurosos basados en evaluaciones como especificación oficial serán líderes en garantizar la fiabilidad y seguridad de sus sistemas de IA en los próximos años.
Este análisis ha sido realizado por Vijay Sagar Gullapalli, Ingeniero Fundador en Adopt AI, y Sarat Mahavratayajula, Ingeniero Senior en Sherwin-Williams.
