ESMA y la Supervisión Digital: Navegando la Transformación con Ética y Precisión

La promesa de la digitalización en supervisión financiera suena irresistible: más datos, más velocidad, mejores alertas. El problema empieza cuando a esa promesa se le añaden atributos que la fuente no sostiene. No, no basta con decir “en tiempo real” y dar por hecho que todo queda resuelto. Y no, tampoco conviene cargar a DORA, NIS2 o al AI Act con obligaciones que no dicen exactamente lo que algunos resúmenes apresurados querrían que dijesen.

Aquí está el quid: la transformación digital de la supervisión y del compliance financiero sí cambia el terreno de juego, pero lo hace de una forma más prosaica y bastante más exigente de lo que sugiere la retórica habitual. La digitalización amplía la capacidad de tratamiento de datos, favorece una supervisión más basada en información estructurada y empuja a las entidades a ordenar mejor su gobernanza tecnológica. Eso ya es mucho. Lo que no permite, al menos con la fuente analizada, es concluir que exista una identificación de riesgos o una supervisión “en tiempo real” como atributo general.

La diferencia no es semántica. En regulación financiera, una palabra mal puesta puede convertir un análisis serio en una pieza decorativa. Y para un responsable de cumplimiento, decorar obligaciones legales es una manera especialmente torpe de complicarse la vida.

Lo que sí puede decirse sobre digitalización y supervisión

La fuente permite afirmar que la digitalización está reforzando el uso de datos y herramientas tecnológicas por parte de los supervisores y de las propias entidades. Eso tiene consecuencias claras: más trazabilidad, más dependencia de la calidad del dato y más presión para que los procesos internos sean consistentes. Si los datos de entrada son defectuosos, el problema no desaparece porque haya más dashboards; simplemente se propaga más deprisa.

También puede sostenerse que el uso de tecnología favorece una supervisión más analítica y una gestión del cumplimiento más apoyada en evidencias documentadas. Lo prudente termina ahí. Dar el salto a una supuesta supervisión instantánea o a una detección automática de riesgos en tiempo real no está respaldado por la fuente. Conviene decirlo sin rodeos porque ese tipo de exageración se ha convertido en vicio sectorial.

Para las entidades financieras, la lectura útil no es futurista, sino operativa: si el supervisor trabaja con más datos y espera mayor consistencia, tu gobierno del dato, tu inventario de proveedores TIC y tu documentación de decisiones dejan de ser un anexo aburrido y pasan a ser material de primera línea.

DORA: menos épica, más artículo 28

Buena parte de la confusión procede de cómo se invoca DORA. El Reglamento (UE) 2022/2554 no necesita adornos; ya impone bastante por sí solo. En materia de terceros TIC, el punto de partida está en el artículo 28, que exige que el riesgo derivado de terceros prestadores de servicios de TIC se gestione como parte integrante del marco de gestión del riesgo de las TIC de la entidad financiera. Esa formulación importa porque fija una obligación estructural: el riesgo de terceros no va por libre ni puede tratarse como un asunto puramente contractual o de compras.

Lo que no conviene hacer es atribuir al artículo 28 mandatos que, al menos en esos términos, no contiene. No puede afirmarse con precisión jurídica que el artículo 28 exija por sí mismo “evaluaciones periódicas” de riesgos a proveedores TIC, ni “auditorías regulares generales”, ni sistemas de monitorización en tiempo real. Tampoco es correcto presentar ese precepto como si detallara de forma cerrada procedimientos de selección, supervisión y auditoría con una revisión exhaustiva de SLA como obligación literal. El capítulo sobre gestión del riesgo de terceros TIC sí incluye estrategia, registro de información y exigencias sobre elementos contractuales en disposiciones posteriores, pero confundir el conjunto del capítulo con una lista cerrada del artículo 28 solo genera ruido.

La consecuencia práctica es más interesante que el eslogan. Si el riesgo de terceros TIC debe integrarse en el marco general de riesgo TIC, la entidad necesita al menos tres cosas bien resueltas: una gobernanza clara sobre quién decide y quién acepta riesgos, un inventario fiable de proveedores y servicios soportados, y una conexión real entre contratación, seguridad, continuidad y cumplimiento. Sin esa conexión, DORA se convierte en una colección de documentos bonitos con poca utilidad el día del incidente.

Qué obliga de verdad el enfoque de terceros TIC

Hay una tentación bastante común: resumir DORA como una orden de “auditar proveedores” y seguir adelante. Es una simplificación cómoda, pero pobre. La lógica regulatoria es más amplia. El reglamento obliga a tratar las dependencias tecnológicas externas como parte del perfil de riesgo operativo de la entidad. Eso afecta a la estrategia, a la documentación y a la forma en que se formalizan y gobiernan las relaciones contractuales.

Si quieres una traducción práctica del artículo 28 y del capítulo en el que se inserta, sería esta: la entidad no puede externalizar una función o un servicio TIC crítico y después fingir que el riesgo también se ha externalizado. La responsabilidad regulatoria sigue dentro. Siempre.

Eso no equivale a afirmar obligaciones no verificadas, como una supuesta monitorización continua exigida literalmente por DORA o una cadencia universal de auditorías periódicas impuesta a todos los proveedores. Equivale, más bien, a algo más incómodo y realista: la entidad debe ser capaz de demostrar que conoce sus dependencias TIC, que las encuadra en su marco de riesgo y que mantiene mecanismos de control coherentes con esa dependencia. A partir de ahí, la intensidad de las medidas dependerá del servicio, de su criticidad y del diseño del marco de control de cada entidad.

El error recurrente: convertir recomendaciones sensatas en obligaciones textuales

Otra fuente de problemas está en disfrazar buenas prácticas como si fueran mandatos literales de la norma o de la fuente analizada. Decir que una entidad debería tener controles internos sólidos o una buena gestión de incidentes puede ser razonable. Presentarlo como un hecho respaldado por la fuente, si la fuente no lo dice, es otra historia.

Con la documentación disponible, lo que sí puede sostenerse es que los marcos normativos digitales elevan la exigencia sobre gobernanza, documentación y capacidad de gestión del riesgo tecnológico. Eso empuja a las entidades a revisar controles internos, criterios de escalado, inventarios y procesos de coordinación entre seguridad, tecnología, compras, legal y compliance. Lo que no procede es rellenar ese análisis con una lista cerrada de supuestas exigencias —monitorización continua, pruebas de penetración periódicas, criterios de auditoría específicos— si la fuente concreta no las contiene o no las vincula al artículo citado.

La diferencia vuelve a ser crucial. Un lector experto no necesita que le repitan un catálogo estándar de controles; necesita saber qué está anclado en un precepto concreto y qué es interpretación operativa. Mezclar ambos planos es la manera más rápida de que una pieza pierda credibilidad entre quienes sí se leen los artículos.

AI Act: cuidado con meter a las finanzas en la caja de “alto riesgo” por reflejo

El AI Act se ha convertido en una víctima perfecta del resumen automático. Se cita el artículo 6, se menciona “alto riesgo” y, acto seguido, se sugiere que cualquier uso de IA en supervisión financiera o en finanzas entra de lleno en esa categoría. No funciona así.

Con rigor, puede decirse que el artículo 6 establece la lógica de clasificación de determinados sistemas de IA como de alto riesgo por referencia a los casos recogidos en el marco del reglamento. Lo que no puede afirmarse de forma general, y menos con la fuente analizada, es que la IA utilizada en supervisión financiera o en finanzas quede automáticamente clasificada como de alto riesgo por ese artículo. Tampoco es correcto atribuir al propio artículo 6 una obligación específica de “evaluaciones de impacto rigurosas antes de la implementación” en esos términos. Ahí se mezclan clasificación y obligaciones de cumplimiento de una manera que jurídicamente no aguanta bien una segunda lectura.

Esto no rebaja la relevancia del AI Act. Lo que hace es recolocarla. Para una entidad financiera, la pregunta útil no es “¿todo lo que hago con IA es alto riesgo?”, sino “¿mi caso de uso encaja en alguno de los supuestos de alto riesgo del reglamento y, si es así, qué obligaciones concretas se activan?”. Esa pregunta exige análisis de caso, no brochazos sectoriales.

Y conviene añadir una cautela más. Atribuir a ESMA una agenda específica sobre “ética” o una exigencia de transparencia de las entidades respecto de cómo usan datos, si la fuente declarada no lo respalda, es mala práctica analítica. El debate sobre datos, supervisión y uso de tecnologías existe. Lo que no debe hacerse es poner en boca del supervisor una formulación normativa o programática que no aparece en la fuente.

ESMA: digitalización sí, grandilocuencia no

La fuente permite hablar de mayor digitalización y de un uso más intenso de los datos en la actividad supervisora. Eso ya ofrece material suficiente para un análisis serio. Lo que no permite es afirmar que ESMA esté construyendo una “supervisión más integrada” orientada a un sistema más cohesionado y eficiente, al menos no en esos términos. Puede ser una inferencia atractiva. No deja de ser una inferencia.

La lectura más sobria es otra: si la autoridad supervisora incrementa su capacidad digital y su dependencia de datos, las entidades supervisadas tendrán menos margen para convivir con inconsistencias internas, taxonomías caóticas y responsabilidades difusas. El supervisor no necesita prometer una revolución para aumentar la presión. Le basta con pedir información de forma más estructurada y cruzar mejor lo que recibe.

Ese cambio, además, tiene una consecuencia incómoda para muchas organizaciones: obliga a revisar cómo se conectan compliance, riesgo operacional, seguridad de la información y gestión de proveedores. Durante años, demasiadas entidades han tratado esos dominios como compartimentos estancos con reuniones de cortesía. La regulación digital está castigando precisamente esa fragmentación.

Lo que no puede afirmarse sobre banca y seguros a partir de esta fuente

Algunas afirmaciones sectoriales resultan intuitivas, pero no por eso quedan verificadas. Con la fuente disponible, no puede sostenerse que en banca la digitalización haya facilitado la detección de fraude y el cumplimiento normativo “en tiempo real”. La coletilla temporal ya era problemática en supervisión; aquí lo es todavía más. La digitalización puede mejorar la capacidad analítica, automatizar tareas y ampliar el tratamiento de datos. Convertir eso en una promesa de control instantáneo es un salto que la fuente no autoriza.

Tampoco procede afirmar que, en seguros, la digitalización permita una evaluación más precisa del riesgo si la fuente declarada no aborda ese sector ni esa consecuencia específica. La frase suena plausible. Ese es precisamente el problema: las frases plausibles son el combustible favorito del contenido regulatorio mediocre.

Algo parecido ocurre con NIS2. La Directiva (UE) 2022/2555 establece obligaciones para las entidades que entren en su ámbito, especialmente en materia de medidas de gestión de riesgos de ciberseguridad y gobernanza, con un punto de referencia central en el artículo 21. Pero de ahí no se sigue una afirmación sectorial genérica según la cual “las aseguradoras deben asegurar que sus sistemas cumplan con los requisitos de seguridad establecidos por la NIS2”. La aplicabilidad depende del ámbito subjetivo de la directiva y de su interacción con marcos sectoriales, incluido DORA cuando corresponda. Reducirlo a una consigna por sector solo crea falsa seguridad o, peor, obligaciones imaginarias.

Qué hacer entonces: leer mejor el cruce entre normas

La parte más útil del análisis no está en inflar titulares, sino en entender cómo se cruzan las piezas regulatorias. DORA organiza la resiliencia operativa digital en el sector financiero y trata expresamente el riesgo TIC, incluido el derivado de terceros. NIS2 fija obligaciones de ciberseguridad para entidades dentro de su ámbito, con un núcleo de medidas de gestión de riesgos en su artículo 21. El AI Act introduce una lógica propia para determinados sistemas de IA, incluida la categoría de alto riesgo del artículo 6. GDPR, por su parte, sigue siendo decisivo cuando el tratamiento de datos personales entra en juego, por ejemplo con las obligaciones de notificación de brechas del artículo 33.

El error habitual consiste en leer estas normas como si fueran cromos intercambiables. No lo son. Tienen puntos de contacto, áreas de solapamiento y finalidades distintas. Una entidad financiera sensata no debería preguntarse qué norma “manda más”, sino dónde se superponen los controles, qué exige cada una de forma literal y qué evidencias documentales necesitará para demostrar cumplimiento sin duplicar trabajo de manera absurda.

Ese enfoque cambia la conversación interna. En lugar de pedir listas genéricas de “mejores prácticas”, obliga a mapear procesos, servicios TIC, proveedores, tratamientos de datos y casos de uso de IA contra artículos concretos. Es más laborioso. También es bastante más útil cuando llega una inspección o un incidente serio.

Una conclusión menos vistosa, pero bastante más fiable

La digitalización de la supervisión financiera y del compliance no necesita promesas exageradas para ser relevante. Ya está alterando la forma en que se recopilan, estructuran y analizan datos; ya está elevando la exigencia sobre trazabilidad y gobernanza; y ya está haciendo más visible algo que muchas entidades preferían mantener en penumbra: sus dependencias tecnológicas.

Lo razonable, por tanto, es limpiar el discurso. La fuente no permite hablar de supervisión o identificación de riesgos en tiempo real como conclusión general. No permite atribuir a ESMA una doctrina concreta sobre ética o transparencia en el uso de datos por las entidades. No permite convertir el artículo 28 de DORA en un cajón de sastre de auditorías periódicas, SLA exhaustivos y monitorización continua. No permite decir que el artículo 6 del AI Act clasifique en bloque la IA en finanzas o supervisión financiera como de alto riesgo. Y no permite importar NIST CSF 2.0 al análisis si ni siquiera forma parte de la fuente declarada.

Lo que sí permite es algo más serio: explicar que la regulación digital está empujando a las entidades hacia un modelo de control más documentado, más dependiente de datos fiables y menos tolerante con improvisaciones entre funciones. Si tu organización todavía trata proveedores TIC, riesgo tecnológico, protección de datos y automatización como asuntos separados que se saludan por Teams una vez al trimestre, conviene asumirlo cuanto antes: el problema no es que falte retórica digital. El problema es que sobra fragmentación.

Y esa, a diferencia de los eslóganes, sí es una conclusión verificable en casi cualquier entidad que haya intentado aterrizar DORA con un mapa de terceros a medio hacer.