La fase de supervisión de DORA quiere evidencias, no PDFs de política
Durante casi toda su vida temprana, el cumplimiento del sector financiero premió la buena documentación. Escribías la política, mapeabas los controles, mantenías el dosier al día, y cuando venía el supervisor le entregabas un conjunto bien organizado de PDFs. El documento era el entregable. Una organización que sabía describir su resiliencia de forma convincente era, a efectos regulatorios, resiliente.
Solo que esa era se está cerrando. DORA, el Reglamento europeo de Resiliencia Operativa Digital, está en vigor desde el 17 de enero de 2025 y, en 2026, entró en su fase de supervisión. Como informa el análisis de Dawiso sobre agentes de IA en banca bajo DORA, y como repiten las coberturas de Auriga y ATM Marketplace sobre gobernanza de IA en entidades financieras, los supervisores han cambiado lo que aceptan. Han pasado de tomar los documentos de política por su valor nominal a esperar evidencia de resiliencia basada en datos. El dosier ya no es el entregable. La prueba sí.
Ese giro cae con más fuerza precisamente sobre los sistemas que los bancos se apresuran ahora a desplegar. Porque un PDF de política que describe cómo se comportan tus agentes y un rastro de evidencias que demuestra cómo se comportaron son dos artefactos completamente distintos, y el segundo es el único que sobrevive a una revisión en fase de supervisión.
La brecha que expone la fase de supervisión
Una política es una descripción del comportamiento pretendido. La evidencia es un registro del comportamiento real. En el mundo previo a la supervisión, una podía sustituir a la otra, porque nadie estaba contrastando la segunda con la primera. La fase de supervisión acaba con esa sustitución.
La razón por la que esto importa ahora, y no hace cinco años, es lo que están desplegando los bancos. La cobertura de Dawiso proyecta que cerca del 44% de los equipos financieros usará IA agéntica en 2026, un salto grande. Esa es la colisión en el centro de esta historia. Un régimen de supervisión que acaba de empezar a exigir evidencia de comportamiento real se encuentra con una oleada de sistemas cuyo comportamiento real es probabilístico, cambia con cada actualización de modelo y, en la mayoría de los despliegues, apenas queda registrado.
Los riesgos nombrados en esa cobertura son concretos, y no son abstractos. Acceso no controlado de los agentes a sistemas internos. Registro inadecuado que hace imposible reconstruir un incidente. Lee esos dos juntos y tienes el modo de fallo exacto que la fase de supervisión de DORA está construida para atrapar: un sistema que puede actuar sobre tus plataformas centrales y que después no puede decirte qué hizo ni por qué. El PDF de política decía que estaba gobernado. La revisión te pide que lo demuestres, y no hay nada que enseñar.
Un agente que no puede reconstruir lo que hizo no pasa una revisión DORA
Esta es la frase que hay que interiorizar, porque convierte una ansiedad vaga de cumplimiento en un requisito arquitectónico concreto.
Las expectativas de resiliencia de DORA asumen que, cuando algo sale mal, puedes reconstruirlo. El reporte de incidentes, el análisis de causa raíz y toda la postura de resiliencia operativa descansan en la capacidad de responder, después, qué pasó, en qué orden y con qué fundamento. Para software determinista es un problema resuelto: los registros son la historia, y el código que los produjo no cambia entre el incidente y la investigación.
Un agente rompe ese supuesto de dos formas. Primera, actúa sobre contexto en vivo y razona de forma probabilística, así que "qué habría hecho" no se recupera volviendo a correr el código. Segunda, si el registro es inadecuado, como la cobertura nombra explícitamente, entonces ni siquiera "qué hizo de verdad" es recuperable. Un agente que leyó un expediente, razonó sobre él y lanzó una decisión, pero no dejó registro inspeccionable de las entradas que vio, la política que aplicó y el veredicto al que llegó, ha producido un resultado que nadie puede reconstruir.
Bajo el régimen antiguo eso era sobrevivible, porque podías señalar la política. Bajo supervisión, es descalificante. Un agente cuyas decisiones no pueden reconstruirse no puede demostrarse resiliente, y un sistema que no puede demostrarse resiliente no pasa. La ausencia de evidencia no es una brecha de documentación que arreglas luego. Es un agujero permanente, porque no puedes registrar retroactivamente decisiones que el sistema ya tomó sin capturarlas.
Cumplimiento como política ejecutable, evidencia como subproducto
La salida no es escribir un PDF de política mejor. Es construir una arquitectura donde la política sea ejecutable y la evidencia se produzca automáticamente, como condición para que el sistema funcione siquiera.
Dos propiedades hacen el trabajo, y corresponden directamente a lo que "evidencias, no políticas" exige.
Cumplimiento como política ejecutable. En lugar de un documento que describe las reglas, las reglas son código del que tu equipo de cumplimiento es dueño, que versiona y firma, evaluado en el momento de cada decisión. Cada acción con consecuencia pasa por un punto de decisión de políticas que devuelve un veredicto legible por máquina: permitir, permitir con condiciones documentadas, denegar o exigir una persona. El peso regulatorio que no se puede delegar se resuelve en una persona, por política; el agente solo analiza. La política deja de ser una afirmación sobre el comportamiento. Es el mecanismo que produce el comportamiento, y se puede probar, reaprobar y demostrar.
Un rastro de evidencias append-only, encadenado por hash. Cada decisión escribe un registro inmutable, antes de que la decisión se confirme, de las entradas que el agente vio, la versión de política contra la que corrió y el veredicto al que llegó. Encadenar las entradas por hash hace el rastro resistente a manipulación: puedes demostrar no solo qué pasó, sino que el registro no se alteró después. Y falla cerrado. Sin almacén de evidencias, no hay decisión. El sistema no puede actuar físicamente sin dejar el registro que un supervisor va a pedir.
Junta las dos y la reconstrucción deja de ser una esperanza y pasa a ser una consulta. Cuando llega la pregunta de la fase de supervisión — qué hizo este agente, con qué fundamento, y puedes demostrar que el registro está intacto — la respuesta es un informe que corres, no una investigación que lanzas. La evidencia existe porque la arquitectura no podría haber producido la decisión sin crearla.
Esa es la diferencia entre describir la resiliencia y demostrarla, y es exactamente la diferencia que la fase de supervisión de DORA se construyó para probar.
El replanteamiento
La pregunta que los bancos siguen haciendo, la que produce otro dosier, es "¿tenemos una política que cubra nuestros agentes de IA?". En la fase de supervisión, esa pregunta responde a un examen que ya nadie pone. Tener la política es lo mínimo. Demostrar el comportamiento es el examen.
La pregunta mejor es esta. Cuando un supervisor nos pida reconstruir exactamente qué hizo uno de nuestros agentes, sobre qué datos, bajo qué regla, y demostrar que el registro no se tocó, ¿podemos correr eso como un informe, o tenemos que admitir que no lo capturamos? Si la respuesta honesta es la segunda, ningún PDF de política cierra la brecha, porque la brecha no está en tu documentación. Está en tu arquitectura, y la fase de supervisión lee arquitectura, no intenciones.
Los supervisores cambiaron lo que aceptan. Los sistemas que se están desplegando hicieron urgente el cambio. Y las organizaciones que construyen el rastro de evidencias dentro del agente, en lugar de escribir una política sobre él, son las únicas que pasarán la revisión que ahora es seguro que van a afrontar.
Si quieres comprobar si tus procesos agénticos podrían producir una reconstrucción que un supervisor de DORA aceptara, reserva una reunión y tráenos el que toca más sistemas internos.