Memória, habilidade e permissão não podem ser a mesma coisa em um agente de IA

O agente corporativo começa a ganhar fronteiras

Em 24 de setembro de 2026, durante o Google Cloud Summit Brasil, o Google anunciou recursos que tratam agentes corporativos como sistemas formados por partes governáveis. Projects restringe a memória aos arquivos e conversas definidos por uma equipe. Skill Registry organiza instruções, scripts e recursos reutilizáveis. Agent Sandbox cria um ambiente controlado para testes antes da produção. Agent Identity, Agent Gateway e Auth Manager cuidam de identidade, acesso e credenciais.

A relevância não está apenas na lista de produtos. A combinação indica uma mudança de arquitetura. Um agente não deve receber contexto, procedimento e autoridade como se fossem uma única coisa. Saber sobre um contrato não significa poder alterá-lo. Conhecer o processo de reembolso não significa estar autorizado a pagar. Executar corretamente em um teste não significa estar pronto para agir no sistema real.

Empresas que ignoram essas diferenças constroem uma automação difícil de explicar e de conter. Quando tudo fica embutido em um prompt, em uma conta técnica ampla ou em uma conexão permanente, qualquer atualização pode mudar mais do que o esperado. A maturidade aparece quando cada camada tem finalidade, responsável, versão e limite próprios.

Memória responde ao que o agente pode considerar

Memória reúne o contexto que ajuda o agente a compreender uma tarefa. Pode incluir documentos, conversas, preferências, decisões anteriores e o estado de um processo. Essa camada melhora continuidade, mas também amplia o que o sistema consegue inferir. Por isso, precisa ser delimitada pelo trabalho que está sendo realizado, não pela conveniência de conectar tudo.

O recurso Projects anunciado no Brasil representa essa lógica ao manter arquivos, conversas e estado dentro de um espaço específico. Para uma empresa, o princípio é mais importante do que o produto: cada projeto deveria carregar apenas o contexto necessário à sua finalidade. Um agente de compras não precisa herdar a memória de recursos humanos. Um fluxo jurídico não precisa absorver conversas comerciais sem justificativa.

Também é preciso separar lembrar de aprender. Registrar uma decisão para dar continuidade a um caso é diferente de reutilizar esse conteúdo em outros processos. A política deve esclarecer origem, validade, retenção e possibilidade de correção. Memória útil não é uma coleção infinita. É contexto selecionado, documentado e revisável.

Habilidade descreve como o trabalho deve ser feito

Uma habilidade reúne instruções, recursos e procedimentos para executar uma tarefa especializada. O Skill Registry apresentado pelo Google propõe uma biblioteca compartilhada desses pacotes. Na prática, isso permite retirar conhecimento operacional de conversas dispersas e tratá-lo como um ativo que pode ser revisado, versionado e reutilizado.

A habilidade deveria explicar etapas, fontes, critérios de qualidade, condições de recusa e pontos de aprovação. Ela não deveria transportar, por conta própria, a autorização para agir. Um pacote pode ensinar como preparar um pedido de compra e ainda depender de uma permissão separada para registrá-lo. Essa divisão impede que atualizar o método amplie silenciosamente o poder do agente.

Versionar habilidades também preserva explicabilidade. Quando um resultado é contestado, a empresa precisa saber qual procedimento orientou a execução naquele momento. Sem essa informação, uma correção atual pode apagar a trilha do passado. Com versões e responsáveis definidos, o aprendizado melhora o processo sem destruir a capacidade de reconstruir decisões.

Permissão define o que o agente pode realmente fazer

Permissão é a fronteira entre produzir uma recomendação e modificar o mundo. Ler um calendário, enviar uma mensagem, consultar uma base, criar um ticket, alterar um cadastro e aprovar um pagamento são ações com consequências diferentes. Elas não deveriam chegar juntas apenas porque o agente usa a mesma interface ou atende à mesma pessoa.

O princípio do menor privilégio recomenda conceder somente o acesso necessário para uma tarefa. Para agentes, isso precisa considerar operação, recurso, duração e condição. Um agente pode ter permissão para preparar uma alteração, mas não para confirmá-la. Pode acessar um conjunto de dados durante um atendimento e perder esse acesso ao término do caso.

A autorização deve existir fora do raciocínio do modelo. Instruir a IA a não realizar uma ação sensível não substitui um controle que bloqueie tecnicamente essa ação. O modelo pode interpretar mal contexto, receber conteúdo adverso ou escolher uma ferramenta inadequada. A barreira confiável é aquela que continua funcionando mesmo quando a resposta gerada está errada.

Identidade própria torna o agente visível para a empresa

A documentação do Google descreve Agent Identity como uma identidade criptográfica individual, vinculada ao ciclo de vida do agente. Essa identidade permite aplicar políticas de acesso e registrar atividade sem esconder a automação atrás de uma conta técnica genérica. Para governança, a diferença é decisiva: a organização passa a reconhecer quem agiu, mesmo quando esse participante não é humano.

Compartilhar uma credencial entre vários agentes impede atribuição precisa. Também torna difícil reduzir acesso de um fluxo sem afetar outros. Com identidades separadas, cada agente pode receber permissões compatíveis com sua finalidade, aparecer nos registros e ser desativado quando deixa de existir. O inventário deixa de listar apenas aplicações e passa a incluir atores automatizados.

Identidade não transforma uma ação em legítima por si só. Ela cria a base para autenticação, autorização e responsabilização. A empresa ainda precisa decidir quem criou o agente, quem o mantém, em nome de quem ele atua e que pessoa responde pelo resultado. Dar nome técnico ao agente não elimina a necessidade de dono institucional.

Agir como agente não é o mesmo que agir em nome do usuário

A documentação oficial distingue situações em que o agente usa sua própria autoridade daquelas em que atua em nome de uma pessoa. No primeiro caso, a organização concede uma capacidade diretamente ao sistema. No segundo, existe uma delegação ligada ao usuário e ao contexto. Misturar esses modelos cria confusão sobre consentimento e responsabilidade.

Um agente de monitoramento pode consultar sinais operacionais com identidade própria. Já um assistente que agenda uma reunião ou envia um documento pode precisar agir em nome de alguém. A autorização delegada deve permanecer limitada ao objetivo apresentado. O fato de uma pessoa conseguir acessar uma informação não significa que todo agente usado por ela deva receber o mesmo alcance.

Essa separação também melhora os registros. Em fluxos delegados, é importante preservar a identidade do usuário e a do agente. Assim, uma auditoria consegue distinguir quem solicitou, que sistema executou e qual política permitiu a ação. A rastreabilidade deixa de atribuir tudo à conta humana e passa a mostrar a cadeia completa.

O sandbox testa capacidade sem antecipar autoridade

Agent Sandbox foi apresentado como ambiente controlado para testar agentes antes da produção. A ideia responde a um risco comum: equipes avaliam um agente diretamente sobre sistemas reais porque precisam observar o fluxo completo. O teste se torna uma implantação prematura, com dados verdadeiros, credenciais amplas e possibilidade de efeitos difíceis de reverter.

Um bom ambiente isolado oferece dados representativos protegidos, ferramentas simuladas, limites de rede e registros detalhados. Ele permite observar como o agente reage a instruções ambíguas, documentos malformados, indisponibilidade, tentativas de desvio e situações em que deveria pedir ajuda. O objetivo não é apenas confirmar o caminho esperado, mas descobrir como o sistema falha.

A aprovação para produção precisa comparar evidências com critérios definidos antes do teste. Quais ações foram concluídas? Em quais o agente excedeu o escopo? Que informações tentou acessar? Quando recusou corretamente? A passagem para o ambiente real deve conceder permissões de maneira gradual. Capacidade demonstrada não justifica autoridade ilimitada.

O gateway aplica regras no momento da ação

O Google descreve Agent Gateway como a camada que fiscaliza conexões entre agentes, ferramentas e destinos. Essa posição arquitetural permite aplicar políticas quando uma ação é solicitada. A regra não depende apenas da intenção declarada no início da conversa, porque cada chamada pode ser avaliada segundo identidade, operação, recurso e contexto.

Para a empresa, o gateway funciona como ponto de controle e observação. Pode negar um destino não autorizado, exigir aprovação para uma operação sensível e registrar a tentativa. Também reduz a necessidade de distribuir credenciais diretamente ao agente. Segundo a documentação do Google, o Auth Manager pode manter credenciais do usuário protegidas e disponibilizá-las no ponto de controle sem expor o segredo ao modelo.

Essa arquitetura não elimina erros de negócio. Uma ação tecnicamente permitida ainda pode ser inadequada para o cliente ou contrariar uma política interna. Por isso, controles de acesso precisam conviver com validação de finalidade, limites de valor, revisão humana e possibilidade de contestação. Segurança responde se o agente pode. Governança também pergunta se ele deve.

O ciclo de vida precisa incluir retirada e revogação

Agentes não permanecem estáticos. Mudam de modelo, habilidade, base de conhecimento, proprietário e sistema conectado. Cada alteração pode modificar risco mesmo quando o nome do agente permanece igual. A empresa precisa tratar essas mudanças como versões verificáveis e decidir quais exigem novo teste, nova aprovação ou redução temporária de acesso.

O encerramento também faz parte da arquitetura. Quando um projeto termina, memórias precisam seguir a política de retenção, habilidades devem ser arquivadas ou transferidas e permissões precisam ser revogadas. Uma identidade vinculada ao ciclo de vida do agente facilita essa limpeza. Contas compartilhadas e tokens permanentes deixam rastros que continuam válidos depois que ninguém se lembra de sua finalidade.

O projeto do NIST sobre identidade e autorização de agentes destaca que sistemas capazes de decidir e agir com supervisão limitada aumentam escala e alcance das operações. Isso torna inventário, autenticação e autorização condições para adoção, não detalhes posteriores. Um agente sem processo de retirada é uma dependência permanente criada por acidente.

Um roteiro para separar as camadas antes de produzir

O primeiro passo é descrever a tarefa sem começar pelo modelo. A equipe identifica contexto necessário, procedimento esperado, ações possíveis, consequências e pessoa responsável. Em seguida, distribui esses elementos: documentos entram na memória apropriada, regras formam uma habilidade versionada e cada ação recebe uma permissão explícita.

O segundo passo é criar identidade própria e testar em ambiente isolado. Casos normais e adversos precisam mostrar o que o agente consultou, que habilidade carregou e que tentativa de ação realizou. As evidências sustentam uma liberação progressiva. A produção começa com escopo pequeno, limites rígidos e aprovação humana nos pontos em que o custo do erro é maior.

Por fim, a organização mantém observação e revisão. Registros conectam usuário, agente, habilidade, memória e operação. Mudanças relevantes disparam novos testes. Permissões sem uso são removidas. Incidentes e recusas alimentam a melhoria dos procedimentos. A arquitetura permanece compreensível mesmo quando a automação cresce.

Conclusão

Os anúncios do Google Cloud Summit Brasil mostram que agentes corporativos estão deixando de ser apenas uma conversa ligada a ferramentas. Eles passam a exigir memória delimitada, procedimentos administráveis, ambiente de teste, identidade própria e autorização aplicada no momento da ação. Essa separação torna a automação mais legível para quem precisa governá-la.

A empresa não deveria perguntar apenas se o agente consegue concluir um fluxo. Precisa saber que contexto ele considerou, qual procedimento orientou a decisão, em nome de quem atuou e que barreira impediria uma ação fora do escopo. Quando essas respostas dependem de um único prompt ou de uma credencial ampla, o sistema ainda não está pronto para receber confiança operacional.

Na minha visão, autonomia empresarial não é permitir que um agente faça tudo sozinho. É construir fronteiras tão claras que a organização consiga ampliar capacidade sem perder a autoria das decisões. Memória ajuda a compreender, habilidade orienta a executar e permissão define o limite. Misturar as três cria poder opaco. Separá-las cria responsabilidade.

IA com propósito não transforma acesso em autoridade por conveniência. Ela concede contexto, método e ação na medida necessária, preserva evidências e mantém pessoas capazes de compreender, interromper e corrigir o sistema.