¿Tu software bancario está listo para DORA? Tero te ayuda a cumplir con la regulación y ganar resiliencia operativa sin perder velocidad de entrega.

En enero de 2025, un fallo de software bloqueó los pagos del banco británico Barclays justo el día del vencimiento fiscal en el Reino Unido: hubo clientes varados en supermercados y familias que no pudieron cerrar la compra de su casa. 

Meses después, una investigación del Parlamento británico reveló que los principales bancos y building societies del país habían acumulado más de 800 horas de caídas tecnológicas no planificadas en solo dos años, el equivalente a 33 días seguidos de sistemas caídos.

Este es exactamente el escenario que el Reglamento de Resiliencia Operativa Digital de la Unión Europea (DORA) busca evitar. La R de DORA es de Resiliencia, y el desafío real para un banco es generar esa resiliencia sin perder velocidad de entrega. Usar agentes de IA para acelerar la calidad del software, como hace Tero, es una de las formas más directas de lograrlo.

Qué es DORA y por qué es importante para tu software

DORA entró en aplicación el 17 de enero de 2025 en bancos, aseguradoras, empresas de inversión y a sus proveedores externos de tecnología. Su objetivo va más allá de la ciberseguridad tradicional. Se enfoca en la resiliencia operativa digital, es decir que las entidades financieras puedan resistir, responder y recuperarse de cualquier perturbación relacionada con las TIC, sea un ciberataque o una falla técnica interna.

El reglamento se organiza en cinco pilares:

1. Gestión del riesgo de TIC: marco de gobierno, identificación de activos críticos y evaluación continua de riesgos, con responsabilidad directa del órgano de dirección.
2. Gestión y notificación de incidentes: clasificar, registrar y reportar incidentes TIC relevantes dentro de plazos estrictos.
3. Pruebas de resiliencia operativa digital: un programa de testing que incluya pruebas anuales de todos los sistemas críticos y, para las entidades más significativas, Threat-Led Penetration Testing (TLPT), cada tres años.
4. Gestión del riesgo de terceros TIC: mapear dependencias de proveedores y exigirles el mismo nivel de control.
5. Intercambio de información: compartir inteligencia sobre amenazas y vulnerabilidades entre entidades del sector.

El tercer pilar es el que casi nunca se conecta con la conversación de IA en QA, y es justo el que más se relaciona con lo que hace un equipo de calidad de software todos los días.

¿La IA en testing rompe DORA?

Cuando un banco evalúa incorporar agentes de IA a sus procesos de entrega, la primera reacción de Riesgo y Compliance suele ser defensiva: ¿esto agrega una nueva fuente de riesgo tecnológico? Es una pregunta razonable, pero está formulada al revés.

DORA no prohíbe usar IA. Según su regulación (Reglamento (UE) 2022/2554), cualquier componente tecnológico, incluida la IA, debe estar gobernado, ser trazable y formar parte de un marco documentado de gestión de riesgo TIC, con controles proporcionales al tamaño y la criticidad de la entidad. Por eso, es fundamental que los agentes de IA utilizados en la calidad de software estén diseñados para operar dentro de ese marco de gobierno. 

Ahí es donde Tero se presenta como un habilitador del cumplimiento de DORA, ya que construye activamente el marco de gobierno que la regulación exige.

Tero es un agent harness de Abstracta, es decir una capa de software que convierte modelos de IA de propósito general en agentes especializados y gobernados para workflows de QA. 

El modelo aporta el razonamiento (interpreta la información y genera respuestas), mientras Tero aporta el contexto, los permisos, la supervisión humana y la evidencia para que esos agentes operen de forma controlada dentro de procesos reales de calidad de software.

Cómo se conectan los principios de Tero con DORA

Tero se organiza en torno a cuatro ejes: contexto de negocio, confianza, visibilidad y gobernanza. Fueron pensados para empresas reguladas. Cada uno responde, casi punto por punto, a una exigencia concreta de DORA:

Capacidades del Harness de Tero	Qué hace	Pilar de DORA al que responde
Confianza: agentes tratados como software, con validación de outputs, criterios de aceptación y evolución controlada	Convierte la IA en un componente auditable, no en una caja negra	Gestión del riesgo de TIC
Gobernanza: despliegue BYOC (en tu propia nube), roles diferenciados, auditoría y aprobación humana para acciones críticas	Mantiene a las personas a cargo de las decisiones, con trazabilidad completa	Gobierno y responsabilidad del órgano de dirección
Visibilidad: medición de uso, costo, adopción e impacto de cada agente	Aporta evidencia concreta para reportar a Riesgo y a los reguladores	Notificación de incidentes y evidencia de control
Contexto de negocio: agentes conectados al stack real del cliente, reusables y versionados	Acelera y amplía la cobertura de testing sobre sistemas críticos	Programa de pruebas de resiliencia operativa
Model-agnostic: los agentes operan sobre distintos proveedores de modelos	Evita la dependencia crítica de un único proveedor de IA	Gestión del riesgo de terceros TIC

A nivel técnico, esto se sostiene en los cinco componentes de Tero: orchestration, integration, observability, governance y security. El componente de observability es especialmente relevante para DORA, porque registra cada conversación, cada llamada a herramientas y cada decisión de cada agente. Tales acciones generan la trazabilidad que Compliance necesita para demostrar control.

El argumento central: menos defectos en producción es más resiliencia operativa

El objetivo de DORA es que los sistemas financieros puedan resistir, responder y recuperarse ante cualquier falla. Los incidentes bancarios de los últimos dos años muestran un patrón: gran parte de las fallas operativas graves no nace de un ciberataque, sino de errores de software que llegan a producción.

Algunos ejemplos recientes lo muestran con claridad:

• Barclays confirmó ante el Comité del Tesoro británico que la caída de enero de 2025 fue causada por un problema de software en su mainframe, no por un ciberataque, e informó que destinaría entre 5 y 7,5 millones de libras solo a compensar a los clientes afectados por ese incidente (UK Parliament).
• En octubre de 2025, Commonwealth Bank sufrió una interrupción de casi tres horas que afectó simultáneamente los pagos, la banca digital y los cajeros automáticos en Australia. El banco restableció los servicios, pero no reveló la causa del incidente  (ABC News).
• La autoridad reguladora bursátil de Estados Unidos (FINRA) multó a un bróker con 2,25 millones de dólares después de que una falla de diseño en su sistema automatizado de supervisión dejara sin detectar más de 4 millones de operaciones irregulares durante 7 años, un problema que se originó en un vacío de cobertura del propio sistema, no en un ataque externo (FinanceFeeds).

DORA exige testing riguroso precisamente porque los reguladores europeos entienden esta relación: sin un programa sólido de pruebas, la resiliencia operativa es una promesa sin sustento. 

Ahí es donde entra el rol de Tero: al desplegar agentes colaborativos para regresión, análisis de impacto, generación de datos de prueba y detección de fallas de lógica, ampliamos la cobertura y la velocidad de las prácticas de QA sin reemplazar el criterio humano que Compliance sigue necesitando.

Dicho de otra forma: cada bug, vulnerabilidad o falla de lógica que un agente de Tero ayuda a detectar antes de un release es un incidente operativo que el banco no tiene que reportar al regulador.

Cómo ganar resiliencia sin perder velocidad de entrega

Sumar Tero a los procesos de calidad de un banco que ya está invirtiendo en DORA es una forma concreta de ganar resiliencia sin perder velocidad de entrega. Fortalece tres frentes al mismo tiempo:

• Para compliance y riesgo: evidencia y trazabilidad concretas de cómo se prueban los sistemas críticos, con aprobación humana en cada decisión sensible.
• Para tecnología e ingeniería: mayor cobertura de testing sobre sistemas complejos y legacy, sin necesidad de un rip-and-replace del stack existente.
• Para el órgano de dirección: un argumento medible frente al supervisor de que la gestión del riesgo de TIC incluye, de forma activa, la prevención de defectos antes de producción.

No se trata de una promesa de cero incidentes: ningún marco de calidad, humano o asistido por IA, puede garantizarlo. La búsqueda debería estar enfocada en reducir de forma sostenida la probabilidad de que un fallo de software se convierta en un incidente que el banco tenga que explicarle a un regulador.

Preguntas frecuentes sobre Tero como habilitador de Dora

¿Qué soluciones existen para el cumplimiento de DORA en banca?

Las soluciones para el cumplimiento de DORA en banca suelen cubrir alguno de sus cinco pilares: gestión del riesgo de TIC, notificación de incidentes, pruebas de resiliencia operativa, gestión del riesgo de terceros e intercambio de información. Tero se enfoca específicamente en el pilar de pruebas de resiliencia operativa, con agentes de IA gobernados que amplían la cobertura de testing sobre sistemas críticos y generan la trazabilidad que Compliance necesita para reportar ante el regulador.

¿DORA prohíbe usar inteligencia artificial en los procesos de testing?

DORA no prohíbe usar inteligencia artificial en los procesos de testing. Lo que exige es que cualquier componente tecnológico, incluida la IA, esté gobernado, sea trazable y forme parte del marco de gestión de riesgo TIC de la entidad.

¿Usar agentes de IA en QA agrega un nuevo riesgo tecnológico que reportar a DORA?

Un agente de IA sin gobierno sí puede representar un riesgo adicional. Tero está diseñado para evitar ese escenario: cada agente tiene criterios de aceptación, aprobación humana para acciones críticas y despliegue BYOC, lo que permite incorporarlo al marco de gestión de riesgo de TIC en lugar de sumarlo como una excepción sin control.

¿Qué evidencia necesita mostrar un banco para demostrar cumplimiento del pilar de testing de DORA?

Un banco debe poder mostrar un programa de pruebas documentado, con procedimientos, herramientas y metodologías definidas, ejecutado por partes independientes, junto con la clasificación, priorización y remediación de las vulnerabilidades encontradas. El componente de observability de Tero aporta esta evidencia de forma nativa, al registrar cada decisión y cada acción de los agentes usados en el proceso de calidad.

¿Con qué frecuencia exige DORA probar los sistemas críticos?

DORA exige pruebas anuales de todos los sistemas y aplicaciones TIC críticos, y pruebas de penetración basadas en amenazas (TLPT) cada tres años para las entidades más significativas.

¿Por qué el testing de software es parte de la resiliencia operativa y no solo de la ciberseguridad?

Porque buena parte de los incidentes operativos graves en banca se origina en errores de software que llegan a producción, no en ciberataques, como muestran los casos de Barclays y Commonwealth Bank citados en este artículo.

Sobre Abstracta

Fundada en 2008 y con presencia global, Abstracta es una empresa de tecnología que ayuda a las organizaciones a entregar software de alta calidad más rápido, gracias a la combinación de ingeniería de calidad potenciada por IA con experiencia humana.

Creemos que fortalecer los lazos de forma activa nos permite avanzar y mejorar el software de nuestros clientes. Por eso, a lo largo del tiempo,  hemos establecido alianzas con referentes de la industria como Microsoft, Datadog, Tricentis, Perforce BlazeMeter, Sauce Labs y PractiTest.

Explora nuestras soluciones o contáctanos para conversar sobre cómo llevar IA al ciclo de calidad de software. 

Recomendados para tí

¿Tiene sentido usar Tero si tu equipo ya usa Claude Code o Cursor? 

La IA puede migrar código. ¿Quién valida que el negocio siga funcionando?

Cómo reconfigurar el testing financiero con IA