Responsabilidade civil por erro da IA: quem responde na empresa

Quando um sistema de IA causa prejuízo a um cliente, quem responde perante ele, na maioria dos casos, é a empresa que colocou o sistema para atender e se beneficiou dele, ainda que o erro tenha origem em um modelo de terceiros. O fornecedor da tecnologia pode responder conforme o contrato e o defeito do que foi entregue, e o usuário interno responde pelo uso indevido que fez. O que decide a discussão na prática são os registros do que a IA fez e a existência de aprovação humana nas decisões de maior impacto. Este texto é uma orientação de gestão, não uma opinião jurídica.

Principais pontos

• A empresa que atende o cliente com IA costuma responder perante ele, mesmo quando a falha veio de um modelo ou plataforma contratada.
• O fornecedor responde pelo que vendeu e pelo que o contrato efetivamente cobre, por isso cláusulas, logs e documentação entram na conta.
• O usuário interno pode responder por desvio de uso, como colar dados de clientes em ferramentas não autorizadas.
• Registros de entrada, consulta, ação e encaminhamento são a principal prova para separar as responsabilidades.
• Aprovação humana em reembolsos, descontos, cancelamentos e orientações sensíveis reduz a chance de o erro chegar ao cliente.

Por que a pergunta já é prática e não teórica

Boa parte da conversa sobre superinteligência trata de sistemas que não existem em operação de empresa hoje. A pergunta de responsabilidade civil, porém, já está na mesa. Um agente que informa prazo de entrega, aplica um desconto ou orienta sobre garantia de um produto está, na prática, falando em nome da empresa. A distinção entre o debate futuro e o que sua operação faz agora ajuda a focar, e o texto sobre a diferença entre AGI e superinteligência organiza esse ponto.

O erro de uma IA que responde no WhatsApp não é diferente, juridicamente, do erro de um atendente mal treinado. A diferença é que a escala é maior e a reconstrução do que aconteceu depende de registros que muitas empresas não guardaram.

Os três cenários de responsabilidade

Para o cliente final, a empresa é quem aparece como fornecedora do serviço. No Código de Defesa do Consumidor, o fornecedor de serviços responde pelos danos causados por defeitos na prestação, independentemente de culpa, segundo o artigo 14. Isso significa que dizer ao cliente que a IA "errou sozinha" não é um argumento que protege a empresa diante dele.

O fornecedor da tecnologia entra em cena na relação interna. Se o problema estiver no modelo, em uma atualização não avisada, em uma falha de segurança da plataforma ou em uma integração que ele entregou, a empresa pode buscar ressarcimento. O alcance disso depende do contrato: limites de responsabilidade, tipo de suporte, prazo de notificação de incidentes e acesso aos logs. Sem essas cláusulas, a empresa fica com o risco inteiro e com pouca prova.

O usuário interno é o funcionário que opera, configura ou usa a ferramenta. Se ele insere dados pessoais de clientes em um assistente não aprovado, ou altera as instruções do agente sem revisão, a responsabilidade interna pode recair sobre ele, sem excluir a da empresa perante terceiros. Por isso a política de uso precisa dizer o que é permitido e o que é proibido, e o texto sobre política de uso de ChatGPT na empresa detalha esse recorte.

Como a responsabilidade se distribui em um caso concreto

Cenário ilustrativo: uma loja de móveis planejados usa um agente no WhatsApp para atender orçamentos. Um cliente recebe a confirmação de um prazo de montagem que não existe na agenda real da equipe e cancela outro compromisso por causa disso. Ele reclama de prejuízo.

Perante o cliente, a loja responde, porque foi ela quem ofereceu o atendimento. Internamente, a análise depende do que os registros mostram. Se o log indica que o agente consultou uma agenda desatualizada, a discussão vai para a integração, que é responsabilidade de quem a construiu e de quem a manteve. Se o log indica que um funcionário alterou a instrução do agente duas semanas antes sem revisão, a discussão vai para o processo interno de mudanças. Se não há log, a empresa não consegue provar nada, e tende a arcar com tudo.

O ponto é que a mesma situação gera caminhos de recurso diferentes conforme a evidência. Sem evidência, a empresa perde também a capacidade de corrigir o fluxo.

O que os registros precisam mostrar

Registro útil não é apenas guardar a conversa. Ele precisa permitir reconstruir a decisão. Um checklist mínimo para cada fluxo de IA que fala com clientes ou toma ações:

• A mensagem recebida, com data e canal, e a versão da instrução ou do fluxo que estava ativa naquele momento.
• As fontes consultadas, como catálogo, agenda ou status de pedido, e a resposta que cada uma devolveu.
• A ação executada, como oferta, desconto, cancelamento ou cobrança, com o valor e a condição aplicados.
• O ponto em que o agente encaminhou para uma pessoa, o motivo e quem assumiu a conversa.
• Quem alterou instruções, limites ou integrações, e quando, com aprovação registrada.

A prática de observabilidade descrita pela documentação de conceitos do OpenTelemetry ajuda a pensar esses registros como trilhas de eventos ligadas entre si, e não como arquivos soltos. Para agentes, a convenção de semânticas de IA generativa do OpenTelemetry é uma referência útil para padronizar o que se registra.

Há um cuidado de privacidade. Registros completos contêm dados pessoais, então precisam de prazo de guarda, acesso restrito e finalidade definida. Registrar tudo sem critério cria outro risco, agora perante a LGPD. A ANPD é o canal de referência para acompanhar orientações sobre tratamento de dados no país.

Aprovação humana: onde colocar e onde não precisa

Aprovação humana não precisa existir em tudo, porque isso anula o ganho de atendimento. O que ela precisa fazer é proteger as decisões que, se erradas, geram dano financeiro ou afetam direitos de uma pessoa. Um guia de decisão simples:

• Ações irreversíveis ou com valor, como reembolso, cancelamento e desconto fora da tabela: o agente prepara a proposta e uma pessoa aprova antes de executar.
• Respostas sobre saúde, crédito, garantia legal ou direitos do consumidor: o agente informa o procedimento padrão e encaminha o caso para revisão humana.
• Informações factuais de catálogo, horário ou status de pedido: o agente responde diretamente, com a fonte consultada registrada.
• Conversas de baixo risco, como triagem ou agendamento de horário livre: o agente conduz, com limites explícitos e opção clara de falar com uma pessoa.

Um detalhe importante: decisão automatizada que afeta o interesse de alguém tem regras próprias na LGPD, incluindo o direito de pedir revisão. O texto sobre decisões automatizadas na LGPD e o artigo 20 trata desse ponto.

A OWASP Top 10 para aplicações com LLM lista riscos como injeção de instruções e uso excessivo de ferramentas. Ela não substitui a análise jurídica, mas mostra por que ações sensíveis devem depender de uma etapa que um texto digitado pelo usuário não consegue contornar.

O que pedir por escrito ao fornecedor

Antes de contratar uma plataforma ou um modelo, a empresa deve transformar a responsabilidade em item de contrato ou de anexo técnico. Pontos que costumam ser discutidos, sem garantias prontas:

• Quais dados o fornecedor armazena, por quanto tempo e se os usa para treinar modelos.
• Onde os dados são processados, com atenção à transferência internacional quando houver. O texto sobre transferência internacional de dados com IA e a LGPD apoia essa conversa.
• Como e em que prazo o fornecedor comunica incidentes e mudanças de modelo que alterem o comportamento do agente.
• Se a empresa consegue exportar logs completos, em formato utilizável, sem depender de suporte.
• Quais são os limites de responsabilidade e como eles se aplicam a falhas de terceiros que o fornecedor utiliza.

Para a análise jurídica desses itens, a empresa deve contar com advogado. O marco legal da IA no Brasil segue em discussão, e acompanhar essa tramitação faz parte da rotina de quem opera IA com clientes.

Como o método reduz o risco na prática

O método que aplicamos segue quatro passos: mapear, limitar, pilotar e transferir. Mapear significa listar o processo atual, os pontos de decisão e onde a IA entra, antes de qualquer configuração. Limitar significa restringir dados e ações ao necessário, com permissões que o agente não pode ultrapassar. Pilotar significa rodar um fluxo real, com logs e uma métrica de sucesso combinada de antemão, para observar o comportamento antes de ampliar. Transferir significa entregar o fluxo com documentação e decidir, com base na evidência, se expande, ajusta ou para.

Esse caminho não elimina o erro, mas faz a empresa saber onde ele aconteceu, quem tinha autoridade para cada ação e o que mudar. Para quem quer testar fluxos antes de expor clientes, o texto sobre mocks e sandbox para testar agentes de IA descreve como fazer isso sem risco real.

Perguntas frequentes

A empresa responde pelo erro da IA mesmo quando o modelo é de outra empresa? Na relação com o cliente, em geral sim, porque a empresa é quem oferece o serviço ao consumidor. A discussão sobre o modelo de terceiros acontece depois, na relação com o fornecedor, e depende do contrato e das provas. Por isso a empresa precisa de registros do que a IA fez e de cláusulas claras sobre incidentes.

O fornecedor do modelo pode ser responsabilizado? Pode, dentro dos limites do contrato e do defeito efetivamente causado pela tecnologia fornecida. Se a falha veio de uma configuração feita pela própria empresa, a responsabilidade tende a ser dela. Sem logs que mostrem a origem do problema, a empresa dificilmente consegue cobrar o fornecedor com segurança.

Um funcionário que usa IA de forma errada gera responsabilidade para a empresa? A empresa pode responder perante terceiros pelo que seus funcionários fazem no exercício do trabalho, e o funcionário pode responder internamente conforme as regras da empresa e a legislação aplicável. Uma política de uso clara, com o que é permitido e o que é proibido, reduz a ocorrência e facilita a apuração.

Aprovação humana elimina o risco? Não elimina, mas reduz bastante o risco nas decisões de maior impacto, porque cria um ponto de revisão com autoridade e registro. Ela só funciona se a pessoa tiver informação suficiente para decidir e tempo para isso. Aprovação automática, sem leitura real, não cumpre esse papel.

Fontes

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OpenTelemetry: observability concepts
• ANPD: Autoridade Nacional de Proteção de Dados