Registro de decisiones de IA: cómo documentar riesgos, controles y evidencias
Imagen generada con gpt-image-2.5-sunburst para InferamaFuente ↗
01

Qué es un registro de decisiones y para qué sirve

Un registro de decisiones de IA es un historial estructurado de decisiones relevantes sobre el diseño, la configuración, la validación, el despliegue y los cambios de un sistema. Su utilidad no está en acumular documentos, sino en permitir reconstruir qué se decidió, por qué, quién asumió la decisión, qué control se puso en práctica y qué evidencia respalda que ese control se verificó. Puede abarcar decisiones técnicas y organizativas, desde la elección de un umbral hasta la definición de quién revisa las salidas del sistema.

Este registro ayuda a explicar el proceso a equipos internos, auditores o autoridades, pero no constituye por sí solo una prueba de cumplimiento. Tampoco sustituye la documentación técnica, los registros operativos, la evaluación de riesgos ni las obligaciones legales que puedan aplicarse a una organización o sistema concreto. La guía de la Agencia Española de Supervisión de Inteligencia Artificial sobre registros trata obligaciones de conservación para determinados responsables de sistemas de alto riesgo; no debe extrapolarse automáticamente a cualquier herramienta de IA.

Conviene delimitar el alcance desde el principio. Indica a qué sistema y versión se refiere, qué usos previstos cubre, quién mantiene el registro y qué tipos de decisiones deben anotarse. Un cambio que no altere el comportamiento ni el uso podría dejarse documentado de manera resumida; una modificación de datos, umbrales, población usuaria o supervisión humana puede requerir una evaluación más completa. La decisión de registrar y el nivel de detalle deben ser proporcionales al impacto y al contexto, sin presentarlos como una regla legal universal.

02

Campos prácticos para documentar cada decisión

No hay un conjunto de campos que pueda declararse mínimo y suficiente para todos los sistemas, usos y obligaciones. Como base operativa, una entrada debe permitir identificar el sistema y su versión, la fecha, la persona responsable, la decisión tomada, el riesgo o necesidad que la motivó, el control asociado, la evidencia disponible y el resultado de la verificación. Añadir el estado, las limitaciones y una fecha o condición de revisión facilita el mantenimiento posterior.

Una entrada clara distingue riesgo, control y evidencia. El riesgo describe un daño posible en un contexto específico; el control es una medida concreta destinada a prevenirlo, reducirlo o detectarlo; la evidencia muestra qué se comprobó y con qué resultado. Por ejemplo, «errores en clasificación» es demasiado vago si no se identifica la población y el uso. «Se mantiene revisión humana para casos de baja confianza» describe una medida, pero aún falta precisar cómo se identifica un caso de baja confianza y cómo se demuestra que la revisión ocurrió.

Registra vínculos estables a los artefactos, no solo nombres genéricos. Una referencia útil puede incluir identificador, versión, fecha, ubicación interna autorizada y responsable de custodia. Conserva los datos personales o confidenciales con controles de acceso adecuados y evita copiar al registro contenido sensible que no sea necesario. Si una evidencia deja de estar disponible, anota la incidencia y la acción para recuperarla o repetir la comprobación.

Estructura sugerida de una entrada

Plantilla operativa adaptable. No es una lista de requisitos legales universales.

CampoQué registrarPregunta de comprobación
IdentificaciónSistema, versión, entorno y uso previsto afectados.¿Se puede saber qué configuración estaba en uso?
Decisión y motivoQué se decidió y qué datos, pruebas o criterios fundamentaron la decisión.¿Otra persona puede reconstruir el razonamiento?
RiesgoDaño posible, contexto, personas afectadas y condiciones de exposición.¿El riesgo es específico y comprobable?
ControlMedida concreta, alcance, responsable de implementación y estado.¿Se explica cómo actúa el control?
Evidencia y resultadoPrueba, revisión o registro identificable, fecha, resultado y limitaciones.¿La evidencia comprueba el control en el uso relevante?
SeguimientoAprobación, cuestiones pendientes y disparador o fecha de revisión.¿Está claro quién debe actuar y cuándo?
03

Vincular riesgos, controles y pruebas

Construye una cadena rastreable: riesgo concreto, objetivo de mitigación, control implementado, método de verificación y resultado. Cada enlace debe poder seguirse mediante identificadores consistentes. Si un control mitiga varios riesgos, registra cada relación; si un riesgo necesita varias medidas, documenta cada control y las dependencias entre ellos. Así se evita que una lista de riesgos quede separada de las actividades de ingeniería o de las decisiones de operación.

La evidencia debe corresponder a la configuración y al uso que se evalúan. Un informe de pruebas sobre una versión anterior puede servir como antecedente, pero no demuestra automáticamente la eficacia de un cambio posterior. Indica el entorno, los datos o escenarios utilizados, los criterios de aceptación, el resultado y las limitaciones. Cuando una prueba no cubre todas las condiciones reales, registra esa brecha y qué supervisión o medida adicional se aplica.

Las pruebas cuantitativas no siempre son suficientes. Para una medida organizativa —como la revisión humana— puede ser pertinente conservar procedimientos vigentes, muestras de casos revisados, registros de escalamiento y comprobaciones de que el personal recibió instrucciones. El nivel de evidencia depende del riesgo y de la afirmación que se quiere sostener. La auditoría algorítmica puede ayudar a estructurar la revisión de mitigaciones y controles, pero una recomendación general no demuestra por sí misma que una medida concreta haya sido aplicada o sea eficaz.

04

Proceso de creación y mantenimiento

Empieza con un inventario de sistemas y versiones, y define quién tiene autoridad para aprobar decisiones y quién mantiene la evidencia. Acuerda convenciones comunes para identificar riesgos, controles y artefactos. Cada entrada debe tener un responsable; un equipo genérico o un buzón sin una función asignada dificulta el seguimiento. Establece también quién puede acceder al registro y cómo se gestionan cambios y correcciones.

Anota las decisiones cuando se toman o cuando se valida la evidencia, no meses después de una auditoría. Vincula cada cambio relevante con la versión afectada y conserva un historial que permita entender cuándo se actualizó el registro. Al revisar una entrada, comprueba si el riesgo sigue vigente, si el control continúa aplicado, si la evidencia corresponde a la versión actual y si las limitaciones o acciones pendientes siguen abiertas.

No existe una frecuencia de revisión única que pueda recomendarse como obligación general para todo sistema. Define una revisión periódica proporcional al contexto y añade revisiones activadas por acontecimientos: nueva versión, cambio de datos o proveedor, modificación del uso previsto, incidentes, resultados de seguimiento que se desvíen de lo esperado o cambios normativos aplicables. Si no hubo cambios, registra la revisión y su conclusión, en vez de dejar que la ausencia de una anotación parezca una omisión.

Ciclo de vida de una entrada

Usa este flujo como procedimiento interno y adáptalo a las responsabilidades y obligaciones que correspondan.

  1. 01Identificar el sistema, la versión y el uso al que se refiere la decisión.
  2. 02Describir el riesgo o la necesidad y documentar los supuestos relevantes.
  3. 03Elegir un control específico, asignar su responsable y definir cómo se comprobará.
  4. 04Vincular la evidencia identificable y registrar método, fecha, resultado y límites.
  5. 05Aprobar la decisión, anotar pendientes y fijar un disparador o plazo de revisión.
  6. 06Reabrir la entrada ante cambios, incidentes o nueva evidencia, conservando el historial.
05

Criterios de auditabilidad y errores frecuentes

Un registro auditable se entiende sin depender de la memoria de quien lo creó. Cada entrada debe ser legible, fechada, atribuible y enlazada con artefactos accesibles para quienes tengan autorización. La completitud no significa incluir todo: significa que la información necesaria para reconstruir la decisión está presente, que las lagunas se señalan y que las afirmaciones no exceden lo que la evidencia permite concluir.

Evita controles descritos con verbos imprecisos, como «vigilar» o «mejorar», si no se explica quién los ejecuta, cuándo y cómo se verifica su cumplimiento. Evita también presentar una política, una evaluación de impacto o una casilla de aprobación como evidencia de eficacia. Esos documentos pueden ser pertinentes, pero prueban cosas distintas. La guía de auditoría de tratamientos con IA de la Agencia Española de Protección de Datos aporta contexto institucional para revisar tratamientos, pero no convierte una plantilla de registro en garantía automática de conformidad.

Antes de una auditoría, selecciona algunas decisiones y recórrelas en ambos sentidos: desde cada riesgo hasta el control y la evidencia, y desde una prueba hasta la decisión que la utiliza. Comprueba que los enlaces siguen disponibles, las versiones coinciden, los responsables están identificados y las excepciones tienen explicación. Si se detecta una brecha, regístrala como hallazgo con responsable y seguimiento; no la ocultes sustituyendo retrospectivamente una evidencia incompleta.

Revisión rápida de calidad

Criterios internos útiles para detectar entradas débiles antes de una revisión formal.

CriterioBuena señalSeñal de alerta
ClaridadLa decisión y su motivo se entienden fuera del equipo autor.La entrada usa siglas o frases sin definir.
TrazabilidadRiesgo, control y evidencia tienen identificadores y vínculos.Solo hay una lista de controles sin riesgos asociados.
CorrespondenciaLa prueba identifica versión, entorno y uso relevante.La evidencia es de otra configuración sin explicación.
ResponsabilidadHay una función o persona responsable de actuar.La responsabilidad aparece como «equipo» sin asignación.
LímitesSe anotan incertidumbres, brechas y acciones pendientes.Se declara eficacia sin informar alcance ni método.
06

Criterios prácticos para empezar

Empieza con una plantilla corta y prueba su uso en una decisión real antes de convertirla en un formulario extenso. Si un campo no ayuda a identificar, explicar, verificar o mantener una decisión, considera si debe estar en el registro o en otro artefacto vinculado. La estructura debe permitir recorrer la cadena entre riesgo, medida y evidencia sin duplicar innecesariamente la documentación técnica o los registros de operación.

Ajusta la conservación, los permisos de acceso y el nivel de detalle a las obligaciones aplicables, al tipo de datos y a las necesidades de auditoría. Consulta la documentación normativa y las instrucciones institucionales vigentes para el caso concreto: las obligaciones pueden depender de la función de la organización, del tipo de sistema y de su uso. El registro ayuda a ordenar y explicar evidencia; no reemplaza el análisis jurídico ni demuestra por sí solo que el sistema cumple.

Como criterio final, considera lista una entrada cuando otra persona autorizada pueda reconstruir qué se decidió, qué riesgo se abordó, qué control se aplicó, qué evidencia se examinó, cuáles son sus límites y cuándo debe revisarse de nuevo. Si alguno de esos elementos falta, señala la incertidumbre y asigna una acción. La transparencia sobre una brecha documentada resulta más útil que una afirmación de eficacia sin respaldo verificable.

Qué sigue abierto

  • Las fuentes aportadas no establecen un esquema universal de campos obligatorios para un registro de decisiones de IA; la plantilla se presenta como una recomendación operativa.
  • La guía de AESIA se refiere a conservación de registros en determinados contextos de sistemas de alto riesgo; no se extrapolan esas obligaciones a todos los sistemas.
  • Las fuentes disponibles no fijan una periodicidad única para revisar el registro. El calendario debe ajustarse al contexto, a los cambios y a la normativa aplicable.
  • La eficacia de un control depende del sistema, el uso previsto, la configuración y la calidad de la evidencia; los ejemplos no garantizan resultados en otros contextos.
07

Continúa explorando

07

Fuentes consultadas

03

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.

Proponer una corrección