Imagen generada por IALa Unión Europea ya tiene bastante con desplegar el AI Act. Pues bien: este año se añade otra pieza que no conviene despachar como ruido institucional. El Parlamento Europeo aprobó el 11 de marzo de 2026 su resolución legislativa sobre la celebración, en nombre de la Unión, del Convenio Marco del Consejo de Europa sobre Inteligencia Artificial, Derechos Humanos, Democracia y Estado de Derecho, publicada en el Diario Oficial de la UE el 26 de agosto de 2026 como OJ C/2026/4028. Traducido al idioma que entienden compliance, legal y los equipos de producto: la conversación regulatoria sobre IA en Europa ya no va solo de seguridad del sistema y clasificación de riesgos; va también de legitimidad institucional, tutela de derechos y rendición de cuentas en despliegues reales.
El dato interesante no es que Europa tenga “otra norma sobre IA”. Europa siempre encuentra una forma de añadir otra capa normativa. Lo relevante es otra cosa: el Convenio del Consejo de Europa y el AI Act no compiten. Se pisan un poco, sí, pero juegan en planos distintos. El AI Act fija obligaciones operativas detalladas para proveedores, importadores, distribuidores, deployers y organismos notificados. El Convenio introduce un marco más amplio de salvaguardas públicas y privadas centrado en derechos fundamentales, procesos democráticos y Estado de Derecho. Juntos endurecen el perímetro de gobernanza. Y eso tiene efectos inmediatos para banca, seguros, fintech, salud digital y administración electrónica.
Si tu organización había decidido que el trabajo de IA consistía en etiquetar casos de uso como “alto riesgo” o “riesgo limitado” y luego rellenar una matriz, toca revisar esa comodidad. El nuevo paisaje europeo exige demostrar algo más incómodo: no solo que el sistema cumple controles técnicos, sino que la institución puede explicar por qué lo usa, cómo limita daños, qué vías de recurso ofrece y quién responde si el algoritmo se equivoca. Parece obvio. En la práctica, no lo es en absoluto.
Mi tesis es simple: el Convenio del Consejo de Europa convierte la gobernanza de IA en un asunto menos técnico y más constitucional. Y eso complica, con razón, la vida de las entidades reguladas.
Durante meses muchas empresas han tratado el AI Act como si fuera un reglamento de producto con anexos largos y una lista fastidiosa de controles. Ya era una lectura pobre. Con la adhesión de la UE al Convenio, esa lectura se queda directamente corta. El mensaje político-jurídico es claro: en 2026 no basta con construir IA segura; hay que demostrar que su uso es compatible con derechos humanos, procesos democráticos y el Estado de Derecho. Es un salto cualitativo.
La tentación corporativa será decir que esto ya estaba implícito en la Carta de Derechos Fundamentales, en el GDPR, en la jurisprudencia del TJUE y en el propio AI Act. Formalmente, algo de razón hay. Pero precisamente ahí está la trampa. Cuando un principio disperso se consolida en un instrumento internacional específico, deja de ser una abstracción elegante y pasa a ser una expectativa de supervisión. La diferencia entre “sí, ya lo sabemos” y “enséñemelo por escrito” suele aparecer el día de la auditoría, la inspección o el litigio.
El Convenio no vuelve irrelevante el AI Act. Lo vuelve insuficiente como única brújula. Y para sectores como banca o seguros, donde ya conviven DORA, GDPR, NIS2 en su trasfondo sectorial y exigencias prudenciales nacionales, el resultado es un mapa de control bastante menos cómodo de lo que muchos comités de dirección querrían admitir.
El documento publicado en EUR-Lex corresponde a la resolución legislativa del Parlamento Europeo de 11 de marzo de 2026 sobre el proyecto de decisión del Consejo relativo a la celebración, en nombre de la Unión Europea, del Convenio Marco del Consejo de Europa sobre Inteligencia Artificial, Derechos Humanos, Democracia y Estado de Derecho. La publicación oficial en el Diario Oficial de la Unión Europea llegó el 26 de agosto de 2026 bajo la referencia C/2026/4028.
No estamos ante una propuesta académica ni ante un informe de intenciones. Estamos ante un paso institucional en el proceso de vinculación de la UE a un tratado paneuropeo diseñado para establecer principios comunes sobre el ciclo de vida de los sistemas de IA y sus efectos sobre personas, instituciones y procesos públicos. El Consejo de Europa no es la UE, conviene recordarlo porque aún se confunden en demasiadas salas de reuniones, pero su peso jurídico y político en materia de derechos fundamentales está lejos de ser decorativo.
La importancia práctica del movimiento depende de entender dos planos a la vez.
Primero, el plano de la arquitectura normativa. El AI Act es legislación de la UE y opera con obligaciones detalladas, enforcement administrativo y una lógica de mercado interior. El Convenio es un instrumento internacional marco que obliga a los Estados y, en este caso, también reconfigura cómo la propia UE articula salvaguardas compatibles con derechos humanos, democracia y Estado de Derecho en materia de IA.
Segundo, el plano operativo. Cuando un banco despliega modelos para scoring, prevención de fraude, onboarding digital o priorización de incidencias; cuando una aseguradora usa IA para tarificación, detección de fraude o gestión automatizada de siniestros; cuando una administración pública recurre a modelos para asistencia, clasificación o vigilancia; el análisis ya no puede cerrarse con un “cumple el AI Act y el GDPR”. Ahora debe incorporar una prueba de gobernanza institucional más amplia: finalidad legítima, proporcionalidad, supervisión humana real, vías de impugnación y trazabilidad de decisiones.
Esto no es teoría. Es preparación para supervisión, defensa procesal y reputación. En 2026, las tres cosas se mezclan.
El AI Act ha generado un efecto curioso: ha profesionalizado la conversación sobre IA y, al mismo tiempo, la ha estrechado. Las organizaciones discuten inventarios, categorías de riesgo, data governance, logging, transparencia, supervisión humana, accuracy, robustness y cybersecurity. Todo eso es necesario. Parte de ese armazón aparece de forma central en el AI Act para sistemas de alto riesgo, especialmente en el artículo 9 sobre sistema de gestión de riesgos, el artículo 10 sobre datos y gobernanza de datos, el artículo 12 sobre registro automático de eventos, el artículo 13 sobre transparencia e información al usuario, el artículo 14 sobre supervisión humana y el artículo 15 sobre exactitud, robustez y ciberseguridad.
Pero aquí está el problema: una entidad puede organizar de manera impecable esa capa documental y seguir sin tener una respuesta sólida a preguntas más incómodas.
Por ejemplo: ¿por qué este caso de uso merece existir, más allá de la eficiencia? ¿Qué derecho o interés legítimo prevalece frente al riesgo de exclusión, sesgo o opacidad? ¿Qué hace la entidad cuando un cliente cuestiona una decisión asistida por IA pero legalmente no encaja del todo en el artículo 22 del GDPR sobre decisiones exclusivamente automatizadas? ¿Cómo prueba que la supervisión humana no era un teatro diseñado para tranquilizar al regulador?
Eso es exactamente el tipo de espacio donde el Convenio gana relevancia. No sustituye al AI Act. Obliga a leerlo con una lente menos industrial y más institucional.
En otras palabras: el AI Act dice mucho sobre cómo diseñar y desplegar determinados sistemas. El Convenio obliga a preguntarse si determinados usos, incluso bien diseñados, son compatibles con un estándar europeo de derechos y de gobernanza pública y privada. Es una diferencia sutil en el papel y enorme en un comité de riesgos no financieros.
Las entidades financieras europeas llevan años automatizando decisiones delicadas con capas crecientes de machine learning: prevención de fraude, scoring de crédito, AML alert triage, monitorización de comunicaciones, marketing personalizado, fijación de precios, detección de reclamaciones sospechosas y atención al cliente con agentes generativos. Nada de esto es nuevo. Lo nuevo es que el margen para defender estos usos con un “hay humano en el loop” se estrecha.
La banca ya vive bajo obligaciones severas de gobernanza y resiliencia. DORA exige un marco de gestión del riesgo TIC sólido y documentado en su artículo 5, gestión de incidentes en los artículos 17 y siguientes, pruebas de resiliencia en los artículos 24 a 27 y control de terceros TIC en el artículo 28 y siguientes. El GDPR exige bases jurídicas, minimización, limitación de finalidad y gestión de derechos; el artículo 5 fija principios, el artículo 25 impone privacidad desde el diseño y por defecto, el artículo 32 medidas de seguridad, el artículo 33 notificación de brechas, y el artículo 35 evaluación de impacto cuando el tratamiento entraña alto riesgo. Si además el caso roza automatización significativa, el artículo 22 aparece en escena.
¿Qué añade el Convenio en la práctica para estas entidades? Cuatro cambios de fondo.
Uno: eleva el listón de justificación material. Ya no basta con documentar controles; hay que documentar razonamientos. El expediente de un uso de IA tendrá que parecerse menos a una ficha técnica y más a una defensa jurídica preventiva.
Dos: amplía el foco a la dimensión democrática e institucional. Esto impacta especialmente en entidades que colaboran con el sector público, infraestructuras críticas y servicios esenciales. Cuando la IA participa en procesos que afectan acceso a servicios básicos, seguridad económica o exclusión financiera, el escrutinio deja de ser puramente comercial.
Tres: refuerza la exigencia de remedios efectivos. Las áreas de atención al cliente, reclamaciones, defensor del cliente y segunda línea de compliance tendrán que conectarse de verdad con el gobierno de modelos. Hasta ahora, en demasiadas entidades esos mundos apenas se saludaban.
Cuatro: obliga a revisar la gobernanza de proveedores. Muchos despliegues financieros dependen de vendors de modelos, servicios cloud, herramientas de MLOps, biometría o modelos fundacionales. Si el proveedor ofrece transparencia limitada, logs insuficientes o restricciones contractuales sobre auditoría, el problema no desaparece porque el contrato tenga 80 páginas. Se queda dentro de casa.
La ironía aquí es evidente: la IA se vendió como una manera de acelerar decisiones; la regulación europea la está convirtiendo en una razón más para frenarlas, documentarlas y discutirlas mejor. No es un fallo del sistema. Es exactamente el sistema intentando corregir un mercado al que la fascinación tecnológica le ganó demasiado terreno.
La manera seria de leer este movimiento no es preguntarse si el Convenio “duplica” otra norma. Hay que ver cómo se solapan las obligaciones y dónde aparece el verdadero coste operativo.
El AI Act sigue siendo la pieza central para clasificar sistemas y asignar obligaciones concretas. Para alto riesgo, el núcleo está en los artículos 9 a 15: gestión de riesgos, gobernanza de datos, documentación técnica, logging, transparencia, supervisión humana y robustez/ciberseguridad. Si tu organización desarrolla o despliega sistemas dentro de esos supuestos, el Convenio no elimina una sola línea de ese trabajo. Añade una capa interpretativa más exigente sobre el propósito y el impacto institucional de ese uso.
El GDPR ya contiene varios puntos de anclaje que se vuelven más incisivos con el Convenio. El artículo 5 sobre principios, el artículo 13 y 14 sobre información, el artículo 22 sobre decisiones individuales automatizadas, y el artículo 35 sobre evaluaciones de impacto dejan de ser casillas de privacidad para convertirse en parte del expediente integral de legitimidad del sistema. La vieja separación entre “esto lo lleva privacidad” y “esto lo lleva IA governance” empieza a parecer un lujo organizativo difícil de sostener.
DORA no regula la ética de la IA, pero sí castiga la fantasía de que un sistema crítico puede funcionar sin disciplina operativa. Si un modelo de IA o un servicio basado en IA soporta funciones críticas o importantes, el marco de gestión del riesgo TIC del artículo 5, el tratamiento de incidentes y la gestión de terceros TIC del artículo 28 y siguientes entran de lleno. La conexión con el Convenio aparece cuando la entidad tiene que demostrar no solo que el sistema es resiliente, sino que su fallo, sesgo o manipulación no erosiona derechos o acceso equitativo a servicios financieros.
NIS2 endurece el gobierno de ciberseguridad y la responsabilidad de dirección para entidades esenciales e importantes. El artículo 20 obliga a los órganos de dirección a aprobar y supervisar medidas de gestión del riesgo; el artículo 21 detalla esas medidas, incluyendo análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía cuando proceda. Si la IA depende de pipelines complejos, proveedores de datos, APIs de terceros y servicios cloud, el riesgo de cadena ya no puede tratarse como un apéndice técnico.
Cuando la IA se cruza con identidad digital, firma electrónica, verificación remota o atributos cualificados, eIDAS 2.0 añade una variable de confianza regulada. No basta con que el modelo “funcione bien”; tiene que integrarse sin erosionar garantías de autenticidad, integridad y no repudio en procesos donde la identidad es determinante.
La CSRD no es una norma de IA, pero sí de divulgación y gobernanza empresarial. Si una compañía presenta en su reporting de sostenibilidad políticas de derechos humanos, gobierno de tecnología y control de riesgos, y luego despliega IA opaca en procesos sensibles, el problema no es solo regulatorio: también es de coherencia de información corporativa. A los auditores y a los inversores no les encanta descubrir que el discurso ESG convive con automatización poco defendible.
NIST CSF 2.0 sigue siendo una referencia operativa valiosa para gobernanza, identificación, protección, detección, respuesta y recuperación. El componente Govern ayuda mucho a ordenar responsabilidades y métricas. Pero una entidad europea que pretenda cubrir el expediente de IA con un framework voluntario estadounidense se expone a una sorpresa desagradable: gestionar bien riesgos de ciberseguridad no responde por sí solo a las exigencias europeas sobre derechos fundamentales y control democrático.
La conclusión del cruce regulatorio es bastante incómoda y bastante simple: ya no hay un “owner” único del cumplimiento de IA. Si legal, privacidad, ciberseguridad, riesgos no financieros, procurement y negocio siguen trabajando con documentos separados, el supervisor encontrará las grietas antes que ellos.
Hay tres áreas donde esta convergencia va a notarse antes que en ninguna otra.
Muchas entidades están comprando capacidades de IA empaquetadas: asistentes para empleados, scoring mejorado, detección de anomalías, análisis documental, monitorización de comunicaciones o biometría. El problema clásico es contractual: el proveedor promete rendimiento, pero limita transparencia, auditoría, acceso a training data provenance, logs detallados o explicaciones útiles para reclamaciones.
Con el AI Act ya era una mala idea aceptar esa opacidad. Con la capa del Convenio, es peor. Porque la entidad usuaria necesita sostener no solo conformidad técnica, sino también explicabilidad institucional y mecanismos de reparación. Si no puede obtener evidencia suficiente del proveedor, ese riesgo no desaparece. Se internaliza.
Esto obliga a renegociar cláusulas concretas: derechos de auditoría, retención de logs, notificación de cambios materiales de modelo, subprocesadores y subproveedores, testing de sesgo, gestión de incidentes, y capacidad para desactivar o degradar el servicio sin colapsar el proceso de negocio.
Un sistema de IA sin un canal serio de impugnación es una bomba lenta. El Convenio refuerza el argumento de que la protección no puede quedarse en transparencia formal. Si un cliente recibe una denegación, una prima disparada, una revisión antifraude agresiva o un cierre de cuenta tras un sistema de detección, la entidad debe poder ofrecer una revisión comprensible, documentada y con autoridad suficiente para corregir el resultado.
Eso suena de sentido común, pero choca con la realidad: muchas organizaciones han automatizado la decisión y han dejado la revisión humana en manos de agentes sin acceso al modelo, sin facultad para apartarse del output y sin información suficiente para reconstruir el caso. Eso no es supervisión humana. Es teatro administrativo.
El artículo 14 del AI Act obliga a diseñar la supervisión humana de forma que se prevengan o minimicen riesgos. El Convenio empuja a que esa supervisión no sea solo una formalidad técnica, sino una garantía sustantiva ligada a derechos. La diferencia importa.
Si el supervisor humano valida el 99% de las recomendaciones porque el workflow no deja tiempo material para revisar, la entidad tiene un problema. Si además carece de métricas sobre override rate, false positives, cohorts afectados o tiempos de resolución de revisiones, tiene un problema documentado a medias. Y media documentación suele equivaler a defensa débil.
Hay una lista de riesgos recurrentes que en 2026 deberían estar identificados, priorizados y con controles claros. Si no lo están, la entidad va tarde.
El primero es el sesgo en datos históricos. Crédito, fraude, precios de seguros y atención al cliente heredan patrones del pasado. Si esos datos reflejan exclusión, correlaciones socioeconómicas indirectas o decisiones humanas ya sesgadas, el modelo puede amplificarlos con aparente neutralidad matemática. El control aquí no es un PDF que diga “hemos revisado el fairness”. Hace falta testing por cohortes relevantes, umbrales aprobados, revisión periódica y criterios de escalado cuando aparezcan desviaciones.
El segundo es la degradación del modelo. Los entornos financieros cambian rápido: fraude adaptativo, comportamientos de clientes, cambios macroeconómicos, nuevas rutas de onboarding. Un modelo que era aceptable hace doce meses puede convertirse en una fuente de errores sistemáticos. DORA ayuda a enfocar esto desde resiliencia operacional; el AI Act y el Convenio lo empujan hacia control continuo con consecuencias sobre derechos y acceso a servicios.
El tercero es la dependencia de terceros. Modelos fundacionales, APIs, plataformas cloud, proveedores de verificación y herramientas de observabilidad forman cadenas complejas. El artículo 28 de DORA sobre terceros TIC y la lógica de NIS2 sobre seguridad de suministro deberían bastar para que esta cuestión ya estuviera madura. Aun así, demasiadas organizaciones siguen comprando IA como si fuera software convencional.
El cuarto es la opacidad en usos “internos” que acaban teniendo efectos externos. Un modelo de priorización de alertas AML o de fraude puede ser interno, sí, pero sus errores afectan bloqueos, retrasos, escalados y trato desigual a clientes. La etiqueta “solo uso interno” no inmuniza frente a escrutinio.
El quinto es el deslizamiento funcional. Un sistema se implanta para asistencia al analista y termina condicionando decisiones materiales porque el equipo confía demasiado en él. Ese paso casi nunca se documenta bien. Y sin documentación, la organización pierde control sobre su propio argumento regulatorio.
Si una entidad quiere tomarse en serio esta convergencia, necesita controles que resistan preguntas concretas. No hace falta inventar una burocracia nueva; hace falta cerrar huecos reales.
Empieza por el inventario. Pero no el inventario cosmético de casos de uso. Cada sistema debería registrar finalidad exacta, base jurídica de tratamientos asociados, clasificación bajo AI Act cuando proceda, impacto potencial sobre clientes o empleados, dependencia de terceros, datasets críticos, métricas de rendimiento y condiciones de retiro o suspensión.
Después, une dos evaluaciones que demasiadas empresas mantienen divorciadas: la evaluación de impacto de protección de datos del artículo 35 GDPR y la evaluación de riesgos de IA exigida por la lógica del artículo 9 del AI Act para alto riesgo. No tiene sentido operativo analizar por separado discriminación, explicabilidad, seguridad, sesgo, ciberincidentes y derechos de los afectados si al final todos esos riesgos convergen en el mismo despliegue.
Tercero, exige trazabilidad técnica útil para litigio y supervisión, no solo para ingeniería. Los logs del artículo 12 del AI Act deben servir para reconstruir decisiones y revisar incidentes. Si los registros no permiten saber qué versión del modelo actuó, con qué inputs, qué score produjo, qué intervención humana hubo y qué salida final se adoptó, la entidad está coleccionando datos irrelevantes.
Cuarto, mide de verdad la supervisión humana. Override rate, tiempo medio de revisión, tasa de confirmación por segmento, número de escalados, supuestos de intervención obligatoria y formación específica de revisores. Si no puedes medirla, no puedes probarla.
Quinto, reescribe procurement. No basta con anexos genéricos de seguridad. Los contratos con vendors de IA deben cubrir cambios de modelo, auditoría, subprocesadores, localización de datos, obligaciones de cooperación ante inspecciones, preservación de evidencia y derechos de terminación si el proveedor impide cumplimiento regulatorio. DORA ya había empujado esta disciplina para terceros TIC. La IA simplemente eleva las consecuencias.
Sexto, conecta reclamaciones con gobierno de modelos. Cada reclamación relevante debe alimentar análisis de causa raíz y revisión de umbrales o datasets. Si el equipo que recibe quejas no tiene ruta directa al owner del modelo, la organización está perdiendo una de sus mejores fuentes de evidencia.
Séptimo, introduce kill switch y modos degradados para usos críticos. Parece una cuestión técnica, pero es también jurídica. Una entidad que detecta un comportamiento anómalo y no puede detener o limitar el sistema con rapidez se expone a daños acumulativos difíciles de justificar después.
La objeción más escuchada desde despachos y empresas es que nada de esto es realmente nuevo: derechos fundamentales ya existen, el GDPR ya regula tratamientos automatizados, la Carta ya obliga y el AI Act ya incorpora salvaguardas. Entonces, ¿para qué otro instrumento?
La respuesta corta: porque la fragmentación también genera impunidad práctica.
Cuando las obligaciones están dispersas, cada función corporativa se refugia en su parcela. Privacidad mira bases jurídicas. Seguridad mira controles técnicos. Legal mira contratos. Riesgos mira taxonomías. Negocio mira eficiencia. Y nadie responde del conjunto. El Convenio aporta una narrativa jurídica integradora que dificulta ese juego de compartimentos.
Hay otra razón menos visible: el marco del Consejo de Europa conecta la IA con democracia y Estado de Derecho, dos dimensiones que muchas empresas preferirían considerar lejanas salvo cuando trabajan con gobiernos. Error. En servicios financieros, identidad, pagos, seguros, scoring y detección de fraude, la infraestructura privada participa de hecho en la distribución de oportunidades y restricciones sociales. No es administración pública, pero su poder práctico sobre la vida de las personas es enorme. Fingir que eso solo merece una respuesta de “gestión de riesgo tecnológico” es quedarse a mitad de la película.
Así que sí, parte del contenido ya estaba en el aire jurídico europeo. Lo que cambia es el peso de esa conversación y la facilidad con la que reguladores, tribunales y partes afectadas podrán encadenar argumentos. Para una entidad regulada, esa diferencia no es filosófica. Es material.
Para bancos, aseguradoras, establecimientos de pago, entidades de dinero electrónico y fintech en España, la convergencia llega en un momento especialmente incómodo: DORA ya está en fase de operacionalización real este año, los programas de IA madura empiezan a salir del laboratorio y el escrutinio sobre outsourcing tecnológico sigue creciendo.
En la práctica, las entidades españolas deberían revisar tres frentes muy concretos.
Primero, el encaje entre comités. Muchas casas siguen separando comité de modelos, comité de riesgos tecnológicos, comité de privacidad y comité de conducta o protección al cliente. Esa estructura genera zonas grises cuando un sistema de IA influye en admisión, precios, fraude o reclamaciones. Si nadie consolida la visión de derechos, resiliencia, seguridad y trato al cliente, la gobernanza falla antes de que falle el modelo.
Segundo, la documentación preparada para supervisores nacionales y europeos. Banco de España, CNMV y DGSFP no van a leer la IA solo como asunto de innovación. La leerán también como riesgo operacional, de conducta, de outsourcing, de protección del cliente y, cuando proceda, de seguridad. Un dossier de uso de IA que no conecte esos planos está incompleto.
Tercero, los contratos con proveedores globales. España no tiene margen para aceptar condiciones de black box incompatibles con obligaciones europeas. Si el proveedor no da visibilidad suficiente sobre cambios materiales, cadenas de subcontratación, localización, evidencia técnica o soporte ante inspecciones, la entidad debe decidir si ese uso merece el riesgo. La respuesta correcta a veces será no. Y convendría acostumbrarse a decirlo sin pedir perdón.
No hace falta una revolución organizativa, pero sí una limpieza de autoengaños.
Compliance debe dejar de tratar la IA como un apéndice documental y empezar a exigir expedientes integrados por caso de uso: base de legitimidad, riesgo de derechos, controles técnicos, evidencia de supervisión humana, vías de recurso y dependencia de terceros. Si el expediente no aguanta una reclamación dura o una inspección cruzada, no está listo.
El CISO tiene que meter la IA en el perímetro de resiliencia de forma explícita: inventario de componentes, seguridad de datos de entrenamiento e inferencia, hardening de pipelines, control de acceso, integridad de modelos, gestión de prompts y logs, y escenarios de degradación o abuso. DORA y NIS2 ya dan cobertura sobrada para hacerlo sin pedir permiso conceptual a nadie.
Negocio, por su parte, debe asumir que eficiencia sin defendibilidad regulatoria sale cara. Un caso de uso brillante sobre el papel puede ser inviable si exige datos demasiado sensibles, genera opacidad incompatible con revisión efectiva o depende de un proveedor incapaz de cooperar. Mejor descubrirlo antes del lanzamiento que después de una investigación o un conflicto masivo con clientes.
Y una advertencia final que vale oro en 2026: no sobreconfíes en la etiqueta “assistive AI”. Muchos sistemas presentados como apoyo terminan determinando el resultado material porque los equipos confían en ellos, los procesos presionan tiempos y los overrides son culturalmente raros. Si ocurre eso, el regulador no se fijará en el PowerPoint inicial. Se fijará en cómo funcionó de verdad.
La resolución del Parlamento Europeo de 11 de marzo de 2026 sobre la celebración del Convenio del Consejo de Europa no es un gesto ceremonial más para coleccionistas de siglas. Es otra señal de hacia dónde va Europa: hacia un modelo donde la IA no se evalúa solo por rendimiento, innovación o cuota de mercado, sino por su compatibilidad con derechos, procesos institucionales y capacidad de rendición de cuentas.
Habrá quien diga que eso resta competitividad. Es el argumento de siempre. También se dijo del GDPR, de partes de DORA y de casi cualquier norma que obligue a documentar algo antes de lanzarlo al mercado a toda velocidad. La cuestión relevante no es si la exigencia añade coste. Claro que lo añade. La cuestión es quién paga el coste de no exigirla.
En finanzas, seguros y servicios esenciales, la respuesta suele ser bastante fea: lo pagan clientes, personas vulnerables, equipos desbordados, mercados menos confiables y, al final, la propia entidad cuando descubre que un modelo eficiente pero injustificable sale carísimo en supervisión, litigio y reputación.
Ese es el verdadero mensaje de 2026. El AI Act ordena la maquinaria. El Convenio del Consejo de Europa obliga a justificar para qué la enciendes y bajo qué límites. Y esa segunda pregunta, la más incómoda, es la que separa el cumplimiento decorativo de la gobernanza adulta.
Nota editorial
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.
Aporta contexto, plantea una duda o responde a la conversación. Los comentarios son públicos y moderables.
Cargando comentarios…