IA de frontera y ciberresiliencia: lo que piden FSB, BIS y FCA a la banca

El FSB, el BIS y la FCA coinciden: la IA de frontera no cambia los fundamentos de la ciberresiliencia, pero sí la velocidad. Qué implica para parcheo, proveedores, autenticación y respuesta.

Lectura de 8 min

El 31 de agosto, Andrew Bailey, presidente del Consejo de Estabilidad Financiera (FSB), escribió a los ministros de Finanzas y gobernadores de bancos centrales del G20 que el riesgo más inmediato de la IA de frontera para el sistema financiero es su impacto en la ciberresiliencia. No habló de chatbots ni de productividad: habló de modelos capaces de alterar “la velocidad, la escala y la economía” del riesgo cibernético. En las mismas semanas, el Banco de Pagos Internacionales (BIS) publicó dos documentos sobre el tema y la FCA británica difundió una revisión con lo que espera ver en las entidades.

Leídos juntos, no piden un marco nuevo: piden que lo que ya hacemos en vulnerabilidades, proveedores y respuesta a incidentes funcione a otra velocidad. Desde la operación de infraestructura de mensajería crítica para banca, lo leo como una lista de trabajo de arquitectura. Te comparto qué dicen y cómo lo traduzco a diseño.

Qué dijeron los organismos entre julio y septiembre

La secuencia es corta y bastante coherente:

  • BIS, 20 de julio. El Boletín 129 plantea que los modelos de frontera aumentan la velocidad, escala y complejidad de los ataques, pero también fortalecen la defensa, con costos asimétricos que pueden favorecer al atacante. Un dato: los CVE críticos reportados pasaron de unos 10 por día en 2022–25 a casi 20 por día después del 1 de abril de 2026.
  • FSB, 31 de agosto. La carta al G20 pide apoyar una liberación y un despliegue seguros de los modelos, y capacidades sólidas de respuesta y recuperación, con resiliencia en los proveedores tecnológicos críticos.
  • FCA, 2 de septiembre. Su revisión observa que el descubrimiento de vulnerabilidades se acelera más rápido que la capacidad de las firmas para responder, y describe la IA de frontera como una prueba de estrés de la ciberresiliencia existente.
  • BIS, 9 de septiembre. El FSI Occasional Paper 28 concluye que la IA de frontera no cambia los fundamentos de la ciberresiliencia, pero aumenta mucho la velocidad y la intensidad con que deben ejecutarse, y señala el software sin parchear como vector de acceso inicial principal en muchos incidentes.

El 10 de septiembre, el gerente general del BIS, Pablo Hernández de Cos, lo sintetizó así: el atacante necesita encontrar una sola vulnerabilidad; el defensor debe proteger todo el sistema. Como contexto, en junio el FSB había puesto en consulta 12 buenas prácticas para adoptar IA; dos tocan esto de lleno: riesgo cibernético y de TIC, y riesgo de terceros.

Ciberresiliencia con IA de frontera: el cuello de botella es el ciclo de parcheo

Si el volumen de vulnerabilidades descubiertas se duplica, el problema deja de ser encontrarlas y pasa a ser procesarlas. La FCA lo plantea como una pregunta directa a las firmas: dónde están los cuellos de botella probables en la validación, la remediación, las pruebas de parches y la implementación de cambios. Esa pregunta es, en el fondo, una pregunta de arquitectura.

En plataformas que no pueden detenerse, el parche rara vez es lo difícil; lo difícil es desplegarlo sin afectar el servicio. Lo que estoy priorizando:

  • Inventario vivo de componentes. No puedes priorizar lo que no sabes que tienes: librerías, imágenes base, runtimes y servicios gestionados, mapeados contra los servicios de negocio que soportan.
  • Priorización por explotabilidad, no por puntaje. La FCA sugiere ordenar hallazgos por explotabilidad, exposición, posibilidad de encadenarse, controles compensatorios e impacto en servicios importantes. Con el doble de CVE críticos, ordenar solo por severidad satura al equipo.
  • Despliegues que hagan barato parchear. Infraestructura inmutable, despliegues por etapas y rollback automático. Si cada parche exige una ventana de mantenimiento negociada, el ciclo no alcanzará el ritmo que describen estos documentos.
  • Reducir lo expuesto. El BIS menciona sistemas heredados, código abierto, terceros y activos expuestos a internet. Acotar la superficie expuesta con gateways y APIs bien delimitadas compra tiempo para todo lo demás.

Hay un matiz que la FCA describe bien: distinguir entre hallazgos técnicamente plausibles y hallazgos genuinamente explotables. Usar modelos para revisar código es útil, pero sus resultados necesitan revisión de alguien con contexto de ciberseguridad, tecnología y negocio. Si no, cambias un cuello de botella por otro.

El proveedor crítico también está en el perímetro

El FSB menciona por nombre a los proveedores tecnológicos críticos, y su documento de buenas prácticas describe la concentración en varias capas de la cadena de suministro de IA: nube, hardware, modelos fundacionales, datos y plataformas de despliegue. El paper del BIS añade que la interrupción o una decisión de política de un solo proveedor puede propagarse entre firmas y jurisdicciones.

Para quienes operamos servicios de los que dependen los bancos, las preguntas de los equipos de riesgo de terceros van a cambiar. Anticipo cuatro; conviene tener la respuesta documentada antes de que lleguen:

  • Cuál es tu tiempo real de remediación de vulnerabilidades críticas y cómo lo mides.
  • Qué dependencias de terceros tienes, incluidas las de IA, y qué pasa si una cambia su modelo sin aviso suficiente (un riesgo que el FSB menciona explícitamente).
  • Cómo y en cuánto tiempo notificas un incidente que afecte al banco.
  • Qué componentes compartes entre clientes y cómo aíslas un incidente para que no se propague.

La FCA invita a colaborar con terceros para escalar riesgos materiales de dependencia. Desde el lado del proveedor, eso significa tratar los cuestionarios de seguridad como un canal de coordinación, no como un trámite. En mi experiencia como auditor interno de ISO/IEC 27001, los controles de proveedores funcionan mejor cuando ambas partes comparten el mismo mapa de dependencias.

Autenticación y canales: capas que se complementan

El documento del FSB describe la ingeniería social amplificada por IA: audio, imagen y video cada vez más realistas para suplantar a quien aprueba operaciones de alto valor o para evadir controles de identificación. La respuesta de diseño no es nueva, pero sí más urgente: ninguna decisión importante debería depender de un solo factor imitable. En atención y canales de voz, eso se traduce en principios sencillos:

  • La voz inicia, no autoriza. Una llamada puede abrir un trámite, pero la confirmación de algo sensible debe ocurrir por un canal independiente y previamente registrado.
  • El OTP sigue siendo la confirmación explícita del usuario. Las señales de red, dispositivo o comportamiento y los modelos de riesgo aportan contexto para decidir cuándo pedir un paso adicional: un complemento que hace al OTP más inteligente, no un reemplazo.
  • Devolver la llamada. Para validaciones internas de alto valor, llamar a un número del directorio, no al que llamó, sigue siendo de los controles más baratos y efectivos.
  • Fricción proporcional al riesgo. Concentrarla donde el riesgo es alto permite sostener controles fuertes sin degradar la experiencia.

Escribí más sobre por qué el canal debe ser verificable de punta a punta en identidad de las comunicaciones; con modelos generativos más capaces, ese argumento gana peso.

IA para defender, con responsabilidad humana clara

El Boletín 129 del BIS considera esencial adoptar con rapidez modelos de frontera para revisar bases de código y corregir vulnerabilidades. La declaración conjunta de la FCA, el Banco de Inglaterra y el Tesoro británico, de mayo, ya sugería considerar defensas automatizadas y habilitadas por IA. El mensaje es claro: la defensa también tiene que usar estas herramientas.

El FSB agrega una advertencia útil para el diseño. La supervisión humana en tiempo real se vuelve poco práctica cuando agentes de IA toman cientos de pasos intermedios, y en algunos casos el monitoreo efectivo puede requerir apoyarse en otro agente o en otras formas de IA. Eso no elimina la responsabilidad humana; la reubica. Lo que propongo:

  • Inventario de IA. El FSB recomienda uno centralizado con propósito, materialidad, dependencias, responsables y aprobaciones; para agentes, también las herramientas a las que acceden y sus salvaguardas.
  • Dueños con nombre. La FCA pregunta quién es dueño de las decisiones sobre el uso de IA de frontera en ciberresiliencia. “El equipo” todavía no es una respuesta.
  • Permisos mínimos para agentes. Un agente que revisa código no necesita credenciales de producción.
  • Escalamiento predefinido. Qué hallazgo se atiende de inmediato, cuál espera y quién decide cuando hay duda.

Respuesta y recuperación: decidir rápido también se diseña

El paper del BIS insiste en estructuras de gobierno que permitan decidir a tiempo durante un incidente. Suena organizacional, pero es muy técnico: si aislar un componente, rotar credenciales o activar una ruta alternativa exige coordinar a seis personas, esa velocidad no se alcanza.

Tres prácticas que recomiendo revisar este trimestre: runbooks ejecutables, no documentos que nadie abre; ejercicios de mesa con escenarios de IA, como pide el FSB para las pruebas; y una matriz clara de quién puede decidir qué sin esperar aprobación. La FCA lo resume al pedir que los controles operen como un sistema interconectado y no como procesos separados.

Nada de esto es exclusivo de la IA de frontera, y eso es una buena noticia: el trabajo que pide el contexto actual es el que ya sabíamos que debíamos hacer, con menos margen para posponerlo.

Fuentes

¿Estás evaluando esto ahora? Si tu equipo está revisando su ciclo de parcheo, sus dependencias de proveedores o cómo encaja la IA en su operación de seguridad, escríbeme: es una conversación que estoy teniendo bastante seguido.

Seguir leyendo

¿Te sirvió? Compártelo con tu equipo:Compartir en LinkedIn

Sigue leyendo