O que é uma camada de dados confiável para agentes de IA
Acesso, definição, atualidade e procedência, decididos antes da pergunta. Conectar está resolvido; confiar é o que ninguém entregou.
Camada de dados confiável é o conjunto de garantias entre a sua base e o agente de IA, para que uma resposta possa ser reproduzida e defendida, não apenas produzida. A urgência é mensurável: um levantamento de 7.973 servidores MCP remotos ativos encontrou 40,55% expondo ferramentas sem autenticação nenhuma (arXiv 2605.22333, preprint), e o próprio protocolo afirma que “a autorização é OPCIONAL para implementações de MCP” (spec MCP).
Conectar está resolvido. Confiar é a parte que ninguém entregou.
A pergunta de projeto mudou. Não é mais “a IA consegue acessar o dado”. É “quando o número sair errado numa reunião, quem consegue reconstruir de onde ele veio”.
Por que um agente exige mais do que um analista?
Porque o mecanismo de segurança que você vinha usando era a desconfiança humana.
O analista que vê um número estranho hesita, confere a exportação, pergunta ao colega. Essa hesitação fazia trabalho real e nunca esteve escrita em lugar nenhum. O agente não tem equivalente: responde com a coluna que encontrar, com a confiança de sempre, e a resposta errada sai formatada igual à certa.
A exigência, então, muda de natureza. Para uma pessoa, o dado precisa estar disponível. Para um agente, precisa ser autodescritivo, porque não existe um segundo leitor para perceber o que ele omitiu.
Quais são as quatro garantias?
Quatro, e cada ausência falha de um jeito diferente.
| Garantia | A pergunta que responde | O que acontece sem ela |
|---|---|---|
| Acesso | o que este solicitante pode ver? | o agente lê o que ninguém autorizou |
| Definição | o que este número significa? | dois times defendem dois valores |
| Atualidade | de quando é esse dado? | tabela parada responde com a mesma confiança |
| Procedência | de onde veio essa resposta? | ninguém reconstrói o número depois |
As quatro são independentes. Dá para ter acesso impecável e devolver um número que ninguém consegue definir, que é a configuração mais comum na prática, porque acesso tem dono e definição normalmente não tem.
No Brasil há uma quinta dimensão que se encaixa na primeira. A LGPD impõe finalidade, “realização do tratamento para propósitos legítimos, específicos, explícitos e informados ao titular”, e necessidade, “limitação do tratamento ao mínimo necessário” (LGPD). “Conectei o agente à base inteira porque pode ser útil” não sobrevive a esse teste.
O data warehouse já não garante isso?
Garante menos do que a documentação sugere.
Em Snowflake, BigQuery e Redshift, uma chave primária declarada num contrato do dbt é declarável mas não cobrada, e o texto é direto: o modelo “ainda pode ser construído mesmo que construí-lo viole a restrição”, porque a restrição “existe apenas para fins de metadado” (dbt). Em Snowflake e BigQuery, unique nem é declarável.
Segurança em nível de linha é real e falha no papel de conexão: “superusuários e papéis com o atributo BYPASSRLS sempre contornam o sistema de segurança de linha”, e o dono da tabela também contorna sem FORCE ROW LEVEL SECURITY (PostgreSQL).
Ou seja: o banco cobra forma no build e linha na consulta, sob um papel bem configurado. Não cobra significado. Não existe NOT NULL para semântica, e é exatamente essa a garantia de que o agente mais precisa.
E um servidor MCP, não resolve?
Entrega o fio, que é outra coisa.
O protocolo torna a autorização opcional e define a ferramenta como controlada pelo modelo. E manda clientes tratarem as anotações de ferramenta como não confiáveis, a menos que o servidor seja confiável. Lendo junto: a descrição que você escreve não é garantia, e a conexão não é controle.
A evidência de fornecedor aponta na mesma direção. Depois de uma cadeia de ataque documentada, em que um ticket de suporte com instrução plantada levou um agente a ler uma tabela de tokens e devolver o conteúdo onde o atacante recolheria, a orientação pública terminou numa frase que vale guardar: “nunca conecte agentes de IA diretamente a dado de produção” (Supabase, 16/09/2025).
Servidor MCP sobre banco cru é protocolo sem camada embaixo. A camada é o que decide, antes da chamada, quais perguntas existem.
Isso é a mesma coisa que camada semântica?
Não. A camada semântica é uma das quatro garantias.
A distinção importa porque muita gente compra a camada de definição e assume que o resto veio junto. Uma camada semântica decide o que a métrica significa e aplica essa regra de forma consistente, que é a mais difícil de instalar depois e a de maior retorno. Ela não diz nada sobre quem pode consultar, sobre quão velho está o dado por baixo, nem sobre reconstruir a resposta de ontem.
Do mesmo jeito, um contrato de dados cobre forma e compromisso operacional entre quem produz e quem consome. É garantia real, cobrada no build para nome e tipo de coluna, e silenciosa sobre significado por construção.
A consequência prática é de sequência. Quem começa só por acesso ganha uma porta trancada na frente de números indefensáveis. Quem começa só por definição ganha números defensáveis acessíveis a qualquer um. Nenhum dos dois está errado; os dois são parciais, e saber qual metade você tem vale mais que um plano que sugere ter as duas.
Como isso se parece na prática?
Menos superfícies, cada uma mais estreita do que o banco atrás dela.
No lugar de uma ferramenta que roda SQL arbitrário, um punhado de ferramentas que respondem perguntas nomeadas, com esquema de entrada fechado. No lugar de uma tabela de pedidos, um recorte modelado onde receita já significa uma coisa só. No lugar de um número devolvido sozinho, um número devolvido com a definição aplicada, o recorte realmente usado e a atualidade do dado por baixo.
Essa última se paga rápido. Um agente que recebe “receita da semana passada” calcula tranquilamente sobre uma tabela que parou de atualizar na terça, porque do ponto de vista da consulta a tabela parada e a viva são idênticas. Devolver o carimbo de tempo mais recente por trás da resposta custa poucos caracteres e torna visível uma falha que o número esconde.
O ganho colateral costuma surpreender: a lista de ferramentas expostas vira também a lista completa do que o agente pode fazer. Auditoria de escopo deixa de ser raciocínio sobre um plano de consulta e vira leitura de cinco linhas.
Como testar se você tem uma?
Quatro verificações, nenhuma exige orçamento.
Peça a duas pessoas de times diferentes a receita do mês passado, sem dizer por quê. Iguais, existe definição viva em algum lugar. Diferentes, você acabou de medir o custo do problema de graça.
Descubra com que papel o agente se conecta. Não o do documento de arquitetura: o da string de conexão em produção. Papel administrativo ou dono de tabela significa que as políticas de linha não se aplicam a ele.
Plante uma instrução inofensiva num campo de texto que o agente lê e depois faça uma pergunta normal. Se a instrução mudar a resposta, o canal de injeção está aberto.
Pegue a resposta de ontem e tente reproduzi-la. Se você não consegue dizer qual definição, qual recorte e qual versão do dado a produziram, você tem saída sem procedência, que é a coisa mais parecida com confiança e a menos confiável de todas.
O que este artigo não cobre?
Não cita produto. A categoria é nova e o mercado se reorganiza mais rápido do que qualquer comparação permanece verdadeira.
Cita os dois levantamentos como preprints, porque é o que são. Nenhum passou por revisão por pares, e estão aqui pela amostra e pelo método declarados, não pela autoridade de um periódico. O segundo analisou 1.899 servidores MCP de código aberto e encontrou 7,2% com vulnerabilidade geral e 5,5% com envenenamento de ferramenta específico de MCP (arXiv 2506.13538).
Não traz estatística de vazamento em implantações com agente. Os estudos medem exposição de configuração, não incidente consumado, e tratar um como o outro exageraria o que se sabe.
E não resolve injeção indireta, porque nada resolve. Estreitar o que o agente alcança reduz o estrago. Não elimina o vetor, e camada que promete o contrário está vendendo conforto.