A maioria das conversas sobre proteção de dados em torno da governação de IA começa no sítio errado. Perguntam que certificações tem um fornecedor, que subcontratantes lista, em que região está a sua cloud. São perguntas legítimas. Mas para a categoria específica de ferramentas que vigiam os seus agentes de IA — descobrindo cada agente, sessão, modelo e servidor MCP na sua infraestrutura e mapeando aquilo que cada um pode alcançar — há uma questão mais fundamental escondida por baixo: a própria ferramenta de governação alguma vez recebe os seus dados?
Se a resposta for sim, acabou de criar um novo subcontratante, uma nova cópia de material sensível, um novo sítio que pode ser violado, intimado judicialmente ou forçado a transmitir dados para o exterior. Se a resposta for não — estruturalmente, por conceção — então a maioria das questões de RGPD a jusante torna-se muito menor. É este o argumento a favor de alojar internamente uma plataforma de IA, e vale a pena fazê-lo com precisão, sem exageros.
A garantia de privacidade que importa é estrutural, não um certificado
Um relatório SOC 2 ou um certificado ISO 27001 dizem-lhe que um fornecedor tem processos em torno dos dados que detém. Isso é útil, mas é uma afirmação sobre a governação do acesso aos seus dados. Uma garantia muito mais forte é não deter os dados, para começar. Não pode vazar, manusear indevidamente nem ser obrigado a divulgar aquilo que nunca recebeu.
Alojar internamente entrega exatamente isso. Quando o plano de controlo corre dentro dos seus próprios hosts, clusters ou clouds — incluindo totalmente air-gapped, sem qualquer egress — o material sensível que observa nunca atravessa o seu perímetro. O fornecedor não é um subcontratante dos seus dados operacionais porque o fornecedor nunca os vê. Isto é um facto arquitetural, não uma promessa de política que tem de auditar.
Para ser claro quanto ao ponto em que este produto se encontra: a Olivares AI está em fase pré-lançamento. Não está certificada ao abrigo do SOC 2, da ISO/IEC 27001, do Regulamento da IA da UE nem de qualquer outro referencial, e não há nenhuma auditoria em curso. O produto está concebido na direção dos objetivos de controlo que esses referenciais examinam — registo de auditoria, controlo de acessos, integridade, cifragem, gestão de alterações — de modo a estar pronto para ser auditado quando chegar a altura. O argumento de residência que se segue não depende de qualquer certificação, e é precisamente esse o ponto.
Arestas, não payloads
A decisão de conceção central é o que fica armazenado. Uma ferramenta de governação de IA tem de perceber quem pode tocar em quê. Não precisa do conteúdo das consultas, dos corpos dos prompts, dos segredos nem dos dados pessoais que circulam por esses contactos.
Por isso, o grafo armazena arestas, não payloads: a relação de acesso entre um agente e um recurso, e se esse acesso é de leitura (R) ou de leitura/escrita (RW). data-export-job → prod-postgres (RW) é uma aresta. As linhas que esse job leu não são armazenadas. O mapa regista que um agente alcançou um objeto em s3://billing-exports; não copia a exportação.
| Armazenado (o mapa de acessos) | Não armazenado |
|---|---|
| Identidade do agente (papel / nome da aplicação) | Valores de credenciais, tokens, chaves |
Recurso alcançado (prod-postgres) | Corpos de consultas, linhas de resultados |
| Tipo de acesso — R ou RW | Payloads de prompts e respostas |
| Timestamp, resultado, nível de confiança | Segredos, PII em trânsito |
Entradas que possam transportar segredos ou dados pessoais são mascaradas e analisadas em busca de segredos antes de qualquer coisa ser escrita, pelo que o mascaramento acontece na fronteira da recolha e não como uma limpeza posterior. Aquilo que não armazena, não pode vazar — e aquilo que não pode vazar não alarga a sua pegada de tratamento ao abrigo do RGPD.
Como os dados permanecem dentro do perímetro
Três propriedades mantêm isto honesto em operação:
Observação read-first. O coletor observa através de sinais que já produz — registos de aplicação e de auditoria, OpenTelemetry, e eBPF como salvaguarda de ground-truth ao nível do kernel. Não é um proxy no caminho de dados do agente, pelo que vê a forma do acesso, não o conteúdo, e se falhar nunca interrompe a produção. Não há nenhum man-in-the-middle obrigatório a copiar o seu tráfego.
Sem telemetria de regresso. Seguro por omissão significa que nada é transmitido para o fornecedor. A telemetria do fornecedor está desligada a menos que a ative explicitamente. Nada sobre o seu estado — nem os nomes dos agentes, nem o mapa de acessos, nem as contagens de utilização — é enviado de volta para o fornecedor por omissão.
Air-gapped com zero egress. Em redes desconectadas, reguladas ou classificadas, o plano de controlo corre inteiramente em local, com o licenciamento validado offline. Não há nenhuma via de saída, ponto final. Para um requisito de residência de dados que diz que os dados da UE têm de permanecer em infraestrutura da UE sob o seu controlo, uma implementação self-hosted air-gapped é a resposta mais literal possível: os dados nunca se movem porque não há para onde se moverem.
A retenção e a purga são configuráveis, pelo que controla durante quanto tempo persiste mesmo o mapa de acessos.
Mapeamento para o Artigo 28.º do RGPD — com honestidade
O Artigo 28.º do RGPD rege a relação responsável pelo tratamento–subcontratante e aquilo que um Acordo de Tratamento de Dados deve abranger. A observação relevante é que, numa implementação self-hosted, a habitual relação fornecedor-como-subcontratante para os seus dados operacionais dissolve-se em grande medida: porque a ferramenta corre na sua infraestrutura e nunca recebe esses dados, na maioria das implementações mantém-se como responsável pelo tratamento e subcontratante dos seus próprios dados dentro do seu próprio ambiente.
Isso não torna um Acordo de Tratamento de Dados inútil. Uma relação comercial continua a beneficiar da formalização de responsabilidades — para a cadeia de fornecimento de software, para o acesso de suporte, para qualquer componente gerido futuro. Um Acordo de Tratamento de Dados ao abrigo do Artigo 28.º está disponível mediante pedido para procurement empresarial. O que muda é o âmbito: não há nenhuma lista de sítios para onde os seus dados pessoais foram enviados, porque nunca foram enviados. É uma conversa muito mais curta e muito mais defensável com um DPO ou uma equipa de procurement do que «confie na nossa lista de subcontratantes».
Este é um argumento estrutural, pelo que deve tratar os limites com a mesma honestidade. Alojar internamente transfere a responsabilidade de residência e tratamento para si; não a remove. Continua a ter de proteger o host, controlar a retenção e governar quem pode ler o mapa de acessos — e esse mapa é, ele próprio, sensível, razão pela qual cada visualização privilegiada do mesmo é auditada e os componentes autenticam-se mutuamente com mutual TLS. O produto reduz a superfície do fornecedor a praticamente zero; não absolve o operador.
A conclusão
Se um regulador, um DPO ou a sua própria equipa de segurança perguntarem «para onde vão os nossos dados quando adotamos esta ferramenta de governação de IA», a resposta mais forte possível é «para lado nenhum — nunca saem, e a ferramenta nunca os vê». Essa resposta vem da arquitetura: execução self-hosted, armazenamento de arestas-não-payloads, mascaramento antes da escrita, sem telemetria de regresso, e operação air-gapped com zero egress. Um certificado pode corroborar um bom processo; não consegue igualar a garantia de dados que nunca foram recebidos.
Se quiser a versão completa e honesta desta postura — incluindo a posição de conformidade ainda-não-certificada e como se encaixa um Acordo de Tratamento de Dados ao abrigo do Artigo 28.º do RGPD — veja /security. Se preferir ler o código que sustenta a afirmação, o produto completo é self-hostable ao abrigo da AGPL-3.0 na página /open-source.