Por que os dados de R&D pertencem ao Lakehouse - e por que os agentes precisam deles lá

O setup

Na cellcentric, uma joint venture do Daimler Truck e do Volvo Group, desenvolvemos e construímos sistemas de células de combustível de hidrogênio para aplicações pesadas. Nosso trabalho é altamente focado em R&D, engenharia e dados. As perguntas que nossas equipes fazem raramente se limitam a um único sistema de origem. Elas cruzam hierarquia de produtos, histórico de fabricação, retrabalho, evidências laboratoriais, telemetria de testes e conhecimento de domínio.

Esse é o desafio central para a AI industrial em R&D. Um agente só é útil se puder raciocinar sobre o mesmo contexto governado que um engenheiro precisa para confiar em uma resposta: de onde os dados vieram, o que significam, quão completos estão, quais ressalvas importam e se o usuário tem permissão para visualizá-los. Transformar isso em um contexto pronto para AI começa com a engenharia de dados, antes mesmo da seleção do modelo.

É por isso que passamos os últimos quatro anos construindo nossa base de dados no Azure e na Databricks. O Unity Catalog fez parte da arquitetura desde o início. O Lakehouse Federation trouxe fontes SQL locais para o padrão lakehouse. O Delta Sharing nos ajudou a compartilhar dados além das fronteiras. Databricks Asset Bundles nos deu um caminho de produção para pipelines e produtos de dados. O resultado é o Data Hub: nossa camada de contexto governada para dados e AI, com uma interface de usuário para funcionários e um servidor MCP para agentes.

O Data Hub começou como uma plataforma de produtos de dados. Olhando para trás, essa base é exatamente o motivo pelo qual ele funciona como uma plataforma de AI.

O Fuel Cell Passport

A base é mais fácil de explicar por meio de um produto de dados: o Fuel Cell Passport. Ele reúne cinco sistemas de origem corporativos, incluindo o SAP S/4HANA, dois sistemas MES para fabricação e retrabalho, um banco de dados laboratorial e uma plataforma de telemetria IoT. Ele modela sete níveis de hierarquia, desde o sistema até o lote de matéria-prima, é atualizado diariamente e usa um modelo temporal baseado em estado para que as equipes possam responder tanto a perguntas de configuração em um momento específico quanto a perguntas sobre todo o histórico de retrabalho. Verificações diárias de qualidade de dados monitoram se o produto está completo o suficiente para apoiar investigações de engenharia, qualidade e fabricação. O nome reflete os conceitos de rastreabilidade e ciclo de vida de um passaporte de produto, mas o Fuel Cell Passport é um produto de dados de engenharia interno — não um artefato de conformidade regulatória como o EU Digital Product Passport (DPP), embora a mesma base de rastreabilidade pudesse dar suporte a um.

Isso parece uma história de sucesso convencional de lakehouse: integrar as fontes, modelar o domínio, governar o acesso, tornar os dados reutilizáveis. Para a AI, o ponto estrutural é o contexto anexado: um produto governado em torno dos dados modelados.

O contexto como uma métrica de qualidade

O Unity Catalog nos fornece a estrutura governada: tabelas, colunas, propriedade, linhagem, classificações e permissões. O Data Hub adiciona a camada de produto ao redor dela. Um produto de dados combina propriedade, estado do ciclo de vida, atribuição de domínio, ativos governados vinculados e entradas de contexto que explicam para que serve o produto e como ele deve ser usado.

Essa distinção é importante para a AI. Os agentes precisam de mais do que metadados de esquema e mais do que um documento. Eles precisam entender quais perguntas de negócios um produto de dados apoia, como as tabelas importantes se relacionam, quais ressalvas importam e quais ativos ao redor devem ser usados com ele. Persistimos esse contexto mais rico na camada de produto de dados, incluindo extensas entradas de catálogo em markdown que são escritas durante o processo de desenvolvimento, enquanto o contexto do projeto ainda está fresco.

Isso mudou a forma como pensamos sobre a qualidade dos dados. A completude e a atualização dos dados ainda importam, mas não são mais suficientes. Para dados prontos para AI, a cobertura de contexto tornou-se uma métrica de qualidade de primeira classe.

Em nosso marketplace, cada produto de dados carrega um selo de cobertura de contexto. Ele mostra se as descrições das tabelas estão presentes e quanta documentação em nível de coluna existe nas tabelas anexadas ao produto. O selo tornou a métrica visível e acionável. A cobertura aumentou porque os engenheiros podiam ver a lacuna diretamente na superfície do produto onde os dados seriam consumidos.

A métrica não é uma garantia de que toda ambiguidade semântica foi resolvida. É um proxy prático que torna o contexto ausente visível cedo o suficiente para ser corrigido. Historicamente, a cobertura de contexto melhorou porque o selo transformou a documentação de uma tarefa de limpeza pós-fato em algo que os engenheiros podiam ver, medir e melhorar como parte da entrega.

Hoje, temos 27 produtos de dados publicados, todos com rica documentação em markdown. Os produtos publicados têm uma média de 90% de cobertura de comentários de coluna, sendo que a maioria dos comentários de coluna é assistida por AI durante o trabalho de engenharia de dados e revisada pelo engenheiro antes do merge. A entrada do catálogo adiciona outra camada de contexto: um resumo longo em markdown do fluxo de trabalho de desenvolvimento, das decisões de domínio, das relações entre tabelas, das ressalvas e das formas pretendidas de consumir o produto.

A mudança importante é que a documentação se torna parte do fluxo de trabalho de engenharia e, em seguida, fica disponível como contexto de produto estruturado para o próximo humano ou agente que precisar raciocinar sobre os dados.

Uma UI para humanos, um MCP para agentes

O Data Hub é a camada que torna esse substrato consumível. Para usuários humanos, é um marketplace e um workbench. Os funcionários podem descobrir produtos de dados, ver proprietários e status do ciclo de vida, abrir dashboards e aplicativos vinculados, consultar dados governados pelo Unity Catalog e usar uma interface de chat para exploração em linguagem natural. Para clientes de AI, o mesmo contexto é exposto por meio do MCP. Qualquer agente ou assistente de codificação compatível com MCP pode acessar os mesmos metadados do Unity Catalog e o contexto do produto de dados que o Data Hub usa.

O modelo de governança

A arquitetura é deliberadamente construída em torno de um único modelo operacional. A identidade flui de ponta a ponta. O acesso aos dados permanece governado. As chamadas de modelo e ferramenta são observáveis. Traces e avaliações alimentam a melhoria contínua.

Isso só funciona porque a governança foi projetada na plataforma desde o início. A propriedade de produção, a implantação e o consumo são preocupações separadas. Os engenheiros alteram pipelines e definições de produtos por meio de código revisado e caminhos de implantação governados. Os consumidores, incluindo agentes, não recebem identidades de gravação em produção. Eles acessam dados por meio do Data Hub, dashboards, Genie, ferramentas SQL ou MCP usando a identidade do usuário autenticado, com o Unity Catalog tomando a decisão final de autorização.

Essa distinção é o que torna o acesso do agente governável. Um agente pode raciocinar sobre o mesmo contexto de produto que um usuário vê e pode chamar ferramentas em nome do usuário, mas não pode se tornar um gravador de produção ou ignorar o Unity Catalog com uma credencial de back-end compartilhada. Se o usuário não tiver acesso a uma tabela, coluna mascarada ou visualização governada, o agente receberá o mesmo limite. Esse modelo operacional nos permite autorizar o acesso de agentes aos dados sem criar um segundo caminho, menos rígido, ao redor da plataforma.

A identidade começa no Azure AD e flui pelo Data Hub para a Databricks usando a troca de tokens OAuth 2.0 — o padrão de passagem de token em nome de (on-behalf-of) que a Databricks descreve em sua arquitetura de governança de agentes. Um usuário que consulta uma tabela por meio da UI, um agente que chama uma ferramenta SQL e um workspace do Genie invocado como uma chamada de ferramenta governada operam todos dentro do mesmo limite de permissão. Se o usuário não puder acessar os dados subjacentes, o agente que atua em nome desse usuário também não poderá. Esse é o modelo de acesso que permite que o Data Hub seja útil sem se tornar um sistema de governança paralelo.

No lado da AI, executamos agentes personalizados no Databricks Model Serving, usamos o Claude por meio de Foundation Model APIs, e invocamos workspaces do Genie como ferramentas governadas onde for adequado. A arquitetura MCP é híbrida por design: o MCP gerenciado pela Databricks oferece acesso governado a recursos da Databricks, como chamadas de ferramentas do Genie, e nosso próprio MCP fornece a camada de contexto mais rica — metadados do Unity Catalog, objetos de produtos de dados e markdown do catálogo —, além das ferramentas específicas de negócios que os agentes chamam sobre ela. Os agentes precisam de ambos.

Observabilidade e avaliação

A observabilidade é onde a arquitetura se torna operacional. O Unity AI Gateway agora roteia o tráfego de modelos de fundação em nosso ambiente. Com uma pequena alteração no cliente do modelo, as chamadas de modelo do Data Hub fluem por uma única camada de governança e observabilidade com rastreamento de uso e tabelas de inferência ativados. Como as solicitações e respostas chegam às tabelas Delta do Unity Catalog, elas podem ser analisadas com os mesmos padrões SQL que já usamos para dados de negócios.

O tracing do MLflow nos dá a próxima camada de visibilidade. Padronizamos os traces em nossos adaptadores de agente para que cada interação possa ser inspecionada como um caminho de execução estruturado: chamadas de modelo, chamadas de ferramenta, etapas intermediárias e respostas finais. Além desses traces, executamos um framework de avaliação contínua com avaliadores de correção determinística e de fundamentação em SQL, avaliadores de custo conscientes de cache e avaliadores de juízes LLM com alinhamento de especialistas do domínio. O objetivo é mais amplo do que testar alterações no agente. A própria camada de contexto precisa de avaliação: o markdown pode se desviar dos pipelines e das definições de tabela, os prompts do sistema evoluem, os contratos de ferramentas mudam e as suposições de domínio envelhecem. Traces e avaliações nos permitem testar o agente, as ferramentas e o contexto em que ele se apoia em conjunto, antes que qualquer um deles molde o comportamento em produção.

Pela primeira vez, a empresa tem um ponto de entrada único e governado para que os funcionários descubram quais produtos de dados existem e interajam com eles em linguagem natural, sujeitos aos mesmos controles de acesso que os dados subjacentes.

O mesmo padrão, dentro do ciclo de desenvolvimento

O mesmo padrão também mudou a forma como construímos.

Nosso fluxo de trabalho de engenharia agora inclui agentes dentro do ciclo de desenvolvimento. A ferramenta de codificação exata é menos importante do que o padrão: um engenheiro trabalha em um ambiente de desenvolvimento assistido por AI conectado aos recursos do Databricks e ao nosso próprio MCP da camada de contexto. Quando o engenheiro trabalha em um produto de dados, o agente pode inspecionar metadados relevantes do Unity Catalog, ler a documentação existente do produto, entender o contexto do projeto próximo e ajudar a estruturar pipelines, testes, descrições de tabelas e entradas de catálogo em markdown. O engenheiro continua sendo o responsável pela revisão e pelo merge, mas o agente está presente enquanto o contexto é mais rico.

Esse momento é fundamental. A documentação escrita após o fato geralmente é incompleta porque o contexto do projeto já mudou. A documentação escrita durante o desenvolvimento captura o raciocínio, as definições e as ressalvas que tornam os dados úteis mais tarde — e, uma vez revisada e commitada, torna-se o contexto para o próximo fluxo de trabalho.

Para muitos de nossos fluxos de trabalho de R&D e desenvolvimento de processos, o que costumava levar semanas de integração de dados entre sistemas, definição de KPIs e estruturação de pipelines agora é entregue em dias. A melhoria aparece menos como um único número de automação e mais como um tempo menor entre a solicitação de investigação e o produto de dados utilizável: menos handoffs manuais entre especialistas de domínio e engenheiros de dados, menos repetição de integração de sistemas de origem, alinhamento mais rápido sobre as definições de KPIs e revisão antecipada de ressalvas enquanto o contexto ainda está fresco. Algumas categorias, especialmente investigações complexas de múltiplas fontes que exigem uma revisão cuidadosa do domínio, continuam exigindo um trabalho substancial, apenas substancialmente mais rápido. O benefício duradouro é cumulativo: cada produto adiciona contexto de negócios revisado à plataforma, de modo que a próxima investigação começa com uma parte maior do domínio já explicada.

A Databricks agora está transformando partes desse padrão em produtos. O Unity AI Gateway Coding CLI, ucode, roteia ferramentas de codificação pelo AI Gateway e conecta servidores MCP ao fluxo de trabalho do desenvolvedor. O Genie Code traz codificação agentica e trabalho com dados diretamente para as interfaces do Databricks.

Para onde vamos a partir daqui

Para nós, o próximo passo é tornar os agentes cientes do contexto operacional em torno dos dados, bem como das próprias tabelas. Em uma investigação de qualidade ou manufatura, um agente deve ser capaz de recuperar uma tendência, inspecionar as verificações de qualidade de dados anexadas ao produto e trazer logs de alarme de máquina relacionados da mesma janela de tempo. A resposta pode, então, trazer a ressalva que um engenheiro esperaria: a tendência aponta nesta direção, mas este trecho exige cautela porque a integridade foi sinalizada e o contexto operacional estava anormal.

A mesma ideia se aplica ao trabalho recorrente. Hoje, o conhecimento do processo está espalhado por runbooks, páginas de wiki, prompts locais, scripts, convenções de equipe e hábitos não documentados. Um Skills Marketplace dá a esse conhecimento o mesmo tratamento de plataforma que os produtos de dados: propriedade, revisão, versionamento, estado do ciclo de vida e um local central onde os agentes encontram a maneira aprovada de trabalhar. Nesse contexto, uma skill empacota as instruções, ferramentas aprovadas, templates, guardrails e verificações de avaliação que dizem a um agente como uma tarefa recorrente deve ser executada em nosso ambiente. Concretamente, ela viveria no marketplace ao lado dos produtos de dados que toca, seria versionada e revisada como código e seria invocada pelo nome para que o agente siga o mesmo caminho aprovado todas as vezes. Uma skill pode estruturar um Databricks Asset Bundle específico do domínio em um repositório remoto ou guiar um engenheiro no registro de um dispositivo IoT e na transformação de logs de máquina desorganizados em um pipeline bronze.

Essa é a direção mais ampla para o Data Hub: extrair a mesma lição da base do lakehouse, governar o contexto primeiro e aplicá-lo tanto aos dados que os agentes consultam quanto ao trabalho que eles ajudam a realizar.

A principal lição

É por isso que os dados de R&D pertencem ao lakehouse. A AI industrial precisa de contexto governado: os dados, o significado, as permissões, os traces e o loop de feedback em uma única arquitetura.

Para a cellcentric, tornar a AI industrial prática significa dar aos agentes esse contexto sobre uma base de lakehouse comprovada. Unity Catalog, produtos de dados, identidade, observabilidade e fluxos de trabalho de agentes trabalham juntos para permitir que humanos e agentes raciocinem sobre dados de R&D com segurança. Isso é mais do que uma prática recomendada para nós. É como estamos moldando a próxima geração da engenharia orientada a dados.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original