Qué es Risk-Driven Development

El desarrollo guiado por riesgo (Risk-Driven Development, RDD) es una idea establecida en la ingeniería del software: hacer que el riesgo sea el motor del proceso. Venturalítica no acuña el término; lo especializa para el tratamiento de riesgo regulatorio de IA, donde la unidad de trabajo es el tratamiento de riesgo, no la funcionalidad. El ciclo de cumplimiento dirige el desarrollo de la misma forma que las pruebas dirigen el desarrollo guiado por pruebas (TDD).

Por qué el riesgo dirige el desarrollo de aprendizaje automático, no la funcionalidad

Un sistema de aprendizaje automático no es software corriente. El modelo se reentrena según llegan datos nuevos, los datos derivan y se alejan de lo que mediste al construirlo, y el sesgo es invisible: no lanza una excepción; solo aflora cuando el sistema ya ha perjudicado a un subgrupo real. Una batería de pruebas en verde te dice que el código hace lo que escribiste, pero no garantiza que el sistema sea equitativo, certero con las personas que importan, ni que siga siendo correcto dentro de un mes. El peligro vive en los datos y en el mundo, no en la función que puedes probar de forma unitaria.

El algoritmo de los A-levels en el Reino Unido (2020) lo ilustra de forma concreta. Era, según cualquier medida convencional, un modelo que funcionaba: con los exámenes cancelados, tomaba los datos de cada centro y producía notas. Sin embargo, había aprendido de años de resultados desiguales a rebajar a los alumnos de centros públicos desfavorecidos mientras subía a los privados —hizo exactamente lo que le enseñaron sus datos sesgados—. Ninguna prueba estaba en rojo; el sistema simplemente codificó un daño que nadie había medido, y la indignación pública forzó una marcha atrás nacional. Por eso el riesgo, y no la lista de funcionalidades, dirige el trabajo: la pregunta que ordena el desarrollo no es «¿funciona?», sino «¿en qué puede equivocarse, con quién, y cómo lo sabríamos?».

Esa postura de riesgo primero no es un invento de Venturalítica — tiene un linaje hondo en la ingeniería del software, que es la credibilidad sobre la que nos apoyamos a continuación.

De dónde viene el término (linaje)

El desarrollo guiado por riesgo tiene raíces de décadas en la ingeniería del software. Venturalítica se apoya en esa tradición; no la inventa.

El modelo en espiral de Boehm (1986/1988). Barry Boehm propuso el primer modelo de proceso de software explícitamente guiado por el riesgo: en cada vuelta de la espiral se hace tanto de cada actividad (análisis, diseño, prototipado) como justifique el riesgo del proyecto, y el reconocimiento explícito del riesgo es lo que lo distingue de los modelos lineales. De ahí viene el adjetivo «risk-driven» en el campo.
La arquitectura guiada por riesgo de Fairbanks (2010). George Fairbanks llevó la idea al diseño arquitectónico con el «modelo guiado por riesgo» (risk-driven model): se invierte esfuerzo de arquitectura en proporción al riesgo, sin sobre-diseñar lo de bajo riesgo ni descuidar lo que amenaza el éxito.
El propio nombre «Risk-Driven Development (RDD)» se usa de forma corriente en la entrega de software, con un bucle muy parecido al nuestro: identificar y evaluar riesgos, expresar los requisitos como controles, priorizar, verificar esos controles y reevaluar el riesgo residual.

Qué especializa Venturalítica

Venturalítica no acuña RDD; lo especializa para la conformidad de IA. La novedad no está en el término, sino en cómo lo ata a un sustrato concreto:

La unidad de trabajo es un tratamiento de riesgo ISO 23894 (una mitigación regulatoria), no el riesgo de proyecto genérico ni la funcionalidad.
El «test» es un control = par (medida, umbral) (por ejemplo, demographic_parity_diff < 0.15), con la misma analogía rojo/verde que el TDD (con el matiz de que, si la evidencia es subpoderada, el control queda INCONCLUSO en vez de verde).
git cierra el bucle: el tratamiento es un cambio versionado; el git log del bundle firmado es el registro de tratamientos, y froga reconstruct lo reproduce como el ciclo formal ISO 23894.
Lo complementan la evidencia firmada (ECDSA-P256+DSSE+in-toto), la proyección dual de estándares y la deriva tipada.

La analogía rojo / verde

En TDD, un test falla (rojo) hasta que el código lo hace pasar (verde). El “refactor” elimina la duplicación sin romper el test.

En RDD el mecanismo es análogo:

RDD	TDD
Rojo — la métrica supera el umbral o falta evidencia	Test fallido
Verde — el tratamiento ha sido implementado y medido; la métrica cruza la barrera	Test en verde
Refactor — el tratamiento de menor coste que lleva el residual por debajo del apetito declarado	Refactor sin romper tests

La medida concreta —una diferencia de paridad demográfica, una métrica de sesgo, una cobertura de prueba— se compara contra su umbral. Ese par (medida, umbral) es el control que define el estado del ciclo.

git cierra el bucle

Cada tratamiento es un cambio versionado anclado a la tripleta (código, modelo, dataset) mediante ECDSA-P256+DSSE+in-toto. El git log del bundle de evidencia (.froga/bundle.json) es el registro de tratamientos; froga reconstruct lo convierte en el ciclo formal ISO 23894.

Como consecuencia, el Anexo IV (EU AI Act Art. 11) se ensambla a partir del bundle —no se redacta a mano. El mecanismo es el descrito; la completitud del Anexo IV sigue siendo parcial (ver Estado e incompletitudes).

Marco normativo

RDD opera sobre dos estándares:

ISO 23894:2023 — especifica el proceso de gestión de riesgos de IA: identificación, análisis, evaluación, tratamiento y riesgo residual (§6.4–§6.5). Venturalítica implementa este ciclo en el motor Rust y lo hace reconstruible por replay de git.

EU AI Act Art. 9 — exige un sistema de gestión de riesgos continuo para sistemas de IA de alto riesgo clasificados bajo Art. 6 y Anexo III. El ciclo froga run → froga conformance implementa el requisito de supervisión continua del Art. 9.

Estos dos estándares no son equivalentes: ISO 23894 define el proceso; el EU AI Act fija el umbral regulatorio. froga conformance proyecta el bundle sobre ambos mediante catálogos de cláusulas separados y emite las conformidades de forma independiente.

Para entender por qué todo esto importa antes de que aparezca ningún regulador, lee Por qué importa.

Mapa de esta sección

El bucle rojo/verde (medida frente a umbral)Cómo un control define el estado rojo/verde/INCONCLUSO y qué significa SUBPODERADO (ejemplo real: la equidad de loan medida held-out).

git cierra el bucle de tratamiento ISO 23894La tesis central: el tratamiento como cambio versionado y froga reconstruct.

Deriva tipadaTipos A/B/C de deriva y cómo froga detecta qué está stale sin recomputar.

Las dos barrerasBarrera de riesgo (controles) y barrera de conformidad normativa.

Modalidades de tratamientoCambio de código, ajuste de parámetro y prompt-tuning (aplazado).

AssuranceProgram vivoEl registro de riesgos que crece durante el desarrollo, auditado por git blame.

Referencias

Boehm, B. (1988). «A Spiral Model of Software Development and Enhancement». IEEE Computer, vol. 21, n.º 5, pp. 61-72. (Versión inicial publicada en 1986).
Fairbanks, G. H. (2010). Just Enough Software Architecture: A Risk-Driven Approach. Marshall & Brainerd.