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).

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.03), con la misma analogía rojo/verde que el TDD.
git cierra el bucle: el tratamiento es un cambio versionado; el git log del bundle firmado es el registro de tratamientos, y sei 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 el gate	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 (.sei/bundle.json) es el registro de tratamientos; sei 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 sei run → sei 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. sei conformance proyecta el bundle sobre ambos mediante catálogos de cláusulas separados y emite las conformidades de forma independiente.

Mapa de esta sección

El bucle rojo/verde (medida vs umbral) Cómo un control define el estado rojo/verde y qué significa SUBPODERADO.

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

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

Los dos gates Gate de riesgo (controles) y gate de conformidad normativa.

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

AssuranceProgram vivo El 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.