IA de voz en la banca: Normas de BaFin y DORA para 2026

IA de voz en la banca: Qué significa la guía de BaFin sobre IA bajo DORA para los agentes telefónicos de IA

Sí, los bancos y aseguradoras pueden implementar agentes telefónicos de IA, pero desde la guía de orientación de BaFin sobre IA bajo DORA (febrero de 2026), no como un proyecto de innovación ajeno a la TI. Un agente telefónico de IA es ahora un activo TIC convencional dentro del marco de gestión de riesgos TIC existente. El movimiento decisivo: el supervisor se aleja de la clasificación de riesgos de la Ley de IA de la UE y define los sistemas de IA en términos puramente técnicos como "redes y sistemas de información". La IA pierde su estatus regulatorio especial.

Para los responsables de la toma de decisiones en las entidades de crédito, esto es concreto: la pregunta ya no es "¿es nuestra IA de voz de alto riesgo?", sino "¿está en el inventario de activos, clasificada por riesgo, monitorizada, cubierta por planes de continuidad y respaldada por una estrategia de salida probada?". Este artículo traduce la guía en un marco práctico para la telefonía.

El mensaje principal: la IA es un activo TIC, no un tema especial

La Ley de IA de la UE clasifica los sistemas de IA por riesgo, desde aplicaciones prohibidas hasta IA de alto riesgo, pasando por riesgo limitado o mínimo. A esa clasificación se asocian obligaciones graduadas: transparencia, documentación, calidad de los datos y supervisión humana.

Para las empresas financieras, esa visión centrada en el producto se queda corta. No responde a la verdadera cuestión de gobernanza: ¿cómo integrar una aplicación de IA, independientemente de su clase de riesgo ético, de forma segura en el panorama informático existente y mantenerla bajo control operativo? Ahí es donde interviene BaFin.

El razonamiento del supervisor es sencillo y eficaz. Un sistema de IA es "basado en máquinas", lo que significa que consta de hardware y software. Eso lo convierte en una "red y sistema de información" bajo DORA y, por tanto, en un activo TIC convencional. Se derivan tres consecuencias:

• Integración en lugar de aislamiento: La IA ya no es un tema de innovación aislado. Debe estar integrada en el marco de gestión de riesgos TIC existente y documentado. Un agente de voz que una unidad de negocio esté "probando" al margen de la TI es, en términos de supervisión, TI en la sombra.
• Enfoque en el ciclo de vida: en lugar de una revisión de riesgos única antes del lanzamiento, BaFin espera una supervisión continua durante todo el ciclo de vida técnico, desde el desarrollo y el entrenamiento hasta la operación en vivo y la retirada segura y eliminación de datos.
• Responsabilidad y resiliencia: el cumplimiento no se mide solo por la transparencia algorítmica, sino por la resiliencia operativa del sistema general frente a interrupciones, manipulaciones como el envenenamiento de datos y ciberataques.

Con esto, BaFin cierra la brecha entre los requisitos abstractos de la Ley de IA y la realidad operativa en los centros de datos y entornos en la nube del sector financiero. Si ya has trabajado con la lista de verificación de cumplimiento de la Ley de IA de la UE para IA de voz, no has terminado: la capa DORA se sitúa por encima.

A quién se dirige la guía

BaFin deriva el alcance directamente de la propia estructura de DORA. Se dirige principalmente a las empresas financieras que deben aplicar el marco completo de gestión de riesgos TIC según los artículos 5 a 15 de DORA, en particular las entidades de crédito CRR y las empresas de seguros bajo Solvencia II.

Para esas instituciones, la guía debe tratarse como la lectura autorizada de las expectativas de supervisión, aunque el documento esté etiquetado formalmente como una "ayuda no vinculante". En la práctica, define el futuro punto de referencia de auditoría. Las empresas financieras que caen bajo el marco simplificado del artículo 16 de DORA, como las pequeñas empresas de inversión o las pequeñas entidades de pago, no son destinatarias directas; ahí se requiere una evaluación por separado.

Proporcionalidad: dónde se sitúa realmente tu agente de voz

Un elemento clave es el principio de proporcionalidad del artículo 4 de DORA. Los requisitos se ajustan al perfil de riesgo y a la relevancia sistémica. Para la práctica de gobernanza, esto significa diferenciar según la criticidad de la función apoyada:

• Funciones críticas o importantes: aplicaciones de IA que dirigen procesos de negocio materiales o toman decisiones con un impacto directo en la posición financiera o los resultados, por ejemplo, algoritmos de calificación crediticia o procesamiento directo de reclamaciones. Aquí son obligatorios controles y medidas de seguridad integrales, incluidas pruebas de resiliencia extendidas y deberes de documentación intensivos.
• Funciones de apoyo: sistemas de IA de menor riesgo bajo supervisión humana continua que no toman decisiones autónomas. Aquí, las salvaguardas pueden reducirse en la medida adecuada según el principio de proporcionalidad.

Para las aplicaciones de telefonía, esta distinción es la decisión de diseño más importante. Un agente de voz no es intrínsecamente crítico; se vuelve crítico por lo que le permites decidir. El siguiente mapeo muestra escenarios bancarios típicos:

La implicación práctica: tu clasificación de los sistemas de IA respecto al apoyo a funciones críticas debe estar documentada, para que la adecuación de las medidas tomadas sea demostrable ante los auditores y el supervisor. Las instituciones que deliberadamente se mantienen en funciones de apoyo durante el despliegue, delegando cualquier cosa con impacto financiero a un humano, acortan considerablemente el tiempo de producción. La transferencia de llamadas a un agente humano no es, por tanto, un detalle de la función, sino una palanca de control regulatorio.

La base: estrategia y gobernanza

La estrategia y la gobernanza forman la base de la gestión de riesgos continua. La guía nombra tres pilares.

Integración estratégica y hoja de ruta. El órgano de administración debe adoptar una estrategia de IA integrada de forma coherente en la estrategia empresarial y DORA más amplia. A diferencia de la TI estándar, la IA requiere una hoja de ruta tecnológica para dirigir las necesidades de recursos específicos (cómputo, volúmenes de datos) y la inversión necesaria con antelación.

Responsabilidad de la junta y alfabetización en IA. La responsabilidad última de los riesgos de la IA recae en el órgano de administración según el artículo 5 de DORA: la junta completa. Eso presupone una experiencia demostrable para evaluar de forma independiente cómo las decisiones algorítmicas afectan al modelo de negocio. La responsabilidad de los resultados de la IA debe asignarse sin lagunas entre la TI y la parte comercial.

Preparación de procesos e integración del control interno. Antes de la implementación técnica, los procesos de negocio deben validarse por su idoneidad para manejar resultados probabilísticos, es decir, no deterministas. Los proveedores externos de TIC involucrados requieren una evaluación de riesgos por separado. Las funciones de control interno (gestión de riesgos, cumplimiento, auditoría interna) deben incorporarse al ciclo de vida de forma temprana y proporcionada.

Ese último punto es el más subestimado en la práctica. Un modelo de lenguaje responde de forma probabilística: la misma pregunta puede producir dos frases ligeramente diferentes. Un proceso que depende de una salida idéntica palabra por palabra no es adecuado para la IA, por muy bueno que sea el modelo.

Desarrollo y pruebas: TI en la sombra y la cadena de suministro

Para la fase de aprovisionamiento, la guía destaca dos temas.

Integridad de la cadena de suministro. Se debe evitar la TI en la sombra no regulada en las unidades de negocio; las soluciones de bajo código están igualmente sujetas a los estándares DORA. Esto es especialmente importante para la IA de voz, porque las plataformas modernas son deliberadamente lo suficientemente simples como para que una unidad de negocio pueda ponerse en marcha sin TI. Ese es precisamente el error. También debe garantizarse la integridad de la cadena de suministro: validación estricta de los datos de entrenamiento contra el envenenamiento de datos, además de una revisión rigurosa de las bibliotecas de código abierto y el código generado por IA.

Desarrollo seguro y estrategias de prueba extendidas. Para controlar el problema de la caja negra, el proceso de desarrollo debe actuar como una red de seguridad: versionado completo del código, datos de entrenamiento y parámetros del modelo, además de una gestión de cambios estricta para las actualizaciones del modelo, incluidas estrategias de reversión probadas. Debido a que las pruebas funcionales convencionales a menudo fallan frente a la IA probabilística, las pruebas deben ampliarse: las pruebas adversarias simulan ataques dirigidos y, para la IA generativa, la revisión humana asegura la seguridad de los resultados.

Para los agentes de voz, el "versionado" cubre no solo el modelo, sino el prompt del sistema y la base de conocimientos. Cambiar el prompt de un agente bancario en vivo sin aprobación y sin una ruta de reversión es un cambio no documentado, con las mismas consecuencias de supervisión que un despliegue no documentado en el sistema bancario central.

Operación en vivo y retirada: las cuatro áreas de acción

Para la fase operativa, la guía convierte los artículos 8 a 11 de DORA en cuatro áreas de acción. La siguiente tabla los traduce en requisitos para una plataforma de IA de voz:

Cabe destacar que el ciclo de vida termina solo con la retirada segura: los modelos y datos obsoletos deben eliminarse de forma irrecuperable para evitar fugas o usos indebidos. Casi nadie planifica esto de antemano, y los auditores lo preguntan de forma fiable.

En el lado de la plataforma, estos no son requisitos exóticos. El historial de llamadas y el análisis post-llamada proporcionan los registros de inferencia que exigen los artículos 8 y 10; mediante API y webhooks, esos datos pueden reflejarse en el SIEM o almacén de datos existente de la institución en lugar de vivir en un panel de terceros.

Integración y nube: el verdadero obstáculo

Debido a que los sistemas de IA capaces se entregan principalmente a través de infraestructura de nube externa en lugar de un centro de datos interno, la guía se concentra en controlar esos riesgos de externalización. Para la IA de voz, esta es la sección crítica: prácticamente todas las plataformas son un acuerdo de externalización.

Evaluación de riesgos extendida y diligencia debida. Antes de la firma del contrato, el inventario de riesgos debe anticipar factores dinámicos como el reentrenamiento del modelo o cambios en la estructura del modelo. La diligencia debida no puede detenerse en el proveedor; debe evaluar explícitamente el riesgo de salida no autorizada de datos y la idoneidad del proveedor frente a los estándares técnicos y regulatorios.

Ciberseguridad específica de la nube. Para entornos de entrenamiento o inferencia alojados externamente, deben identificarse y defenderse vectores de ataque como el envenenamiento de datos o ataques adversarios. Cuando se externalizan funciones críticas o importantes, un nivel de seguridad "adecuado" no es suficiente: el proveedor debe cumplir demostrablemente con los estándares actuales más altos.

Transparencia en toda la cadena de contratos. Controlar la subcontratación sin lagunas es decisivo, porque los sistemas de IA a menudo dependen de cadenas de suministro complejas. La institución debe saber en todo momento dónde tiene lugar físicamente el procesamiento de datos. Los SLA deben abordar de forma vinculante la sensibilidad de los modelos de IA a la latencia y la capacidad de cómputo, respaldados por derechos de auditoría exigibles en profundidad en la cadena.

Estrategia de salida y dependencia del proveedor. Debido a que los servicios de IA en la nube propietarios fomentan la dependencia, los contratos deben asegurar la exportación de modelos, datos de entrenamiento y metadatos en formatos interoperables. Son obligatorias las copias de seguridad regulares en almacenamiento independiente y escenarios de migración validados.

Para la selección de proveedores, esto significa: una plataforma que posee tu número de teléfono, no revela el modelo y bloquea la exportación de datos de conversación es difícil de justificar bajo DORA. Por el contrario, BYOC (trae tu propio operador) desactiva dos puntos a la vez: la institución mantiene el control de sus números y su contrato de telefonía, y cambiar de proveedor sigue siendo posible sin que los clientes marquen un nuevo número. Esa es una estrategia de salida que realmente se sostiene, en lugar de una declaración de intenciones. El acuerdo de procesamiento de datos y las divulgaciones de procesamiento de datos adjuntas proporcionan la base para tu archivo de diligencia debida.

Implementación paso a paso

1. Definir el caso de uso. Comienza deliberadamente con funciones de apoyo: horario de apertura, reserva de citas, enrutamiento, preguntas frecuentes. Todo lo que tenga impacto financiero permanece con humanos por ahora.
2. Documentar la criticidad. Escribe por qué el agente no apoya una función crítica o importante. Ese razonamiento es tu evidencia de proporcionalidad bajo el artículo 4 de DORA.
3. Añadirlo al inventario de activos. Modelo, versión de prompt, base de conocimientos, voz, número de teléfono, proveedor y subproveedores, con un propietario nombrado.
4. Ejecutar la revisión de externalización. Diligencia debida del proveedor, aclarar ubicaciones de procesamiento, divulgar la cadena de subprocesadores, acordar derechos de auditoría y SLA sobre latencia y disponibilidad.
5. Probar antes de la puesta en marcha. Pruebas funcionales, pruebas de carga a densidad de llamadas realista, pruebas adversarias contra inyección de prompts, evaluación humana de la calidad de las respuestas.
6. Configurar la monitorización. No solo disponibilidad: tasa de abandono, tasa de escalada, calidad de respuesta, latencia. Alertas sobre deriva. Refleja los registros en tus propios sistemas.
7. Probar BCM y salida. Volver al enrutamiento o a un anuncio en caso de interrupción. Ejecuta la exportación de artefactos una vez de verdad; no te limites a aceptar una garantía contractual.
8. Establecer gestión de cambios. Cada cambio de prompt o modelo pasa por aprobación, pruebas y una ruta de reversión documentada.
9. Planificar la retirada. Define ahora cómo se eliminarán de forma segura las versiones de modelos obsoletas y los datos de conversación.

Mejores prácticas y errores comunes

• Error: la unidad de negocio comienza sola. Marketing o las operaciones de sucursal "prueban rápidamente" un agente de voz. Eso es exactamente la TI en la sombra a la que se refiere BaFin, incluido el no-código.
• Error: cambios de prompt sin un proceso de cambio. El prompt es configuración de producción, no un campo de texto. Versiona, aprueba y mantén una reversión lista.
• Error: monitorizar solo la disponibilidad. Un agente puede ser 100% alcanzable y aun así haber estado respondiendo peor durante tres semanas. El artículo 10 pide detección de anomalías, no tiempo de actividad.
• Error: salida solo en papel. Una cláusula de salida sin una exportación probada no es una salida. Ensaya la migración una vez.
• Mejor práctica: autenticar antes de revelar. Cualquier cosa más allá de la información pública solo después de una identificación limpia, idealmente mediante entrada de teclado en lugar de un número de cuenta hablado.
• Mejor práctica: escalada como predeterminado. Un agente que transfiere limpiamente a un humano cuando no está seguro sigue siendo una función de apoyo, la palanca de cumplimiento más barata disponible.
• Mejor práctica: mantener los registros internamente. Si los datos de conversación viven solo en un panel de proveedor, el linaje de datos es difícil de demostrar. Refléjalos en tu SIEM.

Ejemplo práctico: un banco regional con 40 sucursales

Un banco regional con 40 sucursales y unos 600 empleados tiene un problema clásico: los lunes por la mañana entre las 9 y las 11, el volumen de llamadas alcanza picos tan altos que una parte sustancial de los llamantes abandona la cola. Las solicitudes son mayoritariamente mundanas: horarios de apertura, citas con asesores, preguntas sobre qué documentos llevar.

El alcance regulatoriamente limpio: el agente de voz responde, contesta preguntas de horario de apertura y documentos desde una base de conocimientos mantenida, reserva citas de asesoramiento y enruta todo lo demás a un humano. Sin información de cuenta, sin bloqueo de tarjeta, sin precalificación. Eso lo convierte en una función de apoyo: documentada, justificada, registrada en el inventario.

Los números de teléfono permanecen con el operador existente de la institución mediante BYOC, los datos de conversación fluyen por webhook hacia el propio almacén de datos del banco, y el respaldo durante un incidente de plataforma es el enrutamiento clásico a la línea de la sucursal. La evidencia DORA sigue siendo proporcionada, y el camino hacia la siguiente etapa de expansión está abierto, porque el inventario, el proceso de cambio y la monitorización ya existen.

Conclusión

Con esta guía, BaFin convierte los requisitos regulatorios abstractos en un marco operativo. Incluso sin el estatus de circular, el documento define efectivamente el futuro estándar de oro para la práctica de auditoría. Para los agentes telefónicos de IA en la banca, la ruta no pasa por la pregunta de si puedes, sino por el inventario de activos, la clasificación de criticidad documentada, la monitorización real, los planes de continuidad probados y una estrategia de salida creíble.

La buena noticia: las instituciones que limitan el caso de uso a funciones de apoyo y delegan las acciones con impacto financiero a humanos pueden proceder de forma proporcionada y llegar a producción mucho más rápido. Famulor está construido exactamente para eso: alojamiento en la UE, un acuerdo de procesamiento de datos, BYOC para un control total sobre números y operador, registros de llamadas exportables para el linaje de datos y una ruta de transferencia limpia al personal humano.

Siguiente paso: habla con nuestro equipo empresarial sobre tu caso de uso específico y la documentación de externalización, o mira cómo Famulor apoya a los servicios financieros hoy. Si necesitas primero el caso de negocio, la calculadora de ROI muestra en minutos lo que ahorra automatizar tus llamadas.

Preguntas frecuentes

¿Puede un banco implementar un agente telefónico de IA?

Sí. BaFin no prohíbe la telefonía con IA; clasifica los sistemas de IA como activos TIC convencionales bajo DORA. La implementación es permisible si el agente está registrado en el inventario de activos, clasificado por riesgo, monitorizado y cubierto por planes de continuidad.

¿Cuál es el mensaje central de la guía de BaFin sobre IA bajo DORA?

Los sistemas de IA son "redes y sistemas de información" y, por tanto, activos TIC convencionales. Pierden su estatus regulatorio especial y deben integrarse completamente en el marco de gestión de riesgos TIC existente durante todo el ciclo de vida.

¿A quién se dirige la guía?

Principalmente a las empresas financieras que aplican el marco completo de gestión de riesgos TIC bajo los artículos 5 a 15 de DORA, especialmente las entidades de crédito CRR y las aseguradoras Solvencia II. Las empresas bajo el marco simplificado del artículo 16 de DORA no son destinatarias directas.

¿Es un agente de voz una función crítica?

No automáticamente. Lo que importa es si toma decisiones autónomas que afecten a la posición financiera o a los resultados. La información y la reserva de citas suelen ser funciones de apoyo; el bloqueo de tarjetas o la precalificación crediticia no lo son.

¿Qué exige BaFin al externalizar a un proveedor de nube?

Diligencia debida extendida que incluya el riesgo de salida de datos, transparencia en toda la cadena de subprocesadores, SLA sobre latencia y capacidad de cómputo, derechos de auditoría exigibles y una estrategia de salida con exportación en formatos interoperables.

¿Quién es responsable de los riesgos de IA dentro de la institución?

La responsabilidad última recae en el órgano de administración según el artículo 5 de DORA: la junta completa. Eso requiere experiencia demostrable ("alfabetización en IA") y una asignación de responsabilidades sin lagunas entre la TI y el negocio.

¿Es suficiente cumplir con la Ley de IA de la UE?

No. La Ley de IA regula los deberes relacionados con el producto y la aplicación por clase de riesgo. DORA y la guía de BaFin añaden requisitos operativos para la resiliencia, monitorización, externalización y gestión de la continuidad.

¿Qué cuenta como TI en la sombra en un contexto de IA de voz?

Una unidad de negocio que pone en marcha un agente de voz sin TI, cumplimiento y auditoría interna. BaFin deja claro que las soluciones de bajo código y sin código están igualmente sujetas a los estándares DORA.

¿Cómo ayuda BYOC con la estrategia de salida?

Con BYOC, los números de teléfono y el contrato de telefonía permanecen con la institución. Cambiar de proveedor es posible sin cambiar de número, una estrategia de salida que se sostiene en la práctica, no solo como cláusula contractual.

¿Cuándo termina el ciclo de vida de un sistema de IA?

Solo en la retirada segura. Los modelos obsoletos, los artefactos del modelo y los datos asociados deben eliminarse de forma irrecuperable para evitar fugas y usos indebidos. Planifica esto antes de la puesta en marcha, no después.