Agente de IA para data ops: calidad de los datos y supervisión de pipelines

El problema

Los incidentes de calidad de datos no siempre se anuncian con una alerta. Una encuesta realizada por Wakefield Research para Monte Carlo entre 200 profesionales de datos en marzo de 2023 indica que el 74 % de los encuestados ve que sus partes interesadas de negocio identifican un problema de datos antes que su propio equipo, "todo o la mayor parte del tiempo". Dicho de otro modo, en la mayoría de las organizaciones es un dashboard erróneo detectado por un comercial, o un cuadro de mando incoherente señalado por la dirección, lo que dispara la alerta, no una monitorización interna.

Esta misma encuesta cuantifica el deterioro de un año a otro: el número de incidentes mensuales pasó de 59 en 2022 a 67 en 2023, el tiempo medio de resolución se disparó un 166 % hasta alcanzar las 15 horas por incidente, y la proporción media de ingresos afectada por un incidente de datos pasó del 26 % al 31 %. Una encuesta anterior de Monte Carlo (más de 300 profesionales entrevistados en 2022) ya encontraba que los data engineers dedicaban el equivalente a dos días por semana, alrededor del 40 % de su tiempo, a corregir problemas de datos en lugar de construir nuevos pipelines.

El costo financiero sigue la misma tendencia. Un artículo de IBM publicado en 2025 y que cita un informe de Forrester señala que más de una cuarta parte de las organizaciones encuestadas estima perder más de 5 millones de dólares al año por una mala calidad de los datos, y un 7 % más de 25 millones de dólares. El mismo artículo cita el caso documentado de Unity Technologies, que estimó en unos 110 millones de dólares la pérdida de ingresos publicitarios causada por conjuntos de datos corruptos en 2022. El IBM Institute for Business Value añade que el 43 % de los directores de operaciones sitúan la calidad de los datos en la cima de sus prioridades de datos en 2025. El motivo común a todos estos estudios: los datos se rompen más rápido de lo que se supervisan, y nadie se da cuenta hasta que el daño es visible aguas abajo.

Qué hace el agente, paso a paso

Un agente de IA autónomo dedicado a los data ops funciona de forma continua en su propio entorno, no solo cuando se le consulta. Revisa regularmente los dashboards y los monitores de Datadog asociados a los pipelines y tablas monitorizados: latencia de los jobs, tasa de fallos, volumen de datos procesado.

En paralelo, verifica reglas de calidad simples sobre las tablas que se le han confiado: si la frescura de los datos tiene un retraso anómalo, si el volumen cargado es coherente con el histórico, si la tasa de valores nulos se desvía, si ha aparecido un cambio de esquema sin avisar. En cuanto una desviación significativa sale de la línea base observada, el agente busca contexto en lugar de limitarse a un simple umbral superado: consulta el historial de commits y pull requests recientes en el repositorio del pipeline afectado, para detectar un cambio de código correlacionado en el tiempo con la anomalía.

Antes de abrir un ticket, verifica que un incidente similar no esté ya en curso de tratamiento. Si se trata realmente de un incidente nuevo, crea un ticket de Jira estructurado: tabla afectada, síntoma observado, impacto estimado, causa probable identificada a partir de los commits recientes. A continuación notifica al equipo de datos en Slack con el enlace a ese ticket y el contexto ya reunido, para que la investigación no tenga que empezar de cero.

Cuando se detecta un cambio de estructura en una tabla monitorizada, el agente actualiza la documentación del esquema correspondiente en Notion, para que el diccionario de datos no quede obsoleto con las evoluciones. Una vez que el equipo cierra el incidente, redacta un informe estructurado a partir de los logs, los commits identificados y los intercambios del ticket, para conservar un registro útil ante el próximo incidente similar. Cada verificación, cada alerta, cada actualización de documentación queda registrada en la línea de tiempo de actividad del agente, lo que constituye la base de la observabilidad del agente: en cualquier momento, el equipo de datos puede reconstruir qué verificó, cuándo, y por qué activó una alerta.

Las integraciones utilizadas

El agente se apoya en las herramientas ya presentes en el stack de datos, en lugar de imponer una nueva plataforma de monitorización.

En Datadog, sigue los dashboards y los monitores de pipeline para detectar una desviación de latencia, tasa de fallos o volumen antes de que se vuelva visible aguas abajo. En GitHub, consulta el historial de commits y pull requests del repositorio que aloja el código de los pipelines o los modelos de transformación, para correlacionar un incidente con un cambio de código reciente. En Jira, verifica que no exista ya un ticket similar antes de crear uno nuevo, documentado con la tabla afectada, el síntoma y la causa probable. En Slack, avisa al equipo de datos en tiempo real con el contexto ya reunido. En Notion, mantiene actualizada la documentación de los esquemas y del diccionario de datos en cada cambio de estructura detectado.

Cada integración solo se activa para las acciones estrictamente necesarias: el agente solo puede leer un dashboard, consultar un repositorio, crear un ticket o modificar una página de documentación si un grant explícito se lo permite, acción por acción, con un alcance de solo lectura o de lectura y escritura.

Lo que sigue en manos humanas

El agente supervisa, correlaciona y documenta, nunca repara un pipeline por sí mismo. Es un límite deliberado de este caso de uso, no una simple precaución editorial: ninguna modificación de una base de datos o de un pipeline en producción se ejecuta jamás sin que un humano haya validado el cambio de antemano.

En concreto, un humano mantiene el control sobre cuatro puntos. Diagnostica la causa raíz exacta y corrige la lógica del pipeline o del modelo de transformación, a partir de la correlación que el agente ha puesto en evidencia, pero sin obligación de seguir esa pista si otra explicación resulta más convincente. Valida y ejecuta él mismo cualquier modificación de una base de datos o un pipeline en producción. Decide las prioridades de remediación cuando hay varios incidentes abiertos al mismo tiempo, según el impacto real en el negocio y no según una puntuación automática. Y revisa la documentación de esquema generada por el agente antes de considerarla como la referencia oficial del equipo.

Resultado medible

La ganancia principal no es sustituir el criterio de un data engineer, sino evitar que sea una parte interesada de negocio quien descubra el problema primero: recordemos que el 74 % de los encuestados de la encuesta de Monte Carlo 2023 ya constatan este escenario en su organización. Una supervisión continua de las tablas y los pipelines, con una alerta en cuanto una desviación sale de la línea base, actúa directamente sobre este punto de fricción.

Un ticket ya documentado en el momento en que el equipo de datos se entera de un incidente, con la tabla afectada y una causa probable ya identificada a partir de los commits recientes, también reduce parte del tiempo de resolución que llegaba a una media de 15 horas por incidente en la encuesta de 2023. Una documentación de esquema que se mantiene al día con los cambios evita, por último, las sorpresas desagradables cuando otra persona reutiliza una tabla que creía conocer.

El precio de la plataforma sigue la lógica de la propia función de datos, por agente activo y no por usuario: más detalle en la página de tarifas.