Quem é responsável quando o agente de IA comete um erro?

Quando um agente de IA comete um erro, a empresa que o colocou em operação responde perante o cliente, o colaborador ou o órgão regulador afetado, porque o agente age em nome dela. A responsabilidade pela causa, porém, é compartilhada: o dono do negócio responde por decisões e permissões, o operador por configuração e monitoramento, e o fornecedor pelo comportamento do modelo e da plataforma que se comprometeu a manter por escrito. O trabalho prático é combinar essa divisão antes de o erro acontecer, e não discuti-la depois.

Principais pontos

• A responsabilidade perante terceiros fica com a empresa cujo nome, canal ou conta o agente usou. Você não consegue repassá-la a um fornecedor.
• A responsabilidade interna pode ser dividida: dono, operador e fornecedor respondem por partes diferentes do sistema.
• A maioria dos erros de agente vem de escopo, permissões, contexto desatualizado ou falta de revisão. São decisões, não falhas do modelo.
• Uma pessoa nomeada, um limite escrito e um registro utilizável do que o agente fez valem mais do que qualquer cláusula sobre culpa.
• Defina a divisão antes de entrar em produção, teste com um incidente ensaiado e revise sempre que o escopo do agente mudar.

Por que não existe uma resposta única sobre quem é responsável?

Muita gente faz essa pergunta como se o agente de IA fosse um produto com defeito, em que o fabricante responde, ou uma ferramenta mal usada, em que o usuário responde. O agente é as duas coisas e nenhuma delas. É um modelo criado por uma parte, envolvido em ferramentas e instruções por uma segunda, e colocado à frente de trabalho real por uma terceira. O erro pode entrar em qualquer uma dessas camadas, e muitas vezes entra nas emendas entre elas.

Duas perguntas costumam se misturar nas conversas, e separá-las ajuda.

• Quem responde perante a pessoa prejudicada? Em geral, a empresa que colocou o agente na frente dela. O cliente que recebe uma mensagem errada da sua empresa não quer saber qual fornecedor criou o modelo.
• Quem responde pela causa? Depende de onde a falha entrou e do que cada parte combinou fazer. Esta é a pergunta que você pode moldar com antecedência.

Este artigo é orientação operacional, não aconselhamento jurídico. As regras de responsabilidade variam por país e por setor, e alguns regimes atribuem deveres específicos à organização que usa um sistema de IA. Se o seu agente toca dados ou decisões regulados, envolva o jurídico desde cedo (veja também LGPD e agentes de IA nas empresas). Referências como o NIST AI Risk Management Framework e os Princípios de IA da OCDE tratam a responsabilização como algo que a organização atribui de forma deliberada, com papéis nomeados e decisões rastreáveis, e não como algo que surge sozinho.

O que cada parte realmente assume?

A forma mais simples de evitar confusão é definir três papéis em linguagem clara e escrever pelo que cada um responde.

O dono do negócio é a empresa que usa o agente. Ele decide qual trabalho o agente faz, quais dados pode ver, o que pode fazer sem perguntar e quem aprova as exceções. Também mantém a relação com o cliente ou colaborador que está do outro lado.

O operador é quem configura, conecta, monitora e mantém o agente no dia a dia. Em uma empresa pequena, pode ser uma pessoa interna. Em outras, é um prestador de serviço gerenciado. O operador responde para que a configuração corresponda ao que o dono decidiu e por perceber quando o comportamento começa a se desviar.

O fornecedor é quem entrega o modelo ou a plataforma. Ele responde pelo que declara sobre disponibilidade, tratamento de dados e comportamento do modelo, e pelos termos que publica. Não responde pela forma como você decidiu usar o resultado, a menos que seus termos digam o contrário.

Uma divisão que funciona na prática é esta:

• Dono: a finalidade, o escopo, os limites de aprovação, a qualidade das fontes de informação e a decisão final sobre qualquer ação com consequência.
• Operador: as permissões como configuradas, as integrações, o monitoramento, as rotinas de avaliação, o controle de mudanças e a primeira resposta a incidentes.
• Fornecedor: a disponibilidade do serviço, a segurança da sua plataforma, a comunicação de mudanças no modelo, os termos de tratamento de dados e os compromissos de suporte.

Se uma mesma pessoa ocupa mais de um papel, registre isso por escrito. A empresa que constrói e opera o próprio agente sobre o modelo de um terceiro é dona e operadora ao mesmo tempo, e carrega os dois conjuntos de deveres.

Qual tipo de erro pertence a quem?

Antes de um incidente, relacione os tipos de erro que você espera com o papel mais bem posicionado para evitá-los. Use como guia de decisão: identifique o sintoma e depois veja onde olhar primeiro.

• O agente fez algo que nunca deveria ter podido fazer. Olhe as permissões e os limites de aprovação. Em geral é responsabilidade de dono e operador: o dono definiu o limite ou deixou de defini-lo, e o operador configurou o acesso. A diferença entre permissão de leitura, rascunho e envio costuma ser o ponto da falha, e o artigo sobre acesso mínimo ao integrar agentes ao Google Workspace ou Microsoft 365 ajuda a pensar nisso.
• O agente usou informação desatualizada ou errada. Olhe as fontes que ele recebeu e como são atualizadas. Costuma ficar com o dono, que fornece as políticas e os registros, e com o operador, que mantém a conexão.
• O agente foi manipulado por texto dentro de um documento ou mensagem. Olhe o tratamento de entradas e os limites do que ele pode fazer depois de ler conteúdo não confiável. O OWASP Top 10 para aplicações com LLM cataloga esses riscos. A responsabilidade é dividida entre o desenho feito pelo operador e as decisões do dono sobre quais fontes merecem confiança.
• O modelo passou a se comportar de outra forma após uma atualização, ou o serviço ficou indisponível. Olhe os avisos de mudança e os termos de serviço do fornecedor. Aqui pesam os compromissos do fornecedor, e o operador deveria ter testes que detectem regressões.
• O agente estava certo, mas uma pessoa agiu com descuido ou pulou uma revisão obrigatória. Olhe a etapa de revisão e quem foi designado para ela. É assunto do dono: o processo existia e não foi seguido.
• Ninguém consegue dizer o que aconteceu. É uma falha de registros. Cabe ao operador corrigi-la e ao dono exigir que seja corrigida.

Repare como poucos desses casos são falhas puras do modelo. A maioria são decisões sobre escopo, acesso, informação e revisão, e isso é uma boa notícia: dá para controlá-las.

Um cenário ilustrativo: a promessa de reembolso errada

Este é um cenário ilustrativo, não um caso real.

Uma distribuidora usa um agente para redigir respostas a e-mails de clientes sobre entregas atrasadas. A dona do processo, a responsável pelo atendimento, definiu uma regra: o agente pode redigir, mas uma pessoa envia. Meses depois, para ganhar tempo, um líder de equipe ativa o envio automático das mensagens que o agente classifica como rotineiras. O operador aplica a mudança a pedido, mas não exige um limite de aprovação por escrito.

Um cliente escreve sobre um palete danificado. O agente, apoiado em um documento de política desatualizado que ninguém havia retirado, promete a reposição completa sem custo, e a mensagem sai automaticamente. O cliente passa a contar com isso.

Quem responde? Perante o cliente, a distribuidora, sem dúvida. Internamente, a causa tem várias partes. O dono permitiu o envio automático sem definir quais assuntos ficavam de fora. O operador alterou uma permissão sem aprovação registrada e não sinalizou o documento desatualizado. O fornecedor não fez nada errado. Com uma divisão escrita, a empresa enxerga isso com clareza, corrige as três lacunas e segue em frente. Sem ela, a conversa vira uma busca por alguém para culpar.

A lição não é que o agente nunca deva enviar. É que a decisão de deixá-lo enviar deveria ter nome, limite e data. Para saber onde um agente deve pausar, veja quando seu agente de IA deve parar e perguntar.

Como atribuir responsabilidades antes de entrar em produção?

Este plano pode ser feito em poucas sessões de trabalho e não exige ferramentas especiais. O resultado é um documento curto que dono e operador aprovam juntos.

• Nomeie o papel. Escreva uma frase descrevendo o trabalho do agente e o que ele explicitamente não faz.
• Nomeie a pessoa responsável. Um indivíduo na empresa responde pelos resultados do agente. Uma equipe ou um cargo não basta. Indique também um substituto nomeado.
• Liste as ações por consequência. Separe o que o agente pode ler, o que pode redigir e o que pode enviar, alterar ou gastar. Marque o que exige aprovação humana e quem a dá.
• Atribua um dono a cada fonte de informação. Toda política, tabela de preços ou cadastro de cliente que o agente usa precisa de uma pessoa responsável por mantê-lo atualizado e de uma regra para aposentar versões antigas.
• Decida o que será registrado. No mínimo: o pedido, as fontes usadas, a ação tomada, quem aprovou e quando. Confirme que o operador consegue recuperar isso sob demanda.
• Defina o que conta como incidente. Mensagem externa errada, exposição de dados, ação fora do escopo, falha repetida. Diga quem é avisado, em quanto tempo e quem pode pausar o agente.
• Combine o controle de mudanças. Quem pode alterar instruções, permissões ou ferramentas conectadas, e como essas mudanças são aprovadas e registradas.
• Ensaie uma falha. Percorra um erro plausível e confirme que cada pessoa sabe o seu papel. Ajuste o documento onde ficou confuso.

Para o lado da resposta, um plano de resposta a incidentes de agentes de IA deve cobrir contenção, comunicação e revisão com mais detalhe.

O que o contrato e os registros devem dizer?

A responsabilidade que existe só em conversa desaparece quando as pessoas mudam de função. Coloque-a em dois lugares: o contrato com o operador ou fornecedor e os registros de operação.

No contrato, procure respostas claras para estes pontos:

• Qual parte configura e mantém as permissões, e quem aprova mudanças nelas.
• O que o operador monitora, com que frequência e o que faz quando algo parece errado.
• Como os incidentes são comunicados a você e dentro de qual expectativa. Um nível de serviço para agentes de IA funciona melhor quando diz o que é medido e evita promessas que ninguém consegue verificar.
• O que os termos do fornecedor dizem sobre tratamento de dados, mudanças no modelo e aviso prévio dessas mudanças.
• Quem é dono das contas, credenciais e logs, para que você tenha acesso a eles se a relação terminar.
• Como a responsabilidade civil é tratada entre as partes. Peça ao jurídico que leia essa seção. Não presuma que o silêncio do contrato favorece você.

Nos registros, mantenha um histórico simples de decisões: quando o escopo foi definido, quando as permissões mudaram, quem aprovou cada mudança e os resultados das revisões periódicas. Conceitos de observabilidade, como rastros e logs estruturados, ajudam, mas o objetivo é simples: uma pessoa que não estava presente deve conseguir reconstruir o que o agente fez e por que ele tinha permissão para fazê-lo.

Preste atenção também ao desenho de acesso. A orientação de autorização da OWASP recomenda o menor privilégio e a verificação de permissões a cada requisição. Para um agente, isso significa dar a ele apenas o acesso que o papel exige. Um acesso estreito reduz o conjunto de erros pelos quais alguém pode ser responsabilizado.

Como a Be Human trata a responsabilização?

A Be Human projeta, implementa e opera infraestrutura de IA personalizada para empresas, e trata a divisão de responsabilidades como parte do primeiro trabalho conjunto. Essa etapa define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável, de modo que as decisões do dono fiquem escritas antes de o agente agir. A operação gerenciada pode incluir monitoramento, avaliações recorrentes, revisão de permissões, manutenção de integrações e resposta a incidentes, com mudanças feitas de forma controlada. A empresa mantém o controle de identidade, memória, canais, ferramentas e permissões, e decide o que o agente pode fazer sem um humano.

Perguntas frequentes

Posso culpar o fornecedor de IA se o agente cometer um erro? Às vezes, mas raramente por inteiro. Seus clientes vão responsabilizar a sua empresa, e a responsabilidade do fornecedor depende dos termos dele e de a falha estar no que ele entregou ou na forma como o agente foi configurado e usado. Leia os termos antes de apostar em qualquer suposição.

Quem é responsável se um colaborador seguir uma sugestão errada do agente? A empresa, na maioria dos casos, e internamente o dono do processo que disse ao colaborador quando confiar no agente e quando conferir. Se a sua política exigia revisão e o colaborador a pulou, é uma questão de processo e treinamento. Uma política de uso aceitável de IA para funcionários ajuda a deixar essas expectativas claras.

A aprovação humana elimina a responsabilidade da empresa? Não. Ela coloca uma pessoa nomeada dentro da decisão, o que melhora a qualidade e a rastreabilidade, mas a empresa continua responsável pelo resultado. A aprovação funciona melhor quando o revisor tem contexto suficiente para dizer não e não é pressionado a aprovar rápido.

Qual é a primeira providência depois de um erro do agente? Contenha: pause a ação envolvida, preserve os registros e avise a pessoa responsável. Depois, repare o dano à parte afetada, descubra qual camada falhou e atualize o limite ou a informação que permitiu o erro. Evite apontar culpados até que o registro mostre o que aconteceu.

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