Como Impedir que o ChatGPT Alucine em Trabalhos de Conformidade Regulada

Uma equipa de Jogo Responsável (RG) do Reino Unido veio até nós com um problema que qualquer pessoa que automatize trabalho regulado irá reconhecer. Eles usam o ChatGPT para transformar gatilhos automáticos de conformidade em notas formais de analista. Quando um cliente ultrapassa um limiar — faturação a subir mais de 100% em 30 dias, uma sessão a decorrer para além do seu limite — um analista copia os dados relevantes para o ChatGPT, e o modelo, seguindo um prompt pré-carregado, redige uma nota para o ficheiro de conformidade do cliente.

Essa nota não é um rascunho de e-mail. É um documento legal revisável pela UK Gambling Commission. E, ao fim de algum tempo, o ChatGPT começou a alucinar números, a omitir informação-chave, a inserir travessões que quebravam o estilo institucional e a desviar-se silenciosamente das regras ao longo da tarde. Num ficheiro regulado, cada uma dessas falhas é uma questão de conformidade.

A pergunta que nos colocaram era simples: é possível obter, de todo, a consistência que o trabalho regulado exige de um modelo de linguagem? A resposta é sim — mas não ajustando a redação de um prompt dentro de uma janela de chat. É preciso uma mudança de arquitetura mais uma reescrita disciplinada. Este artigo percorre o método exato, usando o fluxo de trabalho de RG como exemplo prático, para que possa aplicá-lo a qualquer processo regulado onde a mesma entrada deve produzir sempre o mesmo resultado fiável.

Por que o ChatGPT se desvia em trabalho regulado

Antes de corrigir seja o que for, ajuda nomear com precisão os modos de falha. No fluxo de trabalho de RG reproduzimos cinco formas distintas em que o resultado falhava, desde as críticas até às meramente incómodas.

As duas críticas formam o par perigoso. Números alucinados colocam um valor errado de depósito ou de lucro-e-perda num ficheiro regulado — o modelo preenche uma lacuna a partir da memória de treino em vez de admitir que os dados estão ausentes. A inversão de convenção é mais subtil: este operador usa uma convenção invertida de lucro-e-perda, em que um número positivo significa que o cliente está a perder. É contraintuitivo, pelo que o modelo reverte para a convenção padrão que aprendeu no treino e escreve que um cliente está a perder quando na verdade está a ganhar.

Os problemas de alta severidade — travessões que violam o estilo institucional e o desvio de sessão em que as regras são ignoradas mais tarde no dia — não colocam um número errado no ficheiro, mas corroem a confiança no resultado e criam retrabalho. O problema médio, nomes informais de intervenções em vez dos termos regulatórios exatos, corrompe silenciosamente o registo de conformidade.

A causa raiz é a falta de statelessness

Quatro dessas cinco falhas partilham uma única causa raiz. Numa única sessão de ChatGPT, cada caso revisto é adicionado à janela de contexto. Ao rever o caso um, o modelo vê o prompt e um caso. Ao chegar ao caso quinze, vê o prompt mais o resíduo estatístico de catorze trocas anteriores. As regras do prompt continuam lá, mas competem com uma pilha crescente de contexto, e a atenção a elas decai.

É por isso que o mesmo prompt produz uma nota perfeita às 9h e uma falha às 16h. A correção arquitetural é a statelessness: cada caso deve ser uma chamada completamente nova e isolada, que vê apenas o prompt travado e o caso atual. Nada transita de um caso para o outro. Um agente de IA configurado desta forma dá ao prompt a mesma atenção no caso cinquenta que deu no caso um.

A statelessness é necessária mas não suficiente. Elimina o desvio, mas reproduzirá fielmente um prompt mau em cada chamada. Por isso, o próprio prompt tem de ser reforçado.

Pronto para expandir seu negócio?

Comece seu teste gratuito hoje e veja resultados em dias.

Solicitar demo Entrar

Passo 1: Reforçar o prompt para primazia e recência

Os modelos de linguagem não ponderam todas as linhas de um prompt por igual. A atenção tem, grosso modo, forma de U — mais forte no início e no fim, mais fraca no meio. O prompt original de RG lutava contra isto. A sua regra mais importante, a convenção invertida de lucro-e-perda, estava no meio do prompt, indicada uma única vez. A proibição de travessões era a última linha, também indicada uma única vez.

A reescrita moveu as regras críticas para onde o modelo realmente olha e reformulou as partes fracas do prompt de sistema . Eis o que mudou e porquê.

A maior lição aqui: adjetivos vagos não são instruções. Dizer a um modelo para ser “natural” incentivava ativamente os travessões e os floreios retóricos que quebravam o estilo institucional. Substituir isso por regras concretas e testáveis foi o que tornou o estilo consistente.

Passo 2: Lidar com dados ausentes em vez de os inventar

A alucinação é muitas vezes enquadrada como um defeito do modelo. Em trabalho estruturado, é normalmente um defeito do prompt: o prompt nunca disse ao modelo o que fazer quando um campo está ausente, pelo que o modelo fez o estatisticamente provável e produziu um valor plausível.

A correção é um protocolo de dados ausentes. Divida os seus campos em obrigatórios e opcionais. Os campos opcionais são omitidos silenciosamente quando ausentes. Os campos obrigatórios fazem o oposto — se um estiver em falta, o modelo tem de parar e pedi-lo num formato exato em vez de gerar uma nota. Essa única regra converte uma alucinação silenciosa num pedido visível e auditável de mais dados. É a diferença entre um número errado num ficheiro regulado e uma nota que nunca chegou a ser produzida porque a entrada estava incompleta.

Junte-se à nossa newsletter

Receba gratuitamente as últimas dicas, tendências e ofertas.

Endereço de e-mail

Inscrever-se

Passo 3: Travar a configuração do agente

Com um prompt reforçado, o próprio agente tem de ser travado para que nada reintroduza variabilidade. O fluxo é deliberadamente minimalista — três nós e nada mais.

As escolhas de configuração que fizeram a diferença:

• Prompt de sistema no campo de Mensagem de Sistema, nunca no campo de Entrada, para que seja lido como instruções e não como dados.
• Temperatura 0,2. Baixa o suficiente para máxima consistência, alta o suficiente para evitar prosa robótica. Zero era demasiado rígido; um era demasiado criativo.
• Nenhuma ferramenta associada. Extratores de ficheiros e URLs introduzem imprevisibilidade e podem contornar o raciocínio do agente. Para esta tarefa, o modelo não precisa de nada além do prompt e do caso colado.
• Máximo de tokens deixado no padrão. Limitar os tokens fazia com que as notas fossem truncadas a meio de uma frase, e uma nota truncada num ficheiro de cliente é, em si mesma, um risco regulatório.
• Uma instrução de arranque silencioso no topo do prompt, para que o agente não confirme as regras de volta ao analista quando o fluxo é carregado pela primeira vez.

A única regra operacional que mais importa

Todas as correções acima são anuladas por um mau hábito: reutilizar o mesmo chat. A regra operacional mais importante para a equipa de analistas é iniciar uma nova conversa para cada caso. Nunca continuar a rever casos na mesma janela. Esta é a regra que elimina o desvio de sessão — a causa raiz da maioria das falhas originais — e não custa nada de seguir.

Será que funciona mesmo? 9 modelos, 27 execuções

Um método só é tão bom quanto a evidência que o suporta. Testámos nove modelos face ao prompt reforçado, usando um caso real idêntico (um gatilho de Intensidade de Jogo com histórico prévio de duração de sessão) em três execuções cada — 27 execuções no total — e pontuámos cada execução em relação a 16 critérios de conformidade.

Ao longo das 27 execuções, nenhum modelo pronto para produção alucinou um número, inverteu a convenção de P/L, usou um travessão ou truncou o resultado. O prompt reforçado eliminou todos os modos de falha originais nos modelos que se qualificaram. As diferenças que restaram diziam respeito a profundidade analítica e consistência, não a correção.

As desqualificações são instrutivas. O Claude Sonnet 4.6 produziu uma prosa bonita mas confundiu o limiar do gatilho com o limite de depósito — um número factualmente errado num ficheiro regulado, o que é desqualificante independentemente da qualidade da leitura. A oscilação de execução para execução do DeepSeek (6, 8,5, 9) é o verdadeiro problema: em trabalho regulado, qualidade que depende de sorte não é qualidade nenhuma.

O custo não é a restrição

É tentador otimizar pelo preço, mas os números desaconselham isso. Mesmo o modelo mais caro pronto para produção, o Claude Opus 4.8, custa cerca de seis cêntimos por nota. Para uma equipa que revê 50 casos por dia, isso é menos de $90 por mês. O custo de uma única constatação regulatória decorrente de uma nota incorreta ofuscaria o custo anual de qualquer modelo da lista. Para conformidade regulada, escolha o modelo mais fiável que puder, não o mais barato.

Como é uma nota reforçada

A melhor nota individual entre as 27 execuções veio do Claude Fable 5. Repare no que faz: indica a posição na convenção correta, cita os números verbatim, usa o nome exato da intervenção e — de forma crítica — explica por que a escalada seria desproporcionada em vez de simplesmente declarar um resultado.

The customer is currently in a winning position of £1,612.50 with an account balance of £8,962.50, which represents an improvement on the winning position of £1,275.00 recorded at the previous review… Session duration was reviewed under Session Duration Level 1 on 19/07 and again on 20/07… Given that those decisions were made within the last few days, insufficient time has elapsed to assess their effectiveness, and repeating or escalating on the same behaviour at this stage would be disproportionate… In this context, No Further Action Required is the proportionate outcome.

Esse é o padrão que o trabalho regulado exige: baseado em evidências, proporcionado, e idêntico em qualidade no primeiro caso do dia e no quinquagésimo.

Aplicar isto ao seu próprio fluxo de trabalho regulado

O gerador de notas de RG é um caso específico, mas o método generaliza-se a qualquer processo em que um modelo de linguagem deva produzir um resultado fiável e repetível sobre dados regulados ou de alto risco:

1. Saia da janela de chat. Execute cada caso como uma chamada stateless para que o contexto não se acumule nem haja desvio.
2. Reforce o prompt para primazia e recência. Coloque as regras críticas primeiro e repita-as no fim. Adicione autoverificações.
3. Dê ao modelo um protocolo de dados ausentes. Campos obrigatórios bloqueiam a geração quando ausentes; campos opcionais são omitidos silenciosamente. Nunca o deixe adivinhar.
4. Trave a configuração. Temperatura baixa e não nula, sem ferramentas desnecessárias, resultado sem limite de tokens, prompt na mensagem de sistema.
5. Teste antes de confiar. Execute o mesmo caso várias vezes em modelos candidatos e pontue-o face a critérios explícitos. A consistência entre execuções é a métrica que importa.

Faça essas cinco coisas e transformará um modelo que alucina ao final da tarde num que produz resultados prontos para auditoria todas as vezes. A consistência que o trabalho regulado exige é alcançável — é um problema de arquitetura e de engenharia de prompt, e ambos são solucionáveis.