Todo el que trabaja con datos ha recibido esa llamada. Un número de un informe es incorrecto y alguien tiene que averiguar por qué antes de que empiece la reunión. La investigación que sigue es casi siempre la misma: qué fuente, qué carga, qué columna, hasta dónde se ha propagado y qué hacemos al respecto.

Durante veinte años, las herramientas han mejorado de forma constante en una parte de ese trabajo: detectar. Las reglas capturan lo que alguien anticipó. La observabilidad capta lo que se movió. Pero entre la alerta y la corrección sigue habiendo una persona, una cola y, muy a menudo, un lunes por la mañana.

Este artículo se pregunta si eso tiene que seguir siendo así. ¿Pueden los datos corregirse solos? La respuesta honesta es: en parte, bajo condiciones que se pueden poner por escrito. Y esas condiciones resultan ser más interesantes que la propia automatización.

Calidad de datos y observabilidad de datos: dos disciplinas, ninguna suficiente

La calidad de datos es el grado en que los datos son aptos para el propósito para el que se utilizan, medido frente a una expectativa que alguien tuvo que poner por escrito. Es una propiedad de los propios datos: valores, claves, relaciones. Es relativa a un propósito, porque una hora de salida suficientemente buena para un informe mensual no lo es para solicitar un slot aeroportuario. Y es declarativa. Una regla solo encuentra lo que alguien ya había previsto.

La observabilidad de datos es la capacidad de comprender la salud y el comportamiento de sus datos a partir de las señales que emiten, sin saber de antemano qué va a fallar. La frescura, el volumen, el esquema, la distribución y el linaje se aprenden del histórico en lugar de ser especificados por el negocio, y por eso la observabilidad escala a todas las tablas. Ese es también su límite: la observabilidad puede decirle que algo ha cambiado, nunca que algo está mal.

Ninguna disciplina contiene a la otra. Piense en un tiempo de bloque de 92 minutos en una ruta que normalmente dura 148. El número de filas es normal, la tabla está actualizada, el esquema no ha cambiado y el valor está holgadamente dentro de cualquier rango global. Supera todas las comprobaciones y, aun así, es incorrecto. Es la brecha que describimos en nuestro artículo sobre datos que parecen incorrectos pero superan sus reglas, y la comparación completa de ambas disciplinas está en observabilidad de datos frente a calidad de datos.

¿Qué es la calidad de datos autónoma?

La calidad de datos autónoma es la capacidad continua, impulsada principalmente por IA, de detectar, investigar, evaluar y remediar problemas de calidad de datos con una intervención humana mínima. Cuatro verbos, y los tres últimos son los que la distinguen de las herramientas que la mayoría de los equipos ya tienen:

• Detectar: algo se ha movido lo suficiente como para merecer atención.

• Investigar: qué fuente, qué carga, qué columna.

• Evaluar: cuán grave es y qué depende de ello.

• Remediar: poner en cuarentena, retener o volver a ejecutar, y registrar exactamente lo que se hizo.

Casi todos los productos del mercado se detienen hoy después del primer verbo. Al igual que la observabilidad, la calidad de datos autónoma se adapta: los umbrales y las prioridades siguen a los datos en lugar de quedarse congelados el día en que alguien los escribió. En la práctica, es el intento de usar las señales que produce la observabilidad para generar el trabajo de calidad que antes exigían las reglas.

Por qué esto empieza a ser posible ahora

Dos cosas están cambiando al mismo tiempo. La primera es la forma de la plataforma de datos. El data warehouse central, propiedad de un único equipo que acordaba qué era un cliente o un pasajero, está dando paso a productos de datos con sus propios responsables, contratos y ciclos de publicación. Ahora la calidad tiene que mantenerse en cada frontera que cruzan los datos, no solo donde aterrizan, y ya nadie es dueño de toda la cadena.

La segunda es la llegada de agentes por encima de esa plataforma. A un agente no hace falta decirle cómo. Hay que decirle qué, y hasta dónde puede llegar. Tomemos una recarga rutinaria. Hoy, un ingeniero busca el procedimiento almacenado y sus parámetros, la API de origen con su autenticación y su paginación, escribe los reintentos y la gestión de errores, y lo reescribe todo cuando un socio cambia su exportación. Con un agente, la instrucción se convierte en una frase: vuelve a cargar los registros de embarque de ayer de un vuelo. El agente encuentra el procedimiento y la API en el catálogo, ordena las llamadas, reintenta y verifica él mismo el número de filas.

Es un modelo de integración distinto de todo lo que hemos construido hasta ahora. Dedicaremos menos tiempo a especificar cómo se hace una recarga y más a especificar qué se puede recargar, quién puede hacerlo y sin preguntar a quién.

Un tramo de vuelo, cinco respuestas distintas

Para concretarlo, tomemos Alpenwing Airways, una aerolínea europea ficticia de tamaño medio cuyos problemas son completamente reales. Siete sistemas describen el mismo vuelo: reservas, control de salidas, la base de datos operativa del aeropuerto, mantenimiento, planificación de tripulaciones, contabilidad de ingresos y once fuentes de socios de código compartido. Ninguno de ellos está equivocado. Se construyeron para tareas distintas en momentos distintos, y el data warehouse es donde sus desacuerdos se hacen visibles. Esto es lo que hace un agente con cinco alertas sobre un único tramo de vuelo, el WG 402 de Viena a Varsovia.

1. La fuente de un socio pasa de códigos de aeropuerto IATA a ICAO de la noche a la mañana

La longitud media de la columna del aeropuerto de salida pasa de 3,00 a 4,00 en una sola fuente, y 1.284 filas no superan la comprobación de valores permitidos. Nada más se ha movido en esa fuente. Un Data Steward aprobó la correspondencia de LOWW a VIE hace meses, el registro ICAO publicado la confirma y la corrección es reversible. Es el caso más sencillo que existe y está cerca de lo que ya es posible hoy.

2. El vuelo embarca 36 pasajeros en un avión de 180 plazas

Un factor de ocupación de 0,20, en una ruta que no ha bajado de 0,72 en dos años, mientras todos los demás tramos del día parecen normales. Existe un patrón aprobado exactamente para esto: volver a cargar el tramo y verificarlo frente a un segundo recuento independiente del sistema de reservas. El linaje muestra que tres data marts y el informe diario de operaciones dependen de él, así que el agente los retiene hasta que se confirma el recuento.

3. El control de salidas cuenta 168 pasajeros y la base de datos del aeropuerto, 171

Una conciliación programada falla por tres pasajeros, y la observabilidad no ve absolutamente nada: 168 es un número normal y 171 también. La diferencia resulta ser de definición. ¿Es pasajero un bebé que viaja en el regazo? Ninguna entrada del catálogo lo responde y ningún patrón aprobado lo cubre. El agente puede hacer todo el análisis. La definición sigue siendo una decisión humana.

4. La fuente operativa del aeropuerto llega con tres horas de retraso

La fuente suele llegar antes de las 02:30. A las 05:40 todavía no ha llegado, y el informe de operaciones debe ejecutarse a las 06:00. No salta ninguna regla de calidad de datos, porque los datos no son incorrectos: simplemente no están. Aplazar las cargas dependientes ante una llegada tardía es un patrón aprobado, así que el agente utiliza el linaje y el registro de cargas para retener exactamente los informes que, de lo contrario, se ejecutarían con las cifras de ayer, y nada más.

5. La ciudad de destino llega como texto libre

Wiedeń, Viena y Wien se refieren todas a la misma ciudad. Los valores distintos saltan de 41 a 63 en un día, y 2.140 filas no coinciden con ninguna lista de referencia. Internet abierto sirve para saber que Wiedeń es Viena en polaco, pero nunca es suficiente por sí solo. Una correspondencia solo es segura frente a un dominio declarado: los 94 aeropuertos a los que Alpenwing vuela realmente. Aquí es hacia donde se dirige la tecnología, más que donde está hoy.

Las cuatro comprobaciones que deciden si un agente puede actuar solo

Cada uno de esos escenarios pasa por la misma puerta, construida con cuatro preguntas verificables. Ninguna de ellas es la confianza del propio modelo, que no está calibrada y nunca debería ser el motivo para modificar un data warehouse.

• ¿Se ha aprobado antes exactamente este patrón? Si un Steward lo aprobó una vez, la décima vez es una consulta y no un juicio. Es la señal individual más fuerte, pero no es ni necesaria ni suficiente.

• ¿Es reversible la acción? La cuarentena, la retención, la nueva solicitud y la recarga pueden deshacerse. Sobrescribir un valor en su sitio no. Las acciones reversibles se ganan mucha más libertad.

• ¿Es la fuente autorizada y está fechada? Un registro publicado con fecha de publicación justifica actuar. Una respuesta plausible sin ninguna cita no, por muy segura que suene.

• ¿Qué tamaño tiene el radio de impacto? Una fila en cuarentena no es lo mismo que una dimensión con la que se cruzan todos los data marts, y esto, a su vez, no es lo mismo que una cifra ya presentada ante un regulador.

El orden en que un agente consulta sus fuentes importa igual. Primero va su propia base de conocimiento: el catálogo, el linaje, los contratos y la biblioteca de patrones aprobados. Los registros publicados van en segundo lugar. Internet abierto sirve solo para orientarse, y la memoria del propio modelo es la fuente más débil de todas, porque una respuesta que nadie ha consultado es indistinguible de una que sí se investigó. Un agente que no puede nombrar su fuente no puede actuar.

La libertad que recibe el agente se fija por dominio y por producto de datos, nunca de una sola vez para toda la empresa. Un banco regulado puede permitir solo propuestas, cada una a la espera de un aprobador con nombre. Los datos operativos de una aerolínea pueden dejar que las acciones reversibles se ejecuten solas mientras todo lo irreversible se propone. Un producto de datos de marketing puede ejecutar la mayoría de las correcciones sin supervisión y revisarse semanalmente de forma agregada. Y sea cual sea la configuración, cada acción lleva consigo su evidencia, cada acción puede revertirse por separado y los patrones aprobados se supervisan y caducan, porque el mundo puede cambiar bajo un patrón que antes era correcto.

Lo que la calidad de datos autónoma todavía no puede hacer

Los límites se han desplazado. No han desaparecido, y tres de ellos son permanentes.

• No puede inventar una fuente de verdad. Si un pasajero embarcó realmente lo registra el escaneo de embarque y nada más. Si las dos copias de una cifra están mal a la vez, la conciliación las confirmará sin problema, porque compara, no verifica.

• No puede definir el propósito. Si un bebé cuenta como pasajero, qué sistema es el autorizado y si se puede reexpresar el histórico después de haber comunicado una cifra a un regulador son decisiones de negocio. Alguien tiene que asumirlas, por escrito.

• No corrige el origen. Una fuente que se repara en silencio para siempre es una fuente que nunca se repara en origen, porque el proveedor nunca sufre las consecuencias. Por eso cada corrección automática debe seguir comunicándose.

Qué ocurre con el Data Steward

Todo equipo de datos conoce ese lunes por la mañana: cuarenta y una alertas en la cola del fin de semana, de las que tres son problemas reales. La calidad de datos autónoma no hace desaparecer ese montón. Elimina su parte repetible.

Lo que desaparece es leer la misma alerta por cuadragésima vez, perseguir a un socio por una fuente que ha vuelto a fallar y relanzar cargas a mano a las siete de la mañana. Lo que lo sustituye es mantener la biblioteca de patrones de resolución aprobados, decidir qué significa realmente un valor ambiguo, auditar las decisiones del agente de forma agregada y fijar cuánta libertad recibe cada producto de datos. El Data Steward deja de corregir problemas uno a uno y empieza a decidir cómo se corrigen los problemas. Es un puesto más sénior que el que ocupan hoy la mayoría de los stewards, más cercano a la política que a las operaciones. No se elimina a nadie. Se elimina el trabajo que escalaba mal.

Reflexión final: precedente, reversibilidad y evidencia, no confianza

Un agente de propósito general con credenciales de base de datos no es calidad de datos autónoma. Sin un catálogo, no sabe si una columna contiene un código o una etiqueta, y adivina con total seguridad. Sin linaje, no puede delimitar una nueva ejecución ni valorar un radio de impacto. Sin una biblioteca de patrones, cada caso es el primero, nada se acumula y el Steward nunca recupera tiempo. Sin esas tres cosas, un modelo de lenguaje no debería acercarse a su data warehouse.

Por eso la calidad de datos autónoma debe estar dentro de la plataforma de calidad de datos y no a su lado. La base ya tiene que existir: digna Data Anomalies aprende qué es lo normal sin umbrales manuales, digna Data Validation aplica reglas auditables a nivel de registro, digna Timeliness aprende los patrones de llegada junto con los calendarios que usted declara, digna Schema Tracker detecta los cambios estructurales y digna Data Analytics sigue la tendencia de las propias métricas a lo largo del tiempo. Todo ello se ejecuta in-database, sin que los datos salgan de su entorno. El gradiente de confianza, la puerta de autonomía, el rastro de evidencias y la biblioteca de patrones descritos aquí son la dirección hacia la que digna está construyendo.

¿Pueden los datos corregirse solos? No por sí mismos. Pero con precedente, reversibilidad y evidencia, una parte cada vez mayor puede corregirse sin esperar al lunes.

Conozca la base sobre la que se construye la calidad de datos autónoma.

digna aprende qué es lo normal en todas las tablas, in-database, en la nube u on-premise, sin umbrales manuales que mantener. Es la capa de evidencia que un agente necesita antes de que se pueda confiar en él para actuar.

Reserve una demostración personalizada → Explore la plataforma digna

Preguntas frecuentes

¿Qué es la calidad de datos autónoma?

La calidad de datos autónoma es la capacidad continua, impulsada principalmente por IA, de detectar, investigar, evaluar y remediar problemas de calidad de datos con una intervención humana mínima. La mayoría de las herramientas se detienen hoy en la detección; la parte autónoma es la investigación, la evaluación del impacto y una corrección registrada y reversible.

¿En qué se diferencia la calidad de datos autónoma de la observabilidad de datos?

La observabilidad de datos aprende líneas base de frescura, volumen, esquema y distribución y le indica que algo ha cambiado. La calidad de datos autónoma usa esas señales como disparadores, investiga la causa, evalúa qué depende de los datos y aplica una acción acotada, como una cuarentena, una retención o una recarga.

¿Cuándo puede un agente de IA corregir datos por sí solo?

Lo deciden cuatro comprobaciones: si ese patrón exacto se aprobó antes, si la acción es reversible, si la fuente es autorizada y está fechada, y qué tamaño tiene el radio de impacto. La confianza del propio modelo nunca es una de ellas, porque no está calibrada.

¿En qué fuentes debería confiar un agente de calidad de datos?

Primero en su propia base de conocimiento: el catálogo, el linaje, los contratos y los patrones aprobados. Después, en registros publicados como las listas de códigos IATA o ICAO. Internet abierto solo sirve para orientarse, y la memoria del modelo sin fuentes es la más débil. Un agente que no puede nombrar su fuente no debería actuar.

¿Sustituirá la calidad de datos autónoma al Data Steward?

No. Elimina la parte repetitiva del trabajo, como releer la misma alerta o relanzar cargas a mano. El Steward pasa a mantener patrones de resolución aprobados, decidir qué significan los valores ambiguos y fijar cuánta libertad recibe cada producto de datos, algo más cercano a la política que a las operaciones.