{"id":19138,"date":"2026-08-13T06:40:42","date_gmt":"2026-08-13T10:40:42","guid":{"rendered":"https:\/\/abstracta.us\/es\/blog\/?p=19138"},"modified":"2026-08-13T06:40:49","modified_gmt":"2026-08-13T10:40:49","slug":"tero-agent-harness-habilitador-de-dora","status":"publish","type":"post","link":"https:\/\/abstracta.us\/es\/blog\/tero-agent-harness-habilitador-de-dora\/","title":{"rendered":"Tero, Agent Harness habilitador de DORA en banca"},"content":{"rendered":"\n

\u00bfTu software bancario est\u00e1 listo para DORA? Tero te ayuda a cumplir con la regulaci\u00f3n y ganar resiliencia operativa sin perder velocidad de entrega.<\/strong><\/p>\n\n\n\n

\"Imagen<\/figure>\n\n\n\n

En enero de 2025, un fallo de software bloque\u00f3<\/a> los pagos del banco brit\u00e1nico Barclays justo el d\u00eda del vencimiento fiscal en el Reino Unido: hubo clientes varados en supermercados y familias que no pudieron cerrar la compra de su casa. <\/p>\n\n\n\n

Meses despu\u00e9s, una investigaci\u00f3n del Parlamento brit\u00e1nico revel\u00f3 que los principales bancos y building societies<\/em> del pa\u00eds hab\u00edan acumulado m\u00e1s de 800 horas de ca\u00eddas tecnol\u00f3gicas no planificadas<\/strong> en solo dos a\u00f1os, el equivalente a 33 d\u00edas<\/a> seguidos de sistemas ca\u00eddos.<\/p>\n\n\n\n

Este es exactamente el escenario que el Reglamento de Resiliencia Operativa Digital de la Uni\u00f3n Europea (DORA<\/a>) busca evitar. La R de DORA es de Resiliencia, y el desaf\u00edo real para un banco es generar esa resiliencia sin perder velocidad de entrega. <\/strong>Usar agentes de IA para acelerar la calidad del software, como hace Tero<\/strong><\/a>, es una de las formas m\u00e1s directas de lograrlo.<\/strong><\/p>\n\n\n\n

Qu\u00e9 es DORA y por qu\u00e9 es importante para tu software<\/strong><\/h2>\n\n\n\n

DORA entr\u00f3 en aplicaci\u00f3n el 17 de enero de 2025 en bancos, aseguradoras, empresas de inversi\u00f3n y a sus proveedores externos de tecnolog\u00eda. Su objetivo va m\u00e1s all\u00e1 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\u00f3n relacionada con las TIC, sea un ciberataque o una falla t\u00e9cnica interna.<\/p>\n\n\n\n

El reglamento se organiza en cinco pilares<\/a>:<\/p>\n\n\n\n

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

    El tercer pilar es el que casi nunca se conecta con la conversaci\u00f3n de IA<\/a> en QA<\/a>, y es justo el que m\u00e1s se relaciona con lo que hace un equipo de calidad de software todos los d\u00edas.<\/p>\n\n\n\n

    \u00bfLa IA en testing rompe DORA?<\/strong><\/h2>\n\n\n\n

    Cuando un banco eval\u00faa incorporar <\/strong>agentes de IA <\/strong><\/a>a sus procesos de entrega, la primera reacci\u00f3n de Riesgo y Compliance suele ser defensiva<\/strong>: \u00bfesto agrega una nueva fuente de riesgo tecnol\u00f3gico? Es una pregunta razonable, pero est\u00e1 formulada al rev\u00e9s.<\/p>\n\n\n\n

    DORA no proh\u00edbe usar IA. Seg\u00fan su regulaci\u00f3n (Reglamento (UE) 2022\/2554), cualquier componente tecnol\u00f3gico, incluida la IA, debe estar gobernado, ser trazable y formar parte de un marco documentado de gesti\u00f3n de riesgo TIC<\/strong>, con controles proporcionales al tama\u00f1o y la criticidad de la entidad.<\/a> Por eso, es fundamental que los agentes de IA utilizados en la calidad de software est\u00e9n dise\u00f1ados para operar dentro de ese marco de gobierno. <\/p>\n\n\n\n

    Ah\u00ed es donde Tero se presenta como un habilitador del cumplimiento de DORA, ya que construye activamente el marco de gobierno que la regulaci\u00f3n exige.<\/strong><\/p>\n\n\n\n

    Tero es un agent harness de Abstracta, es decir una capa de software que convierte modelos de IA de prop\u00f3sito general en agentes especializados y gobernados para workflows de QA. <\/strong><\/p>\n\n\n\n

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

    C\u00f3mo se conectan los principios de Tero con DORA<\/strong><\/h2>\n\n\n\n

    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:<\/p>\n\n\n\n

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

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

    El argumento central: menos defectos en producci\u00f3n es m\u00e1s resiliencia operativa<\/strong><\/h2>\n\n\n\n

    El objetivo de DORA es que los sistemas financieros puedan resistir, responder y recuperarse ante cualquier falla. Los incidentes bancarios de los \u00faltimos dos a\u00f1os muestran un patr\u00f3n: gran parte de las fallas operativas graves no nace de un ciberataque, sino de errores de software que llegan a <\/strong>producci\u00f3n<\/strong><\/a>.<\/strong><\/p>\n\n\n\n

    Algunos ejemplos recientes lo muestran con claridad:<\/p>\n\n\n\n