Modelo de responsabilidade compartilhada em agentes de IA: quem faz o quê

Um modelo de responsabilidade compartilhada em agentes de IA é a divisão escrita de deveres entre o fornecedor que constrói e opera o agente e a empresa que é dona dos dados, das decisões e do risco. Em geral, o fornecedor responde por como o sistema é construído, hospedado, monitorado e corrigido, e a empresa responde pelo que o agente pode saber, acessar e decidir em seu nome. Os problemas aparecem onde as duas partes se sobrepõem, por isso cada dever precisa de um responsável nomeado e de um substituto também nomeado.

Principais pontos

• Divida os deveres em quatro áreas: dados, acessos, qualidade e incidentes. Escreva essa divisão antes de o agente entrar em operação.
• A empresa decide o que o agente deve saber, fazer e ter permissão para decidir. O fornecedor garante que essas decisões sejam aplicadas e possam ser observadas.
• A qualidade é compartilhada de um jeito específico: a empresa define o que é um bom resultado, e o fornecedor mede isso em intervalos regulares.
• A maioria das falhas acontece nas passagens de bastão, como uma permissão que ninguém revisou ou um documento desatualizado que ninguém mantém. Nomeie um responsável para cada passagem.
• Ensaie o caminho de um incidente uma vez, com um cenário pequeno, para que o primeiro incidente real não seja também a primeira vez que alguém lê o plano.

Por que um modelo de responsabilidade compartilhada importa para agentes de IA?

A computação em nuvem deixou uma lição útil: o fornecedor protege a plataforma, e o cliente protege o que coloca nela. Os agentes de IA seguem a mesma lógica, com um acréscimo. Um agente não apenas armazena e processa informação. Ele lê, decide e às vezes age, então o comportamento dele também precisa ter dono.

Sem uma divisão explícita, cada lado presume que o outro cuidou do assunto. O fornecedor presume que a empresa revisou quais sistemas o agente consegue alcançar. A empresa presume que o fornecedor acompanha a qualidade das respostas. As duas suposições parecem razoáveis, e as duas podem estar erradas ao mesmo tempo. O agente passa semanas rodando com uma permissão que ninguém aprovou ou com uma fonte que ninguém mantém.

O modelo de responsabilidade compartilhada elimina essa ambiguidade. Ele não é, antes de tudo, um documento jurídico. É um acordo de operação que responde a uma pergunta simples: quando esta coisa específica der errado, quem percebe, quem age e quem decide?

Ele também se encaixa em práticas mais amplas de gestão de risco. O NIST AI Risk Management Framework pede que as organizações governem, mapeiem, meçam e gerenciem o risco de IA, e cada um desses verbos precisa de uma pessoa associada. Se a sua empresa já tem o hábito de uma governança leve, a divisão descrita aqui vira um dos documentos de trabalho dela. Se não tem, o modelo operacional de IA para empresas é um bom ponto de partida, mas este artigo se sustenta sozinho.

Quem é responsável pelos dados?

Os dados são a área em que a divisão é mais intuitiva e, ainda assim, a que mais fica vaga. Uma regra útil: a empresa é dona do significado dos dados, e o fornecedor é dono do tratamento seguro deles.

A empresa é responsável por:

• Decidir quais fontes o agente pode usar e quais estão fora de limite.
• A exatidão e a atualização dessas fontes, como tabelas de preços, políticas e procedimentos.
• Classificar informações sensíveis, incluindo dados pessoais, e confirmar que existe base legal para tratá-las.
• Definir as expectativas de retenção, ou seja, por quanto tempo conversas e memória devem ser guardadas.

O fornecedor é responsável por:

• Armazenar e transmitir os dados com segurança, com separação entre os dados de uma empresa e os de outra.
• Construir as camadas de recuperação e de memória para que o agente use somente as fontes aprovadas.
• Informar onde os dados são processados e quais subprocessadores estão envolvidos.
• Apagar ou exportar dados sob solicitação e manter registros que mostrem o que o agente acessou.
• Declarar por escrito se os seus dados são usados para treinar algum modelo. Esse ponto merece uma cláusula própria, e não uma linha em página de marketing.

A zona cinzenta é a desatualização. Suponha que o agente cite uma política que foi substituída no trimestre passado. O erro é da empresa se ninguém atualizou o documento, e é do fornecedor se a camada de recuperação ignorou uma versão mais nova que estava disponível. Uma boa divisão atribui o documento a um responsável do negócio e a verificação de atualização ao fornecedor, de modo que cada lado cubra uma metade da mesma falha.

Quem é responsável por acessos e permissões?

O acesso é onde um agente pode causar dano real, porque transforma uma resposta errada em uma ação errada. A divisão aqui trata de autoridade e de aplicação. A empresa concede a autoridade. O fornecedor a aplica tecnicamente e comprova que ela funciona.

A empresa decide a quais sistemas o agente se conecta, o que ele pode ler, o que pode alterar e quais ações exigem aprovação humana antes. Ela também deve manter as contas que importam. Se a identidade do agente e as contas de modelo ficam dentro do ambiente do fornecedor, a empresa entregou mais do que uma conveniência. De quem são as contas e chaves de API é uma decisão a tomar de forma deliberada, e uma identidade dedicada para o agente faz com que cada ação seja rastreável ao agente, e não ao login de uma pessoa.

O fornecedor implementa essas decisões com os menores escopos que ainda permitam ao agente fazer seu trabalho. Ele guarda os segredos com segurança, testa que o agente não consegue sair dos próprios limites e documenta cada conexão. As orientações de autorização da OWASP são uma boa referência para o que significam privilégio mínimo e negação por padrão na prática, e o OWASP Top 10 para aplicações com LLMs lista os riscos específicos de agentes, como agência excessiva e injeção de prompt, que um desenho de permissões deve prever.

A injeção de prompt é um bom exemplo de por que isso precisa ser compartilhado. O fornecedor pode reforçar o agente contra instruções escondidas em e-mails ou páginas da web. A empresa decide o tamanho do estrago que um agente enganado poderia causar, limitando desde o início o que ele pode tocar. Nenhum dos lados sozinho basta.

Quem é responsável pela qualidade?

A qualidade é o dever com maior chance de cair no vão, porque ninguém sente que é dono dela. Uma divisão clara funciona assim: a empresa define o que é um bom resultado, e o fornecedor constrói a engrenagem que o mede.

A empresa fornece exemplos reais de resultados bons e ruins, decide a taxa de erro aceitável para cada tipo de tarefa e revisa amostras do trabalho do agente. Só o negócio consegue dizer que uma resposta está tecnicamente correta, mas com o tom errado para um cliente importante. Cabe a ela também decidir quais erros são toleráveis e quais não são, já que um chamado interno classificado errado e uma promessa de reembolso incorreta têm pesos muito diferentes.

O fornecedor transforma esses julgamentos em testes repetíveis, executa-os em intervalos regulares e relata os resultados em linguagem clara. Ele observa desvios após qualquer mudança no modelo de base, nas instruções ou nas ferramentas conectadas. Os textos da Anthropic sobre avaliação de agentes e o guia de evals da OpenAI descrevem a mesma ideia: não se melhora o que não se testa, e os testes devem refletir as suas tarefas reais, e não benchmarks genéricos.

A qualidade também precisa de um ritmo de relatórios. Uma nota mensal que diga o que foi testado, o que mudou e o que o responsável do negócio precisa decidir vale mais do que um painel que ninguém abre. Se você quer definir as medidas antes do lançamento, veja os critérios de sucesso para piloto de agente de IA.

Quem é responsável quando algo dá errado?

Os incidentes são onde uma divisão confusa custa mais caro, porque o tempo conta. Pense em um incidente como cinco passos: detectar, conter, comunicar, corrigir e aprender. Cada passo tem um responsável natural.

• Detectar: o fornecedor, por meio de monitoramento e alertas, além da equipe da empresa, que relata comportamentos estranhos.
• Conter: o fornecedor, que precisa conseguir pausar o agente ou cortar uma conexão rapidamente, com a empresa autorizada a exigir isso.
• Comunicar: a empresa decide quem é avisado, como clientes, órgãos reguladores e liderança, porque essas relações e obrigações legais são dela.
• Corrigir: o fornecedor resolve a causa técnica, e a empresa resolve a consequência de negócio, como desfazer uma mensagem enviada por engano.
• Aprender: os dois, em uma revisão curta que termine com uma regra, um teste ou uma permissão alterada.

Se um dever não tem dono nomeado, o incidente vai atribuir um, e mal.

Cenário ilustrativo: uma empresa usa um agente que redige respostas a e-mails de fornecedores. Uma mensagem de um fornecedor contém texto oculto que manda o agente encaminhar os termos mais recentes de um contrato para um endereço externo. O monitoramento sinaliza uma requisição de saída incomum. O fornecedor pausa a ação de envio em poucos minutos e confirma pelos registros que nada saiu do sistema. A empresa decide se é preciso contatar o fornecedor e se o rascunho que foi escrito precisa de revisão. Depois, o provedor adiciona um teste para esse padrão, e a empresa remove de vez a capacidade de o agente anexar arquivos de contrato. Cada parte fez o que só ela poderia fazer.

Observe o que fez isso funcionar: a autoridade para pausar, o acesso aos registros e a decisão de comunicação foram combinados com antecedência. Para a questão mais ampla de quem responde ao longo de todo o ciclo de vida do agente, o texto sobre o líder interno de IA na empresa ajuda a atribuir esses papéis passo a passo.

Como traçar a linha na prática? Um plano de trabalho

Você não precisa de um workshop longo. Uma única sessão de trabalho com um responsável do negócio, um contato técnico e o líder do fornecedor costuma bastar. Siga estes passos.

• Descreva em uma frase o papel do agente e liste os sistemas e dados que ele toca.
• Para cada uma das áreas (dados, acessos, qualidade e incidentes), escreva três linhas: o que é da empresa, o que é do fornecedor e o que é compartilhado.
• Para cada item compartilhado, nomeie uma única pessoa responsável em cada lado e um substituto.
• Marque cada permissão como leitura, rascunho ou ação, e indique quais ações exigem aprovação humana.
• Combine a regra de pausa: quem pode parar o agente, com que rapidez e sem precisar da permissão de ninguém.
• Defina o ritmo de revisão: quando serão apresentados os resultados de qualidade, as revisões de permissões e as checagens de atualização de documentos.
• Coloque o resultado no contrato ou no escopo de trabalho, para que ele sobreviva a trocas de pessoas.
• Ensaie um cenário de incidente em conversa e corrija qualquer etapa em que duas pessoas achavam que a outra agiria.

Revise o documento sempre que o agente ganhar uma nova ferramenta, uma nova fonte de dados ou um novo canal. A maioria das lacunas de responsabilidade se abre nesses momentos, porque o agente mudou e o acordo não.

Como a Be Human trata essa divisão?

A Be Human projeta, implementa e opera infraestrutura de IA personalizada, então a divisão faz parte do primeiro trabalho conjunto, e não de um ajuste posterior. O projeto define um papel útil 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. Esses quatro itens correspondem diretamente aos deveres de dados, acessos, qualidade e incidentes.

Na operação gerenciada, o lado do fornecedor inclui monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. O lado da empresa continua com a empresa: ela mantém a autoridade sobre o que o agente sabe, o que pode fazer e o que é aceitável. O trabalho é feito remotamente, em português e inglês, e a divisão escrita é mantida como um documento vivo, para que os dois lados vejam quem é dono de quê. Para entender como o trabalho recorrente costuma se organizar, veja os primeiros meses com um agente de IA gerenciado.

Perguntas frequentes

Um modelo de responsabilidade compartilhada é o mesmo que um acordo de nível de serviço (SLA)? Não. Um SLA costuma tratar de disponibilidade, prazos de resposta e condições de suporte. O modelo de responsabilidade compartilhada trata de quem é dono de cada dever, inclusive daqueles que não aparecem em um compromisso técnico, como a exatidão dos documentos, a aprovação de permissões e a decisão de avisar clientes. Use os dois e garanta que não se contradigam.

Quem responde se um agente de IA cometer um erro caro? A responsabilidade legal depende do seu contrato, da jurisdição e dos fatos, então consulte um advogado em vez de confiar em uma regra geral. O que o modelo de responsabilidade oferece é clareza sobre a causa: se a falha veio de uma fonte que a empresa mantinha, de uma permissão que a empresa aprovou ou de um defeito técnico que o fornecedor deveria ter detectado. Essa clareza acelera tanto a correção quanto qualquer conversa jurídica.

Uma empresa sem equipe de TI ainda precisa assumir a sua parte? Sim, mas a parte dela é menor e envolve mais decisões do que tecnologia. A empresa continua decidindo quais dados o agente pode usar, quais ações precisam de aprovação e quem é avisado após um incidente, e isso pode ser feito sem engenheiros. Um único responsável do negócio, com o direito de pausar o agente, cobre a maior parte.

Com que frequência a divisão deve ser revisada? Revise sempre que o agente ganhar uma nova ferramenta, fonte de dados ou canal, e também em um calendário regular, mesmo que nada mude. Uma checagem trimestral curta costuma bastar em configurações estáveis. O objetivo é perceber o desvio entre o que o documento diz e o que o agente realmente faz.

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