El 66% de las firmas financieras ya detecta IA no autorizada: no es una anécdota, es un problema de control interno

La cifra merece menos entusiasmo del que suelen ponerle los departamentos de marketing y bastante más atención por parte de riesgo, compliance y seguridad: el 66% de las empresas financieras afirma haber detectado uso de inteligencia artificial no autorizada entre sus empleados, según el último Enterprise Cloud Index de Nutanix para servicios financieros, difundido por Cybersecurity News ES.

No estamos ante una travesura de oficina. Tampoco ante el clásico “shadow IT” reconvertido en tendencia de LinkedIn. Cuando un empleado usa un copiloto generativo, un resumidor de documentos o un chatbot externo sin validación previa, pueden entrar en juego datos de clientes, información sensible de mercado, secretos de negocio, decisiones automatizadas mal gobernadas y, en el peor caso, una cadena de responsabilidad que nadie quiere firmar después. Ese 66% no habla solo de adopción espontánea. Habla de pérdida de control.

Y aquí está el matiz incómodo: el sector financiero lleva años afinando marcos de control para cloud, outsourcing, continuidad, fraude y ciberresiliencia. Llegan DORA, NIS2 y el AI Act, y uno podría pensar que la disciplina de gobierno ya estaba razonablemente madura. Pero la IA generativa ha entrado por una puerta mucho más humana y mucho menos ordenada: productividad individual, presión comercial y herramientas aparentemente inocuas. El resultado es un agujero de gobernanza justo donde más duele, en el uso cotidiano.

La noticia no va de que los bancos “adopten IA”. Eso ya lo sabíamos. Va de que la están adoptando por las malas: antes de tener inventario, criterios de clasificación de datos, cláusulas contractuales, controles de salida, monitorización y reglas claras para empleados y proveedores. En fin, la versión corporativa del “ya lo arreglaremos luego”, que en finanzas suele salir especialmente caro.

Lo que revela de verdad ese 66%

Tomada de forma aislada, la cifra podría parecer solo otro porcentaje llamativo de encuesta tecnológica. No lo es. En servicios financieros, detectar IA no autorizada significa al menos una de estas cuatro cosas, y a menudo varias a la vez.

Primero, que los controles preventivos no están donde deberían. Si el uso no autorizado se descubre después, la organización probablemente carece de una política eficaz de herramientas aprobadas, de filtros de navegación y DNS, de controles de CASB o SSE, o de reglas DLP adaptadas a aplicaciones de IA generativa. No basta con prohibir ChatGPT, Copilot, Claude o cualquier herramienta que venga mañana con otro nombre más elegante. La prohibición sin arquitectura técnica suele durar lo que tarda alguien en abrir una pestaña de incógnito.

Segundo, que el inventario de datos y procesos sigue siendo más débil de lo que se reconoce en comités. La pregunta clave no es si un empleado ha usado una IA externa, sino qué introdujo en ella: ¿un extracto con datos personales? ¿una política de crédito? ¿un borrador de contrato con cláusulas confidenciales? ¿un informe de auditoría interna? El riesgo cambia por completo según la respuesta. Sin clasificación operativa de la información y sin guías de uso por contexto, la empresa convierte cada empleado en su propio comité de ética y seguridad. Suerte con eso.

Tercero, que el problema no pertenece solo al CISO. También es un asunto de control interno, modelo operativo y responsabilidad de primera línea. Si un analista de riesgos usa una IA externa para resumir expedientes, si un comercial la usa para preparar propuestas con datos de clientes o si RR. HH. la emplea para filtrar currículos, el incidente no es puramente tecnológico. Afecta a privacidad, sesgos, secreto profesional, conservación de evidencias y potencialmente a decisiones con impacto legal.

Cuarto, que la gobernanza de terceros se queda corta si solo mira a los grandes proveedores. DORA se ha centrado, con razón, en terceros TIC críticos y en la cadena de suministro. Pero el uso real de IA en una organización no empieza siempre con un gran contrato marco. Empieza, muchas veces, con una suscripción de 20 euros al mes pagada con tarjeta corporativa o con la versión gratuita de una herramienta usada desde el navegador. El proveedor material para el riesgo puede no ser el que sale en el mapa oficial de outsourcing. Puede ser el que nadie ha registrado.

No es solo AI Act: DORA, GDPR y NIS2 ya convierten este fenómeno en un asunto regulatorio

La tentación fácil sería encajar la noticia solo bajo el AI Act. Error. El uso de IA no autorizada en finanzas pisa a la vez varios marcos normativos ya vigentes o inminentes. Y algunos tienen dientes antes que el propio AI Act despliegue todas sus obligaciones.

Empieza por GDPR. Si un empleado introduce datos personales en una herramienta de IA externa, la primera pregunta jurídica es de manual: ¿quién trata esos datos, con qué base legal, para qué finalidad y bajo qué condiciones? Si la herramienta actúa como encargado, debe haber contrato conforme al artículo 28 del RGPD. Si reutiliza entradas para entrenamiento u otros fines propios, la cosa deja de parecerse a un encargo de tratamiento limpio. Si además hay transferencia internacional, entran las reglas del capítulo V del RGPD. Y si se produce una divulgación no autorizada o acceso indebido, la organización podría verse ante una brecha de datos personales notificable bajo el artículo 33, con el famoso plazo de 72 horas.

La parte desagradable es que muchas empresas siguen analizando la IA como si fuera solo un problema de productividad. No lo es. Es un vector de tratamiento de datos. Y eso, en banca, seguros o pagos, significa que privacidad y secreto profesional deben sentarse a la mesa desde el minuto uno.

Luego está DORA, aplicable desde el 17 de enero de 2025. Aunque DORA no es una ley “de IA”, sí exige que las entidades financieras gestionen riesgo TIC de forma integral. El reglamento dedica el artículo 5 al marco de gestión del riesgo TIC, el artículo 6 a su documentación y revisión, el artículo 9 a la protección y prevención, y el bloque de artículos 28 a 30 al riesgo derivado de terceros proveedores de servicios TIC. Si el uso de IA externa entra por navegadores, plugins, APIs o aplicaciones SaaS no evaluadas, el problema no es semántico: es que la entidad podría estar operando fuera de su propio perímetro de control de terceros y de seguridad.

Hay un punto fino que conviene no perder de vista. DORA obliga a saber qué depende de quién y dónde están los puntos de fallo. La IA generativa, en cambio, mete opacidad por diseño: servicios compuestos, subencargados, modelos de terceros, procesamiento transfronterizo, retención de prompts y salidas difíciles de auditar. Si tu mapa de dependencias ya era complejo con cloud y outsourcing clásico, espera a mezclarlo con copilotos integrados en suites ofimáticas y herramientas conectadas por API. El regulador no va a aceptar “no lo sabíamos” como estrategia de resiliencia.

NIS2 también asoma, sobre todo para entidades esenciales e importantes de sectores cubiertos. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de ciberseguridad. Ahí entran políticas de análisis de riesgos, seguridad en la cadena de suministro, procedimientos de evaluación de eficacia y formación básica en ciberhigiene. Si la empresa sabe que existe uso no autorizado de IA y no articula controles, el argumento de diligencia se deteriora bastante. Traducido: cuando el problema es conocido y recurrente, deja de ser una excepción y pasa a ser un fallo de gestión.

Y luego sí, está el AI Act. Su entrada en aplicación es escalonada. El reglamento (UE) 2024/1689 entró en vigor el 1 de agosto de 2024, con prohibiciones que aplican antes que otras obligaciones y con plazos diferenciados para modelos GPAI y sistemas de alto riesgo. No toda herramienta generativa usada por empleados convertirá automáticamente a la entidad en proveedor o desplegador de un sistema de alto riesgo. Pero pensar que el AI Act no afecta porque “solo usamos asistentes” sería una lectura de becario con exceso de confianza. En finanzas, la IA puede tocar selección de personal, atención al cliente, prevención de fraude, scoring interno, documentación contractual, vigilancia de transacciones o controles AML. El mapa regulatorio cambia rápido según el caso de uso concreto.

El sector financiero tiene un problema específico: la IA entra por donde antes entró el shadow IT, pero con mucho más riesgo de salida de datos

La banca y los seguros conocen bien el fenómeno del shadow IT. Durante años, el patrón fue el mismo: negocio iba más rápido que tecnología, aparecían herramientas no aprobadas, seguridad intentaba poner orden y, meses después, se acababa institucionalizando una parte del caos. La IA generativa repite esa secuencia, pero añade dos agravantes.

El primero es la facilidad de exfiltración semántica. No hace falta descargar una base de datos entera para generar un problema serio. Basta con pegar un resumen de una reclamación compleja, un borrador de due diligence, una cadena de correos con datos de cliente o una política interna sensible. La fuga no siempre parece fuga. Esa es la trampa. Desde el punto de vista del usuario, está “pidiendo ayuda” a una herramienta. Desde el punto de vista de seguridad, puede estar sacando información del perímetro con una interfaz simpática y respuestas educadas.

El segundo agravante es la falsa sensación de inocuidad. Con cloud clásico, los responsables entendieron pronto que había contratos, regiones, cifrado, subprocesadores y matrices de responsabilidad. Con la IA de consumo, mucha gente opera bajo una lógica mucho más laxa: “solo le pedí que me resumiera esto” o “solo le pasé un ejemplo”. En una auditoría, esas frases suelen envejecer fatal.

Además, el riesgo no se limita a la confidencialidad. También afecta a integridad y trazabilidad. Si un empleado usa una IA para generar análisis de riesgo, redactar comunicaciones regulatorias o producir código para sistemas internos, la pregunta ya no es solo qué datos salieron, sino qué decisiones entraron de vuelta en la organización sin validación suficiente. Las alucinaciones de modelo no son un meme de internet cuando acaban incrustadas en procesos críticos.

En servicios financieros esto toca nervios especialmente sensibles: abuso de mercado, AML, protección del consumidor, gobierno de modelos, documentación de crédito, gestión de reclamaciones y continuidad operativa. Una respuesta inventada de un chatbot en atención al cliente puede ser un problema reputacional. Una recomendación errónea insertada en un flujo de decisión puede ser bastante más que eso.

La cifra de Nutanix encaja con una realidad más amplia: la adopción va por delante del gobierno

Aunque la noticia se apoya en el estudio de Nutanix, la conclusión coincide con una tendencia mucho más amplia. La IA se está desplegando antes de que maduren los mecanismos de control. No es exclusivo del sector financiero, pero aquí las consecuencias son más visibles porque el perímetro regulatorio es más denso y la tolerancia al error, bastante menor.

Se repite un patrón en muchas entidades. La dirección quiere capturar eficiencias rápido: asistentes para productividad, análisis documental, automatización de soporte, borradores de informes, búsqueda interna mejorada. Todo eso tiene sentido. El problema llega cuando la organización confunde “adoptar IA” con “permitir herramientas”. Adoptar de verdad implica gobernanza de casos de uso, evaluación de impacto, arquitectura de datos, decisiones sobre residencia y retención, validación jurídica, controles de acceso y monitorización. Es decir, trabajo serio. Menos glamour, más disciplina.

La paradoja es bastante elegante, si uno aprecia el humor negro regulatorio: el sector que más invierte en control puede estar dejando que la IA entre por el canal menos controlado, el usuario final. Ni el mejor comité de outsourcing sirve de mucho si el riesgo operativo viaja en un prompt escrito deprisa un martes a las ocho de la tarde.

El informe de Nutanix, al centrarse en nube e IA, también apunta a otro elemento relevante: la convergencia entre modernización cloud y adopción de IA. Esto importa porque gran parte de los controles heredados no se diseñaron pensando en modelos generativos, APIs conversacionales y herramientas embebidas en software de productividad. Muchas políticas internas siguen separando “aplicaciones SaaS”, “desarrollo”, “datos” e “innovación” como si fueran compartimentos estancos. La IA los mezcla todos. Por eso las respuestas fragmentadas suelen fracasar.

Qué debería mirar ahora mismo un CISO, y qué debería mirar compliance aunque no le apetezca

Si tu entidad ha detectado IA no autorizada, el error no es solo técnico ni solo disciplinario. Es de diseño de control. Y la reacción útil no pasa por mandar un correo grandilocuente diciendo que “queda prohibido” sin ofrecer alternativa. Eso sirve para tranquilizar a quien firma el mensaje; no para resolver el riesgo.

El CISO debería empezar por una pregunta brutalmente práctica: ¿dónde está ocurriendo el uso real? Navegador, extensiones, APIs, copilotos integrados, herramientas de developers, suites documentales, móviles corporativos, cuentas personales en dispositivos corporativos. Sin ese mapa, la organización pelea contra una abstracción. Y las abstracciones, en seguridad, son muy caras.

Compliance, por su parte, tiene que dejar de tratar la IA solo como un futuro programa de cumplimiento ligado al AI Act. Ya es un problema actual de privacidad, outsourcing, gobierno de registros, trazabilidad de decisiones y, en algunos casos, conducta. Si la primera vez que compliance entra en la conversación es cuando ya se quiere firmar contrato con un gran proveedor, llega tarde. El riesgo real puede llevar meses circulando por usos informales.

Hay cuatro frentes inmediatos que conviene revisar a la vez.

El primero es clasificación de datos aplicable al uso de IA. No una taxonomía académica guardada en SharePoint, sino reglas operativas: qué tipos de información pueden usarse en herramientas externas, cuáles solo en entornos aprobados y cuáles están completamente vetados. Si una política no la entiende un gestor comercial, no sirve.

El segundo es arquitectura de control. Aquí entran DLP, filtrado web, CASB/SSE, aislamiento del navegador, registro de uso de aplicaciones sancionadas y control de conectores o plugins. Las entidades que ya tienen estos componentes pueden adaptarlos a IA generativa. Las que no, van tarde.

El tercero es contratación y terceros. Si se van a aprobar herramientas, hay que revisar términos de uso, retención de prompts, entrenamiento con datos del cliente, subprocesadores, ubicaciones de tratamiento, opciones empresariales de no entrenamiento y compromisos de seguridad. El artículo 28 del RGPD no se rellena solo, por mucho que algún proveedor insista en que su plantilla contractual “ya cumple con todo”.

El cuarto es validación de salida. La organización suele obsesionarse con lo que entra en la IA y mucho menos con lo que sale de ella. Error clásico. Si empleados usan IA para producir contenido que influye en decisiones, comunicaciones a clientes, reportes internos o código, hace falta control humano significativo, revisión por pares o pruebas específicas según el caso. La automatización sin verificación no es eficiencia; a veces es externalizar errores a velocidad industrial.

La frontera más delicada: empleados, productividad y responsabilidad disciplinaria

Hay un aspecto incómodo que muchas entidades están evitando por miedo a parecer hostiles a la innovación. La mayoría del uso no autorizado de IA no nace de la mala fe. Nace de incentivos. Hacer más con menos tiempo, responder antes, preparar mejor una presentación, sintetizar documentos interminables, automatizar una tarea repetitiva. El empleado no siempre percibe que esté creando un problema. A veces cree, honestamente, que está compensando la lentitud de su propia organización.

Eso obliga a una respuesta más sofisticada que el simple castigo. Si la empresa no ofrece herramientas seguras y aprobadas, no puede sorprenderse demasiado cuando los equipos busquen alternativas. La disciplina es necesaria, sí, pero sin una vía oficial usable el resultado será clandestinidad, no cumplimiento.

Dicho esto, tampoco conviene infantilizar al usuario. En banca, seguros y pagos, los profesionales manejan información sensible por definición. Las políticas internas, el secreto profesional y la formación no son decoración. Si alguien pega datos de cliente en una herramienta no aprobada pese a instrucciones claras, el asunto puede acabar en medidas disciplinarias. Y con razón. El truco está en no confundir error sistémico con conducta individual. A veces será una cosa; a veces, las dos.

Tu entidad debería poder responder, sin tartamudear, a estas preguntas: ¿hay política específica sobre IA generativa? ¿incluye ejemplos concretos de usos prohibidos y permitidos? ¿está conectada con clasificación de información, privacidad y proveedores? ¿hay alternativa corporativa autorizada? ¿se registra el uso? ¿se investiga cuando hay desvíos? Si la respuesta a varias es no, la organización todavía está improvisando.

El AI Act no arreglará por sí solo el caos interno

Conviene rebajar una expectativa que ya circula en algunos despachos: que el AI Act impondrá orden y resolverá el problema por mera existencia normativa. No exactamente. El reglamento europeo es relevante y va a elevar el nivel de exigencia, pero no sustituye la higiene operativa básica. Ningún artículo del AI Act puede compensar una mala clasificación de datos, una falta de inventario de herramientas o una política interna escrita para quedar bien ante auditoría pero inútil en la práctica.

Además, buena parte del uso no autorizado en oficina gira alrededor de herramientas generales, no siempre encajables de forma simple en la categoría de sistemas de alto riesgo. Eso no las vuelve inocuas. Solo significa que el control debe venir de varias capas a la vez: privacidad, seguridad, terceros, formación, procurement y gobernanza de procesos.

El AI Act sí introduce, eso sí, una lógica que las entidades harían bien en adoptar ya: evaluar casos de uso según riesgo y función, no según entusiasmo comercial. El reglamento distingue entre prohibiciones, alto riesgo, obligaciones de transparencia y reglas específicas para modelos de propósito general. Ese enfoque por casos es mucho más útil que la discusión superficial de “permitimos o prohibimos IA”. La pregunta inteligente es otra: ¿qué usos aceptamos, con qué datos, sobre qué plataformas, con qué evidencia de control y bajo qué responsable?

La respuesta no será uniforme. Un asistente para redactar textos internos con datos desensibilizados no plantea el mismo riesgo que una herramienta conectada a expedientes de clientes o a decisiones de scoring. Tratar ambos supuestos con la misma política solo consigue dos cosas: frenar usos razonables y dejar huecos donde el riesgo sí era serio.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, establecimientos de pago, entidades de dinero electrónico, gestoras y otras firmas bajo supervisión en España, la noticia tiene una lectura muy concreta: la convergencia entre IA, outsourcing digital y resiliencia operativa ya no es teórica. Afecta a supervisión, auditoría interna y relaciones con proveedores desde este mismo ejercicio.

El Banco de España, la CNMV y la Dirección General de Seguros no han necesitado esperar a un incidente masivo de IA para recordar, cada uno dentro de su perímetro, que el gobierno del riesgo tecnológico y la externalización no son opcionales. DORA añade una capa común y más estructurada sobre gestión del riesgo TIC, incidentes, pruebas de resiliencia y terceros. Si una entidad permite de facto el uso de herramientas de IA no inventariadas, se expone a una incoherencia peligrosa entre su discurso de control y su realidad operativa.

En España, además, hay un factor cultural que a veces se minusvalora: el peso de la contratación pública, las relaciones con redes comerciales amplias y la heterogeneidad tecnológica entre grupos y filiales. El uso no autorizado de IA puede crecer especialmente en entornos donde conviven sistemas legacy, presión comercial elevada y procesos documentales pesados. Justo donde la promesa de “te ahorro una hora por expediente” resulta más seductora.

Las entidades españolas harían bien en revisar tres puntos concretos antes de que lo pida el supervisor o lo descubra auditoría interna. Uno, si sus políticas de uso aceptable y de clasificación de información mencionan expresamente herramientas de IA generativa y conectores automáticos. Dos, si sus procesos de alta de proveedores contemplan versiones empresariales de estas herramientas con garantías contractuales suficientes. Tres, si han adaptado sus controles de monitorización para detectar tráfico y uso real, no solo contratos firmados.

Si no lo han hecho, el riesgo no desaparece. Solo queda fuera del PowerPoint.

Qué decisiones distinguen a una entidad seria de una que solo está reaccionando

Hay una diferencia bastante nítida entre organizaciones que están gobernando la IA y organizaciones que simplemente intentan no quedar mal cuando aparece el tema. Las primeras toman decisiones incómodas pero concretas. Las segundas producen principios grandiosos y esperan que el problema se comporte solo. No suele funcionar.

Una entidad seria define un catálogo de usos permitidos y prohibidos con ejemplos por función. Decide qué herramientas pueden conectarse a datos internos y cuáles no. Establece un proceso de excepción con responsable nombrado. Exige revisión legal y de seguridad antes de integrar APIs o asistentes en procesos sensibles. Ofrece una alternativa corporativa aprobada para casos legítimos de productividad. Y, detalle nada menor, mide adopción real para ajustar la política en función del comportamiento observado.

Una entidad que solo reacciona hace lo contrario. Manda una circular vaga, bloquea uno o dos dominios conocidos, confía en que los empleados “actúen con criterio” y descubre meses después que el uso se ha desplazado a otras herramientas, cuentas personales o integraciones menos visibles. Luego llega la auditoría y todo el mundo parece sorprendido. Nadie debería estarlo.

También hay una prueba bastante simple para separar teatro de gobierno real: ¿la organización ha asignado dueño a este riesgo? No un grupo de trabajo difuso, no un comité transversal eterno. Un dueño. Puede ser una estructura compartida entre CISO, riesgo no financiero, privacidad y compliance, pero alguien debe tener mandato para decidir, escalar y bloquear. Cuando la respuesta es “lo estamos viendo entre varios”, normalmente significa que no lo está viendo nadie de verdad.

Lo siguiente que veremos: de la detección a los incidentes formales

El 66% que detecta uso no autorizado es probablemente una cifra de transición, no de equilibrio. A medida que las organizaciones mejoren la monitorización, aparecerán más casos, no menos. Y una parte acabará convertida en incidentes formales: divulgaciones indebidas de datos, errores en decisiones basadas en salidas de IA, conflictos contractuales con proveedores, hallazgos de auditoría y, en algunos casos, notificaciones regulatorias.

No hace falta caer en alarmismo. La mayoría de los usos de IA generativa en oficina no acabarán en catástrofe. Pero eso no reduce la necesidad de gobernarlos. En servicios financieros, basta con unos pocos casos mal gestionados para activar consecuencias bastante terrenales: planes de remediación, revisión por auditoría, tensiones con el DPO, bloqueo de despliegues, exigencias del supervisor o costes de renegociación con proveedores. Todo por no haber hecho a tiempo lo más básico.

La lección de fondo es sencilla y poco glamurosa. El problema de la IA no autorizada no se arregla con discursos sobre innovación responsable mientras los empleados siguen usando herramientas externas a escondidas porque resuelven tareas reales. Se arregla con una combinación bastante menos sexy: inventario, política útil, controles técnicos, contrato, formación y alternativa corporativa. Sí, suena menos futurista. También funciona mejor.

La noticia de Nutanix importa por eso. No porque descubra que la IA está en finanzas —eso ya era obvio—, sino porque pone cifra a algo que muchas entidades preferían considerar anecdótico. Dos de cada tres ya lo están viendo dentro. La pregunta no es si tu organización acabará abordándolo. La pregunta es si lo hará antes de que el primer caso serio convierta una “prueba de productividad” en un problema de control interno, privacidad y supervisión.

Y en este sector, cuando un problema consigue afectar a las tres cosas a la vez, deja de ser una moda tecnológica. Pasa a ser exactamente lo que es: riesgo de negocio.