Tiempo de lectura: 13 minutos
TL;DR
El 2 de agosto de 2026, la parte de la Ley de IA de la UE que todo el mundo ignoraba en voz baja se volvió aplicable: la Oficina de IA ya puede multar a los proveedores de modelos de IA de uso general (GPAI) con hasta el 3% de la facturación anual global o 15 millones de euros, la cifra que sea mayor, y puede exigir tu documentación técnica, realizar sus propias evaluaciones de tu modelo, ordenarte que «adoptes medidas» y, en el peor de los casos, obligarte a restringir, retirar o recuperar el modelo del mercado de la UE. Las obligaciones en sí existen técnicamente desde el 2 de agosto de 2025 —documentación técnica, transparencia hacia clientes intermedios, una política de derechos de autor que respete robots.txt y las exclusiones voluntarias, un resumen público de los datos de entrenamiento— pero hasta ahora eran reglas sin árbitro. Eso cambió. Los modelos considerados de riesgo sistémico (entrenados por encima de 10^25 FLOP) arrastran deberes más pesados que parecen una lista de seguridad escrita por un regulador: evaluaciones del modelo, pruebas adversarias / red teaming, un marco de seguridad, notificación de incidentes graves a la Oficina de IA y protección de ciberseguridad de los propios pesos del modelo. El Código de Buenas Prácticas voluntario te compra un trato más suave, no inmunidad. Los modelos ya en el mercado antes del 2 de agosto de 2025 tienen hasta el 2 de agosto de 2027 para cumplir. Esta es la mitad regulatoria de una historia en dos partes —la mitad de responsabilidad civil, la nueva Directiva de Responsabilidad por Productos, es el artículo que publico justo después de este—. Leídas juntas, la UE ha construido una pinza: un regulador que te multa y un tribunal que te pasa la factura. Aquí va mi lectura como profesional de seguridad de la mandíbula regulatoria.
Las fechas que importan:
| Fecha | Qué ocurre |
|---|---|
| 1 ago 2024 | La Ley de IA entra en vigor |
| 2 ago 2025 | Comienzan las obligaciones para modelos GPAI (modelos colocados en el mercado tras esa fecha) |
| 2 ago 2026 | Se enciende la aplicación — la Oficina de IA / Comisión puede investigar, evaluar, ordenar medidas y multar |
| 2 ago 2027 | Fecha límite de cumplimiento para modelos GPAI ya en el mercado antes del 2 ago 2025 |
El descargo de responsabilidad de siempre: no soy abogado y esto no es asesoramiento legal —es un profesional de seguridad leyendo una regulación como leo una superficie de ataque, buscando dónde recae la presión de verdad y quién acaba sujetándola—. Si construyes o distribuyes modelos de IA en la UE, habla con un abogado de verdad. Lo que sí puedo contarte es qué cambia operativamente para quienes construyen, aseguran y despliegan estos modelos —porque bajo el lenguaje de cumplimiento hay una lista de cosas que llevo dos años exigiendo en este blog, ahora respaldadas por una multa.
Una nota sobre el enfoque antes de empezar. Este artículo es uno de un par. La UE está poniendo dientes a la IA en dos vías distintas a la vez, y muerden de forma diferente. Esta —las reglas de la Ley de IA para la IA de uso general (formalmente un Reglamento, el (UE) 2024/1689, aunque todos la llamemos «Ley de IA»)— es regulatoria: una autoridad pública, la Oficina de IA, con poder para investigarte y multarte. El artículo complementario, sobre la nueva Directiva de Responsabilidad por Productos, es civil: demandantes privados y tribunales, responsabilidad objetiva, indemnizaciones a la persona a la que tu software defectuoso causó un daño. Los publico uno detrás de otro a propósito, porque si solo sigues uno calcularás mal tu exposición. Que un regulador te multe y que un demandante te demande son dos puertas distintas, y tras este verano las dos están abiertas.
Llevo tiempo rondando la puerta regulatoria — por qué «usamos ChatGPT» no es una estrategia de IA, qué pasa cuando el propio modelo se convierte en el atacante, si todavía puedes distinguir un modelo abierto de uno frontera. El 2 de agosto es la UE respondiendo a una parte de esas preguntas con un presupuesto de aplicación adjunto.
Qué cambió realmente el 2 de agosto
Esta es la parte que confunde a la gente, así que déjame ser preciso: el 2 de agosto de 2026 no creó obligaciones nuevas. Las reglas sustantivas para los modelos GPAI entraron en vigor un año antes, el 2 de agosto de 2025. Lo que faltaba hasta ahora era la maquinaria de aplicación. Durante doce meses, el capítulo GPAI de la Ley de IA ha sido una ley que técnicamente podías incumplir sin que nadie pudiera hacer gran cosa al respecto.
Ese periodo de gracia terminó. Desde el 2 de agosto de 2026, la Oficina de IA, el órgano dedicado de aplicación de la Comisión, tiene cuatro poderes concretos que el 1 de agosto no tenía:
- Exigir tu documentación. Puede requerir a un proveedor GPAI que entregue la documentación técnica e información sobre el modelo.
- Evaluar tu modelo. Puede realizar sus propias evaluaciones del modelo para comprobar el cumplimiento e investigar el riesgo sistémico, incluida la solicitud de acceso.
- Ordenar medidas de cumplimiento. Puede exigirte que «adoptes las medidas apropiadas» para ajustar el modelo.
- Retirar el modelo. En el peor de los casos, puede obligarte a restringir su disponibilidad, retirarlo o recuperarlo del mercado de la UE.
Un punto de precisión que conviene tener claro, porque los abogados que lean esto lo harán: la Oficina de IA es el órgano operativo que investiga, evalúa y construye el caso, pero la decisión formal de multar bajo el artículo 101 es de la Comisión Europea. En la práctica tratas con la Oficina de IA; la firma de la sanción es de la Comisión.
Y detrás de los cuatro está la cifra que concentra la atención: multas de hasta el 3% de la facturación anual global o 15 millones de euros, la que sea mayor, según el artículo 101. Ojo: ese es el techo específico de GPAI; las multas de titular del 7% de la facturación son para el despliegue de prácticas de IA prohibidas, otro régimen distinto. Pero para un laboratorio frontera, el 3% de la facturación global es una cifra de las que se ven en un consejo de administración.
Figura 1. Cómo aterriza la aplicación de verdad: una brecha de incumplimiento que sobrevive a la escalada de la Oficina de IA —solicitud de documentación → evaluación del modelo → orden de cumplimiento— acaba en una multa de hasta el 3% de la facturación global o 15 M€ y, en el extremo, en restricción o retirada del mercado de la UE.
Así que nada sobre las obligaciones de tu modelo cambió esta semana. Lo que cambió es que ignorarlas ahora tiene un precio, un árbitro y un botón de parada.
Y aquí está la señal de que esta fecha va en serio. El Digital Omnibus de la UE —un paquete de simplificación que la industria presionó con fuerza para conseguir, presentado en noviembre de 2025 y acordado esta primavera— retrasó los plazos de alto riesgo de la Ley de IA, deslizando las obligaciones del Anexo III hasta diciembre de 2027 y los sistemas integrados hasta 2028. A la GPAI la dejó en paz. De todos los plazos que Bruselas tuvo presión para mover, el único que no movió es el de este artículo. Cuando un regulador parpadea en casi todo excepto en aquello sobre lo que escribes, eso es la prioridad.
A quién afecta esto de verdad
La Ley de IA es quisquillosa con los roles, y la letra pequeña importa. Las obligaciones GPAI recaen sobre el proveedor del modelo —el laboratorio que entrena y coloca el modelo de uso general en el mercado—. Piensa en los nombres frontera obvios, pero también en el creciente campo de laboratorios de modelos abiertos y, algo importante, en cualquiera que haga fine-tuning o modifique sustancialmente un modelo hasta convertirse, en la práctica, en su nuevo proveedor. La propia guía de la Comisión pone una línea aproximada: si modificas un modelo usando más de alrededor de un tercio del cómputo de entrenamiento original, se presume que te has convertido en proveedor, con las obligaciones que ello conlleva. Esa cláusula es la que arrastra al ámbito de aplicación a muchas empresas que se consideran meros «usuarios» sin darse cuenta.
Si eres un responsable del despliegue (deployer) —construyes un producto sobre el modelo de otro— la mayoría de estos deberes GPAI todavía no son directamente tuyos (tu turno llega más tarde, cuando muerdan las reglas de sistemas de alto riesgo —un calendario que el Digital Omnibus acaba de retrasar y condicionar a las normas técnicas—). Pero heredas las consecuencias: la información de transparencia que tu proveedor upstream ahora debe darte es exactamente el material del que dependen tu propio cumplimiento y tu propia revisión de seguridad. Que es el primer punto donde un profesional de seguridad debería aguzar el oído: la Ley está obligando a tu proveedor de modelos a contarte cosas que antes trataba como secreto comercial. Aprovéchalo.
La base: qué debe ahora todo proveedor GPAI
Para cada modelo de uso general en el mercado de la UE, sea del tamaño que sea, cuatro deberes:
Documentación técnica. Un expediente detallado y mantenido del modelo —arquitectura, proceso de entrenamiento, usos previstos y excluidos, consumo energético—, conservado durante diez años y entregado a la Oficina de IA a requerimiento. Este es el archivo que se lee en voz alta en una investigación.
Transparencia hacia clientes intermedios. Debes publicar datos de contacto y responder a las solicitudes de los proveedores intermedios con la información que necesitan para integrar el modelo de forma responsable —la guía de transparencia del Código de Buenas Prácticas apunta a una ventana de respuesta corta, de pocos días (lecturas de despachos citan en torno a 14 días)— protegiendo aún la PI y los secretos comerciales legítimos. La era del «todo es propietario, apáñate tú» en la integración de modelos se acaba.
Una política de derechos de autor con mecánica real. No un párrafo de intenciones: una política funcional que respete las medidas tecnológicas de protección, excluya fuentes conocidas de piratería, honre robots.txt y las señales de exclusión voluntaria legibles por máquina, y dé a los titulares de derechos un contacto y una vía de reclamación. Esta es la disposición de la que colgarán los pleitos por datos de entrenamiento.
Un resumen público de los datos de entrenamiento. Una plantilla de la Oficina de IA rellenada que resuma con qué se entrenó el modelo. No el conjunto de datos, pero sí resumen suficiente para que la caja negra lleve una etiqueta.
Nada de esto es exótico para quien haya dirigido un equipo de ingeniería maduro. Lo nuevo es que es obligatorio, exigible y descubrible.
Riesgo sistémico: cuando la regulación empieza a hablar mi idioma
Aquí está la sección que me hizo querer escribir este artículo. Un subconjunto de modelos —los de «capacidades de alto impacto», presumidas cuando el cómputo de entrenamiento supera los 10^25 FLOP, y cualesquiera otros que la Comisión designe— se clasifican como de riesgo sistémico. Y las obligaciones que se les adhieren podrían haber salido directamente de una de mis propias listas de trabajo:
- Un marco de seguridad (los detalles de plazos aquí provienen del capítulo de seguridad del Código de Buenas Prácticas), montado en semanas tras la notificación y finalizado antes de que el modelo se despliegue.
- Evaluaciones del modelo y pruebas adversarias —la Ley dice red teaming con todas las letras—. La evaluación de vanguardia de las capacidades peligrosas del modelo es ahora un deber legal, no un «estaría bien» por el que tu equipo de seguridad pelea el presupuesto.
- Evaluación y mitigación del riesgo sistémico a lo largo del ciclo de vida: filtrado, monitorización, controles de entrada/salida.
- Notificación de incidentes graves a la Oficina de IA y a las autoridades nacionales en plazos escalonados —una obligación real de respuesta a incidentes para modelos—.
- Protección de ciberseguridad del modelo y de su infraestructura física —es decir, protege los pesos—. La exfiltración de pesos es ahora un fallo de cumplimiento, no solo un titular embarazoso.
- Retención de documentación durante diez años, y un informe de seguridad que incluya los hallazgos de evaluadores externos.
Una nota justa sobre las fuentes: la propia Ley fija estos deberes a nivel de principio (artículo 55); varios de los detalles concretos anteriores —los plazos del marco, la forma exacta del informe de seguridad— provienen del capítulo de seguridad del Código de Buenas Prácticas, que es la carretera asfaltada para demostrar que alcanzaste el listón legal. El deber es ley; parte del detalle es el Código.
Lee esa lista y luego relee lo que escribí tras el incidente de evaluación de modelos de Hugging Face / OpenAI: la mayoría de los defensores tienen cero telemetría en la capa de modelo y de agente, y las herramientas para ejecutar una intrusión completa a velocidad de máquina son ahora algo que puedes disparar por accidente durante tus propias pruebas de seguridad. La Ley de IA acaba de convertir la telemetría, la evaluación y la notificación de incidentes de esa misma capa en una obligación regulada para los modelos de riesgo sistémico. No me encanta cada línea de esta Ley, pero no voy a fingir que exigir pruebas adversarias y seguridad de pesos para los modelos más capaces del planeta sea la parte de la que quejarse. Es la parte que llevo pidiendo.
Hay también un punto sutil de economía de la seguridad. Las pruebas adversarias solo son tan buenas como el adversario. Una regulación que exige red teaming sin definir el rigor invita a la versión de casilla marcada —un equipo interno amable, un fin de semana, un informe en verde—. Los laboratorios que traten esto como trabajo ofensivo real (externo, adaptativo, incentivado para romper el modelo de verdad) producirán evidencia de seguridad con valor real; los que lo traten como un artefacto de cumplimiento producirán un documento que se ve genial hasta que alguien lo lea en una investigación. La misma lección de todo régimen de cumplimiento en el que he trabajado: el artefacto vale lo que la honestidad que hay detrás.
El matiz de los modelos abiertos
Aquí es donde mi tesis sobre los modelos abiertos choca con la Ley, y es el nudo más interesante de todo el asunto. La Ley de IA da a los modelos GPAI abiertos un respiro parcial: los modelos publicados bajo una licencia realmente libre y abierta, con sus parámetros y arquitectura públicos, quedan exentos de algunas de las obligaciones base —la documentación técnica y los deberes de transparencia hacia clientes intermedios—, aunque no de la política de derechos de autor ni del resumen público de datos de entrenamiento, que todo proveedor debe cumplir igualmente. La lógica refleja la exención de código abierto que describí en el artículo de responsabilidad: no quieres aplastar el procomún bajo el papeleo.
Pero —y es el mismo pero que en todas partes en el derecho tecnológico de la UE— la exención se evapora en cuanto el modelo conlleva riesgo sistémico. Cruza el umbral de cómputo y ser abierto no te salva de ninguno de los deberes pesados: sigues debiendo evaluaciones, pruebas adversarias, notificación de incidentes y seguridad de los pesos. Lo que aterriza en un punto peculiar dado hacia dónde va la frontera. Como escribí el mes pasado, los laboratorios chinos están sacando modelos abiertos de billones de parámetros que se miden de tú a tú con los sistemas frontera de EE. UU., NVIDIA y Meta también publican en abierto, y en VULNEX ya ejecutamos nuestro propio agente ofensivo sobre un modelo abierto. La estructura de la Ley implica que los modelos abiertos más capaces —precisamente los que más ilusionan al argumento de la soberanía— heredan el mayor peso regulatorio. La apertura te compra un trato más suave solo hasta que tu modelo se vuelve lo bastante bueno como para importar.
Para las empresas que ejecutan modelos abiertos en su propio hardware, hay una implicación más callada que señalo: si haces fine-tuning de un modelo abierto lo bastante lejos, puedes convertirte en proveedor a ojos de la Ley y heredar obligaciones que dabas por hechas del laboratorio del que descargaste. «Solo lo ejecutamos en local» no es el campo de fuerza que la gente cree.
El Código de Buenas Prácticas: un trato más suave, no un escudo
La Comisión publicó un Código de Buenas Prácticas para GPAI (finalizado en 2025, con capítulos sobre transparencia, derechos de autor y seguridad) como ruta voluntaria para demostrar el cumplimiento. Firmarlo te gana lo que la Oficina de IA llama mayor confianza —una aplicación centrada en tu adhesión al Código en lugar de auditorías abiertas, y los firmantes de buena fe no van a recibir un golpe en cuanto suene la campana si están implementando de forma visible—.
Dos cosas que no hay que malinterpretar. Primera: el Código no es jurídicamente vinculante ni es un puerto seguro —la adhesión no te inmuniza de multas, solo se pondera a tu favor cuando la Oficina de IA calcule una—. Segunda: si no lo firmas, no escapas de las obligaciones; simplemente tienes que demostrar el cumplimiento de otra forma y explicar tu método al regulador, lo que es más trabajo, no menos. El Código es la carretera asfaltada. Puedes ir campo a través, pero aún tienes que llegar al mismo destino y mostrar tu ruta.
¿Hay un equivalente en EE. UU.? La misma respuesta que la última vez: no
Si leíste el artículo de responsabilidad, esto te sonará, porque la divergencia tiene la misma forma. No hay equivalente federal estadounidense al régimen GPAI de la Ley de IA. El empuje federal de la era 2023 hacia obligaciones de seguridad en IA se revirtió; la postura de 2026 es desreguladora, apoyándose en compromisos voluntarios y autoridades sectoriales existentes en vez de en una ley horizontal con un ejecutor dedicado y multas basadas en facturación. Algunos estados de EE. UU. se mueven por su cuenta, pero no hay nada que otorgue a un regulador el poder de exigir la documentación de un laboratorio frontera, evaluar su modelo y retirarlo del mercado.
Así que aplica la misma lógica del efecto Bruselas que con el RGPD y la PLD: un laboratorio global no va a mantener un modelo para Europa y otro más laxo para el resto. Es más barato construir al listón de la UE una vez. Lo que significa que la Ley de IA está fijando en silencio el suelo global de cómo se documentan y aseguran los modelos más capaces —decidido en Bruselas, exportado por la economía, sin que EE. UU. tenga que votar—. Entre esto, la Directiva de Responsabilidad por Productos y los deberes de secure-by-design del Reglamento de Ciberresiliencia (CRA), la UE ha pasado 2026 convirtiéndose en el órgano de estándares de facto para la seguridad del software y la IA, y EE. UU. ha pasado 2026 rechazando explícitamente el puesto.
Mi lectura: qué deberían hacer de verdad los equipos de seguridad e IA
Quita el vocabulario de cumplimiento y el 2 de agosto es una lista de tareas operativas. La mayoría es lo que un programa serio de seguridad de IA ya debería estar haciendo; la diferencia es que «ya lo haremos» ahora lleva un regulador adjunto.
1. Conoce tu rol antes de que la Oficina de IA lo decida por ti. Proveedor, proveedor intermedio o responsable del despliegue lo cambia todo respecto a lo que debes. Y vigila el disparador del fine-tuning: modifica un modelo lo suficiente y te conviertes en proveedor. Mapea cada modelo de tu stack —incluido el modelo abierto que corre en una caja en el armario del equipo de investigación— a un rol, por escrito, ya. Esto es el Vacío de Estrategia de IA hecho concreto: no puedes gobernar modelos que no has inventariado.
2. Trata el red teaming y la evaluación como evidencia, no como teatro. Si tocas un modelo de riesgo sistémico, las pruebas adversarias son ahora un deber legal —así que haz la versión de verdad—. Externa, adaptativa, con adversario incentivado, documentada. El informe que generas es a la vez tu evidencia de seguridad y, algún día, una prueba judicial. Un artefacto de red team que enumera una capacidad que luego desplegaste igualmente es peor que ninguno.
3. La seguridad de los pesos es cumplimiento ahora —protege las joyas de la corona como tal—. La Ley nombra la protección de ciberseguridad del modelo y su infraestructura. Modela explícitamente la amenaza de exfiltración de pesos: controles de acceso, monitorización del tráfico de salida, riesgo de amenaza interna, la cadena de suministro alrededor de tu infraestructura de entrenamiento y servicio. El incidente del modelo-como-atacante mostró qué pasa en esa capa sin telemetría. Instruméntala.
4. Construye el músculo de notificación de incidentes antes de necesitarlo. La notificación de incidentes graves a la Oficina de IA va en plazos escalonados. Eso significa que necesitas detección, clasificación y un runbook de notificación para incidentes de modelo —no solo tu SOC de TI clásico—. Si no sabes cuándo tu modelo hizo algo notificable, no puedes notificarlo a tiempo.
5. Usa los nuevos deberes de transparencia de tu proveedor upstream. Si eres responsable del despliegue, tu proveedor de modelo ahora te debe información de integración y de riesgo en días. Eso no es solo papeleo —es la materia prima para tu propia revisión de seguridad de un modelo que no entrenaste—. Pídela. Por escrito.
6. Firma el Código de Buenas Prácticas con los ojos abiertos. Para proveedores, es la vía de menor fricción y cuenta a tu favor. Solo no lo confundas con un escudo, y no firmes capítulos que no puedas implementar de verdad —un compromiso incumplido es peor que un honesto «lo hacemos a nuestra manera»—.
7. Si eres un proveedor de EE. UU., no leas la desregulación de casa como protección. Que tu gobierno dé un paso atrás en las reglas de IA reduce tu exposición en la UE exactamente en cero: coloca un modelo en el mercado de la UE y la Oficina de IA todavía puede exigir su documentación, evaluarlo, multarte y retirarlo. La misma lógica del efecto Bruselas que en el artículo de responsabilidad —el listón de la UE es el que acabas construyendo, decida lo que decida Washington—.
En resumen
Durante una década, «vamos a por todas con la IA» ha sido una diapositiva, no un sistema. La Ley de IA es la UE decidiendo que si colocas los modelos más capaces del planeta en un mercado de 450 millones de personas, los vas a documentar, probar adversariamente, asegurar sus pesos, notificar cuando fallen y responder ante alguien con poder para multarte y desenchufarte. Eso no es burocracia. Es el trato que todos los demás campos de ingeniería de alta consecuencia aceptaron hace mucho, llegando —tarde, imperfecto, pero llegando— a la IA.
He dedicado este blog a argumentar que la capa de modelo y de agente está poco asegurada y apenas instrumentada. Es extraño ver aparecer a un regulador y ordenar una parte de exactamente eso. Me quedo con la victoria y guardo mi escepticismo para la aplicación —porque una regla es tan real como la primera multa, y estamos a punto de averiguar cuán en serio va la Oficina de IA—.
Y recuerda que esto es solo la primera mandíbula. El regulador puede multarte; la Directiva de Responsabilidad por Productos permite que la persona a la que dañaste te demande, sin culpa que probar, con las cláusulas de exención del EULA anuladas, en diciembre. Un verano, dos puertas, ambas abiertas ya. Construye para las dos.
Figura 2. La pinza — un producto de IA inseguro o no conforme alcanza la responsabilidad por dos vías convergentes: la mandíbula regulatoria de la Ley de IA (la Oficina de IA, desde el 2 de agosto) y la mandíbula civil de la Directiva de Responsabilidad por Productos (responsabilidad objetiva, desde diciembre).
Mantente paranoico. Haz red teaming de verdad. Protege tus pesos.
- X (Twitter): @SimonRoses
Lecturas adicionales:
- Reglamento (UE) 2024/1689 (la Ley de IA) — texto completo en EUR-Lex
- Comisión Europea — Modelos de IA de uso general: obligaciones y Código de Buenas Prácticas
- Comisión Europea — Directrices sobre el alcance de las obligaciones de los proveedores de IA de uso general (julio de 2025)
- EU Artificial Intelligence Act — Aplicación del Capítulo V (GPAI)
- Latham & Watkins — Obligaciones de modelos GPAI en vigor y Código de Buenas Prácticas final
- MediaLaws — Obligaciones de la UE para proveedores GPAI: cumplimiento, aplicación y plazos 2025–2027
- ComplianceHub — Guía de preparación para la aplicación GPAI de la Ley de IA de agosto de 2026
¿Preguntas o comentarios? Contacta a través de:
- Web: vulnex.com
- Estrategia de Seguridad en IA: vulnex.ai
- Twitter/X: @SimonRoses
- LinkedIn: linkedin.com/in/simonroses
- GitHub: github.com/vulnex
¿Necesitas ayuda para preparar tus modelos y sistemas de IA para la era de la Ley de IA? VULNEX ofrece:
- Evaluaciones de seguridad de sistemas y modelos de IA (evaluación, pruebas adversarias / AI red teaming, modelado de amenazas de modelos abiertos)
- Mapeo de roles GPAI y análisis de brechas de gobernanza (proveedor vs. responsable del despliegue, exposición por fine-tuning, inventario de modelos)
- Preparación de respuesta a incidentes de IA y diseño de telemetría en la capa de modelo
- Revisión secure-by-design para productos impulsados por IA y sistemas agénticos
Para estrategia de seguridad en IA —donde el riesgo de modelos y agentes se encuentra con las decisiones a nivel de consejo— visita vulnex.ai.
Contacto: info@vulnex.com
