Deriva tipada A/B/C y obsolescencia

El motor clasifica todo cambio en el sistema de IA en uno de tres tipos de deriva, porque el tipo de deriva determina la respuesta regulatoria requerida. Una clasificación incorrecta —tratar un cambio sustancial como rutinario— es un error de conformidad, no solo técnico.

Los tres tipos

Deriva A — Sustancial

Un cambio en las entradas (features, formato de datos), las salidas (decisión, escala de valores) o la finalidad del sistema (EU AI Act Art. 9(2)) constituye deriva sustancial.

Respuesta obligatoria: re-triaje de riesgo completo. No basta re-medir los controles existentes; el espacio de riesgo puede haber cambiado. El ciclo ISO 23894 §6.4.2 (identificación) debe reabrirse.

Deriva B — Rutinaria

Un cambio en el modelo (arquitectura, pesos, versión) o en el prompt de un sistema basado en LLM constituye deriva rutinaria, siempre que la finalidad y los contratos de entrada/salida no varíen.

Respuesta: re-medición. Los controles existentes se re-evalúan sobre el nuevo modelo; si la métrica cruza el umbral, el ciclo de tratamiento se reabre para ese control.

Deriva C — Datos

Un cambio en el dataset de entrenamiento o validación (incorporación de nuevas instancias, corrección de etiquetas, cambio de distribución demográfica) constituye deriva de datos.

Respuesta: re-medición con especial atención a los controles de sesgo y al requisito EU AI Act Art. 10(5) (suficiencia y representatividad de los datos).

El grafo de dependencias tipado

Los artefactos del sistema (código de entrenamiento, modelo exportado, dataset, métricas, bundle de evidencia) forman un grafo de dependencias cuyas aristas están etiquetadas con el tipo de deriva que activa cada cambio.

froga.lock almacena los anclajes de la tripleta en el último froga run verificado. Cuando el motor ejecuta froga status, compara los digests actuales con los registrados en froga.lock sin recomputar nada:

froga status
# salida posible (una línea por SECCIÓN, no por fichero):
#   classification: Reused
#   risks: Reused
#   model: Stale (re-medir)
#   data: Reused

Si el digest de una sección ha cambiado, froga status la reporta como Stale y clasifica el tipo de deriva; las que no cambian quedan Reused. La barrera de conformidad permanece abierta: no hay falso verde porque froga status no firma evidencia nueva.

Clasificación A/B/C: la infiere el motor (no un envelope declarado)

La clasificación del tipo de deriva (A/B/C) no se declara en froga.yaml: la infiere el motor del diff de la tripleta (froga.lock + el grafo de dependencias). No existe hoy un campo o feature de «envelope» de cambios aceptables.

Detección de obsolescencia

Un bundle de evidencia firmado queda obsoleto cuando cualquiera de los tres digests en froga.lock diverge del estado actual del repositorio. froga status emite exit ≠ 0 en ese caso, lo que permite integrar la detección de obsolescencia en pipelines CI/CD como condición necesaria antes de cualquier afirmación de conformidad.

El principio es sencillo: sin evidencia fresca no se puede afirmar conformidad. Esta es la primera barrera del flujo RDD, descrita en Las dos barreras.

Referencias

Artefacto	Propósito en la gestión de deriva
`froga.lock`	Registra los anclajes verificados de la tripleta
`froga status`	Detecta divergencia vs `froga.lock` sin recomputar
`froga run`	Recomputa, mide y re-ancla la tripleta
`froga.yaml`	Declara la clasificación de controles (la deriva A/B/C la infiere el motor)

Consulta la Referencia del CLI froga para el detalle de comandos y la Referencia de froga.yaml para el esquema del manifiesto.