Governança além da segurança: conhecimento, contexto e ontologia no lakehouse

Pergunte à maioria das organizações o que significa governança de dados para AI, e você ouvirá uma resposta voltada para a segurança: bloquear tudo, restringir o acesso, passar na auditoria. Na área da saúde, a segurança é inegociável — mas é incompleta. A segurança diz quem pode tocar nos dados. Ela não diz nada sobre o que os dados significam, se são confiáveis ou se um modelo de AI deveria aprender com eles.

Nosso Data Empowerment Program (DEP) parte de uma premissa diferente: governança é conhecimento, contexto e ontologia; não apenas controles. Artefatos que a maioria das equipes trata como burocracia de conformidade, como tags de classificação, políticas de desidentificação, model cards e contratos de dados, são a matéria-prima para a semântica de dados corporativos.

Quando vista dessa forma, você não precisa escolher entre governança e AI; em vez disso, a governança ajuda a construir a AI. Novas abordagens de governança precisam ser implementadas na era da AI. A única questão é se você fará o trabalho mais tarde apenas para passar na auditoria, ou agora, para estabelecer a base sobre a qual sua AI opera.

Nosso objetivo é mostrar que o trabalho de segurança e governança que você já faz é a base sobre a qual sua AI opera. Governe os dados bem o suficiente, e a AI poderá rodar em modelos mais baratos com mais confiança.

A governança precisa pensar de forma mais ampla em cinco pilares através de uma única lente

Comece com a perspectiva de que cada artefato de governança contribui para a semântica. Cada tag de classificação é um conceito. Cada model card é um contexto. Cada contrato de dados é uma definição compartilhada. Cada link de linhagem é um relacionamento. Lida dessa forma, a pilha de segurança que você já executa é o primeiro rascunho da sua ontologia, e o catálogo é onde ela reside.

A governança deixa de ser uma coisa só e se torna cinco facetas de uma única disciplina: os dados em si e como são controlados, a AI construída sobre eles, as pessoas que precisam entendê-los, os produtos que os levam para o negócio e o contexto compartilhado que une esses quatro elementos. É a mesma lente, mas sob cinco frentes.

Com o DEP, visualizamos a semântica por meio de cinco pilares:

• Governança de Dados — Catálogo, qualidade, curadoria, linhagem e com segurança e conformidade integradas, como classificação de PII, controle de acesso, HIPAA/GDPR e riscos de privacidade específicos de AI.
• Governança de Conhecimento (AI/ML) — Documentação de modelos, governança e padrões de AI responsável, como viés e equidade, explicabilidade, supervisão humana e preparação para o EU AI Act.
• Alfabetização de Dados (Data Literacy) — Treinamento, capacitação de autoatendimento, certificação de profissionais e KPIs, como taxas de adoção, métricas de uso e ROI do programa.
• Gestão de Dados — Arquitetura, engenharia de dados e contratos de produtos de dados devem incluir acordos de esquema, SLAs e limites de qualidade, além de obrigações de produtores/consumidores.
• Ontologia — Glossário, taxonomia, grafo de conhecimento - culmina em uma camada semântica de AI. Isso inclui contexto para LLMs, grounding de RAG e prontidão para consultas via chat.

Operacionalizando a visão por meio de agentes

Nossa visão de cinco pilares não passa de uma apresentação de slides (slideware) a menos que a plataforma possa transformá-la em algo operacional. Quando seus artefatos de governança passam a existir como metadados estruturados e legíveis por máquina, eles deixam de ser apenas documentação e se tornam conjuntos de instruções para agentes.

Quando nos referimos a "agente", estamos pensando nisso de duas maneiras: “agentes de build” que montam e entregam produtos de dados, e “agentes analíticos” que respondem a perguntas de negócios sobre eles; cada um vinculado a um único produto de dados.

Vamos começar com os agentes de build. Os agentes de build automatizam o ciclo de vida de entrega de produtos de dados, desde o mapeamento de origem até o ETL, testes e desidentificação para um lançamento em produção. Tudo o que eles precisam reside no Unity Catalog como metadados governados: mapeamentos de origem para destino, definições de negócios, níveis de classificação, políticas de desidentificação, contratos de dados e model cards. A plataforma deriva de tags, comentários, flags de certificação, linhagem e termos vinculados ao glossário. O catálogo não é apenas onde você documenta a governança; é o runtime contra o qual os agentes operam.

Cada agente trabalha em um loop. Ele lê instruções do catálogo; realiza uma tarefa concreta, como gerar código de pipeline, executar uma suíte de testes, produzir dados desidentificados ou implantar um conjunto de dados certificado; e depois grava as evidências de volta como resultados de testes, pontuações de qualidade, linhagem ou dados de captura de alterações. Isso se repete.

Na prática, sequenciamos os agentes de De-ID e testes primeiro. Eles eliminam os maiores riscos e o trabalho manual mais pesado logo de início. Começar onde o retorno é mais rápido ajuda a ganhar tração cedo. À medida que avançamos pelo loop, nenhum agente atua em dados que o catálogo não descreva.

Os catálogos modernos tornam essa abordagem escalável porque podem gerar automaticamente descrições de colunas e tabelas para aprovação de um steward, classificar campos confidenciais automaticamente e capturar a linhagem em nível de coluna sem que ninguém precise mantê-la manualmente. O papel humano muda de criar os metadados para aprová-los, que é exatamente o tipo de trabalho de julgamento que os humanos devem fazer.

O ciclo de vida de construção de dados e AI: comprovação e contexto contínuo

Os agentes de build operam dentro de um ciclo de vida de ponta a ponta projetado para lançar dois ativos simultaneamente: o produto de dados governado (mapeamento, curadoria, pipeline) e o agente analítico que roda sobre ele (camada semântica, configurações de prompt, suítes de avaliação).

Essa abordagem marca uma mudança fundamental da engenharia centrada em pipeline (mover dados do ponto A para o B) para a engenharia centrada em contexto (tornar os dados compreensíveis e acionáveis para LLMs). Em vez de certificar apenas a qualidade do código, as etapas de validação (gates) neste ciclo de vida validam a semântica, o contexto e a propriedade.

Duas propriedades centrais distinguem essa estrutura de um SDLC tradicional:

• É autocomprovável: A prova de confiabilidade é um subproduto natural da entrega, em vez de uma correria de auditoria montada após o fato.
• Melhora continuamente o contexto: O comportamento em produção alimenta um loop de AgentOps — transformando consultas com falha, clusters de alucinação e avaliações negativas dos usuários no backlog semântico da próxima sprint.

Os stewards humanos servem como a camada de responsabilidade para ambas as propriedades: os agentes propõem, as pessoas aprovam. Embora gerenciar cinco gates em duas trilhas possa parecer a criação de gargalos demorados, a maioria deles pode ser liberada em poucas horas. As aprovações ocorrem diretamente nas ferramentas padrão dos desenvolvedores. Suítes de testes automatizados anexam resultados de qualidade de dados, pontuações de avaliação e linhagem antes que um ticket seja aberto. Uma reunião formal de validação é uma exceção para investigação, não o procedimento operacional padrão.

A Certificação de AI é o motor por trás dos gates

O mecanismo que torna esses gates objetivos, em vez de arbitrários, é a Certificação de AI. Registrada diretamente no Unity Catalog, essa certificação funciona como um scorecard automatizado e consultável, em vez de um atestado jurídico manual. Ela governa a elegibilidade de lançamento em quatro dimensões principais:

• Pontuação Automatizada vs. Humana: As pontuações de Governança, Qualidade e Semântica são calculadas automaticamente a partir de tabelas de sistema consultáveis, resultados de pipeline e execuções de avaliação. A pontuação de Propriedade e o selo final de implantação exigem uma assinatura explícita do steward.
• Expiração Contínua: A certificação é dinâmica. Uma alteração de esquema, atualização de contrato ou falha na suíte de avaliação revoga instantaneamente a certificação até que as verificações sejam executadas novamente e aprovadas.
• Aplicação na Camada de Dados: Os controles de acesso operam via Attribute-Based Access Control (ABAC) na camada de dados, não na camada de aplicação. Se um usuário não puder consultar uma linha no SQL, nenhum agente poderá recuperá-la via busca vetorial ou embeddings.
• Isolamento Rigoroso de Limites: Ambientes que não são de produção (SIT, regressão, teste de modelo) consomem exclusivamente dados sintéticos ou desidentificados. Isso garante que as PHI de produção nunca saiam do limite governado.

Quando o agente erra, quem corrige?

A certificação e os marcos de aprovação provam que um agente era confiável no momento do lançamento. Mas a pergunta que os líderes de governança fazem não é "como isso funciona", mas sim "quem é o responsável quando ele dá a resposta errada?" A resposta deve ser um nome específico, não um comitê de direção.

Para resolver isso, cada agente analítico (por exemplo, um Databricks Genie Agent) é vinculado a um único produto de dados governado com um proprietário designado. Quando um agente retorna um resultado incorreto porque uma métrica subjacente foi mal definida, o problema não é da equipe de engenharia de AI. Em vez disso, ele vai direto para o Data Product Owner, que corrige a definição no catálogo. Vincular um agente a um produto de dados certificado e com escopo de domínio também é a maior alavanca de precisão disponível: um agente focado que consulta metadados certificados supera consistentemente um modelo global que tenta adivinhar respostas em todo o acervo da empresa.

Crucialmente, essa definição de métrica compartilhada é aplicada de forma obrigatória, e não apenas documentada. Assim que uma métrica certificada é definida no catálogo, o agente de respostas é obrigado a calcular diretamente a partir dela. Isso transforma a documentação estática em lógica ativa de tempo de execução.

A responsabilidade é mantida devido a um limite rígido sobre o que a AI tem permissão para fazer sem supervisão: nenhum agente promove código para produção, modifica políticas ou opera em dados não classificados sem intervenção humana. Embora as pontuações de certificação sejam calculadas automaticamente, o marco final de aprovação de lançamento sempre exige uma assinatura humana. Se o catálogo não descrever explicitamente um ativo de dados, o sistema adota a supressão por padrão em vez de tentar adivinhar. No tempo de execução, essa política de fail-closed impõe limites claros:

• Para Agentes Analíticos: Em vez de especular ou inferir o contexto sobre dados brutos, o agente se recusa explicitamente a responder, retornando uma mensagem transparente (por exemplo, "Este conjunto de dados não possui a certificação ativa ou o mapeamento semântico necessários para processar sua solicitação.")
• Para Agentes de Build: Se um esquema não classificado ou um contrato ausente for detectado durante a montagem do pipeline, a execução será interrompida automaticamente antes de chegar aos ambientes de homologação (staging), registrando um alerta de ativo não mapeado para a revisão do steward.

Definir essas diretrizes de segurança (guardrails) no papel é fácil, mas fazê-las funcionar na prática exige substituir comitês de governança vagos por quatro papéis distintos e responsáveis:

• Data Product Owner: Responsável pelas definições e pela qualidade de um produto governado. Eles são o único ponto de contato quando uma resposta está errada.
• Engenheiro de Governança de Dados e AI: Traduz políticas em metadados de catálogo executáveis (classificações, contratos, linhagem) para que as regras sejam executadas no tempo de execução, em vez de ficarem paradas em um PDF.
• Steward: Revisa as descobertas automatizadas e aprova os marcos de lançamento. A automação propõe; o steward decide.
• Segurança / IAM: Detém os níveis de classificação e os atributos de acesso que direcionam automaticamente a desidentificação e as permissões em nível de linha.

Teste rigorosamente sem comprometer a segurança

O ciclo de vida que descrevemos tem um pré-requisito rígido oculto: cada uma dessas etapas de teste e avaliação precisa de dados realistas para ser executada – e, no setor de saúde, você não pode testar PHI reais. Portanto, o desafio passa a ser a necessidade de dados de teste realistas em todos os lugares, sem comprometer a segurança.

A desidentificação é como mantemos os dados analiticamente úteis e seguros. De onde o agente de desidentificação obtém seu conhecimento? Não de uma planilha mantida manualmente. Ele trabalha a partir das políticas de segurança que as ferramentas corporativas já produzem. O fluxo tem três etapas:

• Descobrir - Scanners de descoberta automatizados e mecanismos de políticas de InfoSec classificam colunas e arquivos confidenciais.
• Fazer a curadoria - As classificações chegam ao catálogo como metadados de política curados; o agente lê essa curadoria e executa.
• Executar - Ingerir metadados e produzir dados sintéticos ou arquivos de origem desidentificados. Em conformidade com o HIPAA Safe Harbor, referencialmente intactos e analiticamente capazes.

Para a equipe de segurança e IAM, essa é uma via de mão dupla. As políticas de InfoSec deixam de ser PDFs e se tornam executáveis: os níveis de classificação e as regras de retenção direcionam a desidentificação automaticamente. Em troca, a segurança ganha uma visão continuamente atualizada dos dados confidenciais, proteção fail-closed para qualquer nova descoberta e varreduras residuais que geram evidências de auditoria a cada execução. O modelo de acesso permanece o mesmo de ponta a ponta. Como qualquer recuperação de dados por parte do agente herda as permissões de catálogo do usuário que faz a consulta, as abordagens de RAG não podem exibir o embedding de uma linha que o usuário não tem permissão para ver. As mesmas regras de ABAC abrangem tanto o SQL quanto a busca vetorial (vector search), e os agentes agem com as permissões do usuário que faz a consulta, não com uma conta de serviço privilegiada. Cada prompt do agente é registrado com a linhagem usada para respondê-lo, sob a mesma governança dos próprios dados.

Esse é o verdadeiro diferencial: um único modelo de permissão para os dados, os modelos, os embeddings e a trilha de auditoria — e não um catálogo de dados costurado a um registro de modelos separado, que por sua vez é costurado a um armazenamento de vetores separado. O trabalho de governança se torna a base da AI, em vez de um projeto paralelo.

Capture métricas, comprove resultados, conquiste confiança

Observe o que o ciclo de vida tem feito durante todo esse tempo: cada etapa, cada marco de aprovação, cada certificação tem gerado métricas. Reúna as quatro dimensões de certificação em uma única pontuação de prontidão para AI (AI-readiness score) por conjunto de dados e torne-a operacional, não aspiracional. A semântica atinge 100% apenas quando cada coluna carrega uma definição vinculada ao glossário e a tabela tem um contrato de dados assinado; a propriedade (Ownership) atinge 100% apenas quando um proprietário nomeado está respondendo aos problemas.

O resultado que acompanha a pontuação é o caso de negócios para todo o programa DEP: as métricas comprovam os resultados da AI, a comprovação conquista a confiança, e a confiança é o que converte um projeto piloto em uso diário. Nenhum usuário de negócios adota um agente porque o diagrama de arquitetura é elegante. Eles o adotam porque os números estavam corretos na semana passada e alguém responsável os corrigiu quando não estavam. A pontuação explica por que os números dão certo logo de início: quanto maior a pontuação, menos o modelo precisa adivinhar. Ele não precisa inferir o que uma coluna significa, compensar duplicatas ou alucinar joins — porque o catálogo já lhe disse isso.

Não corra atrás das manchetes sobre modelos. Foque na economia dos modelos.

A cada semana surge um modelo maior e mais caro. Eis o que o ciclo de hype ignora: quando o catálogo já fornece o significado, a qualidade e o contexto, o modelo não precisa fazer isso. Modelos menores ou de pesos abertos (open-weights) atendem à maioria das necessidades de relatórios e análises em dados governados.

Modelos de fronteira (frontier models) são frequentemente usados para mascarar lacunas de metadados subjacentes. Quando os esquemas e as regras de negócios são explicitamente catalogados, modelos menores e específicos do domínio oferecem a mesma precisão por uma fração do custo de tokens.

Essa é uma escolha de custo-benefício, não um teto de qualidade. Dimensione adequadamente (right-size) o trabalho diário e reserve os gastos com modelos de fronteira para os problemas que realmente precisam deles, assim os custos nunca forçarão a AI a parar. Corrija os dados. Ajuste o tamanho do modelo. Mantenha a precisão. É isso que as raízes de governança trazem para uma estratégia de AI: não uma AI mais barata — uma AI imparável.

Entre em ação: comece com um único produto de dados

Não tente fazer uma reformulação em toda a empresa de uma só vez. Comprove o modelo conduzindo um único produto de dados por todo o ciclo de vida:

1. Escanear: Ative a varredura de descoberta automatizada em um único esquema de destino.
2. Definir: Defina limites de certificação explícitos no Unity Catalog para integridade, semântica e qualidade.
3. Vincular: Associe um agente analítico ao conjunto de dados, juntamente com um conjunto de avaliação dedicado e um caminho de teste desidentificado.
4. Atribuir: Nomeie um único Data Product Owner responsável pelas definições e pela resolução de problemas.

Assim que o loop estiver em execução, repita o processo para um produto de dados certificado de cada vez. A segurança informa quem pode acessar seus dados, mas a governança diz o que eles significam e se uma IA pode confiar neles.

A governança não é o portão de entrada de uma organização orientada a dados. Feita da maneira certa, ela é o chão sob ela.

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