Escopo de trabalho para implantação de agente de IA: o que incluir

O escopo de trabalho para implantação de agente de IA é um documento curto que define uma função para o agente, o que será entregue, a quais sistemas e permissões ele terá acesso, quem aprova o quê, como o aceite será julgado e como tudo será transferido para a empresa. Ele deve ser específico o bastante para que um funcionário novo, de qualquer um dos lados, o leia e saiba o que o agente faz, o que ele nunca pode fazer e como alguém perceberia que ele funciona. Seis partes cobrem quase tudo: função, entregáveis, acessos, aprovações, aceite e transferência.

Principais pontos

• Escreva o escopo em torno de uma função nomeada, não de uma tecnologia nem de uma lista de recursos.
• Liste entregáveis que possam ser inspecionados: acessos configurados, instruções escritas, fluxos testados, uma tela de monitoramento e documentação.
• Trate acessos e aprovações como o centro do documento. Eles definem o que o agente pode fazer quando ninguém está olhando.
• Defina o aceite como comportamento observável diante de exemplos combinados e diga quem assina.
• Inclua a transferência desde o início: contas, memória, instruções e registros devem ficar com a sua empresa.

Por que um agente de IA exige um escopo diferente?

O escopo de um software tradicional descreve um sistema que se comporta do mesmo jeito a cada execução. O agente funciona de outra forma. Ele lê o contexto, faz escolhas, usa ferramentas e, às vezes, age em nome da empresa. Dois pedidos idênticos podem seguir caminhos um pouco diferentes, e o agente vai encontrar situações que ninguém listou de antemão.

Isso muda o que o documento precisa fazer. Ele não pode apenas prometer recursos. Precisa fixar os limites dentro dos quais o agente pode usar julgamento e dizer quem responde quando ele chega à beira desses limites.

Um escopo vago costuma falhar de três maneiras. A função é descrita como "ajudar nas operações", e ninguém consegue dizer se o agente cumpriu o papel. O acesso é liberado de forma ampla porque era mais fácil, e um erro passa a ter grande alcance. Ou o projeto termina e a empresa descobre que instruções, memória e contas estão dentro do ambiente do fornecedor.

Cada seção abaixo fecha uma dessas lacunas. Se você ainda não decidiu qual deve ser a função, comece pelo exercício de Definir a função de um agente de IA na empresa: descrição de cargo e leve o resultado para o documento.

Função e entregáveis: para que o agente foi contratado e o que existirá no fim?

Comece pela função, escrita como se fosse uma descrição de cargo. Dê um nome à função, indique a equipe atendida, o trabalho assumido e o trabalho que fica explicitamente de fora. As exclusões importam tanto quanto as inclusões, porque evitam o crescimento silencioso do escopo.

Uma boa seção de função contém:

• Um objetivo em uma frase, por exemplo: responde dúvidas internas sobre pedidos em aberto usando o sistema de pedidos e redige respostas para a equipe enviar.
• As entradas que recebe e por quais canais.
• As saídas que produz e para onde vão.
• As tarefas fora do escopo, ditas com clareza.
• O responsável humano pela função, do lado da sua empresa, que tira dúvidas e decide sobre mudanças.

Depois, liste os entregáveis. É aqui que muitos documentos escorregam para promessas de inteligência ou de resultado. Mantenha os entregáveis concretos e verificáveis. Em um primeiro projeto, eles costumam incluir:

• As instruções escritas e as regras de operação do agente.
• As fontes de memória ou conhecimento que ele pode consultar e como são mantidas atualizadas.
• As ferramentas que ele pode acionar, cada uma com sua finalidade.
• Os canais pelos quais as pessoas falam com ele.
• Os casos de teste usados para checar o comportamento antes do lançamento.
• Uma tela de monitoramento que mostre o que o agente fez e onde falhou.
• Documentação suficiente para que sua equipe entenda e opere a configuração.

Entregável é algo que você pode apontar e verificar. "Um assistente mais inteligente" não é entregável. "Um conjunto de casos de teste que cobre as solicitações mais comuns e as situações em que o agente deve recusar ou escalar" é.

Mantenha o primeiro projeto estreito. Uma função com limite claro é mais fácil de aceitar, de corrigir e de ampliar depois. Se você está comparando vários candidatos, Como priorizar casos de uso de IA na empresa: método com quatro fatores ajuda a escolher o primeiro antes de escrever qualquer coisa.

Acessos: quais sistemas, contas e permissões o agente recebe?

O acesso é onde a utilidade do agente encontra o seu risco. O escopo deve listar cada sistema que o agente toca, o nível de permissão em cada um e o motivo. Se uma permissão não tem motivo declarado, ela não deve ser concedida.

Alguns princípios mantêm esta seção honesta:

• Privilégio mínimo. Comece com acesso de leitura e acrescente escrita só onde a função exigir, uma ação por vez.
• Identidade separada. O agente deve ter conta própria em cada sistema, para que suas ações sejam visíveis e revogáveis sem mexer no login de uma pessoa.
• Propriedade da empresa. As contas, as chaves de API e as contas do provedor de modelo devem estar registradas em nome da sua empresa, não do implementador. O raciocínio está em De quem devem ser as contas e chaves de API do agente de IA?.
• Escopo de dados nomeado. Diga quais dados o agente pode ler, quais ele nunca deve ver e onde os dados processados ficam armazenados.
• Termos do provedor. Registre se o provedor do modelo pode reter ou usar seus dados para treinamento, conforme combinado por escrito.

Para o desenho da autorização em si, o OWASP Authorization Cheat Sheet é uma boa referência sobre negar por padrão e verificar cada requisição. Você não precisa copiá-lo no contrato, mas seu contato técnico deve saber explicar como as permissões do agente seguem essas ideias.

Uma forma simples de apresentar esta seção é uma tabela com uma linha por sistema. Como o formato aqui é texto simples, uma lista por sistema funciona igualmente bem:

• Nome do sistema e responsável do seu lado.
• Nome da conta do agente.
• Ações permitidas (ler, redigir, atualizar, enviar).
• Ações proibidas.
• Quem pode revogar o acesso e com que rapidez.
• Data de revisão da permissão.

As duas últimas linhas costumam ser esquecidas. Um acesso que não pode ser revogado rápido nem revisado com regularidade vai se acumulando até que ninguém lembre por que existe.

Aprovações: quem decide o que o agente pode fazer sozinho?

A seção de aprovações transforma a sua tolerância a risco em regras. Para cada ação que o agente pode executar, defina qual dos três modos se aplica:

• Agir sozinho: ações de baixo impacto e reversíveis, como consultar um registro ou redigir uma resposta que ninguém vê até que uma pessoa a envie.
• Agir e depois relatar: ações fáceis de desfazer, registradas para revisão posterior.
• Perguntar antes: tudo que movimenta dinheiro, altera o cadastro de um cliente, envia comunicação externa, apaga dados ou compromete a empresa com algo.

Escreva isso como um guia de decisão que as instruções do agente possam seguir. Para cada ação, indique o aprovador pela função e não pelo nome, e diga o que acontece se nenhum aprovador responder. O padrão deve ser o agente esperar ou escalar, nunca seguir em frente.

Esta seção também deve tratar do controle de mudanças. Quem pode alterar as instruções, as ferramentas ou as permissões do agente depois do lançamento? Como as mudanças são testadas e revertidas? Uma regra curta como "nenhuma mudança em agente em produção sem aprovação registrada e um teste" evita a maior parte das surpresas. Para o lado prático, veja Como atualizar agente de IA em produção sem quebrar nada.

Por fim, inclua uma cláusula de incidente. Se o agente fizer algo que não deveria, quem é avisado, quem pode pausá-lo e qual é a primeira resposta? Sua equipe deve conseguir pausar o agente sem pedir permissão ao fornecedor.

Para um enquadramento mais amplo de risco e responsabilidade, o NIST AI Risk Management Framework oferece um vocabulário que muitas diretorias consideram útil. É uma referência, não uma exigência para um primeiro escopo de trabalho.

Aceite e transferência: como saber que funciona e o que fica com você?

O aceite responde a uma pergunta simples: o que precisa ser verdade para você dizer que o trabalho está concluído? Evite critérios baseados em impressão, como "a equipe está satisfeita". Use critérios observáveis, combinados antes da construção.

Bons critérios de aceite costumam incluir:

• Um conjunto de pedidos de exemplo com o comportamento esperado, incluindo exemplos em que o correto é recusar ou passar para uma pessoa.
• Uma revisão de saídas reais pelo responsável da função durante um período combinado.
• Evidência de que as regras de aprovação disparam quando deveriam.
• Evidência de que registros e monitoramento mostram o que o agente fez e por quê.
• Um signatário nomeado do seu lado.

Como medir um período de teste é outro assunto, tratado em Critérios de sucesso para piloto de agente de IA: como definir. Sobre o método de avaliação, o texto Demystifying evals for AI agents, da Anthropic, explica por que casos de teste construídos a partir de tarefas reais valem mais do que impressões gerais. Para enxergar o comportamento em execução, o guia introdutório de observabilidade do OpenTelemetry descreve logs, métricas e traces em termos que seu responsável técnico reconhecerá.

A transferência é a outra metade do encerramento. Especifique o que você recebe e em que formato:

• Instruções escritas e regras de operação, em formato legível.
• A memória e as fontes de conhecimento, com a descrição de como são mantidas.
• As definições de ferramentas e integrações.
• Os casos de teste e o resultado da última execução.
• Um registro do agente no inventário: responsável, finalidade, sistemas, permissões e datas de revisão.
• Um manual para pausar, restaurar e alterar o agente.
• Uma declaração sobre quais dados o implementador mantém e como serão devolvidos ou apagados.

O objetivo é simples: se a relação terminasse amanhã, sua empresa poderia manter o agente funcionando ou levá-lo para outro lugar. O detalhe prático está em Plano de saída de fornecedor de IA: o que manter e documentar.

Se o agente for operado por um fornecedor depois do lançamento, acrescente uma cláusula curta de operação que diga o que é monitorado, com que frequência ocorrem as revisões e quais prazos de resposta valem para incidentes. O que prometer e o que deixar de fora dessa cláusula é discutido em SLA para agentes de IA: o que definir por escrito e o que evitar.

Um cenário ilustrativo e um checklist para revisar qualquer rascunho

Este é um cenário ilustrativo, não um projeto real. Uma distribuidora quer um agente para a equipe de atendimento. A função: responder dúvidas da equipe sobre o status de pedidos e redigir respostas para os clientes. O escopo diz que o agente tem acesso de leitura ao sistema de pedidos por uma conta própria, pode redigir mas não enviar e-mails, e deve consultar um líder de equipe nomeado antes de qualquer reembolso ou troca de endereço. Os entregáveis incluem as instruções, os modelos de rascunho, uma tela de monitoramento e um conjunto de casos de teste. O aceite é uma revisão das respostas redigidas pelo líder da equipe durante um período de teste combinado, mais a verificação de que todo pedido de reembolso foi escalado. A transferência inclui tudo isso, mais as contas registradas em nome da empresa.

Repare como isso é pequeno. Não descreve uma transformação. Descreve uma função que pode ser conferida.

Use este checklist em qualquer rascunho, seja seu ou do fornecedor:

• Existe exatamente uma função nomeada, com exclusões?
• Existe um responsável nomeado do seu lado?
• Todo entregável tem um jeito de ser inspecionado?
• Todo sistema tem nível de permissão e motivo declarados?
• O agente tem contas próprias, registradas em nome da sua empresa?
• Toda ação com consequência está classificada como agir sozinho, relatar ou perguntar antes?
• Sua equipe consegue pausar o agente sem ajuda do fornecedor?
• Os critérios de aceite estão escritos como exemplos e observações, com signatário nomeado?
• A transferência cobre instruções, memória, ferramentas, testes e registros?
• Há uma posição declarada sobre retenção de dados e treinamento pelo provedor?

Como a Be Human aborda isso: o primeiro projeto é delimitado em torno de uma função útil, com a memória e as ferramentas de que ela precisa, limites de aprovação por escrito e um critério de sucesso observável. O agente opera com identidade e contas próprias, e as instruções, permissões e o contexto permanecem sob o controle da sua empresa. Quando a operação gerenciada está incluída, ela cobre monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e resposta a incidentes, e cada uma dessas atividades é escrita no documento como atividade definida, não como promessa genérica.

Se você ainda está comparando parceiros antes de redigir, Como escolher parceiro de implementação de IA para sua empresa lista o que observar.

Perguntas frequentes

Qual deve ser o tamanho do escopo de trabalho de um agente de IA? Tão curto quanto possível, desde que cubra função, entregáveis, acessos, aprovações, aceite e transferência. Para uma única função, poucas páginas costumam bastar. Se o documento cresce porque várias funções foram reunidas, separe-o em escopos distintos.

Quem deve assinar o escopo de trabalho? O responsável de negócio pela função, porque é ele quem vai conviver com o comportamento do agente. Um responsável técnico deve confirmar a seção de acessos, e quem cuida de proteção de dados ou da revisão jurídica deve checar os termos de dados e do provedor. Assinar por função mantém o documento válido se as pessoas mudarem de cargo.

O escopo deve prometer resultados específicos? É mais seguro prometer trabalho inspecionável e testes combinados do que resultados de negócio. Os resultados dependem dos seus dados, dos seus processos e de como sua equipe usa o agente. Defina o sucesso como comportamento observável diante de exemplos e de um período de revisão, e mantenha as metas de resultado no business case interno.

O que fazer quando a função do agente precisa crescer? Trate como uma mudança, não como uma expansão silenciosa. Escreva um aditivo que atualize as seções de função, acessos, aprovações e aceite, teste o novo comportamento e registre a aprovação. Assim cada etapa da responsabilidade do agente fica visível e reversível.

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