Superinteligência e segurança de dados: o que revisar agora

Superinteligência e segurança de dados se encontram em uma pergunta prática: o que o modelo pode ler, o que pode fazer e o que fica registrado. Antes de dar mais autonomia a modelos mais capazes, revise permissões por identidade, separação entre ambientes e dados, e logs que permitam reconstruir cada decisão. Nada disso depende de a superinteligência existir. Depende de tratar o modelo como um usuário poderoso e pouco previsível.

Principais pontos

• Autonomia maior exige permissões menores e mais explícitas: o agente recebe só o acesso que o fluxo piloto precisa, não o que seria conveniente.
• Segregação vale para dados, ambientes, credenciais e até para o que entra no contexto do modelo.
• Registro bom responde quatro perguntas: quem pediu, o que o modelo viu, o que ele fez e quem aprovou.
• Ferramentas, conectores e textos externos são a principal porta de entrada de comportamento indesejado, mais do que o modelo em si.
• Ampliar a autonomia é uma decisão com critério de parada, não um efeito colateral de o modelo ter ficado melhor.

Por que falar de superinteligência agora, se ela é hipotética?

É útil separar três camadas. A primeira é o que a documentação oficial descreve: modelos atuais seguem instruções, chamam ferramentas e podem errar ou ser induzidos a erro. A segunda é a experiência de implementação: o risco real em empresas costuma vir de permissões largas demais, dados misturados e falta de registro, não de uma máquina com intenções próprias. A terceira é hipótese: se modelos futuros forem muito mais capazes, controles frouxos hoje se tornarão problemas maiores amanhã.

Você não precisa decidir se a superinteligência vai chegar para agir. Basta aceitar que a capacidade dos modelos tende a crescer e que o custo de apertar controles depois de dar autonomia é maior do que o de projetá-los antes. Para uma visão mais clara do que é e do que não é esse tema, vale ler mitos sobre superinteligência que atrapalham decisões na empresa.

A base conceitual é conhecida. O NIST AI Risk Management Framework organiza a gestão de risco de IA em torno de governar, mapear, medir e gerenciar. É um bom vocabulário comum para conversar com jurídico, TI e diretoria.

Como revisar os controles de acesso de um agente de IA?

O ponto de partida é uma regra simples: o agente não é uma pessoa, mas deve ter identidade própria, com permissões próprias. Compartilhar o login de um funcionário com o agente apaga a trilha de responsabilidade e herda acessos que ninguém revisou. O guia de autorização do OWASP trata de princípios que se aplicam aqui: negar por padrão, aplicar o menor privilégio e validar a permissão em cada requisição, não só na entrada.

Uma checklist de revisão:

• Cada agente tem uma conta de serviço própria, nomeada pelo fluxo que atende.
• As permissões são de leitura por padrão. Escrita, envio e exclusão são concedidos ação por ação.
• O acesso a dados depende de quem está sendo atendido, não só de quem é o agente. Um agente que atende o cliente A não deve conseguir consultar o cliente B.
• Credenciais ficam em um cofre, com prazo de validade e rotação, nunca dentro de prompt ou de planilha.
• Ações irreversíveis (pagamento, cancelamento, envio em massa, exclusão) exigem aprovação humana registrada.
• Existe um responsável nomeado por cada agente, com poder de desligá-lo.
• Toda permissão tem data de revisão. Permissão sem revisão tende a virar permanente.

A pergunta de fundo é: se este agente for induzido a fazer a pior ação que suas permissões permitem, o que acontece? Se a resposta incomoda, reduza o acesso antes de aumentar a autonomia.

O que precisa ficar segregado?

Segregar é impedir que um erro em uma parte contamine as outras. Em projetos com IA, a separação costuma falhar em quatro lugares.

• Ambientes: teste, homologação e produção com dados e credenciais distintos. Agente em teste não deve enxergar dado real de cliente. Para isso, como testar agente de IA com mocks e sandbox sem risco mostra um caminho concreto.
• Dados por finalidade: o que serve ao atendimento não precisa estar no mesmo índice que dados de RH, financeiro ou saúde. Misturar tudo em uma base única de busca é conveniente e perigoso.
• Contexto do modelo: o que entra na conversa fica disponível para o modelo naquela interação. Coloque no contexto só o necessário para a tarefa, e filtre campos sensíveis antes, não depois.
• Fornecedores e regiões: saiba para onde os dados vão quando chamam um modelo hospedado fora do país. A LGPD tem regras sobre transferência internacional, e o artigo sobre transferência internacional de dados com IA e o que a LGPD exige detalha o que verificar.

Se a política da empresa exigir que certos dados nunca saiam da sua infraestrutura, a separação pode incluir um modelo rodando localmente para essas tarefas. É uma decisão de arquitetura, não um selo de segurança: modelo local também precisa de acesso restrito e registro.

Que registro é suficiente para reconstruir uma decisão?

Log de erro não basta. O objetivo é poder responder, semanas depois, por que o agente fez o que fez. Isso interessa à segurança, ao atendimento de um titular de dados que pede explicações e a qualquer auditoria interna. Os conceitos de observabilidade do OpenTelemetry (rastros, métricas e logs correlacionados) ajudam a estruturar isso sem inventar formato próprio.

O que registrar, em cada interação relevante:

• Identidade de quem iniciou o pedido e identidade do agente que executou.
• Versão do prompt, do modelo e das ferramentas habilitadas naquele momento.
• Fontes consultadas (documentos, registros, páginas), com referência e não necessariamente o conteúdo completo.
• Ferramentas chamadas, com parâmetros e resultado.
• Decisão tomada, motivo resumido e, quando houver, aprovação humana com identificação de quem aprovou.
• Data e hora, sempre com o mesmo fuso.

Há um cuidado: o log também é dado. Se ele guarda o texto integral das conversas, passa a conter dados pessoais e precisa de prazo de retenção, acesso restrito e mascaramento de campos sensíveis. Registro excessivo cria o problema que deveria ajudar a resolver.

Ferramentas, conectores e textos externos: onde mora o risco?

Quando o modelo ganha ferramentas, a superfície de ataque passa a incluir tudo que ele lê. Um e-mail, um PDF ou uma página web pode conter instruções escondidas que tentam desviar o comportamento do agente. O OWASP mantém material específico sobre isso: o Top 10 para aplicações com LLM e um guia de prevenção de prompt injection. Vale que a equipe técnica os leia e os use como roteiro de revisão.

Na prática, três perguntas orientam a revisão:

• Quais fontes o agente lê que não são controladas pela empresa? Trate todo conteúdo externo como não confiável.
• Quais ferramentas o agente pode chamar depois de ler esse conteúdo? Quanto maior o poder da ferramenta, mais a chamada deve depender de aprovação.
• Qual é o pior efeito possível de uma chamada indevida, e ele é reversível?

Se você usa o Model Context Protocol para conectar ferramentas, o escopo importa. Em configurar MCP no Claude Code: escopos local, projeto e usuário explicamos como limitar onde cada conexão vale. Para quem expõe um gateway de agentes, o checklist de segurança do OpenClaw Gateway trata de evidência antes de exposição.

Em que ordem revisar antes de ampliar a autonomia?

Um plano em etapas evita a revisão genérica que ninguém termina.

• Etapa um, inventário: liste cada agente, modelo, ferramenta, base de dados e credencial em uso, inclusive os que surgiram informalmente em equipes.
• Etapa dois, classificação: marque quais dados são pessoais, sensíveis, financeiros ou sigilosos, e quais fluxos tocam neles.
• Etapa três, redução: remova acessos que o fluxo não usa. Troque escrita por leitura onde for possível.
• Etapa quatro, segregação: separe ambientes, índices de busca e credenciais por finalidade.
• Etapa cinco, registro: implemente o conjunto mínimo de logs acima e defina prazo de retenção com o jurídico.
• Etapa seis, aprovação humana: defina quais ações exigem confirmação e quem confirma, com substituto para ausências.
• Etapa sete, teste adversarial: simule instruções maliciosas em conteúdo externo e verifique se os limites seguram.
• Etapa oito, decisão: com os logs de um piloto, decida entre expandir, ajustar ou parar.

Esse roteiro segue o método que usamos: mapear o processo atual e a linha de base, limitar dados e ações, pilotar um fluxo real com logs e uma métrica de sucesso combinada, e transferir a operação para quem vai mantê-la. A decisão de expandir só vem depois, com evidência do piloto. Quando a empresa prefere não operar sozinha, a operação gerenciada pode ser feita pela Be Human, com as mesmas regras de limite e registro.

Cenário ilustrativo: um agente de WhatsApp pedindo mais autonomia

Imagine, como cenário ilustrativo, uma empresa de serviços com um agente no WhatsApp que hoje responde dúvidas e consulta o status de pedidos. A área comercial pede que ele também conceda descontos, altere cadastros e envie mensagens ativas.

Antes de aceitar, a revisão faria o seguinte. Primeiro, separar a consulta de status (leitura) da alteração de cadastro (escrita) em credenciais distintas. Segundo, limitar a consulta ao cliente que está na conversa, validando o número de origem. Terceiro, tratar o desconto como ação com teto e aprovação humana acima dele. Quarto, registrar cada alteração com o texto do cliente que a motivou. Quinto, para mensagens ativas, exigir permissão prévia do contato, conforme o artigo sobre opt-in no WhatsApp.

O resultado esperado não é dizer não ao comercial. É conceder autonomia por degraus, cada um com um registro que permita voltar atrás.

Autonomia é um privilégio concedido por evidência, não um recurso que vem de fábrica.

Perguntas frequentes

Preciso esperar uma superinteligência para me preocupar com segurança de dados em IA? Não. Os riscos mais prováveis hoje são permissões amplas, dados misturados e falta de registro, e todos já existem com modelos atuais. Apertar esses controles agora também prepara a empresa para modelos mais capazes.

A LGPD muda alguma coisa quando o agente tem mais autonomia? Os princípios são os mesmos: finalidade, necessidade, segurança e transparência. O que cresce é o cuidado com decisões automatizadas e com a capacidade de explicar o que foi feito com os dados de uma pessoa. Consulte o jurídico e acompanhe as orientações da ANPD para o seu caso.

Modelo local é mais seguro do que um modelo hospedado por terceiros? Depende dos dados e do controle que você consegue operar. Ele reduz a dependência de um fornecedor externo, mas exige gestão de acesso, atualização e registro por conta da empresa. A escolha deve vir da classificação dos dados, não de uma regra geral.

Quando é seguro dar mais autonomia a um agente? Quando o piloto mostrou, com logs, que ele respeita os limites, a métrica combinada foi atingida e existe um responsável com poder de desligá-lo. Se algum desses itens faltar, ajuste antes de expandir. Parar também é uma decisão legítima.

Fontes

• NIST: AI Risk Management Framework
• OWASP: Top 10 for LLM Applications
• OWASP: Authorization Cheat Sheet
• OpenTelemetry: observability concepts