El AI Act entra en fase operativa: desde este 2 de agosto ya no basta con ‘usar IA’ sin dejar rastro

La fecha importa más de lo que parece. Desde este 2 de agosto de 2026, el AI Act deja de ser para muchas empresas ese reglamento europeo que todo el mundo menciona en comités y casi nadie había convertido en control operativo. Se activa un bloque adicional de obligaciones y, con él, una pregunta incómoda para banca, seguros, pagos y fintech: ¿tu entidad sabe realmente qué sistemas de IA usa, quién los gobierna, qué datos tocan y qué rastro dejan?

La Comisión Europea ha querido marcar el momento político. Tiene lógica. El problema es que la conversación pública sigue demasiado centrada en la gran etiqueta —“regular la IA”— y muy poco en la letra pequeña que ahora empieza a doler: formación obligatoria del personal, reglas de transparencia para ciertos usos, supervisión más tangible y una necesidad brutal de trazabilidad interna. Dicho sin rodeos: si tu organización no ha hecho inventario, clasificación de casos de uso y asignación clara de responsables, va tarde.

Y no, esto no afecta solo al puñado de empresas que desarrollan modelos fundacionales. Ese es uno de los malentendidos más cómodos de 2025, y ya no sirve en 2026. El AI Act reparte obligaciones entre proveedores, importadores, distribuidores, deployers y otros actores de la cadena. En el sector regulado, especialmente en servicios financieros, el riesgo no está solo en “crear IA”, sino en comprarla, integrarla, orquestarla sobre datos sensibles y tomar decisiones con ella sin una gobernanza mínimamente defendible.

Tesis editorial

La entrada en esta fase del AI Act no es un problema de innovación. Es un problema de madurez operativa. Europa no está diciendo “usen menos IA”; está diciendo algo bastante más sensato: si la IA influye en decisiones, clientes, fraude, riesgo, siniestros, onboarding, prevención de blanqueo o soporte interno, demuéstrame quién manda, qué controles existen y cómo se evita el caos. La ironía es evidente: muchas entidades llevan dos años presumiendo de copilotos, modelos de scoring enriquecidos y automatización inteligente, pero todavía no pueden responder con precisión a una pregunta infantil y devastadora a la vez: ¿cuántos sistemas de IA tenéis en producción?

Ese desfase entre ambición comercial y disciplina documental es exactamente el hueco que el AI Act empieza a cerrar. Y el sector financiero debería tomárselo en serio por una razón muy simple: cuando una tecnología impacta en operaciones críticas, clientes y terceros, termina chocando con todo lo demás. Choca con DORA si falla la resiliencia; con GDPR si hay datos personales y perfiles; con NIS2 si soporta servicios esenciales o importantes; con eIDAS 2.0 si entra en identidad, confianza y validación; y con los marcos de control interno si nadie puede explicar por qué el sistema hizo lo que hizo.

Qué cambia a partir del 2 de agosto y por qué esta fecha sí obliga a mover fichas

El Reglamento (UE) 2024/1689, el AI Act, establece una aplicación escalonada. Parte de sus disposiciones se adelantaron meses atrás, pero el 2 de agosto de 2026 es uno de los hitos que convierten el texto en algo material para funciones de compliance, riesgo, legal, compras, seguridad y auditoría interna. No es la aplicación completa de todas las obligaciones imaginables; es peor para quien improvisó, porque combina deberes ya vigentes con la necesidad de preparar los que llegarán a continuación sin la coartada de “todavía falta”.

Hay tres bloques que merecen atención inmediata.

El primero es la alfabetización en IA. El AI Act exige que los proveedores y deployers adopten medidas para garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA de su personal y de otras personas que operen y utilicen sistemas de IA en su nombre. Eso está en el artículo 4. Parece blando hasta que lo traduces a una auditoría interna o a un supervisor sectorial: no basta con una sesión genérica de una hora sobre “qué es la IA generativa”. Hay que poder demostrar que quienes diseñan, compran, configuran, usan o supervisan sistemas de IA entienden riesgos, limitaciones, supervisión humana y uso permitido.

El segundo bloque es la transparencia para sistemas concretos. Los artículos 50 y siguientes introducen obligaciones de transparencia en determinados supuestos, entre ellos cuando una persona interactúa con un sistema de IA y no resulta obvio, o cuando se generan contenidos sintéticos como audio, imagen, vídeo o texto. No todas las herramientas internas de IA entran de lleno en el mismo saco, pero en atención al cliente, asistentes virtuales, chatbots, generación automatizada de comunicaciones o tratamiento documental la pregunta ya no es teórica: ¿estás informando adecuadamente de que hay IA? ¿Puedes acreditar cuándo se usa, con qué finalidad y con qué intervención humana?

El tercer bloque es institucional, y suele subestimarse. A estas alturas de 2026 ya existe una arquitectura de supervisión más definida: la Comisión, la Oficina Europea de IA y las autoridades nacionales competentes van aterrizando mecanismos de vigilancia y coordinación. Eso cambia el incentivo. Durante la fase previa, muchas empresas operaban como si el cumplimiento fuese un ejercicio de prospectiva. Con el despliegue institucional, pasa a ser un ejercicio de demostración.

El punto delicado es que el AI Act funciona por capas de riesgo. Los sistemas de uso prohibido quedan fuera del juego; los de alto riesgo arrastran requisitos mucho más duros; otros usos activan transparencia; y los modelos de propósito general siguen su propio carril regulatorio. El resultado práctico es poco elegante, pero muy europeo: hay que clasificar bien antes de controlar bien. Si no sabes en qué categoría cae tu caso de uso, no puedes decidir ni qué documentación necesitas ni qué cláusulas exigir al proveedor.

El error que más se repite: confundir “comprar IA” con “trasladar el riesgo al proveedor”

Aquí está uno de los grandes autoengaños del mercado. Muchas entidades creen que, si la herramienta la suministra un gran proveedor cloud, un fabricante de software o una fintech especializada, el grueso del problema regulatorio queda externalizado. No funciona así.

El AI Act distingue funciones y responsabilidades a lo largo de la cadena. El proveedor tiene obligaciones propias, sí. Pero el deployer —quien usa el sistema bajo su autoridad, especialmente en el ámbito profesional— no desaparece del radar. En banca y seguros, donde la IA se incrusta en procesos sujetos a control estricto, el deployer sigue siendo el rostro visible del riesgo frente al cliente, al supervisor y, llegado el caso, al juez.

Eso tiene consecuencias muy concretas. Si una aseguradora usa IA para priorizar siniestros, detectar fraude o sugerir reservas, el hecho de que el motor venga de un tercero no elimina la necesidad de supervisión humana, validación de resultados, control de sesgos, gestión de incidencias y registro de cambios. Si un banco integra un asistente generativo para resumir expedientes de onboarding o preparar respuestas a alertas AML, tampoco puede escudarse en que “el modelo es del proveedor”. La entidad decide el contexto de uso, los datos que expone, los permisos, el flujo de aprobación y la confianza que otorga al resultado. Y eso ya es gobernanza.

En términos operativos, el contrato con el proveedor deja de ser una compra tecnológica y se parece más a una pieza híbrida entre outsourcing, seguridad de la información y cumplimiento regulatorio. Tu equipo de procurement quizá aún no lo ha asumido. Debería.

Lo que el sector financiero tiene que ordenar ya: inventario, clasificación y trazabilidad

El primer trabajo serio no es desplegar una política corporativa grandilocuente. Es hacer inventario. Inventario de verdad, no una hoja de cálculo decorativa preparada para el comité. La entidad tiene que identificar, al menos, cinco capas.

Una, los sistemas desarrollados internamente, incluidos modelos estadísticos avanzados y herramientas generativas encapsuladas como producto interno. Dos, los sistemas comprados a terceros e integrados en procesos de negocio. Tres, las funcionalidades de IA embebidas en software empresarial que entraron por la puerta de atrás: suites de productividad, CRM, herramientas de atención, plataformas de ciberseguridad, soluciones KYC, motores antifraude. Cuatro, los usos experimentales o de shadow AI, porque abundan más de lo que se admite en las reuniones formales. Cinco, los flujos de datos asociados: qué entra, qué sale, qué se conserva, qué se reinyecta al modelo y qué terceros tienen acceso.

Sin ese mapa, todo lo demás es teatro. No puedes clasificar riesgo, ni decidir si hay obligaciones de transparencia, ni documentar supervisión humana, ni verificar base jurídica de tratamiento de datos personales, ni revisar transferencias internacionales, ni evaluar dependencia de terceros críticos, ni preparar evidencias de control.

La trazabilidad es la segunda gran pieza. En entornos regulados, “trazabilidad” no significa solo logs técnicos. Significa poder reconstruir, de forma razonable, qué sistema intervino, qué versión estaba activa, con qué datos operó, qué output generó, quién lo revisó, qué decisión final se tomó y qué excepción se permitió. Si ese rastro no existe, la IA se vuelve muy vistosa en demo y muy tóxica en auditoría.

Los equipos de riesgo de modelo ya conocen esta lógica en ámbitos tradicionales. La novedad es que ahora debe ampliarse a sistemas que mucha gente del negocio aún percibe como herramientas ofimáticas potentes. Un copiloto que resume expedientes no parece un “modelo de riesgo” hasta que omite un dato relevante, contamina una decisión o induce a un analista a validar algo que no habría validado sin ese resumen. La supervisión humana no sirve si el humano va ciego, saturado o excesivamente confiado. El AI Act no inventa ese problema; simplemente obliga a dejar de fingir que no existe.

El artículo 4 parece inocente. No lo es.

La obligación de alfabetización en IA del artículo 4 está recibiendo menos atención mediática que las prohibiciones o que los sistemas de alto riesgo. Error. Para muchas entidades va a ser el primer punto por el que un supervisor o un auditor pregunte, porque es transversal, relativamente verificable y deja en evidencia la diferencia entre gobernanza real y PowerPoint.

¿Qué significa cumplir de forma defendible? No hay una única plantilla, pero sí un mínimo creíble. La entidad debería segmentar colectivos: consejo y alta dirección, funciones de control, equipos de compras, desarrolladores o integradores, negocio usuario intensivo y personal general. Después, definir contenidos distintos. Quien aprueba presupuesto y apetito de riesgo no necesita el mismo detalle que quien configura prompts conectados a datos de clientes o quien revisa salidas de un sistema usado en siniestros.

Además, la alfabetización útil no se limita a explicar conceptos técnicos. Tiene que cubrir errores típicos: alucinaciones, sesgo, sobreconfianza, exposición de datos, reutilización indebida de contenido, dependencia de outputs, ausencia de trazabilidad y límites de explicabilidad. En banca y seguros conviene añadir dos módulos que suelen olvidarse: interacción con GDPR y criterios de escalado de incidencias operativas.

La prueba de fuego es sencilla. Si mañana un supervisor pregunta por la capacitación de quienes usan IA en procesos sensibles, ¿puedes mostrar fechas, asistentes, materiales, evaluación y refrescos periódicos? Si la respuesta es no, el artículo 4 deja de parecer simpático.

Impacto regulatorio cruzado: el AI Act no vive solo y ahí empiezan los dolores de verdad

La gran trampa del debate regulatorio europeo consiste en leer cada norma como si viviera en una caja separada. No ocurre. En una entidad regulada, la IA se superpone a obligaciones existentes y, en ocasiones, las complica.

AI Act y GDPR: cuando la innovación toca datos personales

Si un sistema de IA trata datos personales, el GDPR entra de inmediato. El artículo 5 impone principios de minimización, limitación de finalidad y exactitud; el artículo 6 exige base jurídica; el artículo 13 y 14 obligan a informar; el artículo 22 añade reglas si hay decisiones exclusivamente automatizadas con efectos jurídicos o significativamente similares; el artículo 25 exige privacidad desde el diseño; y el artículo 35 puede obligar a una evaluación de impacto si el tratamiento entraña alto riesgo.

La fricción práctica aparece en dos puntos. Uno: muchas herramientas generativas o analíticas se alimentan de datos más amplios de lo necesario “porque así rinden mejor”. Eso choca frontalmente con minimización. Dos: incluso cuando no existe decisión exclusivamente automatizada en sentido estricto, la IA puede influir tanto en una decisión humana que la revisión acaba siendo ritual. El GDPR no se impresiona con firmas automáticas de validación. Quiere sustancia.

Si además hay una brecha de seguridad vinculada al sistema de IA, el artículo 33 del GDPR obliga a notificar a la autoridad de control en 72 horas cuando proceda, y el artículo 34 puede activar comunicación a los interesados. La IA no crea un universo paralelo de incidentes.

AI Act y DORA: si la IA soporta procesos financieros críticos, ya no es solo una cuestión ética

DORA, aplicable desde el 17 de enero de 2025, sigue siendo la norma que más cambia el tono de la conversación en servicios financieros. Su artículo 5 pone la responsabilidad en el órgano de dirección respecto al marco de gestión del riesgo TIC. El artículo 9 exige capacidades de detección. El artículo 10 aborda respuesta y recuperación. El artículo 17 trata la clasificación e información de incidentes relacionados con las TIC. Y el artículo 28 entra de lleno en la gestión de riesgo de terceros proveedores de servicios TIC.

¿Qué ocurre cuando la IA forma parte de un proceso cubierto por DORA? Que deja de ser solo un asunto de compliance algorítmico y pasa a ser un componente operativo que debe encajar en resiliencia, continuidad, pruebas, gestión de cambios e inventario de dependencias. Si un motor de IA apoya antifraude en pagos, scoring, priorización de alertas de ciberseguridad o triaje de incidencias, su indisponibilidad, degradación o comportamiento anómalo puede convertirse en incidente TIC. Y si depende de un proveedor cloud o de una API externa, entra el universo de terceros críticos y subcontrataciones en cascada.

Aquí aparece una tensión nada menor. Algunas entidades quieren desplegar IA generativa rápida vía APIs públicas o servicios SaaS muy cómodos. DORA, en cambio, obliga a saber bastante sobre dependencias, continuidad, concentración y salidas contractuales. La frase “es una herramienta de productividad sin criticidad” se desmorona en cuanto esa herramienta termina integrada en operaciones centrales.

AI Act y NIS2: el ángulo de ciberseguridad que muchos siguen tratando como posdata

La Directiva (UE) 2022/2555, NIS2, exige en su artículo 21 medidas de gestión de riesgos de ciberseguridad, incluidas políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y prácticas de higiene básica y formación. Si la entidad está dentro del perímetro NIS2 —como esencial o importante, según transposición nacional y sector—, cualquier despliegue serio de IA debe leerse también desde esta óptica.

La IA introduce nuevos vectores: fuga de datos vía prompts, manipulación de inputs, poisoning, dependencia de repositorios o modelos externos, credenciales expuestas en integraciones, y ampliación de superficie de ataque por conectores y plugins. La seguridad de la cadena de suministro no desaparece porque el proveedor tenga una marca conocida. A veces ocurre justo lo contrario: la dependencia se vuelve más opaca.

En 2026, quien separe “gobierno de IA” de “gobierno de ciberseguridad” está construyendo un problema para sí mismo.

AI Act y eIDAS 2.0: identidad, confianza y atribución

EIDAS 2.0 importa cuando la IA se cruza con identidad digital, servicios de confianza, onboarding remoto, validación documental, firmas o wallet europea. Si una solución de IA participa en verificación de identidad, detección de fraude documental o soporte a decisiones de alta de clientes, la entidad necesita cuidar la atribución de acciones, la integridad de evidencias y la confianza del proceso. No es solo una cuestión de precisión técnica; es una cuestión de validez del flujo y capacidad de demostrar quién hizo qué y con qué base.

AI Act, CSRD y gobierno corporativo: la IA también acaba en el relato de gobernanza

La CSRD no regula la IA como tal, pero sí empuja a las empresas a explicar con más detalle cómo gestionan riesgos, gobernanza y cuestiones materiales. Si la IA afecta a empleados, clientes, derechos fundamentales o control interno, tarde o temprano aparecerá en comités, memorias y preguntas de auditoría. Cuanto más madura sea la gobernanza, menos improvisada parecerá la organización. Parece obvio, pero conviene decirlo: la IA no va a quedarse en el sótano técnico.

Lo que realmente preocupa en banca y seguros: cinco casos de uso y sus riesgos regulatorios

No toda IA plantea el mismo nivel de exposición. El problema es que en servicios financieros la lista de usos aparentemente inocuos se vuelve muy sensible en cuanto se conecta a clientes, fraude o decisiones económicas.

Onboarding y KYC

Usar IA para extraer datos de documentos, detectar incoherencias, asistir al analista o priorizar revisiones puede ahorrar tiempo. También puede introducir errores sistemáticos, tratar más datos de los necesarios o sesgar la revisión. Si el sistema sugiere decisiones o descarta casos de forma automática, la entidad tiene que revisar de cerca el encaje con GDPR art. 22, con los controles de supervisión humana y con la trazabilidad de cada paso.

Scoring, concesión y pricing

Aquí el riesgo sube rápido. Aunque una herramienta se presente como “asistida” y no “decisoria”, si altera de forma material la evaluación de solvencia, prima o condiciones, la entidad entra en terreno muy delicado. Las obligaciones de documentación, explicabilidad práctica y revisión humana dejan de ser teóricas. Además, si el modelo incorpora variables proxy problemáticas, el debate de sesgo no es académico; es litigable.

Fraude y AML

La IA puede mejorar detección de anomalías y priorización de alertas. También puede saturar de falsos positivos o, peor, invisibilizar patrones si la calidad del dato es pobre o el umbral está mal calibrado. En AML, el peligro operativo es delegar demasiado en el modelo y erosionar el juicio experto del analista. En fraude, el peligro es bloquear o retrasar operaciones legítimas sin una lógica suficientemente trazable. En ambos casos, DORA añade la capa de resiliencia si el sistema es crítico para la operación.

Siniestros y gestión de reclamaciones

En seguros, la promesa de eficiencia es enorme: clasificación de documentación, estimación preliminar, detección de fraude, asistencia al perito. El riesgo es convertir una recomendación en una cuasi-decisión sin el nivel de revisión y evidencia necesario. Cuando un cliente impugna, el expediente debe hablar por sí solo. Si lo único que queda es “lo sugirió la herramienta”, mal asunto.

Asistentes generativos internos

Este es el caballo de Troya favorito de 2026. Parecen de bajo impacto porque “solo ayudan a resumir, redactar o buscar”. Luego resulta que acceden a documentación interna, tickets de incidencias, expedientes de clientes, procedimientos de seguridad o análisis jurídicos. Si no se limitan permisos, se segmentan datos y se registra el uso, el asistente termina convirtiéndose en un punto ciego maravilloso para compliance y seguridad. Maravilloso, claro, salvo para quien tiene que explicarlo después.

Controles recomendados: menos manifiesto ético y más disciplina verificable

Las entidades que van en serio están convergiendo hacia un conjunto bastante reconocible de controles. No porque lo diga una consultora con un diagrama elegante, sino porque son los únicos que aguantan una revisión mínimamente dura.

Primero, inventario vivo de sistemas de IA y funcionalidades embebidas, con propietario de negocio, propietario técnico, proveedor, finalidad, datos usados, clasificación preliminar de riesgo y dependencias de terceros. “Vivo” significa actualizado con cambios, no revisado una vez al año para cubrir expediente.

Segundo, proceso de intake previo al despliegue. Ningún caso de uso nuevo debería entrar en producción sin evaluación legal, de privacidad, seguridad, arquitectura y continuidad, proporcionada al riesgo. Si la entidad tiene comité de nuevos productos o de cambios materiales, la IA debe pasar por ahí. Si no pasa, lo que tiene es shadow governance.

Tercero, controles de datos. Minimización, segregación, filtrado de información sensible, reglas de retención, límites de reentrenamiento o reutilización por parte del proveedor, revisión de transferencias internacionales y due diligence de subencargados. En generativa, esto no es accesorio; es el corazón del riesgo.

Cuarto, supervisión humana diseñada, no ceremonial. Hay que definir qué decisiones puede tomar el humano, cuándo debe discrepar, qué señales obligan a escalar, qué muestras se revisan y cómo se mide la dependencia del output. El control humano no vale si se limita a pulsar “aceptar”.

Quinto, logging y versionado. Registro de prompts relevantes cuando proceda, configuración, modelos y versiones usadas, fuentes consultadas, cambios de parámetros, incidencias, overrides humanos y resultados de validación. La trazabilidad parcial es mejor que ninguna, pero no conviene venderla como si fuera total.

Sexto, gestión contractual reforzada con proveedores. Deben revisarse derechos de auditoría o, al menos, evidencias sustitutivas; seguridad; notificación de incidentes; subprocesadores o subproveedores; uso de datos; localización; continuidad; cambios materiales del servicio; y salida. Aquí DORA y AI Act se dan la mano sin pedir permiso.

Séptimo, pruebas. No solo precisión técnica. También pruebas de resiliencia, escenarios de fallo, comportamiento ante inputs maliciosos, calidad de respuestas, tasas de error por tipo de caso, drift y sesgo cuando el uso lo exija. Quien no prueba, en realidad está externalizando la fase beta al cliente o al empleado.

Octavo, formación segmentada y refrescos. Volvemos al artículo 4 porque es el control más transversal y, a la vez, el más fácil de dejar en humo.

Implicaciones para entidades financieras españolas

Para entidades españolas, el AI Act se suma a una agenda regulatoria que ya estaba razonablemente saturada. Banco de España, CNMV y DGSFP no supervisan el AI Act como tal en todos sus ángulos del mismo modo que una autoridad horizontal, pero sí condicionan el tono de la exigencia en gobernanza, outsourcing, continuidad, control interno y protección del cliente. Traducido: nadie va a aceptar que la IA quede fuera de los circuitos de segunda y tercera línea porque “todavía estamos aprendiendo”.

Además, España ha ido moviendo estructura institucional en materia de supervisión algorítmica y gobernanza de IA. Esa evolución importa porque reduce la posibilidad de tratar la norma como una abstracción bruselense. El efecto combinado es claro: quien opere en servicios financieros en España debe prepararse para preguntas cruzadas, no para una única revisión monográfica.

Hay otra derivada muy española y muy terrenal: la presión de costes. Muchas entidades medianas y pequeñas quieren capturar eficiencia con herramientas generativas y analíticas empaquetadas por terceros. Tiene sentido económico. El peligro está en comprarlas como si fueran software de oficina vitaminado, cuando en realidad están alterando controles, datos y dependencias. Ahí es donde los departamentos de compras y negocio suelen pisar el acelerador justo cuando compliance y seguridad piden frenar. Si no se fija un proceso claro, gana la velocidad. Luego llegan los remiendos, que suelen ser más caros.

La objeción habitual: “esto mata la innovación”. No exactamente.

La crítica tiene algo de verdad y bastante de pereza. Sí, cumplir cuesta tiempo, dinero y coordinación. Sí, la fragmentación regulatoria europea puede ser desesperante. Sí, algunas obligaciones del AI Act plantean dudas interpretativas que deberán aclararse con guías, práctica supervisora y jurisprudencia. Todo eso es cierto.

Lo que no es cierto es que la alternativa —desplegar IA sin clasificación, sin trazabilidad, sin controles de datos y sin responsables claros— sea compatible con un sector financiero serio. Eso no es innovación; es trasladar riesgo operacional, legal y reputacional al futuro inmediato. Y el futuro inmediato ya está aquí.

Además, hay un punto que conviene decir sin demasiado romanticismo tecnológico: la regulación también limpia mercado. Obliga a distinguir entre proveedores que pueden documentar controles y proveedores que solo venden entusiasmo. Obliga a separar casos de uso donde la IA aporta productividad real de los que solo generan ruido con facturas elevadas. Y obliga, sobre todo, a que la dirección asuma que adoptar IA no es comprar una licencia, sino rediseñar control.

Qué deberían decidir los comités de dirección esta misma semana

No hace falta un programa faraónico para empezar bien, pero sí decisiones concretas. La primera: nombrar un responsable ejecutivo de coordinación de gobierno de IA, aunque la responsabilidad esté repartida entre varias funciones. Sin un dueño operativo, el tema se disuelve entre legal, tecnología, riesgo y negocio.

La segunda: exigir un inventario inicial con criterio amplio en un plazo corto y realista, incluyendo herramientas embebidas y usos experimentales. Si solo afloran los casos oficialmente aprobados, el ejercicio habrá fracasado.

La tercera: aprobar un proceso de admisión para nuevos casos de uso, con criterios de clasificación, revisión de datos, ciberseguridad, continuidad y contratación. No es burocracia; es control de entrada.

La cuarta: ordenar la revisión de contratos prioritarios con proveedores de IA o con proveedores de software que hayan activado funcionalidades de IA dentro de productos ya contratados. Esto último importa mucho: muchas capacidades de IA están apareciendo por actualización de servicio, no por compra explícita.

La quinta: lanzar formación segmentada con registro de evidencias antes de que alguien pregunte por ella. El artículo 4 no debería pillar a nadie con una presentación genérica de enero y poco más.

La sexta: definir criterios de escalado de incidentes y anomalías relacionados con IA hacia los marcos ya existentes de seguridad, continuidad, privacidad y DORA. La peor respuesta posible ante un incidente de IA es abrir un circuito paralelo y descoordinado.

Lo que viene después de este 2 de agosto

La activación de este hito no cierra la historia; la abre. Quedan por delante desarrollos de supervisión, práctica interpretativa, ajustes contractuales y, previsiblemente, bastante confusión interesada de mercado. Algunos vendedores inflarán el miedo regulatorio para vender “AI governance” en spray. Otros minimizarán el problema hasta que ya sea demasiado obvio. Ni una cosa ni la otra ayuda.

Lo útil en 2026 es mucho más prosaico. Saber qué IA tienes. Saber dónde toca datos y decisiones. Saber qué depende de terceros. Saber quién la supervisa. Y poder demostrarlo con evidencias razonables. Parece poco glamuroso. También es exactamente lo que separa a una entidad que adopta IA con criterio de otra que la adopta con fe.

Europa, para bien o para mal, ha elegido regular la IA no solo como tecnología sino como práctica organizativa. El 2 de agosto deja una enseñanza bastante nítida: el debate ya no va de si el AI Act gusta más o menos. Va de quién llega a esta fase con gobierno real y quién sigue improvisando con una política bonita en PDF.

Y en el sector financiero, improvisar con tecnología que afecta a clientes, decisiones y operaciones críticas suele salir carísimo. A veces en multas. A veces en incidentes. A veces en algo peor: pérdida de control sin darte cuenta hasta que ya es portada.