Num artigo recente, «Quando os agentes guardam segredos: o novo perímetro da segurança em IA empresarial», defendi uma tese. A segurança é o novo perímetro da inteligência artificial, IA agêntica. Era teoria. Hoje mostro essa teoria a funcionar num sistema que construí.

Montei um laboratório doméstico onde agentes de IA leem dados reais e o estado de um ambiente vivo. A casa não é o tema. É a fonte. Gera dados em fluxo contínuo, à semelhança dos sistemas transacionais de uma empresa. Serviu para formar uma base de conhecimento sobre a qual o agente trabalha. O tema é a governança de IA. O ponto de partida é simples: estes dados têm valor, logo têm de ser protegidos.

A melhor forma de perceber o valor é ver o agente a trabalhar. Seguem seis pedidos / prompts reais e os resultados que produzem. Os relatórios são gerados a partir dos dados da casa. Podem ver o resumo do projeto aqui.

O risco aparece cedo. Bastou um reinício, ainda na fase de implementação, para uma atualização automática expor ao agente mais de duas centenas de entidades da casa, incluindo comandos críticos. A plataforma decidiu sozinha mostrar o que não devia. Detetei o desvio nos testes, diagnostiquei a causa e fechei a exposição antes do arranque. O sistema nunca chegou a produção com aquela porta aberta. Foi o desenho safety-first a fazer o seu trabalho. A IA agêntica só entra em sistemas reais se a segurança for desenhada desde o primeiro dia.

1. Os dados são o novo petróleo. Em bruto, não valem nada

Os dados são descritos, hoje, como o petróleo do nosso tempo. A comparação ajuda num ponto e engana noutro.

Ajuda porque os dados, tal como o petróleo, têm valor económico, são alvo de roubo e de extorsão, e exigem proteção. Uma casa moderna produz dados a toda a hora. Produção solar, consumos por circuito, eletrodomésticos, câmaras e sensores de vigilância, carregamento de veículos, qualidade da ligação à internet, faturas do fornecedor de energia, etc. Em poucas semanas, o sistema acumulou centenas de milhares de leituras. A maioria desses dados, sem um sítio onde viver, perder-se-ia. As plataformas domésticas guardam o histórico poucos dias.

Engana porque o petróleo bruto tem valor latente. Os dados em bruto, não. Sem qualidade, sem contexto e sem verificação, um número extraído de um documento é ruído. Uma fonte de erro, não de decisão. O valor nasce da refinação. Recolher com fiabilidade. Guardar com soberania. Validar contra fontes independentes.

Há ainda uma diferença que pesa. O petróleo derrama, e limpa-se. Um derrame de dados pessoais ou empresariais não se limpa. Por isso a proteção não é um acrescento. É um requisito de desenho.

2. O método. Segurança desde o desenho, acessos sob controlo

A segurança não foi o último passo. Foi o primeiro requisito. Aqui, segurança tem dois sentidos. Proteger o sistema de quem o ataca, e impedir que o próprio agente cause dano. Cada nova capacidade entrou com o seu controlo e com o seu risco residual assumido.

A ordem importou. Primeiro a memória. Recolher e guardar os dados de forma fiável, em infraestrutura própria. Só depois o acesso. Dar ao agente uma porta estreita e vigiada para esses dados. Quem inverte a ordem dá poder antes de ter controlo.

Os princípios não são novos. Menor privilégio. Segregação de funções. Exposição mínima. Identidade própria para o agente. Auditabilidade. Supervisão humana nas decisões que contam. A novidade está em aplicá-los a um ator que lê, raciocina e propõe ações sobre sistemas reais.

3. Os acessos do agente. Canais separados, menor privilégio

O agente liga-se ao ambiente por dois canais distintos e independentes. Um operacional, que lê o estado atual. Um analítico, que lê o histórico, só de leitura. Separar os canais é uma decisão de segurança. O acesso que vê o presente não partilha credenciais nem caminho de acesso com o que lê o passado.

A cada canal foi dado o mínimo. O canal operacional usa uma conta dedicada, não administradora, limitada a um conjunto curado de entidades. O canal analítico usa um papel só de leitura, em modo restrito, que recusa qualquer escrita.

Um automatismo merece atenção à parte. Para tratar as faturas de energia, um processo lê uma caixa de correio. Ler uma caixa de correio é uma exposição elevada. Guarda correspondência sensível. Por isso o acesso foi desenhado com regras estritas de filtragem por remetente, assunto e tipo de anexo, conta dedicada, palavras-passe e chaves fora do código, e desacoplamento. O processo extrai o anexo para uma pasta de receção. O resto da cadeia trabalha sobre a pasta, nunca sobre a caixa de correio. A lição é geral. Quando uma IA agêntica ou um automatismo toca num canal de comunicação, esse canal passa a ser uma superfície de risco de primeira ordem.

4. Dados com qualidade e Dados não fiáveis. A segunda fonte de verdade

Este é, para mim, o ponto mais importante do artigo.

Um agente que lê um PDF e extrai números faz um trabalho probabilístico, não determinístico. Pode ler mal um valor. Pode trocar um escalão. A tentação é confiar no que ele extraiu. Seria um erro.

O desenho parte do princípio oposto. A extração não é fiável até prova em contrário. A fatura nunca é a sua própria verdade. O documento muda de formato com frequência, e o agente tem de o interpretar, não de o ler em posições fixas. Os kWh que extrai do PDF são conferidos contra duas fontes independentes. As leituras oficiais do operador de rede e o consumo medido em casa, circuito a circuito. Uma rotina determinística, escrita em código e a correr em infraestrutura própria, faz a reconciliação e assinala os desvios. O agente coordena. O código calcula. A pessoa decide.

Um exemplo concreto dá a medida da qualidade. Ao longo de setenta horas, a produção solar (56,4 kWh) cobriu quase todo o consumo da casa (57,2 kWh). A importação de rede ficou perto de 11 kWh, valor confirmado pelas leituras oficiais do operador. Três fontes independentes, o mesmo número. É isto que sustenta uma decisão.

A verificação não se limita às faturas. A ligação à internet é outro caso. O sistema mede o débito e a latência reais e compara-os com o serviço contratado. Quando fica abaixo do prometido, o desvio fica registado, com prova do lado de quem paga. Promessa contratual de um lado, medição independente do outro. A mesma disciplina.

Há uma evidência que me dá ainda mais confiança no sistema. A cozinha ainda não tem medidor próprio. Em vez de inventar um valor para fechar o processo, o agente assinala a lacuna. Um sistema que admite o que não sabe vale mais do que um que estima para agradar, ou, pior, inventa.

A regra é simples. Nunca deixe o mesmo ator (IA Agêntica) ser quem extrai e quem valida. Separe a extração da verificação. Tenha uma segunda fonte de verdade, independente, e uma verificação determinística por cima. Numa empresa, é a diferença entre automatizar com confiança e automatizar um erro à escala.

5. Expor apenas o necessário à IA agêntica

A exposição mínima é a regra que mais protege e a que mais se descura.

Ao agente dá-se acesso apenas ao que ele precisa de usar. O que é acionável e crítico fica de fora. A opção de expor automaticamente novas capacidades fica desligada por defeito.

Esta regra não saiu de um manual. Saiu da prática, e a um custo baixo, porque o problema apareceu no sítio certo. Durante a implementação, antes de o sistema entrar em produção, um reinício levou a plataforma a auto-expor ao agente mais de duas centenas de entidades, incluindo comandos sensíveis. A fase de validação existe justamente para isto. O desvio foi detetado, diagnosticado e corrigido antes do arranque. A exposição tem de ser curada, item a item, e revista sempre que o sistema muda. O que se mostra a um agente é uma decisão, não um automatismo. Apanhar este risco em produção teria sido um incidente grave. Detetá-lo na conceção apenas comprovou a eficácia do planeamento.

6. Onde corre o modelo. Soberania contra custo

Falta a decisão mais difícil e mais cara. Onde deve correr o próprio modelo de IA.

No sistema atual, os dados e os automatismos correm em infraestrutura própria. Só o modelo de IA é um serviço na cloud, acedido através de uma camada de periferia controlada. A escolha mantém os dados em casa, on-premises. Em troca, obriga a desenhar com rigor o que se expõe ao modelo. O modelo vê o que lhe é mostrado, e nada mais. É a aplicação prática da menor exposição à internet. Quanto menos sai de casa, menor a superfície de ataque.

A pergunta seguinte é pertinente. Faz sentido o modelo correr na infraestrutura local, para ter soberania absoluta? A solução exige ponderar o risco, o custo e a viabilidade técnica.

Um modelo on-premises dá soberania completa. Os pedidos e os dados não saem do perímetro. Em troca, exige investimento em hardware, custo de energia e manutenção, e trabalho contínuo de atualização. Hoje, costuma oferecer menos capacidade do que os melhores modelos da cloud, e dificilmente o ROI (retorno do investimento) é positivo.

Um modelo na cloud dá a melhor capacidade com pouco investimento inicial. Em troca, obriga a confiar no fornecedor e a desenhar a periferia com o máximo de cuidado e foco na segurança.

A minha leitura é proporcional ao risco. Para a telemetria de baixa sensibilidade, é adequado e proporcional adotar um modelo na cloud com a periferia controlada. Para dados pessoais, como os de um CV, ou se mantêm fora do caminho do modelo, ou se pondera a sério um modelo on-premises. A decisão não é técnica. É gestão do risco e do custo. A decisão é tomada caso a caso, sendo revista assim que o custo da soberania tecnológica diminuir.

7. O que é transferível para a empresa

O método não depende da escala doméstica. Os mesmos pilares respondem na organização. Construir a base de conhecimento primeiro. Dar ao agente acesso mínimo, por canais segregados. Tratar cada canal de comunicação como superfície sensível. Validar a extração contra uma segunda fonte de verdade. Curar a exposição item a item. Decidir a localização do modelo por risco e por custo. Manter a pessoa no comando.

Projeto, desenvolvo e implemento estes sistemas. Não me limito a comentá-los. A diferença vê-se nos pormenores que só a prática revela. O reinício que expõe o que não devia. O escalão que o modelo lê mal. A caixa de correio que se torna porta de entrada. Estes problemas vivem na base de código e na operação. É aí que as soluções se validam ou falham.

8. A porta seguinte. Marketplaces de IA agêntica

A evolução natural da IA agêntica passa pela criação de catálogos e marketplaces de agentes e conectores. Subscrevem-se e instalam-se como uma aplicação qualquer. O problema desloca-se. Deixa de ser ter agentes e passa a ser necessário orquestrá-los e controlá-los. Quem faz o quê, com que privilégio, sobre que dados e com que rasto.

Nas empresas, isto alimenta dois riscos próximos. O Shadow IT, ou seja, aplicações e serviços de nuvem usados por colaboradores sem aval da direção de sistemas. E o Shadow AI, a utilização não autorizada de ferramentas de IA, como contas pessoais de assistentes públicos ou extensões de código, para tratar informação da empresa.

O protocolo aberto que liga agentes a ferramentas e dados (MCP, Model Context Protocol) é o que torna estes catálogos possíveis. Por isso a governança tem de acompanhar a adoção, logo no início, e não vir depois. Sem orquestração e controlo, um marketplace multiplica a superfície de risco em vez do valor. Fica o tema, talvez, para a próxima peça.

Conclusão

A IA agêntica só entra em sistemas reais se a segurança for desenhada desde o início. O valor não está no agente. Está na qualidade dos dados que ele lê, no controlo do acesso que recebe, e na verificação independente do que produz. A casa foi o laboratório e o gerador de dados. Os mesmos que uma empresa produz e tem de proteger. Os dados foram a matéria-prima. A segurança foi o método. É assim que recomendo a qualquer organização que queira adotar agentes sem abrir mão do controlo.

Pode consultar o caso de estudo completo do Projeto Home, com a arquitetura e exemplos reais.