AI Act: qué cambia de verdad para las empresas en 2026

El 2 de agosto de 2026 el Reglamento (UE) 2024/1689 —el AI Act— alcanzó su fecha general de aplicación. Once días antes, el 27 de julio, había entrado en vigor el Reglamento (UE) 2026/1744, conocido como Digital Omnibus sobre IA, que modifica el calendario y varias obligaciones sustantivas. Casi toda la cobertura de esa semana describió una foto que ya no era la vigente.

Las cuatro frases que importan

1. Lo que empezó el 2 de agosto de 2026 es, sobre todo, transparencia: decir que hay una IA detrás, marcar lo que genera y revelar los deepfakes.
2. El grueso de la carga documental —los sistemas de alto riesgo— no empezó. Se aplazó a diciembre de 2027 y agosto de 2028.
3. La obligación de alfabetización en IA lleva aplicándose desde febrero de 2025 y acaba de suavizarse: de garantizar un nivel a adoptar medidas para apoyarlo.
4. El aplazamiento no es tiempo libre. Es el único momento en el que se puede construir el inventario y la trazabilidad sin un plazo encima.

Una aseguradora mediana, cuatrocientos empleados, plataforma Java sobre AWS. En el comité de dirección la respuesta a esa pregunta fue «dos: el chatbot y el motor de siniestros». El inventario real, levantado en once días revisando contratos, facturas de tarjeta y configuración de los SaaS contratados, dio ocho.

Seis de los ocho entraron sin que nadie tomara una decisión sobre ellos. Dos de esos seis —el cribado de currículos y la transcripción de llamadas— tocan materias que el anexo III del Reglamento considera de alto riesgo. Y uno de los ocho convierte a la empresa en proveedor, con un régimen de obligaciones completamente distinto al de simple usuario.

Por qué esto se ha vuelto urgente ahora

La cuarta fila merece una pausa. Un sistema que redacta un borrador y se lo enseña a una persona tiene un perfil de riesgo acotado por esa persona. Un agente que ejecuta acciones sobre sistemas reales —abre un ticket, aprueba un pago, modifica un registro— no lo tiene. La supervisión humana deja de ser un adorno arquitectónico y pasa a ser el único mecanismo de contención que queda.

Qué vamos a recorrer

Empezamos por qué dice exactamente la norma y terminamos en cómo se instrumenta la trazabilidad en una plataforma Java. Sin saltarse ningún paso y distinguiendo en todo momento el texto normativo del análisis.

El 2 de agosto de 2026 es la fecha general de aplicación del AI Act que fija el artículo 113. Todo lo que ese artículo no coloque expresamente en otra fecha es exigible desde ese día. La confusión de la cobertura periodística viene de mezclar tres conceptos que el Reglamento mantiene separados.

Y viene, sobre todo, de una razón más simple: hasta hace tres semanas el calendario era otro. El Reglamento (UE) 2026/1744, de 8 de julio de 2026, publicado en el DOUE el 24 de julio y en vigor desde el 27, reescribió el artículo 113. Buena parte de los artículos publicados esa semana estaban preparados con la versión anterior.

El calendario completo

Qué obligaciones empiezan de verdad

Tres bloques, y conviene entender que son de naturaleza muy distinta.

1 · Transparencia (artículo 50)

Es el bloque que afecta a más empresas y el que menos titulares se llevó. Obliga a informar de que se interactúa con una IA, a marcar el contenido sintético, a informar cuando se usa reconocimiento de emociones o categorización biométrica y a revelar los deepfakes. El capítulo 5 lo desarrolla entero.

2 · Poder sancionador sobre los modelos de uso general (artículo 101)

Las obligaciones del capítulo V para proveedores de modelos de IA de uso general —documentación técnica, política de derechos de autor, resumen del contenido de entrenamiento— son exigibles desde el 2 de agosto de 2025. Lo que faltaba era la capacidad de la Comisión de imponer multas por incumplirlas, y eso es exactamente lo que arranca ahora: hasta el 3 % del volumen de negocios mundial o 15 millones de euros, la cifra que sea mayor.

3 · Todo lo demás sin fecha propia

El capítulo VI de medidas de apoyo a la innovación, el capítulo IX de vigilancia del mercado en lo que no depende del alto riesgo, y el capítulo X de códigos de conducta. No generan carga inmediata para la mayoría de empresas, pero completan el marco de actuación de las autoridades.

Qué NO ha empezado

Qué cambia respecto a 2025

Qué se ha retrasado y por qué

El aplazamiento de las obligaciones de alto riesgo no responde a un cambio de criterio político sobre la conveniencia de regular. Responde a que faltaba la infraestructura para poder cumplir.

Un sistema de alto riesgo debe superar una evaluación de conformidad. Esa evaluación se realiza contra normas armonizadas —las que elabora el CEN-CENELEC por mandato de la Comisión— que traducen requisitos jurídicos abstractos, del tipo «niveles adecuados de precisión y solidez», en especificaciones verificables. En noviembre de 2025 esas normas seguían sin estar terminadas.

A eso se sumó que varios Estados miembros no habían designado ni dotado a las autoridades de vigilancia del mercado que debían estar operativas desde el 2 de agosto de 2025. Exigir conformidad sin norma técnica contra la que evaluar y sin autoridad que la verifique habría producido certificaciones sin contenido.

Todo lo que cambió el Digital Omnibus

El AI Act no clasifica empresas por sector ni por tamaño. Clasifica papeles dentro de la cadena de valor de un sistema de IA. Una misma empresa puede tener papeles distintos respecto de sistemas distintos, y ese es exactamente el punto donde se equivoca casi todo el mundo al planificar.

Proveedor frente a responsable del despliegue

En la práctica, el 95 % de las empresas solo necesitan entender bien estos dos. La diferencia no es de grado: son dos regímenes de obligaciones distintos, con documentación distinta y responsabilidad distinta.

Cuándo un usuario se convierte en proveedor

El artículo 25 contiene la trampa más habitual del Reglamento. Tres actuaciones aparentemente inocuas convierten a quien usa un sistema en proveedor de ese sistema, con todas las obligaciones que eso arrastra.

Perfil a perfil

El alcance extraterritorial

El artículo 2(1) es más amplio de lo que la mayoría de empresas no europeas asume. Alcanza a los proveedores que introducen sistemas en el mercado de la Unión con independencia de dónde estén establecidos, y también a proveedores y responsables del despliegue de terceros países cuando el resultado producido por el sistema se utiliza en la Unión.

Ese segundo supuesto es el que sorprende. Una consultora en Sudamérica que analiza currículos con IA para un cliente en Alemania está dentro del ámbito, aunque no tenga ninguna presencia en Europa, porque el resultado se usa en la Unión.

Qué queda fuera

La exclusión de código abierto del artículo 2(12) genera bastante confusión. No es una exención general: decae en cuanto el sistema es de alto riesgo, entra en una práctica prohibida o cae en alguno de los supuestos del artículo 50. Publicar un modelo bajo licencia Apache 2.0 no exime de marcar sus salidas.

Si estás decidiendo cómo estructurar la adopción de IA en tu organización, la página de Inteligencia Artificial Empresarial recoge cómo encajan estas decisiones con la arquitectura de la plataforma.

La alfabetización en IA es, según el artículo 3(56), el conjunto de capacidades, conocimientos y comprensión que permiten a proveedores, responsables del despliegue y personas afectadas realizar un despliegue informado de los sistemas de IA y tomar conciencia de las oportunidades, los riesgos y los perjuicios que puede causar.

El artículo 4 la convierte en obligación. Es aplicable desde el 2 de febrero de 2025, no desde 2026, y alcanza tanto a proveedores como a responsables del despliegue. Es decir, a cualquier empresa que use un sistema de IA en su actividad profesional.

La redacción cambió en julio de 2026

El Reglamento (UE) 2026/1744 sustituyó el artículo 4 completo. El cambio es de fondo, no de estilo.

«Los proveedores y responsables del despliegue de sistemas de IA adoptarán medidas para garantizar, en la mayor medida posible, un nivel suficiente de alfabetización en materia de IA de su personal…»

«…adoptarán medidas para apoyar el desarrollo de un nivel adecuado de alfabetización en materia de IA…», con una aclaración añadida: la obligación no exige garantizar ningún nivel concreto de alfabetización en IA de ninguna persona en particular.

La diferencia entre «garantizar» y «apoyar el desarrollo» es la diferencia entre una obligación de resultado y una de medios. En la práctica: antes había que poder demostrar que la gente sabía; ahora basta con poder demostrar que se han puesto los medios razonables para que sepa.

Qué exige exactamente

Qué NO exige

Esta tabla es la que conviene tener a mano cuando alguien llegue con un titular. Cada fila es una obligación que se ha atribuido al artículo 4 y que el artículo 4 no contiene.

Cómo se estructura un programa que aguante una inspección

El Reglamento no impone un catálogo. Lo que sigue es un modelo por niveles que cumple los criterios del artículo —diferenciación por conocimientos, por contexto y por personas afectadas— sin convertirse en un plan de formación corporativo de seis meses.

Un ejemplo real

Una consultora de sesenta personas, tres perfiles claros: desarrollo, gestión y administración. El programa completo se ejecutó en cinco semanas.

1. Semana 1. Política de uso de IA de dos páginas: herramientas aprobadas, qué información no puede salir de la organización, quién autoriza una herramienta nueva y qué hacer ante una salida sospechosa.
2. Semana 2. Sesión de nivel 0 de cuarenta y cinco minutos, grabada, con acuse de asistencia. Toda la plantilla.
3. Semana 3. Sesión de nivel 1 para quienes operan sistemas, con los casos de uso reales de la empresa sobre la mesa.
4. Semana 4. Taller de nivel 3 con el equipo de desarrollo: cómo clasificar lo que construyen y qué exige el artículo 50 de lo que entregan.
5. Semana 5. Ficha de sistema para cada herramienta del inventario, con sus instrucciones de uso resumidas en media página.

Coste directo: cero euros de proveedor externo y unas treinta horas de trabajo interno. La parte cara no fue la formación, fue levantar el inventario que hacía falta para poder redactar las fichas.

Qué documentación conservar

La pregunta que hay que poder responder no es «¿formamos a la gente?». Es «demuéstrelo».

Malas prácticas frecuentes

La respuesta corta: el Reglamento (UE) 2024/1689 no contiene ninguna disposición que obligue a una empresa a contratar a un experto en inteligencia artificial, a un responsable de IA ni a ningún otro perfil. Lo que obliga el artículo 4 es a adoptar medidas para apoyar el desarrollo de la alfabetización en IA del personal que ya se tiene, y desde la reforma del Reglamento (UE) 2026/1744 el propio artículo aclara que no exige garantizar ningún nivel concreto de ninguna persona en particular.

Ese párrafo se puede citar entero. El resto del capítulo explica por qué se ha publicado tantas veces lo contrario y en qué situaciones incorporar perfiles especializados sí tiene sentido —por razones de negocio y de riesgo, no porque lo imponga la norma.

De dónde sale la confusión

No es una invención. Cada una de las lecturas erróneas parte de un artículo que existe y dice algo parecido, pero no lo mismo.

Por qué la analogía con el DPO no funciona

Es la comparación que más daño hace, porque es la más natural: si el RGPD creó el delegado de protección de datos, el reglamento de IA habrá creado algo equivalente. No lo hizo.

Cuándo sí conviene incorporar perfiles especializados

Desmontar el mito no puede convertirse en el mensaje contrario. Hay situaciones en las que no tener a nadie con criterio propio sobre IA sale caro, y ninguna tiene que ver con el cumplimiento formal: tienen que ver con que las decisiones técnicas se toman una vez y se pagan durante años.

Árbol de decisión

Cuatro preguntas. La primera separa a los proveedores del resto, que es la línea que más cambia la respuesta.

Lo que sí hay que tener, con o sin contratación

1. Un responsable identificable. No un cargo nuevo: una persona concreta a la que preguntar cuando llegue un requerimiento. Puede ser el CTO, el responsable de cumplimiento o el DPO, con dedicación parcial y mandato escrito.
2. Un canal de decisión. Quién autoriza incorporar una herramienta de IA nueva y con qué criterios. Sin esto, el inventario vuelve a desfasarse en un trimestre.
3. Acceso a criterio jurídico para los casos límite. Puntual y externo funciona perfectamente; lo que no funciona es resolver una clasificación dudosa por consenso interno y no dejar constancia de por qué se decidió así.

Esas tres cosas no aparecen en ningún artículo del Reglamento. Aparecen en la primera reunión con una autoridad de vigilancia del mercado, que es un escenario distinto y bastante más concreto.

El artículo 50 no depende del nivel de riesgo del sistema. Se aplica a cualquier sistema de IA que caiga en alguno de sus cuatro supuestos, sea de alto riesgo o no. Es la razón por la que este capítulo afecta a más empresas que todo el capítulo III junto.

La distinción que hay que interiorizar

Los apartados 1 y 2 obligan al proveedor. Los apartados 3 y 4 obligan al responsable del despliegue. No es un detalle: significa que una empresa que solo usa herramientas de terceros tiene obligaciones propias que no puede trasladar al proveedor por contrato.

Si generas imágenes con un servicio comercial y las publicas como si fueran fotografías de personas reales, el marcado técnico es responsabilidad del servicio, pero la revelación del deepfake es tuya. Que el fichero lleve el manifiesto C2PA correcto no te exime del apartado 4.

Cómo se marca el contenido en la práctica

El artículo 50(2) exige que las soluciones sean «eficaces, interoperables, sólidas y fiables en la medida en que sea técnicamente viable». No impone una tecnología concreta, pero el ecosistema ha convergido de facto en dos: las credenciales de contenido C2PA firmadas criptográficamente y los vocabularios IPTC para el tipo de fuente digital.

Implementación

1 · El manifiesto que se firma en la generación

Este es el artefacto que satisface el marcado legible por máquina. Lo relevante es digitalSourceType con el valor trainedAlgorithmicMedia del vocabulario IPTC: es el término que un verificador automático busca para decidir si el contenido es sintético.

{
  "claim_generator": "AcmeImaging/2.4 c2pa-rs/0.36",
  "title": "informe-riesgo-2026.webp",
  "assertions": [
    {
      "label": "c2pa.actions",
      "data": {
        "actions": [
          {
            "action": "c2pa.created",
            "digitalSourceType":
              "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
            "softwareAgent": "acme-imaging-service/2.4",
            "when": "2026-08-06T09:41:12Z"
          }
        ]
      }
    },
    {
      "label": "stds.iptc.photo-metadata",
      "data": {
        "dc:creator": ["Acme Seguros, S.A."],
        "Iptc4xmpExt:DigitalSourceType":
          "trainedAlgorithmicMedia"
      }
    }
  ],
  "signature_info": {
    "alg": "ps256",
    "issuer": "Acme Seguros, S.A.",
    "cert_serial_number": "4c1f9a2e00b7"
  }
}

La firma es lo que convierte esto en una credencial y no en un comentario. Sin signature_info, cualquiera puede escribir esos metadatos, y un marcado que cualquiera puede falsificar difícilmente cumple el criterio de «sólido y fiable» del apartado 2.

2 · Las cabeceras de la respuesta

Los metadatos incrustados sirven a quien descarga el fichero. Para el resto de consumidores —una CDN, un agregador, un rastreador— la señal tiene que viajar en la respuesta HTTP.

HTTP/1.1 200 OK
Content-Type: image/webp
Content-Disposition: inline; filename="informe-riesgo-2026.webp"

# Procedencia legible por máquina. Referencia al manifiesto C2PA
# incrustado en el propio fichero, para clientes que no lo parsean.
Content-Credentials: c2pa; manifest="urn:uuid:8f3c1d0a-5b21-4e7f-9a3d-1c2b4e6f8a90"

# Señal explícita de contenido sintético.
X-Content-Provenance: ai-generated
X-Content-Generator: acme-imaging-service/2.4

# Nunca cachear la política de procedencia por separado del contenido.
Cache-Control: private, no-transform, max-age=3600

no-transform es la directiva que más se olvida. Sin ella, un intermediario puede recomprimir la imagen legítimamente y destruir el manifiesto que acabas de firmar.

3 · La revelación en la página

Cuando el contenido se publica en una web, el JSON-LD es donde la revelación se vuelve interpretable por buscadores y por motores generativos. Nótese que este ejemplo declara además el editor responsable, que es lo que activa la excepción del apartado 4 para el texto.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Informe trimestral de siniestralidad",
  "datePublished": "2026-08-06",

  "author": {
    "@type": "Organization",
    "name": "Acme Seguros, S.A."
  },

  "// Revelación del artículo 50(4)": "",
  "creativeWorkStatus": "Published",
  "isBasedOn": {
    "@type": "CreativeWork",
    "name": "Borrador generado por IA",
    "creator": {
      "@type": "SoftwareApplication",
      "name": "acme-drafting-assistant",
      "applicationCategory": "GenerativeAI"
    }
  },

  "// Responsabilidad editorial que activa la excepción": "",
  "editor": {
    "@type": "Person",
    "name": "Nombre del editor responsable"
  },
  "publishingPrinciples":
    "https://acme.example/politica-uso-ia"
}

4 · Centralizar el marcado en la plataforma

La implementación que falla es la que deja el marcado en manos de cada equipo. En una plataforma Spring Boot, el sitio correcto es un filtro que se aplique a todas las respuestas y lea el contexto de generación de la petición.

/**
 * Marca en la respuesta HTTP todo contenido cuya generación haya pasado
 * por un modelo. La decisión no se delega en cada controlador: si el
 * marcado depende de que alguien se acuerde, tarde o temprano se olvida.
 */
@Component
@Order(Ordered.HIGHEST_PRECEDENCE + 20)
class ContentProvenanceFilter extends OncePerRequestFilter {

    private final ProvenanceContext provenance;

    ContentProvenanceFilter(ProvenanceContext provenance) {
        this.provenance = provenance;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain chain)
            throws ServletException, IOException {

        try {
            chain.doFilter(request, response);
        } finally {
            // Se evalúa al final: durante la petición cualquier capa puede
            // haber invocado un modelo, y el filtro no puede saberlo antes.
            provenance.currentGeneration().ifPresent(generation -> {
                response.setHeader("X-Content-Provenance", "ai-generated");
                response.setHeader("X-Content-Generator", generation.modelId());
                generation.manifestUrn().ifPresent(urn ->
                    response.setHeader("Content-Credentials",
                        "c2pa; manifest=\"" + urn + "\""));
            });
        }
    }
}

El detalle importante está en el finally. La invocación al modelo puede producirse en cualquier capa y en cualquier momento de la petición, así que el filtro no puede decidir antes de que la cadena termine. Registrar la generación en un contexto de petición y consultarlo al final es lo que hace que ningún endpoint pueda olvidarse del marcado.

5 · El aviso del apartado 1

/**
 * Aviso del artículo 50(1). Se renderiza en el servidor y forma parte del
 * primer fragmento de HTML: si el aviso depende de que cargue el bundle de
 * JavaScript, hay una ventana en la que el usuario ya está escribiendo y
 * todavía no se le ha informado de nada.
 */
---
interface Props {
    assistantName: string;
    policyHref: string;
}

const { assistantName, policyHref } = Astro.props;
---

<p class="ai-disclosure" role="note">
    Estás hablando con <strong>{assistantName}</strong>, un asistente
    automático basado en inteligencia artificial. Puede cometer errores.
    <a href={policyHref}>Cómo usamos la IA</a> ·
    <button type="button" data-escalate>Hablar con una persona</button>
</p>

Qué NO obliga a etiquetar

La lectura maximalista —«hay que etiquetar todo lo que toque una IA»— genera avisos por todas partes, cansa al usuario y no cumple mejor. El artículo tiene cuatro supuestos y fuera de ellos no hay obligación.

El calendario del artículo 50

El Código de Buenas Prácticas es voluntario. La Comisión y el Comité Europeo de IA han confirmado que es un instrumento adecuado para demostrar cumplimiento, y el artículo 50(7) reserva a la Comisión la facultad de adoptar actos de ejecución si el código resulta insuficiente. Adherirse no es obligatorio; es la vía más barata de acreditar que se han tomado medidas razonables.

El régimen sancionador del AI Act es aplicable desde el 2 de agosto de 2025, salvo el artículo 101, que lo es desde el 2 de agosto de 2026. Los Estados miembros debían tener aprobado su propio régimen y comunicado a la Comisión en esa primera fecha.

Los tramos

Quién puede sancionar

El caso español

España fue de los primeros Estados miembros en crear una autoridad específica. El modelo no es completamente centralizado: la ley opta por una supervisión distribuida por sectores.

Cómo llega una sanción

No empieza con una multa. El procedimiento tiene varias fases y, en casi todas, la empresa tiene margen de actuación.

Qué gradúa la cuantía

El artículo 99(7) enumera las circunstancias que las autoridades deben tener en cuenta. Leerlas al revés es la mejor guía de preparación que existe.

La reforma del Reglamento (UE) 2026/1744 añadió algo relevante: el artículo 99(1) reescrito habla de sanciones y otras medidas de ejecución, incluidos los apercibimientos y las medidas no pecuniarias, y pide tener en cuenta la viabilidad económica de pymes y small mid-caps. En la práctica abre la puerta a que un primer incumplimiento subsanado se resuelva sin multa.

Seis situaciones concretas

Los casos que siguen son composiciones a partir de encargos reales. Cada uno ilustra una dificultad estructural distinta, y el orden no es casual: van de menos a más complejidad regulatoria hasta el banco, y terminan en la startup, que es el caso donde el coste de equivocarse temprano es mayor.

Caso 1 · Empresa de software con producto propio

Cuarenta personas, un producto SaaS de gestión documental. Hace dieciocho meses añadieron un asistente que resume documentos y genera borradores de contrato. Nadie en la empresa había considerado que eso los convertía en proveedores de un sistema de IA.

La conversación empezó cuando un cliente del sector público les pidió, en un pliego, la ficha del sistema y las instrucciones de uso.

Caso 2 · Despacho de abogados

Veinte profesionales. Usan un asistente comercial para redactar, resumir sentencias y preparar escritos. Ningún sistema propio, ningún desarrollo, ninguna función de alto riesgo. Su problema no es el AI Act: es el secreto profesional.

Su exposición regulatoria bajo el AI Act es de las más bajas del capítulo. Su exposición real es de las más altas, porque una filtración de información de cliente o una cita inventada en un escrito tienen consecuencias que no dependen de ningún reglamento europeo.

Caso 3 · Hospital

Hospital comarcal, ochocientas camas. Tres sistemas clínicos con IA —apoyo al diagnóstico por imagen, priorización de listas de espera y detección de deterioro— y una decena de sistemas administrativos. Es el caso con el régimen más complejo de los seis, porque se solapan dos marcos normativos.

Caso 4 · Banco

Entidad mediana. Ya tiene un marco de gobierno de modelos maduro, porque lleva años sujeto a supervisión prudencial sobre sus modelos de riesgo. Es, con diferencia, el caso mejor preparado de los seis, y aun así el que más trabajo tiene por delante.

La ventaja del banco es que ya sabe qué es validar un modelo, documentar sus supuestos y someterlo a revisión independiente. El error habitual en este perfil es construir una estructura de cumplimiento de IA en paralelo a la que ya existe, en lugar de extender la que funciona.

Caso 5 · Consultora tecnológica

Ciento veinte personas, proyectos de desarrollo a medida para grandes cuentas. Su problema es contractual antes que técnico: en la mitad de sus proyectos no está escrito quién es el proveedor del sistema que entregan.

Caso 6 · Startup

Ocho personas, producto de análisis de candidatos para procesos de selección. Es el caso más delicado de los seis: el punto 4(a) del anexo III incluye expresamente los sistemas destinados a la contratación o selección de personas físicas, en particular para publicar anuncios dirigidos, analizar y filtrar solicitudes y evaluar candidatos.

Tienen dieciséis meses hasta diciembre de 2027. Suena a mucho, y no lo es: la documentación técnica del anexo IV, la gobernanza de datos del artículo 10 y la evaluación de conformidad son trabajo de varios trimestres para un equipo de ocho personas que además tiene que construir el producto.

Matriz comparativa

Un patrón que se repite en los seis: lo urgente es siempre pequeño y lo importante es siempre grande. Lo urgente son avisos, políticas y marcado, y se resuelve en semanas. Lo importante es inventario, clasificación y trazabilidad, y se resuelve en trimestres. Empezar por lo importante y dejar lo urgente sin hacer es el único orden que no funciona.

Una lista de comprobación sin columna de evidencia no sirve para nada: se marca entera y no demuestra nada. Cada fila de lo que sigue indica qué documento concreto acredita el cumplimiento, porque eso es lo que se pide en un requerimiento.

Bloque A · Inventario y clasificación

No es una obligación con artículo propio. Es la condición previa a todas las demás: sin inventario no se puede formar a quien opera, ni saber qué avisos hacen falta, ni determinar qué sistemas caerán en el anexo III dentro de dieciséis meses.

Ficha mínima de inventario

Este es el formato que sobrevive. Todo lo que sea más largo se rellena la primera vez y no se actualiza nunca.

# Ficha mínima de un sistema de IA en el inventario.
# Cabe en una fila de hoja de cálculo. Que quepa es el requisito:
# un inventario que exige media hora por sistema no se mantiene.

id:                    SIA-014
nombre:                Cribado de currículos
proveedor:             Nombre del fabricante del ATS
integrado_en:          Suite de RR. HH.
propietario_funcional: Responsable de Selección
propietario_tecnico:   Responsable de Sistemas

# Rol de nuestra empresa respecto de este sistema (art. 3.3 / 3.4)
rol:                   deployer
rol_justificacion:     >
  Se usa conforme a las instrucciones del fabricante, sin cambio de
  finalidad ni marca propia. No concurre el art. 25.

# Clasificación (art. 5, art. 6 y anexo III)
practica_prohibida:    no
alto_riesgo:           si
alto_riesgo_base:      Anexo III, punto 4(a) — selección de personal
clasificado_por:       Nombre y cargo
clasificado_el:        2026-08-06

# Transparencia (art. 50)
interaccion_directa:   no
genera_contenido:      no
biometria_emociones:   no

# Datos y trazabilidad
datos_personales:      si
categorias_especiales: no
retencion_registros:   180 dias
epd_realizada:         si

# Hitos
proxima_revision:      2027-02-01
hito_conformidad:      2027-12-02

Dos campos merecen atención. rol_justificacion es la defensa frente al artículo 25: deja constancia de que se comprobó que no había cambio de finalidad. Y clasificado_por con clasificado_el convierten una opinión en un acto documentado.

Bloque B · Alfabetización en IA

Bloque C · Transparencia

Bloque D · Alto riesgo

Este bloque no es exigible en 2026. Está aquí para que quien tenga un sistema del anexo III sepa el tamaño de lo que le espera y pueda planificarlo, no para que empiece a ejecutarlo ahora.

El plan que sigue está calibrado para una organización de entre cincuenta y quinientas personas sin función de cumplimiento dedicada. Las duraciones son de calendario, no de esfuerzo: buena parte del tiempo se va esperando respuestas de proveedores y de responsables de área, no trabajando.

Los primeros 30 días

El objetivo del primer mes no es cumplir. Es saber. Y, de paso, resolver las dos cosas que ya son exigibles y se arreglan en días: el barrido de prácticas prohibidas y los avisos de interacción.

De 31 a 90 días

La clasificación es la tarea central. No consiste en decidir si algo es de alto riesgo: consiste en dejar escrito por qué se decidió lo que se decidió. Una clasificación sin justificación no es defendible, y en dieciséis meses nadie recordará el razonamiento.

La formación va en paralelo porque no depende de la clasificación. El nivel 0 se puede impartir con el inventario en bruto.

De 91 a 180 días

Aquí empieza el trabajo de ingeniería. La trazabilidad de las llamadas a modelos es lo que convierte una declaración en una prueba, y es lo que el capítulo 11 desarrolla en detalle.

El simulacro de requerimiento del mes 6 es la parte más incómoda y la más útil. Alguien —idealmente de fuera del equipo que lo ha montado— pide la documentación como la pediría una autoridad, y se cronometra. Si la respuesta tarda más de una semana, el sistema documental no funciona por muy completo que parezca.

De 7 a 12 meses

La fase de consolidación tiene un único objetivo: que el régimen se mantenga solo. Un programa de cumplimiento que exige un proyecto cada año no es un programa, es una serie de proyectos.

El flujo que hay que dejar montado

Todo lo anterior converge en un proceso. Sin él, el inventario vuelve a desfasarse en un trimestre y hay que repetir el trabajo del mes 2.

Esfuerzo y coste

Cinco formas de hacerlo mal

La pregunta que se hace un desarrollador al leer sobre el AI Act es si le pueden multar por usar Copilot. La respuesta es que no: usar un asistente de código no está regulado como tal. Lo que está regulado es el sistema que entregas, y ahí sí cambian varias cosas.

Qué cambia en el día a día

Instrumentar toda llamada a un modelo

El requisito técnico central no viene del artículo 50: viene de poder responder a un requerimiento. Si no hay traza, no hay nada que enseñar, y eso pesa como circunstancia agravante en el artículo 99(7).

En Spring AI el sitio correcto es un Advisor. Se registra una vez en el ChatClient y aplica a todos los casos de uso, presentes y futuros.

/**
 * Advisor que instrumenta toda llamada a un modelo.
 *
 * Se registra una sola vez en el ChatClient y aplica a cualquier caso de
 * uso. Si la trazabilidad depende de que cada servicio se acuerde de
 * loguear, en tres meses habrá servicios que no lo hagan.
 *
 * No registra el prompt completo a propósito: el contenido puede incluir
 * datos personales y el AI Act no obliga a conservarlo. Lo que se conserva
 * es lo que permite reconstruir la decisión.
 */
@Component
class ProvenanceAdvisor implements CallAroundAdvisor {

    private static final Logger AUDIT = LoggerFactory.getLogger("ai.audit");

    private final ProvenanceContext provenance;

    ProvenanceAdvisor(ProvenanceContext provenance) {
        this.provenance = provenance;
    }

    @Override
    public AdvisedResponse aroundCall(AdvisedRequest request,
                                      CallAroundAdvisorChain chain) {

        var started = Instant.now();
        var invocationId = UUID.randomUUID().toString();

        try {
            var response = chain.nextAroundCall(request);

            var usage = response.response().getMetadata().getUsage();

            AUDIT.atInfo()
                .addKeyValue("invocation.id", invocationId)
                .addKeyValue("model.id", request.chatModel().toString())
                .addKeyValue("prompt.version", request.adviseContext()
                        .getOrDefault("prompt.version", "unversioned"))
                .addKeyValue("prompt.hash", sha256(request.userText()))
                .addKeyValue("tokens.input", usage.getPromptTokens())
                .addKeyValue("tokens.output", usage.getGenerationTokens())
                .addKeyValue("latency.ms",
                        Duration.between(started, Instant.now()).toMillis())
                .addKeyValue("subject.id", currentSubjectPseudonym())
                .log("model invocation");

            provenance.record(invocationId, request.chatModel().toString());

            return response;

        } catch (RuntimeException failure) {
            AUDIT.atWarn()
                .addKeyValue("invocation.id", invocationId)
                .addKeyValue("outcome", "failed")
                .log("model invocation failed", failure);
            throw failure;
        }
    }

    @Override
    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE;
    }

    @Override
    public String getName() {
        return "provenance";
    }
}

Tres decisiones de este código merecen explicación.

• No se registra el prompt completo. Se registra su hash. El contenido puede incluir datos personales y el AI Act no obliga a conservarlo: conservarlo por si acaso es crear un problema de RGPD para resolver uno de IA.
• El sujeto va seudonimizado. Suficiente para reconstruir una decisión concreta si hay reclamación, sin construir un registro nominal de uso.
• La versión del prompt es un campo de primer nivel. Sin ella, dos invocaciones idénticas del mismo modelo pueden haber tenido comportamientos distintos y no hay forma de saberlo.

Versionar los prompts

Un prompt de sistema determina el comportamiento del sistema tanto como el código. Que viva como una cadena literal dentro de una clase es la razón por la que casi ninguna organización puede responder a «qué instrucciones tenía el modelo en marzo».

# Los prompts de sistema se versionan como se versiona el esquema de
# la base de datos: porque cambian el comportamiento del sistema y
# porque hay que poder responder «qué instrucciones tenía el modelo
# el 14 de marzo».

resources/prompts/
├── triage-siniestros/
│   ├── v1.0.0.md          # Retirado. Se conserva: hubo decisiones con él
│   ├── v1.1.0.md          # Añade la regla de escalado a humano
│   └── v2.0.0.md          # Activo desde 2026-07-01
└── prompts.yaml           # Qué versión está activa en cada entorno

Las versiones retiradas se conservan. No por nostalgia: porque hubo decisiones tomadas con ellas y explicar una decisión requiere conocer las instrucciones vigentes en ese momento.

RAG: la respuesta sin las fuentes no es reproducible

En un sistema de recuperación aumentada, la salida depende tanto del modelo como de qué documentos se recuperaron. Registrar solo la respuesta deja fuera la mitad de la información necesaria para explicarla.

/**
 * En un sistema RAG, la respuesta sin las fuentes recuperadas es
 * irreproducible. Registrar solo la salida del modelo deja fuera la
 * mitad de la información necesaria para explicar por qué respondió
 * lo que respondió.
 */
record RetrievalTrace(
        String invocationId,
        String query,
        List<DocumentRef> retrieved,
        String rerankerVersion,
        int contextTokens) {

    record DocumentRef(
            String documentId,
            String chunkId,
            double score,
            Instant indexedAt) {}
}

indexedAt es el campo que se olvida siempre. Un documento reindexado con contenido distinto produce respuestas distintas a la misma pregunta, y sin la fecha de indexación esa diferencia es inexplicable.

Agentes: donde el riesgo cambia de naturaleza

Un sistema que genera texto está acotado por la persona que lo lee. Un agente que ejecuta acciones no lo está. La diferencia no es de grado: es la línea a partir de la cual la supervisión humana deja de ser una buena práctica y pasa a ser el único mecanismo de contención.

/**
 * Un agente que ejecuta acciones necesita un límite explícito, no una
 * instrucción en el prompt. Lo que el modelo puede hacer se declara en
 * código; lo que se le pide se declara en el prompt. Confundir ambas
 * cosas es lo que produce los incidentes.
 */
@Component
class ActionGuard {

    private static final Set<String> REVERSIBLE =
            Set.of("draft.create", "ticket.comment", "report.generate");

    private final AuditTrail audit;

    ActionResult execute(AgentAction action, Principal subject) {

        if (!REVERSIBLE.contains(action.type())) {
            // Toda acción irreversible pasa por una persona. No es una
            // exigencia del artículo 50: es lo que hace que el sistema
            // siga siendo defendible cuando algo salga mal.
            audit.record(action, subject, Outcome.ESCALATED);
            return ActionResult.requiresHumanApproval(action);
        }

        if (!action.withinBudget()) {
            audit.record(action, subject, Outcome.BLOCKED_BY_BUDGET);
            return ActionResult.blocked("budget exceeded");
        }

        var result = executor.run(action);
        audit.record(action, subject, Outcome.EXECUTED, result.reference());

        return result;
    }
}

La regla que sostiene este diseño es simple: lo que el agente puede hacer se declara en código; lo que se le pide se declara en el prompt. Un agente cuyos límites viven en las instrucciones en lenguaje natural tiene exactamente la robustez del modelo que las interpreta, que es poca.

Asistentes de código: los riesgos reales

Ninguno de estos riesgos procede del AI Act. Todos son anteriores y todos siguen ahí.

Si estás dimensionando la infraestructura que va a soportar todas estas llamadas bloqueantes a modelos —que tardan segundos, no milisegundos—, el artículo sobre Virtual Threads en Java 21 explica por qué el pool de hilos clásico es el primer techo que vas a encontrar. Y la página de consultoría Spring Boot recoge cómo encaja todo esto en una plataforma en producción.

Un arquitecto que lee el capítulo III del AI Act no encuentra nada exótico. Encuentra gestión de riesgos, gobernanza de datos, registro de eventos, documentación, supervisión y monitorización poscomercialización. Es la lista de requisitos no funcionales de cualquier sistema serio, escrita por un legislador.

Eso tiene una consecuencia práctica que conviene aprovechar: el presupuesto de cumplimiento y el de calidad son el mismo presupuesto. Presentarlo así suele desbloquear conversaciones que llevaban dos años estancadas.

Gobierno de IA en una empresa

La estructura que funciona tiene cuatro niveles y una característica: el flujo va en los dos sentidos. Una estructura que solo emite políticas hacia abajo y no recibe evidencia hacia arriba produce documentos que nadie aplica.

Roles implicados

La columna de la derecha es la que importa. Casi ningún rol de esta tabla es un perfil nuevo: son responsabilidades que se asignan a personas que ya están.

Trazabilidad: qué registrar exactamente

La pregunta operativa no es «¿hay que registrar?». Es «¿qué campos permiten reconstruir una decisión un año después sin conservar datos que no deberías tener?».

# Convenciones de atributos para trazas de IA generativa.
# Se apoyan en las semantic conventions de OpenTelemetry para GenAI:
# usar los nombres estándar es lo que permite que las herramientas de
# observabilidad los entiendan sin configuración a medida.

gen_ai.system:               "openai"
gen_ai.request.model:        "gpt-4.1"
gen_ai.request.temperature:  0.2
gen_ai.request.max_tokens:   2048
gen_ai.response.model:       "gpt-4.1-2026-04-14"
gen_ai.response.finish_reasons: ["stop"]
gen_ai.usage.input_tokens:   1840
gen_ai.usage.output_tokens:  412

# Atributos propios. El prefijo evita colisiones con futuras
# convenciones estándar.
app.ai.use_case:             "triage-siniestros"
app.ai.prompt_version:       "2.0.0"
app.ai.risk_class:           "annex-iii-5b"
app.ai.human_review:         "required"
app.ai.human_review.outcome: "accepted"
app.ai.subject_pseudonym:    "sub_9f3c1d0a"
app.ai.retrieval.doc_count:  7

Usar las convenciones semánticas de OpenTelemetry para IA generativa en lugar de nombres propios no es cosmética. Es lo que hace que Grafana, Tempo o cualquier backend de trazas entiendan los atributos sin configuración a medida, y lo que permite correlacionar la invocación del modelo con el resto de la traza distribuida de la petición.

El montaje concreto de esa telemetría —Micrometer, OpenTelemetry, exportadores y muestreo— está desarrollado en Observabilidad en Microservicios. Aquí solo cambia qué atributos se emiten, no la infraestructura.

Aislar el modelo detrás de un puerto

El error de diseño más común es tratar al proveedor de modelos como una librería y salpicar llamadas por toda la aplicación. El modelo es un sistema externo, no determinista, con versiones que cambian sin aviso y con condiciones contractuales que pueden cambiar también.

/**
 * El modelo entra en el dominio por un puerto, no por una dependencia
 * directa. No es purismo hexagonal: es lo que permite cambiar de
 * proveedor sin tocar la lógica, y lo que hace que la traza y la
 * política de revisión humana vivan en un solo adaptador.
 */
public interface RiskAssessmentPort {

    /**
     * @return la valoración, siempre acompañada de la evidencia que
     *         permite explicarla. Devolver solo el resultado hace que
     *         el sistema sea inexplicable por construcción.
     */
    RiskAssessment assess(ClaimContext context);
}

public record RiskAssessment(
        RiskLevel level,
        double confidence,
        List<Factor> factors,
        Evidence evidence,
        boolean requiresHumanReview) {

    public record Factor(String name, double weight, String rationale) {}

    public record Evidence(
            String invocationId,
            String modelId,
            String promptVersion,
            List<String> retrievedDocumentIds,
            Instant assessedAt) {}
}

Lo relevante de este diseño no es el puerto: es que el tipo de retorno obliga a devolver la evidencia. Un método que devuelve solo el nivel de riesgo produce un sistema inexplicable por construcción, y añadir la explicabilidad después significa reescribir todas las firmas.

Si trabajas con Arquitectura Hexagonal, esto es exactamente el patrón de puertos y adaptadores aplicado a una dependencia que casi nadie trata como lo que es: infraestructura.

Atributos de calidad y su artículo

Política de retención

Aquí es donde el AI Act y el RGPD tiran en direcciones opuestas: uno pide conservar para poder demostrar, el otro pide minimizar y suprimir. La política tiene que resolver esa tensión dato a dato, no en abstracto.

Este tipo de decisiones estructurales —dónde vive la IA en la plataforma, qué se aísla y qué se traza— es el contenido de la página pilar de Arquitectura Java.

Los cinco primeros se corrigen leyendo. Los cinco siguientes, inventariando. Los seis siguientes, montando un proceso. Y los cuatro últimos son decisiones de arquitectura que se toman una vez y se pagan durante años.

Los cuatro que salen más caros

No son los más frecuentes: son los que tienen peor relación entre lo que cuesta evitarlos y lo que cuesta arreglarlos después.

Si diriges una empresa

Tu decisión no es cuánto invertir en cumplimiento. Es a quién le pones nombre. Una persona concreta, con dedicación declarada y con autoridad para pedir información a cualquier departamento, resuelve más que cualquier presupuesto.

La segunda decisión es no confundir aplazamiento con desaparición. El calendario de alto riesgo se reactiva el 2 de diciembre de 2027, y lo que hay que tener listo para entonces —inventario, clasificación justificada, trazabilidad— tarda trimestres en construirse y no se puede comprimir con dinero en el último momento.

Y la tercera: no pares proyectos por incertidumbre regulatoria. El coste de no adoptar IA donde tiene retorno claro es mayor que el de cualquier sanción realista para una empresa que actúa de buena fe y documenta lo que hace.

Si eres desarrollador

Nada de lo que usas para escribir código está prohibido ni lo va a estar. Lo que cambia es lo que entregas.

1. Si tu aplicación habla con personas, comprueba que el aviso de interacción está en el HTML inicial y no depende del bundle de JavaScript.
2. Instrumenta las llamadas a modelos con un interceptor o un advisor, una sola vez, en la capa compartida. Si depende de que cada servicio se acuerde, en tres meses habrá servicios que no lo hagan.
3. Saca los prompts del código y versiónalos. Determinan el comportamiento del sistema tanto como una clase.
4. Si estás construyendo un agente, declara en código lo que puede hacer. Los límites que viven en el prompt tienen la robustez del modelo que los interpreta.

Si eres arquitecto

Tienes la mejor posición de la organización para llevar esto, y la razón no es regulatoria: es que el AI Act pide trazabilidad, observabilidad, explicabilidad y reversibilidad, que es literalmente tu lista de requisitos no funcionales con otro nombre.

Aprovecha esa coincidencia para desbloquear lo que llevaba dos años sin presupuesto. Separa el registro de auditoría del operativo desde el primer día, aísla el modelo detrás de un puerto y haz que el tipo de retorno obligue a devolver la evidencia. Las tres cosas cuestan poco cuando se hacen al principio y son proyectos completos cuando se hacen después.

Si necesitas ayuda para levantar el inventario, clasificar los sistemas con justificación defendible o dejar montada la trazabilidad en una plataforma Java antes de diciembre de 2027, en servicios de consultoría está cómo trabajo y en casos reales, qué resultados ha dado en proyectos comparables.

Normativa

Artículos citados

Comisión Europea y AI Office

• Comisión Europea — Marco regulador de la IA Página oficial de referencia, con el calendario actualizado tras el Digital Omnibus.
• AI Office — Oficina Europea de Inteligencia Artificial Autoridad competente sobre los modelos de IA de uso general.
• AI Act Service Desk Servicio oficial de consulta de la Comisión, con preguntas frecuentes y explorador de obligaciones.
• Código de Buenas Prácticas sobre transparencia del contenido generado por IA Instrumento voluntario del artículo 50(7). Versión final publicada el 10 de junio de 2026.
• Código de Buenas Prácticas para modelos de IA de uso general Referencia para las obligaciones del capítulo V.
• Comisión Europea — Aplicación del AI Act Directrices, actos de ejecución y normas armonizadas en preparación.

Otras instituciones europeas

• Consejo de la Unión Europea — Inteligencia artificial Posición del Consejo y comunicados de las fases de aprobación.
• Parlamento Europeo — Ley de IA de la UE Documentación parlamentaria del procedimiento legislativo.
• EUR-Lex Fuente primaria de todos los textos citados, en las 24 lenguas oficiales.

España

• AESIA — Agencia Española de Supervisión de la Inteligencia Artificial Autoridad de vigilancia del mercado de referencia en España. Sede en A Coruña.
• Agencia Española de Protección de Datos Competente en biometría, categorización biométrica y en todo lo que toque datos personales.
• Congreso de los Diputados Tramitación del Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial.
• Ministerio para la Transformación Digital y de la Función Pública Notas oficiales sobre la adaptación del AI Act al ordenamiento español.

Estándares técnicos

• C2PA — Especificación de Content Credentials Base técnica del marcado del artículo 50(2). No es una norma jurídica: es el estándar de facto.
• IPTC — Vocabulario Digital Source Type Define trainedAlgorithmicMedia, el término que identifica contenido generado por IA.
• OpenTelemetry — Semantic Conventions for Generative AI Convenciones de atributos usadas en el capítulo 11.
• CEN-CENELEC — Normas armonizadas de inteligencia artificial Las normas contra las que se evaluará la conformidad de los sistemas de alto riesgo.

Continúa en este sitio

• Inteligencia Artificial Empresarial La página pilar: cómo se adopta IA en una plataforma enterprise.
• Observabilidad en Microservicios El montaje de Micrometer y OpenTelemetry del que depende la trazabilidad del capítulo 11.
• Arquitectura Hexagonal desde cero Puertos y adaptadores aplicados a aislar el modelo del dominio.
• Virtual Threads en Java 21 Por qué el pool de hilos clásico es el primer techo al llamar a modelos que tardan segundos.
• Arquitectura Java Decisiones estructurales en plataformas Java enterprise.
• Auditoría técnica Cuando el problema que revela el AI Act no es de cumplimiento, sino de gobierno del software.