Por qué la Calidad del Dato es el verdadero motor de los Agentes IA

Nos venden a diario la magia de los ‘Agentes de IA autónomos’ que harán nuestro trabajo. La teoría de un sistema que piensa y ejecuta por sí solo es preciosa. Pero detrás de tanta promesa hay una gran trampa: un agente nunca será más inteligente que los datos de los que se alimenta.

La calidad del agente depende directamente de la calidad del dato.

Imagina que le preguntas a un nuevo empleado “¿cuántos ingresos tuvimos el mes pasado?” y, en vez de responder, abre 40 carpetas distintas, que están etiquetadas más o menos como “ingresos”, cada una con un número diferente. Este es exactamente el problema al que se enfrenta un agente cuando lo conectamos a un sistema de almacenamiento de datos real. No hay un ingreso, hay muchas tablas y métricas que se parecen, con pequeños matices (¿incluye devoluciones? ¿y usuarios de prueba? ¿en qué moneda?).

El agente no falla porque no sepa sumar. Falla porque no sabe qué sumar. Y aquí está la trampa: si el agente tiene que elegir entre 40 candidatos posibles, elegirá uno, sea o no el correcto, y te lo presentará con la misma convicción con la que presentaría el número correcto.

Los datos que caducan sin avisar

Hay un segundo problema más traicionero todavía. Las definiciones y reglas de negocio cambian, los esquemas cambian, los productos se renombran… y el agente sigue funcionando como si nada hubiera pasado. No se rompe con un error visible. Sigue respondiendo con la misma seguridad, solo que ahora la respuesta es sutilmente incorrecta. Es la versión silenciosa del Garbage in, garbage out.

La aguja en el pajar (y por qué tener más datos no es la solución)

Los tres síntomas que explican casi cualquier respuesta incorrecta de un agente de datos. 

Aquí viene la parte paradójica. Podríamos pensar que la solución a la ambigüedad es darle al agente acceso a todo. Todas las tablas, todo el histórico de consultas, toda la documentación. El resultado sería casi nulo y la precisión apenas cambiaría, incluso si comprobásemos que la respuesta correcta estaba en ese historial y el agente la hubiera leído. El cuello de botella no está en el acceso a la información sino en la falta de estructura para relacionar la pregunta con la entidad correcta. Tener más datos no ayuda si el agente no sabe cuáles de esos datos importan para la pregunta que le acaban de hacer.

Cómo lo resolvemos: menos candidatos, no más datos

La respuesta a los tres problemas anteriores no es “más IA”, es más gobernanza del dato. La lógica que aplicar es la misma que la del Golden Record para clientes duplicados. Si un concepto como “ingresos” puede resolver a 40 tablas distintas, el trabajo no es que el agente adivine mejor entre esas 40, es reducirlas a una sola, gobernada y con dueño.

• Crear conjuntos de datos canónicos: una única tabla o métrica de referencia para cada concepto de negocio eliminando sin contemplaciones las versiones obsoletas. Cuando el agente busca “ingresos”, encuentra una respuesta, no 40.
• Implantar una capa semántica obligatoria: un catálogo de métricas predefinidas que el agente debe consultar antes de generar SQL. Si la métrica existe, la utiliza tal cual, y solo cuando no está disponible, explora otras opciones.
• Documentar las excepciones, no solo las tablas: registrar los filtros obligatorios, las columnas obsoletas y las diferencias entre tablas aparentemente iguales. Es como actualizar un cliente en un CRM desordenado con tres perfiles llamados “Juan Pérez” y sin otro dato para distinguirlos. El problema es la coexistencia de varias versiones sin una referencia clara.
• Aplicar estándares con mecanismos de control: el agente se dirige por diseño a las fuentes canónicas, la integración continua bloquea cualquier cambio que las omita y los modelos, la capa semántica y su documentación se mantienen en el mismo repositorio. Así, cada cambio en un modelo actualiza también su documentación.

También cabría probar y descartar que un LLM generara por sí solo las definiciones de la capa semántica a partir de tablas e histórico de consultas. El resultado no sería bueno porque produciría definiciones plausibles, pero reproduciría las mismas ambigüedades que se pretenden eliminar. Sería como pedirle a un alumno que se evaluara a sí mismo. Lo recomendable es usar IA para redactar la documentación, pero que una persona del equipo valide siempre la definición final.

En el stack de seis capas descrito en Arquitectura de Agentes, la capa semántica y la documentación de excepciones constituyen la memoria semántica del agente, donde el conocimiento de dominio evita empezar cada consulta desde cero. Como señalábamos en el artículo, una memoria mal diseñada puede perjudicar al sistema en lugar de mejorarlo. Esta capa marca la diferencia.

No basta con dar buenos datos: hay que saber pedirle las cosas al agente

Aquí hay un matiz que se pasa por alto muchas veces. Puedes tener el dato perfectamente limpio, gobernado y sin duplicados y aun así obtener una respuesta mediocre si el agente recibe instrucciones imprecisas o simples. Un prompt ambiguo produce resultados ambiguos, exactamente con el mismo espíritu del “garbage in, garbage out” pero aplicado a las instrucciones, no solo a los datos.

• Ser directos y específicos: en vez de decirle al agente “analiza estas ventas”, indicar qué comparar, con qué periodo y bajo qué filtros. La especificidad reduce el margen para que el agente rellene huecos por su cuenta.
• Separar contexto, datos e instrucciones con claridad: usar etiquetas que marquen explícitamente qué es una instrucción y qué es un dato de entrada, para que el agente no mezcle ambas cosas.
• Dar ejemplos, no solo descripciones: un par de ejemplos de “esto está bien” y “esto está mal” enseña más rápido que un párrafo de reglas abstractas, sobre todo en tareas de clasificación o extracción de datos.

Esta es la memoria procedimental del agente, las instrucciones explícitas sobre cómo actuar. Si son vagas, el agente improvisa el proceso en cada ocasión y puede ejecutarlo de forma distinta sin perder seguridad en su respuesta.

Ponemos al agente a examen antes de lanzarlo a producción

Ningún agente sale a producción sin pasar antes por un examen con nota. La capa de validación agéntica es obligatoria para lanzar un agente a producción. Sin esta validación, todos los pasos anteriores no sirven de nada. En el artículo de QA Tradicional comentamos el sistema de validación necesario para ello.

Sistemas legacy y permisos: hasta dónde dejamos llegar al agente

Casi ningún cliente empieza de cero. Hay ERPs antiguos, CRMs con años de parches y APIs que nunca se diseñaron pensando en que un agente autónomo las iba a usar. Y aquí aparece la pregunta ¿qué puede hacer realmente el agente sin poner en riesgo el negocio?

La solución no es dar acceso total ni dar acceso mínimo: es diseñar funciones concretas y acotadas que encapsulen las reglas de negocio, no la tabla entera. El agente puede crear una reserva, pero no tocar precios ni datos financieros. Para estandarizar esto hacemos uso de Model Context Protocol (MCP): herramientas (“tools”) con un contrato de entrada y salida bien definido, recursos de solo lectura para la documentación de referencia (“resources”), y plantillas reutilizables (“skills” con prompts) para que distintos agentes resuelvan la misma tarea recurrente de la misma forma. Así, el agente operaría siempre a través de la puerta diseñada para ello, nunca directamente contra el sistema legacy.

El último tramo: vigilar al agente cuando ya está trabajando

Aprobar el examen no es el final, es el punto de partida. Una vez el agente está en producción, conviene seguir vigilando cuál de los tres síntomas iniciales se filtra sin que nadie lo note.

• Revisión adversarial: una skill que cuestiona y evalúa la respuesta antes de entregarla. Aumenta la precisión a costa de consumo de tokens y latencia, por lo que conviene reservarla para las preguntas de mayor impacto.
• Pie de página de procedencia: cada respuesta indica su fuente, qué tan reciente es y quién posee el modelo, para que el lector sepa cuánto puede fiarse de ella.
• Comprobaciones de calidad del dato: el agente puede usar el campo correcto de la forma correcta y aun así fallar si el dato subyacente es incorrecto. Por eso conviene verificar actualidad, completitud y anomalías antes de confiar en una fuente.
• Recolección activa de correcciones: cuando alguien corrige al agente “esa no es la tabla correcta”, la corrección se convierte automáticamente en una propuesta de mejora de la documentación, cerrando el círculo entre producción y las skills.

Las seis capas que blindan la calidad del dato en un agente, de los fundamentos a la validación en producción. 

Cuando funciona: el agente que sí sabe de qué habla

Aplicando esta disciplina completa de datasets canónicos, capa semántica obligatoria, documentación de referencias, instrucciones claras, un examen que hay que aprobar antes de salir a producción y vigilancia continua, es posible llevar a un cliente a automatizar la gran mayoría de sus consultas de análisis de negocio a través de un agente, liberando a sus equipos del trabajo repetitivo para centrarse en análisis de más valor. La diferencia no la marcaría un modelo más grande, la marcaría reducir 40 candidatos a 1 antes de que el agente tuviera que adivinar nada.

Cuando no funciona: las formas en que un agente puede fallar

• El fallo silencioso: imaginemos que la documentación de un proyecto deja de actualizarse al mismo ritmo que cambian los datos, y que en un solo mes la precisión cae de forma drástica sin que nadie lo note hasta que un cliente detecta un número raro. El agente nunca avisaría de que “algo no le cuadra”, simplemente seguiría respondiendo con la misma seguridad de siempre, sobre datos que ya no son ciertos.
• El acceso sin criterio: dar acceso total a todo el histórico de consultas no bastaría cuantos más datos, cero mejoras, porque lo que falta es estructura, no información.
• La capa semántica autogenerada: dejar que el propio modelo defina sus métricas sin supervisión humana reproduciría la ambigüedad que se pretende resolver.

Conclusión: la calidad del dato importa más que el modelo

La experiencia con distintos proyectos apunta a que la diferencia no está en utilizar un modelo más grande, sino en reducir la ambigüedad antes de que el agente tenga que interpretar o completar información por su cuenta.

Un agente de datos trabaja siempre sobre un entorno cambiante: datos en tiempo real, esquemas que evolucionan y reglas de negocio que se actualizan. En este contexto, la calidad del dato deja de ser una tarea previa para convertirse en el pilar fundamental de todo el sistema.

• El problema es la inconsistencia del dato, no el modelo. Cuando un concepto como “ingresos” puede resolverse a partir de 40 tablas distintas, ningún LLM, por potente que sea, puede garantizar una respuesta fiable. El fallo nace de la ambigüedad, no de la falta de inteligencia.
• Fuentes de verdad únicas e instrucciones precisas. Los datasets canónicos, una capa semántica obligatoria y una documentación clara de las excepciones reducen la variabilidad desde el lado del dato. Del mismo modo, los prompts directos, el contexto bien estructurado y los ejemplos concretos la reducen desde el lado de las instrucciones. El objetivo es limitar tanto el número de opciones posibles como los vacíos que el agente debe completar por sí mismo.
• Validar antes y supervisar después. Ningún agente debería llegar a producción sin superar un proceso riguroso de evaluación. Una vez desplegado, es necesario monitorizar su consistencia de forma continua, porque los datos, las reglas de negocio, los prompts y los propios modelos no dejan de cambiar.

En esencia, esta es nuestra especialidad: garantizar la calidad del dato, de las instrucciones y del agente durante todo su ciclo de vida. Por eso hablamos de QA para agentes de IA. Esa capa de control es la que separa a un agente que impresiona en una demostración de uno en el que el negocio puede confiar cada día.