A cena se repete em quase todo banco que visito. O lakehouse está pronto, o Power BI está disseminado, o time comprou a ideia de copiloto de dados — e a POC morre na primeira pergunta séria. O motivo nunca é o modelo. É que ninguém contou ao LLM que, naquele banco, inadimplência exclui contratos renegociados nos últimos 90 dias, que “cliente ativo” tem regra diferente em Varejo e em Atacado, e que Conta se liga a Contrato por uma chave que só existe no mainframe. O modelo não erra por falta de dado. Ele erra por falta de contexto de negócio governado.

As duas plataformas dominantes chegaram à mesma conclusão e moveram a semântica para baixo, do BI para a camada de dados. Databricks respondeu com Unity Catalog Metric Views e Genie Ontology; Microsoft Fabric respondeu com Fabric IQ Ontology sobre o OneLake. Métricas, entidades e regras deixaram de ser código dentro de um relatório e viraram artefatos de catálogo — com linhagem, permissão e auditoria — consumidos igualmente por SQL, BI e agentes.

O que é ontologia de dados?

Ontologia é a camada que declara o que as coisas significam no seu negócio: quais entidades existem (Cliente, Conta, Contrato, Garantia, Evento de Risco), como elas se relacionam, e quais regras definem cada métrica. É o oposto de um dicionário de dados em PDF: é um objeto versionado, governado e consultável por máquina.

O contraste com a alternativa é direto. Sem ontologia, o significado vive espalhado em três lugares — no DAX do modelo semântico, no notebook do time de risco e na planilha da controladoria. Com ontologia, existe um contrato semântico único, e todo consumidor — dashboard, analista ou agente — parte da mesma definição.

O problema que resolve

O problema não é falta de dado. É deriva semântica: a mesma pergunta gera três respostas porque a métrica foi reimplementada três vezes. Enquanto isso ficava em BI, o custo era um slide errado numa reunião. Com agentes, o custo muda de natureza:

Um agente de cobrança que entende “inadimplente” de forma diferente do time de risco não produz um número errado. Ele produz uma ação errada em produção — uma régua disparada contra um cliente que renegociou ontem.

Três dores desaparecem quando a semântica sobe para o catálogo:

1. Divergência de KPI — cada métrica passa a ter um dono nomeado e uma definição versionada, em vez de três implementações concorrentes.
2. IA não auditável — o agente resolve contra uma métrica governada, e o SQL gerado é inspecionável. Isso é o que torna IA generativa aceitável em ambiente regulado.
3. Segunda cópia do dado — quando a semântica é compartilhada, o dado físico não precisa ser duplicado para atender BI e engenharia.

Como funciona — passo a passo

1. Fixe a autoridade sobre o dado. Unity Catalog é a autoridade única sobre o dado físico em Delta; Purview é o plano de conformidade corporativo por cima. Essa decisão vem antes de qualquer discussão de ferramenta.
2. Conforme o Silver pelas entidades, não pelo sistema de origem. A camada Silver deve refletir Cliente, Conta, Contrato — não o layout de arquivo do mainframe. É aqui que a ontologia deixa de ser diagrama e vira modelagem.
3. Declare a ontologia mínima. Comece com 7 entidades e ~12 relações. Em banco de varejo, o núcleo que sustenta risco, cobrança, fraude e resposta regulatória é: Cliente → Conta → Contrato → Garantia, mais Relacionamento (grafo societário), Transação, Evento de Risco e Alerta de Fraude.
4. Converta os KPIs críticos em métricas governadas. Cinco bastam para provar o conceito. KPI que depende da lógica do pipeline nasce como Metric View no Databricks; métrica de apresentação nasce no modelo semântico do Fabric.
5. Exponha por referência, não por cópia. Publique as tabelas Gold no OneLake via shortcut ou mirroring. O dado permanece em Delta sob o Unity Catalog e aparece no Fabric sem pipeline, sem defasagem e sem segunda fatura de storage.
6. Aponte a IA para a semântica, nunca para a tabela crua. Genie, Copilot, Data Agents e agentes do Foundry devem resolver contra Metric View e ontologia. Se o agente consegue ler a tabela crua, você não tem contrato semântico — tem uma sugestão.
7. Instrumente o agente como ativo auditável. MLflow 3 grava o trace completo de cada decisão — prompt, versão do prompt, ferramentas chamadas, contexto recuperado, versão da métrica e resposta — em tabela Delta governada pelo UC.

Onde nasce cada conceito

O erro mais caro que vejo não é escolher a plataforma errada. É escolher uma das duas e recriar as definições na outra. A arquitetura correta define onde cada conceito nasce e propaga a partir dali.

A regra prática: Databricks é o plano de engenharia e ML; Fabric é o plano de consumo e semântica de negócio. Em quase todo cliente FSI de porte, a resposta não é “um ou outro” — é definir a fronteira por persona, e deixar o OneLake evitar a segunda cópia.

O caso de uso que fecha a conta

Pegue o perfil típico: banco de varejo com ~12 milhões de clientes, ~40 milhões de transações PIX por dia, carteira de R$ 60 bi, core em mainframe e um time de risco que exporta para Excel porque não confia no número do painel.

Quatro dores, quatro respostas arquiteturais:

• Inadimplência 90+ tem três implementações. Vira uma Metric View com dono nomeado, definição em Git e teste de regressão semântica. Fim da divergência.
• Score de fraude roda em batch de 15 minutos, mas a perda acontece em 90 segundos. PIX entra por Event Hubs → Eventstream → Eventhouse; o modelo fica no Databricks; o Activator dispara o bloqueio. Score na janela da transação.
• Demanda do BACEN sobre exposição de grupo econômico leva 5 dias e 4 times. A entidade Relacionamento na ontologia transforma isso em consulta — o agente regulatório monta a exposição em minutos.
• Régua de cobrança única para toda a carteira. Modelo de recuperabilidade no MLflow + agente que prioriza por probabilidade de retorno, e não por dias de atraso.

O efeito colateral que ninguém antecipa: quando existe uma definição oficial por KPI, o time de risco para de exportar para Excel. A confiança no painel é consequência da governança semântica, não de treinamento de usuário.

O custo que ninguém modela

Duas plataformas, dois modelos de consumo — e é aí que a conta escapa.

Databricks cobra por DBU/segundo mais a infraestrutura Azure. Escala bem com carga irregular e reprocessamento histórico. O risco de FinOps é conhecido e sempre o mesmo: cluster all-purpose sem auto-terminate. É de longe a maior fonte de desperdício de DBU que encontro em FSI.

Fabric cobra capacidade F (CU) compartilhada entre todas as cargas, com smoothing e bursting. Reserva de 1 ano reduz cerca de 40%. O risco aqui é oposto: throttling por capacidade subdimensionada e vizinho barulhento no mesmo F SKU. Vale lembrar o degrau de licenciamento: abaixo de F64 você ainda paga Power BI Pro por leitor; a partir de F64 os leitores são gratuitos — o que muda a matemática em qualquer cenário com milhares de usuários de BI.

Some a inferência: em torno de 3.500 tokens de entrada e 900 de saída por consulta de agente é uma premissa razoável para dimensionar a curva. Modele a adoção em 12 meses, com fundação e migração nos primeiros meses e cargas de IA entrando a partir do M4 — não como um degrau único no mês 1. E valide sempre na Calculadora de Preços do Azure antes de qualquer compromisso: preço de lista varia por região, câmbio, tributo e acordo comercial.

Boas práticas para produção

• Uma cópia física do dado. Fabric acessa por shortcut ou mirroring. Copiar Gold com pipeline paga storage e computação duas vezes e ainda cria defasagem.
• Cada KPI com dono nomeado, definição versionada em Git e teste de regressão semântica no CI/CD. Métrica sem dono volta a divergir em três meses.
• Capacidade F separada por domínio crítico, com alerta de consumo antes do throttling. Não rode ETL pesado dentro da capacidade F e depois culpe o Power BI.
• Auto-terminate e autoscale obrigatórios em todo cluster. Tags por domínio, orçamento por workspace e revisão mensal de DBU ocioso — FinOps desde o dia 1, não no mês 9.
• Agente sempre resolvendo contra ontologia ou Metric View, com o SQL gerado visível ao usuário. Apontar agente para tabela crua “porque é mais rápido para a POC” não sobrevive à auditoria.
• Rótulo de sensibilidade e masking aplicados no UC/Purview, herdados por BI e por agente. Controle aplicado na borda não é controle.
• Steward de negócio na ontologia. Ontologia desenhada só por engenharia vira mais um dicionário morto.

O que precisa estar de pé

Não é questão de prazo — é questão de dependência. Cada estágio só se sustenta se o anterior estiver fechado, e é por isso que projeto de ontologia que começa pelo agente sempre volta para o início. O que segue é declarativo: o que precisa ser verdade, não quando.

Fundação — a autoridade sobre o dado. Unity Catalog é a autoridade única sobre o dado físico, com Purview conectado como plano de conformidade corporativo. A landing zone tem Private Link, CMK, Entra e tags de FinOps desde o primeiro workspace — não como retrofit. Ao menos dois domínios chegam ao Silver conformados pelas entidades da ontologia, não pelo layout do sistema de origem. A ontologia mínima está declarada, e os KPIs mais brigados da casa existem como Metric Views com dono nomeado e definição em Git. Uma tabela Gold já aparece no Fabric por shortcut, alimentando um modelo semântico Direct Lake.
Está de pé quando um KPI de risco devolve o mesmo número no Power BI e no Genie.

Produção com contexto — a semântica virando decisão. A ontologia de negócio está publicada e ligada ao dado que já vive no OneLake, por referência e nunca por cópia. Os modelos que importam — fraude, recuperabilidade, PD/LGD — estão em serving, e o evento crítico atravessa o streaming até o gatilho operacional dentro da janela em que a perda acontece. O primeiro agente de negócio responde no canal onde a pessoa já trabalha, resolvendo contra métrica governada, com o SQL gerado visível. Cada decisão desse agente deixa trace, versão de prompt, ferramentas chamadas e versão de métrica em tabela Delta governada pelo UC.
Está de pé quando Compliance aceita a rastreabilidade sem pedir planilha de apoio.

Escala e eficiência — a plataforma como produto. A ontologia deixou de ser projeto de um domínio e cobre as demais áreas do banco, mantida por stewards de negócio e não por engenharia. Cada domínio crítico tem capacidade própria com chargeback interno e alerta de consumo antes do throttling. O contrato semântico está versionado em CI/CD, com teste de regressão que quebra o build quando alguém muda a definição de um KPI sem querer. Reserva de capacidade e higiene de DBU — auto-terminate, autoscale, revisão mensal de ocioso — deixaram de ser iniciativa e viraram rotina. Os data marts e as extrações legadas que existiam só para contornar a falta de definição única foram descomissionados.
Está de pé quando o custo por domínio é visível e o número do painel não é mais discutido em reunião.

Repare que a ordem não é cronológica, é causal. Você não escala uma semântica que ninguém governa, e não governa uma semântica que não tem dono. Quem tenta pular a fundação para chegar mais rápido ao agente não chega mais rápido — chega ao mesmo lugar duas vezes.

Perguntas frequentes (FAQ)

Databricks ou Fabric — preciso escolher?

Na prática, não. A pergunta certa é onde colocar cada carga. ETL pesado, treino de modelo e observabilidade de agente ficam no Databricks, pela elasticidade por segundo e pelo MLflow. Modelo semântico, BI corporativo e ontologia de negócio ficam no Fabric, pelo Direct Lake e pelo alcance junto ao negócio. O OneLake é o que evita a cópia entre os dois.

Ontologia não é só um dicionário de dados com nome bonito?

Não. Dicionário de dados descreve; ontologia executa. A diferença prática é que a definição de “cliente ativo” na ontologia é a mesma string que o agente consulta, o dashboard renderiza e o auditor lê — com linhagem e permissão herdadas do catálogo. Dicionário em PDF não tem nada disso.

Fabric IQ está em preview. Dá para comprometer arquitetura com isso?

Dá para comprometer o padrão, não o cronograma. Declare a semântica primeiro onde ela já é GA — Metric Views no Unity Catalog e modelo semântico certificado — e valide disponibilidade regional do Fabric IQ (especialmente em Brazil South) antes de mover o vocabulário corporativo para lá.

Como provo para Compliance que o agente é auditável?

Com trace, não com slide. MLflow 3 grava prompt, versão do prompt, ferramentas chamadas, contexto recuperado, versão da métrica e resposta em tabela Delta governada pelo UC. LLM judges pontuam qualidade em produção e detectam regressão antes do regulador. É a diferença entre “o agente respondeu isso” e “consigo reconstruir por que ele respondeu isso”.

Por onde começar se o orçamento é pequeno?

Por um KPI. Escolha a métrica mais brigada da casa, dê um dono a ela, converta em Metric View e prove que Power BI e Genie devolvem o mesmo número. Isso custa semanas, não trimestres — e é o argumento que destrava o resto.

Conclusão

O gargalo da IA corporativa deixou de ser o modelo. É contexto de negócio governado — e as duas plataformas convergiram para a mesma tese porque a alternativa não escala: agente apontado para tabela crua é protótipo, não sistema.

A decisão de arquitetura que sobra não é “Databricks ou Fabric”. É onde nasce cada definição, quem é o dono dela e como o agente é obrigado a passar por ela. Quem resolve isso primeiro coloca IA em produção em ambiente regulado. Quem deixa para depois passa o ano explicando por que o número do painel não bate.

👉 Se você está desenhando a camada semântica da sua plataforma de dados — especialmente em serviços financeiros, onde auditoria e definição única não são opcionais —, essa é a decisão que separa POC de produção. Quer trocar ideia sobre ontologia, Databricks e Fabric? Me chama no LinkedIn.