Governança de agentes de IA: como controlar identidade, permissões e autonomia?

Resposta direta

Antes de permitir que um agente consulte dados ou execute tarefas, a empresa precisa atribuir um responsável, identificar sua execução, restringir dados e ferramentas, proteger credenciais e definir como autorizar cada classe de ação. Operações de maior impacto exigem aprovação humana vinculada ao que será executado. Registros, limites de consumo, interrupção e recuperação completam o controle. A exigência deve acompanhar o efeito possível, inclusive a exposição de informação em uma consulta.

A posição da G2C é liberar autonomia somente até onde a empresa consegue impor limites e verificar resultados. Instruções escritas para o modelo orientam seu comportamento; permissões e regras aplicadas pelas ferramentas e pelos sistemas de destino determinam o que ele efetivamente pode fazer. Se uma ação proibida continua tecnicamente disponível, a política ainda depende de o agente obedecer.

Recomendar e executar criam compromissos diferentes

Um agente que reúne documentos e sugere uma resposta deixa a decisão e o envio com uma pessoa. Quando recebe a capacidade de enviar, passa a comprometer a empresa diante do destinatário. O mesmo vale para sugerir um ajuste de cadastro e gravá-lo no sistema. A governança precisa identificar a etapa em que uma interpretação se transforma em efeito externo.

Somente leitura também exige proteção. Consultar remunerações ou contratos fora da autorização do solicitante já pode causar exposição, mesmo sem alterar o banco de dados. Uma ferramenta de pesquisa não deve reunir documentos de toda a empresa e confiar ao modelo a decisão sobre o que cada usuário pode ver.

A escolha da abordagem é discutida em chatbot, agente ou automação. Aqui, o critério é o controle da autoridade concedida depois dessa escolha. Um fluxo fixo com uma etapa de IA pode preservar interpretação útil sem delegar ao agente a decisão de executar o compromisso.

Identidade própria precisa permitir atribuição e revogação

Mantenha um cadastro do agente com finalidade, responsável de negócio, responsável técnico, ambientes, fontes de dados e ferramentas autorizadas. A identidade da aplicação ou da carga de trabalho deve permitir distinguir sua atividade da atividade humana e de outras aplicações. Um nome na interface não basta se todas as chamadas chegam ao sistema de destino com a mesma conta administrativa.

Quando o agente atua por solicitação de alguém, registre também quem solicitou e qual autoridade foi delegada. O acesso efetivo deve ficar limitado ao que a aplicação pode fazer, ao que o solicitante pode autorizar e ao escopo da tarefa. Uma delegação para consultar um pedido não deve permitir pesquisar toda a carteira de clientes.

Identidade própria não exige necessariamente uma conta por instância de execução. A solução precisa combinar identidade técnica, identificação do agente e correlação por tarefa, preservando atribuição e isolamento adequados ao risco. Se o legado aceitar apenas uma conta de integração, uma camada intermediária pode restringir as operações e registrar o contexto. O acesso direto a essa conta deve ser bloqueado; a limitação de atribuição no legado continua documentada.

Peça uma demonstração de revogação: ao desabilitar aquele agente, quais caminhos deixam de funcionar e quais credenciais permanecem válidas? A resposta determina se a empresa consegue retirar a autorização sem interromper outras integrações. Compartilhar credenciais entre agentes de finalidades distintas dificulta essa contenção.

Menor privilégio deve alcançar operação, registro e destino

Descreva permissões com verbos e objetos: consultar pedidos de determinada unidade, criar um rascunho de atendimento ou atualizar um campo específico. Expressões como acesso ao CRM escondem diferenças entre ler, exportar, alterar e excluir. Restrinja ainda destinatários, unidades, campos e valores quando essas condições definirem a autorização do processo.

A OWASP, na referência sobre autonomia excessiva, recomenda limitar funcionalidades e privilégios e aplicar autorização nos sistemas que recebem as operações. Para avaliar esse princípio, solicite testes em que o agente tenta acessar outra unidade ou executar uma função não permitida. A evidência útil é a recusa técnica, mesmo quando a solicitação parece convincente.

Ferramentas específicas são mais fáceis de delimitar que um console genérico de comandos. Quando uma tarefa exige apenas abrir uma solicitação, fornecer execução livre de código amplia desnecessariamente a superfície de ação. Para alterações relevantes, separe quem propõe, quem autoriza e o componente que executa. O agente não deve conceder a si próprio permissões, modificar a regra de aprovação ou apagar a própria trilha.

Na comunicação entre agentes, confira novamente identidade, escopo e autorização. Receber uma mensagem de outro agente não prova que a pessoa responsável aprovou a ação. A delegação precisa conservar os limites originais, inclusive quando a tarefa passa por ferramentas ou fornecedores diferentes.

Credenciais e conteúdo consultado precisam de fronteiras distintas

Secrets são senhas, chaves e tokens usados para autenticar integrações. Devem ficar sob custódia de um mecanismo próprio, com acesso restrito, rotação e revogação, sem serem inseridos em instruções, documentos ou conversas. Prefira credenciais temporárias e identidades gerenciadas quando a plataforma e o destino permitirem. A ferramenta usa a credencial para executar; o modelo não precisa receber seu valor.

Um documento, uma mensagem ou o retorno de uma ferramenta pode conter uma instrução maliciosa que tenta desviar a tarefa, situação conhecida como prompt injection. A orientação da Microsoft para risco de agentes recomenda tratar entradas externas como não confiáveis e validar ferramentas e parâmetros fora do modelo. Filtrar texto ajuda em alguns casos, mas não garante que todo desvio será reconhecido.

Restrinja os destinos para os quais informação pode sair, incluindo chamadas externas e anexos. Uma conta com leitura limitada ainda pode vazar o conteúdo que consegue consultar. Memória persistente, arquivos temporários e índices de pesquisa também precisam de separação por contexto, acesso e retenção definidos. A permissão removida na fonte deve ser refletida no caminho de recuperação da informação.

Verifique no contrato e na configuração do fornecedor o tratamento dos dados enviados, a retenção e os acessos de suporte. O nome comercial da solução não demonstra essas condições. Se a empresa não consegue delimitar a circulação de informação sensível, mantenha o uso em um conjunto de dados aprovado até resolver a lacuna.

Aprovação humana deve autorizar uma ação concreta

O aprovador precisa ver objeto, destinatário, valores, alterações e consequência antes do compromisso. A autorização deve valer para aquela operação e por um prazo definido. Se os parâmetros ou o estado relevante mudarem, a proposta precisa voltar à revisão. A OWASP recomenda esse vínculo entre aprovação e ação, com validação independente antes de executar operações de alto impacto.

Considere um exemplo hipotético: um agente prepara um reembolso para um cliente. A aprovação de um valor e de um beneficiário não autoriza o agente a trocar a conta de destino durante uma tentativa posterior. A execução deve conferir o conjunto aprovado e as regras financeiras no sistema. O exemplo ilustra um requisito de controle e não representa um projeto da G2C.

Defina quem pode aprovar, quem substitui essa pessoa e quanto trabalho cabe à revisão. Exibir dezenas de telas sem contexto favorece aceitação automática. Uma aprovação útil destaca o compromisso, a evidência necessária e as exceções. Quando falta aprovador ou a autorização não pode ser validada, a ação relevante deve permanecer pendente, sem presumir consentimento.

Nem toda consulta exige um clique humano. A empresa pode aprovar previamente uma classe de ações de baixo impacto, com escopo, limites e exceções impostos tecnicamente. Isso reduz a fila de revisão, mas exige acompanhar desvios e retirar a autorização quando as condições mudarem. Quanto mais difícil desfazer o efeito, maior deve ser a exigência de controle prévio.

Uma matriz curta para decidir o nível de autonomia

Use a matriz por ação, não apenas por agente. Uma mesma solução pode consultar automaticamente e exigir aprovação para enviar uma mensagem. O responsável do processo aceita o impacto; TI e segurança verificam se os limites são executáveis.

Logs devem comprovar o efeito e permitir intervenção

Relacione solicitação, identidade, versão da configuração, ferramenta chamada, autorização, aprovação e resultado confirmado no destino. Registre também operações negadas e estados pendentes. O relato do modelo de que concluiu uma tarefa não comprova a gravação nem o envio. Uma mensagem de sucesso da ferramenta só sustenta aquilo que o contrato dessa interface efetivamente confirma.

Se a conexão cair depois de uma solicitação de criação, a operação pode ter sido aceita sem devolver confirmação. Repetir pode gerar duplicidade. O sistema deve consultar o estado ou usar um mecanismo de prevenção de duplicatas antes de tentar novamente. Uma execução com etapas incompletas precisa continuar visível como parcial até a reconciliação.

Proteja os registros contra alteração pelo próprio agente e limite sua consulta. Guarde contexto suficiente para investigação sem copiar indiscriminadamente documentos, dados pessoais ou credenciais. Não é necessário armazenar raciocínio interno do modelo para demonstrar uma transação; é necessário preservar decisões de autorização e evidências verificáveis da execução.

Associe alertas de ação fora do padrão, falhas repetidas e consumo anormal a alguém que possa intervir. Defina limites de chamadas, duração, volume e gasto por tarefa e no agregado. Um alerta de orçamento apenas informa; o bloqueio depende de um mecanismo que efetivamente interrompa ou recuse novas operações. Planeje o tratamento das tarefas interrompidas.

Versionar o agente não desfaz o que ele executou

Controle versões de instruções, ferramentas, regras, configurações de modelo e fontes relevantes. Uma mudança no conector pode ampliar autoridade sem alterar a conversa visível. Compare a versão candidata em cenários representativos, inclusive acesso negado, aprovação ausente, instrução maliciosa, repetição e falha parcial. Registre a configuração que chegou à operação e o responsável pelo aceite.

Voltar à versão anterior recupera uma configuração; não recolhe um e-mail enviado nem desfaz automaticamente uma alteração no ERP. Separe rollback do software, restauração de dados e ações compensatórias do processo, como cancelar uma solicitação ou corrigir um lançamento. Cada caminho tem autoridade, prazo e limites próprios. Nem todo efeito será reversível.

A parada deve alcançar novas tarefas, filas, agendamentos, credenciais e ações já em andamento conforme a capacidade de cada sistema. Revogar um token pode não cancelar uma transação que o destino já aceitou. Exercite a interrupção e a reconciliação em ambiente controlado. Quem assume manualmente precisa conhecer o último estado confirmado antes de continuar.

O ciclo termina com desativação: retire permissões e integrações, encerre agendamentos e trate memória e registros conforme a retenção aprovada. A McKinsey inclui entrada, operação e retirada de agentes na governança de ciclo de vida. É uma orientação de gestão, não uma certificação de conformidade ou comprovação de segurança de uma implantação.

Quando liberar, limitar ou adiar a execução

Comece com execução restrita quando a tarefa tiver fronteira clara, efeito compreendido, responsável disponível e mecanismos de recusa e recuperação demonstrados. Para uma PME, um inventário simples e controles nativos bem configurados podem atender melhor que uma nova plataforma de governança sem equipe para operá-la. Ferramentas adicionais fazem sentido diante de lacunas comprovadas de escala, segregação ou rastreabilidade.

Mantenha o agente como recomendador quando a interpretação trouxer valor, mas o destino não permitir limitar a escrita ou confirmar o resultado. Use integração convencional para efetivar a operação aprovada quando as regras forem estáveis. Adie a execução se depender de conta administrativa compartilhada, aprovação genérica ou recuperação ainda desconhecida em processo de alto impacto.

A revisão também tem custo. Compare tempo de conferência, tratamento de exceções, manutenção, consumo e incidentes com o trabalho que a solução pretende reduzir. Se o aprovador precisar refazer toda a análise em cada tarefa, o ganho pode desaparecer. Reduzir o escopo da autonomia pode preservar mais valor do que acrescentar sucessivas camadas de revisão.

Como transformar a política em uma decisão de operação

A frente de Inteligência Artificial ajuda a delimitar o uso e a avaliação. Em Automação de Processos e IA, a autonomia precisa respeitar as aprovações do processo. O trabalho de Desenvolvimento e Integração de Sistemas é relevante para impor esses limites nas interfaces e tratar resultados incompletos. Segurança e governança atravessam essas decisões, com participação do responsável pelos dados e pelo risco.

A empresa precisa conseguir explicar qual autoridade concedeu, demonstrar onde ela é limitada e assumir o processo quando o agente parar. Quando uma dessas capacidades falta, a decisão prudente é reduzir o escopo executável enquanto a lacuna é corrigida.

• Escolha um processo e liste dados, ações e efeitos possíveis. O dono do processo define o impacto tolerável e quais compromissos exigem decisão humana.
• Identifique agente, solicitante, ferramentas e sistemas de destino. TI verifica onde permissões e regras são aplicadas; segurança avalia exposição e segregação.
• Exija evidências de recusa, aprovação específica, confirmação de resultado e interrupção. Use cenários controlados que incluam uma falha parcial e a retomada manual.
• Autorize um escopo delimitado, com responsável, limites e revisão após mudanças. A ampliação depende da evidência de operação, não apenas do desempenho em demonstração.