Agentes de IA nativos de datos: por qué los agentes deben moverse a tus datos

La mayoría de los pilotos de IA empresariales superan el mismo listón bajo: conectar un LLM a sus datos, integrar una base de datos vectorial y hacer una demostración ante el equipo directivo. La parte difícil viene después. El equipo de seguridad señala las brechas de gobernanza. La latencia en los agentes de varios pasos arruina la experiencia del usuario. La factura del proveedor de modelos no para de subir. Estos problemas suelen tener su origen en una sola decisión: extraer los datos de los sistemas gobernados para llevarlos a un entorno de IA que nunca se diseñó para aplicar sus políticas.

Este artículo propone una dirección arquitectónica diferente: llevar los modelos y los agentes a los datos, y no al revés. En lugar de crear una infraestructura de IA paralela y conectarla de vuelta a su lakehouse, los agentes se tratan como cargas de trabajo nativas que se ejecutan dentro de su plataforma de datos, bajo los mismos controles de gobernanza, seguridad y observabilidad en los que ya confía para sus datos.

El lakehouse le ofreció un único lugar para gobernar sus datos. La siguiente pregunta es si sus agentes residen dentro o fuera de ese límite. Existen dos paradigmas emergentes.

Agentes externos

Los agentes y los LLM se ejecutan en un entorno de IA independiente. Los datos se exportan o se consultan a través de la red en bases de datos vectoriales externas, LLM de tipo SaaS o capas de servicio personalizadas. La gobernanza, la seguridad y la observabilidad se vuelven a implementar de forma paralela para la IA.

Agentes nativos de datos

Los agentes, los modelos, las herramientas, la recuperación y la memoria de los agentes se ejecutan dentro de la misma plataforma que los propios datos, bajo una capa unificada de gobernanza y seguridad. La IA se convierte en otra carga de trabajo en su pila de datos existente.

El coste oculto de los agentes externos

Los datos tienen gravedad. El cómputo es fácil de trasladar; los datos no, especialmente a medida que los volúmenes crecen y las modalidades se multiplican. Extraerlos introduce una serie de inconvenientes conocidos:

• La gobernanza se debilita. Volver a implementar el control de acceso, el linaje y la residencia de los datos en cada integración deja brechas que las auditorías acaban detectando.
• La latencia se acumula. Cada salto a un almacén de vectores externo, a un LLM y de vuelta se acumula en los agentes multiherramienta.
• Los costes se fragmentan. La salida de datos, el almacenamiento duplicado y el precio por token de los distintos proveedores afectan al presupuesto desde tres frentes.
• El ciclo de vida se convierte en una coordinación de proveedores. Los esquemas, índices y modelos se desvían entre sistemas que no comparten un pipeline de implementación.
• La observabilidad se fragmenta. Realizar el seguimiento de una solicitud de extremo a extremo implica unificar los registros de tres o cuatro herramientas.
• El contexto de negocio se queda atrás. Las definiciones de métricas, el glosario empresarial y las agrupaciones de dominios residen en su capa de gobernanza; un agente externo tiene que reconstruirlos a partir de los nombres de las columnas o adivinarlos.

Por qué la gobernanza a posteriori falla con los agentes

De todos estos inconvenientes, la gobernanza merece especial atención porque es el único que no se puede solucionar a posteriori. La mayoría de los enfoques de gobernanza de IA la tratan como un filtro que se aplica después de que el agente ya haya accedido a los datos; por ejemplo, ocultando campos confidenciales de la respuesta, bloqueando ciertos temas en la capa de salida y auditando los registros a posteriori. Esto funciona para demostraciones sencillas de Q&A, pero se desmorona en el momento en que los agentes empiezan a procesar datos.

Pensemos en un agente que calcula un resumen financiero a partir de filas sujetas a seguridad a nivel de fila. La propia agregación (la suma, el promedio, la tendencia) es un valor derivado que depende de qué filas se incluyan. Si la gobernanza no se aplica antes de que se ejecute la consulta, el resultado ya codifica datos en los que el usuario no debería haber influido. Ninguna ocultación posterior puede deshacer ese cálculo. La decisión sobre la política debía tomarse en el momento de la planificación de la consulta, no al renderizar la respuesta.

Esta es la brecha fundamental de la gobernanza perimetral o a posteriori: asume que los datos se pueden censurar de forma segura después de que lleguen al agente. En la práctica, una vez que se ha producido una agregación o transformación, la intención de gobernanza ya se ha perdido. Los controles retroactivos son fundamentalmente incompletos.

Hay un segundo coste si esto se hace mal, y se refleja en la factura. El problema no es solo lo que el agente tiene permitido tocar, aunque eso es parte de ello. Cuando la gobernanza se resuelve a posteriori en lugar de en el origen, el agente acaba haciendo la conciliación por sí mismo: recorriendo registros de auditoría, uniendo fragmentos de sistemas externos, extrayendo el mismo registro de varios lugares para determinar si puede usarlo y volviendo a razonar sobre cada resultado parcial. Nada de eso es su tarea real. Es el agente compensando una respuesta gobernada que nunca se le proporcionó de antemano. Las salidas bloqueadas u ocultadas solo alimentan la espiral, ya que el agente las interpreta como fallos e intenta de nuevo. Las sesiones se alargan, cada salto carga más contexto en el modelo y una sola solicitud se convierte silenciosamente en miles de tokens facturados. Ese es el bucle de consumo desmedido de tokens, y la gobernanza a posteriori es lo que lo pone en marcha.

Los agentes nativos de datos abordan estos desafíos integrando la aplicación de políticas directamente en la planificación y el procesamiento de las consultas. Cada resultado intermedio refleja las mismas restricciones de gobernanza. La gobernanza debe evaluarse antes y durante la ejecución, algo que no puede permitirse aplicar como una ocurrencia tardía una vez finalizado el procesamiento. Las guardrails personalizadas en Unity AI Gateway son la forma concreta de esto: políticas componibles y deterministas que la pasarela aplica en cada solicitud y respuesta, no filtros que se le pide al modelo que obedezca a posteriori. Decidir la política en el momento de la planificación, sobre datos que ya residen en un único lugar gobernado, también significa que el agente obtiene una respuesta limpia en una sola pasada en lugar de tener que explorar diversos sistemas para recopilarla o justificarla.

El estado y la memoria del agente necesitan gobernanza

Hasta ahora, nos hemos centrado en cómo los agentes leen los datos. Pero los agentes en producción también escriben: historial de conversaciones, progreso de tareas, preferencias del usuario, resultados almacenados en caché y salidas de herramientas para auditorías posteriores. A medida que los agentes asumen más funciones, la capa de estado importa tanto como la de datos. Si la deja fuera del límite de gobernanza, cualquier promesa de auditabilidad de extremo a extremo tendrá una brecha.

El estado es el bloc de notas a corto plazo del agente: la conversación activa, la tarea en curso, la caché que acaba de llenar. La memoria es lo que sobrevive a la sesión: con qué clientes ha tratado un agente, qué prefiere un usuario, qué salidas anteriores vale la pena reutilizar. Ambos necesitan almacenamiento transaccional, y ambos pierden gobernanza en el momento en que salen de la plataforma. Un recuerdo como "el usuario X es un cliente de la EU de alto valor" es en sí mismo un dato confidencial, sujeto a las mismas reglas de acceso y residencia que el registro que resume. Y es una carga de trabajo transaccional: las tablas Delta están diseñadas para grandes análisis de datos, pero el estado del agente necesita lecturas y escrituras rápidas por fila, búsquedas por clave y actualizaciones atómicas.

La solución habitual es un Postgres o Redis externo. Pero eso le devuelve al problema contra el que argumenta este artículo: el estado del agente sale del perímetro gobernado hacia un sistema que su capa de gobernanza no puede ver, con su propia seguridad y ciclo de vida que gestionar. Habrá creado un agente nativo de datos con una dependencia no gobernada.

Y el problema crece en el momento en que un agente se convierte en muchos. Un enjambre que trabaja para lograr un resultado mayor (un planificador que delega en especialistas, un supervisor que concilia sus resultados) necesita memoria compartida, y mantener la alineación en ella es donde estos sistemas fallan. Cuando cada agente mantiene un estado privado y transmite el contexto de punto a punto, no hay una única fuente de verdad. Los agentes divergen, las escrituras colisionan y cada transferencia es otro canal no gobernado que se multiplica a medida que el enjambre crece. Intercambiar memoria resulta ser la parte difícil.

Lakebase cierra estas brechas. Es un almacenamiento de PostgreSQL totalmente gestionado dentro de la plataforma Databricks, bajo el mismo plano de gobernanza que todo lo demás. El estado del agente se convierte en un activo gobernado: hereda los controles de acceso de la plataforma, reside junto a los datos y herramientas del agente, y no requiere un equipo de infraestructura independiente. Y dado que cada agente lee y escribe en esa misma capa transaccional, también funciona como la única fuente de verdad del enjambre. El estado se mantiene consistente, las actualizaciones atómicas evitan que dos agentes corrompan la misma tarea, una política sobre la vista de un agente se traslada a lo que escriba para el siguiente, y cualquier memoria se puede rastrear a través del enjambre: qué agente la escribió, cuál la leyó y cómo una conclusión profunda llega a su origen.

El argumento a favor de los agentes nativos de datos

El argumento de la gobernanza es el más sólido, pero las ventajas van más allá. Cuando los agentes se ejecutan dentro de la pila de datos, las ventajas se acumulan en cada dimensión operativa: seguridad, calidad, observabilidad, implementación, latencia y coste. Las herramientas y las dependencias de datos se configuran y registran junto con el modelo, por lo que todo el sistema está versionado, es auditable y reproducible de forma predeterminada.

La siguiente comparación resume cómo difieren estos dos paradigmas en las dimensiones que más importan para los sistemas en producción:

Cómo se ven realmente los agentes nativos de datos en Databricks

La Data Intelligence Platform pone esto en práctica. En lugar de construir una "pila de AI" separada y conectarla a sus datos, usted construye agentes de AI dentro de la propia pila de datos. Un agente nativo de datos en Databricks es aquel que:

• Dirige todo el tráfico de modelos y agentes a través de Unity AI Gateway, donde cada solicitud se verifica antes de la ejecución y cada respuesta se inspecciona después, con políticas deterministas de ALLOW / DENY / ASK que reemplazan el filtrado de mejor esfuerzo a posteriori. El control de acceso, la limitación de velocidad, el registro de carga útil (payload) y el seguimiento de costos residen en el mismo plano de control, incluidas las llamadas a proveedores externos de LLM y agentes de codificación.
• Trata cada primitiva de AI (modelos, agentes, MCPs, habilidades y las herramientas que llaman) como un activo de Unity Catalog junto con tablas y funciones, de modo que la identidad, el linaje y los controles de acceso se aplican de manera uniforme en toda la superficie de AI.
• Captura trazas completas de solicitudes a través de MLflow 3: cada llamada de LLM, invocación de herramientas, puntuaciones, evaluaciones (evals), documentos recuperados y bucles de monitoreo de extremo a extremo se vuelven auditables para el cumplimiento y observables para la depuración.
• Ejecuta la inferencia dentro del perímetro de seguridad de Databricks en Model Serving, sin movimiento de datos no gobernados hacia pilas de AI de terceros.
• Recupera el contexto de índices respaldados por Delta que respetan las ACLs de Unity Catalog y rastrean automáticamente el linaje, con la tecnología de AI Search.
• Recuerda a través de las sesiones mediante el estado y la memoria respaldados por Lakebase: el contexto de conversación a corto plazo, el progreso de tareas de múltiples pasos, las preferencias del usuario a largo plazo y el recuerdo episódico de llamadas a herramientas anteriores coexisten junto con los datos sobre los que razona el agente.
• Fundamenta el razonamiento en un contexto de negocio a través de Unity Catalog Semantics (métricas, glosario de negocio, dominios) y Genie Ontology, un gráfico de conocimiento mantenido automáticamente y extraído de las tablas, consultas, tableros y aplicaciones que el equipo ya utiliza.
• Delega el razonamiento especializado en otros agentes, incluido Genie para preguntas de datos estructurados, con una coordinación multidominio y de múltiples pasos dentro de los límites de la plataforma.
• Extiende el mismo gobierno a los agentes de codificación a través de Omnigent, un meta-arnés que dirige Claude Code, Codex y Cursor a través de Unity AI Gateway con sesiones compartidas y un registro de auditoría común.

Por dónde empezar

Algunas empresas ya están construyendo de esta manera. Sus agentes se ejecutan dentro del mismo límite que sus datos, con políticas de Unity Catalog que cubren ambos, el estado en Lakebase y el tráfico a través de Unity AI Gateway. Ninguna de ellas llegó allí con un solo proyecto de cambio de plataforma. Cerraron la brecha entre el lakehouse y la pila de AI un piloto a la vez, y luego dejaron de abrir otros nuevos.

Para los equipos que están al inicio del camino, el trabajo no es drástico. La mayoría de las piezas ya existen en el lado de la plataforma: Model Serving, Unity Catalog, Lakebase, MLflow. Lo que falta es la decisión de tratarlos como el hogar del agente en lugar de como fuentes de datos para una pila paralela. Esa decisión suele ser la parte más difícil.

El lugar más útil para comenzar es un inventario de lo que ya se está ejecutando fuera del perímetro. De ahí es de donde provendrá el próximo incidente de gobierno, y ese es el trabajo que hace posible todo lo demás.

Si desea profundizar en cómo operacionalizar agentes nativos de datos con los mecanismos de protección y los patrones adecuados, estos recursos son un excelente siguiente paso:

• Para traducir la estrategia en controles concretos, lea Un marco práctico de gobierno de AI para empresas, que muestra cómo convertir objetivos de alto nivel en roles, políticas y flujos de trabajo en la Databricks Data Intelligence Platform.
• Para obtener una visión más amplia de la AI responsable en la práctica, Mejores prácticas de gobierno de AI: cómo crear programas de AI responsables y eficaces recorre los principios y modelos operativos que puede adoptar en todos los equipos.

Para explorar las capacidades de la plataforma analizadas en esta publicación:

• Unity AI Gateway: novedades en el Data + AI Summit 2026 — un único plano de control para todo el tráfico de modelos y agentes, con Custom Guardrails deterministas de ALLOW/DENY/ASK.
• Agent Bricks: Data + AI Summit 2026 — agentes autooptimizados entregados como cargas de trabajo gobernadas de primer nivel en la plataforma.
• Omnigent: un meta-arnés para combinar, controlar y compartir sus agentes — dirige los agentes de codificación (Claude Code, Codex, Cursor) a través de Unity AI Gateway con un registro de auditoría compartido.
• Presentación de Genie One, Genie Agents y Genie Ontology — el gráfico de conocimiento mantenido automáticamente que fundamenta a los agentes en su contexto de negocio.
• Escalado de memoria para agentes de AI — cómo escalan el estado y la memoria del agente en Lakebase, gobernados por Unity Catalog dentro de la plataforma.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original