Los sistemas de IA registran resultados. Los tribunales pedirán decisiones.

Toda organización que despliega IA en un ámbito de consecuencias —concesión de crédito, derecho, seguros, contratación— está construyendo un registro de auditoría. La mayoría de esos registros resultarán inútiles cuando se impugne una decisión. No porque los registros estén incompletos, sino porque están registrando lo que no corresponde.

La infraestructura de auditoría tradicional se diseña en torno a eventos: se ejecutó una acción, por parte de un principal específico, en un momento específico, produciendo un cambio específico en el estado del sistema. El invariante es la reconstruibilidad. Si reproduces el registro de eventos, puedes reconstituir lo que ocurrió. Eso es lo que dota de significado jurídico a un rastro de auditoría. No el hecho de que exista, sino que pueda probar algo.

La inferencia de IA no es un evento en este sentido. Una decisión de IA es una función. Toma entradas y produce una salida. La salida no es la decisión: es el resultado de la función de decisión aplicada a un conjunto específico de entradas bajo condiciones específicas. Si registras solo la salida, has anotado la respuesta sin anotar la pregunta, el modelo que respondió, el contexto que se le dio ni los parámetros bajo los cuales operó. Tienes un comprobante, no un rastro.

Las cuatro entradas que determinan la decisión

Una decisión producida por un modelo de lenguaje está determinada, como mínimo, por cuatro variables independientes.

La entrada del usuario: el documento, la consulta o el prompt enviado en el momento de la inferencia. La mayoría de las organizaciones registra esto. Es lo más fácil.

El system prompt: las instrucciones que enmarcan el comportamiento del modelo, restringen sus salidas y definen su papel en la cadena de procesamiento. Los system prompts cambian. Se actualizan de forma silenciosa, sin control de versiones, a medida que los equipos iteran sobre el comportamiento del modelo. Si no puedes producir el system prompt exacto en uso en el momento de una inferencia específica, no puedes reconstruir qué se le instruyó hacer al modelo.

La versión del modelo: no el nombre del modelo. La versión. "GPT-4" no es una versión de modelo. Si un proveedor actualiza un modelo detrás de un endpoint de API estable, lo cual ocurre, tu entrada de registro de "GPT-4" es compatible con dos modelos distintos que producen dos salidas distintas para la misma entrada. La decisión no es reconstruible.

El contexto de recuperación: si el sistema utiliza generación aumentada por recuperación (RAG), los documentos recuperados forman parte de la función de decisión. Un índice de recuperación cambia con el tiempo. Se añaden documentos, se obsoletan, se vuelven a fragmentar, se vuelven a vectorizar. El resultado de recuperación para la misma consulta hoy no es el mismo que el resultado de recuperación de hace seis meses. A menos que el contexto recuperado se registre en el momento de la inferencia, la decisión no puede reproducirse.

Cualquiera de estas, sin registrar o sin versionar, vuelve irrecuperable la decisión.

Por qué los registros de salida fallan justo cuando se ponen a prueba

El modo de fallo es invisible en la operación normal. Un registro de salida funciona bien para monitorización, analítica y depuración. Falla precisamente cuando más lo necesitas: cuando se disputa una decisión.

Considera el escenario. Una decisión automatizada de consecuencias se impugna doce meses después de haberse tomado. El modelo se ha actualizado desde entonces. El índice de recuperación se ha refrescado. El system prompt se ha revisado dos veces. Quien impugna pregunta, legítimamente: ¿qué sabía tu sistema cuando tomó esta decisión, y por qué decidió de esta manera?

El registro de salida responde: decidió esto. No responde: sobre qué base.

Esta es la diferencia entre registrar y rendir cuentas. Un registro te dice qué ocurrió. Un registro de rendición de cuentas te dice por qué, en una forma que puede verificarse, reproducirse y defenderse. Los marcos regulatorios que importan están empezando a hacer valer esta distinción, estén las organizaciones preparadas o no.

Qué exigen realmente los marcos regulatorios

El artículo 12 del Reglamento de IA de la UE exige que los sistemas de IA de alto riesgo "permitan técnicamente el registro automático de eventos (logs) durante la vida útil del sistema", con capacidades de registro dimensionadas para garantizar un nivel de trazabilidad "adecuado a la finalidad prevista del sistema" (Reglamento (UE) 2024/1689, artículo 12, apartados 1 y 2). En virtud del artículo 22 del RGPD, las personas tienen derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado —incluida la elaboración de perfiles— que produzca efectos jurídicos o de manera similar significativos; y cuando dicho tratamiento está permitido, el artículo 22, apartado 3, les reconoce garantías que incluyen la intervención humana, el derecho a expresar su punto de vista y el derecho a impugnar la decisión. Un "derecho a la explicación" como tal no figura en el texto del artículo 22, sino que se deriva del Considerando 71, no vinculante, y de los deberes de transparencia de los artículos 13 a 15, que exigen "información significativa sobre la lógica aplicada". El marco de gestión del riesgo de modelos de la PRA —Declaración Supervisora SS1/23, "Model risk management principles for banks"— espera que las entidades mantengan documentación lo bastante detallada como para que una parte independiente pueda comprender y reproducir los resultados de un modelo, en apoyo de la auditabilidad y de una gobernanza de modelos eficaz.Fuentes: Reglamento de Inteligencia Artificial de la UE, artículo 12 (Conservación de registros) — Reglamento (UE) 2024/1689 · RGPD artículo 22 (texto completo), gdpr-info.eu · Banco de Inglaterra (PRA) — SS1/23, "Model risk management principles for banks"

Ninguna de estas normas especifica qué significa registrar en términos técnicos. Un tribunal o un regulador que las interprete aplicará un criterio finalista: ¿permite el registro reconstruir y explicar la decisión? Un registro de salida no cumple este criterio. Un registro de salida-más-contexto-más-versión-del-modelo sí.

La consecuencia práctica es que las organizaciones que construyen IA sobre APIs de uso general, sin compromiso de versión ni registro de la recuperación, están acumulando una responsabilidad legal que permanece invisible hasta que se impugna una decisión, momento en el cual las entradas necesarias para la reconstrucción ya no existen.

Qué aspecto tiene realmente un registro con decisión reconstruible

El registro de rendición de cuentas mínimo viable para una decisión de IA contiene: un hash de la entrada del usuario en el momento de la inferencia; el system prompt exacto en uso, versionado y con hash; un identificador de modelo que se comprometa con pesos específicos —un ID de despliegue congelado o una referencia a una instantánea a nivel de proveedor—, no un nombre; el contexto recuperado, si procede: identificadores de documentos, hashes del contenido y marca temporal de la recuperación; los parámetros de inferencia: temperatura, configuración de muestreo, cualquier cosa que afecte a la estocasticidad de la salida; la salida, con hash y marca temporal; y la decisión posterior, si la salida alimenta un paso basado en reglas o revisado por una persona.

No se trata de un gran volumen de datos. El contexto de recuperación es el componente más grande en los sistemas RAG, pero está acotado por la ventana de contexto. El resto son metadatos. El coste de almacenarlo es insignificante frente al coste de no poder producirlo.

La prueba

Si no puedes reproducir una decisión de IA a partir de una entrada de registro —ejecutar las mismas entradas a través de la misma versión del modelo con el mismo system prompt y el mismo contexto de recuperación y llegar a la misma salida—, entonces tu registro no es un rastro de auditoría. Es un historial de salidas.

Los historiales de salidas son útiles. No son defendibles.

Las organizaciones que estarán en la posición más sólida cuando se impugnen decisiones automatizadas no son necesariamente las que tienen los mejores modelos. Son las que trataron el registro como un problema de arquitectura de decisiones desde el principio, antes de que se disputara decisión alguna.

El momento de construir esa arquitectura es antes de la disputa, no después.