«Lo de los riesgos ya lo tenemos: bajamos una plantilla y rellenamos las casillas.» Lo he visto las veces suficientes como para saber cómo acaba. Semanas antes de la evaluación de conformidad, alguien descarga una plantilla de gestión de riesgos de IA, marca las casillas de siempre —«sesgo», «falta de robustez», «falta de transparencia»— y la guarda con la etiqueta de artículo 9, hecho. La intención es buena: poner orden donde había niebla. Pero esa plantilla describe los riesgos de un sistema de IA. No los del tuyo.
Y la diferencia no es de matiz. Es la que separa aprobar de suspender.
No es que la plantilla esté mal escrita. Es que está escrita para nadie. «Sesgo» es un riesgo de cualquier sistema que aprende de datos; «falta de robustez», de cualquiera que generalice. Son verdaderos y son inútiles, porque no dicen qué se rompe en tu sistema, cuándo y sobre quién. El artículo 9 del Reglamento de IA no se conforma con la categoría. Quiere la cadena.
Lee el artículo con ojos de ingeniero y no pide un documento, pide un trabajo. Identificar y analizar los riesgos conocidos y razonablemente previsibles para la salud, la seguridad y los derechos fundamentales —los que nacen del uso previsto del sistema y del mal uso que cabe esperar—. Hay tres ejes de concreción ahí dentro que ninguna plantilla descargada puede tener, porque no te conoce: tu caso de uso, tus datos y las personas afectadas. La plantilla trae las tres columnas vacías. Llenarlas es el trabajo.
Aquí está lo que distingue un mapa de un inventario. Un mapa traza cadenas causales: qué falla, en qué condición, con qué consecuencia, sobre qué persona. «Sesgo en los datos» no es un riesgo; es una etiqueta. El riesgo es otra cosa: en un cribado de currículums, que la muestra de entrenamiento apenas contenga trayectorias con interrupciones por cuidados —fallo—, de modo que ante un currículum con un paréntesis de dos años —condición— el modelo lo puntúe sistemáticamente por debajo —consecuencia—, y a una mujer que volvió de una baja de maternidad se le cierre la criba antes de que un humano la lea —afectado—. Eso es un riesgo de tu sistema. Tiene dueño, tiene disparador y tiene a quién le pasa. Un evaluador no interroga la etiqueta. Interroga la cadena: «esto, ¿por qué le aplica a su sistema, y a quién se lo hace?». Si la respuesta es la casilla genérica, ya has perdido.
Y el detalle que decide cuál es tu cadena puede ser uno solo. Coge el mismo modelo de cribado, la misma tubería por dentro, los mismos datos. En un caso, la salida sugiere: ordena los currículums y un reclutador los lee todos antes de descartar a nadie. En el otro, la misma salida decide: por debajo de cierta puntuación, la criba se cierra sola y nadie vuelve a abrir esa carpeta. La consecuencia sobre la mujer del paréntesis de dos años solo se materializa en el segundo —porque allí el modelo es el último que la mira—. Mismo modelo, mismos datos, riesgo distinto. A uno le aplica esa cadena y al otro no, y la diferencia es una sola: si después del modelo hay un humano que de verdad lee, o no lo hay. Una plantilla descargada no sabe en cuál de los dos estás. Tú sí.
Y hay un segundo modo de fallar, más silencioso. La plantilla nace huérfana. Vive en un documento aparte, desacoplada de cómo está construido el sistema —de la versión de datos con la que se entrenó, del modelo que decide, del código que los une—. La pregunta de la pieza anterior vuelve aquí con otra cara: si no puedes atar un riesgo a la terna que lo genera, ese riesgo es una afirmación, no una propiedad del sistema. Cuando el modelo cambie —y cambiará—, el documento se queda hablando de un sistema que ya no existe. Por eso el mapa de riesgos pertenece al mismo flujo donde vive el modelo —a eso apunta GovOps—, no a un documento aparte que envejece solo.
El tercero es el más humano: confundir tener una metodología con haberla aplicado. Copiar la estructura de una norma —sus capítulos, sus tablas— no es ejecutarla, igual que tener el índice de un libro no es haberlo leído. La estructura es de la norma; el contenido tiene que ser tuyo.
Entonces, ¿cómo se identifican los riesgos de tu sistema? Como un ejercicio de ingeniería, no de consultoría. A grandes rasgos:
- Delimita el uso previsto y el contexto. Quién decide qué con la salida del modelo, con cuánta autonomía, y qué pasa aguas abajo. Un mismo modelo que sugiere y un modelo que decide tienen riesgos distintos.
- Mapea a las partes interesadas afectadas y los derechos en juego. Un riesgo no se ve igual desde la sala donde se construye el modelo que desde el lado de quien lo sufre —y el equipo que entrena casi nunca está en el grupo al que el sistema puede dañar—. Por eso identificar de verdad obliga a mirar desde fuera: quiénes son las personas afectadas, qué derechos ponen en juego y, cuando se puede, consultarlas o representar su punto de vista —la propia guía de método lo pone como primer paso del proceso—. La evaluación de impacto sobre los derechos fundamentales entra aquí como entrada, no como anexo: te dice a quién le cae la consecuencia, y a menudo te descubre un riesgo que desde dentro no veías.
- Analiza las fuentes de riesgo capa por capa. En los datos: representatividad, sesgo, deriva. En el modelo: robustez, casos límite, comportamiento ante lo que nunca vio. En la frontera humano-sistema: el exceso de confianza, el sesgo que se automatiza al delegar.
- Razona las cadenas causales y prioriza. Fallo → condición → consecuencia → afectado, ordenadas por gravedad y por lo probable que sea cada una. No es enumerar todo lo imaginable; es acotar lo que de verdad puede pasar en tu sistema.
Y para el paso tres, un atajo honesto: no construyas el catálogo de categorías desde cero. Contrástalo con uno serio y abierto —el AI Risk Repository del MIT, que reúne más de setecientos riesgos de IA de más de cuarenta marcos, ordenados por causa y por dominio—. Pero ten claro qué es: el universo de lo que puede salir mal, no lo que sale mal en tu sistema. Úsalo como lista de control para no dejarte ninguna familia de riesgos fuera; luego instancia las que te aplican en su cadena causal. El catálogo te da las categorías; las cadenas las pones tú.
Cada riesgo así identificado nace ya apuntando a una decisión de diseño o a una medida de control. Pero qué se hace con él —cómo se gestiona, y por qué eso es un bucle y no un trámite— es harina del próximo capítulo.
Llegados aquí toca el paisaje de normas, porque es donde más gente se pierde —y donde más se confunden dos cosas que no son la misma—.
La guía de método para gestionar el riesgo de IA es la ISO/IEC 23894:2023 («Inteligencia artificial. Guía para la gestión del riesgo»). Es la que apoya al artículo 9: describe el recorrido —comunicar y consultar, fijar el alcance y los criterios, identificar, analizar, evaluar, tratar, seguir y revisar, y dejar registro de todo ello—. Para esta pieza nos interesa su primer tramo, el de identificar y analizar. Bebe de la ISO 31000:2018, el sustrato genérico de gestión del riesgo del que sale casi todo lo demás.
Y ojo con una confusión que veo a menudo: la guía de método para el riesgo no es lo mismo que el sistema de gestión que la envuelve —el gobierno, los roles, la continuidad—. Ese sistema de gestión responde a otra pregunta, vive en otro artículo y es harina de otra pieza. Tener uno no te dice cuáles son los riesgos de tu modelo, igual que tener una imprenta no te escribe el libro.
Y luego está la europea: la prEN 18228, de gestión del riesgo de IA, que prepara el comité conjunto CEN-CENELEC. Es la que un día dará presunción de conformidad para el artículo 9. Pero hoy es un borrador —en consulta pública hasta el 31 de julio de 2026—, y aquí conviene ser preciso con una palabra que se usa a la ligera. Ninguna de estas normas «confiere» presunción de conformidad: la apoyan. Una norma confiere presunción solo cuando se cita en el Diario Oficial de la Unión Europea, y hoy ninguna está citada para el artículo 9. Usar la 23894 o seguir el borrador de la prEN es prueba de diligencia, no un salvoconducto.
El contraste lo deja claro: en producto sanitario, la ISO 14971 —la gestión de riesgos de toda la vida— sí confiere presunción bajo su reglamento. En IA todavía no estamos ahí. Tenemos el método; no tenemos aún el atajo. Razón de más para que la identificación sea de verdad tuya y no copiada: cuando la norma armonizada llegue, te encontrará con el trabajo hecho o por hacer.
Volviendo al principio: una plantilla rellena no es un mapa de riesgos. Es la foto de un sistema cualquiera pegada encima del tuyo. Y la identificación es el primer eslabón: si arranca genérica, todo lo que cuelga de ella —el bucle que la gestiona, la supervisión que la vigila, la evidencia que la prueba— hereda el vacío. Por eso este eslabón no es papeleo. Es la base de ingeniería sobre la que se sostiene lo demás.
Hay tiempo: la obligación para el alto riesgo del Anexo III no se aplica hasta el 2 de diciembre de 2027 —una fecha que los colegisladores acaban de dejar firme al aprobar la reforma del Reglamento—. Pero los riesgos del sistema que diseñas este trimestre son los que tendrás que tener mapeados —y vivos— entonces.
Identificar bien los riesgos es solo el paso uno. El siguiente es no dejarlos morir en un documento: gestionarlos como un bucle que dirige el diseño, no como un informe del último día. De eso va la próxima pieza.
Pruebas, no promesas: un riesgo identificado de verdad —con su cadena, atado a la versión que lo genera— es una prueba; una casilla copiada es una promesa. Y la evidencia se genera, no se redacta. Si construyes IA que decide sobre personas, suscríbete y seguimos.
— Rodrigo