Si preguntamos a cualquier responsable de datos por qué su organización no tiene la calidad de datos que querría, la respuesta casi nunca es «porque no sabemos que es importante». El problema de la calidad del dato nunca ha sido de convicción: ha sido de coste. Definir las reglas de negocio que los datos deben cumplir exige sentar a los expertos del dominio, traducir su conocimiento a condiciones precisas, programar los validadores, ejecutarlos, interpretar los resultados y, finalmente, corregir lo que está mal. Cada eslabón de esa cadena consume horas de perfiles escasos, y por eso la mayoría de las organizaciones valida solo una fracción de sus datos, con reglas que envejecen mal por su no mantenimiento y se revisan tarde.
Los agentes de inteligencia artificial han irrumpido precisamente en ese punto de dolor. En apenas dos años hemos pasado de los primeros experimentos con modelos de lenguaje que sugerían reglas sueltas a plataformas comerciales que se anuncian como «administradores de datos digitales» y a resultados académicos que documentan reducciones de más de diez veces en el tiempo de construcción de reglas de calidad. La categoría tiene ya nombre propio en los cuadrantes de los analistas —Augmented Data Quality— y la promesa es ambiciosa: que el agente recorra solo, o casi solo, la cadena completa que va de la regla a la medición y de la medición a la corrección.
En este artículo analizamos con cierto detalle qué pueden hacer hoy los agentes de IA en tres tareas concretas: la definición de reglas de negocio, la evaluación de la calidad de los datos y la mejora de esa calidad. Y, con el mismo detalle, qué no deberíamos dejarles hacer solos todavía, porque —adelantamos la tesis— el agente acelera extraordinariamente la ejecución, pero no sustituye ni al marco contra el que se ejecuta ni al criterio de quien lo supervisa.
Antes de empezar: ¿qué es exactamente un agente de IA?
Conviene precisar el término, porque se usa con generosidad. Un agente de IA no es un chatbot que responde preguntas, ni un asistente que autocompleta código. Es un sistema construido sobre un modelo de lenguaje que, ante un objetivo («evalúa la calidad de esta tabla de clientes»), es capaz de planificar los pasos necesarios, usar herramientas para ejecutarlos —consultar el catálogo de datos, perfilar una tabla, escribir y ejecutar código, lanzar una consulta SQL—, observar los resultados de cada paso e iterar hasta completar la tarea o toparse con algo que requiere decisión humana.
Esa capacidad de actuar sobre los sistemas, y no solo de conversar, es la que cambia las reglas del juego en calidad de datos: el trabajo de calidad es, en esencia, un ciclo de hipótesis (¿qué debería cumplir este dato?), verificación (¿lo cumple?) y corrección (¿cómo lo arreglo?), y ese ciclo es exactamente el tipo de bucle que un agente sabe recorrer. La diferencia con la automatización tradicional es la flexibilidad: no hace falta programar de antemano cada comprobación, porque el agente puede formularlas, codificarlas y ejecutarlas sobre la marcha, explicando en lenguaje natural lo que va encontrando.
Primera tarea: la definición de reglas de negocio
Toda evaluación de calidad empieza por una pregunta engañosamente simple: ¿qué deben cumplir estos datos? La respuesta son las reglas de negocio —»el descuento no puede superar el 20% en las tiendas de una determinada región», «todo paciente pediátrico debe tener una edad inferior a 18 años en la fecha de ingreso», «el NIF debe ser válido y único»— y su definición ha sido siempre la parte más cara del proceso, porque el conocimiento está repartido en tres sitios distintos que hay que explotar de tres maneras distintas.
-
- Las reglas que están en los documentos. Buena parte de las reglas no hay que inventarlas: están escritas en normativa, contratos, políticas internas y procedimientos, en lenguaje jurídico o administrativo. La investigación reciente demuestra que los modelos de lenguaje son notablemente buenos extrayéndolas y formalizándolas: existen ya métodos que transforman regulación financiera en vocabularios y reglas estructuradas conforme al estándar SBVR, trazando cada regla hasta el pasaje normativo del que procede, y trabajos recientes que evalúan la generación de modelos de decisión ejecutables (DMN) directamente desde texto legal. Para una organización, esto significa poder convertir «lo que dice la circular» en reglas verificables en una fracción del tiempo, y con la trazabilidad regla-a-fuente que cualquier auditoría agradece.
- Las reglas que están en los datos. Otra parte del conocimiento no está escrita en ningún sitio: está implícita en los propios datos. Aquí el agente actúa como un analista incansable: perfila las tablas, examina distribuciones, formatos y relaciones entre columnas, y propone reglas candidatas que un humano probablemente tardaría semanas en formular. La literatura ha consolidado un patrón de trabajo muy elegante para esto, las llamadas rule cards: el agente no genera código directamente, sino fichas estructuradas de regla —nombre, descripción en lenguaje natural, columnas afectadas, especificación precisa y pseudocódigo— que primero se depuran y validan, y solo después se traducen a validadores ejecutables. La ficha intermedia es importante: es lo que permite que un experto de negocio revise la regla sin leer código.
- Las reglas que están en la cabeza de los expertos. La tercera fuente es la más valiosa y la más difícil de explotar: el conocimiento tácito del negocio. La aportación del agente aquí es abaratar radicalmente la elicitación: el experto describe la regla en su propio lenguaje y el agente la convierte en la expresión formal correspondiente, mostrando al instante qué registros la incumplirían, lo que permite refinarla en conversación («no, las devoluciones no cuentan») hasta dejarla afinada. Las principales plataformas comerciales del mercado ofrecen ya exactamente este flujo en ambas direcciones: del lenguaje natural a la regla ejecutable, y de la regla técnica ya existente a una descripción comprensible para negocio, algo nada menor para la transparencia de los programas de gobierno del dato.
¿Y funciona? Los resultados publicados más sólidos vienen del ámbito sanitario, que es de los más exigentes: un sistema basado en LLM para generar reglas de calidad sobre historias clínicas electrónicas (LLM-DQR, publicado en 2025 en el Journal of Biomedical Informatics) alcanzó coberturas del 97% y el 99% de las reglas de referencia en dos bases de datos hospitalarias distintas, redujo el tiempo de construcción en más de diez veces respecto al método manual y, quizá lo más revelador, propuso 89 reglas adicionales que los expertos no habían previsto y que, tras revisarlas, dieron por válidas. El agente no solo va más rápido: ve cosas que a nosotros se nos escapan.
Ahora bien, la misma literatura que documenta estos resultados documenta el reverso, y conviene contarlo con la misma claridad: los modelos también generan reglas alucinadas —perfectamente redactadas, plausibles y falsas— y reglas contradictorias entre sí, hasta el punto de que los sistemas serios incorporan filtros específicos de detección de conflictos y validación semántica antes de dejar pasar una sola regla a producción. La conclusión práctica es nítida: el agente propone reglas; quien las aprueba es siempre el experto. La productividad no está en eliminar la revisión humana, sino en que el humano revise fichas de regla bien estructuradas en lugar de arrancar de un folio en blanco.
Segunda tarea: la evaluación de la calidad de los datos
Con las reglas definidas, toca medir. Aquí la aportación del agente tiene dos caras: una de volumen y otra de inteligencia.
La cara de volumen es la más evidente. Programar validadores es trabajo de ingeniería repetitivo, y los agentes lo hacen bien y rápido: toman la ficha de la regla y generan el código de comprobación (SQL, Python, expresiones del motor de calidad correspondiente), lo prueban contra los datos, corrigen sus propios errores de ejecución y lo dejan listo. Los sistemas académicos de referencia incorporan para ello bucles cerrados de validación: el código generado se ejecuta en un entorno aislado (sandbox), y si falla, el propio agente depura e itera hasta que funciona. El efecto práctico es que la cobertura deja de estar limitada por las horas de ingeniería disponibles: donde antes se validaban las veinte tablas críticas, ahora puede validarse el catálogo entero, y donde antes la evaluación era una foto anual, ahora puede ser una monitorización continua que detecta la degradación cuando se produce, no cuando alguien la sufre.
La cara de inteligencia es más sutil y, a nuestro juicio, más valiosa. Un motor de reglas tradicional solo encuentra lo que alguien le dijo que buscara; un agente, además de ejecutar las reglas del catálogo, puede detectar anomalías que ninguna regla contemplaba —una deriva en la distribución de una columna, un cambio de patrón en los nulos, una relación entre tablas que deja de cumplirse— y, sobre todo, puede explicar lo que encuentra en lenguaje de negocio: no «la regla R-047 ha fallado en 12.304 registros», sino «desde el día 12, uno de cada cinco pedidos llega sin código postal, coincidiendo con el despliegue de la nueva app; afecta sobre todo a clientes nuevos». Esa traducción del síntoma técnico al relato accionable es, para el día a día de un equipo de datos, casi tan valiosa como la detección misma.
Dicho esto, aquí va la segunda advertencia de rigor, y es la que más nos importa como practicantes de la disciplina: medir no es opinar. Si dejamos que cada agente decida por su cuenta qué entiende por «calidad», obtendremos evaluaciones tan fluidas como incomparables: no habrá forma de saber si la tabla de clientes está mejor que hace un año, ni de comparar dos conjuntos de datos, ni de certificar nada ante un tercero. Por eso la evaluación agéntica debe ejecutarse contra un marco normalizado: las características de calidad de los modelos ISO/IEC 25012 y 25024 —exactitud, completitud, consistencia, credibilidad, actualidad— y los métodos de evaluación que sistematiza la especificación UNE 0081. El reparto de papeles es limpio y conviene formularlo así de claro: la norma define qué se mide y cómo se interpreta; el agente aporta la escala y la velocidad a la que se mide. Un agente evaluando contra UNE 0081 produce resultados comparables, repetibles y certificables; un agente evaluando «a su criterio» produce prosa convincente.
Tercera tarea: la mejora de la calidad de los datos
La tercera pata es la más golosa y la más delicada: no solo detectar el problema, sino corregirlo. Técnicamente, es terreno abonado para los agentes, porque las tareas típicas de remediación son exactamente las que mejor se les dan:
-
- Estandarización: unificar formatos de fechas, teléfonos, direcciones o unidades, y normalizar representaciones inconsistentes de un mismo valor («S.A.», «SA», «Sociedad Anónima»), un problema semántico donde los modelos de lenguaje superan con claridad a las reglas y expresiones regulares tradicionales.
- Deduplicación: identificar que dos registros distintos son la misma entidad real aunque no compartan ningún campo exacto, gracias a la comprensión semántica («Cía. Logística del Sur» y «Compañía Logistica Sur SL» se parecen poco para un algoritmo clásico y mucho para un modelo de lenguaje).
- Imputación: proponer valores para los huecos a partir del contexto del propio registro y de registros similares, con la ventaja de poder justificar cada propuesta.
- Orquestación de la remediación: quizá lo más transformador no es corregir el dato, sino gestionar el incidente completo: el agente que detecta el problema puede diagnosticar la causa raíz apoyándose en el linaje («el error entra por esta integración desde el día del último despliegue»), abrir el incidente, proponer la corrección aguas arriba —que es donde de verdad se arregla la calidad— y verificar el cierre. Las plataformas líderes del mercado han evolucionado en 2025 y 2026 exactamente en esta dirección: del cuadro de mandos que muestra el problema al flujo agéntico que va de la detección al triaje y la remediación.
La evidencia académica acompaña: se ha demostrado que agentes equipados con herramientas de ejecución de código, iterando solos sobre datasets tabulares, consiguen mejorar el rendimiento de los modelos de aprendizaje automático entrenados después con esos datos, únicamente detectando y corrigiendo errores; y los enfoques más recientes organizan la limpieza como comités multiagente, donde unos agentes proponen correcciones, otros las verifican y otros arbitran, precisamente para no depender del juicio de un único modelo.
Y sin embargo, este es el eslabón donde más despacio hay que ir, por una razón que se entiende mejor con un contraste. Cuando un agente detecta mal, el coste es una falsa alarma que alguien descarta. Cuando un agente corrige mal, el coste es un dato plausible y erróneo escrito en los sistemas, firmado por un proceso automático y documentado en un registro de auditoría impecable. Si además la regla que motivó la corrección era una de aquellas reglas alucinadas que el modelo redactó con total convicción, el resultado es lo que podríamos llamar error industrializado: equivocarse a escala, con trazabilidad perfecta y sin que nadie se entere hasta que el daño aflora aguas abajo. La corrección manual se equivocaba de una en una; la corrección agéntica sin gobierno puede equivocarse de un millón en un millón.
La respuesta: autonomía graduada, no autonomía total
Nada de lo anterior es un argumento contra los agentes; es un argumento contra desplegarlos con el mismo nivel de autonomía en todas partes. La práctica sensata que está cristalizando tanto en la literatura como en las implantaciones serias es graduar la autonomía del agente según la criticidad del dato y la reversibilidad de la acción:
|
Nivel de autonomía |
Qué hace el agente |
Qué hace el humano |
Dónde aplicarlo |
|
Asistente |
Propone reglas, genera validadores, sugiere correcciones; no ejecuta nada por sí mismo |
Revisa y aprueba cada regla y cada corrección |
Datos críticos (financieros, clínicos, regulatorios) y primeras fases de adopción |
|
Supervisado |
Ejecuta la evaluación de forma continua y aplica correcciones pre-aprobadas por tipología; encola el resto |
Aprueba tipologías de corrección y revisa excepciones y muestras |
Datos operativos de criticidad media, con reglas ya maduras |
|
Autónomo |
Detecta, corrige y documenta de extremo a extremo, con revisión a posteriori |
Audita muestras, vigila métricas del propio agente, ajusta límites |
Datos no críticos, correcciones reversibles y estandarizaciones de bajo riesgo |
Tres criterios ayudan a decidir en qué escalón situar cada caso: la criticidad del dato (¿qué decisiones alimenta?), la reversibilidad de la acción (¿podemos deshacerla?; toda corrección autónoma debería conservar el valor original) y la madurez de la regla (una regla recién propuesta por el agente no debería habilitar correcciones autónomas; una regla veterana, validada y con historial, sí puede). La autonomía, en definitiva, no se declara: se gana, regla a regla y dominio a dominio.
Gobernar al agente: la nueva tarea del data steward
Queda la pregunta de fondo: si el agente propone las reglas, ejecuta las evaluaciones y aplica las correcciones, ¿qué nos queda a las personas? La respuesta corta: el gobierno. La llegada de los agentes no elimina el trabajo de calidad del dato; lo desplaza un nivel hacia arriba, y ese desplazamiento tiene consecuencias muy concretas:
-
- Toda regla necesita linaje. El catálogo de reglas debe registrar quién propuso cada regla (agente o persona), de qué fuente procede (norma, perfilado, experto), quién la aprobó y qué versión está activa. Cuando una corrección resulte fallida —ocurrirá—, la capacidad de reconstruir por qué el sistema creyó que debía hacerla es la diferencia entre un incidente y una crisis.
- El agente también se mide. Un agente de calidad es software que toma decisiones sobre datos, y merece sus propias métricas: tasa de aceptación de sus reglas propuestas, precisión de sus detecciones, porcentaje de correcciones revertidas. Si la tasa de aceptación de sus propuestas cae, algo ha cambiado en los datos o en el agente, y hay que saberlo antes de que lo cuente un cliente.
- El perfil del equipo cambia. El data steward deja de pasar sus horas escribiendo reglas y validadores para pasar a curar lo que el agente produce: revisar fichas de reglas, decidir niveles de autonomía, auditar muestras de correcciones, afinar los marcos de evaluación. Es un trabajo de más criterio y menos teclado, y las organizaciones que lo entiendan pronto tendrán una ventaja doble: retendrán mejor el talento (desaparece la parte más tediosa del oficio) y escalarán su programa de calidad sin escalar linealmente su plantilla.
- Y una nota de coherencia que no podemos dejar de hacer: un agente que evalúa y modifica datos corporativos es, él mismo, un sistema de IA operando sobre activos críticos, y le aplican las mismas exigencias de gobernanza, transparencia y supervisión humana que defendemos para cualquier otro sistema de IA en la organización. Gobernar los datos con agentes ingobernados sería una ironía cara.
Los agentes de IA están atacando el que siempre fue el verdadero cuello de botella de la calidad del dato: el coste de definir reglas, construir evaluaciones y ejecutar correcciones. La evidencia disponible —académica e industrial— indica que lo están consiguiendo: reglas que se extraen de la norma con trazabilidad, catálogos enteros bajo evaluación continua, remediaciones que van de la detección a la causa raíz. Pero la misma evidencia enseña las dos condiciones del éxito: medir contra marcos normalizados como UNE 0081, para que la velocidad del agente produzca resultados comparables y certificables y no opiniones elocuentes; y graduar la autonomía con puntos de control humanos, porque la diferencia entre productividad y error industrializado es, exactamente, el gobierno que pongamos alrededor. La calidad del dato deja de ser un trabajo de escribir reglas para convertirse en un trabajo de gobernar a quien las escribe. Y ese trabajo, hoy más que nunca, es nuestro.
Si tu organización quiere explorar el uso de agentes de IA en su programa de calidad del dato —desde la generación asistida de reglas hasta la evaluación continua conforme a UNE 0081— con el gobierno y los puntos de control adecuados, en DQTeam podemos ayudarte. ¡Hablemos de datos!
