Agente de IA errou com o cliente: quem responde pelo prejuízo?

Conteúdo patrocinado.

Quando um agente de inteligência artificial causa prejuízo, a responsabilidade depende da relação jurídica, do defeito, do dano e do controle efetivo sobre a operação. Nem empresa nem fornecedor recebem imunidade por usar IA.

Transforme a função do agente em uma lista de capacidades

Descreva a função com verbos específicos: consultar catálogo, localizar pedido, criar rascunho, encaminhar solicitação. Evite permissões genéricas como “gerenciar clientes” quando a tarefa exige apenas leitura de alguns campos. Quanto mais ampla a ferramenta, mais decisões ficam escondidas dentro de uma autorização aparentemente simples.

O OWASP Gen AI Security Project relaciona o risco de agência excessiva a funcionalidades, permissões e autonomia além do necessário. A referência ajuda a examinar separadamente o que uma ferramenta faz, quais dados alcança e quando pode executar uma ação.

Na revisão do projeto, confronte cada capacidade com uma necessidade do processo. Se não existe uma tarefa prevista que exija excluir registros, essa operação não precisa estar disponível. Se o agente só atua em uma unidade da empresa, o acesso deve refletir esse alcance.

A primeira pergunta é quem prometeu e quem executou

Quando um agente de IA fornece uma informação errada ao consumidor ou pratica uma ação indevida, não existe uma regra única que transfira o prejuízo automaticamente ao desenvolvedor ou à empresa que o utiliza. A análise começa por identificar a relação jurídica, o defeito do serviço, o dano, o nexo causal e quem tinha controle sobre fontes, permissões e aprovação da operação.

Em uma relação de consumo, a Lei 8.078 de 1990, Código de Defesa do Consumidor prevê, no artigo 14, regras de responsabilidade do fornecedor por defeitos na prestação de serviços, com hipóteses legais de afastamento. Isso não significa que qualquer resposta imprecisa de chatbot gere automaticamente indenização. É necessário examinar a situação concreta.

Já na relação entre a empresa contratante e a software house, o contrato pode distribuir deveres de implementação, testes, manutenção, tratamento de incidentes e limites de uso. Cláusulas entre empresas não eliminam por si mesmas direitos de terceiros nem obrigações impostas pela legislação.

Exemplo hipotético: preparar uma condição comercial

Imagine um agente que auxilia a equipe de vendas a organizar solicitações de condição especial. Seu trabalho é consultar dados autorizados do cliente, verificar uma tabela comercial vigente e preparar um resumo para análise. A decisão final continua com um responsável definido pela empresa.

O exemplo não define uma política comercial universal. Ele mostra como transformar uma intenção de controle em regras verificáveis. A mesma lógica pode ser adaptada a abertura de chamados, revisão de cadastros ou preparação de pedidos, com limites próprios para cada operação.

Três situações mostram por que a resposta jurídica muda

Quem recebeu a reclamação e quem podia evitar a falha?

Registros de treinamento, histórico da conversa, base consultada e permissões do agente ajudam a reconstruir a sequência. A ausência de evidências pode dificultar tanto a defesa quanto a correção do problema.

No terceiro exemplo, entram também deveres de privacidade e segurança. A orientação da ANPD sobre agentes de tratamento ajuda a distinguir responsabilidades conforme o papel efetivamente desempenhado em cada atividade de tratamento de dados.

Faça a aprovação apontar para uma ação concreta

Supervisão humana é um controle real apenas se a pessoa recebe informações suficientes para recusar a ação e tem tempo para fazê-lo.

“Você aprova?” é uma pergunta insuficiente quando o usuário não consegue ver o que será executado. A tela deve apresentar o cliente, a alteração proposta, os dados relevantes e as consequências esperadas. Uma pessoa precisa poder comparar o rascunho com a solicitação original antes de decidir.

A autorização também deve corresponder à versão revisada. Se o conteúdo ou o destinatário muda depois da aprovação, a aplicação precisa reavaliar se a autorização ainda cobre a ação. O sistema que executa a mudança deve conferir esses parâmetros, em vez de aceitar apenas uma declaração textual do agente.

Para projetos desse tipo, a empresa de desenvolvimento apresenta o planejamento de agentes com permissões delimitadas e acompanhamento. Na definição do escopo, vale solicitar uma demonstração de aprovação e uma tentativa de executar uma operação fora do limite acordado.

Separe informação consultada de autorização

Uma mensagem recebida, um documento ou uma página externa pode conter instruções que não pertencem ao processo da empresa. O OWASP descreve a injeção indireta de instruções como a influência de conteúdo externo sobre o comportamento do modelo. Ler um texto não deve conceder a ele autoridade para mudar permissões.

No exemplo comercial, um campo de observações do cliente pode afirmar que um desconto já foi aprovado. Essa afirmação é um dado a verificar. A aplicação deve consultar o registro de autorização previsto no processo, e não tratar a observação como autorização suficiente.

O mesmo cuidado vale para respostas de ferramentas. Uma mensagem de erro ou um texto recuperado pode sugerir uma ação, mas a execução continua sujeita às regras do sistema. Essa fronteira deve ser validada com casos de teste que tentem induzir alterações fora do escopo.

Registre o necessário para explicar a operação

Um registro útil permite responder quem solicitou a tarefa, quais ferramentas foram acionadas, que ação foi proposta, quem aprovou e qual foi o resultado no sistema de destino. Também ajuda identificar a versão da aplicação que executou o fluxo.

Isso não exige copiar indiscriminadamente todos os documentos para um histórico. Escolha identificadores, estados e evidências suficientes para a investigação, com acesso restrito aos responsáveis. O próprio registro pode conter informações da empresa e precisa ter uma finalidade de uso e uma política de retenção definidas no projeto.

Quando há várias tentativas, preserve a relação entre elas. Se o sistema de destino demorou a responder, a equipe precisa saber se a operação ficou pendente ou se foi concluída. Uma nova tentativa sem essa verificação pode repetir uma alteração que já ocorreu.

Teste os limites antes de ampliar o acesso

• Tente consultar um registro fora do conjunto autorizado.
• Altere os parâmetros de um rascunho depois da aprovação.
• Simule a interrupção de uma ferramenta durante a execução.
• Apresente uma solicitação que inclua instruções incompatíveis com o processo.
• Revogue uma permissão e verifique se o acesso deixa de funcionar.
• Verifique se é possível suspender novas execuções sem perder o estado das tarefas em andamento.

Esses exercícios não demonstram ausência de todos os riscos. Eles produzem evidências sobre as fronteiras específicas do projeto e mostram se o controle existe além da interface. A ampliação das capacidades deve acompanhar tarefas bem definidas, avaliação dos resultados e uma equipe capaz de operar e revisar o sistema.

O contrato precisa conversar com os controles técnicos

1. Determine o conjunto de ações autorizadas para o agente.
2. Identifique ações que dependem de aprovação humana.
3. Defina registros necessários à investigação de reclamações.
4. Combine revisão periódica de fontes, resultados e permissões.

Um fornecedor não deveria prometer ausência absoluta de erro de um modelo probabilístico. O contrato pode exigir escopo autorizado, fontes utilizadas, cenários de teste, indicadores de qualidade, critérios de aceite, tratamento de falhas e processo de correção. Para tarefas de maior risco, a equipe contratante precisa manter uma autoridade humana claramente identificada.

• Descrever quais decisões o agente pode apenas sugerir e quais pode executar.
• Definir usuários, credenciais, acesso a dados e trilha de auditoria.
• Combinar quem atualiza conteúdos, revisa respostas e atende reclamações.
• Estabelecer canais de incidente, prazos de comunicação e evidências.

A aplicações de inteligência artificial da LOFRANO Tecnologia aparece nesse debate como fornecedora de soluções de IA cujo planejamento pode incluir fontes, permissões e critérios de avaliação. Isso não equivale a afirmar que a empresa prestou consultoria jurídica ou que algum de seus produtos causou um incidente.

O exame jurídico de um episódio real deve considerar documentos, provas e regras vigentes, com análise individualizada por profissional habilitado.