Quais configurações do agente de IA o dono do negócio deve controlar

O dono do negócio deve controlar as configurações que definem o que o agente de IA pode fazer, o que ele pode ver, quem aprova suas ações e quanto ele pode gastar. As escolhas técnicas, como a forma de indexar documentos ou de repetir requisições que falharam, podem ficar com o fornecedor, desde que respeitem esses limites e que qualquer mudança que os toque seja informada. Um teste simples: se uma configuração errada mudaria quem vê os seus dados, o que você promete aos clientes ou o que você paga, a decisão é sua.

Principais pontos

• As decisões sobre autoridade (ações, aprovações, gastos, promessas externas) e sobre exposição (acesso a dados, canais, retenção) pertencem ao negócio.
• As decisões sobre mecânica (indexação, novas tentativas, cache, formato de logs, desenho das ferramentas) podem ficar com o fornecedor, dentro dos limites que você define.
• Algumas escolhas parecem técnicas, mas alteram o seu risco, como trocar o modelo de base ou ampliar o que o agente memoriza. Trate essas escolhas como decisões de negócio.
• Registre o limite por escrito, indique um responsável por configuração e exija que o fornecedor comunique qualquer mudança que toque o lado do negócio.
• Revise as configurações em intervalos definidos, porque o acesso do agente costuma crescer sem alarde.

Por que a divisão entre configurações de negócio e técnicas importa?

A maioria dos documentos de implantação de agentes mistura os dois tipos de configuração em uma lista longa. Diante dela, o dono costuma cair em um de dois erros. Ele tenta aprovar tudo, o que é lento e o coloca em conversas para as quais não tem contexto. Ou não aprova nada e deixa o fornecedor decidir, o que faz a responsabilidade perante clientes, funcionários e órgãos reguladores recair sobre quem não pode assumi-la.

O fornecedor pode construir e operar o sistema. Ele não pode responder ao seu cliente quando o agente promete um reembolso, nem ao seu regulador quando dados pessoais chegam ao lugar errado. Por isso o modelo de responsabilidade compartilhada é importante: ele define de antemão quem carrega cada risco. Referências como o NIST AI Risk Management Framework também tratam a governança como uma função da organização, e não apenas da engenharia.

O objetivo prático é ter uma lista curta de configurações que são suas, escrita em linguagem simples, e uma autorização clara para o fornecedor cuidar de todo o resto sem precisar perguntar a cada vez.

Quais configurações pertencem ao negócio?

Essas configurações definem autoridade e exposição. Cada uma responde a uma pergunta que só a empresa pode responder.

• Papel e finalidade: para que o agente serve e para o que ele explicitamente não serve. Um agente de suporte que começa a negociar preços saiu do seu papel, qualquer que seja a capacidade do modelo.
• Limites de aprovação: quais ações o agente pode executar sozinho, quais exigem a aprovação de uma pessoa indicada e o que acontece quando essa pessoa não está disponível. O padrão para tudo o que for irreversível ou externo deve ser a aprovação.
• Escopo de dados: quais sistemas e pastas o agente pode ler, em quais pode escrever e quais estão fora do alcance. Isso inclui definir se dados pessoais, financeiros ou contratuais entram no escopo.
• Permissões e identidade: as contas que o agente usa, o que cada conta pode fazer e quem pode conceder mais acesso. O princípio do menor privilégio, descrito na orientação de autorização da OWASP, vale para agentes tanto quanto para pessoas.
• Canais: onde o agente fala e com quem. Um chat interno expõe a empresa de forma muito diferente de um e-mail para clientes.
• Limites de gasto: o teto de custo de uso, os níveis de alerta e quem é avisado. Uma configuração prática está em limites de gasto e alertas em agentes de IA.
• Compromissos externos: o que o agente pode dizer sobre preços, prazos, reembolsos, termos jurídicos e orientações médicas ou financeiras.
• Retenção e treinamento: por quanto tempo conversas e memória são guardadas e se algum fornecedor pode usar seus dados para treinar modelos. Peça a resposta por escrito.
• Critérios de sucesso e de parada: a medida observável que mostra que o agente está cumprindo sua função e a condição em que ele é pausado.
• Titularidade das contas: quem é o titular das contas de modelo, das chaves e do ambiente de trabalho, e o que você consegue exportar se a relação terminar.

Nenhuma dessas decisões exige conhecimento técnico. Exigem conhecer o seu negócio, os seus clientes e as suas obrigações.

Quais escolhas o fornecedor pode fazer por você?

Essas configurações mudam o quanto o agente funciona bem, não o que ele tem permissão para fazer. Um fornecedor competente deve tomá-las sem reunião, documentá-las e testar o resultado.

• Desenho da recuperação de informações: como os documentos são divididos, indexados e pesquisados para que o agente encontre o trecho certo.
• Estrutura de prompt e de contexto: como instruções, memória e material recuperado são organizados a cada requisição.
• Desenho das ferramentas: como cada ferramenta é descrita e quais entradas aceita, para que o agente a use corretamente. A orientação de engenharia da Anthropic sobre como construir agentes eficazes mostra quanto da qualidade vem desse tipo de detalhe.
• Mecânica de confiabilidade: novas tentativas, tempos limite, proteção contra duplicidade e verificação de webhooks.
• Eficiência: cache, processamento em lote e tamanho das requisições, desde que o teto de gasto que você definiu continue valendo.
• Observabilidade: rastros, métricas e formatos de log que permitem ao fornecedor ver o que o agente fez e por quê.
• Estrutura de avaliação: os conjuntos de testes e verificações executados antes e depois das mudanças.
• Detalhes de infraestrutura: servidores, filas e armazenamento, dentro da região e do modelo de hospedagem que você aprovou.

O padrão é consistente. O fornecedor escolhe o método, você escolhe o limite. Se o fornecedor pede que você decida qual tipo de índice usar, ele está passando a você um trabalho que deveria ser dele. Se ele nunca menciona uma mudança nos dados a que o agente tem acesso, está ficando com uma decisão que é sua.

Onde fica a zona cinzenta?

Algumas configurações parecem técnicas, mas têm consequências para o negócio. Três aparecem com frequência.

• Troca de modelo: um modelo diferente pode mudar qualidade, velocidade e custo, mas também qual empresa processa seus dados e onde. Isso altera os termos de uso dos dados, então exige a sua aprovação, mesmo que o fornecedor apresente o argumento técnico a favor da troca.
• Memória: o que o agente lembra entre conversas é em parte uma escolha de desenho e em parte uma escolha de privacidade. Defina quais categorias de informação podem ser armazenadas e por quanto tempo.
• Nível de detalhe dos logs: logs mais ricos ajudam a depurar, mas podem registrar dados pessoais ou textos confidenciais. Cabe a você definir o que pode ser registrado e quem pode ler. As exigências são maiores em setores regulados, o que vale para os requisitos de trilha de auditoria de empresas reguladas.

Uma regra útil para a zona cinzenta é fazer ao fornecedor uma pergunta: se esta configuração estivesse errada, quem seria afetado fora do sistema? Se a resposta incluir um cliente, um funcionário, um regulador ou o seu orçamento, a decisão é do dono do negócio.

Se uma configuração errada pode mudar quem vê seus dados, com quem você se compromete ou quanto você gasta, ela é uma decisão de negócio.

Guia de decisão: quem decide o quê

Use este guia em três níveis quando surgir uma configuração e ninguém souber de quem ela é.

• O negócio decide, o fornecedor aconselha: regras de aprovação, escopo de dados, permissões, canais, tetos de gasto, compromissos externos, retenção, critérios de sucesso e de parada, titularidade das contas.
• O fornecedor propõe, o negócio aprova: troca de modelo, novas ferramentas ou integrações, ampliação da memória, novas fontes de dados, mudança da região de hospedagem, mudança no conteúdo dos logs.
• O fornecedor decide, o negócio é informado: ajuste da recuperação de informações, estrutura de prompt, cache, novas tentativas, configuração de monitoramento, métodos de avaliação, manutenção de rotina dentro dos limites combinados.

Imprima, adapte ao seu agente e anexe ao contrato ou ao escopo de trabalho, para que os níveis façam parte do acordo e não de um entendimento verbal.

Um cenário ilustrativo: uma troca de modelo que parecia técnica

Este é um cenário ilustrativo, não um caso real. Uma distribuidora usa um agente de suporte a pedidos que responde perguntas de clientes e redige respostas para a equipe aprovar. O fornecedor percebe que outro modelo responderia mais rápido e propõe a troca em uma nota de atualização de rotina.

A dona da empresa, usando os níveis acima, percebe que a mudança afeta quem processa os dados de pedidos e de clientes. Ela faz três perguntas: o fornecedor do novo modelo guarda os dados ou os usa para treinamento, o processamento continua na região aprovada e o teto de gasto continua valendo. O fornecedor responde as duas primeiras por escrito e confirma a terceira depois de um teste curto. Ela aprova, e a troca segue em frente com a regra de aprovação de reembolsos inalterada.

Na mesma semana, o fornecedor também reformula a forma como os manuais de produtos são divididos para a busca. Essa mudança entra sem reunião, com uma nota e o resultado das verificações de avaliação. As duas mudanças foram tratadas corretamente, por pessoas diferentes, porque o limite já estava escrito.

Como definir esses controles na prática?

Você não precisa de um projeto longo. Uma empresa pequena consegue concluir isso em algumas sessões de trabalho.

• Primeiro passo: liste as ações do agente, os sistemas que ele toca e as pessoas com quem ele conversa. Esse é o material de partida.
• Segundo passo: para cada ação, marque se ela é apenas de leitura, reversível ou irreversível. Exija aprovação para tudo o que for irreversível ou voltado ao cliente até que o agente conquiste mais confiança.
• Terceiro passo: escreva o escopo de dados em duas listas, o que o agente pode ler e o que pode escrever. Tudo o que não estiver na lista está fora do escopo.
• Quarto passo: defina o teto de gasto, os níveis de alerta e uma pessoa indicada para receber os alertas.
• Quinto passo: indique um responsável por configuração de negócio e um substituto. Configurações sem dono se desviam.
• Sexto passo: combine como as mudanças são solicitadas e aprovadas e revise os acessos em intervalos definidos, com uma revisão periódica de permissões.

Espere que a primeira versão seja cautelosa demais. Tudo bem. É mais fácil ampliar o acesso depois de ver evidências do que recuar depois de um incidente.

Como a Be Human trata esse tema?

A Be Human começa cada projeto definindo um papel para o agente, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável, e registra tudo isso como configurações que pertencem ao cliente. O agente opera com identidade e contas próprias, com permissões ajustadas a esse papel. Durante a operação gerenciada, o fornecedor cuida do ajuste técnico, do monitoramento e das avaliações, e leva ao cliente como pedido de aprovação tudo o que toca escopo de dados, permissões, modelos ou gastos. O processo é o de solicitar e aprovar mudanças em um agente de IA gerenciado.

Perguntas frequentes

Preciso de conhecimento técnico para controlar essas configurações? Não. As configurações que são suas tratam de autoridade, exposição e custo, e dependem de conhecer o seu negócio e as suas obrigações. O fornecedor deve explicar cada uma em linguagem simples e mostrar o que ela muda na prática.

Posso mudar de ideia sobre as aprovações depois? Sim, e deve. Comece com aprovação humana para tudo o que for externo ou irreversível e, depois, flexibilize regras individuais quando tiver visto o agente se comportar bem ao longo do tempo. Registre cada mudança e quem a aprovou, para que o histórico fique claro.

E se o fornecedor disser que uma configuração é técnica demais para eu decidir? Pergunte o que acontece fora do sistema se a configuração estiver errada. Se um cliente, um funcionário, um regulador ou o orçamento forem afetados, a decisão é sua, e o papel do fornecedor é explicar as opções com clareza. Se ninguém fora do sistema é afetado, delegar a decisão é razoável.

Com que frequência devo revisar as configurações? Revise em intervalos regulares e depois de qualquer mudança relevante, como uma nova integração, uma nova equipe usando o agente ou a troca de modelo. O acesso costuma crescer sem alarde, então uma verificação recorrente de permissões, escopo de dados e alertas de gasto detecta o desvio cedo.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.