Em 22 de maio de 2026, a Northeastern University publicou uma matéria com um título direto: o ChatGPT enfrenta uma onda de processos. Até março, pelo menos 11 ações haviam sido movidas apenas contra a OpenAI, além de outras contra a Character.AI e o Google. As teses estão avançando rápido -- morte culposa, defeito de projeto do produto, falha em alertar. Em janeiro, o caso emblemático Setzer foi encerrado com um acordo depois que um tribunal fez algo inédito: classificou a saída de um chatbot de IA como um "produto", e não como fala protegida.
Se você opera um chatbot no seu site, é tentador ler essas manchetes e relaxar. Aqueles são processos contra os laboratórios que constroem os modelos, sobre casos extremos trágicos envolvendo IA de companhia. Você só responde perguntas sobre envio. Nada disso se aplica a você.
Essa é a conclusão errada. Os processos que viram manchete são sobre fabricantes de modelos fundacionais e danos catastróficos. A exposição legal que se aplica ao seu negócio é mais antiga, mais silenciosa e muito mais consolidada. Ela tem um nome que a maioria das pessoas em suporte já conhece: a linha Air Canada.
O caso que todo dono de chatbot empresarial deveria ter decorado
Em fevereiro de 2024, um tribunal canadense decidiu uma disputa que parecia trivial. Um cliente de luto havia perguntado ao chatbot do site da Air Canada sobre tarifas de luto. O bot disse a ele que poderia reservar agora e solicitar reembolso em até 90 dias. Essa política não existia. O bot inventou.
Quando o cliente pediu o reembolso, a Air Canada recusou e argumentou, por escrito, que o chatbot era "uma entidade jurídica separada, responsável por suas próprias ações." O tribunal rejeitou isso de forma categórica. A decisão traz a frase que deveria estar colada no seu monitor:
"Não faz diferença se a informação vem de uma página estática ou de um chatbot."
A Air Canada foi condenada a honrar a política inventada e a pagar indenização, juros e custas. O valor era pequeno. O princípio não era. Um regulador olhou para um bot alucinando e disse: isso é a empresa falando. Você está vinculado ao que ele diz.
Esse princípio só se consolidou desde então. O enquadramento como "produto" no acordo do caso Setzer significa que a saída de um chatbot pode ser avaliada como qualquer outra coisa que uma empresa lança -- sujeita a teorias de responsabilidade pelo produto quando defeituosa. Os tribunais dos EUA impuseram mais de $145,000 em sanções por alucinação de IA no primeiro trimestre de 2026, incluindo uma multa recorde de $110,000 no Oregon e a primeira suspensão de licença profissional do tipo em Nebraska. Os grandes processos podem levar anos e talvez não reformulem o setor, como alertou John Wihbey, da Northeastern -- provar que uma tecnologia específica prejudicou uma pessoa específica é difícil. Mas a linha Air Canada não precisa de nenhuma teoria jurídica inédita. Ela já funciona, em tribunais de pequenas causas e em reclamações de defesa do consumidor, hoje.
Este post é sobre essa exposição do dia a dia, não sobre os litígios de manchete. Nada aqui é aconselhamento jurídico -- fale com um advogado sobre a sua situação. O objetivo aqui é mais específico e mais útil: entender exatamente como um chatbot de site cria responsabilidade legal, e quais controles realmente reduzem esse risco.
As sete formas de um bot de suporte te levar a um processo
"Alucinação" é uma única palavra para pelo menos sete modos de falha distintos, e cada um carrega um tipo diferente de risco de negócio. Um bot que inventa uma janela de reembolso é um problema diferente de um que fabrica uma instrução de segurança.
| Tipo de alucinação | O que o bot faz | Responsabilidade que cria |
|---|---|---|
| Política | Inventa um termo de devolução, reembolso ou garantia | Você pode ficar obrigado a honrá-lo (a linha Air Canada) |
| Preço | Cita um preço, desconto ou taxa que não existe | Exposição a preços enganosos e defesa do consumidor |
| Específico da conta | Declara um fato errado sobre o pedido ou saldo deste cliente | Quebra de contrato, indução a erro |
| Ação | Alega que fez algo ("seu pedido está cancelado") que não aconteceu | Falha na entrega; danos por confiança |
| Citação | Cita uma fonte, lei ou documento que não existe | Sanções em contextos regulados; perda de confiança |
| Capacidade | Promete algo que o produto não consegue fazer | Publicidade enganosa |
| Segurança | Dá uma instrução errada com consequências físicas | Negligência, responsabilidade pelo produto, o nível mais grave |
O fio condutor: a lei não se importa se foi uma IA que gerou a declaração. A FTC e as leis estaduais de defesa do consumidor proíbem práticas injustas ou enganosas, independentemente de terem sido produzidas por um humano ou por um modelo. Como colocou uma análise de responsabilidade legal, se sua IA age como agente do seu negócio, você é responsável pelo que ela comunica.
Por que um LLM cru é uma máquina de gerar responsabilidade legal
Aqui está o fato de engenharia desconfortável por trás de tudo isso. Um modelo de linguagem de grande porte é otimizado para produzir texto fluente, plausível e confiante. Ele não é otimizado para produzir texto verdadeiro. Esses dois objetivos coincidem na maior parte do tempo, o que é exatamente o que torna as falhas perigosas -- a resposta errada chega no mesmo tom calmo e autoritativo da resposta certa. Não há tremor na voz dele quando inventa a sua política de reembolso.
As pessoas presumem que a recuperação de conteúdo resolve isso. Ela ajuda enormemente, mas não é garantia. Um estudo de 2025 da Stanford sobre ferramentas de pesquisa jurídica fortemente baseadas em recuperação de conteúdo descobriu que a melhor delas estava correta e fundamentada em apenas 65% das consultas; as concorrentes ficaram em 41% e 19%. São produtos caros, construídos sob medida, com o modelo apontado para um corpus curado, e ainda assim alucinaram em um terço das perguntas. Colar um modelo de propósito geral no seu site com um prompt de sistema que diz "seja útil" não está no mesmo universo de segurança.
A lição não é "não use um chatbot." Muitas empresas resolvem a maior parte do seu volume de suporte com IA e nunca enfrentam um problema, porque restringiram o bot corretamente. A lição é que a segurança está na arquitetura em torno do modelo, não no modelo em si. Um chatbot só é tão defensável quanto os controles que você coloca entre o modelo de linguagem e o seu cliente.
Os controles que realmente reduzem a exposição
Mapeie cada controle para o risco que ele endereça. Esta é a parte que importa, e é onde a escolha de plataforma deixa de ser cosmética.
| Controle | O que faz | Risco que reduz |
|---|---|---|
| Grounding por recuperação de conteúdo | Responde apenas a partir do seu conteúdo de treinamento, não da memória do modelo | Alucinações de política, preço e capacidade |
| Pares de perguntas e respostas autoritativos | Respostas exatas, escritas à mão, que têm prioridade sobre tudo o mais | As perguntas de alto risco que você não pode errar |
| Citação de fonte | Mostra de qual documento a resposta veio | Alucinações de citação; torna a revisão possível |
| Ações em tempo real | Consulta dados reais de pedido/conta via API em vez de adivinhar | Alucinações específicas da conta |
| Transferência baseada em confiança | Encaminha intenções incertas ou de alto risco para um humano | Alucinações de ação e de segurança |
| Guardrails de saída | Bloqueia descontos inventados, URLs falsas, alegações não confirmadas | Alucinações de preço e de ação |
| Logs de conversas | Um registro revisável de cada resposta que o bot deu | Evidência, auditoria, correção rápida |
Alguns desses controles merecem mais detalhes, porque são onde a maioria das equipes investe pouco.
O grounding é o piso, não o teto. Treinar seu chatbot no seu próprio site, documentos e central de ajuda é a diferença entre um bot que responde a partir da sua realidade e um que responde a partir da média da internet. No Agentkit, isso é o padrão: um chatbot responde a partir do conteúdo em que você o treina -- páginas rastreadas, PDFs e documentos enviados, e trechos de texto. O modelo é instruído a trabalhar a partir desse corpus, em vez de improvisar. Para suporte com muitos documentos, conversar com os seus próprios documentos mantém as respostas atreladas ao arquivo de política real, não a uma paráfrase dele.
Os pares de perguntas e respostas são o seu cinto de segurança para as perguntas que não podem estar erradas. O grounding reduz a invenção, mas não a elimina. Para o punhado de perguntas em que uma resposta errada é um processo -- sua janela de reembolso, seus termos de cancelamento, uma instrução crítica de segurança -- você quer uma resposta fixa, não uma gerada. Os pares de perguntas e respostas do Agentkit fazem exatamente isso: uma resposta exata, escrita por humanos, que tem prioridade sobre qualquer outra fonte. O modelo não tem voto sobre se a sua política de devolução é de 30 dias. Você escreveu isso; o bot só lê de volta. Identifique suas dez perguntas de maior risco e trave-as como pares de perguntas e respostas antes de lançar.
Ações em tempo real trocam adivinhação por consulta. Alucinações específicas da conta -- "seu pedido foi enviado ontem" quando não foi -- vêm de um bot respondendo perguntas para as quais não tem dados. A solução é dar a ele os dados. As ações de API personalizada permitem que o chatbot chame seu sistema de pedidos, CRM ou estoque em tempo real e responda a partir do registro real. Se o dado não estiver disponível, um bot bem construído diz isso em vez de inventar um status.
A transferência para humano é um controle de responsabilidade legal, não um capricho de UX. A decisão arquitetural mais importante é o que o bot faz quando está inseguro. Um chatbot defensável escala respostas de baixa confiança e intenções de alto risco -- reembolsos, faturamento, cancelamentos, qualquer coisa relacionada à segurança -- para uma pessoa. Projetar bem esse limite é uma disciplina em si; cobrimos isso em profundidade em design de transferência para atendente humano. O bot que diz "deixa eu chamar um colega" numa disputa de reembolso é o bot que nunca inventa uma política de reembolso.
Instruções e guardrails definem os padrões do bot. Seu prompt de sistema deve dizer ao bot para se recusar a especular, nunca inventar preços ou descontos, admitir quando não sabe e permanecer estritamente dentro do seu domínio. Boa engenharia de prompt transforma "seja útil" em "seja útil, mas nunca invente uma política, e transfira para um humano qualquer coisa da qual não tenha certeza." Combine isso com restrições de domínio, para que o widget só rode nas suas próprias páginas, e limitação de taxa, para que um único usuário não consiga provocá-lo a se comportar mal, do jeito que o chatbot da DPD foi famosamente induzido a xingar clientes em 2024.
Os logs são a sua evidência e o seu sistema de alerta antecipado. Toda conversa no Agentkit é registrada. Esse registro cumpre duas funções: permite que você revise o que o bot realmente disse às pessoas (e corrija um padrão ruim antes que vire uma reclamação), e é a documentação que você vai querer se um cliente algum dia alegar que o bot prometeu algo. Revise semanalmente a taxa de respostas fundamentadas e as perguntas que dispararam a transferência para humano. O bot que está deslizando silenciosamente vai aparecer nos logs muito antes de aparecer em um tribunal.
Mais uma coisa, fácil de esquecer: mantenha a base de conhecimento atualizada. Metade da responsabilidade legal não vem de invenção, mas de declarar com confiança uma política que costumava ser verdadeira. O retreinamento automático (nos planos Standard e superiores) rastreia novamente o seu conteúdo em uma programação, para que o bot não fique citando a página de preços do trimestre passado.
Um checklist de responsabilidade legal antes do lançamento
Antes de incorporar um chatbot em uma página onde os clientes tomam decisões, percorra esta lista:
- Ele tem grounding? O bot responde a partir do seu conteúdo, não do modelo aberto. Verifique perguntando algo que não está na sua documentação -- ele deve recusar, não improvisar.
- As respostas de alto risco estão travadas? Reembolso, cancelamento, garantia, preço e qualquer instrução crítica de segurança são pares de perguntas e respostas, não texto gerado.
- Ele consulta em vez de adivinhar? Perguntas específicas de conta e pedido acionam uma API em tempo real ou são transferidas -- nunca respondidas do nada.
- Ele transfere quando está inseguro? Intenções de baixa confiança e alto risco são encaminhadas para um humano. Você testou que esse limite realmente dispara.
- Ele está delimitado? Restrições de domínio o limitam ao seu site; a limitação de taxa bloqueia abuso; as instruções proíbem preços e promessas inventados.
- Você consegue revisar? Os logs de conversas estão ativados, e alguém olha para eles em uma cadência regular.
- O conhecimento está atualizado? Confiante, mas desatualizado, é seu próprio modo de falha. O retreinamento automático ou uma programação de atualização manual mantêm o conteúdo vivo.
A incorporação é a parte fácil, uma vez que os controles estejam em vigor:
<script src="https://cdn.agentkit.ai/widget.js" data-chatbot="your-chatbot-id" async> </script>
Uma nota sobre escopo: isto é sobre responsabilidade civil pelo que o seu bot diz -- diferente da onda de regulação específica de IA avançando pelas assembleias estaduais, que cobrimos separadamente em o guia de leis de chatbot de 2026. Você precisa pensar nas duas coisas. Um bot pode estar totalmente em conformidade com as leis de divulgação e ainda assim te vincular a uma política de reembolso inventada.
A conclusão
Os processos contra a OpenAI e a Character.AI serão litigados por anos, e a maioria das empresas que opera um bot de suporte nunca será parte de nada parecido. Mas cada uma dessas empresas vive sob a linha Air Canada: seu chatbot fala por você, e você é dono do que ele diz. Isso não é motivo para evitar o suporte com IA. As empresas estão resolvendo a maior parte do seu volume de suporte com chatbots e economizando dinheiro de verdade com isso -- os números não estão em disputa. É motivo para tratar o bot pelo que ele legalmente é: um agente do seu negócio, implantado com o mesmo cuidado que você daria a um humano.
A diferença entre uma responsabilidade legal e um ativo é a arquitetura em torno do modelo. Baseie-o no seu conteúdo. Trave suas respostas de alto risco. Transfira quando estiver inseguro. Registre tudo. Um chatbot construído assim não só evita o tribunal -- é aquele em que os clientes realmente confiam, porque diz a verdade ou diz que não sabe.
Crie seu chatbot gratuitamente →
Não é necessário cartão de crédito.
