Compliance on lo0 — Blog Técnico

Runbooks de incident response para inferencia LLM: cada alerta a una acción concreta con Kafka y Keep

Tue, 02 Jun 2026 04:30:00 +0200

Este post cierra la trilogía de observabilidad que abrieron Observabilidad GPU para inferencia LLM (qué métricas) y Anatomía de las doce métricas DCGM y cinco vLLM (qué anomalía documentada por métrica). Aquí cada anomalía recibe su acción concreta y se encaja en la maquinaria de gestión de incidentes que compliance exige.

TL;DR

Las alertas de observabilidad GPU son inútiles sin un procedimiento codificado por cada una; el operador que las interpreta a mano cada vez opera por intuición. La combinación correcta tiene tres piezas indispensables. (1) Catálogo de runbooks: para cada una de las seis alertas críticas (GpuHbmNearOom, GpuThermalOrPowerThrottle, GpuXidErrorDetected, GpuEccDoubleBit, VllmKvCachePoolNearFull, VllmTtftP95OutOfSlo), severity, mitigación inmediata, evidencia que capturar antes de remediar, acción de resolución, criterio de cierre y trigger de postmortem. (2) Pipeline reproducible: Prometheus + DCGM → Alertmanager → Kafka como event bus (topics gpu.alerts.enriched, incidents.lifecycle, audit.actions con retención WORM) → Keep como workflow engine (workflows declarativos YAML versionados en git) → ejecutores Kubernetes jobs / scripts / ChatOps. (3) Encaje formal en gestión de incidentes según el corpus normativo: ISO/IEC 27035 fases identify → report → assess → respond → learn; ENS controles op.exp.7 (gestión de incidentes), op.exp.8 (registro de actividad), op.exp.10 (notificación a usuarios); NIS2 art. 23 con notificación temprana 24 h, notificación formal 72 h e informe final 1 mes; EU AI Act art. 73 para incidente grave de un sistema de alto riesgo, plazos 2 a 15 días según severity; ISO/IEC 42001 cláusula 10 (mejora continua del AIMS). La taxonomía de acción es mitigación inmediata (drain, throttle, scale-down: contiene el daño en segundos) → diagnóstico (captura de evidencia con nvidia-smi -q, dmesg, vLLM /metrics snapshot, traza OTel relacionada; sin esto el postmortem no es defensible) → resolución (restart, reset, RMA, rollback) → postmortem (RCA por 5-whys, plan de prevención, actualización del runbook). Kafka aporta el audit trail inmutable que ENS y EU AI Act exigen — cada acción ejecutada por Keep o por humano se publica como evento en audit.actions con timestamp, actor, decisión y evidencia, retenido WORM mínimo 6 meses. Keep aporta los workflows como código: este post incluye tres workflows completos (XID con drain + ticket Jira, ECC DBE con paginación inmediata y bloqueo del nodo en scheduler, canary rollback automático por TTFT P95 fuera de SLO). Cuatro anti-patrones cierran el material: alertas sin runbook (la mayoría), runbook sin captura de evidencia previa (perpetúa el incidente porque la causa raíz se pierde), escalada por antigüedad en vez de severity (operador junior gestiona ECC DBE), ausencia de gate humano para acciones destructivas (Keep ejecutando nvidia-smi --gpu-reset sin confirmación). Aplicable a un cluster genérico de 4×H100 SXM con Kafka y Keep ya desplegados.

Estás aquí: OBSERVE → DEPLOY (incident response cierra el bucle)

La analogía: la sala de control de un reactor nuclear

En una sala de control de central nuclear, el operador de turno nunca decide qué hacer al ver una alarma. La decisión está pre-tomada y codificada en un procedimiento escrito (SOP) que cubre cada alarma del panel: si suena la X, abrir libro X, leer los pasos 1-N, ejecutar exactamente, llamar al supervisor en el paso M, escalar al director de planta en el paso N+3. La razón es estricta: las alarmas críticas son raras pero catastróficas si se gestionan mal; un operador improvisando en una emergencia toma decisiones peores que uno aplicando un procedimiento revisado por expertos y validado por simulación.

El reactor no espera que el operador sea genio. Espera que conozca los procedimientos al pie de la letra y que el sistema de gestión de operaciones le entregue el procedimiento correcto al momento. Si los procedimientos no están escritos, no están versionados, o no están integrados con las alarmas que disparan, la sala de control opera por intuición. La diferencia entre ambas operaciones —procedimentada vs intuitiva— es la diferencia entre una central que opera 30 años sin incidentes y otra que entra en lista negra.

El incident response de un cluster de inferencia LLM funciona idéntico. Las alertas DCGM y vLLM que los posts anteriores listaron son las alarmas del panel. Cada una necesita su SOP escrito, versionado, integrado con la alerta que la dispara y revisado tras cada incidente. Sin esa codificación, el operador de turno improvisa en mitad de un fallo de ECC DBE a las 4 de la mañana; con ella, ejecuta los nueve pasos del runbook 12 y el incidente se cierra en 20 minutos.

La arquitectura del incident pipeline

Prometheus + DCGM. Recolecta las métricas descritas en los dos posts anteriores. PrometheusRules definen las seis alertas críticas con for: <duración> para evitar ruido.

Alertmanager. Recibe alertas crudas; deduplica, agrupa por labels ({cluster, node, gpu, model}), enruta. En vez de enviar directamente a PagerDuty o Slack, envía a Kafka vía webhook receiver — esto convierte la alerta en un evento del bus que múltiples consumidores procesan (Keep para acción, audit topic para compliance, dashboards para visualización).

Kafka como event bus. Tres topics canónicos:

gpu.alerts.enriched — alertas con contexto añadido (tenant, modelo, versión, owner del namespace, severity efectiva). Retención: 7 días, replication factor 3.
incidents.lifecycle — eventos del ciclo del incidente: incident.opened, incident.acknowledged, action.proposed, action.executed, incident.escalated, incident.resolved, postmortem.attached. Retención: 90 días.
audit.actions — registro inmutable de cada acción ejecutada (por Keep automáticamente o por humano confirmando). Retención: 6 meses mínimo con compaction off + tiered storage, almacenamiento WORM. Es el topic que ENS op.exp.8, EU AI Act art. 12 y NIS2 obligan a conservar.

Keep como workflow engine. Consume de gpu.alerts.enriched, dispara workflows YAML versionados en git, ejecuta acciones (llamadas HTTP, kubectl jobs, mensajes Slack, tickets Jira) y publica el resultado en incidents.lifecycle + audit.actions. La elección de Keep sobre Alertmanager solo (o sobre PagerDuty solo) es deliberada: Keep separa declaración del runbook (YAML legible y revisable) de distribución de notificación (PagerDuty). El runbook es código versionado; las notificaciones son detalles operativos.

Ejecutores. Lo que de verdad mueve el cluster:

Kubernetes jobs: kubectl drain, kubectl cordon, kubectl rollout undo.
NVIDIA API: nvidia-smi --gpu-reset, dcgmi diag -r <level>.
ChatOps: confirmaciones humanas a través de Slack interactive messages antes de ejecutar acción destructiva.
Tooling externo: ticket Jira, notificación PagerDuty, llamada a CMDB.

Las seis alertas críticas y sus runbooks

Para cada alerta: severity, mitigación inmediata (segundos), evidencia que capturar antes de remediar, acción de resolución, criterios de cierre, trigger de postmortem.

RB-01 · `GpuHbmNearOom` — HBM > 92 % sostenido

Severity: WARNING. Riesgo OOM en la siguiente asignación de PagedAttention.

Mitigación inmediata. Reducir admission temporalmente bajando max_num_seqs del motor afectado vía hot reload (si el motor lo soporta) o restart escalonado de réplicas. Disparar scale-out adicional vía KEDA si hay nodos GPU libres. No es necesario drenar el nodo.

Evidencia a capturar.

nvidia-smi --query-gpu=index,memory.used,memory.free,memory.total --format=csv
nvidia-smi -q -d ROW_REMAPPER | grep -i pending
curl http://vllm-pod:8000/metrics | grep -E "gpu_cache_usage|num_requests"
kubectl logs <pod> --tail=200 | grep -i "preempt\|swap"

Guardar snapshot en audit.actions con timestamp y incident_id.

Resolución. Si la causa es pico de tráfico: dejar al autoscaler escalar a régimen estable, monitorizar 30 min. Si la causa es regresión de modelo (canary v2 consume más KV cache que v1): rollback del canary (ver RB-06). Si es leak (la métrica crece sin que el tráfico crezca): restart del pod con captura de heap dump.

Cierre. gpu_cache_usage_perc < 80 % sostenido durante 15 min Y num_requests_waiting == 0.

Postmortem. No obligatorio salvo si el incidente duró > 30 min o tuvo impacto en SLO.

RB-02 · `GpuThermalOrPowerThrottle` — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

Severity: WARNING (térmico) o CRITICAL (HW Power Brake sostenido, riesgo PDU).

Mitigación inmediata. Identificar el bit (decodificar bitmap). Si es 0x40 HW_THERMAL o 0x20 SW_THERMAL: drenar workload del nodo a otras réplicas si la temperatura no baja en 2 min, evitar nuevos pods en ese nodo (kubectl cordon). Si es 0x80 HW_POWER_BRAKE: alerta a infraestructura de DC inmediatamente (probable PDU sobrecomprometida — caso Dell KB 000220508 / Lenovo HT514380), reducir TDP de las GPUs del rack vía nvidia-smi -pl a un valor menor para liberar carga sobre el breaker.

Evidencia.

nvidia-smi --query-gpu=index,temperature.gpu,temperature.memory,power.draw,clocks_throttle_reasons.active --format=csv
ipmitool sdr | grep -i "fan\|temp\|inlet"
# Datos de PDU si están instrumentadas (modbus / SNMP)

Resolución.

Térmico: revisar flujo de aire del rack, verificar rear-door HX, T_inlet, ventiladores DGX. Issue de infra, no de motor.
Power Brake: revisar dimensionado de PDU rama, breaker, distribución 415 VAC. Probable redistribución de carga a otra rama o limitación temporal de TDP.

Cierre. CLOCK_THROTTLE_REASONS == 0x1 (solo Idle) o 0x0 durante 30 min con carga normal.

Postmortem. Obligatorio si fue HW Power Brake — implica infraestructura eléctrica del DC.

RB-03 · `GpuXidErrorDetected` — `increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0`

Severity: CRITICAL.

Mitigación inmediata. kubectl cordon del nodo (sin más nuevos pods). Si el XID es 31/48/79/94/95 (hardware o cascada): drenar los pods existentes del nodo. Si el XID es 13/43 (posible software): mantener pods pero bloquear nuevos, capturar trace y workload activo.

Evidencia.

# El XID concreto del dmesg
dmesg | grep -i xid | tail -30
nvidia-smi -q -d ERROR
nvidia-smi -q -d PCIE
# Estado de las páginas retiradas
nvidia-smi -q -d ROW_REMAPPER
# Workload que estaba ejecutándose
kubectl get pods -o wide | grep <node>
kubectl logs <pod> --previous --tail=500

Resolución.

XID 13/43 (software exception / channel verif): si recurre solo con un modelo concreto, es bug del workload — issue al equipo de modelos. Si es transitorio, reiniciar el pod basta.
XID 31 (MMU fault): suele ser cascada de un XID 48 previo. Reset de la GPU (nvidia-smi --gpu-reset -i <index>) o reboot del nodo si reset no resuelve.
XID 48 / 95 (DBE / uncontained ECC): ver RB-04. El nodo entra en cuarentena.
XID 79 (fallen off the bus): reboot del nodo. Si recurre tras reboot, abrir RMA de la GPU. ByteDance reporta 43 % de coocurrencia con errores PCIe — verificar también el slot y el cable.
XID 94 / 145 / 149: catalogados en el Xid Catalog de NVIDIA con procedimiento específico.

Cierre. Smoke test del nodo pasado (dcgmi diag -r 3), 24 h sin nuevos XIDs, vuelta al pool.

Postmortem. Obligatorio. Incluir XID concreto, distribución de XIDs en el cluster, MTBE actualizado.

RB-04 · `GpuEccDoubleBit` — `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0`

Severity: CRITICAL — corrupción de datos en curso.

Mitigación inmediata. Drenar el nodo inmediatamente sin esperar evidencia adicional. Páginas guardia (PagerDuty / OpsGenie) ON-CALL primario. Marcar el nodo unschedulable y failed. El XID 48 tiene 100 % probabilidad de matar el job en curso según el dataset de Story of Two GPUs; cualquier inferencia ya está comprometida.

Evidencia (en paralelo a la mitigación).

nvidia-smi -q -d ECC
nvidia-smi -q -d ROW_REMAPPER # Pending: Yes esperado
dmesg | grep -E "Xid.*48|DBE|double-bit" | tail -50
# Captura completa del estado de la GPU
dcgmi diag -r 4 -i <gpu_index>

Resolución. Reset completo de la GPU (nvidia-smi --gpu-reset) o reboot del nodo si reset no completa. El reset activa el row remap. Tras el reboot:

nvidia-smi -q -d ROW_REMAPPER # Pending: No esperado
nvidia-smi -q -d ECC # contadores volátiles a 0

Si RETIRED_DBE > 8 páginas tras el remap: planificar reemplazo de GPU en próxima ventana — la degradación del silicio es progresiva. Documentado ~19 horas de downtime típico en el caso real publicado.

Cierre. Nodo en pool tras 48 h sin nuevos DBE.

Postmortem. Obligatorio. Si el incidente afectó a una request con datos personales / clasificados, evaluar notificación a DPO bajo GDPR art. 33 (no es necesariamente brecha, pero hay que evaluarlo).

RB-05 · `VllmKvCachePoolNearFull` — `gpu_cache_usage_perc > 95 %` sostenido 3 min

Severity: WARNING (riesgo de preempt-on-OOM, no de OOM real).

Mitigación inmediata. Activar scale-out del autoscaler bajando el umbral de KEDA temporalmente (de 0.85 a 0.75) durante 30 min. Si está en modo recompute, los preempts elevan TTFT pero no rompen requests; aceptable a corto plazo. Si está en modo swap, latencia se va al techo — preferible cortar tráfico nuevo (devolver 503 desde el router) durante 5 min.

Evidencia.

curl http://vllm-pod:8000/metrics | grep -E "gpu_cache|num_requests|num_preemptions"
kubectl get hpa vllm-llama70b
kubectl logs <pod> --tail=200 | grep -i preempt

Resolución. Si recurre regularmente: capacity planning revisado, posiblemente reducir max_num_seqs o subir réplicas estables. Ver Capacity planning.

Cierre. Pool < 85 % sostenido 30 min, sin preempts en último 15 min.

Postmortem. No obligatorio salvo recurrencia > 3 veces / semana.

RB-06 · `VllmTtftP95OutOfSlo` — TTFT P95 > 1.5 s durante 5 min

Severity: CRITICAL (violación de SLO contractual).

Mitigación inmediata. Diagnóstico rápido del régimen (en orden de probabilidad):

Si hay canary v2 activo y el ratio ttft_p95(v2)/ttft_p95(v1) > 1.30: rollback automático del canary vía Argo Rollouts (argo rollouts abort vllm-llama70b).
Si num_requests_waiting > 5: scale-out vía KEDA.
Si DRAM_ACTIVE > 90 % + gpu_cache_usage_perc > 90 %: cuello en HBM, palanca de quantization o reducción de contexto.
Si CLOCK_THROTTLE_REASONS != 0: ver RB-02.

Evidencia.

# Snapshot del histograma
curl http://vllm-pod:8000/metrics | grep time_to_first_token
# Distribución por versión si hay canary
# Estado DCGM del momento
curl http://dcgm-exporter:9400/metrics | grep -E "PIPE_TENSOR|DRAM_ACTIVE|THROTTLE"
# Tráfico activo
kubectl top pods -n inference

Resolución. Depende del diagnóstico. Casos típicos:

Canary regresión → rollback completo (ver Canary).
Saturación de capacidad → escalar réplicas o aceptar 503 temporal con Retry-After.
Prefill bound → activar/calibrar chunked prefill o disaggregated serving (ver Disaggregated serving).

Cierre. TTFT P95 dentro de SLO sostenido 30 min.

Postmortem. Obligatorio. Documentar causa raíz y palanca aplicada; actualizar runbook.

Workflows Keep YAML — tres ejemplos completos

Los runbooks son útiles solo si están codificados en el workflow engine. Keep permite declararlos en YAML versionados en git.

Workflow 1 — `xid-detected.yaml`

workflow:
 id: xid-detected-drain
 name: "XID error detected — cordon node and capture evidence"
 description: "RB-03 implementation"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: GpuXidErrorDetected
 steps:
 - name: capture-evidence
 provider:
 type: bash
 with:
 command: |
 set -e
 NODE="{{ alert.labels.node }}"
 GPU="{{ alert.labels.gpu }}"
 INC_ID="{{ alert.fingerprint }}"
 mkdir -p /var/evidence/$INC_ID
 kubectl debug node/$NODE -it --image=nvcr.io/nvidia/cuda:12.4.0-base-ubuntu22.04 -- \
 bash -c "nvidia-smi -q -d ERROR,PCIE,ROW_REMAPPER > /host/var/evidence/$INC_ID/smi.txt"
 kubectl describe node $NODE > /var/evidence/$INC_ID/node.txt
 - name: cordon-node
 provider:
 type: kubernetes
 with:
 action: cordon
 name: "{{ alert.labels.node }}"
 if: "{{ alert.labels.severity == 'critical' }}"
 actions:
 - name: open-jira-ticket
 provider:
 type: jira
 config: "{{ providers.jira-prod }}"
 with:
 project: GPUOPS
 issuetype: Incident
 summary: "RB-03: XID {{ alert.annotations.xid_code }} on {{ alert.labels.node }}/{{ alert.labels.gpu }}"
 description: |
 Severity: {{ alert.labels.severity }}
 XID: {{ alert.annotations.xid_code }}
 Evidence: /var/evidence/{{ alert.fingerprint }}
 Runbook: https://runbooks.example.local/RB-03
 - name: notify-slack
 provider:
 type: slack
 config: "{{ providers.slack-gpu-incidents }}"
 with:
 message: |
 :warning: *RB-03 triggered*
 Node: `{{ alert.labels.node }}` GPU: `{{ alert.labels.gpu }}`
 XID: `{{ alert.annotations.xid_code }}`
 <{{ jira.url }}|Jira ticket>
 - name: emit-audit
 provider:
 type: kafka
 config: "{{ providers.kafka-audit }}"
 with:
 topic: audit.actions
 message:
 incident_id: "{{ alert.fingerprint }}"
 action: "cordon_node"
 actor: "keep-workflow"
 workflow_id: "xid-detected-drain"
 target: "{{ alert.labels.node }}"
 timestamp: "{{ now }}"

Workflow 2 — `ecc-dbe.yaml` — paginación inmediata

workflow:
 id: ecc-dbe-critical
 name: "ECC double-bit — page on-call and quarantine node"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: GpuEccDoubleBit
 steps:
 - name: cordon-immediately
 provider:
 type: kubernetes
 with:
 action: cordon
 name: "{{ alert.labels.node }}"
 - name: drain-workload
 provider:
 type: kubernetes
 with:
 action: drain
 name: "{{ alert.labels.node }}"
 options:
 ignore-daemonsets: true
 delete-emptydir-data: true
 grace-period: 120
 - name: page-oncall
 provider:
 type: pagerduty
 config: "{{ providers.pagerduty-critical }}"
 with:
 service_key: "{{ env.PD_SERVICE_KEY }}"
 severity: critical
 summary: "RB-04 ECC DBE on {{ alert.labels.node }}/{{ alert.labels.gpu }} — node drained"
 - name: emit-lifecycle
 provider:
 type: kafka
 config: "{{ providers.kafka-incidents }}"
 with:
 topic: incidents.lifecycle
 message:
 incident_id: "{{ alert.fingerprint }}"
 event: incident.opened
 severity: critical
 runbook: RB-04
 requires_postmortem: true
 - name: notify-dpo
 provider:
 type: email
 with:
 to: dpo@example.local
 subject: "ECC DBE en GPU productiva — evaluación necesaria"
 body: |
 Incidente RB-04 ECC DBE detectado en {{ alert.labels.node }}.
 Modelo afectado: {{ alert.labels.model }}.
 Por favor evaluar si hubo procesamiento de datos personales/clasificados
 durante la ventana de error y necesidad de notificación GDPR art. 33.

Workflow 3 — `canary-rollback.yaml` — TTFT P95 fuera de SLO

workflow:
 id: canary-rollback-ttft
 name: "Rollback canary when TTFT P95 ratio v2/v1 > 1.30"
 triggers:
 - type: alert
 filters:
 - key: alertname
 value: VllmTtftP95OutOfSlo
 - key: canary_active
 value: "true"
 steps:
 - name: check-ratio
 provider:
 type: prometheus
 config: "{{ providers.prom-prod }}"
 with:
 query: |
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v2"}[5m])))
 /
 histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket{version="v1"}[5m])))
 condition: result > 1.30
 actions:
 - name: argo-rollback
 provider:
 type: kubernetes
 with:
 action: exec
 command:
 - kubectl
 - argo
 - rollouts
 - abort
 - "{{ alert.labels.rollout }}"
 - -n
 - "{{ alert.labels.namespace }}"
 - name: notify-and-audit
 provider:
 type: kafka
 config: "{{ providers.kafka-audit }}"
 with:
 topic: audit.actions
 message:
 incident_id: "{{ alert.fingerprint }}"
 action: canary_rollback
 ratio: "{{ steps.check-ratio.result }}"
 actor: keep-workflow
 timestamp: "{{ now }}"

Cada workflow se guarda en repos/keep-workflows/ versionado en git, revisado por pull request, validado por CI (keep workflow validate). El runbook escrito vive como docs/runbooks/RB-XX.md enlazado desde el workflow YAML — los dos siempre evolucionan juntos.

El schema canónico de eventos Kafka

Para que los topics sean consumibles por compliance, postmortem tooling y dashboards sin que cada consumer tenga que adivinar el shape, se fija schema con Avro / Protobuf.

{
 "name": "IncidentLifecycleEvent",
 "type": "record",
 "fields": [
 { "name": "incident_id", "type": "string" },
 { "name": "event", "type": { "type": "enum", "symbols": [
 "incident.opened", "incident.acknowledged", "action.proposed",
 "action.executed", "action.failed", "incident.escalated",
 "incident.resolved", "postmortem.attached"
 ]}},
 { "name": "timestamp", "type": "string", "logicalType": "timestamp-millis" },
 { "name": "actor", "type": "string" },
 { "name": "severity", "type": { "type": "enum", "symbols": ["low","warning","critical"] } },
 { "name": "runbook", "type": ["null","string"], "default": null },
 { "name": "alert_name", "type": "string" },
 { "name": "labels", "type": { "type": "map", "values": "string" } },
 { "name": "annotations", "type": { "type": "map", "values": "string" } },
 { "name": "evidence_uri", "type": ["null","string"], "default": null },
 { "name": "requires_postmortem", "type": "boolean", "default": false }
 ]
}

Para audit.actions (WORM), un schema separado más exigente con campos no-modificables:

{
 "name": "AuditAction",
 "type": "record",
 "fields": [
 { "name": "incident_id", "type": "string" },
 { "name": "action", "type": "string" },
 { "name": "actor", "type": "string" },
 { "name": "actor_type", "type": { "type": "enum", "symbols": ["human","workflow","scheduler"] } },
 { "name": "workflow_id", "type": ["null","string"], "default": null },
 { "name": "target", "type": "string" },
 { "name": "command", "type": ["null","string"], "default": null },
 { "name": "result", "type": { "type": "enum", "symbols": ["success","failure","partial"] } },
 { "name": "timestamp", "type": "string", "logicalType": "timestamp-millis" },
 { "name": "evidence_uri", "type": ["null","string"], "default": null },
 { "name": "approver", "type": ["null","string"], "default": null }
 ]
}

El topic se configura con cleanup.policy=delete, retention.ms=15552000000 (6 meses) y min.insync.replicas=2 con acks=all para garantizar durabilidad. Para retención más larga sin coste de Kafka, tiered storage a Ceph RGW o S3-compatible — el log nuevo en hot tier, el viejo en cold tier transparente al consumer.

Encaje formal en gestión de incidentes

Los runbooks no son una práctica de SRE aislada — encajan en cuatro marcos normativos que las plataformas LLM productivas tocan a diario.

ISO/IEC 27035 — gestión de incidentes de seguridad de la información

Define el ciclo formal en cinco fases: plan & prepare → detect & report → assess & decide → respond → lessons learned. Cada fase tiene salidas exigibles documentalmente. La traducción al stack:

Plan & prepare: los runbooks RB-01 a RB-06 + los workflows Keep son parte del Information Security Incident Management Plan. Versionados en git, revisados anualmente.
Detect & report: las alertas Prometheus que entran a Kafka son la materialización.
Assess & decide: la severity en gpu.alerts.enriched + la lógica del workflow Keep.
Respond: ejecución de los steps + actions del workflow.
Lessons learned: postmortem obligatorio para los runbooks que lo marcan; salida documentada en el repo de postmortems + actualización del runbook.

ENS (Esquema Nacional de Seguridad) — controles op.exp

op.exp.7 Gestión de incidentes: el catálogo de runbooks + el pipeline Keep / Kafka materializan la “respuesta organizada y procedimentada”.
op.exp.8 Registro de actividad: el topic audit.actions con retención WORM 6 meses (mínimo nivel ALTO).
op.exp.9 Registro de la gestión de incidentes: el topic incidents.lifecycle con el ciclo completo de cada incidente.
op.exp.10 Protección de los registros de actividad: WORM + cifrado en reposo + control de acceso (consumers compliance solo-lectura).

NIS2 — notificación a autoridad competente

Para entidades esenciales / importantes, el art. 23 fija tres plazos a partir del significant impact detectado:

24 horas: notificación temprana (“early warning”) al CSIRT nacional (INCIBE-CERT en España).
72 horas: notificación formal con assessment inicial.
1 mes: informe final con causa raíz, impacto, medidas correctivas.

Los datos para esos informes salen directamente de incidents.lifecycle + audit.actions con un consumer que genera el dossier en el formato requerido. Sin el pipeline auditable, los plazos NIS2 son inalcanzables.

EU AI Act — art. 73 (serious incident reporting)

Aplicable a sistemas de alto riesgo. Plazos:

2 días: para incidentes que provoquen fallecimiento o daño irreversible a personas o infraestructuras críticas.
10 días: para incidentes que produzcan disrupción seria de infraestructura crítica.
15 días: para el resto de “serious incidents”.

La definición de “serious incident” incluye fallos sistemáticos del modelo, brecha de fundamental rights, daño material o medioambiental. Los runbooks deben marcar qué alertas pueden derivar en serious incident (típicamente cualquier cosa que afecte la salida del modelo en un contexto de alto riesgo) y disparar un sub-workflow específico de evaluación legal.

ISO/IEC 42001 — AIMS cláusula 10 mejora continua

El postmortem obligatorio post-incidente alimenta la cláusula 10. La actualización del runbook tras cada incidente que descubre un patrón nuevo es la “acción correctiva con verificación de eficacia” que la norma exige. Ver ISO 42001 AIMS.

Cuatro anti-patrones

Anti-patrón 1 — alertas sin runbook. La alerta dispara, el operador junior de guardia mira el dashboard, busca en Confluence, no encuentra nada actualizado, llama al senior por Slack, espera 20 minutos. En ese tiempo el incidente ha crecido. Regla: ninguna alerta entra a producción sin runbook publicado y workflow Keep aprobado. CI valida que cada PrometheusRule con severity ≥ warning tiene su keep workflow correspondiente.

Anti-patrón 2 — runbook sin captura de evidencia previa. El workflow ejecuta nvidia-smi --gpu-reset en cuanto llega el XID, perdiendo el estado que habría diagnosticado la causa raíz. El siguiente XID idéntico exige rehacer el diagnóstico desde cero. Regla: steps antes de actions; toda evidencia se captura primero, las acciones destructivas después.

Anti-patrón 3 — escalada por antigüedad en vez de severity. El operador junior de guardia gestiona un ECC DBE porque “le toca”. Le falta contexto para entender row remap, retired pages o el riesgo de corrupción de datos. Regla: paginación por severity, no por rotación: RB-04 y RB-03 dispararon ON-CALL primario senior con escalada automática a infra/hardware si no acuse en 10 min.

Anti-patrón 4 — ausencia de gate humano para acciones destructivas. El workflow ejecuta kubectl drain automáticamente sobre cualquier alerta marcada como CRITICAL. En la primera falsa alarma (un transitorio que se autoresolvió en 30 s), Keep drenó un nodo productivo durante hora pico. Regla: acciones destructivas (drain, reset, RMA, rollback completo) exigen confirmación humana vía Slack interactive message, con timeout configurable. Excepción justificada: ECC DBE confirmado por > 1 medición — el riesgo de corrupción supera el de falsa alarma.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB con Kafka y Keep ya desplegados:

Kafka: cluster de 3 brokers en nodos no-GPU del cluster K8s; topics gpu.alerts.enriched, incidents.lifecycle, audit.actions configurados con replication factor 3, min.insync.replicas 2. Audit con tiered storage a Ceph RGW para retención > 6 meses sin coste brutal.
Keep: 2 réplicas del operator + 1 réplica del worker en un namespace keep; conectado a Prometheus (provider read), Kafka (provider read + write), Slack, PagerDuty, Jira, Kubernetes (provider con SA específico con permisos get/list/patch nodes, create jobs).
Workflows: ~25-40 YAML en el repo infra/keep-workflows/, sincronizado con el cluster vía Flux o Argo CD. Validados por CI (keep workflow validate) en cada PR.
Volumen de eventos: para 16 GPUs en operación normal con alertas debounced, ~50-200 eventos/día en gpu.alerts.enriched. En incidente típico, picos de 500-2000 eventos/día.
Compliance consumers: un consumer python en namespace compliance que genera reportes NIS2 / ENS / EU AI Act semanalmente, leyendo audit.actions y incidents.lifecycle.

Lo que no hemos cubierto (próximos posts)

Playbooks de postmortem — la mecánica de RCA con 5-whys, Ishikawa adaptado a LLM, integración con MLflow tracking de re-training si el postmortem produce dataset enriquecido.
Chaos engineering para LLM — inyección controlada de XID errors, ECC simulados, latencia HBM artificial para validar runbooks antes del incidente real.
Multi-cluster incident coordination — cómo coordinar Keep entre clusters geográficos cuando un incidente afecta a múltiples regiones.
Integración con CMDB y procurement — el ciclo RMA → ticket → ServiceNow → reposición de hardware automatizado vía workflow.
Forense LLM — extracción de la traza OTel completa de una request afectada por un incidente, redacted PII, conservación en evidence vault.

Ver también

Anatomía de las doce métricas DCGM y cinco vLLM — la anomalía documentada por métrica que estos runbooks resuelven.
Observabilidad GPU para inferencia LLM — la lista compacta y las seis alertas críticas.
Tracing LLM con OpenTelemetry GenAI — la traza OTel que se captura como evidencia.
Canary, blue-green y shadow — el mecanismo de rollback que RB-06 invoca.
Autoscaling LLM en Kubernetes — la palanca de escalado que RB-01 y RB-05 invocan.
Capacity planning — el head-room presupuestado para absorber incidentes sin SLO break.
ISO/IEC 42001 AIMS para LLM on-premise — la cláusula 10 que estos postmortems materializan.
Controles técnicos ENS × 42001 × EU AI Act — el mapeo de controles que estos runbooks satisfacen.
EU AI Act: mapeo a arquitectura LLM — el art. 73 de incidentes graves que activa el sub-workflow legal.
Cinco niveles de madurez — los runbooks codificados son requisito del nivel 3-4.

Referencias

ISO/IEC 27035-1:2023 — Information security incident management — Principles and process.
ISO/IEC 27035-2:2023 — Information security incident management — Guidelines to plan and prepare for incident response.
ENS — Real Decreto 311/2022, Anexo II controles op.exp.7 a op.exp.10.
Directiva NIS2 (UE 2022/2555) — art. 23 (notificación de incidentes significativos).
Reglamento EU AI Act (UE 2024/1689) — art. 73 (reporting of serious incidents).
ISO/IEC 42001:2023 — AI management system — cláusula 10 (mejora continua).
Keep project — keephq.dev y github.com/keephq/keep (documentación de workflows YAML, providers).
Apache Kafka — Tiered Storage y cleanup.policy (docs.confluent.io / kafka.apache.org).
Confluent — Schema Registry y best practices para eventos lifecycle.
NVIDIA — Xid Errors Documentation y procedimientos de remediación.
Google SRE Book — Effective Troubleshooting y Postmortem Culture.
Atlassian — Incident Management Handbook (referencia para severity matrices).

ISO/IEC 42001: el manual de operaciones del sistema de IA — cómo encaja el AIMS sobre la plataforma LLM on-premise descrita en el blog

Mon, 01 Jun 2026 06:00:00 +0200

Este post cierra una asimetría que el blog acumulaba: hemos descrito en detalle la plataforma técnica (siete capas del stack, siete fases del despliegue, cinco niveles de madurez), el pipeline operativo (seis etapas LLMOps), las piezas data (curación de corpus, versionado), las piezas eval / safety (evals, guardrails, LLM Guard) y las piezas observe (tracing OTel GenAI). Lo que no había aparecido es la capa de gobierno que un cliente regulado pide encima de todo eso. ISO/IEC 42001 es esa capa.

TL;DR

ISO/IEC 42001:2023 es la primera norma internacional certificable que define cómo se gestiona un sistema de IA. No es una norma técnica (no dice “usa este motor de inferencia” ni “este threshold de safety”): es una norma de gestión, prima de ISO 27001 e ISO 9001. Hereda de ambas la estructura Annex SL —siete cláusulas obligatorias que recorren contexto, liderazgo, planificación, soporte, operación, evaluación de desempeño y mejora— y añade un Annex A con 38 controles específicos de IA en 9 secciones: políticas, organización interna, recursos, impact assessment, ciclo de vida, datos, información a partes interesadas, uso, terceros. La tesis del post es que la arquitectura técnica descrita en este blog cubre directamente entre el 60% y el 80% de los controles A sin trabajo adicional —el pipeline LLMOps materializa A.6, el versionado y curación materializan A.7, los guardrails y evals materializan A.9, el tracing OTel materializa A.8—; el resto es disciplina de gobierno que no aparece en el código (política de IA escrita, impact assessments por sistema, registro de stakeholders, decisiones de roles entre provider/producer/customer, documentación obligatoria), y es precisamente lo que diferencia una certificación real de un cumplimiento performativo. El post mapea control a control la correspondencia, cruza con EU AI Act (siete artículos directamente alineados con 42001: 9, 10, 11, 12, 13, 14, 17), con NIS2 (asset register, incident notification, supply chain) y con ENS (RD 311/2022, categorías Básico/Medio/Alto), lista los siete documentos obligatorios mínimos que un auditor pide, presenta el caso del chatbot multi-tenant del blog como checklist 42001 vivo, y cierra con las cinco trampas habituales (confundir 42001 con cumplimiento EU AI Act, sobre-documentar sin medir, ignorar A.5 hasta el audit, asumir que 27001 cubre la parte AI, pensar que la certificación es un proyecto puntual y no un sistema vivo).

La analogía: el manual de operaciones del avión

Un avión moderno —un A350, un Boeing 787, un dron certificado para reparto urbano— no vuela porque tenga buenos motores. Vuela porque la organización que lo opera tiene un Manual de Operaciones aprobado por la autoridad aeronáutica (EASA en Europa, FAA en EEUU, AESA en España como delegada). El manual no contiene los planos del motor —eso lo certifica el fabricante—; contiene los procedimientos: quién es el comandante en cada vuelo, qué checklist se ejecuta antes de cada despegue, qué inspecciones periódicas se hacen a las 100, 500 y 2.000 horas de vuelo, qué proveedores externos están autorizados a tocar qué componentes, qué se documenta tras cada incidente, qué hacer cuando aparece una alerta nueva en el panel. La autoridad no se sienta en cada vuelo: lee el manual, audita aleatoriamente la trazabilidad de los vuelos pasados contra el manual, y si todo cuadra, mantiene la certificación.

Un sistema de IA en producción —el chatbot multi-tenant del post forense, un copiloto para abogados, un sistema de scoring crediticio— es exactamente lo mismo. Vuela porque el modelo es bueno, el pipeline LLMOps está bien montado, los guardrails atrapan los casos malos. Pero certifica porque la organización que lo opera tiene un AIMS (AI Management System) descrito en un manual auditable. ISO/IEC 42001 es ese manual: su índice obligatorio (Annex SL, siete cláusulas) y su catálogo de controles específicos de IA (Annex A, 38 controles). El auditor no se sienta junto al ingeniero MLOps: lee la política de IA, revisa los impact assessments de los últimos sistemas desplegados, comprueba que el retrain de incidentes está documentado, verifica los contratos con terceros, audita una muestra de trazas en Langfuse cruzadas con dataset_hash y prompt_id. Y si todo cuadra, certifica.

La analogía importa porque acota la pregunta correcta: 42001 no certifica el modelo ni el código. Certifica la forma de operar del sistema completo. Un equipo puede tener el mejor stack OSS del mundo y suspender la auditoría porque no tiene una política de IA escrita ni una decisión documentada sobre qué rol (provider vs producer vs customer) ocupa frente a sus clientes. Y viceversa: un equipo con un modelo modesto pero con disciplina de manual de operaciones puede certificar sin acrobacias.

ISO/IEC 42001 en 15 segundos

Publicación: diciembre de 2023, ISO/IEC JTC 1/SC 42 (el subcomité ISO/IEC de AI).
Estado en 2026: norma vigente, certificable por organismos acreditados (BSI, AENOR, TÜV, Bureau Veritas, A-LIGN, Schellman). Aún no reconocida formalmente como norma armonizada del EU AI Act, pero proporciona la base de gestión sobre la que apoyarse.
Compatibilidad: comparte la estructura Annex SL con ISO 9001 (calidad), 27001 (seguridad de la información), 27701 (privacidad), 22301 (continuidad), 20000-1 (servicios IT). Las organizaciones con sistemas de gestión integrados (IMS) la añaden con un esfuerzo del 20-40% del que costaría implantarla desde cero.
Aplicabilidad: cualquier organización que desarrolle, provea, despliegue o use sistemas de IA. No se limita a desarrolladores: una empresa que consume un LLM hospedado y lo integra en un producto propio está dentro del alcance.
Certificación: ciclo de 3 años con auditoría inicial (Stage 1: review documental + Stage 2: auditoría in-situ) y auditorías de seguimiento anuales. Coste típico: 15.000-60.000 € la inicial según tamaño; 6.000-20.000 € por seguimiento anual.

Lo que no hace 42001:

No dice qué modelos usar ni qué thresholds aplicar.
No certifica el modelo individual (eso lo hacen evaluaciones específicas tipo NIST AI RMF profile o EU AI Act technical documentation).
No sustituye al EU AI Act ni al RGPD: es complementaria. Implantarla bien facilita el cumplimiento legal pero no lo garantiza.
No es una norma técnica de explicabilidad ni de robustez (esas son ISO/IEC 25059, 24029, 23894 y otras de la familia SC 42).

Distinción con marcos vecinos

Marco	Naturaleza	Ámbito	Certificable	Solapamiento con 42001
ISO/IEC 42001:2023	Norma de gestión	AIMS para cualquier sistema IA	Sí	—
EU AI Act (Reg. 2024/1689)	Reglamento legal vinculante	Sistemas IA en UE, riesgo-categorizado	No (es ley)	Arts 9, 10, 11, 12, 13, 14, 17
NIS2 (Dir. 2022/2555)	Directiva ciberseguridad	Entidades esenciales/importantes	Vía Esquema Nacional	Asset register, incident, supply chain
ENS (RD 311/2022)	Reglamento español de seguridad	Sector público y sus proveedores	Sí (categorías B/M/A)	Trazabilidad, gestión incidentes
ISO/IEC 27001	Norma de gestión	Seguridad de información	Sí	Estructura Annex SL + Annex A solapan
ISO/IEC 27701	Norma de gestión	Privacidad (extiende 27001)	Sí	PII en datos de entrenamiento
NIST AI RMF 1.0	Marco voluntario	Risk management AI	No	Conceptualmente alineado, no idéntico
ISO/IEC 23894	Norma técnica	Risk management AI	No	Insumo de A.5 (impact assessment)
ISO/IEC 5259	Familia	Data quality for AI	No	Insumo de A.7 (data)

Tres distinciones que importan operativamente y que son fuente de confusión recurrente con clientes:

ISO 42001 ≠ EU AI Act compliance. Tener la certificación 42001 facilita demostrar artículos 9-17 del Reglamento europeo, pero el Reglamento exige más cosas que 42001 no cubre directamente (CE marking de sistemas de alto riesgo, registro en la base de datos europea, declaración de conformidad, post-market monitoring específico). Implantar 42001 primero y luego completar los huecos del AI Act es la ruta estándar.
ISO 27001 no es suficiente. 27001 cubre confidencialidad, integridad y disponibilidad de la información. Falta el lado AI: sesgo, opacidad, deriva del modelo, calidad del corpus de entrenamiento, evaluación humana, impacto sobre afectados. 42001 es complemento, no sustituto. Las organizaciones con 27001 ya implantado tienen ventaja porque comparten la mitad de la documentación.
NIS2 ≠ AI safety. NIS2 obliga a registrar activos críticos, notificar incidentes en 24 h, gestionar la cadena de suministro digital. Los sistemas de IA pueden estar dentro del alcance NIS2 si forman parte del activo crítico (un LLM que sirve atención al cliente en una entidad financiera lo está), pero NIS2 no audita la calidad del modelo. 42001 sí.

Las siete cláusulas (Annex SL): el índice obligatorio

Las siete cláusulas de la cláusula 4 a la 10 son comunes a todas las normas de gestión modernas (Annex SL, también llamado “High Level Structure”). Esto significa que una organización con ISO 9001 o 27001 ya implantada reconoce la estructura. Las cláusulas 1-3 son introductorias (alcance, referencias normativas, términos).

Cláusula 4 — Contexto de la organización

Identificar el contexto externo (regulación aplicable, expectativas de los clientes, riesgos sociales) y el contexto interno (estrategia, cultura, capacidades). Identificar las partes interesadas y sus expectativas: clientes, reguladores, afectados, empleados, proveedores. Definir el alcance del AIMS: qué sistemas de IA están dentro y cuáles fuera.

El gap habitual: organizaciones que dicen “todos nuestros sistemas IA están en el alcance” sin haberlos enumerado. El auditor pide la lista. Sin lista, no hay alcance.

Cláusula 5 — Liderazgo

La dirección debe aprobar y publicar una política de IA (AI policy), asignar roles y responsabilidades (típicamente AI lead, AI risk owner, data officer), y demostrar compromiso con recursos, comunicación y supervisión. La política es documento auditable y debe ser proporcionada al personal y partes interesadas.

El gap habitual: política de IA genérica copiada de internet, sin medibles ni objetivos concretos. El auditor pide cómo se mide su cumplimiento. Sin métricas, la política es teatro.

Cláusula 6 — Planificación

Identificar riesgos y oportunidades del AIMS (no del modelo individual). Definir objetivos de IA medibles, con plazos y responsables. Planificar los cambios al AIMS.

El gap habitual: confundir riesgos del AIMS (¿qué pasa si no documentamos correctamente?) con riesgos del modelo (¿qué pasa si el modelo sesga?). El primero va aquí; el segundo va a A.5.

Cláusula 7 — Soporte

Recursos humanos, técnicos, financieros, infraestructura. Competencia del personal (formación documentada). Conciencia del personal sobre la política. Comunicación interna y externa. Información documentada (la columna vertebral del SI: política, procedimientos, registros, evidencias).

El gap habitual: documentación dispersa en confluence/notion/drive sin control de versiones ni aprobaciones registradas. El auditor pide el último cambio: ¿quién lo aprobó? ¿cuándo? ¿con qué justificación?

Cláusula 8 — Operación

La cláusula más operativa. Exige:

Planificación y control operacional: cómo se gestiona el ciclo de vida del sistema de IA día a día. → Cubierto en el blog por pipeline LLMOps de seis etapas.
Impact assessment (vinculado a A.5).
Gestión del ciclo de vida del sistema de IA (vinculado a A.6).
Datos para sistemas de IA (vinculado a A.7).

Es la cláusula que se materializa en los controles A.5, A.6, A.7. Por sí sola no añade requisitos nuevos: enlaza con el Annex A.

Cláusula 9 — Evaluación del desempeño

Monitoreo, medición, análisis, evaluación. Auditorías internas (planificadas, con criterios, alcance, frecuencia, registro de resultados). Revisión por la dirección (típicamente trimestral o semestral, con agenda obligatoria: inputs, evidencia, decisiones, acciones).

El gap habitual: hay tracing OTel + Langfuse + Grafana y datos de sobra, pero no hay agenda formal de revisión por la dirección con minuta documentada. El auditor pide la minuta. Sin minuta, no hay revisión.

Cláusula 10 — Mejora

No conformidad y acción correctiva: cuando algo falla, se registra, se analiza causa raíz, se acuerda corrección, se verifica eficacia. Mejora continua: el sistema evoluciona deliberadamente.

El gap habitual: tickets de Jira con post-mortems técnicos pero sin registro formal de “no conformidad ISO” que cierra con verificación de eficacia. Son dos artefactos distintos aunque puedan integrarse.

Los 38 controles del Annex A: el catálogo AI-específico

A diferencia del Annex SL (común), el Annex A es la firma AI-específica de la 42001. Los 38 controles se organizan en 9 secciones (A.2 a A.10; A.1 es la introducción) que cubren los riesgos AI-específicos: opacidad, sesgo, deriva, calidad del corpus, impacto sobre afectados, dependencia de terceros. Cada control tiene objetivo (qué se quiere conseguir) y guidance de implementación en el Annex B.

Sección	Foco	# controles
A.2	Políticas relacionadas con IA	2
A.3	Organización interna	3
A.4	Recursos para sistemas IA	6
A.5	Evaluación de impactos	5
A.6	Ciclo de vida del sistema IA	4
A.7	Datos para sistemas IA	5
A.8	Información para partes interesadas	4
A.9	Uso de sistemas IA	3
A.10	Terceros y relaciones con clientes	4
Total	—	38

Lo que sigue es el mapeo control por sección al material que ya hemos cubierto en el blog. La intención editorial es enseñar qué huecos quedan después de tener implementada la arquitectura técnica, para que el camino a certificación no empiece desde cero.

Mapeo cruzado: 38 controles ↔ posts del blog

A.2 — Políticas de IA (2 controles): PARCIAL

A.2.2 AI policy: la organización debe tener una política de IA documentada, aprobada por dirección, revisada periódicamente, comunicada y disponible. Cubre principios, alcance, compromisos.
A.2.3 Alignment with other policies: la política de IA no es huérfana — se alinea con políticas existentes de seguridad, privacidad, calidad, ética.

Hueco: no es asunto del código. La política de IA es un documento que la dirección de la organización aprueba y firma. El blog enseña la postura editorial neutra y técnica (sin hype, soberanía, OSS por defecto en ENS/NIS2) pero esto no es la política IA de una organización concreta. Cada cliente debe redactarla y firmarla.

Plantilla mínima: 1-2 páginas con: principios (transparencia, supervisión humana, fairness, responsabilidad, sostenibilidad), alcance (qué sistemas), compromisos medibles (revisión anual, evaluación de impacto antes de despliegue, formación al equipo), gobierno (quién aprueba qué).

A.3 — Organización interna (3 controles): HUECO

A.3.2 AI roles and responsibilities: roles definidos, no solapados, comunicados. Típicamente: AI lead, AI risk owner, data steward, AI ethics officer (puede ser uno solo en organizaciones pequeñas).
A.3.3 Reporting of AI incidents/concerns: canal para que cualquier persona (interna o externa) reporte un problema con un sistema IA, con seguimiento documentado.
A.3.4 Identification of stakeholders: lista mantenida de stakeholders (clientes, afectados, reguladores, partners) y sus expectativas.

Hueco: tampoco técnico. Decisión organizativa. La forma habitual de cubrirlo es nombrar un AI lead (puede ser el CIO, CTO o un rol nuevo dependiendo del tamaño), reusar el canal de reporting de seguridad (típicamente ya existe por 27001) extendiéndolo a IA, y mantener un registro vivo de stakeholders.

A.4 — Recursos (6 controles): CUBIERTO

A.4.2 Documented information: documentación del AIMS.
A.4.3 Data resources: identificación y gestión de los datos disponibles para entrenamiento, evaluación, operación.
A.4.4 Tooling resources: herramientas de desarrollo, validación, monitoreo.
A.4.5 System resources: hardware, infraestructura, cómputo.
A.4.6 Human resources: personal con competencia.
A.4.7 Financial resources: presupuesto.

Cubierto por el blog en los tres posts arquitectónicos:

Anatomía del stack: siete capas — A.4.5 system resources, A.4.4 tooling.
Siete fases del despliegue — A.4.5 + A.4.7 (presupuesto implícito).
Cinco niveles de madurez — A.4.5 + A.4.6 (madurez del equipo).
Catálogo OSS de herramientas — A.4.4 tooling.
Data versioning con DVC y lakeFS — A.4.3 data resources.

A.5 — Impact assessment (5 controles): PARCIAL

A.5.2 AI impact assessment process: procedimiento documentado de evaluación de impacto.
A.5.3 Documentation of AI impact assessments: registros de las evaluaciones hechas.
A.5.4 Alignment with AI risk treatment: las decisiones del impact assessment alimentan el tratamiento de riesgos.
A.5.5 Impacts on individuals: dimensiones específicas sobre personas afectadas (derechos, discriminación, privacidad).
A.5.6 Societal impacts: dimensiones sobre la sociedad (información, derechos sociales).

Parcial: el método existe en la familia ISO/IEC SC 42 — ISO/IEC 23894:2023 es la norma técnica de risk management para IA y NIST AI RMF 1.0 es el equivalente americano de uso libre. Pero la organización debe escribir su procedimiento y ejecutarlo por sistema antes del despliegue. No es código, es disciplina.

Plantilla mínima del impact assessment (3-5 páginas por sistema):

Descripción del sistema (qué hace, a quién sirve, modelo y stack subyacentes).
Stakeholders identificados.
Impactos potenciales (intencionados + no intencionados) en personas, grupos y sociedad.
Métricas de fairness y robustez aplicadas, con umbrales y resultados.
Mitigaciones aplicadas (guardrails, evals, supervisión humana, rate limiting).
Riesgos residuales aceptados, con justificación firmada.
Cadencia de revisión (típicamente anual o ante cambio sustancial).

A.6 — Ciclo de vida del sistema IA (4 controles): CUBIERTO

A.6.2.2 Objectives for responsible development of AI: objetivos de desarrollo responsable definidos por sistema.
A.6.2.3 Processes for responsible AI design and development: procedimientos de diseño y desarrollo.
A.6.2.4 AI system requirements and specifications: especificación formal del sistema.
A.6.2.5 Verification and validation: V&V antes y durante operación.
A.6.2.6 Deployment: procedimientos de despliegue.
A.6.2.7 Operation and monitoring: operación y monitoreo continuo.
A.6.2.8 Documentation: documentación del ciclo de vida.

Cubierto por el blog:

Pipeline LLMOps de seis etapas — el mapa maestro completo del ciclo de vida.
Anatomía de una petición LLM — la versión forense de cómo se ejecuta en producción.
Fine-tuning continuo en producción — la disciplina A.6.2.3 + A.6.2.5 + A.6.2.6 + A.6.2.7 en operativa real.
Evals: la capa después del tracing — A.6.2.5 verification and validation.
Retrain — A.6.2.7 operación + iteración continua.
Alignment moderno: DPO, KTO, ORPO, SimPO — A.6.2.3 design responsable.
MLOps panorama 2026 — el panorama de herramientas.

A.7 — Datos para sistemas IA (5 controles): CUBIERTO

A.7.2 Data for development and enhancement of AI: política y procedimientos de gestión de datos para desarrollo y mejora.
A.7.3 Acquisition of data: procedimientos de adquisición (origen, autorización, calidad).
A.7.4 Quality of data for AI systems: criterios de calidad medibles.
A.7.5 Data provenance: lineage del dato.
A.7.6 Data preparation: procedimientos de preparación (chunking, anonimización, etiquetado).

Cubierto por el blog:

RAG corpus curation: el bibliotecario activo — A.7.4 + A.7.5 + A.7.6 al detalle (cinco capas: schema, dedup, PII, anti-contaminación, lineage).
Data versioning: DVC y lakeFS — A.7.2 + A.7.5 (los cuatro artefactos data versionados con lineage).
Reranker y hybrid retrieval — A.7.6 preparación + filtrado.
LLM Guard — A.7.6 anonimización en runtime con Vault.

A.8 — Información para partes interesadas (4 controles): CUBIERTO

A.8.2 System documentation and information for users: documentación técnica disponible.
A.8.3 External reporting: capacidad de reportar a autoridades cuando aplique.
A.8.4 Communication of incidents to users: notificación a usuarios cuando hay incidente.
A.8.5 Information for interested parties: información para otros stakeholders.

Cubierto por el blog:

Tracing LLM con OpenTelemetry GenAI — A.8.2 trazabilidad por request, A.8.3 capacidad de extraer reporting forense.
Prompt versioning con Langfuse y MLflow — A.8.2 versionado documentado.
Guardrails y safety en LLMs — A.8.4 spans gen_ai.guardrail.* como base para notificación de incidentes.
LLM Guard — A.8.4 incident events para retrain.

A.9 — Uso de sistemas IA (3 controles): CUBIERTO

A.9.2 Processes for responsible use of AI: procedimientos de uso responsable.
A.9.3 Objectives for responsible use of AI: objetivos.
A.9.4 Intended use of AI systems: documentación del uso previsto.

Cubierto por el blog:

Guardrails y safety en LLMs — A.9.2 + A.9.3 (las cuatro líneas de defensa).
LLM Guard — A.9.2 detalle operativo.
Evals: la capa después del tracing — A.9.3 medición de objetivos.
Retrain — A.9.2 closed loop.

A.10 — Terceros y relaciones con clientes (4 controles): CUBIERTO

A.10.2 Allocation of responsibilities: distribución de responsabilidades entre roles AI.
A.10.3 Suppliers: procedimientos para proveedores AI.
A.10.4 Customers: procedimientos hacia clientes.
A.10.5 Third parties: procedimientos para terceros.

Cubierto por el blog:

El catálogo paralelo: OSS vs hyperscalers — A.10.3 evaluación de proveedores con análisis de lock-in y soberanía contractual.
El catálogo OSS para LLMOps — A.10.5 inventario de terceros (componentes OSS con licencias y gobierno).
Anatomía de una petición LLM — A.10.2 + A.10.4 en el caso multi-tenant.

Los roles definidos por la norma

ISO/IEC 22989:2022 (vocabulario IA, complementaria a 42001) define seis roles. Cada organización debe decidir cuáles ocupa y documentarlo:

Rol	Definición	Responsabilidad principal	Ejemplo
AI provider	Organización que provee el sistema IA a otros	Hace que el sistema esté disponible	OpenAI provee GPT-5 vía API
AI producer	Organización que desarrolla el sistema IA	Diseño, desarrollo, validación	Meta produce Llama 4
AI customer	Organización que adquiere el sistema IA	Selección, integración, supervisión	Una consultora que integra un LLM en un producto propio
AI partner	Organización que colabora con otra rol AI	Compartido	Un fabricante de hardware GPU
AI subject	Persona/grupo afectado por el sistema	Receptora del impacto	El usuario final del chatbot
Relevant authority	Regulador con jurisdicción	Supervisión externa	AEPD, CNMC, autoridades EU AI Act

Una organización puede ocupar varios roles a la vez, lo cual cambia los controles aplicables. Un patrón habitual en consultoría es: producer + customer + provider hacia el cliente final. Las responsabilidades A.10 se modulan según los roles.

Ejemplo de mapeo de roles del chatbot multi-tenant del post forense:

Fabricante del modelo base (Llama 4): AI producer del modelo base.
Operador del stack OSS (consultora): AI producer del adapter LoRA + AI provider del chatbot a sus clientes + AI customer del modelo base de Meta.
Cliente final (aseguradora): AI customer del chatbot + AI provider del servicio de atención al cliente.
Asegurado: AI subject.
AEPD + autoridad EU AI Act: relevant authority.

Cada caja del cuadro genera obligaciones distintas. La consultora, por ser producer del adapter, debe documentar A.6 (ciclo de vida) y A.7 (datos) del adapter. Por ser provider del chatbot, debe documentar A.10.4 (customers). Por ser customer del modelo base, debe documentar A.10.3 (suppliers) y validar que Meta cumple su parte.

Niveles de impacto y proporcionalidad

42001 no obliga el mismo rigor a todos los sistemas. La cláusula 6.1.2 y el control A.5 introducen el concepto de impacto como modulador. La norma no define categorías taxativas (a diferencia del EU AI Act, que sí define “prohibido / alto riesgo / riesgo limitado / mínimo”), pero recomienda usar niveles según severidad y probabilidad.

La práctica industrial 2026 alinea los niveles 42001 con las categorías del EU AI Act:

Nivel 42001	EU AI Act	Ejemplos	Profundidad de controles
Alto	Alto riesgo (Anexo III)	Scoring crediticio, RRHH, salud, infraestructura crítica	Impact assessment exhaustivo, supervisión humana obligatoria, monitoreo continuo, evals adversariales, registro detallado, revisión por dirección semestral
Medio	Riesgo limitado	Chatbots customer service no automatizan decisiones, asistentes de productividad	Impact assessment estándar, guardrails completos, revisión anual
Bajo	Riesgo mínimo	Filtros de spam, recomendaciones de contenido no personalizado	Impact assessment ligero, controles básicos

Esta proporcionalidad es clave operativa: implantar 42001 al máximo rigor para un sistema de bajo riesgo es desperdicio; relajarla en uno de alto riesgo es incumplimiento.

Los siete documentos mínimos del AIMS

Un auditor en Stage 1 (revisión documental) pide entre siete y diez documentos. Los siete imprescindibles:

Política de IA (cláusula 5.2 + A.2.2). 1-2 páginas. Aprobada por dirección, fechada, versionada.
Alcance del AIMS (cláusula 4.3). Lista de sistemas IA dentro del alcance, criterios de inclusión.
Registro de stakeholders (cláusula 4.2 + A.3.4). Lista mantenida con expectativas.
Registro de riesgos AIMS (cláusula 6.1). Riesgos del sistema de gestión, no de cada modelo.
Procedimiento de impact assessment (A.5.2) + registros de assessments ejecutados (A.5.3). Procedimiento + uno o varios assessments hechos.
Procedimiento de ciclo de vida de IA (A.6.2) — puede ser literalmente “consultar el pipeline LLMOps de seis etapas” con referencias a runbooks técnicos.
Procedimiento de gestión de datos (A.7.2) — incluye adquisición, calidad, provenance, preparación, anonimización.

Documentos adicionales habituales:

Política de uso responsable (A.9.2) con tipos de uso permitidos/no permitidos.
Procedimiento de gestión de terceros AI (A.10.3, A.10.5) con criterios de evaluación de proveedores AI.
Plan de auditorías internas + agenda de revisión por dirección (cláusulas 9.2 + 9.3).

Para una organización con stack OSS maduro, los documentos 6 y 7 son referencias a artefactos técnicos ya existentes (runbooks de pipeline, configuraciones de DVC, política de PII en LLM Guard). El esfuerzo documental real está en los documentos 1, 2, 3, 4, 5.

Caso aplicado: el chatbot multi-tenant del blog → checklist 42001

Tomamos el sistema descrito en el post forense —chatbot multi-tenant de atención al cliente para aseguradoras sobre stack OSS on-premise— y lo recorremos como auditor 42001 haría.

Cláusula 4 — Contexto. El alcance del AIMS incluye el chatbot, no incluye el sistema interno de RRHH (otra IA distinta). Stakeholders identificados: aseguradoras cliente, asegurados afectados, AEPD, autoridad EU AI Act (cuando entre en vigor 2 ago 2026), proveedor Meta (modelo base), proveedor de hardware NVIDIA. → Documentado.

Cláusula 5 — Liderazgo. Política de IA firmada por CEO, vigente. Roles asignados: AI lead (CTO), AI risk owner (CISO), data steward (Head of Data), AI ethics committee trimestral. → Documentado.

Cláusula 6 — Planificación. Registro de riesgos AIMS: documentación incompleta, churn del equipo, dependencia de proveedor único de GPU, cambio regulatorio EU AI Act. Objetivos AIMS para 2026: certificación 42001 antes Q4, cumplimiento EU AI Act high-risk antes 2 ago. → Documentado.

Cláusula 7 — Soporte. Recursos: cluster 4×H100 SXM + siete capas del stack. Competencia: 2 MLE + 2 SRE + 1 AI ethics part-time, todos con formación documentada. Comunicación: política de IA en intranet + handbook. → Documentado.

Cláusula 8 — Operación. Procedimientos operativos = pipeline LLMOps de seis etapas. Impact assessment ejecutado antes del despliegue + revisión anual + revisión ante cambio sustancial (definido: cambio de modelo base, cambio de adapter mayor, expansión a nuevo tenant). → Documentado.

Cláusula 9 — Evaluación. Monitoring: Langfuse + Tempo + VictoriaMetrics + Grafana. Métricas obligatorias en dashboard: F1 por categoría guardrail sobre tráfico real, drift estadístico, faithfulness RAG, tasa de refused. Auditoría interna trimestral con criterios escritos. Revisión por dirección semestral con minuta firmada. → Documentado.

Cláusula 10 — Mejora. Tickets de incident-driven retrain mapeados como no-conformidades cuando severity ≥ HIGH. Análisis causa raíz documentado. Eficacia verificada en el siguiente eval gate. → Documentado.

Annex A — Por sección:

A.2 (Políticas): política de IA + política de uso responsable. → Documentado.
A.3 (Organización): roles asignados, canal de reporting, registro de stakeholders. → Documentado.
A.4 (Recursos): siete fases despliegue + catálogo OSS + plan de formación + presupuesto anual. → Documentado.
A.5 (Impact): procedimiento + assessments por sistema + métricas de fairness aplicadas. → Documentado.
A.6 (Ciclo de vida): pipeline LLMOps + fine-tuning continuo + retrain. → Documentado.
A.7 (Datos): data versioning + RAG corpus curation + LLM Guard Vault + Presidio. → Documentado.
A.8 (Información partes): tracing OTel + Langfuse + spans gen_ai.guardrail.* + notificación a tenants en SLA. → Documentado.
A.9 (Uso): guardrails + evals + política de uso responsable. → Documentado.
A.10 (Terceros): OSS vs hyperscalers con análisis de lock-in + contrato Meta para modelo base + contratos con tenants. → Documentado.

Resultado del recorrido: certificable. Los huecos típicos (A.2.2 política escrita, A.3 roles, A.5 procedimiento de impact assessment) están cubiertos como documentos formales. Las cláusulas operativas (8, 9, 10) se apoyan en la arquitectura técnica del blog. La distancia entre “tener la arquitectura” y “tener certificación” se mide en disciplina documental, no en código.

Mapeo cruzado con EU AI Act, NIS2 y ENS

EU AI Act (Reg. 2024/1689) — siete artículos directamente alineados

Artículo EU AI Act	Tema	Control 42001 alineado	Aplicable a
Art. 9	Risk management system	A.5 + cláusula 6	Sistemas alto riesgo
Art. 10	Data and data governance	A.7 (todos)	Sistemas alto riesgo
Art. 11	Technical documentation	A.6 + A.4.2	Sistemas alto riesgo
Art. 12	Record-keeping (logs)	A.8.2 + tracing OTel	Sistemas alto riesgo
Art. 13	Transparency to deployers	A.8.5 + A.10.4	Sistemas alto riesgo
Art. 14	Human oversight	A.9.2 + supervisión documentada	Sistemas alto riesgo
Art. 17	Quality management system	Cláusulas 4-10	Proveedores alto riesgo

Las obligaciones principales para sistemas de alto riesgo entran en aplicación el 2 de agosto de 2026. Implantar 42001 ahora construye la base de gestión que ese deadline exige.

Qué falta para cumplimiento EU AI Act que no cubre 42001:

Conformidad CE de los sistemas de alto riesgo (declaración de conformidad, marcado, registro en EU database).
Post-market monitoring específico exigido por el Art. 72.
Reporting de incidentes graves a autoridades en plazos legales (no sólo a usuarios).
Obligaciones de transparencia a usuarios para sistemas de riesgo limitado (Art. 50): chatbots, deepfakes, contenido generado.
Prohibiciones del Art. 5 (social scoring, manipulación, biometría en tiempo real con excepciones).

NIS2 (Dir. 2022/2555) — tres pilares con solapamiento

Asset register (Art. 21.2.f): los sistemas IA en alcance NIS2 deben estar en el inventario de activos. → Solapa con A.4 + cláusula 4.3 (alcance).
Incident notification (Art. 23): incidentes significativos se notifican en 24 h (alerta inicial) + 72 h (informe detallado). → Solapa con A.3.3 (reporting) + cláusula 10 (improvement).
Supply chain security (Art. 21.2.d): evaluación de seguridad de la cadena de suministro digital. → Solapa con A.10.3 (suppliers).

Para entidades NIS2 esenciales que además usan sistemas IA, 42001 cubre la parte AI-específica que NIS2 exige inferencialmente pero no detalla.

ENS (RD 311/2022)

El Esquema Nacional de Seguridad español ya contempla expresamente IA en su anexo II (controles ENS). Categorías Básico/Medio/Alto se alinean con niveles de impacto 42001. Los controles ENS de trazabilidad (op.exp.8), registro de actividad (op.exp.10) y gestión de incidentes (op.exp.7) se cubren con los mismos artefactos técnicos que A.8 y A.5 de 42001. Una organización certificada en ENS Categoría Alta con sistemas IA está a un esfuerzo razonable de añadir 42001.

Las cinco trampas habituales de la certificación

Trampa 1 — Confundir 42001 con cumplimiento EU AI Act. Pasar la auditoría 42001 no implica conformidad con el Reglamento europeo. Son universos distintos con solapamiento del 60-70%. La trampa se descubre cuando el cliente pide CE marking del sistema de alto riesgo y la organización presenta sólo el certificado 42001.

Trampa 2 — Sobre-documentar. Manuales de 200 páginas con procedimientos copiados de plantillas, sin medibles ni evidencias de aplicación. El auditor pide la última ejecución del procedimiento — si no hay registros, los procedimientos son ornamento. La regla práctica: prefiere documentos cortos referenciando artefactos técnicos vivos a documentos largos auto-contenidos.

Trampa 3 — Sub-medir. Definir objetivos AIMS sin métricas operativas. “Mejorar la calidad del modelo” es objetivo nulo; “F1 por categoría guardrail ≥ 0,85 sobre tráfico real, medido semanalmente, revisado trimestralmente en management review” es objetivo auditable. El blog ha insistido en esto en cada post de evals, guardrails y retrain.

Trampa 4 — Ignorar A.5 hasta el día del audit. El impact assessment es el control más infravalorado y el primero que pide el auditor. Sin assessments por sistema ejecutados antes del despliegue, no hay forma de demostrar A.5. La trampa se descubre cuando ya no hay tiempo de hacer assessments retrospectivos creíbles.

Trampa 5 — Asumir que 27001 cubre lo AI. Las organizaciones con 27001 ya implantado a veces piensan que “tenemos la mitad hecha”. Es verdad para Annex SL (estructura) y para A.5/A.6/A.7 de 27001 (no de 42001) en lo que se refiere a infosec. Es falso para A.5 de 42001 (impact assessment), A.7 de 42001 (data quality AI-específica), A.9 (uso responsable) y A.10.4 (customers AI). Hay que añadir, no asumir.

Lo que no hemos cubierto (próximos posts)

Plantillas concretas de los siete documentos obligatorios, con ejemplos de redacción y métricas. Material para un post tipo “Manual del AIMS en 7 documentos” con frame de referencia.
Mapeo detallado a EU AI Act por artículo con la checklist de evidencias técnicas que se pueden derivar del stack OSS del blog. Especialmente Arts 11 (technical documentation), 14 (human oversight) y 72 (post-market monitoring).
Caso ENS Categoría Alta + 42001 combinados: qué controles ENS se cubren con qué artefactos del AIMS, evitando duplicidades.
Comparativa NIST AI RMF 1.0 vs 42001: muchos clientes internacionales piden ambos. Cómo se reciclan los mismos artefactos para satisfacer los dos frameworks.
42001 para agentes LLM y MCP: dimensiones nuevas que emergen cuando el sistema IA es agéntico (excessive agency, tool use, autonomía graduada). El post de guardrails introdujo la línea 3 (tool GR); 42001 tiene huecos abiertos en este terreno y la SC 42 trabaja en addendums.

Referencias

ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/81230.html.
ISO/IEC 22989:2022 — Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. Define los roles AI provider/producer/customer/partner/subject.
ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. Insumo de A.5.
ISO/IEC 38507:2022 — Governance implications of the use of AI by organizations. Complemento de gobierno.
ISO/IEC 5259 — Data quality for analytics and machine learning (familia). Insumo de A.7.
EU AI Act (Regulation 2024/1689) — texto consolidado en EUR-Lex. Entrada en vigor de obligaciones de alto riesgo: 2 ago 2026.
NIS2 (Directive 2022/2555) — texto consolidado en EUR-Lex.
ENS — Real Decreto 311/2022 — Esquema Nacional de Seguridad, BOE-A-2022-7191.
NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
EUR-Lex EU AI Act consolidated text — https://eur-lex.europa.eu/eli/reg/2024/1689.
A-LIGN / BSI / Schellman — blogs sobre experiencia de auditoría 42001 con casos reales 2024-2025.

Ver también

El pipeline LLMOps de seis etapas — el procedimiento operativo que materializa A.6 ciclo de vida sin trabajo adicional.
Anatomía de una petición LLM en producción — el caso forense recorrido como checklist 42001 en la sección “caso aplicado” de este post.
Siete capas del stack de inferencia LLM on-premise y siete fases del despliegue — material directo para A.4 recursos.
Cinco niveles de madurez de la plataforma — cómo justificar la proporcionalidad de los controles según el nivel de madurez existente.
Data versioning con DVC y lakeFS y RAG corpus curation — A.7 datos cubierto al detalle.
Tracing LLM con OpenTelemetry GenAI — A.8 información a partes interesadas a través de trazabilidad estandarizada.
Guardrails y safety en LLMs y LLM Guard — A.9 uso responsable.
Evals: la capa después del tracing y LLM-as-judge — A.6.2.5 verification and validation.
Retrain: cerrar el bucle feedback → dataset → adapter — cláusula 10 mejora continua + bucle incident-driven que alimenta no-conformidades formales.
El catálogo paralelo: OSS vs hyperscalers — A.10.3 evaluación de proveedores con análisis estructural de lock-in y soberanía contractual; insumo directo del registro de proveedores AI.
El catálogo OSS para LLMOps — A.10.5 inventario de terceros OSS con licencia, gobierno y madurez documentados.
MLOps específico para LLMs en 2026: panorama — contexto operativo en el que el AIMS opera y se audita.
EU AI Act: el expediente técnico artículo por artículo — el post hermano sobre el Reglamento UE 2024/1689; baja del sistema de gestión a las obligaciones legales directamente aplicables, con plazos, sanciones y mapeo control-a-artículo.
Controles técnicos: el mapeo cruzado ENS × ISO 42001 × EU AI Act — el tercer post de la trilogía de gobernanza; baja al detalle de los 25 controles técnicos comunes a los tres marcos con la tabla maestra de cumplimiento triple y el etiquetado de evidencia.
Runbooks de incident response para LLM con Keep + Kafka — la materialización operativa de la cláusula 10 (mejora continua) y la traza WORM que A.8.2 exige: cada incidente abre no-conformidad, dispara postmortem, actualiza el runbook y queda registrado en audit.actions Kafka.

EU AI Act: el expediente técnico artículo por artículo sobre la arquitectura LLM on-premise del blog

Mon, 01 Jun 2026 05:30:00 +0200

Post hermano del mapeo a ISO/IEC 42001. Aquel descomponía el sistema de gestión de IA — la norma certificable. Éste descompone el reglamento legal vinculante que aplica sin certificación: el EU AI Act es ley directa en los 27 Estados miembros, sin transposición, con sanciones explícitas hasta 35 millones de euros o el 7% del volumen mundial. Las obligaciones principales para sistemas de alto riesgo entran en vigor el 2 de agosto de 2026; cada artículo aplica desde su fecha, no desde la fecha de certificación de la organización.

TL;DR

El Reglamento UE 2024/1689 (EU AI Act, “Reglamento Europeo de Inteligencia Artificial”) publicado en el Diario Oficial el 12 de julio de 2024 establece obligaciones por niveles de riesgo (prohibido, alto, limitado, mínimo) y por rol (provider, deployer, importer, distributor, authorised representative). Las obligaciones para sistemas de alto riesgo (Anexo III: biometría, infraestructura crítica, educación, empleo, servicios esenciales públicos y privados, law enforcement, migración, justicia, procesos democráticos) entran en vigor el 2 de agosto de 2026 y son la categoría que aplica a la mayoría de proyectos LLM en empresa media-grande. Este post mapea artículo por artículo las obligaciones relevantes para un sistema LLM de alto riesgo desplegado on-premise: cada artículo enuncia su exigencia, identifica qué post del blog ya describe la pieza técnica que la materializa, y cierra con un checklist auditable que un proveedor presenta a una autoridad de supervisión nacional. El expediente técnico del Anexo IV se reconstruye apuntando sus nueve apartados obligatorios a los runbooks técnicos correspondientes. Se cubren además: la clasificación del Art. 6 y cómo decidir si un sistema cae como alto riesgo, las prohibiciones del Art. 5 (qué se excluye por construcción), las obligaciones GPAI del Art. 53 que afectan a quien construye sobre modelos base (Llama, Mistral, DeepSeek, Qwen) en lugar de modelos propios, el calendario completo de fechas de aplicación (5 ago 2024 entrada en vigor, 2 feb 2025 prohibiciones, 2 ago 2025 GPAI, 2 ago 2026 alto riesgo Anexo III, 2 ago 2027 alto riesgo Anexo I y GPAI sistémico), el cuadro de sanciones del Art. 99 (hasta 35 M€ o 7% del volumen mundial para violaciones de Art. 5, 15 M€ o 3% para alto riesgo, 7,5 M€ o 1% para información incorrecta) y las cinco trampas frecuentes del cumplimiento. La tesis editorial: la arquitectura técnica descrita en el blog cubre directamente entre el 70% y el 85% de las exigencias técnicas del Reglamento; el resto es disciplina documental y procedimental (FRIA, CE marking, declaración de conformidad firmada, registro en EU database, reporting de incidentes en plazos legales) que se construye sobre artefactos técnicos ya existentes pero que tiene su propio circuito.

La analogía: el expediente de homologación de un vehículo nuevo

Un fabricante de vehículos no puede vender un coche nuevo en la UE sin pasar WVTA (Whole Vehicle Type Approval). El proceso es público y estandarizado: el fabricante prepara un expediente técnico con docenas de capítulos (frenos, emisiones, seguridad activa y pasiva, iluminación, ruido, peso, dimensiones, materiales reciclables, dispositivos de ayuda al conductor), lo presenta a una autoridad de homologación o a un servicio técnico notificado, éste audita el dossier y, si todo cuadra, emite la homologación de tipo. El fabricante entonces estampa la etiqueta E (E1 Alemania, E9 España, etc.) y la placa CE/UNECE en cada vehículo de ese tipo producido en serie. Cada vehículo lleva además un libro de mantenimiento con revisiones obligatorias, y los accidentes graves o defectos sistémicos se reportan al ministerio competente, que puede ordenar llamadas a revisión.

El EU AI Act adapta exactamente este modelo industrial al software de IA de alto riesgo. El provider prepara el expediente del Anexo IV (nueve apartados obligatorios) con la documentación técnica completa del sistema, ejecuta un conformity assessment (con autoeval para la mayoría de casos del Anexo III, con notified body para los del Anexo I más sensibles), firma la declaración de conformidad UE, registra el sistema en la base de datos europea, y aplica el CE marking al sistema cuando se pone en mercado. A partir de ahí, debe mantener un post-market monitoring system vivo y reportar los incidentes graves a las autoridades de vigilancia del mercado de cada Estado miembro en plazos legales que van de 2 a 15 días según severidad. Si no cumple, las sanciones llegan a 35 millones de euros o el 7% del volumen mundial según artículo violado.

La analogía importa porque acota expectativas: este no es un trabajo de compliance puntual ni un sello que se compra. Es un proceso de homologación industrial, con cadencias, evidencias, firmas y responsabilidades penales. Y la mayor parte de las evidencias técnicas que pide el expediente ya existen en cualquier sistema serio descrito en este blog: lineage de datos, tracing OTel, evals continuos, guardrails, retrain incident-driven, política de uso responsable. Lo que falta es ensamblarlas en el formato legal correcto.

Encaje con ISO 42001, NIS2 y ENS

Antes de bajar a los artículos, recordamos la posición editorial del post sobre ISO 42001:

Pieza	Naturaleza	Quién la opera	Cobertura
EU AI Act	Ley directa UE	Provider + deployer + autoridades de vigilancia nacionales	Sistemas IA en mercado UE, segmentados por riesgo
ISO/IEC 42001	Norma de gestión certificable	Organización + organismo certificador	AIMS, gobierno organizacional
NIS2	Directiva ciber transpuesta	Entidades esenciales/importantes	Asset register, incident notification, supply chain
ENS (RD 311/2022)	Reglamento español de seguridad	Sector público + sus proveedores	Categorías B/M/A, certificable

Implantar 42001 facilita demostrar artículos 9-17 del EU AI Act, pero no equivale a cumplimiento legal. El cuadro de obligaciones legales y la cadena de responsabilidad penal vienen del Reglamento, no de la norma. Una organización certificada en 42001 que despliega un sistema de alto riesgo sin CE marking, sin registro en EU database, sin declaración de conformidad firmada y sin FRIA documentada, incumple el Reglamento aun teniendo el certificado en la pared.

Las cuatro categorías de riesgo y la clasificación del Art. 6

El Reglamento clasifica los sistemas en cuatro niveles de riesgo. La elección de categoría es del provider y debe documentarse en el expediente, con justificación técnica y legal.

Categoría	Artículo	Ejemplos	Consecuencia
Prohibido	Art. 5	Social scoring, manipulación, biometría tiempo real con excepciones, scraping facial indiscriminado	No puede operar en UE bajo ninguna circunstancia
Alto riesgo	Art. 6 + Anexo I + Anexo III	Scoring crediticio, RRHH, educación, infraestructura crítica, biometría no en tiempo real, justicia, migración, salud	Cumple Arts. 9-17, expediente Anexo IV, CE marking, registro EU DB
Riesgo limitado	Art. 50	Chatbots con humanos como usuarios, deepfakes, contenido sintético	Obligaciones de transparencia hacia el usuario
Riesgo mínimo	Resto	Filtros de spam, NPC de videojuegos, sugerencias de contenido	Sin obligaciones específicas; recomendado código de conducta voluntario

El test del Art. 6 para decidir si un sistema es de alto riesgo:

¿Está en el Anexo I? (productos regulados por legislación de armonización del listado: maquinaria, ascensores, juguetes, dispositivos médicos, etc.). Si el sistema IA es componente de seguridad de un producto del Anexo I, es alto riesgo.
¿Está en el Anexo III? (ocho áreas: biometría, infraestructura crítica, educación, empleo, servicios esenciales públicos/privados, law enforcement, migración/asilo, justicia/procesos democráticos). Si el sistema cae en alguna de esas áreas, es alto riesgo, excepto si se invoca la excepción del Art. 6.3 (sistemas con tarea procedimental limitada, mejora de actividades humanas previas, detección de patrones de decisión sin influir en la decisión final, tareas preparatorias).

La excepción del Art. 6.3 requiere documentación formal que justifique por qué no aplica. Es decir, ni siquiera quedar fuera es gratis: hay que demostrar por qué.

Para los sistemas LLM típicos del blog:

Chatbot de soporte al cliente para banca / seguros / salud: probablemente alto riesgo si automatiza decisiones contractuales sobre el cliente, riesgo limitado si solo informa.
Asistente interno para RRHH (criba de currículos): alto riesgo (Anexo III, área empleo).
Asistente médico (apoyo a diagnóstico): alto riesgo (Anexo III, área servicios sanitarios).
Sistema de detección de fraude: alto riesgo (Anexo III, área servicios financieros si afecta acceso a crédito).
Copiloto de código para desarrolladores: riesgo mínimo (no afecta a derechos fundamentales de terceros).
LLM as a service interno sin uso productivo: riesgo mínimo.

La decisión de categoría no es opinión: se documenta y se justifica en el expediente.

Calendario de aplicación

Las obligaciones entran escalonadas. Las fechas son inflexibles:

Fecha	Aplica
1 ago 2024	Reglamento entra en vigor
2 feb 2025	Prohibiciones del Art. 5 + obligaciones AI literacy del Art. 4
2 ago 2025	GPAI obligations (Art. 53) + gobernanza + sanciones generales + autoridades nacionales designadas
2 ago 2026	Obligaciones principales alto riesgo del Anexo III + Art. 50 transparencia a usuarios
2 ago 2027	Alto riesgo del Anexo I (componentes de productos regulados) + GPAI con riesgo sistémico

El 2 de agosto de 2026 es la fecha que importa a la mayoría de proyectos LLM empresariales. Estamos en junio 2026: queda menos de dos meses.

Mapeo artículo por artículo

Las siguientes secciones siguen la estructura del Reglamento. Para cada artículo se enuncia la exigencia, se identifica el artefacto técnico del blog que la cubre y se cierra con un checklist auditable.

Art. 5 — Prácticas prohibidas (vigente desde 2 feb 2025)

Qué exige. Prohíbe colocar en el mercado / poner en servicio / usar sistemas IA que:

Manipulen el comportamiento mediante técnicas subliminales o engañosas que distorsionen la toma de decisiones.
Exploten vulnerabilidades por edad, discapacidad o situación socioeconómica.
Implementen social scoring por parte de autoridades públicas.
Hagan policía predictiva individual basada en perfilado.
Hagan scraping indiscriminado facial para construir bases de datos de reconocimiento facial.
Inferencia de emociones en lugares de trabajo o educación, salvo razones médicas/seguridad.
Categorización biométrica que infiera atributos sensibles (raza, opinión política, orientación sexual, etc.).
Biometría de identificación en tiempo real en espacios públicos por law enforcement, con excepciones estrictas (terrorismo, secuestro, personas desaparecidas) con autorización judicial previa.

Stack del blog. Ninguna pieza del blog facilita estas prácticas; el catálogo OSS descrito está orientado a tareas legítimas. Pero el provider debe documentar explícitamente por qué el sistema no cae en estas prohibiciones. No es asumible.

Checklist.

Análisis de prohibiciones documentado por sistema, con declaración escrita de no aplicabilidad.
Si el sistema usa biometría facial o análisis de emociones: análisis legal específico con dictamen.
Revisión legal anual o ante cambio de funcionalidad.

Art. 6 — Clasificación de sistemas de alto riesgo

Qué exige. Definir si el sistema es de alto riesgo por estar en Anexo I (componente de seguridad de producto regulado) o Anexo III (8 áreas). Si está en Anexo III, evaluar excepción Art. 6.3 si aplica.

Stack del blog. El post forense y el pipeline de seis etapas describen sistemas que típicamente son alto riesgo (chatbot multi-tenant que afecta a decisiones de servicio al cliente regulado).

Checklist.

Análisis Art. 6 firmado por responsable legal de la organización.
Si se invoca Art. 6.3: documentación formal de la excepción.
Re-evaluación si la funcionalidad cambia (ej. el asistente pasa de informar a tomar decisiones).

Art. 9 — Sistema de gestión de riesgos

Qué exige. Sistema iterativo, planificado y ejecutado durante todo el ciclo de vida. Identificar riesgos previsibles, estimar riesgos en uso normal y previsible mal uso, evaluar riesgos emergentes en post-market monitoring, adoptar medidas de mitigación, comunicar riesgos residuales. Las pruebas de eficacia se hacen en condiciones realistas.

Stack del blog.

Pipeline LLMOps de seis etapas — el ciclo de vida iterativo.
Evals: la capa después del tracing — pruebas en condiciones realistas con golden sets.
Guardrails y safety en LLMs — medidas de mitigación operativas.
Retrain: cerrar el bucle — gestión de riesgos emergentes via incident-driven retrain.

Checklist.

Documento de gestión de riesgos por sistema, con identificación, mitigación, riesgos residuales aceptados y firmados.
Procedimiento de revisión periódica (mínimo anual o ante cambio sustancial).
Vinculación con el bucle de mejora documentado.

Art. 10 — Datos y gobernanza de datos

Qué exige. Datasets de entrenamiento, validación y testing relevantes, representativos, lo más libres de errores y completos posible, considerando características del propósito previsto. Documentar:

Recogida y selección de datos.
Procesamiento y anotación.
Sesgos identificados con probabilidad de afectar derechos fundamentales o causar discriminación; medidas para prevenirlos.
Identificación de lagunas en datos y cómo se aborda.

Stack del blog.

Data versioning con DVC y lakeFS — los cuatro artefactos data + lineage end-to-end.
RAG corpus curation: el bibliotecario activo — cinco capas: schema, dedup, PII, anti-contaminación, lineage.
LLM Guard: Vault y Anonymize — anonimización runtime con restitución.

Checklist.

Documento de gobernanza de datos por dataset (training / RAG corpus / golden eval / enriched retrain).
Análisis de sesgos por categoría protegida con métricas (parity ratio, equalized odds, calibration).
Procedimiento de PII / anonimización / pseudonimización con F1 medido.
Justificación de representatividad para el contexto previsto.
Lineage chunk→trace verificable.

Art. 11 + Anexo IV — Documentación técnica

Qué exige. Expediente técnico con los nueve apartados del Anexo IV, redactado antes de poner el sistema en el mercado, mantenido durante operación, disponible para autoridades diez años tras la última operación. Los nueve apartados:

Descripción general del sistema: nombre, versión, propósito, integrador, hardware previsto, instrucciones de uso.
Descripción detallada del diseño y desarrollo: arquitectura, modelos base, métodos de entrenamiento, decisiones de diseño con justificación.
Información sobre monitoreo, funcionamiento y control: capacidades, limitaciones, precisión esperada, comportamiento en uso normal y mal uso previsible.
Información sobre datos: datasets usados, fuentes, métodos de preparación, sesgos abordados.
Descripción del sistema de monitoreo y métricas: trazas, logs, dashboards.
Descripción del QMS y procedimientos del Art. 17.
FRIA si aplica (Fundamental Rights Impact Assessment, Art. 27).
Logs automáticamente generados que el sistema almacena (Art. 12).
Declaración de conformidad UE del Art. 47 incluida.

Stack del blog. Sirve como insumo directo para cada apartado:

Apartado Anexo IV	Insumo técnico del blog
1. Descripción general	Anatomía del stack: 7 capas + siete fases despliegue
2. Diseño y desarrollo	Pipeline LLMOps 6 etapas + fine-tuning continuo + alignment moderno
3. Capacidades y limitaciones	Evals + LLM-as-judge
4. Datos	Data versioning + RAG corpus curation
5. Monitoreo	Tracing LLM con OTel GenAI + prompt versioning
6. QMS	Procedimientos derivados de ISO 42001
7. FRIA	Hueco — ver Art. 27 abajo
8. Logs	Tracing OTel + retención y políticas
9. Declaración conformidad	Hueco documental — ver Art. 47 abajo

Checklist.

Expediente Anexo IV completo, versionado, fechado, firmado.
Acceso retención 10 años garantizado (storage inmutable / WORM).
Procedimiento de actualización ante cambio sustancial.

Art. 12 + Art. 19 — Record-keeping (logs)

Qué exige. El sistema de alto riesgo debe ser técnicamente capaz de generar logs automáticos durante su operación. Estos logs deben permitir:

Trazar el funcionamiento del sistema a lo largo del tiempo.
Facilitar el post-market monitoring (Art. 72).
Permitir investigación de incidentes graves (Art. 73).
Soportar auditorías.

El provider debe conservar los logs durante al menos seis meses (o más si lo exigen leyes nacionales o el QMS). Para sistemas biométricos de identificación remota, requisitos específicos adicionales.

Stack del blog.

Tracing LLM con OpenTelemetry GenAI — el sustrato canónico. Cada request emite un span con trace_id, atributos gen_ai.*, costes, latencias, decisiones de guardrail.
Prompt versioning — prompt_id + version viajan como atributos.
Guardrails y safety en LLMs — atributos gen_ai.guardrail.* registran cada decisión.
LLM Guard — spans por scanner con risk_score y action.
Data versioning — dataset_hash y model_version propagados.

Checklist.

OTel + backend (Tempo, Jaeger) operativos en producción.
Retención mínima 6 meses (sugerido 24-36 meses para regulación financiera).
Almacenamiento WORM / inmutable.
PII en logs redactada (vía LLM Guard Vault o equivalente) — los logs no son excepción de RGPD.
Procedimiento de consulta forense con permisos auditados.

Art. 13 — Transparencia a los deployers

Qué exige. El provider entrega al deployer instrucciones de uso claras, completas y accesibles, en lenguaje comprensible, con:

Identidad del provider.
Características, capacidades, limitaciones (precisión por categoría, especificaciones técnicas).
Cambios previstos al sistema y sus métricas.
Medidas de supervisión humana (Art. 14).
Recursos computacionales y hardware previstos.
Cuándo aplica, expectativa de vida del sistema y de mantenimiento.

Stack del blog.

Catálogo OSS para LLMOps — qué componentes y con qué función.
OSS vs hyperscalers — análisis del lock-in y dependencias documentadas.
Anatomía petición LLM — capacidades y limitaciones forenses.

Checklist.

Manual del usuario en lenguaje no técnico para deployer + manual técnico detallado.
Métricas de precisión por categoría con thresholds.
Procedimiento de cambio con notificación previa.

Art. 14 — Supervisión humana

Qué exige. Sistema diseñado para permitir supervisión humana efectiva durante el periodo de uso, con interfaces y procedimientos que faciliten:

Comprender capacidades y limitaciones.
Detectar disfunciones (automation bias awareness).
Decidir no usar la salida del sistema, anularla, revertirla.
Para biometría de identificación remota: verificación humana antes de actuar, al menos dos personas.

Stack del blog.

Guardrails y safety — Línea 3 (Tool GR) con human-in-the-loop para acciones destructivas.
Evals — métricas en dashboard humano accesibles.
Tracing OTel — Langfuse con sessions humanas auditables.

Checklist.

Interfaz de supervisión documentada con casos de uso.
Capacidad de override / abort sin restricciones técnicas.
Formación documentada al personal de supervisión.
Métricas de efectividad de la supervisión (override rate, false-negative rate de la supervisión).

Art. 15 — Precisión, robustez y ciberseguridad

Qué exige. Sistemas de alto riesgo se diseñan y desarrollan para alcanzar un nivel apropiado de precisión, robustez y ciberseguridad, y para funcionar consistentemente durante todo su ciclo de vida. Las métricas relevantes de precisión se declaran en las instrucciones de uso. Resistencia a:

Errores, fallos, inconsistencias dentro del entorno de uso.
Sesgos de retroalimentación durante operación (feedback loops).
Ataques que intenten explotar vulnerabilidades del sistema (data poisoning, model poisoning, model evasion, confidentiality attacks).
Medidas técnicas y organizativas para detectar, responder, resolver vulnerabilidades.

Stack del blog.

Quantization fundamentos — precisión vs eficiencia con métricas reportadas.
Continuous batching + KV cache — robustez operativa.
Guardrails: línea 1 input + línea 2 retrieval — defensa frente a prompt injection y data poisoning vía RAG.
LLM Guard: PromptGuard 2 + scanners injection — mitigación adversarial directa.
Evals: jailbreak resistance + adversarial — métricas de robustez evaluadas en CI.

Checklist.

Métricas de precisión declaradas: F1 por categoría, accuracy, calibración, faithfulness RAG, hallucination rate.
Plan de robustez frente a adversarial inputs (suite Garak / Promptfoo redteam / PyRIT ejecutada periódicamente).
Plan ciberseguridad: gestión vulnerabilidades, patching del stack (vLLM, sus deps, cuda), secrets rotation.
Análisis de feedback loops potenciales con monitoreo de drift.

Art. 17 — Sistema de gestión de calidad (QMS)

Qué exige. El provider tiene un QMS escrito, sistemático y proporcionado, que cubra (sin limitarse a):

Estrategia de cumplimiento regulatorio.
Diseño, verificación, control de calidad del sistema.
Procedimientos de testeo, validación.
Gestión de datos.
Sistema de gestión de riesgos (Art. 9).
Post-market monitoring (Art. 72).
Reporting de incidentes (Art. 73).
Comunicación con autoridades, deployers, otros stakeholders.
Registros: documentación, mantenimiento de logs.
Gestión de recursos.
Accountability: responsabilidades de management.

Stack del blog. El QMS no es código pero se apoya en código.

ISO/IEC 42001 implantada (post anterior) cubre prácticamente todo el contenido del Art. 17.
Pipeline LLMOps 6 etapas como procedimiento operativo de referencia.

Checklist.

Manual del QMS escrito, fechado, firmado, versionado.
Plan anual de auditorías internas con criterios y registros.
Agenda de revisión por dirección con minutas firmadas.
Si hay 42001 implantada: mapping QMS-42001 documentado.

Art. 26 — Obligaciones de los deployers

Qué exige. Quien despliega el sistema (lo usa en su nombre, no necesariamente el desarrollador) tiene obligaciones propias:

Usar el sistema conforme a las instrucciones (Art. 13).
Asignar supervisión humana competente y formada (Art. 14).
Asegurar que los datos de entrada que controla son apropiados.
Monitorear el funcionamiento y notificar al provider si detecta problemas o incidentes graves.
Mantener logs bajo su control durante al menos 6 meses.
Informar a las personas afectadas cuando el sistema se use sobre ellas para tomar decisiones (en el contexto laboral, además, consultar a sus representantes).
Para algunos casos del Anexo III: completar un FRIA (Art. 27).

Stack del blog. En el caso del chatbot multi-tenant, el deployer es la aseguradora cliente. Esta debe:

Aceptar las instrucciones del provider (la consultora) y firmar términos.
Configurar supervisión humana en su lado.
Notificar al provider cuando detecta drift o queja seria.
Conservar logs propios además de los del provider.

Checklist (para el deployer).

Contrato con provider con SLAs, responsabilidades, plan de salida.
Programa de formación a personal supervisor.
Procedimiento de notificación de incidentes hacia provider.
Política de información a afectados (en ámbito laboral, notificación a representantes).
FRIA si aplica.

Art. 27 — Fundamental Rights Impact Assessment (FRIA)

Qué exige. Aplicable a deployers que sean cuerpos públicos o entidades privadas que provean servicios públicos, o que usen sistemas para evaluar credit score / life insurance. Antes del primer uso, el deployer hace un FRIA documentando:

Descripción del uso previsto.
Periodo y frecuencia de uso.
Categorías de personas afectadas.
Riesgos específicos de daño identificados.
Medidas de supervisión humana.
Medidas de mitigación si los riesgos se materializan.

El FRIA se notifica a la autoridad de vigilancia del mercado. Cambios sustanciales obligan a actualizar.

Stack del blog. El FRIA es un documento de gobierno, no un artefacto técnico. El blog no lo cubre directamente. Pero el insumo técnico es:

Los análisis de impacto del post sobre ISO 42001 — sección A.5 son el punto de partida natural.
Las métricas del post sobre evals sobre fairness por categoría y groundedness alimentan la sección de riesgos del FRIA.

Checklist.

Procedimiento FRIA documentado, alineado con AIIA ISO 42005 (publicada como complemento).
FRIA ejecutado por sistema antes del primer uso.
Notificación a autoridad de vigilancia del mercado.
Revisión periódica + ante cambio sustancial.

Art. 47 — Declaración UE de conformidad

Qué exige. El provider redacta una declaración de conformidad escrita por sistema de alto riesgo, indicando:

Identificación del sistema y provider.
Declaración de que cumple los Arts. 8-15 + Art. 17.
Referencia a normas armonizadas y especificaciones comunes aplicadas.
Si aplica, notified body y certificado.
Lugar y fecha, firma y nombre del firmante autorizado.

Debe estar disponible para autoridades diez años. Se mantiene actualizada.

Stack del blog. Documento legal puro. Plantilla del Anexo V.

Checklist.

Declaración de conformidad firmada por persona autorizada antes de mercado.
Idiomas: al menos UE oficial donde se ponga el sistema en mercado.
Procedimiento de re-firma ante cambio sustancial.

Art. 48 — Marcado CE

Qué exige. Sistema de alto riesgo lleva el marcado CE de manera visible, legible e indeleble. Para sistemas digitales sin parte física, el marcado se incluye en la documentación / interfaz. Si participó un notified body, su número va a continuación.

Stack del blog. El marcado CE en un sistema software se materializa típicamente en:

Página de información del producto / “Acerca de”.
Documentación oficial del producto entregada al deployer.
Metadata del API exposed (header HTTP custom, OpenAPI info).

Checklist.

CE marking visible en interfaz del producto o documentación oficial.
Número notified body adjunto si aplicó.
Procedimiento de actualización ante cambio sustancial.

Art. 49 — Registro en la base de datos europea

Qué exige. Antes de poner en mercado / poner en servicio un sistema de alto riesgo del Anexo III (excepto el área 2 — infraestructura crítica), el provider lo registra en la base de datos UE de sistemas IA de alto riesgo gestionada por la Comisión. Los deployers que sean autoridades públicas también registran su uso. Los datos del registro son públicos en su mayoría (transparencia hacia el público).

Stack del blog. Procedimiento administrativo puro. Sin parte técnica más allá de tener el dossier preparado.

Checklist.

Registro completado antes del primer uso productivo.
Actualización ante cambio sustancial.
Acceso al portal mantenido (credenciales, contacto).

Art. 50 — Transparencia a los usuarios finales

Qué exige. Aplica a sistemas de riesgo limitado (y también a algunos de alto riesgo, complementariamente):

Chatbots y asistentes IA: la persona que interactúa debe saber que está hablando con una IA, salvo que sea obvio del contexto.
Contenido sintético generado (texto, audio, imagen, video): marcar como contenido AI-generated en el output, en formato machine-readable.
Deepfakes: declarar explícitamente que el contenido es artificialmente generado o manipulado.
Detectores de emociones o categorización biométrica: informar a las personas afectadas.

Stack del blog. Materialización técnica:

Banner UI en el chatbot indicando “Estás conversando con un asistente IA”.
Disclaimer en cada respuesta exportable (PDF, email): “Generado por IA”.
Watermarking del output (perplexity-based, model-fingerprint) — opcional pero útil para deepfakes.
Para audio/imagen/video generado, metadatos C2PA estándar.

Checklist.

Banner UI obligatorio.
Disclaimer en outputs exportables.
Si genera contenido visual: marcado C2PA o equivalente.
Procedimiento ante uso del sistema sobre persona sin su conocimiento (ej. evaluación automática de CV).

Art. 53 — Obligaciones de los proveedores de GPAI (vigente desde 2 ago 2025)

Qué exige. Los proveedores de GPAI (modelos de propósito general entrenados con vasto cómputo, típicamente fundacionales: Llama 4, Mistral, DeepSeek, Qwen, Gemma) deben:

Mantener documentación técnica del modelo, accesible a la AI Office y autoridades nacionales.
Hacer disponible información para los proveedores downstream que vayan a integrarlo.
Cumplir con copyright UE (Art. 4 Directiva 2019/790): mecanismo opt-out para titulares de derechos.
Publicar un resumen del contenido del training (Anexo XI - copyright summary).

Si el modelo tiene riesgo sistémico (umbral 10^25 FLOPs o designado por la Comisión), obligaciones adicionales (Art. 55): model evaluation, adversarial testing, reporting incidentes, cybersecurity.

Stack del blog. Para una organización que usa modelos GPAI (Llama 4, Mistral) y no los entrena desde cero:

No es provider GPAI; es downstream provider que integra GPAI en su sistema.
Debe disponer de la documentación técnica del GPAI (Llama paper, Mistral docs) y referenciarla en su propia documentación Anexo IV.
Análisis de licencia GPAI específica (Llama Community License, Apache 2.0, etc.).
El post sobre alignment moderno y fine-tuning continuo describen cómo el adapter LoRA sobre el GPAI no convierte al downstream en provider GPAI siempre que no entrene un modelo nuevo desde cero.

Checklist (downstream provider).

Inventario de GPAI usados con versión, fuente, licencia, documentación referenciada.
Mapping responsabilidades upstream provider GPAI vs nosotros como downstream.

Art. 72 — Post-market monitoring

Qué exige. Sistema documentado de monitoreo post-mercado proporcional al riesgo, que recoja datos sobre el funcionamiento durante todo el ciclo de vida, incluyendo interacción con otros sistemas IA. Permite al provider:

Evaluar cumplimiento continuo de Arts. 8-15.
Adoptar medidas correctivas necesarias.
Detectar tendencias en uso real (drift, abuso).

El plan de monitoreo es parte del Anexo IV y se mantiene durante toda la vida del sistema. La Comisión publica plantilla en 2026.

Stack del blog.

Tracing OTel + Langfuse — la base.
Evals continuos — métricas operativas como gates online.
LLM-as-judge — judges sobre sampling de producción para detectar degradación.
Retrain incident-driven — el bucle de mejora cerrado.

Checklist.

Plan de monitoreo post-mercado documentado por sistema.
Métricas operativas definidas con thresholds y revisión periódica.
Procedimiento de acción correctiva ante alerta.
Integración con Art. 73 (cuando alerta = incidente grave).

Art. 73 — Reporting de incidentes graves

Qué exige. Definición de incidente grave (Art. 3(49)):

Muerte o daño grave a la salud.
Disrupción grave de infraestructura crítica.
Infracción de obligaciones legales destinadas a proteger derechos fundamentales.
Daño grave a la propiedad o al medio ambiente.

El provider reporta a la autoridad de vigilancia del mercado del Estado miembro donde ocurrió el incidente. Plazos:

Tipo de incidente	Plazo máximo desde que se conoce
General	15 días
Muerte	10 días
Infra crítica afectada o infracción amplia	2 días

El primer informe puede ser preliminar; el completo sigue después. Investigación interna obligatoria; cooperación con autoridades. Acción correctiva proporcional.

Stack del blog. El flujo técnico:

Tracing OTel provee la trazabilidad para investigación forense.
Guardrails y safety emite el incident_event canónico (categoría, severity, trace_id).
Retrain incident-driven materializa la acción correctiva.

Checklist.

Procedimiento de incident reporting documentado con plazos y plantillas.
Persona designada (típicamente DPO + AI Risk Owner) con responsabilidad y formación.
Dry-run anual del procedimiento (simulacro).
Integración técnica entre la capa de guardrails / tracing y el canal de notificación.

El expediente Anexo IV ensamblado: SVG del dossier completo

El gráfico muestra la asimetría editorial del blog: siete de nueve apartados del Anexo IV los cubre el stack técnico directamente. Solo el FRIA (apartado 7) y la declaración de conformidad firmada (apartado 9, no representado en el SVG por ser un documento de una página) son huecos documentales que necesitan trabajo administrativo expreso. El esfuerzo principal de cumplimiento es ensamblar y firmar, no construir desde cero.

Caso aplicado: el chatbot multi-tenant evaluado contra el AI Act

Tomamos el sistema del post forense — chatbot multi-tenant de atención al cliente para aseguradoras — y lo recorremos como provider del sistema.

Clasificación Art. 6: el chatbot ayuda a clientes a entender productos, consultar estado, abrir incidencias. No automatiza decisiones contractuales (no aprueba siniestros, no calcula primas). Cae en Anexo III área 8 (servicios privados esenciales)? — depende del uso. Si la aseguradora lo usa solo para soporte informativo, riesgo limitado (aplica Art. 50). Si lo usa para evaluar declaraciones de siniestros, alto riesgo. Documentación obligatoria del análisis.

Asumimos alto riesgo para el recorrido completo:

Art. 5 prohibiciones: declaración escrita de no aplicabilidad. ✓
Art. 9 risk management: documento por sistema con riesgos identificados (alucinación, sesgo por dialecto, fuga PII, jailbreak), mitigaciones aplicadas (RAG con corpus curado, guardrails con 4 líneas, LLM Guard Vault, evals continuos), residuales aceptados firmados. ✓ (insumo: pipeline + guardrails + evals).
Art. 10 data governance: gobernanza de los cuatro datasets (training adapter, RAG corpus aseguradora, golden eval, enriched retrain) con sesgos analizados, PII anonimizada, lineage. ✓ (insumo: data-versioning + rag-corpus-curation + LLM Guard).
Art. 11 + Anexo IV: expediente con 9 apartados redactado, firmado, accesible 10 años en bucket WORM. ✓ (7 apartados de blog, 2 nuevos).
Art. 12 + Art. 19 logs: OTel + Tempo + Langfuse con retención 24 meses, PII redactada por Vault. ✓.
Art. 13 transparencia deployers: manual de usuario para aseguradora + manual técnico. ✓ (insumo: catálogo OSS + anatomía request).
Art. 14 supervisión humana: dashboard Langfuse + Grafana + protocolo de escalado humano para casos críticos + formación al personal de la aseguradora. ✓.
Art. 15 precisión, robustez, ciberseguridad: métricas F1 por categoría declaradas, suite adversarial Promptfoo redteam ejecutada mensualmente, plan ciberseguridad del stack (vLLM patching, secrets rotation). ✓.
Art. 17 QMS: ISO 42001 implantada y certificada. ✓.
Art. 26 deployer: contrato con aseguradora incluye obligaciones del deployer. ✓.
Art. 27 FRIA: la aseguradora ejecuta FRIA antes de primer uso (es entidad privada de servicio esencial). ✓ (responsabilidad del deployer, provider asiste).
Art. 47 declaración conformidad: firmada por el CTO de la consultora antes de mercado. ✓.
Art. 48 CE marking: visible en la interfaz del chatbot y en documentación oficial. ✓.
Art. 49 registro EU DB: completado antes del primer uso productivo. ✓.
Art. 50 transparencia usuarios: banner UI “Estás hablando con un asistente IA”, disclaimer en respuestas exportables. ✓.
Art. 53 GPAI: documentación de Llama 4 (modelo base) referenciada + análisis copyright EU + mapping de responsabilidades. ✓.
Art. 72 post-market monitoring: plan documentado, OTel + evals continuos + retrain ya operativos. ✓.
Art. 73 reporting incidentes: procedimiento + responsable designado + dry-run anual. ✓.

Resultado: certificable y desplegable en mercado UE el 2 de agosto de 2026. Los huecos clave (FRIA, CE marking, registro EU DB, declaración conformidad) son trabajo documental sobre artefactos técnicos ya existentes, no proyectos técnicos nuevos.

Sanciones (Art. 99)

El cuadro de sanciones es proporcional al volumen mundial o a un tope absoluto, el que sea mayor:

Violación	Tope sanción
Art. 5 (prácticas prohibidas)	Hasta 35 M€ o 7% volumen mundial anual
Otras obligaciones (Arts. 8-22, 26-50, 72-73, etc.)	Hasta 15 M€ o 3% volumen mundial anual
Información incorrecta o engañosa a autoridades	Hasta 7,5 M€ o 1% volumen mundial anual

Para PYMEs y startups, los topes son el menor de las dos cifras (no el mayor) — la mitigación de proporcionalidad existe pero requiere demostración formal.

Adicionalmente, las autoridades nacionales pueden ordenar:

Suspensión inmediata del sistema en el mercado.
Llamada a revisión (recall) obligatoria.
Comunicación pública obligatoria de la sanción.

Las cinco trampas frecuentes del cumplimiento

Trampa 1 — Asumir que el modelo GPAI usado ya cubre las obligaciones. El downstream provider sigue siendo responsable del sistema integrado: ni Meta ni Mistral ni DeepSeek asumen las obligaciones de quien construye sobre sus modelos. La trampa se descubre cuando la autoridad pide el expediente y el equipo apunta al model card de Llama como si bastara.

Trampa 2 — Confundir ISO 42001 con conformidad EU AI Act. Tener 42001 certificado no implica conformidad: la certificación no es FRIA, no es CE marking, no es registro en EU database, no es declaración de conformidad firmada. La normalización avanza pero hasta que ISO 42001 se publique como norma armonizada (no lo era al cierre de 2025), no hay presunción de conformidad. El cuadro de obligaciones legales tiene su propio circuito.

Trampa 3 — Olvidar el reporting de incidentes en plazo legal. 15 días suena largo hasta que un incidente coincide con vacaciones de verano. 2 días para infra crítica no es negociable. Sin procedimiento documentado y simulacro anual, el plazo se incumple en silencio. Sanción por información engañosa (1% volumen mundial) si el reporting incompleto se descubre.

Trampa 4 — Subestimar el deployer. El AI Act asigna obligaciones tanto al provider como al deployer. Una empresa que usa un LLM hospedado integrado en su servicio (sin desarrollarlo) sigue siendo deployer con obligaciones propias (Art. 26): supervisión humana, FRIA si aplica, notificación a personas afectadas. La trampa se descubre cuando el deployer asume que “la responsabilidad es del proveedor del modelo” — no lo es del todo.

Trampa 5 — Dejar el FRIA para el final. El FRIA (Art. 27) requiere análisis de impacto sobre derechos fundamentales con dimensiones cualitativas (discriminación, privacidad, derechos sociales). No es un documento de una tarde. Se ejecuta antes del primer uso, no después de detectar un problema. Los deployers públicos y los proveedores de servicios esenciales privados que lo dejan para “cuando lo pidan” tardan 4-8 semanas en producir uno creíble — tiempo que típicamente no se tiene cuando llega la inspección.

Lo que no hemos cubierto (próximos posts)

Plantillas concretas de cada documento: declaración de conformidad UE (Anexo V), expediente Anexo IV completo apartado por apartado, FRIA, plan de post-market monitoring, informe inicial de incidente grave. Material para un post tipo “Carpeta del cumplimiento EU AI Act en 12 plantillas”.
Códigos de práctica voluntarios publicados por la Comisión bajo Art. 56 — útiles para sistemas de riesgo limitado que quieran demostrar buen comportamiento sin obligación legal.
Análisis comparativo de notified bodies para sistemas que requieran conformity assessment de tercero (Anexo I principalmente).
Cómo cambia el cumplimiento para agentes LLM — sistemas con autonomía gradúa, tool calling, capacidad de acción. La SC 42 y la AI Office trabajan en guidance específica.
El cuadro completo de autoridades nacionales designadas bajo Art. 70 + autoridades sectoriales que mantienen jurisdicción (AEPD para privacidad, CNMV para servicios financieros, Banco de España para banca, AESA para aviación).

Referencias

Regulation (EU) 2024/1689 (EU AI Act) — Texto consolidado en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689. Diario Oficial L 1689/12.7.2024.
EU AI Act Explorer (AI Act Service Desk, Comisión Europea): https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer.
AI Act Text portal (artificialintelligenceact.eu): artículos individuales con anotaciones.
Anexo IV — Technical documentation: estructura de los nueve apartados obligatorios.
Anexo V — EU declaration of conformity: plantilla obligatoria.
Anexo III — High-risk AI systems: las ocho áreas que clasifican un sistema como alto riesgo.
Anexo XI — Copyright training summary template: para GPAI providers.
NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
ISO/IEC 42001:2023 — sistema de gestión, complemento facilitador.
ISO/IEC 42005 — Impact assessment AI (publicada 2025 como guía técnica para FRIA).
Draft Commission guidance on serious incident reporting (2025) — borrador en consulta para Art. 73.

Ver también

ISO/IEC 42001: el manual de operaciones del sistema de IA — el post hermano sobre el sistema de gestión que facilita demostrar Arts. 9, 10, 11, 17 del Reglamento.
El pipeline LLMOps de seis etapas — el ciclo de vida que materializa los Arts. 9 (risk management) y 17 (QMS) operativamente.
Anatomía de una petición LLM en producción — el caso forense usado como checklist del cumplimiento en este post.
Data versioning con DVC y lakeFS y RAG corpus curation — Art. 10 data governance.
Tracing LLM con OpenTelemetry GenAI — Arts. 12 + 19 (record-keeping) con OTel canónico.
Guardrails y safety en LLMs — Arts. 14 (supervisión humana) y 15 (ciberseguridad/robustez).
LLM Guard: el traductor jurado con cuaderno de equivalencias — Art. 10 + Art. 12 con PII redactada en path runtime.
Evals: la capa después del tracing — Art. 15 (precisión) y Art. 72 (post-market monitoring).
Retrain: cerrar el bucle feedback → dataset → adapter — Art. 72 mejora continua + Art. 73 acción correctiva tras incidente.
El catálogo paralelo: OSS vs hyperscalers — Art. 53 (GPAI obligations) y análisis de proveedores GPAI integrados.
El catálogo OSS para LLMOps — Art. 13 (transparencia a deployers) con inventario completo de componentes.
Alignment moderno: DPO, KTO, ORPO y SimPO — diseño responsable del adapter (Art. 9 mitigación + Art. 15 robustez).
Controles técnicos: el mapeo cruzado ENS × ISO 42001 × EU AI Act — el zoom técnico al solapamiento de los tres marcos. Una sola pieza de tracing, una sola pieza de guardrails, una sola pieza de versionado materializa las exigencias técnicas de ENS + 42001 + AI Act simultáneamente cuando se etiqueta con vocabulario común.
Runbooks de incident response para LLM con Keep + Kafka — la operacionalización del Art. 73 (reporting of serious incidents) con plazos 2/10/15 días según severity, workflows Keep YAML y topic Kafka audit.actions WORM como evidencia para autoridad competente.

Compliance on lo0 — Blog Técnico

Runbooks de incident response para inferencia LLM: cada alerta a una acción concreta con Kafka y Keep

TL;DR

Estás aquí: OBSERVE → DEPLOY (incident response cierra el bucle)

La analogía: la sala de control de un reactor nuclear

La arquitectura del incident pipeline

Las seis alertas críticas y sus runbooks

RB-01 · GpuHbmNearOom — HBM > 92 % sostenido

RB-02 · GpuThermalOrPowerThrottle — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

RB-03 · GpuXidErrorDetected — increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

RB-04 · GpuEccDoubleBit — DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0

RB-05 · VllmKvCachePoolNearFull — gpu_cache_usage_perc > 95 % sostenido 3 min

RB-06 · VllmTtftP95OutOfSlo — TTFT P95 > 1.5 s durante 5 min

Workflows Keep YAML — tres ejemplos completos

Workflow 1 — xid-detected.yaml

Workflow 2 — ecc-dbe.yaml — paginación inmediata

Workflow 3 — canary-rollback.yaml — TTFT P95 fuera de SLO

El schema canónico de eventos Kafka

Encaje formal en gestión de incidentes

ISO/IEC 27035 — gestión de incidentes de seguridad de la información

ENS (Esquema Nacional de Seguridad) — controles op.exp

NIS2 — notificación a autoridad competente

EU AI Act — art. 73 (serious incident reporting)

ISO/IEC 42001 — AIMS cláusula 10 mejora continua

Cuatro anti-patrones

Aplicado a hardware on-premise típico

Lo que no hemos cubierto (próximos posts)

Ver también

Referencias

ISO/IEC 42001: el manual de operaciones del sistema de IA — cómo encaja el AIMS sobre la plataforma LLM on-premise descrita en el blog

TL;DR

La analogía: el manual de operaciones del avión

ISO/IEC 42001 en 15 segundos

Distinción con marcos vecinos

Las siete cláusulas (Annex SL): el índice obligatorio

Cláusula 4 — Contexto de la organización

Cláusula 5 — Liderazgo

Cláusula 6 — Planificación

Cláusula 7 — Soporte

Cláusula 8 — Operación

Cláusula 9 — Evaluación del desempeño

Cláusula 10 — Mejora

Los 38 controles del Annex A: el catálogo AI-específico

Mapeo cruzado: 38 controles ↔ posts del blog

A.2 — Políticas de IA (2 controles): PARCIAL

A.3 — Organización interna (3 controles): HUECO

A.4 — Recursos (6 controles): CUBIERTO

A.5 — Impact assessment (5 controles): PARCIAL

A.6 — Ciclo de vida del sistema IA (4 controles): CUBIERTO

A.7 — Datos para sistemas IA (5 controles): CUBIERTO

A.8 — Información para partes interesadas (4 controles): CUBIERTO

A.9 — Uso de sistemas IA (3 controles): CUBIERTO

A.10 — Terceros y relaciones con clientes (4 controles): CUBIERTO

Los roles definidos por la norma

Niveles de impacto y proporcionalidad

Los siete documentos mínimos del AIMS

Caso aplicado: el chatbot multi-tenant del blog → checklist 42001

Mapeo cruzado con EU AI Act, NIS2 y ENS

EU AI Act (Reg. 2024/1689) — siete artículos directamente alineados

NIS2 (Dir. 2022/2555) — tres pilares con solapamiento

ENS (RD 311/2022)

Las cinco trampas habituales de la certificación

Lo que no hemos cubierto (próximos posts)

Referencias

Ver también

EU AI Act: el expediente técnico artículo por artículo sobre la arquitectura LLM on-premise del blog

TL;DR

La analogía: el expediente de homologación de un vehículo nuevo

Encaje con ISO 42001, NIS2 y ENS

Las cuatro categorías de riesgo y la clasificación del Art. 6

Calendario de aplicación

Mapeo artículo por artículo

Art. 5 — Prácticas prohibidas (vigente desde 2 feb 2025)

Art. 6 — Clasificación de sistemas de alto riesgo

Art. 9 — Sistema de gestión de riesgos

Art. 10 — Datos y gobernanza de datos

Art. 11 + Anexo IV — Documentación técnica

Art. 12 + Art. 19 — Record-keeping (logs)

Art. 13 — Transparencia a los deployers

Art. 14 — Supervisión humana

RB-01 · `GpuHbmNearOom` — HBM > 92 % sostenido

RB-02 · `GpuThermalOrPowerThrottle` — bit ≠ 0 ni Idle en CLOCK_THROTTLE_REASONS

RB-03 · `GpuXidErrorDetected` — `increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0`

RB-04 · `GpuEccDoubleBit` — `DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0`

RB-05 · `VllmKvCachePoolNearFull` — `gpu_cache_usage_perc > 95 %` sostenido 3 min

RB-06 · `VllmTtftP95OutOfSlo` — TTFT P95 > 1.5 s durante 5 min

Workflow 1 — `xid-detected.yaml`

Workflow 2 — `ecc-dbe.yaml` — paginación inmediata

Workflow 3 — `canary-rollback.yaml` — TTFT P95 fuera de SLO