El esquema de una base de datos cambia. Una columna se renombra, otra cambia de tipo, una tercera desaparece. En el mundo tradicional, la aplicación que consume esos datos lanza una excepción de tipo, el pipeline se detiene y el equipo de datos corre a arreglarlo. Pero cuando el consumidor es un agente de inteligencia artificial —un LLM que razona sobre tablas para generar informes, tomar decisiones o ejecutar código— la historia es distinta: no hay error, no hay alerta, solo una inferencia silenciosamente equivocada.
Este fenómeno, bautizado como "Silent Schema Drift" (deriva de esquema silenciosa), se está convirtiendo en el talón de Aquiles de las arquitecturas basadas en agentes. Los contratos de datos clásicos, diseñados para validar tipos y estructuras en tiempo de compilación o despliegue, asumen un consumidor que falla ruidosamente ante una violación. Un modelo de lenguaje, en cambio, no valida esquemas: infiere significado a partir de nombres de columnas, valores de muestra y contexto semántico. Si la columna `revenue_usd` pasa a llamarse `revenue_eur` sin actualizar la documentación que el agente usa como contexto, el modelo seguirá razonando como si fueran dólares, contaminando todos los análisis downstream.
La gravedad del problema radica en su invisibilidad. Un pipeline de ETL roto se detecta en minutos; un agente que durante semanas ha estado calculando márgenes sobre la moneda errónea puede descubrirse solo cuando un informe ejecutivo llega al consejo. Además, los agentes suelen operar con cierta autonomía: consultan bases de datos, unen tablas, escriben SQL. Un cambio de esquema en una tabla auxiliar —quizás mantenida por otro equipo— puede alterar el plan de ejecución del agente sin que nadie lo note.
¿Por qué fallan los contratos de datos actuales? Porque están pensados para productores y consumidores deterministas. Herramientas como Great Expectations, dbt tests o Protobuf validan que los datos cumplan un esquema acordado. Pero el "consumidor" agente no firma ese contrato; lo interpreta. Peor aún: muchos agentes reciben el esquema como parte del prompt (vía RAG o function calling), y si esa descripción está desactualizada, el agente alucina estructura.
La solución exige un cambio de paradigma: de contratos estáticos a contratos vivos y observables. Tres pilares emergen como necesarios. Primero, versionado semántico de esquemas con notificación automática a los registros de agentes (agent registries). Segundo, pruebas de regresión semántica: suites que ejecutan prompts representativos contra versiones antiguas y nuevas del esquema, comparando salidas no solo sintácticas sino de negocio. Tercero, observabilidad de razonamiento: trazas que registren qué columnas y valores usó el agente para cada decisión, permitiendo auditoría post-mortem.
Empresas como Monte Carlo, Datafold y startups enfocadas en AI observability (ej. Arize, LangSmith) empiezan a integrar detección de drift semántico. Pero la responsabilidad final recae en los equipos de datos: deben tratar el esquema como una API pública versionada, con deprecation policies, changelogs y SLAs de notificación a consumidores —humanos o sintéticos.
El "Silent Schema Drift" no es solo un problema técnico; es un riesgo de gobernanza. Cuando un agente aprueba un préstamo, ajusta inventario o sugiere un tratamiento médico basándose en una columna fantasma, la organización entra en territorio regulatorio. La próxima generación de data contracts debe incluir cláusulas de "interpretabilidad garantizada": garantías de que el significado de cada campo permanece invariante o que su cambio dispara una revisión humana antes de que cualquier agente lo consuma.
Mientras tanto, la regla de oro para los ingenieros es simple: si cambias un esquema, asume que hay un agente leyéndolo. Y ese agente no te avisará cuando se equivoque.
