Times conectam uma IA ao data warehouse esperando respostas imediatas. O que recebem é um SQL convincente que conta as coisas erradas. O modelo raramente é o problema. Um schema bruto não carrega nenhum dos significados de negócio de que a pergunta depende. A solução é uma camada silver que a Inteligência Artificial consiga ler. Ou seja: nomes previsíveis, descrições prescritivas e regras de negócio definidas uma única vez em uma camada semântica governada.
Testamos isso de ponta a ponta: Airbyte para o Snowflake, modelos dbt e um agente de IA consultando via MCP. Este artigo mostra o que se sustentou e o que precisamos mudar.
Vale um contexto rápido. A camada silver vem da arquitetura medallion, o padrão em camadas que a maioria dos data warehouses modernos segue. A camada bronze guarda os dados brutos exatamente como foram ingeridos. A silver reúne tabelas limpas e padronizadas, com nomes e tipos consistentes. A gold concentra os marts e agregados de negócio.
Cada camada refina a anterior. É na silver que os dados se tornam confiáveis o suficiente para uma IA ler.
1. Como a IA consome dados da camada silver?
Dois paradigmas de IA tocam o seu data warehouse. O primeiro são os agentes de código, que ajudam pessoas desenvolvedoras a escrever SQL e modelos dbt. O segundo são as ferramentas de analytics em linguagem natural, que respondem perguntas de negócio diretamente. A camada silver atende aos dois pela mesma camada semântica.
1.1 Cortex Code (CoCo) vs. Claude Code: qual agente escreve o pipeline?
São ferramentas de código com agentes que atuam como pares, e não exatamente como concorrentes. O Cortex Code chegou à disponibilidade geral em fevereiro de 2026. No Summit de junho de 2026, a Snowflake o renomeou como “CoCo” e entregou uma integração com o Claude Code no mesmo release.
| Cortex Code / CoCo | Claude Code | |
| Conhecimento dos dados | Profundo e automático: lê seus schemas, catálogo, RBAC e linhagem de dados dentro do Snowflake | Ganha contexto pela conexão (por exemplo, um servidor MCP do Snowflake) e pelo seu repositório |
| Governança | Roda dentro do perímetro de governança do Snowflake | Depende das permissões da conexão |
| Escopo | dbt + Airflow + fluxos de trabalho nativos do Snowflake | Uso geral: qualquer codebase, qualquer ferramenta |
O CoCo é a escolha padrão mais segura quando tudo vive no Snowflake. Já o Claude Code se destaca quando o trabalho atravessa sistemas além do data warehouse. No nosso projeto, ele se conectou por um servidor MCP do Snowflake e consultou o data warehouse diretamente.
Leia também: As decisões de arquitetura de dados que realmente importam
1.2 Como uma pergunta em linguagem natural vira uma consulta?
Um schema bruto, sozinho, produz SQL pouco confiável. O mapeamento da linguagem de negócio para as tabelas físicas acontece por meio de um modelo semântico: tabelas lógicas, dimensões, medidas e as relações que tornam os joins corretos.
A IA apenas escolhe as métricas e dimensões certas. O motor monta o SQL de forma determinística a partir de entidades e chaves, relações, medidas, dimensões, sinônimos e consultas verificadas, nessa ordem.
2. Quais convenções de nomenclatura tornam a camada silver legível para a IA?
Previsibilidade é o maior ganho de todos. Use prefixos de camada (stg_, int_ e nomes de mart por domínio de negócio), sufixos consistentes (_id, _at), snake_case e nomes com significado de negócio. Uma tabela fct_orders com a coluna order_id diz muito mais ao modelo do que t_ord_01.oid.
2.1 O que acontece quando o mesmo nome de coluna aparece em tabelas diferentes?
order_id é chave primária em orders e chave estrangeira em order_items, payments e shipments. Uma ferramenta ingênua de text-to-SQL faz o join, conta order_id e devolve uma linha por item do pedido. O resultado são contagens infladas.
A correção é estrutural: declare a entidade uma única vez e defina a métrica de forma explícita (number_of_orders = count_distinct(order_id) em orders). Assim, a colisão nunca chega até a IA.
2.2 E quando o mesmo termo de negócio significa duas coisas diferentes?
Colisões de coluna têm solução conhecida. Já as colisões de termo são a armadilha que ninguém planeja. No nosso projeto de time tracking, “horas pendentes” significava duas coisas sem relação: horas abaixo da meta semanal e horas aguardando aprovação do gestor. Pergunte a uma IA sobre “horas pendentes” e ela escolhe um dos sentidos em silêncio, respondendo com toda a confiança.
Resolva no modelo semântico, não no prompt. Dê a cada conceito a sua própria métrica (weekly_hours_gap e hours_pending_approval), associe sinônimos de forma deliberada e nunca deixe uma palavra de negócio apontar para duas medidas. A camada semântica é onde você desambigua um termo uma única vez, para todos os consumidores.
Leia também: Sua estratégia de IA tem um problema de dados
3. Descrições de tabelas e colunas ajudam mesmo a IA?
Sim. O Cortex Analyst e os agentes conectados via MCP leem os metadados do modelo semântico para decidir o que cada campo significa. No entanto, as descrições cumprem dois papéis distintos, e a maioria dos times escreve apenas o primeiro.
3.1 Qual a diferença entre metadados descritivos e regras prescritivas?
Metadados descritivos dizem o que um campo é: “booked_hours: horas lançadas na data do registro”. Regras prescritivas dizem como consultá-lo corretamente: “conte apenas as linhas com status = ‘approved'” ou “um gap positivo significa abaixo da meta”.
No nosso projeto, os agentes respeitaram os comentários prescritivos no momento da consulta: eles mudaram o SQL gerado. Por isso, trate os comentários como um canal de instrução, e não apenas como documentação.
3.2 Onde as descrições devem ficar?
Em ordem crescente de valor: os campos de descrição no YAML do dbt (versionados e persistidos no Snowflake como comentários de objeto via persist_docs); a semantic view (descrições, sinônimos e regras prescritivas); e as consultas verificadas, que fixam o SQL exato para perguntas recorrentes.
4. Onde as regras de negócio devem ficar: nos modelos dbt ou na camada semântica?
Mantenha a camada silver limpa. Mas a resposta prática é mais específica do que “coloque a lógica na camada semântica”. Calcule as regras nos marts do dbt. Em seguida, use a camada semântica como o contrato governado que nomeia, descreve e entrega os números já prontos.
4.1 Qual camada semântica: semantic views do Snowflake ou dbt MetricFlow?
Escolha com base em quem consulta os dados. Se os seus consumidores de IA falam SQL diretamente (Cortex Analyst, Snowflake Intelligence ou um agente em um servidor MCP do Snowflake), use as semantic views do Snowflake. São objetos no nível do schema que o agente pode descobrir, inspecionar e consultar pela função de tabela SEMANTIC_VIEW(), herdando o RBAC nativo.
Se os seus consumidores passam pelas APIs do dbt Cloud, o MetricFlow oferece as mesmas garantias de forma portável entre data warehouses. Para uma stack de Snowflake com agentes, as semantic views funcionaram sem nenhum serviço extra no meio do caminho.
4.2 Como regras de negócio simples e complexas se diferenciam?
Uma regra simples, como “gross_revenue = price × quantity”, agrega uma única tabela. Defina-a como métrica e a IA a seleciona. Já uma regra complexa, como net_revenue = (price × quantity) − tax1 − tax2 − tax3, em que cada imposto vem de outra tabela, não deve ser montada no momento da consulta.
Pré-calcule no dbt: joins e condicionais nos modelos int_, materializados no grão correto em um modelo fato e expostos como métrica pronta pela semantic view.
No nosso projeto, o gap de horas semanais, o gap de feriados e a classificação de horas faturáveis viviam em modelos de rollup do dbt (fct_weekly_hours, fct_quarterly_hours). O papel da semantic view era nomear e governar. Quanto mais pesada a regra, mais cedo você deve materializá-la no dbt. A IA só deve selecionar uma métrica pronta e nomeada, nunca reconstruir uma.
4.3 Você planejou a cobertura de grãos?
Essa foi a lacuna que mais nos custou, e a maioria dos guias de arquitetura nem a menciona. Nossos rollups existiam no grão semanal e no trimestral. No momento em que alguém pediu um resumo mensal por time, a pergunta escorreu até as tabelas brutas de apontamento, com SQL escrito à mão. Ou seja, passou por cima de todas as regras e guardrails que tínhamos construído.
Antes de construir, enumere os grãos e as entidades sobre os quais as pessoas vão perguntar: dia, semana, mês e trimestre; por usuário, por cliente e por projeto. Em seguida, construa um fato para cada grão que você pretende atender. Um grão ausente não é uma camada semântica menor. É um buraco pelo qual a IA escapa.
4.4 Como é o vazamento semântico em uma stack de IA?
Vazamento semântico é a lógica de negócio escapando da camada governada para cópias sem governança. Em BI, isso aparece como fórmulas em planilhas. Em uma stack de IA, a rota de fuga são os prompts e os arquivos do agente. Vimos isso acontecer: quando o nosso resumo mensal não pôde ser expresso na semantic view, o SQL dele foi parar em um documento de skill do agente. Fora do data warehouse, invisível para o BI e sem governança de ninguém.
A regra que adotamos foi simples: toda consulta de contorno vira backlog para um novo modelo ou métrica. Se a IA precisa de SQL sob medida para responder a uma pergunta recorrente, a camada semântica tem uma lacuna. E a correção é um modelo, não um prompt mais longo.
Leia também: Quando tirar seus dados das planilhas?
5. Como as regras de LGPD e PII se aplicam quando a IA consulta seus dados?
A LGPD rege os dados pessoais da mesma forma, seja um humano ou uma IA executando a consulta. A IA não cria exceção e ainda eleva a régua em finalidade, minimização e explicabilidade. O GDPR se aplica em paralelo para titulares de dados na União Europeia, e as ferramentas do Snowflake tratam os dois de modo semelhante.
5.1 Você deve mascarar PII?
Sim. E o mascaramento no nível do data warehouse se aplica automaticamente às consultas de IA. O Snowflake aplica mascaramento dinâmico e baseado em tags, além de políticas de row access e de projeção na camada de dados. Por isso, os Cortex Agents e as consultas às semantic views herdam essas regras: a IA não enxerga dados que o operador humano não pode acessar.
Use mascaramento baseado em tags para que a proteção se propague conforme os datasets crescem, AI_REDACT para PII em texto livre e o Cortex Guard para controles de entrada e saída do LLM.
5.2 Modelo nativo do data warehouse ou modelo local?
Um modelo nativo do data warehouse (Cortex) roda ao lado dos seus dados, dentro do perímetro de governança do Snowflake. Não há movimentação de dados, o RBAC e o mascaramento são herdados e não há treinamento sobre os seus dados. É o caminho mais curto para a conformidade com a LGPD.
Já um modelo local, hospedado por você, transfere todo o peso de conformidade e infraestrutura para o seu time. Só vale a pena diante de requisitos rígidos de residência de dados.
6. Como manter as consultas de IA baratas, pequenas e seguras?
As consultas do Cortex consomem créditos, e um agente sem proteção pode varrer tabelas enormes para responder a uma pergunta de um número só. Dois controles funcionaram para nós. Primeiro, a camada semântica mantém os resultados pequenos por construção: as métricas retornam agregados, então “quantas horas no último trimestre?” devolve uma linha, e não um milhão.
Segundo, um contrato explícito com o agente: uma role somente leitura; limites de linhas (cerca de 20 linhas de detalhe, suficientes para responder e pequenas o bastante para continuar baratas); e descoberta com escopo definido (SHOW … IN DATABASE analytics_db, nunca varreduras em toda a conta). As restrições que mantêm o consumo de créditos previsível também mantêm as respostas confiáveis.
7. O que construir primeiro?
Comece com tabelas silver limpas e nomes previsíveis. Modele as regras de negócio no dbt em todos os grãos sobre os quais as pessoas vão perguntar. Em seguida, exponha tudo por uma única camada semântica, com comentários prescritivos que a IA precisa seguir. Mascare PII na camada de dados, para que a governança viaje junto com cada consulta.
Depois, trate cada pergunta que a camada não consegue responder como um ticket de modelagem. A IA nunca será melhor do que o contrato que você entrega a ela.
Descubra em que ponto a sua organização está no caminho da experimentação com IA até a real transformação do negócio e o que fazer em seguida.
