Arquitecto de un banco: en la prueba de METR, la IA aumentó un 19% el tiempo de las tareas de desarrolladores experimentados

El responsable de la función de arquitectura de un banco ruso ha publicado en Habr un análisis de cómo la IA generativa y los agentes LLM cambian la arquitectura corporativa. El argumento central del autor se apoya en la prueba aleatorizada de METR de 2025 (METR es una organización independiente que evalúa las capacidades de la IA): los desarrolladores experimentados que trabajaron con IA en bases de código maduras tardaron un 19% más en sus tareas que sin ella. Al mismo tiempo, ellos estaban convencidos de haber ganado un 20% de velocidad, de modo que la distancia entre la percepción y la realidad fue de 39 puntos porcentuales.

Según el autor, esto demuestra que escribir código nunca fue el cuello de botella de la empresa. La verdadera dificultad está en encajar la nueva lógica en un entorno con sistemas legacy, regulación y restricciones de seguridad de la información.

La ilusión de la aceleración y el precio del código barato

La red neuronal elimina el miedo a la página en blanco: el desarrollador obtiene un fragmento de código al instante. Pero entonces empieza la integración. El código generado parece sintácticamente impecable, pero a menudo ignora las dependencias implícitas de los sistemas legacy y falla en tiempo de ejecución. El ingeniero pasa horas depurando algo que solo parece funcionar.

Los datos de GitClear lo confirman de forma indirecta: el volumen de código copiado superó al de código refactorizado, y el churn rate (la proporción de código reciente que se reescribe poco después del commit) subió del 3,3% previo a la adopción masiva de la IA al 7,1%. Los informes DORA muestran el mismo patrón: el rendimiento (throughput) aumenta y la estabilidad de las entregas cae.

La conclusión del autor es práctica: no se puede confiar en la revisión de código hecha por personas. Hacen falta sensores deterministas en el pipeline, como fitness functions, linters y contratos, que impidan que código alucinado o estructuralmente defectuoso llegue a master. Los documentos de arquitectura ceden su lugar a guardrails-as-code.

Regulación rusa y el modelo como actor

Las noticias occidentales sobre aplazamientos de plazos apenas significan nada para un banco ruso. El EU AI Act Omnibus retrasó los requisitos para los sistemas de alto riesgo hasta el 2 de diciembre de 2027, y la Fed y la FDIC de Estados Unidos, con el documento SR 26-2, sacaron la IA generativa y agéntica del marco estándar de gestión del riesgo de modelos. En Rusia, la arquitectura la determinan la ley 187-ФЗ sobre infraestructura crítica de información (КИИ), la norma 850-П sobre resiliencia operativa y el plazo para migrar los objetos significativos de la КИИ a una pila nacional: el 1 de enero de 2028.

Cada decisión debe pasar el filtro del registro de software ruso, la categoría de significancia de los objetos de la КИИ y la localización de datos personales según la ley 152-ФЗ.

El apartado 2.5 del documento 3-МР del Banco de Rusia, publicado en junio de 2026, recomienda que un empleado confirme obligatoriamente la operación y pueda modificarla. Esto afecta a la IA en procesos críticos, como los pagos con riesgos elevados de seguridad de la información. Por eso el human-in-the-loop se ha convertido en una capa obligatoria del diseño. Sobre los LLM, el banco incorpora una abstracción de tipo router para que un cambio de modelo motivado por la ley de IA (243-ФЗ) no paralice la operación.

La revisión de diseño empieza con una pregunta: ¿el modelo es un componente o un actor? Si está confinado en una aplicación y solo muestra una respuesta en pantalla, basta con el OWASP GenAI LLM Top 10. Si tiene memoria, acceso a API y llamadas a funciones, se aplica el OWASP Agentic Top 10, donde el riesgo de agencia excesiva (Excessive Agency) ha subido al tercer puesto. Para estos agentes se construyen sandboxes de ejecución de código, se limitan estrictamente las llamadas a herramientas y se cierra el acceso directo a las bases de datos.

Un agente no es una cuenta de servicio. Una clave de API estática con permisos amplios abre la puerta a un ataque de tipo confused-deputy: un prompt astuto obliga al agente autorizado a ejecutar una acción maliciosa con los máximos privilegios. Por eso cada agente tiene su propia identidad y los permisos se conceden mediante tokens de delegación de corta duración para una llamada concreta. En los registros de auditoría se distingue cuándo actuó una persona y cuándo un agente en su nombre.

El tercer riesgo es la IA «heredada»: los proveedores de SaaS, ERP e ITSM activan Copilots integrados con sus actualizaciones y modifican el mapa de flujos de datos, lo que afecta al secreto bancario (art. 26 de la ley «Sobre los bancos y la actividad bancaria», art. 857 del Código Civil de la Federación de Rusia). La política del banco es default-off para las funciones de IA externas: activarlas equivale a un cambio mayor y se registran en un inventario aparte.

Documentación para máquinas, el fin del ARB y nuevos NFR

La documentación de arquitectura (ADR, esquemas C4, descripciones de API) vive en Git como Markdown, PlantUML y Structurizr. Los agentes leen el texto sin procesar del repositorio mejor que las exportaciones de sistemas propietarios, así que en el repositorio hay archivos de contexto RULES.md y ARCHITECTURE.md. Para acceder a ellos, el banco desarrolló una capa interna sobre los repositorios con soporte de MCP. Los comités ARB se han disuelto: ahora rige un advice process, en el que la decisión la toma el arquitecto de soluciones (Solution) del dominio, y los contornos regulatorios siguen siendo restricciones obligatorias.

En las plantillas de ADR se han añadido el límite entre la lógica determinista y la salida probabilística, la topología de los flujos de datos dentro del perímetro del banco, los disparadores de traspaso del control a una persona y un exit path por si el proveedor se degrada o cambia la licencia. En los requisitos no funcionales han aparecido métricas de comportamiento ante fallos: un «rechazo correcto» vale más que una alucinación arriesgada. En FinOps se fija un tope de coste en tokens para cada transacción de negocio, y la latencia se mide a lo largo de todo el ciclo, incluidas las llamadas del agente a sistemas externos.

El autor deja abierta la cuestión de los metamodelos: ArchiMate no puede describir de forma adecuada un prompt, un umbral de validación o una cadena de delegación dinámica. Su conclusión es esta: un plano promete cómo funcionará el sistema, mientras que un componente probabilístico no ofrece tales promesas. Solo queda limitarlo de antemano, interceptarlo en el momento de la acción y demostrar a posteriori con qué autoridad actuó.