Tero, Agent Harness habilitador de DORA en banca

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:

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.