Por qué los datos de R&D pertenecen al Lakehouse y por qué los agentes los necesitan allí

La configuración

En cellcentric, una empresa conjunta de Daimler Truck y Volvo Group, desarrollamos y fabricamos sistemas de pilas de combustible de hidrógeno para aplicaciones de carga pesada. Nuestro trabajo se centra en gran medida en el R&D, la ingeniería y los datos. Las preguntas que se hacen nuestros equipos rara vez caben en un solo sistema de origen. Abarcan la jerarquía de productos, el historial de fabricación, los reprocesamientos, las pruebas de laboratorio, la telemetría de ensayos y el conocimiento del dominio.

Ese es el desafío central para la AI industrial en R&D. Un agente solo es útil si puede razonar sobre el mismo contexto gobernado que un ingeniero necesita para confiar en una respuesta: de dónde provienen los datos, qué significan, qué tan completos están, qué advertencias importan y si el usuario tiene permiso para verlos. Convertir eso en un contexto listo para la AI comienza con la ingeniería de datos antes de la selección del modelo.

Por eso hemos pasado los últimos cuatro años construyendo nuestra base de datos en Azure y Databricks. Unity Catalog formó parte de la arquitectura desde el principio. Lakehouse Federation llevó las fuentes SQL locales al patrón de lakehouse. Delta Sharing nos ayudó a intercambiar datos a través de diferentes fronteras. Databricks Asset Bundles nos dio una ruta de producción para pipelines y productos de datos. El resultado es el Data Hub: nuestra capa de contexto gobernada para datos y AI, con una interfaz de usuario para empleados y un servidor MCP para agentes.

El Data Hub comenzó como una plataforma de productos de datos. En retrospectiva, esa base es exactamente la razón por la que funciona como una plataforma de AI.

El Fuel Cell Passport

La base es más fácil de explicar a través de un producto de datos: el Fuel Cell Passport. Reúne cinco sistemas de origen empresariales, incluidos SAP S/4HANA, dos sistemas MES para fabricación y reprocesamiento, una base de datos de laboratorio y una plataforma de telemetría de IoT. Modela siete niveles de jerarquía, desde el sistema hasta el lote de materia prima, se actualiza diariamente y utiliza un modelo temporal basado en estados para que los equipos puedan responder tanto a preguntas de configuración en un momento dado como a preguntas sobre el historial completo de reprocesamiento. Los controles diarios de calidad de los datos supervisan si el producto está lo suficientemente completo como para respaldar las investigaciones de ingeniería, calidad y fabricación. El nombre refleja los conceptos de trazabilidad y ciclo de vida de un pasaporte de producto, pero el Fuel Cell Passport es un producto de datos de ingeniería interno, no un artefacto de cumplimiento normativo como el Pasaporte Digital de Productos (DPP) de la EU, aunque la misma base de trazabilidad podría respaldar uno.

Eso suena como una historia de éxito convencional de lakehouse: integrar las fuentes, modelar el dominio, gobernar el acceso, hacer que los datos sean reutilizables. Para la AI, el punto estructural es el contexto adjunto: un producto gobernado en torno a los datos modelados.

El contexto como métrica de calidad

Unity Catalog nos brinda la estructura gobernada: tablas, columnas, propiedad, linaje, clasificaciones y permisos. El Data Hub añade la capa de producto a su alrededor. Un producto de datos combina propiedad, estado del ciclo de vida, asignación de dominio, activos gobernados vinculados y entradas de contexto que explican para qué sirve el producto y cómo debe utilizarse.

Esa distinción es importante para la AI. Los agentes necesitan más que metadatos de esquema y necesitan más que un documento. Deben comprender qué preguntas comerciales admite un producto de datos, cómo se relacionan las tablas importantes, qué advertencias importan y qué activos circundantes deben usarse con él. Conservamos ese contexto más enriquecido en la capa del producto de datos, incluidas extensas entradas de catálogo en markdown que se escriben durante el proceso de desarrollo mientras el contexto del proyecto aún está fresco.

Esto cambió nuestra forma de pensar sobre la calidad de los datos. La integridad y la frescura siguen importando, pero ya no son suficientes. Para los datos listos para la AI, la cobertura del contexto se ha convertido en una métrica de calidad de primer nivel.

En nuestro mercado, cada producto de datos lleva una insignia de cobertura de contexto. Muestra si las descripciones de las tablas están presentes y cuánta documentación a nivel de columna existe en las tablas adjuntas del producto. La insignia hizo que la métrica fuera visible y accionable. La cobertura aumentó porque los ingenieros podían ver la brecha directamente en la interfaz del producto donde se consumirían los datos.

La métrica no pretende afirmar que se hayan resuelto todas las ambigüedades semánticas. Es un indicador práctico que hace visible la falta de contexto con la suficiente antelación como para solucionarla. Históricamente, la cobertura de contexto mejoró porque la insignia convirtió la documentación de una tarea de limpieza posterior al desarrollo en algo que los ingenieros podían ver, medir y mejorar como parte de la entrega.

Hoy en día, tenemos 27 productos de datos publicados, todos con una rica documentación en markdown. Los productos publicados tienen un promedio del 90% de cobertura de comentarios de columnas, y la mayoría de los comentarios de columnas son asistidos por AI durante el trabajo de ingeniería de datos y revisados por el ingeniero antes de la fusión. La entrada del catálogo añade otra capa de contexto: un resumen detallado en markdown del flujo de trabajo de desarrollo, las decisiones de dominio, las relaciones entre tablas, las advertencias y las formas previstas de consumir el producto.

El cambio importante es que la documentación se convierte en parte del flujo de trabajo de ingeniería y luego está disponible como contexto de producto estructurado para el próximo humano o agente que necesite razonar sobre los datos.

Una UI para humanos, un MCP para agentes

El Data Hub es la capa que hace que ese sustrato sea consumible. Para los usuarios humanos, es un mercado y un espacio de trabajo. Los empleados pueden descubrir productos de datos, ver a los propietarios y el estado del ciclo de vida, abrir paneles y aplicaciones vinculados, consultar datos gobernados por Unity Catalog y utilizar una interfaz de chat para la exploración en lenguaje natural. Para los clientes de AI, el mismo contexto se expone a través de MCP. Cualquier agente o asistente de programación compatible con MCP puede acceder a los mismos metadatos de Unity Catalog y al contexto del producto de datos que utiliza el Data Hub.

El modelo de gobernanza

La arquitectura está construida deliberadamente en torno a un único modelo operativo. La identidad fluye a través del sistema. El acceso a los datos sigue estando gobernado. Las llamadas a modelos y herramientas son observables. Las trazas y las evaluaciones alimentan la mejora.

Esto solo funciona porque la gobernanza se diseñó en la plataforma desde el principio. La propiedad de producción, el despliegue y el consumo son aspectos independientes. Los ingenieros cambian los pipelines y las definiciones de productos a través de código revisado y rutas de despliegue gobernadas. Los consumidores, incluidos los agentes, no reciben identidades de escritura en producción. Acceden a los datos a través del Data Hub, paneles de control, Genie, herramientas SQL o MCP utilizando la identidad del usuario autenticado, y Unity Catalog toma la decisión final de autorización.

Esa distinción es lo que hace que el acceso de los agentes sea gobernable. Un agente puede razonar sobre el mismo contexto de producto que ve un usuario y puede llamar a herramientas en nombre del usuario, pero no puede convertirse en un escritor de producción ni eludir Unity Catalog con una credencial de backend compartida. Si el usuario no tiene acceso a una tabla, columna enmascarada o vista gobernada, el agente recibe el mismo límite. Ese modelo operativo nos permite autorizar a los agentes a acceder a los datos sin crear una segunda ruta más laxa alrededor de la plataforma.

La identidad comienza en Azure AD y fluye a través del Data Hub hacia Databricks utilizando el intercambio de tokens OAuth 2.0, el patrón de transferencia de tokens en nombre de (on-behalf-of) que Databricks describe en su arquitectura de gobernanza de agentes. Un usuario que consulta una tabla a través de la UI, un agente que llama a una herramienta SQL y un espacio de trabajo de Genie invocado como una llamada de herramienta gobernada operan dentro del mismo límite de permisos. Si el usuario no puede acceder a los datos subyacentes, tampoco puede hacerlo el agente que actúa en su nombre. Ese es el modelo de acceso que permite que el Data Hub sea útil sin convertirse en un sistema de gobernanza paralelo.

Por el lado de la AI, ejecutamos agentes personalizados en Databricks Model Serving, usamos Claude a través de Foundation Model APIs e invocamos espacios de trabajo de Genie como herramientas gobernadas donde corresponde. La arquitectura MCP es híbrida por diseño: el MCP gestionado por Databricks ofrece acceso gobernado a las capacidades de Databricks, como las llamadas a herramientas de Genie, y nuestro propio MCP ofrece la capa de contexto más enriquecida (metadatos de Unity Catalog, objetos de productos de datos y markdown de catálogo), además de las herramientas específicas del negocio que los agentes llaman sobre ella. Agentes necesitan ambas cosas.

Observabilidad y evaluación

La observabilidad es el punto donde la arquitectura se vuelve operativa. Unity AI Gateway ahora dirige el tráfico de modelos fundacionales en nuestro entorno. Con un pequeño cambio en el cliente del modelo, las llamadas al modelo de Data Hub fluyen a través de una única capa de gobernanza y observabilidad con el seguimiento de uso y las tablas de inferencia habilitadas. Debido a que las solicitudes y respuestas se registran en las tablas Delta de Unity Catalog, se pueden analizar con los mismos patrones SQL que ya utilizamos para los datos comerciales.

El rastreo de MLflow nos brinda el siguiente nivel de visibilidad. Estandarizamos los rastreos en nuestros adaptadores de agentes para que cada interacción pueda inspeccionarse como una ruta de ejecución estructurada: llamadas a modelos, llamadas a herramientas, pasos intermedios y respuestas finales. Sobre esos rastreos, ejecutamos un marco de evaluación continua con evaluadores de corrección determinista y de base SQL, evaluadores de costos conscientes de la caché y evaluadores basados en jueces LLM con alineación de expertos en el dominio. El propósito va más allá de probar los cambios en los agentes. La propia capa de contexto necesita evaluación: el markdown puede desviarse de los pipelines y las definiciones de tablas, los prompts del sistema evolucionan, los contratos de herramientas cambian y las suposiciones del dominio envejecen. Los rastreos y las evaluaciones nos permiten probar juntos el agente, las herramientas y el contexto en el que se basa antes de que cualquiera de ellos afecte al comportamiento en producción.

Por primera vez, la empresa cuenta con un punto de entrada único y gobernado para que los empleados descubran qué productos de datos existen e interactúen con ellos en lenguaje natural, sujetos a los mismos controles de acceso que los datos subyacentes.

El mismo patrón, dentro del bucle de desarrollo

El mismo patrón también cambió nuestra forma de construir.

Nuestro flujo de trabajo de ingeniería ahora incluye agentes dentro del bucle de desarrollo. La herramienta de codificación exacta es menos importante que el patrón: un ingeniero trabaja en un entorno de desarrollo asistido por IA conectado a las capacidades de Databricks y a nuestro propio MCP de capa de contexto. Cuando el ingeniero trabaja en un producto de datos, el agente puede inspeccionar los metadatos relevantes de Unity Catalog, leer la documentación existente del producto, comprender el contexto del proyecto cercano y ayudar a estructurar pipelines, pruebas, descripciones de tablas y entradas de catálogo en markdown. El ingeniero sigue siendo responsable de la revisión y la fusión, pero el agente está presente cuando el contexto es más completo.

Ese momento es clave. La documentación escrita a posteriori a menudo está incompleta porque el contexto del proyecto ya ha cambiado. La documentación escrita durante el desarrollo captura el razonamiento, las definiciones y las advertencias que hacen que los datos sean útiles más adelante y, una vez revisada y confirmada, se convierte en el contexto para el siguiente flujo de trabajo.

Para muchos de nuestros flujos de trabajo de R&D y desarrollo de procesos, lo que antes requería semanas de integración de datos entre sistemas, definición de KPI y estructuración de pipelines, ahora se entrega en días. La mejora se manifiesta menos como una cifra única de automatización y más como un tiempo más corto desde la solicitud de investigación hasta el producto de datos utilizable: menos traspasos manuales entre expertos del dominio e ingenieros de datos, menos integraciones repetidas de sistemas de origen, un acuerdo más rápido sobre las definiciones de KPI y una revisión más temprana de las advertencias mientras el contexto aún está fresco. Algunas categorías, especialmente las investigaciones complejas de múltiples fuentes que exigen una revisión cuidadosa del dominio, siguen requiriendo un trabajo sustancial, solo que sustancialmente más rápido. El beneficio duradero es acumulativo: cada producto añade contexto empresarial revisado a la plataforma, por lo que la siguiente investigación comienza con una mayor parte del dominio ya explicada.

Databricks ahora está convirtiendo en productos partes de este patrón. La CLI de codificación de Unity AI Gateway, ucode, dirige las herramientas de codificación a través de AI Gateway y conecta los servidores MCP al flujo de trabajo del desarrollador. Genie Code lleva la codificación agéntica y el trabajo con datos directamente a las interfaces de Databricks.

El siguiente paso

Para nosotros, la próxima ola consiste en hacer que los agentes sean conscientes del contexto operativo que rodea a los datos, así como de las propias tablas. En una investigación de calidad o de fabricación, un agente debería ser capaz de recuperar una tendencia, inspeccionar los controles de calidad de datos asociados al producto e incorporar los registros de alarmas de máquinas relacionados de la misma ventana de tiempo. La respuesta puede entonces incluir la advertencia que un ingeniero esperaría: la tendencia apunta en esta dirección, pero este segmento requiere precaución porque se alertó sobre la integridad y el contexto operativo era anormal.

La misma idea se aplica al trabajo recurrente. Hoy en día, el conocimiento de los procesos está disperso en runbooks, páginas wiki, prompts locales, scripts, convenciones de equipo y hábitos no documentados. Un Skills Marketplace da a ese conocimiento el mismo tratamiento de plataforma que a los productos de datos: propiedad, revisión, control de versiones, estado del ciclo de vida y un lugar central donde los agentes encuentran la forma aprobada de trabajar. En este contexto, una habilidad empaqueta las instrucciones, las herramientas aprobadas, las plantillas, las salvaguardas y los controles de evaluación que le indican a un agente cómo debe realizarse una tarea recurrente en nuestro entorno. Concretamente, viviría en el marketplace junto a los productos de datos que toca, tendría un control de versiones y se revisaría como el código, y se invocaría por su nombre para que el agente siga la misma ruta aprobada cada vez. Una habilidad podría estructurar un Databricks Asset Bundle específico del dominio en un repositorio remoto, o guiar a un ingeniero para registrar un dispositivo IoT y convertir registros de máquina desordenados en un pipeline bronce.

Esa es la dirección más amplia para el Data Hub: tomar la misma lección de la base de lakehouse, gobernar primero el contexto y aplicarlo tanto a los datos que consultan los agentes como al trabajo que ayudan a realizar.

La clave

Por eso los datos de R&D pertenecen al lakehouse. La IA industrial necesita un contexto gobernado: los datos, el significado, los permisos, los rastreos y el bucle de retroalimentación en una sola arquitectura.

Para cellcentric, hacer que la IA industrial sea práctica significa dar a los agentes ese contexto sobre una base de lakehouse probada. Unity Catalog, los productos de datos, la identidad, la observabilidad y los flujos de trabajo de los agentes colaboran para permitir que los humanos y los agentes analicen los datos de R&D de forma segura. Eso es más que una buena práctica para nosotros. Es la forma en que estamos diseñando la próxima generación de ingeniería impulsada por datos.

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