Cyber
Modelos de IA de propósito general en 2026: qué exige el AI Act a proveedores y qué no puede ignorar el cliente
Por Redacción CyberComplianceAI27 min lectura
Ultima revision
8 de julio de 2026
Imagen generada por IAUltima revision
8 de julio de 2026
Imagen generada por IALa conversación sobre IA se ha pasado dos años obsesionada con la aplicación visible —el copiloto, el asistente, el chatbot con demasiada autoestima— y ha dejado en segundo plano la pieza que más complica la gobernanza: el modelo de propósito general que alimenta todo lo demás.
Ahí está el cambio real del AI Act en 2026. La Unión Europea no se limita a regular sistemas de IA de alto riesgo desplegados en banca, recursos humanos o infraestructuras críticas. También impone obligaciones directas a los proveedores de general-purpose AI models (GPAI) y, cuando esos modelos cruzan el umbral de riesgo sistémico, endurece el listón con requisitos de evaluación, mitigación y ciberseguridad. Dicho en castellano llano: si tu entidad compra, integra, ajusta o redistribuye un modelo fundacional, ya no basta con pedir una bonita hoja comercial y una promesa de “IA responsable”.
La arquitectura jurídica relevante está en el Reglamento (UE) 2024/1689, el AI Act. Para GPAI, el núcleo está en los artículos 51 a 56. El artículo 51 define qué es un modelo de IA de propósito general; el artículo 52 fija las obligaciones de los proveedores de GPAI; el artículo 53 añade obligaciones reforzadas para los proveedores de modelos GPAI con riesgo sistémico; el artículo 55 trata la representación autorizada; y el artículo 56 crea un mecanismo de códigos de buenas prácticas que, siendo voluntario en su forma, va a funcionar en la práctica como el atajo de mercado hacia la presunción de cumplimiento. La Comisión Europea, además, ha dejado claro en su material explicativo que las obligaciones para GPAI tienen un calendario propio dentro del despliegue gradual del AI Act. Eso importa mucho porque en 2026 ya no estamos en fase teórica: estamos en fase de compra, de due diligence y de reparto contractual de responsabilidades.
El problema para CISOs y responsables de cumplimiento es menos filosófico y más incómodo: muchas de las obligaciones críticas recaen formalmente sobre el proveedor del modelo, pero el riesgo regulatorio, operativo y reputacional se desplaza al cliente si compra a ciegas. Y comprar a ciegas aquí significa integrar un modelo sin documentación técnica utilizable, sin información suficiente para cumplir transparencia aguas abajo y sin garantías mínimas de gestión de incidentes o vulnerabilidades. Luego llega el comité de riesgos y pregunta quién validó esto. Silencio administrativo.
Hasta hace poco, muchas organizaciones europeas seguían pensando la regulación de IA con una lógica heredada del software clásico: el proveedor del producto final es quien responde, y el componente subyacente queda más o menos escondido en la cadena. El AI Act rompe esa comodidad. Introduce una capa regulatoria específica para modelos GPAI porque entiende algo bastante obvio, aunque el mercado haya tardado en admitirlo: cuando un mismo modelo se reutiliza en cientos o miles de casos de uso, los riesgos no nacen únicamente en la interfaz final. Nacen en la arquitectura, en los datos de entrenamiento, en las limitaciones del modelo y en la imposibilidad práctica de entender su comportamiento si el proveedor se limita a decir “confíe en nosotros”.
El artículo 3 del AI Act contiene definiciones generales, pero el punto operativo para este debate está en el artículo 51: un modelo de IA de propósito general es un modelo entrenado con grandes cantidades de datos, con una generalidad significativa y capaz de realizar de forma competente una amplia gama de tareas distintas, integrable en múltiples sistemas o aplicaciones aguas abajo. Esto excluye, por ejemplo, muchos modelos estrechamente sectoriales o desarrollos hechos para una sola función muy concreta. Incluye, en cambio, a los grandes modelos fundacionales que hoy se usan para generación de texto, código, imágenes, análisis documental o razonamiento multimodal.
Que el modelo sea “de propósito general” no significa automáticamente que sea “de riesgo sistémico”. Esa segunda etiqueta la reserva el AI Act a los modelos GPAI cuyas capacidades o alcance pueden tener un impacto amplio en el mercado europeo y en la seguridad pública. El artículo 51 conecta esa calificación con criterios objetivos y con metodología que la Comisión puede desarrollar, incluyendo umbrales vinculados a la potencia de cómputo usada en el entrenamiento. La Comisión Europea ha explicado ya que la presunción inicial de riesgo sistémico se activa para modelos muy avanzados, medidos entre otros elementos por el cómputo total de entrenamiento, con el umbral conocido de 10^25 FLOPs. No es una cifra ornamental. Es el punto en el que Bruselas está diciendo: aquí no hablamos de una API útil; hablamos de una infraestructura de capacidad con externalidades serias.
Para un banco, una aseguradora o una fintech, esto tiene una consecuencia inmediata. Tu mapa de terceros ya no debe distinguir solo entre “proveedor SaaS”, “outsourcer cloud” y “proveedor crítico”. Debe identificar si el componente de IA subyacente es un GPAI normal o un GPAI con riesgo sistémico, porque de esa clasificación dependerán la documentación exigible, el nivel de escrutinio y la probabilidad de que aparezcan futuras exigencias de supervisión. Si tu contrato solo menciona “servicio de IA generativa” y omite el modelo concreto, estás gestionando riesgo con los ojos cerrados.
El artículo 52 del AI Act es el corazón práctico para los proveedores de modelos GPAI. No les exige magia ética. Les exige cosas bastante más útiles: documentación técnica, información para integradores, cumplimiento del derecho de autor de la UE y un resumen suficientemente detallado del contenido usado para entrenamiento. El mercado ha reaccionado a esto como si fuera una molestia burocrática. En realidad, es una de las pocas partes del AI Act diseñadas para arreglar un problema muy concreto: la opacidad casi total con la que se estaban integrando modelos fundacionales en procesos críticos.
Primero, documentación técnica. El proveedor debe elaborar y mantener documentación técnica del modelo que permita a la Oficina de IA y a las autoridades nacionales entender el cumplimiento del Reglamento, y también debe poner a disposición de los proveedores de sistemas de IA que integren ese modelo la información y documentación necesarias para que estos cumplan sus propias obligaciones. Aquí está el quid. Si tu entidad construye un sistema de IA sobre un modelo de tercero, tu capacidad de cumplir con las exigencias aplicables al sistema final depende materialmente de lo que ese tercero te entregue.
¿Qué debería contener esa documentación, aterrizada a una due diligence seria? Como mínimo, descripción del modelo, finalidad prevista y no prevista, limitaciones conocidas, requisitos de integración, evaluaciones realizadas, rendimiento relevante por categorías de tareas, dependencias técnicas, medidas de mitigación implementadas y condiciones de uso que eviten despliegues incompatibles. Si el proveedor te entrega cuatro páginas de marketing con alguna referencia genérica a “guardrails”, eso no es documentación técnica; eso es propaganda con tipografía amable.
Segundo, información para permitir el cumplimiento aguas abajo. Este punto es especialmente sensible para entidades sujetas además a DORA, GDPR o NIS2. Un proveedor de sistema de IA que integre un GPAI necesita conocer limitaciones, condiciones y riesgos residuales para diseñar sus propios controles de supervisión humana, calidad de datos, exactitud, robustez o transparencia. Sin esa información, el integrador queda jurídicamente expuesto y operativamente desarmado. No es casualidad que el AI Act haya intentado resolver esta asimetría a nivel de modelo, no solo de producto final.
Tercero, política de cumplimiento del derecho de autor de la Unión y resumen suficientemente detallado del contenido utilizado para el entrenamiento. Este punto no es una nota al pie para abogados de propiedad intelectual. Afecta a riesgo litigioso, a uso comercial y a reputación. Si una entidad despliega un sistema basado en un modelo con disputas serias sobre entrenamiento no autorizado, la cuestión no se queda en el proveedor. Puede contaminar decisiones de procurement, contratos con clientes y apetito de riesgo del consejo. El AI Act no obliga a publicar el dataset entero, pero sí a contar lo suficiente para que el mercado y los titulares de derechos entiendan la naturaleza de lo usado. Es un equilibrio imperfecto, sí. También era insostenible la caja negra anterior.
Cuarto, cooperación con la autoridad. Esto incluye facilitar información a la Comisión y a la Oficina de IA cuando sea requerida. Desde la perspectiva del cliente, la lectura práctica es clara: si el proveedor no tiene capacidad interna para responder a peticiones regulatorias serias, probablemente tampoco la tiene para sostener un programa de gobernanza maduro. Hay vendedores excelentes haciendo demos y equipos sorprendentemente pequeños manteniendo el backend regulatorio. Conviene saber en cuál de los dos mundos vive tu proveedor.
El artículo 53 introduce obligaciones reforzadas para los proveedores de modelos GPAI con riesgo sistémico. Aquí el AI Act se pone bastante menos complaciente. Ya no basta con documentar y explicar. Hay que evaluar, probar, mitigar, monitorizar y reportar.
La primera obligación relevante es realizar evaluaciones del modelo conforme a protocolos y herramientas estandarizadas y, cuando proceda, incluyendo pruebas adversariales para identificar y mitigar riesgos sistémicos. Para un CISO, esto importa porque convierte la seguridad de modelos en algo más parecido a una disciplina de control continuo que a un simple test previo al despliegue. No hablamos solo de sesgo o alucinaciones. Hablamos también de abuso para ciberataques, escalado de desinformación, generación de malware, manipulación automatizada o pérdida de control sobre capacidades emergentes. Algunas de estas amenazas siguen siendo difíciles de cuantificar. Eso no las vuelve opcionales.
La segunda obligación es evaluar y mitigar posibles riesgos sistémicos a escala de la Unión, incluidos sus orígenes y efectos. El AI Act no restringe el análisis al daño directo causado por el proveedor. Le pide considerar externalidades amplias. Aquí se nota que Bruselas ha tomado nota de una realidad industrial incómoda: los modelos más potentes se convierten en infraestructura cognitiva compartida. Si fallan, fallan en cadena.
La tercera obligación es hacer seguimiento, documentación y notificación de incidentes graves y posibles medidas correctoras. Aunque el régimen preciso de notificación se articula dentro del propio AI Act y futura práctica supervisora, el paralelismo con otras normativas europeas es evidente. Si vienes de GDPR art. 33, de DORA para incidentes graves relacionados con las TIC o de NIS2 art. 23 sobre notificación de incidentes significativos, la lógica te resultará familiar: el regulador ya no acepta enterarse por la prensa. Tampoco debería hacerlo el cliente.
La cuarta obligación es garantizar un nivel adecuado de ciberseguridad para el modelo y su infraestructura física. Este punto merece más atención de la que recibe. El AI Act está reconociendo algo que demasiados programas de cumplimiento separan artificialmente: la seguridad del modelo no es solo control de acceso a la API. Incluye protección del pipeline de entrenamiento, integridad de pesos, seguridad de datos, protección frente a extracción del modelo, manipulación de inferencia, abuso de plugins o herramientas conectadas y seguridad del entorno donde el modelo se desarrolla y despliega. Si alguien sigue viendo la IA como un riesgo exclusivamente “ético”, va con retraso de una temporada.
La consecuencia práctica para el usuario empresarial es que un proveedor de GPAI con riesgo sistémico debería poder enseñarte un programa serio de evaluación y seguridad. No necesariamente todo, porque habrá secretos industriales y límites razonables, pero sí evidencia suficiente para una valoración de terceros. Si no puede hacerlo, hay dos opciones: o su madurez es baja, o su departamento legal ha decidido que decir poco sale gratis. En 2026, ninguna de las dos es buena noticia.
El AI Act entró en vigor el 1 de agosto de 2024, pero no se aplica de golpe. Su despliegue es escalonado. La Comisión Europea ha explicado este calendario de forma consistente: algunas prohibiciones empezaron a aplicarse antes; las obligaciones para GPAI tienen su propia fecha de aplicación; y los requisitos completos para sistemas de alto riesgo llegan más tarde. Para 2026, esto ya no es una cronología de PowerPoint: es planificación presupuestaria y contractual.
La referencia operativa que más interesa aquí es que las obligaciones para modelos GPAI empezaron a ser aplicables 12 meses después de la entrada en vigor, es decir, en 2025. Este año, 2026, ya estamos en fase de ejecución y prueba de mercado. Quien siga tratando GPAI como una conversación prematura simplemente va tarde. Y los contratos firmados en 2024 o principios de 2025 sin anexos regulatorios específicos de AI Act probablemente necesitan revisión.
Además, la Oficina Europea de IA, creada dentro de la Comisión, ya no es una promesa institucional. Es el centro de coordinación para supervisión de GPAI y desarrollo de guías, plantillas y códigos de buenas prácticas. Eso significa una cosa muy concreta: la interpretación de obligaciones va a ganar densidad. En otras palabras, el margen para esconder la falta de preparación detrás del “la norma aún no está clara” se estrecha. Seguirá habiendo zonas grises, claro. Pero la gran coartada de la niebla regulatoria empieza a agotarse.
Existe una tentación bastante común en consejos de administración y comités de compras: asumir que si el modelo lo suministra una gran tecnológica, el problema regulatorio queda externalizado. Ojalá funcionara así. No funciona.
El AI Act impone obligaciones directas al proveedor del modelo GPAI, sí. Pero el usuario que integra ese modelo en un sistema propio sigue asumiendo deberes por otras vías. Si el sistema final entra en una categoría de alto riesgo del anexo III, aparecerán obligaciones específicas para el proveedor o desplegador de ese sistema. Si la salida del modelo implica tratamiento de datos personales, seguirá aplicando el GDPR, incluyendo principios del artículo 5, base jurídica del artículo 6, información del artículo 13 o 14 y, en su caso, evaluaciones de impacto del artículo 35. Si la entidad es financiera, DORA añade obligaciones de gestión del riesgo TIC, terceros y pruebas de resiliencia. Si presta servicios esenciales o importantes bajo NIS2, el artículo 21 exige medidas técnicas, operativas y organizativas apropiadas. El modelo puede ser de otro; el incidente, la reclamación del cliente o la inspección sectorial serán muy tuyos.
Hay un punto que muchas organizaciones siguen pasando por alto. Un mismo modelo GPAI puede alimentar varios casos de uso con perfiles regulatorios muy distintos: un asistente interno para redactar correos, un motor para resumir llamadas de clientes, un sistema de apoyo en concesión de crédito o una herramienta de detección de fraude. El proveedor del modelo ofrece una base común. La carga de gobernanza cambia radicalmente según el uso. Quien confunde esas capas termina aplicando controles livianos donde no toca o montando burocracia excesiva donde no hace falta. Ninguna de las dos cosas sale barata.
Si tu organización compra o integra GPAI, la discusión ya no puede quedarse en “firmemos la DPA” o “pasemos el cuestionario de terceros”. Hace falta una diligencia dividida por funciones. Y no, no es burocracia por amor al arte. Es la única forma de no descubrir demasiado tarde que el proveedor no puede darte lo que el regulador sí te va a pedir.
Procurement debería exigir, antes de la firma, al menos cinco bloques documentales.
Primero, identificación precisa del modelo o familia de modelos, con versión, modalidad y condiciones de actualización. Muchos contratos siguen describiendo el servicio, no el modelo. Eso es insuficiente si el comportamiento del sistema puede cambiar con una actualización silenciosa.
Segundo, el paquete de documentación técnica y de integración alineado con el artículo 52. No hace falta que el proveedor entregue secretos comerciales completos, pero sí una base bastante para evaluación de riesgos y cumplimiento aguas abajo.
Tercero, detalle de subencargados, infraestructura de hosting, ubicación de procesamiento y uso de datos del cliente para entrenamiento, afinado o mejora del servicio. Aquí convergen AI Act, GDPR y, en algunos casos, secreto profesional o regulación sectorial.
Cuarto, compromiso contractual sobre notificación de incidentes, cambios materiales del modelo, deprecación, restricciones de uso y cooperación regulatoria. Si esto queda en una cláusula vaga de “reasonable efforts”, el proveedor está comprando flexibilidad a costa de tu incertidumbre.
Quinto, derechos de auditoría o al menos de revisión documental reforzada, con periodicidad y alcance definidos. A veces no obtendrás auditoría técnica plena, sobre todo con grandes hyperscalers o proveedores de frontera. Pero sí deberías conseguir evidencia alternativa: informes de terceros, certificaciones relevantes, resúmenes de pruebas de seguridad, resultados de red teaming y compromisos de remediación.
El equipo de cumplimiento necesita responder tres preguntas simples, que en la práctica no lo son tanto.
Una: ¿estamos ante un mero uso de una herramienta genérica o estamos construyendo un sistema de IA sujeto a obligaciones propias? Dos: ¿qué información del proveedor necesitamos conservar para demostrar diligencia? Tres: ¿qué afirmaciones de marketing del proveedor podrían volverse en nuestra contra si las repetimos a clientes o supervisores?
La evidencia útil no es un folleto con principios éticos. Es un repositorio con: clasificación del caso de uso; evaluación de si entra o no en alto riesgo; ficha del modelo empleado; documentación del proveedor; análisis de tratamiento de datos personales; restricciones de uso; validación de transparencia al usuario cuando proceda; evaluación de impacto en protección de datos si aplica; y registro de aprobaciones internas. Si la empresa no puede reunir esto en 48 horas ante una inspección o requerimiento del supervisor, su gobernanza de IA sigue siendo decorativa.
Compliance también debería revisar un punto delicado del artículo 52: el resumen suficientemente detallado del contenido utilizado para entrenamiento. No porque vaya a leer corpus por corpus, sino porque ese resumen ayuda a estimar exposición a litigios de copyright, riesgos de contaminación por datos no aptos y coherencia con políticas internas de uso de IA. Hay sectores —medios, educación, servicios profesionales, salud— donde esta cuestión no es académica. Es comercial.
En muchas organizaciones, la evaluación de seguridad de proveedores de IA sigue centrada en controles cloud clásicos: IAM, cifrado, logging, BCP/DR, vulnerabilidad de la plataforma. Todo eso sigue siendo necesario. Ya no es suficiente.
La capa modelo exige preguntas adicionales. ¿Existe protección frente a extracción o robo del modelo? ¿Qué controles hay contra abuso automatizado de la API? ¿Cómo se gestionan los prompts y outputs en términos de retención y segregación? ¿Qué defensas hay frente a inyección de prompts, herramientas conectadas inseguras o exfiltración vía contexto? ¿Se prueban comportamientos peligrosos con red teaming? ¿Hay procedimientos para retirada o contención cuando aparece un fallo material del modelo? ¿El proveedor ha definido incidentes específicos de IA o sigue metiendo todo en el cajón de “incidente de aplicación”?
Este último detalle revela mucho. Un proveedor que no ha separado conceptualmente incidentes de modelo de incidentes de infraestructura probablemente tampoco tiene telemetría ni playbooks maduros para gestionar el primero. Y ahí es donde una entidad regulada se puede llevar la sorpresa.
El AI Act no vive en una urna. Su impacto real aparece cuando se cruza con otras normas ya operativas.
Si un modelo GPAI procesa datos personales en prompts, contexto, archivos adjuntos o salidas enriquecidas, el GDPR sigue completamente vivo. El proveedor del modelo puede ser encargado, corresponsable o incluso responsable según el diseño del servicio y el uso de datos para fines propios. Esa calificación jurídica importa, pero más importa algo previo: entender qué hace realmente el proveedor con los datos del cliente.
El artículo 5 del GDPR exige limitación de finalidad, minimización y exactitud; el artículo 28 impone condiciones estrictas para encargados; el artículo 32 obliga a medidas de seguridad apropiadas; y el artículo 35 puede forzar una EIPD cuando haya alto riesgo para derechos y libertades. Un asistente documental conectado a expedientes de clientes o historiales laborales puede activar varias de estas piezas a la vez. Si el equipo de IA insiste en que “no almacenamos nada” pero el proveedor conserva prompts 30 días para detección de abuso, ya tienes un tratamiento que documentar. Si además usa esos datos para reentrenamiento salvo opt-out, la conversación cambia de nivel.
El AI Act aporta una capa útil aquí: obliga al proveedor de GPAI a dar información para cumplimiento aguas abajo. Aprovecharla bien puede mejorar la posición GDPR del cliente. Ignorarla es regalarse problemas.
Para entidades financieras, DORA ha dejado una enseñanza elemental: si una dependencia tecnológica es relevante para servicios críticos, debe gobernarse como tal aunque el negocio la vea como innovación. Los artículos 5 a 16 cubren el marco de gestión del riesgo TIC; los artículos 28 a 30 se centran en terceros proveedores de servicios TIC. Un proveedor de GPAI encaja muchas veces en esa categoría funcional, sobre todo cuando el modelo soporta procesos internos clave o servicios a clientes.
La dificultad está en que no siempre se contrata directamente al proveedor del modelo. A veces se accede vía una plataforma, un integrador o una suite empresarial que subcontrata el motor. Resultado: la dependencia existe, pero queda difuminada. Mala idea. DORA obliga a registrar y clasificar proveedores TIC, identificar funciones críticas o importantes soportadas y asegurar cláusulas contractuales específicas. Si la pieza de IA subyacente puede afectar disponibilidad, integridad, confidencialidad o continuidad operativa, debe entrar en esa conversación.
Además, cuando un fallo del modelo provoque un incidente operativo serio —por ejemplo, bloqueo de procesos de atención, fuga de información por respuestas indebidas o automatización errónea de decisiones— la organización tendrá que valorar también obligaciones de clasificación y notificación de incidentes bajo DORA. El proveedor puede llamarlo “degradación temporal del servicio”. El supervisor quizá lo vea de otra manera.
NIS2, en su artículo 21, exige medidas de gestión de riesgos de ciberseguridad, incluyendo seguridad de la cadena de suministro y de la relación con proveedores. Los modelos GPAI intensifican ese reto porque añaden una capa técnica difícil de auditar y muy dependiente de actualizaciones continuas. Un proveedor puede cambiar filtros, pesos, latencia, funcionalidades o conectores con impacto material en el riesgo sin que el cliente vea el código ni el proceso de entrenamiento.
Por eso la diligencia NIS2 sobre IA no puede limitarse al cuestionario clásico de terceros. Necesita mecanismos de vigilancia continua: seguimiento de cambios del servicio, reevaluación de casos de uso, validación recurrente de resultados críticos y planes de fallback si el modelo deja de ser aceptable. Quien dependa de un único proveedor de GPAI para funciones operativas sensibles y no tenga salida razonable está incubando riesgo de concentración. La palabra suena aburrida; el incidente asociado no suele serlo.
Los contratos de proveedores de IA suelen estar llenos de garantías cuidadosamente pequeñas. Es comprensible. Nadie quiere asumir responsabilidad abierta por un modelo probabilístico desplegado a escala. El problema empieza cuando el cliente interpreta esa prudencia contractual como sustituto de diligencia técnica y regulatoria.
Una cláusula que diga que el proveedor “busca alinear sus prácticas con la legislación aplicable” vale poco si no se acompaña de anexos documentales, obligaciones de notificación, compromisos sobre datos y derecho a recibir información suficiente para cumplimiento aguas abajo. El artículo 52 no se satisface con intenciones. Requiere output documental.
También conviene vigilar una asimetría frecuente: el proveedor se reserva el derecho de cambiar el modelo, sus proveedores subyacentes o sus políticas de uso con simple notificación electrónica, mientras que el cliente asume restricciones severas y responsabilidad casi plena sobre el uso final. Si el modelo cambia materialmente y el caso de uso es sensible, la organización debería poder reevaluar el servicio, suspenderlo o resolver el contrato sin penalización significativa. No siempre se conseguirá. Pero si ni siquiera se intenta, luego no vale fingir sorpresa.
Otra cuestión espinosa es la indemnidad por reclamaciones de propiedad intelectual. Dado que el AI Act obliga a una política de cumplimiento de derecho de autor de la UE y a un resumen del contenido de entrenamiento, los clientes deberían usar esa base para negociar garantías más concretas, especialmente cuando el contenido generado se usa comercialmente o se incorpora a productos propios. No es lo mismo usar un asistente interno de borradores que construir una oferta de contenido automatizado para clientes finales. El nivel de exposición cambia. El contrato también debería hacerlo.
Una gobernanza madura no consiste en crear un comité de IA con nombre rimbombante y actas impecables que luego aprueba cualquier herramienta porque “la competencia ya la usa”. Consiste en decisiones trazables y controles proporcionados.
La primera señal de madurez es el inventario. La organización sabe qué modelos usa, en qué casos de uso, con qué datos, bajo qué proveedor y con qué dependencias subyacentes. Parece básico. No lo es. En 2026 siguen apareciendo pilotos convertidos en producción por desgaste, sin dueño claro y con acceso a información sensible.
La segunda es la clasificación por riesgo. No todos los usos de GPAI merecen el mismo control. Un asistente para brainstorming de marketing no necesita la misma revisión que un sistema para resumir documentación de siniestros, asistir a analistas de fraude o apoyar decisiones de admisión de clientes. La clasificación debe mirar impacto regulatorio, datos tratados, criticidad operativa y grado de autonomía.
La tercera es la evidencia reutilizable. Si cada evaluación de IA empieza desde cero, la empresa no tiene un programa; tiene heroísmo administrativo. Hace falta un expediente estándar por proveedor/modelo y un expediente por caso de uso, con componentes modulares que compras, legal, privacidad, seguridad y negocio puedan reutilizar.
La cuarta es la vigilancia post-contratación. Los modelos cambian. Las políticas de uso cambian. Los límites de rate, las funciones de memoria, el uso de datos del cliente y los conectores a herramientas externas cambian. Un proveedor que hoy es aceptable puede dejar de serlo tras una actualización relevante. La gobernanza madura no termina en la firma.
La quinta es el plan de contingencia. ¿Qué pasa si el proveedor suspende una capacidad clave, si aparece una vulnerabilidad seria, si la autoridad cuestiona la base de entrenamiento o si una auditoría interna concluye que el caso de uso no es defendible? Si la respuesta es “ya veremos”, la organización no tiene resiliencia; tiene fe.
En banca, pagos, seguros y gestión de inversiones, el uso de GPAI se está colando sobre todo por cuatro puertas: asistentes internos de productividad, análisis documental, atención al cliente y apoyo a funciones de control. Ninguna es inocente.
Un asistente interno conectado a políticas, correos o documentación contractual puede tratar datos personales, secretos empresariales e información regulada. Un motor de análisis documental para onboarding o siniestros puede influir materialmente en decisiones sujetas a revisión humana y a obligaciones de trazabilidad. Un chatbot de atención al cliente puede activar exigencias de transparencia frente al usuario y contaminar registros si resume o clasifica interacciones de forma errónea. Y un copiloto para compliance o ciberseguridad puede introducir alucinaciones peligrosas precisamente en equipos que necesitan precisión, no entusiasmo algorítmico.
Para entidades supervisadas por Banco de España, CNMV o DGSFP, el impacto no llega solo por el AI Act. Llega también por gobernanza interna, outsourcing, continuidad, seguridad y deber de control sobre terceros. La autoridad sectorial no necesita una norma específica sobre “copilotos” para preguntarte por qué una función relevante depende de un modelo externo que no has evaluado bien. De hecho, si algo enseñan los supervisores financieros es que suelen empezar por la pregunta más sencilla: quién aprobó esto y con qué evidencia.
En España hay además una sensibilidad práctica hacia la trazabilidad documental. Quien pretenda justificar un uso relevante de GPAI con capturas de pantalla, correos sueltos y una política interna de una página se está preparando un mal rato. Aquí conviene documentar mejor desde el principio, no por devoción al archivo, sino porque reconstruir decisiones después de un incidente cuesta bastante más.
Primer error: creer que el tamaño del proveedor sustituye el análisis. Un gigante tecnológico puede ofrecer más recursos y madurez que un actor pequeño. También puede imponer condiciones estándar difíciles de negociar y opacidad suficiente para dejar al cliente corto de evidencia.
Segundo error: tratar todos los usos de GPAI como si fueran de bajo impacto porque “no automatizan la decisión final”. Ese argumento se ha usado demasiado. El hecho de que exista revisión humana no elimina riesgo si la herramienta orienta, resume, prioriza o descarta información de manera material.
Tercer error: mezclar en una sola evaluación el modelo y el caso de uso. Son capas distintas. El proveedor del modelo puede cumplir razonablemente con el artículo 52 o 53 y, aun así, tu despliegue ser inviable por privacidad, por sesgo en datos internos o por criticidad operativa.
Cuarto error: olvidarse del dato de entrada. Buena parte del riesgo regulatorio no nace en el output espectacular que enseña la demo, sino en los prompts, contextos y documentos que el usuario sube sin filtro. Si no has definido qué datos pueden introducirse, qué registros se conservan y qué salidas pueden reutilizarse, la herramienta ya gobierna a tus usuarios más de lo que tú la gobiernas a ella.
Quinto error: no preparar una posición corporativa sobre modelos open source y modelos cerrados. El AI Act no exime sin más cualquier variante abierta. La gobernanza cambia según quién distribuya el modelo, quién lo modifique y cómo se integre. El ahorro aparente de coste puede convertirse en deuda operativa si nadie asume actualizaciones, pruebas y seguridad del stack.
La fase de debate abstracto ya pasó. En 2026, la pregunta sensata no es si una organización europea va a usar modelos de IA de propósito general. La mayoría ya los usa o los va a usar de algún modo. La pregunta correcta es mucho más prosaica: ¿qué evidencia tienes para demostrar que el proveedor cumple sus obligaciones de GPAI, que tú puedes cumplir las tuyas aguas abajo y que el modelo no se ha colado en un proceso crítico sin barandillas suficientes?
El AI Act, en su parte de GPAI, no resuelve todas las opacidades del mercado. Ni de lejos. Tampoco elimina la asimetría entre el puñado de proveedores de frontera y los clientes que dependen de ellos. Pero sí crea un mínimo regulatorio que las empresas inteligentes pueden usar a su favor. El artículo 52 sirve para exigir documentación e información que antes el proveedor podía negar con total normalidad. El artículo 53 da base para pedir más cuando el modelo es sistémico. Y el despliegue institucional de la Oficina de IA deja claro que esta capa no se va a quedar en literatura europea de alto nivel.
Si eres CISO o responsable de cumplimiento, la tarea incómoda es también la más rentable: obligar a que cada iniciativa con GPAI aterrice en inventario, clasificación, evidencia, contrato y control continuo. Sin eso, la IA generativa no es una palanca de eficiencia. Es un tercero crítico mal catalogado, con capacidad de tocar datos, procesos y decisiones, envuelto en una UX tan pulida que a veces parece inocente. No lo es.
Y conviene recordarlo ahora, cuando aún se puede negociar, antes de que un proveedor cambie el modelo, aparezca un incidente serio o llegue un requerimiento regulatorio pidiendo exactamente la documentación que nadie se molestó en pedir al principio.
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en AI Act: clasificación de riesgo de tus sistemas de IA y obligaciones por nivel.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment AI Act.
El Reglamento de IA de la UE clasifica los sistemas por nivel de riesgo: inaceptable (prohibido), alto riesgo (sujeto a obligaciones estrictas), riesgo limitado (transparencia) y riesgo mínimo.
Gestión de riesgos, gobernanza de datos, documentación técnica, registro de actividad, transparencia, supervisión humana y robustez/ciberseguridad, además de evaluación de conformidad.
El Reglamento entró en vigor en 2024 con una aplicación escalonada: las prohibiciones aplican antes y las obligaciones de alto riesgo se aplican de forma progresiva en los años siguientes.