Validar y publicar LMs custom en sectores regulados

Notas del Ciclo de Release — Parte IV

Una abogada general entra a la revisión de ingeniería. Trae una sola pregunta: “Si mañana aterriza una solicitud del derecho al borrado del Artículo 17 del EU AI Act pidiéndonos remover cada hecho que nuestro modelo aprendió sobre un paciente específico, ¿podemos probar que lo hicimos?”

La respuesta honesta que la mayoría de equipos tiene que dar es: “Podemos hacer fine-tuning del modelo para que olvide. Podemos mostrarte el training run. Pero no podemos probar que la información esté estructuralmente fuera, porque podría reaparecer bajo el prompt adversarial correcto.”

Eso no es una respuesta de cumplimiento. Es una no-respuesta con un encogimiento de hombros procedimental.

Este post trata de cómo se ve una respuesta real de cumplimiento para LLMs custom — a través de cuatro marcos regulatorios (EU AI Act, GDPR Artículo 17, HIPAA, NIST AI RMF), mapeados al pipeline de cuatro etapas (Register → Gate → Roll → Observe) que enviamos para releases de cliente. La tensión titular que atraviesa la petición de cada regulador es open-weights vs closed-API: las cosas que puedes probar sobre un fine-tune de Gemma 4 no son las cosas que puedes probar sobre un release servido detrás de una API opaca de proveedor. El formato de recibo que usamos lo dice explícitamente, línea por línea. Esa honestidad es lo que hace al recibo útil para un auditor.

Los cuatro reguladores y lo que cada uno realmente quiere

Las discusiones de cumplimiento tienden a colapsar en “documentamos cosas”. Ese enfoque falla ante un auditor. Lo que los auditores quieren es evidencia que pueden verificar sin confiar en tu infraestructura. Los cuatro marcos a continuación usan vocabularios distintos para la misma petición subyacente.

Los números de sanción no son lo que hace interesantes a estos marcos. Los números de sanción son lo que los vuelve estructurales. La parte interesante es la primitiva de verificación — cómo cada marco realmente quiere que se vea el artefacto. Tres de los cuatro piden prueba de grado criptográfico en vocabularios distintos. El cuarto (NIST AI RMF) es voluntario pero de facto requerido en la procura empresarial. Convergen en la misma forma: un artefacto que un auditor puede verificar sin confiar en tus logs.

El corte: open-weights vs closed-API

Antes del mapeo por etapas, la advertencia más importante de todo este post:

Para respaldos de modelo open-weights — Gemma, Qwen, Llama, Mistral, GPT-OSS, cualquier cosa donde los pesos sean direccionables y editables — cada decisión de release de Divinci emite un recibo de vindex que incluye un weight-attestation: prueba criptográfica de que los pesos activos en el momento de la decisión son exactamente los pesos que el manifest registró. Esto es lo que hace posible el borrado verificable del Artículo 17 del GDPR. Aplicas un parche DELETE que remueve una relación-entidad específica del espacio de pesos, el recibo embebe el hash antes-y-después, y un auditor puede verificar que el borrado ocurrió volviendo a correr la verificación contra el vindex público.

Para respaldos de modelo closed-API — OpenAI, Anthropic, Google vía APIs opacas — el mismo recibo cubre la cadena de decisión (qué manifest, qué resultado de gate, qué lectura de monitor, qué usuario disparó qué acción) pero no puede reclamar procedencia de pesos, porque el proveedor no expone pesos. El recibo lo nota explícitamente en un campo weight_attestation: null con una note explicando por qué. Eso no es una postura de cumplimiento degradada — es el límite de lo que es verificable, escrito honestamente. Un auditor que lea el recibo entiende exactamente qué clase de prueba se está y no se está haciendo.

Este corte atraviesa la petición de cada regulador a continuación. Cada vez que un marco exige algo a nivel de pesos, el camino open-weights puede satisfacerlo y el camino closed-API no. Lo decimos en el recibo en lugar de implicar una prueba que no podemos entregar.

Cómo cada marco mapea a las cuatro etapas del pipeline

El pipeline tiene cuatro etapas. La petición de cada regulador mapea a una o más de ellas. La matriz de abajo es el mapa real.

Las dos celdas ◐ son las entradas de GDPR Artículo 17 / solo open-weights — estas son las peticiones que el camino closed-API no puede satisfacer completamente. Todo lo demás aplica a ambos respaldos.

El resto del post recorre la contribución de cada etapa.

Etapa ① — Register

La etapa Register produce un manifest JSON inmutable, direccionado por SHA-256. Para releases regulados el manifest lleva todo lo que el Anexo IV^[1] pide en un solo artefacto:

• El artefacto del modelo (repo HF + commit SHA, o una referencia de parche vindex)
• La plantilla de prompt (cada variable, cada system message — versionada)
• Las reglas de routing (qué clase de tráfico aterriza en qué release)
• La versión del dataset usada para computar los umbrales del gate (resumen de datos de training por hash)
• El SHA del release previo (para que la cadena de auditoría sea ininterrumpida)
• El alcance de divulgación — para despliegues HIPAA, qué categorías de PHI el modelo tiene permitido recibir

El manifest es la documentación. Un auditor no lee prosa; lee el hash del manifest y verifica el bundle. No se requiere resumen en prosa escrito-seis-meses-después.

Bonus open-weights. Cuando el artefacto del modelo referencia un modelo open-weights, el manifest también embebe el vindex_sha256 — la huella criptográfica del vindex publicado del modelo. Esa huella es lo que le permite a un tercero verificar los pesos activos sin nunca tener que confiar en nuestra infraestructura de despliegue.

Advertencia closed-API. Cuando el artefacto del modelo referencia un modelo closed-API, el campo vindex_sha256 del manifest es null, y el weight_attestation_class del manifest es decision_chain_only. El auditor que lee esto sabe exactamente qué se afirma y qué no.

Etapa ② — Gate

La etapa Gate es donde las “medidas de supervisión humana”^[1] del EU AI Act se operacionalizan. Un regulador que lea el EU AI Act y concluya “necesitamos un workflow de aprobación humana” ha errado el punto — la petición más difícil es contra qué está aprobando el humano. La etapa Gate responde esa pregunta con un Spearman ρ por slice contra un grader anclado en humano^[3]. Cada slice que importa en tu postura regulatoria (oncología pediátrica, licenciamiento de IP, francés belga) recibe su propio umbral. El camino de override requiere un razonamiento escrito que va al rastro de auditoría.

Para despliegues cubiertos por HIPAA, esto también es donde vive la regla de divulgación “mínima-necesaria”. La suite de QA puntuada del gate incluye tests negativos para sobreexposición de PHI — respuestas que incluyen identificadores personales cuando ninguno fue pedido. Un release que regresa en el slice de sobreexposición falla el gate, sin importar cómo se desempeñen sus otros slices.

Para NIST AI RMF, la etapa Gate cubre la función “measure” — la evidencia numérica por slice de que el sistema está desempeñándose dentro de las tolerancias configuradas.

Etapa ③ — Roll

El monitoreo post-mercado^[1] del EU AI Act requiere que el operador demuestre observación continua — no solo previa al lanzamiento — de cómo el sistema de IA se desempeña en condiciones reales. Un canary 5% → 25% → 100% con checkpoints de monitor de calidad es la forma más natural de satisfacer esto. El dwell en cada checkpoint, más las lecturas del monitor durante el dwell, es lo que un auditor quiere ver.

Para HIPAA, la etapa canary también es donde el logging de auditoría por petición se ejercita end-to-end. Cada checkpoint produce una muestra de recibos firmados de petición-respuesta; si alguno de ellos tiene un manejo de PHI mal configurado, sale a flote a 5% de tráfico en lugar de a 100%.

Etapa ④ — Observe

Esta es la etapa que se gana la historia de cumplimiento. La etapa Observe corre replay continuo de trazas a través del release activo, puntuado por el mismo juez anclado en humano de Gate, con un monitor de calidad que dispara rollback automático si rompe el umbral.

Cada decisión de release — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, y cualquier aplicación de parche DELETE del Artículo 17 del GDPR — emite un recibo de vindex. Encadenado por hash al recibo previo para este cliente y al recibo previo para este release.

Aquí está cómo se ve un recibo real para un parche DELETE del Artículo 17 del GDPR — adaptado directamente del formato documentado en la página de compliance:

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

Ese artefacto es verificable. Un auditor no tiene que confiar en nuestros logs. Toman el vindex_sha256_after, jalan el vindex publicado correspondiente de huggingface.co/Divinci-AI, y verifican que la feature 11179 en la layer 27 está estructuralmente ausente del top-25. Toman el chain_signature y lo verifican contra el recibo anterior. Toda la cadena está anclada externamente en una agenda que el cliente configura.

La misma operación contra un modelo closed-API. Los campos del recibo de arriba cambian de tres formas: operation.target se vuelve provider_api_endpoint, verification se vuelve un esquema distinto cubriendo solo evidencia de cadena de decisión, y weight_attestation_class se vuelve decision_chain_only. El proveedor del modelo closed-API no ha expuesto pesos, así que el recibo lo dice. Un auditor que quiera prueba a nivel de pesos ahora sabe que tiene que escalar al proveedor, no a nosotros.

Esta es la diferenciación que nadie más envía en 2026. El campo de eval-CI (Braintrust, Humanloop, Patronus) no se sienta sobre tráfico y no emite recibos de decisión. El campo de canary de serving (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) emite logs de métricas de infraestructura pero no recibos de cumplimiento encadenados por hash. El campo de observabilidad (Arize, Phoenix, Confident, Deepchecks) observa el output pero no hace cumplir.

¿Qué verifica realmente un auditor?

Un ejercicio útil: caminar por las preguntas que un auditor real hará, y qué artefacto responde a cada una.

Lo que el auditor no tiene que hacer: confiar en nuestro Datadog. Confiar en nuestro CloudWatch. Confiar en un screenshot. Confiar en un export. El punto entero del formato de recibo es que el auditor pueda verificarlo independientemente.

Lo que esto no resuelve

Tres limitaciones honestas:

Las regresiones closed-API en territorio del Artículo 17 del GDPR no son resolubles a nivel de plataforma. Si estás sirviendo un asistente sanitario detrás de un modelo closed-API y un paciente invoca el Artículo 17, la plataforma puede atestiguar que el registro del paciente fue removido de tu store de retrieval, tu plantilla de prompt y tus reglas de routing — pero no puede atestiguar que los pesos del modelo subyacente olvidaron los datos del paciente. Necesitas o bien un respaldo open-weights o un compromiso del proveedor para borrado a nivel de pesos. Lo decimos en el recibo.

La documentación es necesaria pero no suficiente. Un recibo que prueba que un modelo cumplió un umbral no prueba que el umbral fuera el umbral correcto. Si tu suite de QA puntuada no cubre el slice que realmente le importa a un paciente en tu servicio, ninguna cantidad de encadenamiento de recibos arregla eso. Los reguladores entienden esto cada vez más; “pasamos nuestro eval” ya no es una respuesta de cumplimiento suficiente si el eval era el eval equivocado.

El formato vindex es de un solo proveedor. Lo usamos porque es la primitiva criptográfica más concreta disponible hoy para prueba a nivel de pesos. Si la industria se asienta en un formato distinto — model-cards-con-hashes, esquemas de artefacto publicados por NIST — el formato de recibo debería evolucionar a eso. La sustancia (encadenado por hash, verificable externamente, consciente del weight-attestation) es lo estructural, no el nombre específico del esquema. Esperamos que eso cambie conforme el paisaje regulatorio y de estándares madure.

FAQ

¿Qué es el borrado verificable bajo el Artículo 17 del GDPR para sistemas de IA?

Borrado verificable significa que un tercero puede verificar que los datos fueron removidos sin tener que confiar en tus logs. Hacer fine-tuning de un modelo para que “olvide” información específica no cumple este estándar — la información puede reaparecer bajo prompting adversarial, y no hay primitiva criptográfica que un auditor pueda verificar. Un parche DELETE a nivel de pesos con un hash de vindex antes/después publicado sí cumple el estándar, porque el auditor puede volver a correr la verificación contra el artefacto público.

¿Por qué los modelos closed-API no pueden satisfacer el Artículo 17 del GDPR de la misma forma?

Porque el proveedor no expone pesos. Sin acceso a los pesos, ningún tercero — incluyendo al cliente que usa la API — puede emitir o verificar un borrado a nivel de pesos. La parte de cadena de decisión del recibo (qué plantilla de prompt se usó, de qué store de retrieval vinieron los datos, qué reglas de routing estaban activas) sigue siendo verificable, pero la afirmación a nivel de pesos no. Esto es un límite de lo que es verificable cuando los pesos son privados, no un límite del marco de cumplimiento.

¿Qué requiere el Anexo IV del EU AI Act, en castellano llano?

El Anexo IV pide documentación técnica que cubra la lógica del sistema, el resumen de datos de training, el uso previsto, las medidas de supervisión humana y el monitoreo post-mercado. La trampa en la que cae la mayoría de equipos es tratar estos como cinco documentos separados. El manifest de release en la Etapa 1 carga las primeras tres peticiones como un solo hash; la etapa Gate cubre la cuarta; las etapas Roll + Observe cubren la quinta. Un solo pipeline; cuatro peticiones satisfechas como subproducto de operaciones normales.

¿Qué tan rápido debería ser el rollback para despliegues cubiertos por HIPAA?

HIPAA no especifica un tiempo de rollback, pero la guía del HHS sobre respuesta a brechas trata el tiempo-hasta-contención como estructural. Un rollback en el orden de segundos (drenado en vuelo sobre un flip impulsado por manifest — nuestro número anda alrededor de 12 segundos) es estructuralmente más rápido que un blue-green típico de métricas de infraestructura que depende de propagación de alarmas. Compara con postmortems públicos: el incidente de Cloudflare de junio de 2022^[4] tardó 44 minutos en revertirse porque los ingenieros se pisaron las reversiones unos a otros.

¿Cómo mapea NIST AI RMF a un pipeline de release?

Las cuatro funciones núcleo de NIST AI RMF — Govern, Map, Measure, Manage — abarcan todo el ciclo de vida del release, no una sola etapa. Govern es la política de release documentada más el workflow de razonamiento de override del gate (etapas Register + Gate). Map es la suite de QA puntuada por slice (Gate). Measure son los umbrales de Spearman por slice y el monitor continuo de calidad (Gate + Observe). Manage es el camino de rollback y la cadena de recibos (Observe). Las cuatro están cubiertas cuando el pipeline emite su conjunto completo de recibos.

Referencias

1. EU AI Act. artificialintelligenceact.eu. El Anexo IV define los requisitos de documentación técnica para sistemas de IA de alto riesgo: lógica del sistema, resumen de datos de training, medidas de supervisión humana, monitoreo post-mercado. Sanciones de hasta 7% de la facturación global por incumplimiento.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. TerminationWaitInSeconds por defecto 600, MaximumExecutionTimeoutInSeconds máximo 1800. Citado como el canary de métricas de infraestructura estándar de la industria contra el que se contrasta el monitor de calidad de la Etapa 4.
3. Acuerdo calibrado de LLM-como-juez. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% de acuerdo global GPT-4-vs-humano, con varianza por categoría desde coding (86%) hasta writing (36–44%). Ancla para la calibración de Spearman por slice que impulsa la etapa Gate.
4. Caída de Cloudflare de junio de 2022. Cloudflare outage on June 21, 2022. 44 minutos desde "sabemos qué revertir" hasta revertido completo porque los ingenieros se pisaron las reversiones unos a otros. Ancla para la afirmación "un rollback impulsado por manifest no puede tener ese modo de fallo".
5. NIST AI Risk Management Framework. NIST AI RMF. Marco voluntario — Govern, Map, Measure, Manage — que se ha vuelto la línea base de facto en procura empresarial para gobernanza de IA. Voluntario pero enforced en la práctica vía cuestionarios de due-diligence del cliente.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Requisitos de divulgación mínima-necesaria, auditoría de acceso y tiempos de respuesta a brechas aplicables a cualquier sistema de IA que toque PHI. Sanciones monetarias civiles de hasta $1.9M por tipo-de-violación por año según CMP inflation adjustment, 2025.
7. GDPR Artículo 17 (Derecho al borrado). gdpr-info.eu/art-17-gdpr. El derecho del titular de datos a obtener el borrado de datos personales, y la obligación del controlador de demostrar cumplimiento bajo la responsabilidad del Artículo 5(2). Sanciones de hasta €20M o 4% de la facturación global anual.
8. Interno — formato de recibo vindex. El JSON del recibo en este post se adapta del formato documentado en la página de compliance y demostrado en el post "Deleting Paris from a Language Model". La cadena de hash es SHA-256 sobre manifest || prev_manifest || user_id || created_at || prev_chain_signature. Anclable externamente en una agenda configurada por el cliente.

Siguiente en esta serie: Pipelines automatizados de CI/CD de LLM con rollback instantáneo. Este post mostró qué quiere un auditor. El siguiente muestra el patrón operativo que hace llegar el recibo al escritorio del auditor en segundos en lugar de semanas — la automatización bajo el pipeline de cuatro etapas, con foco en qué cambia cuando el rollback dispara por sí solo.