Introducción
, Los ejemplos de ingeniería de datos de IA giran en torno a una cosa: arreglar una tubería. Un ingeniero abre Claude Code, pega algunos registros y se realiza una solicitud de extracción.
La semántica es fundamental aquí. Porque cuando la gente dice "autocuración" lo que quieren decir es "autogestión". La clave del éxito en la IA no se define por la intervención y la interacción manuales, sino por la ausencia de ellas.
El sueño de los equipos de datos es un sistema en el que los canales de datos y los flujos de trabajo generalmente tengan éxito sin ninguna intervención humana. Sin embargo, existen barreras que se interponen entre nosotros y este futuro dorado.
Los agentes requieren contexto: la reparación de una canalización puede deberse a un error transitorio, un cambio de esquema ascendente o algo completamente incontrolable, como que un humano deje caer una mesa. La experiencia proporciona a los equipos de ingeniería los conocimientos necesarios para solucionarlos; Faltan agentes de contexto.
También será evidente un cambio de mentalidad. El antiguo patrón de “Nueva rama, fusión, repetición” es claramente lento y no es un agente. A menos que cambiemos nuestros patrones y permitamos que los agentes también fusionen relaciones públicas, parece que se requiere un gran cambio de mentalidad.
Por último, los datos no se “ramifican” bien. Proyectos como Lake FS prometieron popularizar “Git para datos”, pero no es así. Llevo años escribiendo sobre la clonación con copia cero, pero todavía no se utiliza mucho. Las distinciones entre código y datos no son obvias.
En este artículo, cubriremos 7 barreras entre las pilas de datos típicas de hoy y el nirvana de los canales de datos autocurativos/canales de datos autónomos.
¡Vamos a sumergirnos!
Barrera 1 | Recuerdo de contexto y fracaso
Las tuberías pueden fallar por una gran cantidad de razones, y poder repararlas es un requisito para un sistema de inteligencia artificial. Podemos clasificar las fallas en algunos tipos amplios:
Problemas de infraestructura Problemas de código Problemas de datos Problemas transitorios o de terceros
Generalmente, la forma de fijar datos requiere conocimiento del sistema. Por ejemplo, solo el Sr. Bob, que es la única persona que tiene acceso a la clave de acceso especial de Bob oculta en AWS Secrets Manager con un encabezado no estándar, puede acceder al clúster Kubernetes de Acme. La IA no conoce la clave de Bob, por lo que no podrá reparar el clúster.
De manera similar, la analista Sophie puede saber que lo correcto en Widgets Incorporated es simplemente pasar por alto el hecho de que las ventas se informan en múltiples monedas y manipular las cifras para que sean un 10% más altas que las de ayer. La IA no sabe cómo tratar los números.
Es posible que la IA tampoco sepa que, si no puede manejar la API interna, simplemente debe intentarlo nuevamente entre las 2:47 a. m. y las 3:12 a. m.
Estos son ejemplos ridículos, pero ilustran el hecho de que el conocimiento para corregir estos diferentes tipos de errores a menudo existe dentro de la cabeza de las personas. No basta con hablar de “contexto de metadatos”. Si bien es indudable que es imperativo recopilar linaje, registros, código, documentación y otro contexto escrito, la IA es bastante buena para resolverlo.
Como Data Folks, todos hemos estado en una situación en la que nosotros (o quizás alguien con quien hemos hablado) hemos pensado:
“¿Cómo diablos podría haberlo sabido?”
Al fin y al cabo, sólo los humanos saben dónde están enterrados los cuerpos.
Barrera 2 | Infraestructura elástica
Considerando específicamente cuestiones de tipo infraestructura, estoy acuñando el término infraestructura “elástica”. La “Infraestructura elástica” no solo escala, sino que también tiene una API para administrarla.
Una instancia EC2 no sería elástica, ya que no escala más allá de cierto punto.
Un clúster de Kubernetes en una máquina bloqueada no sería una nube elástica ya que no habría ninguna API que administrar.
La razón es que la IA requerirá acceso a la infraestructura para poder recuperarse de sus fallas.
Los proveedores de SaaS deberían aprovechar esta oportunidad. Los proveedores de SAAS necesariamente eliminan la carga de gestión de la infraestructura de los equipos de datos, pagando una tarifa. Este es un enfoque muy compatible con la IA, pero fracasa con respecto a la Barrera 6, a la que llegaremos.
Barrera 3 | Agentes Operativos y Datos de Calidad
Pete, de Finanzas, ha sobrescrito nuevamente la hoja de Google de planificación de operaciones y suministros para EE. UU. Las previsiones internacionales no se cumplen y su canalización está fallando. Hay 0 filas en us_forecast_dec_v1 y Forecasts_agg está obsoleto.
La IA te dice que los conectores están bien pero no había datos. No puede hacer nada.
¿Cuál es la solución aquí? Juguemos un cuestionario. Te daré algunas ideas y tú eliges la respuesta correcta.
Opción 1: dejar que la IA alucine los pronósticos Opción 2: dejar que la IA alucine los pronósticos en su almacén de datos y volver a ejecutar Google Sheet Pipeline más tarde Opción 3: ¡La IA le dice a Pete que suba los malditos pronósticos! Opción 4: hay una piscina cálida de humanos alquilados. Cuando este tipo de tubería falla, la IA le indica a la piscina caliente que moleste a Pete en persona hasta que él mismo arregle la tubería a mano.
¡Por supuesto que no existe una respuesta correcta! No todas las opciones son buenas, desde malas hasta ridículas. De hecho, la Opción 4 realmente no requiere IA en absoluto, sino algo llamado trabajo en equipo.
Los datos de calidad son, como siempre, lo más importante para un ingeniero de datos. Los equipos de datos deberían hacer esta pregunta cuando entrevisten más "¿Qué tan buenos son sus datos?". Es un determinante tan determinante de la calidad de vida que sorprende no recibir más mención.
Esto no quiere decir que los agentes operativos no tengan lugar; por ejemplo, un agente operativo podría corregir fácilmente los errores genuinos de dedos gordos. Por ejemplo, digamos que hay un nuevo acuerdo por 10 millones de dólares; quizás la cifra correcta sea 1 millón de dólares. Un agente con una clave API de Salesforce podría modificar fácilmente los datos y reiniciar una canalización.
Barrera 4 | Git para datos
El ejemplo anterior plantea una pregunta importante: "¿Deberían los agentes de IA editar la producción?"
Si ha experimentado múltiples entornos de Salesforce en su carrera, escucho su dolor. Pero la función está diseñada para evitar la situación anterior. Verá, tal vez el ejecutivo de cuentas haya conseguido un gran acuerdo y valga 10 millones de dólares. En ese caso, ¿seguramente es mucho mejor para el agente editar la instancia provisional de Salesforce en lugar de la de producción?
Lo anterior es una representación de alto nivel de cómo funcionaría el proceso que utiliza un enfoque similar a git-for-data. Hay una versión simple a continuación.
En ambos casos, la IA necesita una nueva rama para hacer su trabajo. Esa rama no necesita clones de copia de los datos, necesita un enfoque de git para datos y usted debe poder "cambiar" los datos de manera eficiente al final.
Sin esta estructura, me cuesta ver cómo se puede confiar en que la IA solucione las cosas de manera confiable, sin crear una pesadilla de gobernanza en la que tenga acceso de escritura a los datos de producción.
Con respecto a esto, empresas como Snowflake están bien posicionadas, ya que han admitido funciones como la clonación sin copia durante mucho tiempo. Motherduck también admite esta función. Sin embargo, el ganador más claro es el iceberg.
Iceberg admite viajes en el tiempo, reversión y git para datos. Empresas como Bauplan han construido motores informáticos alrededor de un iceberg, lo que crea una experiencia agradable y compatible con la IA. La IA debería ser un gran catalizador para el iceberg.
Barrera 5 | La penetración en la industria
La arquitectura autorreparable plantea un problema cuando hablamos de interoperabilidad.
Fivetran y dbt armaron un gran escándalo sobre la infraestructura de datos abiertos en 2025: no es lo mismo que la infraestructura de datos de código abierto, sino que se refiere a un enfoque que creo que sería mejor llamar Arquitectura de datos modular, mediante el cual diferentes funciones obtienen diferentes herramientas. A continuación se incluye un ejemplo.
No tiene sentido tener una arquitectura autorreparable si los componentes subyacentes no la soportan. La mayoría de los proveedores de servicios subyacentes proporcionan API relevantes que respaldan todos los principios de este documento, así como funciones de autorreparación para que los patrones funcionen.
Por ejemplo, supongamos que hay una falla silenciosa en un proveedor de ELT, por lo que el subesquema cambia; las columnas y los tipos siguen siendo los mismos, pero los valores cambian. Quizás ahora haya monedas reportadas en yenes, así como en dólares estadounidenses, pero las dos columnas moneda y valor_local permanecen.
Lo correcto puede ser modificar el trabajo ELT en su entorno de preparación, verificar el resto de la canalización a partir de esos datos de preparación, cambiar los datos que ahora son correctos y finalmente cambiar el trabajo de ELT que se realizó erróneamente.
Muchas herramientas ELT simplemente no proporcionan las API para obtener esta funcionalidad. Sin embargo, si estuviera haciendo esto con un script de Python, usted mismo se controlaría, no hay problema. Esto creará una presión masiva sobre los jugadores de ETL de hoy para que cambien sus estructuras o mueran.
Esta es una barrera enorme entre los sistemas modulares de hoy y la verdadera arquitectura autónoma con capacidad de autorreparación. Los únicos otros ejemplos serían que los sistemas mismos se autocuraran de forma independiente, como se esperaría que si todas las partes de un sistema se autocuran, también lo sea el todo.
Barrera 6 | Sandboxes de agentes y nuevos orquestadores
El lugar lógico para ejecutar agentes que arreglen cosas es dentro de una herramienta de orquestación.
Esto se debe a que la herramienta de orquestación tiene algunas cosas que el agente necesita.
La capacidad de ejecutar cualquier código y reproducir cualquier DAG con cualquier conjunto de parámetros arbitrarios Las conexiones a las diferentes partes del sistema que el agente pueda necesitar (recuerde, un orquestador orquesta, por lo que tiene acceso a las cosas) Alertas integradas, con monitoreo, recuperación e infraestructura escalable
Sin embargo, existe un enorme problema: la seguridad.
Empresas como Cloudflare han creado entornos sandbox para agentes. Esto se debe a que modelos como Fable (que fue prohibido recientemente) necesitan zonas de pruebas, ya que pueden explotar. Este es especialmente el caso cuando se está bajo el ataque de una inyección rápida.
Las herramientas de orquestación heredadas simplemente no están diseñadas para manejar agentes de esta manera. Los riesgos de seguridad son inmensos. ¡Sin mencionar que las cargas de trabajo de IA podrían pisar los dedos de las de datos!
Está bastante claro que los agentes necesitarán acceso a los marcos de orquestación. Ya sea que Open AI y Anthropic proporcionen un orquestador, orquestadores de la nueva era con entornos sandbox de agentes o alguna forma de interoperabilidad entre los dos, algo tiene que ceder aquí. Porque la seguridad.
Barrera 7 | Estándares para servidores proxy y definición de agentes
Un enfoque de seguridad es configurar un servicio de proxy para los agentes. En lugar de instalar los secretos en la zona de pruebas, el agente tiene acceso a una cantidad determinada de herramientas/MCP.
El servicio proxy es entonces lo único que tiene acceso a sistemas externos. Esto significa que incluso si el agente se convierte en víctima de un ataque de inyección rápida, todo lo que podría hacer está limitado por los puntos finales de los MCP a los que tiene acceso.
El aspecto que debe tener este servicio proxy no es obvio. MCP es grande. Cloudflare lanzó el modo Código. Si necesita acceder a varios puntos finales diferentes, la forma en que se deben configurar los servidores MCP no es sencilla ni obvia.
Deben prevalecer los estándares abiertos: cualquier agente que busque interactuar de forma segura con múltiples sistemas se beneficiaría, desde una perspectiva de seguridad, de la interacción con un servicio proxy. Estos existen hoy en día, pero en herramientas SaaS privadas como Foundry.
También sería necesario que surgieran marcos para el diseño de agentes. En el ejemplo anterior, un único agente que requiera integración con cientos de sistemas puede no ser factible, ya que el contexto necesario para acceder a cientos de MCP puede ser demasiado grande.
Poniéndolo todo junto | Un único panel de cristal para la IA
En conjunto, lograr lo anterior permitiría a los equipos de datos construir un panel único para la IA.
Contexto: proporciona a los agentes la información para resolver cualquier problema Infraestructura elástica: proporciona la base para arreglar los canales Datos de calidad: erradica el lado humano de las entradas de datos Git para datos: crea confiabilidad y confianza en la IA Adopción masiva: previene el colapso de la industria Sandboxes de agentes y nuevos orquestadores: elimina la arquitectura heredada Servidores proxy: hacen todo lo posible para garantizar la seguridad
Este panel de cristal único permitiría a los agentes de IA operar de forma segura. Ejecutarían cuando lo necesitaran y también tendrían el contexto para lograr lo que necesitaban.
Las primitivas de datos centrales como git para datos, la infraestructura elástica y el soporte en todo el ecosistema harían que esto pasara de ser una idea teórica a una realidad práctica.
Los equipos de datos que busquen implementar una arquitectura autónoma impondrán una presión significativa a los proveedores existentes para respaldar la interoperabilidad.
Esto exacerbará la consolidación, a medida que empresas tradicionales como Salesforce, SAP y ServiceNow implementen sus propios productos agentes y estudios de datos, capaces de controlar de extremo a extremo sin proporcionar interoperabilidad.