La IA está acelerando proyectos de modernización que antes exigían meses de análisis. Pero en las organizaciones más reguladas aparece enseguida una realidad incómoda: el riesgo ya no está en convertir el código, sino en demostrar que la versión nueva sigue haciendo exactamente lo que hacía la anterior.
Casi todos los comités de dirección han tomado la misma decisión este año: aplicar inteligencia artificial a sus sistemas. Y casi todos descubren lo mismo cuando bajan al detalle. La IA es fácil de añadir en la periferia —un chatbot, un copiloto, un cuadro de mando— y muy difícil de meter donde de verdad importa, que es el núcleo heredado. En banca, en seguros, en buena parte de la Administración, ese núcleo sigue siendo COBOL sobre mainframe, con décadas de parches encima y una documentación que, siendo generosos, es incompleta.
Ahí es exactamente donde se concentra el riesgo regulatorio. Y ahí es donde más proyectos descarrilan.
Llevo tres décadas en sectores regulados y el patrón se repite. El equipo de IT aborda la modernización como un problema de delivery —entregar rápido, cerrar tickets, pasar a producción— cuando en un sector supervisado el problema es de compliance. No se mide por lo que entregas, sino por lo que puedes defender. Cambiar ese chip es la mitad del trabajo.
La promesa es seductora. Hoy un modelo de lenguaje lee miles de líneas de COBOL, las documenta, las explica y propone una equivalencia en Java o en Python en una fracción del tiempo que costaría a un equipo humano. Funciona. Lo he visto acelerar análisis que antes llevaban semanas.
El problema no es el código. El problema son las reglas de negocio que nadie escribió nunca. En un proyecto de migración en un entorno bancario altamente regulado, el mayor riesgo no estaba en las rutinas, sino en una excepción de cálculo que llevaba quince años funcionando y que no figuraba en ningún documento: vivía solo en el código y en la cabeza de un analista ya jubilado. Cuando se le pide a un modelo que “traduzca” eso, no traduce: rellena el hueco con lo que estadísticamente parece correcto. Y lo hace con una seguridad impecable.
En un cuadro de mando, una alucinación es un error molesto. En el motor de cálculo de una entidad financiera es una incidencia de cumplimiento, una reclamación de cliente y, potencialmente, una sanción del supervisor.
La tentación, precisamente porque la herramienta es tan rápida, es saltarse la parte lenta: la reconstrucción de esa lógica con quien la conoce. Es la peor decisión posible. La velocidad de la IA seduce justo en el punto donde más caro sale equivocarse.
DORA está en vigor desde enero de 2025 y es muy claro: resiliencia operativa, gestión de activos TIC, continuidad de negocio y control del riesgo de terceros. Modernizar el núcleo toca las cuatro cosas a la vez. NIS2 añade la capa de seguridad y notificación. Y el Reglamento de IA introduce su propio marco cuando el sistema que despliegas es de alto riesgo.
Aunque DORA, NIS2 y el Reglamento de IA persiguen objetivos distintos, comparten una exigencia común: poder demostrar control, trazabilidad y responsabilidad sobre los sistemas que se despliegan. Esa es la pieza que conecta los tres marcos, y la que un proyecto de modernización tiene que proteger desde el primer día.
Aquí conviene deshacer un malentendido reciente. Con el acuerdo del Digital Omnibus de mayo de 2026, las obligaciones de alto riesgo del Anexo III se aplazan a diciembre de 2027. Muchos directivos han leído el titular —”la UE retrasa la Ley de IA”— como una tregua. Es una lectura peligrosa. Las obligaciones de transparencia siguen aplicándose en agosto de 2026, el marcado de contenido sintético llega en diciembre de 2026 y, sobre todo, el riesgo subyacente no se mueve ni un día. Una decisión automatizada errónea en 2026 sigue cayendo bajo el RGPD, bajo la normativa sectorial y bajo el supervisor de turno. El plazo se ha movido; la responsabilidad, no.
No tengo una fórmula mágica, pero sí cinco principios que aplico en cada proyecto de este tipo.
Primero, inventariar antes de modernizar. No se puede asegurar ni migrar lo que no se ha mapeado. Activos, dependencias, flujos de datos: si no existe ese mapa, el primer entregable del proyecto es construirlo, no escribir código.
Segundo, la IA propone, una persona valida. El modelo acelera el análisis y el primer borrador de la transformación. La regla de negocio crítica la confirma un ingeniero que entiende el negocio, no el modelo. Donde no haya quien la entienda, se reconstruye con el área de negocio antes de tocar nada.
Tercero, trazabilidad de extremo a extremo. Cada transformación generada por IA debe quedar registrada: qué entró, qué salió, quién lo aprobó y por qué. Eso no es burocracia; es exactamente lo que el auditor pedirá, y es lo que convierte un cambio en defendible.
Cuarto, cuidado con dónde va el código. Volcar fuentes del núcleo en un modelo externo es una transferencia de datos y un problema de confidencialidad antes que una cuestión técnica. DORA exige controlar al tercero; el RGPD, controlar el dato. Esa decisión se toma al principio del proyecto, no cuando ya está hecho.
Quinto, gobernar el shadow AI. Si la organización no ofrece una vía segura para usar IA, los equipos la usarán igual, por su cuenta y sin control. La gobernanza no consiste en prohibir, sino en dar un camino habilitado.
En un sector regulado, el reto del CIO ya no consiste únicamente en modernizar los sistemas heredados, sino en hacerlo de una forma que resista el escrutinio de auditores, reguladores y comités de riesgo. Dirigir uno de estos proyectos ya no es coordinar entregas: es hacer que la transformación sea defendible. Significa decir que no a un atajo que ahorraría dos semanas, pero dejaría un hueco sin trazabilidad. Significa tratar la gobernanza como un acelerador —porque un cambio bien documentado se aprueba antes— y no es un freno.
La IA es una palanca extraordinaria para sacar a las organizaciones de su deuda técnica heredada. Pero en banca, seguros o Administración, la velocidad sin control no es una ventaja: es un pasivo que aflora en la primera inspección. Modernizar rápido puede ser una ventaja competitiva; modernizar con trazabilidad, control y capacidad de defensa es lo que la hace sostenible.
Por eso resumo así lo que llevo aprendido en estos años: una solución segura no es la más lenta ni la más cara. Es la que sobrevive a la primera auditoría.
José Enrique Ibarra es CIO interim y AI Project Manager, con tres décadas dirigiendo TI en sectores regulados —banca, seguros, energía y administración pública—. Su foco es gobernar la transformación digital y la adopción de IA bajo el Reglamento de IA, DORA, NIS2, RGPD, ISO 27001 y el ENS, de forma que resista el escrutinio de auditores y reguladores. Impulsa AI Forge, su iniciativa de IA aplicada. Reside en Almería.