Un registro de riesgos no es una lista de cosas que podrían salir mal. Es un mecanismo para decidir qué riesgo acepta la organización, qué control debe demostrar, quién responde y qué señal obliga a revisar la decisión.
Esta plantilla permite crear un registro vivo para un sistema de IA concreto. El resultado debe ser una vista común para negocio, tecnología, seguridad, privacidad y cumplimiento, conectada con pruebas y decisiones operativas.
Qué es un registro de riesgos de IA
Un registro de riesgos de IA es un inventario estructurado de escenarios que pueden afectar a personas, operaciones, información, cumplimiento, seguridad o resultados empresariales durante el ciclo de vida de un sistema. Relaciona cada riesgo con causas, consecuencias, controles, evidencia, responsable, nivel residual y condiciones de revisión.
No sustituye una evaluación de impacto, un análisis de protección de datos, una revisión de seguridad ni la gestión corporativa de riesgos. Los conecta. El inventario de IA responde qué sistemas existen; el registro explica qué puede ocurrir en uno de ellos y cómo se está gestionando.
El NIST organiza la gestión de riesgos de IA en cuatro funciones —gobernar, mapear, medir y gestionar— y subraya que debe ser continua durante el ciclo de vida. Su AI Risk Management Framework es voluntario y está siendo revisado; esta plantilla toma su lógica operativa, no pretende certificar conformidad con el marco.
Plantilla: los campos mínimos
| Campo | Pregunta que debe responder |
|---|---|
| ID y sistema | ¿A qué sistema, versión y proceso pertenece el riesgo? |
| Escenario | ¿Qué puede ocurrir, por qué causa y en qué condición? |
| Activos o personas afectadas | ¿Quién o qué soportaría la consecuencia? |
| Consecuencia | ¿Qué daño operativo, económico, legal, de seguridad o de derechos produciría? |
| Uso previsto y mal uso previsible | ¿Aparece en el uso normal, en una excepción o por abuso razonablemente previsible? |
| Probabilidad y justificación | ¿Con qué evidencia se estima la posibilidad de que ocurra? |
| Impacto y justificación | ¿Qué magnitud tendría y cómo se ha determinado? |
| Riesgo inherente | ¿Cuál es el nivel antes de aplicar controles específicos? |
| Controles | ¿Qué medida preventiva, detectiva, correctiva o de recuperación se aplica? |
| Evidencia del control | ¿Qué prueba demuestra que el control existe y funciona? |
| Riesgo residual | ¿Qué nivel queda después de controles probados? |
| Propietario y aprobador | ¿Quién ejecuta el tratamiento y quién puede aceptar el residual? |
| Indicador y umbral | ¿Qué señal obliga a intervenir o reevaluar? |
| Próxima revisión | ¿Cuándo se revisa y qué evento puede adelantarla? |
| Estado y decisión | ¿Abierto, en tratamiento, aceptado, escalado o cerrado? ¿Por qué? |
Para trabajar en una hoja de cálculo, crea una columna por campo y añade enlaces a pruebas, decisiones e incidentes. No pegues documentos completos dentro del registro: conserva una referencia estable, el propietario de la evidencia y su fecha.
Cómo redactar un riesgo que se pueda gestionar
Utiliza la forma causa → evento → consecuencia. Obliga a separar el fallo técnico de su impacto real.
Si documentos externos con instrucciones maliciosas entran en la base de conocimiento, el asistente puede seguir esas instrucciones durante la recuperación, lo que podría exponer información o ejecutar una acción fuera del propósito autorizado.
«Riesgo de prompt injection» no dice qué activo está expuesto, qué acción puede ocurrir ni dónde colocar el control. La formulación completa permite decidir entre filtrar fuentes, separar instrucciones y datos, reducir permisos, validar salidas, aislar herramientas o exigir aprobación.
La identificación debe cubrir tanto el uso previsto como el mal uso razonablemente previsible. Para sistemas de alto riesgo, el artículo 9 del Reglamento europeo de IA exige un proceso iterativo durante todo el ciclo de vida que identifique, estime y evalúe riesgos conocidos y previsibles, aplique medidas y utilice información posterior a la comercialización. Fuera de ese ámbito, la misma disciplina sigue siendo útil, pero no debe presentarse como una obligación legal automática.
Ocho familias para iniciar la identificación
La taxonomía debe adaptarse al contexto. Estas familias evitan que el taller se limite a precisión y privacidad:
| Familia | Ejemplos de escenarios que conviene preguntar |
|---|---|
| Resultado y calidad | Respuesta incorrecta, omisión, degradación por segmento, falta de abstención |
| Personas y derechos | Discriminación, acceso desigual, decisión difícil de impugnar, daño reputacional |
| Datos y privacidad | Uso sin base adecuada, exposición, retención indebida, datos desactualizados |
| Seguridad y abuso | Inyección de instrucciones, privilegios excesivos, fuga, manipulación, uso malicioso |
| Operación y resiliencia | Caída de proveedor, latencia, dependencia, coste descontrolado, recuperación incompleta |
| Supervisión y organización | Revisión simbólica, falta de autoridad, automatización por costumbre, responsabilidades difusas |
| Legal y contractual | Clasificación incorrecta, transparencia insuficiente, derechos de terceros, incumplimiento sectorial |
| Proveedor y cadena de suministro | Cambio de modelo, componente vulnerable, región, subencargado, bloqueo de salida |
Para aplicaciones con modelos de lenguaje, el OWASP GenAI LLM Top 10 2026 aporta escenarios técnicos recientes. Úsalo como fuente de identificación, no como sustituto del análisis del proceso: un mismo fallo tiene consecuencias distintas en un buscador interno y en un agente con capacidad de pago.
Valorar sin fabricar precisión
Una matriz de probabilidad por impacto puede ayudar a priorizar, pero el número no es el riesgo. Define escalas observables y registra la justificación.
| Nivel | Probabilidad orientativa | Impacto orientativo |
|---|---|---|
| 1 | Excepcional en las condiciones previstas | Efecto menor, reversible y contenido |
| 2 | Poco probable, con señales o precedentes limitados | Interrupción o corrección asumible dentro del equipo |
| 3 | Plausible durante la vida del sistema | Afecta al proceso, a clientes o a información sensible de forma relevante |
| 4 | Probable sin controles adicionales | Daño grave, recuperación costosa o incumplimiento significativo |
| 5 | Esperado o ya observado | Consecuencia crítica, difícilmente reversible o extendida |
Multiplicar ambos valores produce una prioridad orientativa. No utilices el resultado para compensar un impacto inaceptable con una probabilidad incierta. Privacidad, seguridad, derechos fundamentales o seguridad física pueden requerir una regla de escalado independiente.
La ISO 31000:2018 sigue vigente en agosto de 2026, aunque existe una revisión en desarrollo. La norma ofrece principios y un proceso general —identificar, analizar, evaluar, tratar, monitorizar y comunicar—, pero no es certificable. La organización debe alinear las escalas con su marco corporativo y apetito de riesgo.
Del control declarado al control demostrado
Clasifica cada control por su función y exige una prueba:
- Prevenir: permisos mínimos, separación de datos e instrucciones, límites de uso o diseño del flujo.
- Detectar: evaluación automática, muestreo, alertas, revisión de registros o monitorización de deriva.
- Contener: modo seguro, límites de gasto, aislamiento de herramientas o bloqueo de acciones.
- Corregir: revisión humana, restauración, rectificación de datos o reversión de una decisión.
- Recuperar: continuidad, exportación, copia verificable, proveedor alternativo o procedimiento manual.
- Aprender: análisis de incidentes, actualización de pruebas, control de versiones y comunicación a afectados.
«Hay supervisión humana» no es evidencia. La evidencia puede ser una prueba de que el revisor recibe información suficiente, dispone de tiempo, detecta el caso, puede detener la acción y utiliza esa autoridad. La guía sobre human in the loop explica por qué una aprobación sin capacidad real de intervención produce una falsa sensación de control.
Riesgo inherente, residual y aceptado
El riesgo inherente describe la exposición antes de controles específicos. El riesgo residual se estima después de controles implementados y probados. El riesgo aceptado es el residual que una persona con autoridad decide asumir durante un periodo y un alcance definidos.
No marques un control previsto como si ya funcionara. Durante un piloto pueden coexistir tres estados: diseñado, implementado y validado. Solo el tercero justifica reducir la valoración con evidencia.
La aceptación debe registrar quién decide, hasta cuándo, con qué límites y qué señal la invalida. Aceptar riesgo no significa cerrar la fila; significa acordar las condiciones bajo las que el sistema puede seguir operando.
Ejemplo ilustrativo: tres filas de un asistente interno
| ID | Escenario | Control principal | Evidencia | Residual | Señal de revisión |
|---|---|---|---|---|---|
| R-01 | Una respuesta cita una política antigua y provoca una gestión incorrecta | Fuentes con propietario y vigencia; respuesta obliga a citar | Prueba mensual por fuente y registro de citas inválidas | Medio | Más del 2 % de citas inválidas o cambio de política |
| R-02 | Un documento manipulado induce al asistente a revelar contenido restringido | Separación de permisos, aislamiento y prueba adversarial | Casos de inyección ejecutados sobre cada versión | Alto hasta corregir | Cualquier acceso fuera del permiso del usuario |
| R-03 | Los usuarios confían en la respuesta sin comprobar casos sensibles | Etiqueta de límite, escalado obligatorio y muestreo de decisiones | Tasa de escalado y prueba de comprensión de usuarios | Medio | Descenso del escalado o aumento de correcciones tardías |
Los umbrales son ilustrativos. Deben definirse con la línea base, la exposición y el apetito de riesgo de la organización. Un único acceso no autorizado puede ser crítico aunque una tasa agregada parezca baja.
Cadencia de revisión
La revisión por calendario es necesaria, pero no suficiente. Añade eventos que reabren automáticamente el análisis.
| Momento | Qué revisar |
|---|---|
| Antes de una prueba | Escenarios, datos, permisos, controles y criterios de parada |
| Antes de ampliar usuarios o autonomía | Evidencia del control, riesgo residual y capacidad operativa |
| Tras cambiar modelo, prompt, fuente o integración | Regresiones, nuevos modos de fallo y vigencia de pruebas |
| Tras un incidente o casi incidente | Causa, alcance, contención, comunicación y controles aprendidos |
| Periódicamente en producción | Indicadores, deriva, costes, quejas, anulaciones y cambios de contexto |
| Al retirar o sustituir | Exportación, borrado, dependencias, conservación y riesgos remanentes |
El registro debe conectarse con el proceso de cambios. Si una actualización puede alterar comportamiento, permisos, población afectada o datos, no debería llegar a producción sin revisar los riesgos correspondientes.
Cuándo el registro está fallando
El registro pierde utilidad cuando todas las filas son «medias», los propietarios son departamentos, los controles no tienen evidencia o las fechas se actualizan sin revisar el fondo. También cuando solo lo ve cumplimiento y el equipo que cambia el sistema trabaja en otra herramienta sin referencias cruzadas.
No recomendamos centralizar todos los riesgos de todos los sistemas en una única tabla inmanejable. Conserva una vista corporativa resumida y registros operativos por sistema o familia, con identificadores y escalados comunes.
Preguntas frecuentes
¿Quién debe ser propietario de un riesgo de IA?
Una persona con capacidad para coordinar el tratamiento y obtener recursos, no una etiqueta como «IT» o «Legal». El propietario del riesgo puede ser distinto del responsable de ejecutar un control. La aceptación del residual puede requerir una autoridad superior según impacto y apetito de riesgo.
¿Cuántos riesgos debe contener el registro?
Los necesarios para cubrir escenarios materiales y decisiones reales. Una lista de cien riesgos genéricos puede ocultar los cinco que determinan si el sistema debe operar. Empieza por proceso, personas, datos, seguridad, operación y terceros; fusiona duplicados, conserva causas distintas cuando exijan controles diferentes y archiva con trazabilidad.
¿Debemos registrar oportunidades además de amenazas?
Puede hacerse si el marco corporativo trata riesgo como efecto de la incertidumbre sobre objetivos. Para la operación de un sistema de IA, conviene no mezclar beneficios esperados con daños potenciales en una única puntuación. Documenta ambos, pero evita que una oportunidad económica compense un riesgo de derechos o seguridad sin una decisión explícita.
¿El registro demuestra cumplimiento del AI Act?
No. Puede aportar evidencia a un sistema de gestión de riesgos, pero el cumplimiento depende del papel de la organización, la clasificación, el contexto de uso y otras obligaciones. Tras el AI Omnibus, las reglas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027 y determinadas reglas del anexo I desde el 2 de agosto de 2028, según la Comisión Europea. Revalida siempre el calendario y el texto aplicable.
¿Una herramienta GRC genérica es suficiente?
Puede serlo si permite representar sistema, versión, datos, controles, pruebas, cambios e indicadores. El problema no es la herramienta, sino perder el vínculo con la realidad técnica y operativa. Si el registro corporativo no admite ese detalle, enlázalo con evaluaciones, incidencias y documentación del sistema en lugar de duplicarlas.
Un riesgo sin señal de revisión envejece en silencio
La calidad del registro se mide por las decisiones que cambia: detener una ampliación, exigir una prueba, reducir permisos, corregir un control o aceptar de forma consciente una exposición limitada.
En INSTINTIA podemos ayudarte a convertir la arquitectura y el proceso real en escenarios, controles, pruebas y umbrales que el equipo pueda mantener después del lanzamiento.
Fuentes y lecturas recomendadas
- NIST AI Risk Management Framework y recursos de aplicación, consultados el 20 de agosto de 2026. NIST informa de que AI RMF 1.0 está en revisión.
- NIST AI RMF Core, con las funciones Govern, Map, Measure y Manage, consultado el 20 de agosto de 2026.
- Reglamento (UE) 2024/1689, texto consolidado de 27 de julio de 2026, especialmente el artículo 9.
- Comisión Europea: AI Act y calendario de aplicación, actualizado en agosto de 2026.
- ISO 31000:2018 — Risk management, versión confirmada en 2023 y en revisión en agosto de 2026.
- OWASP GenAI LLM Top 10 2026, publicado el 3 de agosto de 2026.
Fuentes y vigencia revisadas el 20 de agosto de 2026. Esta plantilla no constituye asesoramiento jurídico ni sustituye los procesos de riesgo, privacidad, seguridad o cumplimiento aplicables a cada organización.