Perguntas à equipa de plataforma onde corre o modelo e respondem-te com uma região: «Frankfurt». Respiras de alívio. Nessa mesma noite, para resolver o caso de um cliente, o agente consulta um CRM na nuvem de um terceiro, chama uma ferramenta de pesquisa externa, faz passar o texto por um servidor MCP que alguém instalou em março e, quando o fornecedor principal satura, volta a tentar noutro modelo, noutra região. Frankfurt era um elo em cinco.
A tese numa linha: a soberania dos dados de um agente não a decide o sítio onde corre o modelo; decide-a cada elo da cadeia que esse agente percorre para fazer o seu trabalho. Um perímetro que só olha para o modelo é um cadeado numa porta com quatro janelas abertas.
Soberania dos dados com agentes de IA: decide-a cada chamada, não o modelo
Um chatbot clássico tinha uma fronteira fácil de desenhar: o utilizador escreve, o modelo responde e o dado vai e volta por um único sítio. Um agente rebenta essa geometria porque age: lê num sistema, escreve noutro, pede ajuda a uma ferramenta, guarda memória. Cada uma destas ações é uma chamada de rede, e cada chamada de rede é uma decisão sobre para onde vai o dado, quem o trata e durante quanto tempo o conserva. «Onde vive o nosso agente?» não tem resposta útil. A que a tem é: «para onde vai cada byte desta execução?»
Se a execução contém dados pessoais, cada destino é, em proteção de dados, um tratamento com o seu fornecedor, o seu contrato de subcontratante e, se sai do Espaço Económico Europeu, a sua base de transferência. Um agente não muda as regras: multiplica os sítios onde é preciso aplicá-las. Já explicámos em IA generativa e RGPD: o que o teu fornecedor não te conta porque é que a etiqueta «enterprise» não é uma garantia; com agentes, o problema deixa de ser um contrato e passa a ser um percurso.
Os cinco elos de uma cadeia de agente e o que sai em cada um
| Elo | O que pode sair | A pergunta que decide |
|---|---|---|
| Modelo principal | O prompt completo: instruções, contexto recuperado e dados do caso | Em que região é processado e conservado, e sob que contrato? |
| Ferramentas e APIs | Os parâmetros de cada chamada: nomes, montantes, identificadores | Que campos recebe realmente a ferramenta e precisa de todos? |
| Servidores MCP e conectores | O que o servidor pedir e o que o agente lhe entregar, por vezes a um terceiro | Quem o opera, onde corre e quem o aprovou? |
| Modelo de reserva | O mesmo pedido reenviado a outro fornecedor ou a outra região quando o principal falha | A tua política permite essa reserva ou ela ativa-se sozinha? |
| Memória, rastos e embeddings | Cópias do dado em vetores, registos e ferramentas de observabilidade | Quem vê os rastos, quanto tempo se conservam e onde vivem? |
O MCP merece uma linha à parte. É o padrão que liga um agente a ferramentas e dados através de servidores, e esses servidores podem ser teus, de um fornecedor ou de um terceiro que alguém instalou por comodidade (explicamos o que é o MCP e porque muda os agentes de empresa). Um servidor remoto recebe tudo o que o agente lhe enviar. Tratá-lo como «um plugin» é tratar um subcontratante ulterior como uma extensão do navegador.
Os dois elos que mais deixam escapar são o quarto e o quinto, pela mesma razão: funcionam quando não os vês. O modelo de reserva é uma rede de segurança útil: o principal devolve um erro, o encaminhador tenta o seguinte da lista e o utilizador não repara em nada. A tua política de dados também não, ela que dizia «só região UE» e acabou de enviar o mesmo prompt para outra. Os rastos são igualmente silenciosos: a ferramenta que te ajuda a depurar guarda, se não a configuraste de propósito, uma cópia literal de cada conversa.
E o quadro legal das transferências? Também não é uma constante
Parte da resposta a «posso enviar isto a um fornecedor norte-americano?» assenta no Quadro de Privacidade de Dados UE-EUA. O Tribunal Geral da UE confirmou a sua validade a 3 de setembro de 2025, ao rejeitar o recurso de Philippe Latombe, e Latombe recorreu para o Tribunal de Justiça a 31 de outubro de 2025 (fonte: WilmerHale, dezembro de 2025). Âmbito: direito da UE; importa para dados pessoais que saem do EEE para empresas norte-americanas certificadas e não se extrapola para outros regimes.
Como auditar a soberania de um agente sem equipa de plataforma
Não é preciso um projeto de seis meses. É preciso uma execução real e uma hora:
- Pega num pedido real, dos que levam dados de cliente, e executa-o com o registo de rede ou os rastos do agente ativos.
- Anota cada destino para onde sai tráfego: domínio, fornecedor e região, se a souberes. O normal é saírem mais do que esperavas.
- Marca os que levam dados pessoais ou confidenciais e, para cada um, escreve três coisas: contrato, região e prazo de conservação. Onde não souberes preencher uma, esse é o teu achado.
- Decide por elo: cortar, minimizar (enviar só os campos necessários), pseudonimizar antes de sair ou mudar de fornecedor.
- Deixa o resultado como mapa vivo: uma página com os destinos aprovados. Qualquer elo novo — uma ferramenta, um servidor MCP, uma reserva — entra no mapa antes de entrar em produção.
Duas peças tornam isto mais fácil do que parece. A primeira são as permissões de um agente de IA: um agente com identidade própria e âmbito por tarefa já limita que dados chegam a cada ferramenta. A segunda é escolher que modelo usar num agente com a região e o contrato em cima da mesa, e não só a precisão. E se a tua resposta a «alojamos nós?» for sim, lê antes quando compensa o self-host e o que resolve de facto: alojar o motor não fecha os outros quatro elos.
Quando o mapa tem mais destinos do que a tua equipa consegue rever, é trabalho de governação de dados, e a parte que demonstra o que aconteceu em cada execução é a rastreabilidade das decisões de IA.
Quando não é preciso tanto
Se o teu agente só toca em informação pública ou não pessoal — um que resume documentação aberta, por exemplo — e não escreve em nenhum sistema, o mapa de cinco elos é excessivo: basta saber que fornecedor o executa. E alojar tudo em casa não é uma solução automática: um modelo na tua infraestrutura que entrega o dado completo a uma ferramenta externa continua a ter a fuga; só mudou de elo. Tudo isto é critério operacional, não aconselhamento jurídico: a base legal de cada transferência valida-a o teu encarregado de proteção de dados ou o teu consultor.
A frase para levar: não perguntes onde corre o modelo, pergunta para onde vai cada chamada. A primeira pergunta tem uma resposta cómoda. A segunda tem uma lista, e é essa lista que tens de poder mostrar.