De dónde nacen los riesgos

⚡ TL;DR

¿Qué es un riesgo? te dio la anatomía — probabilidad × impacto, apetito, residual, la barrera. Esta página es el paso que todo el mundo se salta: ¿de dónde nacen de verdad los riesgos? Un riesgo no es un fallo — no hay ninguna prueba en rojo, ningún cierre inesperado. Es un daño que el sistema puede causar mientras hace exactamente aquello para lo que se construyó, por culpa de sus datos, de su diseño o del uso que las personas le dan. El EU AI Act dice exactamente dónde mirar. El artículo 9(2) te obliga a identificar los riesgos conocidos y razonablemente previsibles que el sistema plantea para la salud, la seguridad y los derechos fundamentales — (a) bajo su fin previsto, (b) bajo el mal uso razonablemente previsible y (c) desde la realidad poscomercialización. Y las fuentes están dentro del sistema: los datos (art. 10), el modelo (art. 15) y la interacción persona-IA (art. 14). Los cuatro casos de la página de inicio nacieron todos en los datos. Identificar ese origen es el primer paso del bucle — antes de medir ninguna probabilidad.

🎯 Al terminar sabrás…

• Nombrar los tres orígenes del riesgo en el artículo 9(2): el fin previsto (a), el mal uso razonablemente previsible (b, definido en el art. 3(13)) y la realidad poscomercialización (c, art. 72).
• Señalar las fuentes dentro del sistema que la norma destaca — los datos (art. 10), el modelo (art. 15), la supervisión humana (art. 14) — y reconocer que la mayor parte del daño real nace en los datos.
• Decir a quién daña — a la salud, la seguridad y los derechos fundamentales — y proyectar eso con honestidad sobre los ejes de impacto del motor (individual / sociedad / organización), incluido dónde no encajan.
• Leer dónde vive todo esto en froga.yaml: intended_purpose, potential_misuses, el domain de cada riesgo y los ejes de impact — para que «identificar un riesgo» deje de ser una intuición y se convierta en una declaración.
• Explicar por qué el riesgo poscomercialización (art. 72) es el GAP honesto: este motor gobierna ex ante; la monitorización en tiempo de ejecución es una línea futura, no una capacidad actual.

Los tres orígenes — artículo 9(2)

Un sistema de gestión de riesgos, dice el artículo 9(2), debe identificar «los riesgos conocidos y razonablemente previsibles que el sistema de IA de alto riesgo puede plantear para la salud, la seguridad o los derechos fundamentales» — y nombra tres lugares donde nacen esos riesgos:

• (a) El fin previsto. El riesgo nace en el uso mismo. Un sistema que puntúa la solvencia, criba candidaturas o califica exámenes acarrea riesgo por aquello que decide sobre las personas — no porque el código tenga un defecto. El fin previsto (y el supuesto del Anexo III bajo el que cae) es lo primero que declaras, porque fija lo que está en juego.
• (b) El mal uso razonablemente previsible. El art. 9(2)(b) extiende el deber a los riesgos bajo «un mal uso razonablemente previsible» — definido en el art. 3(13) como un uso que no se ajusta al fin previsto pero que cabe esperar de un comportamiento humano normal. El reclutador que trata una puntuación de cribado como la decisión final; quien opera el modelo sobre una población para la que nunca se validó. Es previsible, así que es tu riesgo a anticipar.
• (c) La realidad poscomercialización. El art. 9(2)(c) añade los riesgos que emergen una vez desplegado el sistema, desde la vigilancia poscomercialización del art. 72 — deriva, condiciones nuevas, daños que solo afloran a escala.

Un riesgo no es un fallo

Este es el cambio de mentalidad. Un fallo es el sistema haciendo algo para lo que no se construyó. Un riesgo es el sistema haciendo exactamente aquello para lo que se construyó — y causando daño igualmente, por culpa de sus datos, de su diseño o de un mal uso previsible que nadie anticipó. Por eso una batería de pruebas en verde no basta para la IA de alto riesgo: las pruebas comprueban ¿se ejecuta como se especificó?; el riesgo pregunta ¿en qué puede equivocarse, con quién, y cómo lo sabríamos?. El origen es la respuesta a esa pregunta.

Las fuentes dentro del sistema

Los orígenes te dicen cuándo entra el riesgo; estas te dicen dónde mirar dentro del sistema. La norma señala tres:

• Los datos — art. 10 (gobernanza de datos). La mayor fuente con diferencia. Unos datos de entrenamiento sesgados, incompletos o poco representativos producen una discriminación que ninguna prueba funcional detecta. La norma exige examinar los conjuntos de datos en busca de sesgos (art. 10(2)(f)–(g)). Cada uno de los cuatro casos de la página de por qué importa nació aquí: las notas de los A-levels del Reino Unido, las puntuaciones del AMS austriaco y los perfiles de la CNAF francesa codificaron una desigualdad que ya estaba presente en los datos. Te enfrentas a este origen de lleno en la brecha de datos.
• El modelo — art. 15 (precisión, robustez, ciberseguridad). Un modelo impreciso, frágil ante casos límite o atacable es una fuente de riesgo por sí mismo — con independencia de los datos.
• La interacción persona-IA — art. 14 (supervisión humana). El riesgo también vive en cómo se usa el sistema: sin una revisión humana significativa, con sesgo de automatización, con un operador que no puede anular la decisión. El control puede ser perfecto y el riesgo seguir siendo real si una persona da el visto bueno a cada salida sin mirar.

A quién daña

El artículo 9(2)(a) es explícito sobre a quién amenaza el riesgo: a la salud, la seguridad o los derechos fundamentales. Esa es la prueba de si algo es un riesgo digno de gestionarse — no «¿es molesto para el negocio?», sino «¿puede dañar a una persona, su seguridad o sus derechos?».

Una nota honesta sobre los ejes de impacto

El motor puntúa el impacto en tres ejes — individual, sociedad, organización. Proyéctalos con cuidado: los daños del AI Act a los derechos fundamentales y a la salud o la seguridad viven en individual (y, para los efectos colectivos, en sociedad). organización es la dimensión de negocio de la ISO 23894 (el riesgo reputacional o financiero para el proveedor) — útil para priorizar, pero no es una categoría de daño del AI Act. Así que cuando leas un impacto alto en organización, ese es un riesgo para ti, no el daño regulado a las personas. Mantén separadas las dos cosas: la ley se ocupa de las personas y los derechos; el eje de organización es tu propia piel en el juego.

Cómo FROGA hace explícito el origen

El sentido de nombrar el origen es que se convierta en una declaración en froga.yaml, no en un gesto al aire:

• intended_purpose (más classification.basis) — el origen del art. 9(2)(a): para qué sirve el sistema, y la base del Anexo III que lo hace de alto riesgo.
• potential_misuses (cada uno con un addressed_by que apunta a un riesgo) — el origen del art. 9(2)(b) / art. 3(13): los malos usos previsibles que anticipaste, y qué riesgo trata cada uno. Un mal uso con addressed_by: [] es un asunto abierto honesto, no uno oculto.
• El domain de cada riesgo — data, safety, governance, transparency — nombra la fuente de ese riesgo concreto (datos / modelo / supervisión / divulgación), de modo que el dossier muestra dónde nació cada riesgo.
• impact: {individual, society, organization} — las dimensiones de daño de arriba.

Así, «identificar un riesgo» — el primer paso del bucle de ¿Qué es un riesgo? — es, en concreto: declarar el fin, enumerar los malos usos previsibles y, para cada riesgo, nombrar su dominio de origen y a quién puede dañar. Esa declaración es lo que el resto del motor mide, trata y firma después.

El GAP honesto: la poscomercialización (art. 72)

De los tres orígenes, este motor sirve plenamente dos. Los orígenes de fin previsto y mal uso previsible son ex ante — se declaran y gobiernan antes de poner el sistema en el mercado, que es exactamente lo que hace froga. El origen poscomercialización (art. 9(2)(c), art. 72) es ex post: necesita telemetría en tiempo de ejecución y monitorización de incidentes del sistema ya desplegado. Eso es una línea futura, no una capacidad actual — el curso enseña la identificación de riesgos ex ante, y es honesto en que la vigilancia poscomercialización continua queda más allá del motor de hoy.

Autoevaluación

❓ Según el artículo 9(2), ¿cuáles son los tres orígenes de los riesgos de un sistema de IA?

(a) El fin previsto — los riesgos que el sistema plantea cuando se usa según lo previsto (y dentro de su supuesto del Anexo III); (b) el mal uso razonablemente previsible — los riesgos de un uso no previsto pero esperable de un comportamiento humano normal (definido en el art. 3(13)); y (c) la realidad poscomercialización — los riesgos que emergen una vez desplegado, que aflora la vigilancia poscomercialización del art. 72. En los tres, los riesgos que importan son los que afectan a la salud, la seguridad o los derechos fundamentales.

❓ ¿Dónde, dentro del sistema, te dice el EU AI Act que busques la fuente de un riesgo, y qué fuente produjo los cuatro casos de la página de inicio?

En tres lugares: los datos (art. 10 — sesgo, lagunas, falta de representatividad), el modelo (art. 15 — precisión, robustez, ciberseguridad) y la interacción persona-IA (art. 14 — supervisión insuficiente). Los cuatro casos europeos (los A-levels del Reino Unido, el AMS austriaco, la CNAF francesa y el Toeslagenaffaire neerlandés) nacieron todos en los datos: cada uno codificó una desigualdad que ya estaba presente en sus datos de entrenamiento, e hizo exactamente lo que esos datos le enseñaron — ningún fallo, un riesgo que nadie midió.

❓ El motor puntúa el impacto en individual / sociedad / organización. ¿Cuál de estos NO es una categoría de daño del EU AI Act, y por qué importa?

organización no es una categoría de daño del AI Act. La norma protege la salud, la seguridad y los derechos fundamentales — daños a las personas — que el motor lleva en los ejes individual y sociedad. organización es el riesgo de negocio para el proveedor (reputacional, financiero), procedente de la ISO 23894; sirve para priorizar el trabajo, pero no es lo que la ley regula. Confundir «esto es malo para nosotros» con «esto daña los derechos de una persona» es justo la mezcla que los ejes de impacto están diseñados para evitar.

A dónde ir ahora

¿Qué es un riesgo?La anatomía sobre la que se apoya esta página: probabilidad × impacto, la matriz 5×5, el apetito, el inherente frente al residual y la barrera ROJO/ÁMBAR/VERDE. Primero el origen, después la medición.

La brecha de datos (art. 10)El origen más común, hecho concreto: cuando el riesgo nace en los datos y ningún cambio de código lo cierra — la barrera de suficiencia que permanece en ROJO hasta que consigues datos más representativos.

Cuando la IA decide sobre personasLos cuatro sistemas europeos cuyos riesgos nacieron todos en los datos — A-levels, AMS, CNAF, el Toeslagenaffaire — y lo que costó que nadie identificara el origen antes de ponerlos en el mercado.

EU AI Act — la columna vertebralEl artículo 9 (gestión de riesgos) en su contexto, junto al art. 10 (datos), el art. 14 (supervisión) y el art. 15 (robustez) — los artículos que nombran de dónde viene el riesgo y qué hacer al respecto.