Por qué los agentes de IA fallan con confianza: no es el modelo ni el contexto, es la ingeniería de datos

El artículo de VentureBeat, firmado por Junaid Effendi, plantea un problema de fondo que muchos equipos de IA empresarial están viviendo sin saber nombrarlo: un chatbot o agente que funcionaba bien al lanzarse empieza, meses después, a dar respuestas equivocadas con total seguridad, sin que nadie haya tocado el modelo ni los prompts. La causa, según el autor, no está en la IA en sí, sino en que el mundo cambió (precios, políticas, versiones de producto) y el almacén de conocimiento del que se alimenta el sistema no se actualizó al mismo ritmo.

El núcleo del argumento es que este tipo de fallo es invisible por diseño. Ya sea que un agente recupere información de una base vectorial, un índice de documentos o una llamada a una API, el mecanismo de recuperación evalúa relevancia o disponibilidad, no corrección. Un documento de precios obsoleto se recupera con la misma confianza que uno vigente, y un registro con un campo silenciosamente vacío pasa los mismos controles que uno completo. El resultado es que los paneles de control siguen en verde, el pipeline parece funcionar, y sin embargo el sistema está dando información falsa. El autor ilustra esta dinámica con un caso fuera del ámbito de la IA: en una empresa fintech, un sistema ascendente cambió un campo sin avisar a los sistemas que dependían de él, y el pipeline no falló técnicamente, simplemente propagó valores incorrectos hacia los paneles, porque solo se verificaba que el trabajo se completara, no que los datos siguieran siendo correctos. El problema solo se detectó cuando un cliente notó una inconsistencia, para entonces los datos erróneos ya se habían propagado.

Según el artículo, las organizaciones que se topan con este fallo suelen diagnosticarlo mal, y encima dos veces. El primer instinto es culpar al modelo y probar con otro LLM o ajustar el prompt. Descartado esto, el segundo instinto es culpar a la capa de recuperación (retrieval) y buscar una herramienta mejor. El autor conecta este segundo instinto con movimientos recientes del mercado: AWS habría entrado en la carrera de la "capa de contexto" con un grafo de conocimiento que aprende del uso de los agentes, y Snowflake habría lanzado Horizon Context y Cortex Sense apuntando justamente al síntoma descrito al inicio del artículo, agentes que responden mal con confianza porque nada gobierna la lógica de negocio subyacente. El autor reconoce que ambas son respuestas reales a un problema real, pero sostiene que se sitúan una capa por encima de la raíz: un grafo de conocimiento sigue dependiendo de lo que lo alimenta. El problema real está más arriba, en la ingeniería de datos, donde los equipos comprueban si un trabajo se ejecutó, no si los datos que movió siguen siendo ciertos, un hábito anterior a la IA que la monitorización actual arrastra: está pensada para vigilar el pipeline, no los datos.

Lo que falta, argumenta el autor, es observabilidad de datos entendida de forma rigurosa. La métrica relevante no es un porcentaje aislado sino la cobertura: qué fracción de los conjuntos de datos críticos tiene un linaje (lineage) realmente consultable, en lugar de vivir solo en la cabeza de alguien. Como ejemplos previos a la llegada de los LLM, el artículo cita a Uber, que construyó una plataforma dedicada de calidad y observabilidad de datos (Unified Data Quality) que cubre más de 2.000 conjuntos de datos críticos y detecta alrededor del 90% de los incidentes de calidad antes de que lleguen a los consumidores posteriores. Netflix, por su parte, habría resuelto una pieza distinta del mismo problema construyendo un sistema de linaje de datos a escala de toda la compañía, que permite a cualquiera rastrear de dónde proviene un conjunto de datos y qué lo tocó en el camino, mapeando dependencias entre topics de Kafka, modelos de machine learning y experimentos, no solo tablas de un data warehouse. El autor señala que ambos sistemas se diseñaron originalmente para humanos y que su importancia ha crecido con el auge de las aplicaciones de IA/LLM.

Entre Uber y Netflix, el artículo sostiene que se cubren solo dos de cuatro dimensiones que, según el autor, hay que medir por separado: primero, corrección (correctness), es decir si cada registro cumple la forma y las reglas esperadas, tipos de campo correctos, sin nulos inesperados, valores dentro de rango; para esto se mencionan herramientas como Great Expectations y Soda, que permiten validación automatizada a nivel de fila y columna en lugar de comprobaciones manuales tras un fallo, midiendo el porcentaje de registros que pasan la validación en cada ejecución. Segundo, frescura (freshness), o si los datos siguen siendo actuales respecto a su fuente y no solo respecto a la última vez que se comprobaron; se propone medir el tiempo desde la última actualización exitosa por fuente, con un SLA específico por conjunto de datos en lugar de un umbral único, ya que algunas fuentes necesitan refresco horario y otras no. Tercero, consistencia (consistency), es decir si el mismo hecho se lee igual en todos los sistemas donde se almacena o indexa; este fallo es silencioso y solo aparece cuando dos sistemas alimentados por la misma fuente empiezan a discrepar, por lo que basta una comprobación cruzada periódica entre destinos posteriores que marque cuando la tasa de discrepancia supera un umbral. Cuarto, linaje (lineage), la capacidad de rastrear cualquier salida hasta su origen y cada transformación por la que pasó, la misma pregunta que Netflix resolvió con su sistema.

El autor añade una experiencia propia en Socure, donde los datos de los clientes llegaban en el formato que cada cliente quisiera enviarlos, y ocasionalmente de forma silenciosamente incorrecta. El reto fue construir un sistema capaz de identificar datos incorrectos antes de que se propagaran río abajo, aplicando los mismos principios: validar lo que llega, entender de dónde viene, y evitar que los datos malos se conviertan en problema de otro. Great Expectations formó parte de esa base, junto con validación de esquema y rango en la ingesta, SLA de frescura por fuente, comprobaciones cruzadas de consistencia y linaje a nivel de archivo, todo ello sostenido por un patrón de "write-audit-publish" (escribir-auditar-publicar), en el que los datos aterrizan primero en un área de staging, se validan, y solo avanzan río abajo si superan las comprobaciones exigidas. Según el autor, el resultado se notó en mejoras de precisión tanto en reporting como en modelos de machine learning y en la recuperación de datos para IA construida sobre esa misma base.

El artículo cierra con una lista de cuatro preguntas de diagnóstico para quienes operan sistemas de IA basados en recuperación de datos en producción, planteando que la pregunta relevante no es qué modelo probar después ni a qué arquitectura de recuperación migrar: ¿los datos subyacentes están validados según los estándares que exigen sus consumidores?, ¿cuál es la pieza de contenido más antigua que se está sirviendo actualmente con alta confianza?, ¿podrían dos fragmentos de la misma fuente llegar a contradecirse dentro de un mismo resultado de recuperación?, y ¿se podría rastrear el origen de un dato si resultara ser erróneo? Si estas preguntas no se pueden responder, concluye el autor, el problema está en el pipeline entre los sistemas fuente y lo que lee el agente, y la solución pasa por ingeniería de datos, no por cambiar de modelo ni de proveedor. Cierra con la idea de que, ya se trate de pipelines de reporting, sistemas de machine learning o agentes de IA, la corrección, la frescura, la consistencia y el linaje son lo que hace confiables a los datos, y que la IA simplemente está exponiendo debilidades que ya existían en la ingeniería de datos desde antes.