Inteligência Artificial

Agentes de IA: como limitar o acesso aos sistemas da empresa

Módulo de processamento diante de uma pasta protegida por porta com fechadura e chave controlada por uma mão humana.

Agentes de IA: como limitar o acesso aos sistemas da empresa

Entenda como definir permissões para agentes de IA com ferramentas, separar consulta de alteração e testar limites antes de liberar uma integração empresarial.

André Fonseca
5 min de leitura

Uma empresa quer que a inteligência artificial consulte documentos e prepare uma análise para o gestor. Durante a integração, porém, o agente recebe credenciais que também permitem alterar registros. A tarefa continua sendo de consulta, mas a capacidade de causar mudanças ficou muito maior. Essa diferença entre o que foi pedido e o que o sistema permite fazer precisa ser resolvida na arquitetura.

O recorte deste artigo é a definição de permissões para agentes de IA que utilizam ferramentas empresariais. As fontes foram consultadas em 16 de outubro de 2026. Trata-se de uma orientação prática, não de um anúncio de lançamento.

O que significa chamar uma ferramenta

Tool calling, ou chamada de ferramentas, é o mecanismo pelo qual uma aplicação com IA solicita a execução de funções conectadas a sistemas e dados. A resposta do modelo e o resultado da execução são coisas diferentes: sugerir uma operação não prova que ela foi realizada.

Em seu guia de engenharia publicado em 11 de setembro de 2025, a Anthropic recomenda ferramentas com finalidade clara, descrições cuidadosas e avaliações baseadas em tarefas realistas. A empresa também alerta que um conjunto maior de ferramentas não garante melhores resultados. Consulte o guia original.

Permissão deve ser verificada fora do modelo

A OWASP trata o excesso de funcionalidades, permissões e autonomia como causas de risco em aplicações com modelos de linguagem. Suas recomendações incluem conceder apenas o acesso necessário, aplicar autorização nos sistemas de destino e exigir aprovação humana para ações de alto impacto. Logs e limites de frequência ajudam a conter danos, mas não substituem esses controles. Veja a referência LLM06:2025.

Na prática, escrever “não altere dados” nas instruções do agente não deve ser a única barreira quando a integração permite alterações. O sistema precisa impedir tecnicamente a operação fora do escopo autorizado.

Exemplo hipotético: analisar documentos sem modificá-los

Imagine um assistente interno que prepara um relatório sobre documentos recebidos. Este é um exemplo hipotético de projeto de integração, não uma funcionalidade de IA anunciada para qualquer produto da System4u.

A demanda inicial pode ser descrita assim: consultar documentos de uma empresa em determinado período, identificar quais precisam de conferência e preparar um rascunho. O projeto não precisa começar com acesso administrativo a toda a base.

Uma proposta de implementação seria disponibilizar uma operação de consulta com filtros explícitos e uma operação separada para salvar o rascunho. Excluir documentos, enviar o relatório para terceiros e alterar a classificação original ficariam fora desse primeiro escopo. Os identificadores retornados pela consulta seriam utilizados para referenciar os documentos, sem inventar registros ausentes.

Se a consulta falhar, o assistente deve informar que não conseguiu verificar os dados. Se o rascunho não for salvo, deve apresentar essa pendência. Essa separação torna o resultado operacional verificável e evita confundir uma mensagem convincente com uma tarefa concluída.

O que testar antes de liberar a integração

Para esse cenário hipotético, a equipe pode estabelecer critérios de aceite concretos:

  • Escopo dos dados: uma solicitação com identificador de outra empresa deve ser recusada pelo sistema, mesmo que pareça válida no texto recebido.

  • Ausência de resultado: uma consulta vazia deve gerar uma informação de ausência, não um relatório com documentos inventados.

  • Operação não permitida: um pedido para excluir os originais deve ser bloqueado, pois essa ação não faz parte da tarefa.

  • Falha de gravação: a indisponibilidade ao salvar deve resultar em erro explícito, sem declaração de sucesso.

  • Repetição da solicitação: o comportamento esperado para uma nova tentativa deve ser definido antes de liberar o fluxo, evitando rascunhos duplicados sem necessidade.

O ganho esperado dessa abordagem é tornar a integração mais controlável e auditável. Isso não elimina erros do modelo, falhas de infraestrutura ou a necessidade de revisão. Também pode exigir desenvolvimento adicional para adaptar permissões, respostas e testes ao sistema existente.

Como relacionar a decisão ao negócio

A página institucional da System4u apresenta atuação em desenvolvimento de software, integrações, automação e IA aplicada. Nesse contexto, um projeto de agente deve começar pela pergunta empresarial: qual tarefa precisa ser executada, sobre quais dados e com qual autorização?

Antes de ampliar a autonomia, a gestão pode aprovar um fluxo restrito, testar seus limites e analisar as evidências. O objetivo não é oferecer acesso irrestrito à IA, mas construir uma integração útil cujo comportamento possa ser conferido.

Fontes consultadas

Comentários

Escrever comentário

Seja o primeiro a comentar!