Cómo evitar que ChatGPT alucine en trabajos de cumplimiento regulado

Un equipo de Juego Responsable (RG) del Reino Unido acudió a nosotros con un problema que cualquiera que automatice trabajo regulado reconocerá. Usan ChatGPT para convertir disparadores de cumplimiento automatizados en notas formales de analista. Cuando un cliente incumple un umbral —una facturación que sube más del 100% en 30 días, una sesión que supera su límite—, un analista copia los datos relevantes en ChatGPT, y el modelo, siguiendo un prompt precargado, redacta una nota para el expediente de cumplimiento del cliente.

Esa nota no es un borrador de correo. Es un documento legal revisable por la UK Gambling Commission. Y después de un tiempo, ChatGPT empezó a alucinar cifras, omitir información clave, insertar rayas largas que rompían el estilo corporativo y desviarse silenciosamente de las reglas por la tarde. En un expediente regulado, cada uno de esos fallos es un problema de cumplimiento.

La pregunta que plantearon era simple: ¿podemos obtener la consistencia que exige el trabajo regulado a partir de un modelo de lenguaje? La respuesta es sí, pero no ajustando la redacción de un prompt dentro de una ventana de chat. Requiere un cambio de arquitectura además de una reescritura disciplinada. Este artículo recorre el método exacto, usando el flujo de trabajo de RG como ejemplo práctico, para que puedas aplicarlo a cualquier proceso regulado en el que la misma entrada deba producir siempre el mismo resultado fiable.

Por qué ChatGPT deriva en trabajo regulado

Antes de arreglar nada, conviene nombrar con precisión los modos de fallo. En el flujo de trabajo de RG reprodujimos cinco formas distintas en las que el resultado se rompía, desde críticas hasta simplemente molestas.

Los dos críticos forman el par peligroso. Las cifras alucinadas ponen un número de depósito o de pérdidas y ganancias erróneo en un expediente regulado: el modelo rellena un vacío con memoria de entrenamiento en lugar de admitir que faltan los datos. La inversión de la convención es más sutil: este operador utiliza una convención invertida de pérdidas y ganancias en la que un número positivo significa que el cliente está perdiendo. Es contraintuitivo, así que el modelo vuelve a la convención estándar que aprendió en el entrenamiento y escribe que un cliente está perdiendo cuando en realidad está ganando.

Los problemas de alta severidad —rayas largas que violan el estilo corporativo y la deriva de sesión, donde las reglas se ignoran más avanzado el día— no ponen una cifra errónea en el expediente, pero erosionan la confianza en el resultado y generan retrabajo. El problema de severidad media, nombres informales de intervenciones en lugar de los términos regulatorios exactos, corrompe silenciosamente el registro de cumplimiento.

La causa raíz es la falta de “statelessness” (ausencia de estado)

Cuatro de esos cinco fallos comparten una misma causa raíz. En una sola sesión de ChatGPT, cada caso que revisas se añade a la ventana de contexto. Al revisar el caso uno, el modelo ve el prompt y un caso. Para el caso quince, ve el prompt más el residuo estadístico de catorce intercambios anteriores. Las reglas del prompt siguen ahí, pero compiten con un montón creciente de contexto, y la atención hacia ellas se degrada.

Por eso el mismo prompt produce una nota perfecta a las 9 de la mañana y una defectuosa a las 4 de la tarde. La solución arquitectónica es la ausencia de estado: cada caso debe ser una llamada completamente nueva y aislada que solo vea el prompt bloqueado y el caso actual. Nada se traslada de una llamada a otra. Un agente de IA configurado así presta al prompt la misma atención en el caso cincuenta que en el caso uno.

La ausencia de estado es necesaria pero no suficiente. Detiene la deriva, pero reproducirá fielmente un prompt malo en cada llamada. Así que el propio prompt tiene que endurecerse.

¿Listo para hacer crecer tu negocio?

Comienza tu prueba gratuita hoy y ve resultados en días.

Solicitar demo Iniciar sesión

Paso 1: Endurecer el prompt para la primacía y la recencia

Los modelos de lenguaje no ponderan por igual todas las líneas de un prompt. La atención tiene aproximadamente forma de U: más fuerte al principio y al final, más débil en el medio. El prompt original de RG luchaba contra esto. Su regla más importante, la convención invertida de pérdidas y ganancias, estaba en medio del prompt, formulada una sola vez. La prohibición de rayas largas era la última línea, también formulada una sola vez.

La reescritura trasladó las reglas críticas al lugar donde el modelo realmente mira y reforzó las partes débiles del prompt de sistema . Esto es lo que cambió y por qué.

La lección más importante aquí: los adjetivos vagos no son instrucciones. Decirle a un modelo que sea “natural” fomentaba activamente las rayas largas y los adornos retóricos que rompían el estilo corporativo. Sustituir eso por reglas concretas y verificables es lo que hizo que el estilo fuera consistente.

Paso 2: Gestionar los datos faltantes en lugar de inventarlos

La alucinación a menudo se plantea como un defecto del modelo. En trabajo estructurado, suele ser en realidad un defecto del prompt: el prompt nunca le indicó al modelo qué hacer cuando falta un campo, así que hizo lo estadísticamente probable y produjo un valor plausible.

La solución es un protocolo de datos faltantes. Divide tus campos en obligatorios y opcionales. Los campos opcionales se omiten en silencio cuando están ausentes. Los campos obligatorios hacen lo contrario: si falta uno, el modelo debe detenerse y solicitarlo en un formato exacto en lugar de generar una nota. Esa única regla convierte una alucinación silenciosa en una solicitud de más datos visible y auditable. Es la diferencia entre una cifra errónea en un expediente regulado y una nota que nunca se produjo porque la entrada estaba incompleta.

Únete a nuestro boletín

Obtén los últimos consejos, tendencias y ofertas gratis.

Dirección de correo electrónico

Suscribirse

Paso 3: Bloquear la configuración del agente

Con un prompt endurecido, el propio agente debe quedar bloqueado para que nada reintroduzca variabilidad. Todo el flujo es deliberadamente mínimo: tres nodos y nada más.

Las decisiones de configuración que marcaron la diferencia:

• Prompt de sistema en el campo de Mensaje de Sistema, nunca en el campo de Entrada, para que se lea como instrucciones y no como datos.
• Temperatura 0.2. Suficientemente baja para máxima consistencia, suficientemente alta para evitar una prosa robótica. Cero era demasiado rígido; uno, demasiado creativo.
• Ninguna herramienta conectada. Los recuperadores de archivos y URL introducen imprevisibilidad y pueden saltarse el razonamiento del agente. Para esta tarea el modelo no necesita nada más que el prompt y el caso pegado.
• Máximo de tokens dejado en su valor predeterminado. Limitar los tokens provocaba que las notas se truncaran a mitad de frase, y una nota truncada en el expediente de un cliente es en sí misma un riesgo regulatorio.
• Una instrucción de arranque silencioso al principio del prompt, para que el agente no confirme las reglas al analista cuando el flujo se carga por primera vez.

La única regla operativa que más importa

Cada solución anterior queda anulada por un mal hábito: reutilizar el mismo chat. La regla operativa más importante para el equipo de analistas es iniciar una conversación nueva para cada caso, sin excepción. Nunca seguir revisando casos en la misma ventana. Esta es la regla que elimina la deriva de sesión —la causa raíz de la mayoría de los fallos originales— y no cuesta nada seguirla.

¿Funciona realmente? 9 modelos, 27 ejecuciones

Un método vale lo que valga su evidencia. Probamos nueve modelos frente al prompt endurecido, usando un caso real idéntico (un disparador de Intensidad de Juego con historial previo de duración de sesión) en tres ejecuciones por modelo —27 ejecuciones en total— y puntuamos cada ejecución frente a 16 criterios de cumplimiento.

En las 27 ejecuciones, ningún modelo listo para producción alucinó una cifra, invirtió la convención de pérdidas y ganancias, usó una raya larga o truncó la salida. El prompt endurecido eliminó todos los modos de fallo originales en los modelos que calificaron. Las diferencias que quedaron tenían que ver con la profundidad analítica y la consistencia, no con la corrección.

Las descalificaciones son instructivas. Claude Sonnet 4.6 produjo una prosa hermosa pero confundió el umbral del disparador con el límite de depósito, una cifra factualmente errónea en un expediente regulado, lo cual es descalificante sin importar lo bien que se lea. La oscilación de ejecución a ejecución de DeepSeek (6, 8.5, 9) es el verdadero problema: en trabajo regulado, la calidad que depende de la suerte no es calidad en absoluto.

El coste no es la limitación

Es tentador optimizar por precio, pero las cifras juegan en contra de esa idea. Incluso el modelo listo para producción más caro, Claude Opus 4.8, cuesta aproximadamente seis centavos por nota. Para un equipo que revisa 50 casos al día, eso supone menos de $90 al mes. El coste de un único hallazgo regulatorio derivado de una nota incorrecta empequeñecería el coste anual de cualquier modelo de la lista. Para el cumplimiento regulado, elige el modelo más fiable que puedas, no el más barato.

Cómo es una nota endurecida

La mejor nota individual de las 27 ejecuciones vino de Claude Fable 5. Fíjate en lo que hace: expone la posición en la convención correcta, cita las cifras literalmente, usa el nombre exacto de la intervención y, de forma crucial, explica por qué escalar sería desproporcionado en lugar de limitarse a enunciar un 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.

Ese es el estándar que exige el trabajo regulado: basado en evidencia, proporcionado, e idéntico en calidad tanto en el primer caso del día como en el quincuagésimo.

Aplicar esto a tu propio flujo de trabajo regulado

El generador de notas de RG es un caso específico, pero el método se generaliza a cualquier proceso en el que un modelo de lenguaje deba producir un resultado fiable y repetible sobre datos regulados o de alto riesgo:

1. Sal de la ventana de chat. Ejecuta cada caso como una llamada sin estado para que el contexto no pueda acumularse ni derivar.
2. Endurece el prompt para la primacía y la recencia. Coloca las reglas críticas primero y repítelas al final. Añade autoverificaciones.
3. Dale al modelo un protocolo de datos faltantes. Los campos obligatorios bloquean la generación cuando faltan; los opcionales se omiten en silencio. Nunca dejes que adivine.
4. Bloquea la configuración. Temperatura baja no nula, sin herramientas innecesarias, salida sin límite, prompt en el mensaje de sistema.
5. Prueba antes de confiar. Ejecuta el mismo caso varias veces en distintos modelos candidatos y puntúa frente a criterios explícitos. La consistencia entre ejecuciones es la métrica que importa.

Haz esas cinco cosas y convertirás un modelo que alucina por la tarde en uno que produce un resultado listo para auditoría cada vez. La consistencia que exige el trabajo regulado es alcanzable: es un problema de arquitectura e ingeniería de prompts, y ambos son solucionables.