El Reglamento de IA no se implementa adjuntando un informe legal al ticket de release. Los requisitos se convierten en inventario, clasificación, linaje, evidencia versionada, logs automáticos, autoridad humana, quality gates, conformidad, vigilancia poscomercialización y respuesta a incidentes.
Identifique si el producto es un sistema de IA, mercados y personas afectadas, finalidad prevista, misuse razonablemente previsible y rol de cada actor. Proveedor, responsable del despliegue, importador, distribuidor, representante, fabricante y proveedor GPAI tienen obligaciones distintas. Una organización puede desplegar un sistema y convertirse en proveedora tras una modificación sustancial o rebranding.
Al 22 de junio de 2026: el Reglamento entró en vigor el 1 de agosto de 2024; prohibiciones, definiciones y alfabetización en IA aplican desde el 2 de febrero de 2025; gobernanza y GPAI desde el 2 de agosto de 2025; y muchas disposiciones están previstas desde el 2 de agosto de 2026. El acuerdo político del AI Omnibus, anunciado el 7 de mayo de 2026, señala el 2 de diciembre de 2027 para sistemas del Anexo III y el 2 de agosto de 2028 para sistemas integrados en productos. Separe el texto vigente de las modificaciones acordadas aún sujetas a adopción formal.
El registro no puede estar desconectado de producción. Endpoint, modelo, prompt, política, dataset, workflow humano y deployment deben resolver al mismo sistema. El control plane verifica evidencia, bloquea releases incompatibles, publica configuración aprobada y recibe outcomes de runtime.
| Requisito | Capacidad | Evidencia de release | Señal runtime | Bloqueo |
|---|---|---|---|---|
| Riesgo, Art. 9 | Registro de hazards ligado a finalidad, misuse, grupos, controles, tests y riesgo residual. | Versión aprobada y métricas predefinidas. | Nuevo hazard, queja, contexto o falla. | Riesgo no aceptado o assessment vencido. |
| Datos, Art. 10 | Registro con origen, propósito, preparación, labels, geografía, población, calidad, sesgo, gaps, acceso y retención. | Manifests inmutables y checks firmados. | Drift, grupos faltantes, cambios o feedback loop. | Linaje desconocido o quality gate fallido. |
| Documentación, Art. 11 | Docs-as-code desde registro, arquitectura, versiones, performance, límites y cambios. | Bundle alineado al Anexo IV. | Runtime distinto de lo documentado. | Docs ausentes, stale o inconsistentes. |
| Logs, Art. 12 | Eventos automáticos con versiones, input reference, output, acción humana, tiempo y trace IDs. | Schema, retención, integridad, acceso y replay. | Pérdida, schema roto, clock drift o decisión sin rastro. | No puede reconstruirse un evento. |
| Información, Art. 13 | Instrucciones versionadas con finalidad, límites, métricas, inputs, supervisión y mantenimiento. | Paquete aprobado ligado al artefacto. | Uso fuera de instrucciones. | El deployer no opera con seguridad. |
| Supervisión, Art. 14 | Cola, autoridad, competencia, contexto, override/stop, prevención de automation bias y escalamiento. | Pruebas de escenarios e intervención. | Overrides, alertas ignoradas, demora y error. | Nadie entiende, interviene o detiene. |
| Accuracy/robustez/cyber, Art. 15 | Evals, métricas declaradas, tests de falla/ataque, fail-safe, redundancia y feedback-loop control. | Reporte por contexto y grupo. | Drift, ataque, outage, fallback o amplificación. | Nivel declarado o fallback falla. |
Release → modelo/prompt → commit/container → data manifests → evals → controles → documentación → instrucciones → supervisión → seguridad → conformidad/registro → deployment. La evidencia guarda autor, reviewer, timestamp, herramienta, fuente, firma, vigencia y supersession. El PDF es export, no fuente de verdad.
El proveedor responde por diseño, quality management, documentación, conformidad, corrección y posmercado. El deployer sigue instrucciones, asigna supervisión competente, monitorea, conserva logs bajo su control y gestiona inputs; organismos públicos y ciertos servicios esenciales pueden requerir evaluación de impacto en derechos fundamentales.
Defina qué ve la persona, competencia, momento, obligatoriedad, plazo, auto-stop y reversibilidad. Mida edad de cola, éxito de intervención, overrides, automation bias, desacuerdo, escalamiento y outcomes.
Registre lo necesario para reconstrucción y monitoring con minimización, retención, acceso, integridad y seguridad. Prefiera referencias, hashes y contexto estructurado frente a prompts o datos personales indiscriminados. Separe analytics, seguridad, evidencia regulatoria y expedientes sensibles.
Finalidad, segmento, país, autoridad, autonomía, datos, threshold, UI, permisos, integración o vendor pueden modificar riesgo y rol. PR y pipeline calculan impacto, invalidan evidencia, solicitan revisiones y repiten evals.
Assessment, declaración UE, marcado CE cuando corresponda, registro, conservación y cadena de valor se vuelven estados: desarrollo, sandbox, pendiente, aprobado por mercado/finalidad, registrado, suspendido, retirado o retired. Un artefacto no migra silenciosamente a otra finalidad.
Defina antes del launch performance, drift, grupos, overrides, misuse, quejas, recursos, precursores, contexto, avisos del proveedor e interacciones. Cada señal tiene threshold, owner, playbook, acción y actualización de evidencia.
Preserve versión, timeline, outputs, logs, acciones humanas, datos, impacto, contención y comunicación. El flujo evalúa notificación bajo el Artículo 73, coordina actores y autoridades, impide borrar evidencia y verifica la acción correctiva.
Guarde proveedor, modelo/versión, release, integración, documentación, acceptable use/copyright, evals, riesgo sistémico, hosting y avisos. Un alias que apunta a otro modelo es cambio de supply chain.
El Artículo 50 puede exigir aviso de interacción con IA y marcado/divulgación de contenido. Incorpore notices, provenance metadata, detección, disclosure, idioma, accesibilidad y prueba de entrega. Una política en el footer no equivale a aviso oportuno.
Registro y actor graph; servicio de baseline legal; motor de clasificación; data/model BOM; evidence graph; eval service; generador de docs; gateway policy-as-code; allow-list; logging schema; consola de supervisión; transparencia/provenance; bus posmercado; workflow de incidentes; state machine de conformidad; monitor de vendors; y exports auditables.
El Reglamento se vuelve manejable cuando el estado de cumplimiento deriva del software, modelo, datos, finalidad, mercado y evidencia en producción. La arquitectura no reemplaza criterio jurídico, pero conecta cada decisión con controles ejecutables y hechos reconstruibles.
Nota jurídica: interpretación de ingeniería, no asesoría legal. Verifique texto aplicable, directrices, normas armonizadas y requisitos nacionales.
Artículo sobre el Reglamento de IA de la UE como arquitectura: registro, clasificación, datos, documentación, logs, supervisión, gates, conformidad, monitoring, incidentes, GPAI y transparencia.