En la IA regulada, el modelo nunca corrige su propio examen. La prueba tiene que venir de fuera

Dos anuncios de esta semana parecen no tener relación. Las herramientas de modernización de mainframe de Google usan Gemini para leer código heredado y después confían en Dual Run, una reproducción determinista de transacciones reales, para demostrar que el sistema nuevo se comporta igual. La marca de agua de texto de OpenAI llega acompañada de una lista franca de lo que la detección no puede demostrar. Si se ponen junto a lo que hemos cubierto en la última semana, aparece una regla para las organizaciones reguladas: la evidencia de que una salida de IA es correcta tiene que venir de algo independiente del modelo que la produjo.

Es un punto de vista, y diremos dónde se apoya en hechos y dónde es lectura nuestra.

La evidencia detrás de la regla

• Modernización. En el diseño de Dual Run de Google, la lectura que hace Gemini del código heredado es un conjunto de hipótesis; la prueba es lo que hacen ambos sistemas con las mismas transacciones reales. Intesa Sanpaolo describe Dual Run como la evidencia que construye para su dirección, su control interno y sus supervisores.
• Procedencia. Las propias cifras de OpenAI muestran que la detección de la marca cae de cerca del 92% al 66% cuando se sustituye el 10% de las palabras. Una señal probabilística no sostiene por sí sola una decisión sobre una persona.
• Ingeniería. En GPT-Synopsys, el modelo maneja herramientas de diseño de chips, pero las herramientas de verificación tienen la última palabra.
• Operaciones financieras. El sistema de cuentas a pagar de Snowflake mantiene deterministas la conciliación y los cálculos, y Chatham Financial rediseñó la validación de operaciones en torno a la evidencia y las excepciones.
• Personas. El estudio de IBM con responsables de recursos humanos muestra que un revisor que no puede cuestionar a la IA no es un control.

Cuatro fuentes de prueba que valen, tres que no

1. Comparación con un sistema de confianza
2. Verificador del dominio o motor de reglas
3. Conjunto de referencia hecho por expertos
4. Revisor cualificado que puede rechazar
5. El modelo revisándose a sí mismo
6. LLM juez sin calibrar
7. Benchmarks del proveedor

Vale como evidencia

Lo que vale. Una comparación determinista con un sistema en el que ya confía (Dual Run, conciliaciones, ejecuciones en paralelo). Un verificador del dominio que no comparte los modos de fallo del modelo: simuladores, motores de reglas, motores de cálculo, controles de aprobación. Un conjunto de referencia elaborado por expertos con sus propios casos, separado de todo lo que se usó para ajustar el modelo. Un revisor cualificado con tiempo, información y autoridad para rechazar.

Lo que no vale por sí solo. El modelo explicando por qué tiene razón. Otro LLM juzgando al primero, salvo que haya medido con qué frecuencia coincide con sus expertos. Los benchmarks del proveedor, que miden sus tareas, no las suyas.

Los reguladores ya hablan este idioma

Nada de esto es nuevo en los sectores regulados; la IA solo lo vuelve urgente.

En la industria farmacéutica europea, el borrador del Anexo 22 de las GMP de la UE y PIC/S sobre inteligencia artificial, cuya consulta pública se cerró en octubre de 2025 y que aún no es definitivo, se limita a modelos estáticos, que no cambian después de entrenados, en sistemas GMP con impacto en la seguridad, la eficacia o la calidad del producto, y dice que la IA generativa y los LLM no deben usarse en aplicaciones GMP críticas. Las farmacéuticas en España, que aplican las GMP europeas bajo la supervisión de la AEMPS, deberían leerlo como una señal de hacia dónde va la inspección: la evidencia de un paso con IA no puede ser la propia IA.

En banca, los equipos de riesgo de modelo conocen el principio como desafío efectivo (effective challenge): un análisis crítico hecho por personas objetivas e informadas, con capacidad de exigir cambios. Un modelo que se valida a sí mismo es lo contrario. La IA generativa usada en crédito, fraude o cumplimiento normativo se medirá con ese estándar, se la llame modelo o no.

Qué implica para la arquitectura

Nuestra lectura, y es una opinión, no un hecho: los sistemas de IA regulados que lleguen antes a producción se diseñarán como dos sistemas, uno que produce y otro que demuestra. El que demuestra suele ser antiguo (una conciliación, un protocolo de validación, un paso de revisión) y deliberadamente no es IA. Inclúyalo en el presupuesto desde el principio; ahí se va la mayor parte del esfuerzo, y es lo que leerá el auditor.

Qué hacer ahora

1. Para cada paso con IA en un proceso regulado, identifique la evidencia independiente de que su salida es correcta.
2. Si la única evidencia es el modelo o un modelo parecido, no deje que el paso pase de “recomendar”.
3. Construya conjuntos de referencia con expertos a partir de sus casos y manténgalos fuera del ajuste del modelo.
4. Calibre cualquier LLM juez frente a revisores cualificados antes de confiar en él.
5. Dé a los revisores autoridad y tiempo para rechazar, y mida con qué frecuencia lo hacen.
6. Prepare el expediente de evidencia para auditoría durante el proyecto, no después de la puesta en producción.

En resumen

La IA lee, redacta, traduce y transforma más rápido que cualquier equipo. En una organización regulada, sigue sin poder ser su propio testigo. Diseñe cada uso en producción para que la prueba venga de fuera del modelo, y la conversación con riesgos, calidad y el supervisor será mucho más corta.