Quem responde quando a IA aconselha mal no apoio ao cliente?

Conclusões principais

• OLG Hamm, acórdão de 12 de maio de 2026, processo 4 UKl 3/25: quem explora o sistema responde pelas afirmações falsas do chatbot, mesmo com dados corretamente carregados
• A Air Canada teve de pagar 812,02 dólares canadianos porque o chatbot prometeu uma tarifa de luto com efeito retroativo que a política não previa. O argumento de que o bot era autónomo não vingou.
• O art. 50(1) do regulamento da IA exige, desde 2 de agosto de 2026, que as pessoas reconheçam quando falam com um sistema de IA e não com um ser humano.
• As infrações ao art. 50 do regulamento da IA podem ser punidas com até 15 milhões de euros ou 3 por cento do volume de negócios anual mundial.
• Uma aprovação só é eficaz se quem verifica tiver tempo e a fonte. O enviesamento de automatização retira valor à confirmação às cegas.

Três tipos de erro. Três consequências diferentes.

Nem todos os erros da IA são iguais. Na prática distinguem-se três tipos, e o tipo decide o quanto o erro sai caro e quanta verificação merece. O primeiro tipo: uma característica de produto inventada. O Tribunal Regional Superior de Hamm (OLG Hamm) teve de decidir sobre o chatbot de uma clínica que apresentava os dois médicos da empresa demandada como especialistas em cirurgia plástica e estética e como especialistas em medicina estética. Esses títulos de especialidade não existem nesta forma ou não são usados pelos médicos. O tribunal qualificou as respostas como práticas comerciais ilícitas da empresa nos termos do § 5 Abs. 1, Abs. 2 Nr. 3 UWG (acórdão de 12 de maio de 2026, processo 4 UKl 3/25)¹.

O segundo tipo: uma informação errada sobre prazos ou preços. O Tribunal Regional de Kiel (LG Kiel) teve de decidir sobre um serviço de informação económica cuja análise automatizada comunicou por engano que a demandante seria eliminada por falta de património. A informação falsa lesou o direito de personalidade da empresa e fundamentou um pedido de abstenção contra quem explorava o serviço (LG Kiel, sentença de 29 de fevereiro de 2024, processo 6 O 151/23)². O terceiro tipo: uma promessa que ninguém consegue cobrir. O chatbot da Air Canada deu a entender a um cliente que podia pedir a tarifa de luto depois, coisa que a política real não previa. O Civil Resolution Tribunal da Colúmbia Britânica condenou a companhia a pagar 650,88 dólares canadianos de indemnização, mais 36,14 dólares de juros e 125 dólares de custas, num total de 812,02 dólares canadianos³.

Porque é que a distinção conta: uma simples informação pode ser falsa e ainda assim não vincular ninguém. Uma promessa, pelo contrário, vincula-te de imediato, porque para o exterior funciona como uma declaração da tua empresa. É precisamente por isso que os três tipos de erro exigem intensidades de verificação diferentes. Uma característica inventada é sobretudo um risco de indução em erro e de concorrência. Uma informação errada sobre um prazo ou um preço repercute-se nas relações contratuais. Uma promessa sem cobertura é o caso mais caro, porque tem de ser cumprida de imediato.

• Característica inventada: risco de indução em erro e de concorrência, como no caso dos títulos de especialidade não usados perante o OLG Hamm¹.
• Informação errada sobre prazos ou preços: interfere em relações contratuais existentes e pode lesar direitos alheios, como no caso de Kiel².
• Promessa sem cobertura: vincula a empresa de imediato, como a promessa tarifária do chatbot da Air Canada³.

Para o teu dia a dia no suporte isso significa: quanto mais perto uma resposta estiver de um preço, de um prazo ou de um compromisso vinculativo, mais alto é o nível de aprovação. Os quatro níveis estão mais abaixo.

O princípio: o bot trabalha para ti.

Nenhum dos três tribunais responsabilizou a própria IA. Isso não é acaso. Um sistema de IA não é uma pessoa jurídica e não pode ser titular de direitos nem de deveres. A responsabilidade recai sempre sobre quem explora o sistema por sua própria conta. Foi exatamente assim que três decisões de duas ordens jurídicas, duas na Alemanha e uma no Canadá, o viram de forma independente.

O OLG Hamm tratou as respostas do chatbot como práticas comerciais da própria demandada. A empresa objetara que as respostas erradas não lhe eram imputáveis como prática comercial própria. O tribunal não a acompanhou: mesmo que a demandada tivesse mandado programar o bot exclusivamente com conjuntos de dados corretos, responderia pelas indicações falsas. O chatbot também não é um terceiro na aceção da lei, razão pela qual estava vedado recorrer aos pressupostos de um dever de segurança¹.

O LG Kiel apoiou-se na decisão empresarial a montante: quem se serve voluntariamente do seu próprio software para produzir informações responde como perturbador direto pelo resultado inteiramente automatizado. O tribunal escreveu textualmente que a demandada não podia escudar-se em não ter participado nesse processo automático, porque se servira conscientemente de uma inteligência artificial².

E o tribunal da Colúmbia Britânica rejeitou o argumento de que o chatbot seria um sujeito de direito separado, responsável pelos seus próprios atos. Na decisão lê-se que um chatbot tem, é certo, uma componente interativa, mas continua a ser apenas uma parte do sítio da Air Canada, e que não faz diferença se a informação vem de uma página estática ou de um chatbot³.

O que disto é texto da lei e o que é interpretação? O texto da lei diz: § 280 Abs. 1 BGB: se o devedor violar um dever decorrente da relação obrigacional, o credor pode exigir a indemnização do dano daí resultante. Isto não se aplica se o devedor não responder pela violação⁴. Essa norma é o fundamento contratual típico do pedido quando uma informação errada do suporte prejudica a clientela. Que uma informação da IA seja imputada a quem a explora como declaração própria é, pelo contrário, interpretação retirada das decisões citadas, não texto literal da lei. E uma nota prévia: este artigo não é aconselhamento jurídico, mas uma orientação para o dia a dia do suporte.

Identificação. Obrigatória desde agosto de 2026.

Desde 2 de agosto de 2026 vigora na UE um dever de transparência que muitas equipas de suporte só tarde têm presente. O artigo 50(1) do regulamento da IA exige que os sistemas de IA destinados a interagir diretamente com pessoas singulares sejam concebidos de modo que essas pessoas sejam informadas de que estão a interagir com um sistema de IA. O dever não se aplica quando isso for evidente pelas circunstâncias para uma pessoa razoavelmente informada, atenta e avisada⁵. A data de aplicação decorre do artigo 113 do regulamento⁶.

A IHK de Schleswig-Holstein dá a este respeito uma indicação prática: o aviso deveria surgir logo no início da comunicação e não apenas nas condições gerais ou na política de privacidade. Como formulações possíveis, a IHK indica frases como: está a comunicar com um sistema de IA. Ou então: este chatbot responde ao seu pedido com a ajuda de inteligência artificial⁶.

As infrações ao artigo 50 podem ser punidas com coimas até 15 milhões de euros ou, no caso de empresas, até três por cento do volume de negócios anual mundial. Aplica-se o montante mais elevado; no caso das PME, o mais baixo⁷⁶.

• O aviso no início da conversa, não nas condições gerais⁶.
• Exceção apenas quando a participação da IA é evidente para quem usa o serviço⁵.
• Coimas até 15 milhões de euros ou três por cento do volume de negócios anual mundial, aplica-se o montante mais elevado⁶.

Na prática isso significa: o aviso de identificação pertence à própria janela de chat, visível no primeiro contacto. Um aviso no rodapé do sítio não chega. A identificação, aliás, não protege da responsabilidade por conteúdos falsos. Cumpre um dever próprio e cria clareza sobre de quem é a declaração que a resposta constitui: tua.

Sem registo não há defesa.

Quando acontece um erro, o decisivo não é se aconteceu. Decisivo é se consegues reconstituí-lo. Só com um registo da conversa, da fonte citada e da transferência podes verificar o que a IA respondeu, quando e com que base. Sem esse registo, num litígio apoias-te em afirmações, e afirmações não são uma defesa.

Três coisas têm de continuar reconstituíveis. Primeiro, a própria conversa: que pergunta foi feita, que resposta foi dada e quando. Segundo, a fonte: a partir de que artigo de conhecimento ou documento respondeu a IA, ou se não houve fonte nenhuma. Terceiro, a transferência: quando e porquê o sistema passou o caso a uma pessoa, ou se justamente não o fez apesar de dever tê-lo feito.

A isso acresce a própria aprovação. A IHK recomenda documentar quem verificou os conteúdos e quem assume a aprovação final⁶. Transpõe isso para o suporte: em cada resposta aprovada por uma pessoa deveria estar claro quem verificou e com que fontes. Num litígio, essa é a diferença entre um processo reconstituível e uma lacuna.

• Regista a conversa por inteiro: pergunta, resposta, momento.
• Guarda com ela a fonte citada: que artigo de conhecimento, que documento, ou nenhuma fonte.
• Documenta as transferências: quando, porquê, para quem.
• Documenta as aprovações: quem verificou e deu o aval⁶.

Uma palavra sobre prazos de conservação: durante quanto tempo tens de guardar conversas e registos depende dos teus deveres legais e contratuais, por exemplo do direito da proteção de dados e do direito comercial. Não indicamos aqui de propósito nenhum prazo concreto, porque a duração certa depende do caso. Regula-o de forma consciente, por escrito, e acerta-o com a pessoa responsável pela proteção de dados. Guardar pouco tempo custa-te a defesa; guardar demasiado custa-te do lado da proteção de dados.

A base de conhecimento é a alavanca da responsabilidade.

A fonte de erro mais frequente não é o modelo. É conhecimento desatualizado ou contraditório. Um agente de IA que responde a partir de uma base de conhecimento vale tanto quanto os artigos, os ficheiros PDF e as páginas que lhe dás. Um preço de 2023 num ficheiro PDF que ninguém atualizou é para a IA uma fonte tão válida como a tua página de preços atual. O erro não nasce, portanto, no modelo, mas na tua manutenção.

É justamente por isso que a indicação da fonte é a segunda alavanca em importância. Cada resposta que nomeia a sua fonte torna os erros localizáveis: a tua equipa vê logo que artigo produziu a afirmação falsa e pode corrigi-lo. O dano fica limitado às respostas alimentadas por essa única fonte. As respostas sem fonte, pelo contrário, não são verificáveis, e são precisamente essas que não deverias sequer permitir.

A lição da Air Canada mostra o que a indicação da fonte não consegue salvar. A Air Canada alegou que a política correta estava disponível para leitura no sítio. O tribunal rejeitou-o: era evidente para a Air Canada que a empresa responde por toda a informação do seu sítio, venha ela de uma página estática ou de um chatbot³. Traduzido: uma ligação correta ao lado de uma resposta falsa não te protege. Tem de estar certa a própria resposta.

• Nomeia responsáveis: quem mantém preços, prazos e condições contratuais na base de conhecimento.
• Versiona os artigos críticos: mantém reconstituíveis as alterações a preços, prazos e contratos.
• Remove ativamente as fontes desatualizadas: um ficheiro PDF antigo na base de conhecimento é uma informação falsa em diferido.
• Verifica as contradições: se dois artigos respondem de forma diferente ao mesmo tema, a IA escolhe um deles, não o certo.

Um processo de manutenção não precisa de uma grande organização. Precisa de responsáveis, de um ritmo e de uma prioridade. Os artigos críticos são todos os que dizem respeito a um preço, um prazo, um contrato ou uma promessa. Esses vão para o topo da tua lista de verificação, não para o fim.

Quatro níveis de aprovação para o dia a dia.

De tudo o que ficou dito resulta uma pergunta simples para cada resposta do suporte: quanta verificação precisa este conteúdo antes de sair? A resposta cabe em quatro níveis. Não são uma norma jurídica, mas uma tradução prática da situação de responsabilidade para o dia a dia.

1. 01Nível 1: resposta totalmente automática com fonte. Para temas não críticos em que a fonte dá a resposta de forma inequívoca: perguntas de navegação, informação geral do produto, remissões para documentos. A IA responde diretamente, citando a fonte.
2. 02Nível 2: rascunho da IA, uma pessoa verifica e envia. Para temas de risco médio: a IA apresenta um rascunho com fonte, uma pessoa lê, ajusta e envia. Nada sai de forma automática.
3. 03Nível 3: sempre uma pessoa no preço, no prazo, no contrato e em qualquer promessa. Estas respostas nunca saem de forma totalmente automática. São redigidas, ou verificadas e aprovadas, por uma pessoa, com a fonte à frente.
4. 04Nível 4: transferência para a equipa quando a fonte não chega. Se a IA não encontrar uma fonte fiável, não responde, mas transfere para uma pessoa. Isso não é uma falha, é o nível mais seguro.

A atribuição dos temas típicos fica assim: estado da encomenda, descarregamento da fatura e acesso à conta ficam no nível 1, enquanto a fonte for inequívoca. Devoluções e cancelamentos ficam no nível 2 ou 3, consoante estejam prazos em jogo. Preços, prazos de denúncia, condições contratuais e qualquer forma de promessa, desconto, gesto comercial ou condição especial ficam no nível 3. E tudo aquilo a que a base de conhecimento não responde de forma inequívoca fica no nível 4.

Uma palavra de aviso sobre o enviesamento de automatização. O Instituto Alexander von Humboldt para a Internet e a Sociedade assinala que as pessoas tendem a confiar demasiado nas decisões prévias das máquinas, o que é conhecido como enviesamento de automatização⁸. Transposto para o suporte, isso significa: um clique em aprovar, sem ter lido a fonte, não é uma verificação. É uma confirmação. A diferença é exatamente aquela que conta num litígio.

Por isso quem verifica precisa de duas coisas: tempo e a fonte à frente. Um rascunho sem indicação de fonte não é verificável; uma pessoa sem tempo não é um controlo. Se os teus processos de aprovação estiverem construídos de modo que verificar seja mais rápido do que ler, então ninguém verifica de verdade. Conta com esse tempo, senão a aprovação não vale nada.

Um exemplo da nossa própria configuração.

Para terminar, um exemplo da nossa própria oficina, não um argumento de venda. A ComLayer é uma plataforma de suporte com IA com widget, Centro de ajuda, caixa de entrada partilhada e um agente de IA que responde exclusivamente a partir do conhecimento da própria empresa. O agente só responde a perguntas quando o conhecimento guardado dá a resposta, e sustenta cada resposta com a fonte. Se o conhecimento não chegar, não adivinha, mas transfere para uma pessoa.

Como isso se reflete nos quatro níveis de aprovação: o nível 1 é a resposta automática com indicação da fonte, tal como o agente a entrega por defeito. O nível 2 é o rascunho da IA na caixa de entrada partilhada: para as perguntas em aberto há um rascunho de resposta com fonte pronto, a tua equipa lê, ajusta e envia. Os níveis 3 e 4 são regras de processo do teu lado: as questões de preço, prazo e contrato configuras no teu espaço de trabalho de modo que passem sempre pelo rascunho, e a transferência quando falta a fonte é o mecanismo técnico que concretiza o nível 4.

O que a ComLayer também não consegue fazer: tirar a quem a explora a verificação do conteúdo. Nenhuma ferramenta pode decidir por ti se o teu artigo de preços está atual ou se uma promessa tem cobertura. Isso continua a ser a tua responsabilidade, e é justamente por isso que o registo, a indicação da fonte e os níveis de aprovação contam tanto. Como se evitam tecnicamente as alucinações está explicado em evitar as alucinações no suporte; o lado da proteção de dados é tratado em IA conforme ao RGPD no apoio ao cliente.

Perguntas frequentes