Muchas empresas del sector bancario, de servicios financieros y de seguros (BFSI) creen que los datos de sus clientes cumplen con la normativa. Pero cuando un organismo regulador les pide que lo demuestren, su confianza empieza a tambalearse.
Una prueba no es lo mismo que una política guardada en una carpeta de gobernanza. Los reguladores quieren algo más específico que eso.
Para un cliente y una decisión concretos, las empresas deben demostrar:
- Qué registro se consideró fiable y por qué se utilizó para una decisión concreta
- De dónde procedían los datos y quién era su titular
- Qué datos y controles respaldaron la decisión, y quién aprobó las posibles excepciones
La mayoría de los equipos de cumplimiento normativo pueden describir sus procesos con detalle. Sin embargo, pocos pueden aportar rápidamente esa evidencia justificativa para un cliente concreto, una decisión específica y un momento determinado.
Contar con una política no es lo mismo que poder demostrar que se ha aplicado de forma coherente, y esa diferencia es donde muchas empresas del sector BFSI se ven en apuros. Las normas están establecidas, pero no disponen de una forma rápida y defendible de demostrar que las cumplen.
A continuación te ofrecemos una forma sencilla de comprobar si tu empresa puede aportar esa evidencia de forma rápida y coherente.
¿Pueden los datos de sus clientes resistir el escrutinio de las autoridades reguladoras?
Si un organismo regulador le pidiera pruebas sobre un cliente y una decisión, ¿podría su equipo responder en cuestión de minutos, o pasaría semanas buscando a ese cliente en sistemas que nunca se diseñaron para comunicarse entre sí, conciliando nombres y direcciones que no coinciden antes incluso de poder empezar?
Responder con rapidez depende de dos factores:
- Una única versión fiable de ese cliente, en lugar de varias versiones contradictorias
- Un rastro visible que muestre de dónde proceden los datos y quién los ha aprobado
Muchas empresas siguen teniendo dificultades para ofrecer ambas cosas de forma rápida y coherente, sobre todo cuando los datos de apoyo se encuentran dispersos en múltiples sistemas.
¿Qué exigen actualmente los organismos reguladores?
Los distintos marcos normativos imponen diferentes obligaciones a las empresas del sector BFSI, pero varios de ellos coinciden en un énfasis cada vez mayor en la gobernanza, la rendición de cuentas y las pruebas demostrables.
- El «deber para con el consumidor» y la FCA, que exigen a las empresas evaluar, comprender y demostrar los resultados obtenidos por los clientes minoristas
- El RGPD, que exige a las empresas que comprendan qué datos personales conservan, por qué se tratan, cuánto tiempo deben conservarse y cómo se respetan los derechos de las personas
- La DORA, que exige a las entidades financieras reforzar la gestión de riesgos de las TIC, la resiliencia operativa y la supervisión de los proveedores de tecnología críticos
- La Ley de IA de la UE, que introduce obligaciones en materia de gobernanza, transparencia y gestión de riesgos para determinados sistemas de IA utilizados en los servicios financieros.
Nada de esto es nuevo. Lo que ha cambiado es el nivel de detalle que los reguladores esperan obtener cuando lo solicitan.
Cuando ese regulador señala a un cliente y pregunta por el razonamiento que hay detrás de una decisión, debes ser capaz de relacionar el resultado con los datos, los controles y las aprobaciones que lo respaldaron.
¿Cómo crean los sistemas desconectados puntos ciegos en materia de cumplimiento normativo para las empresas del sector BFSI?
Cada sistema de una empresa del sector BFSI recopila datos de los clientes con un fin empresarial diferente.
Por ejemplo, una plataforma bancaria central puede registrar una cuenta, un sistema de gestión de relaciones con el cliente (CRM) una relación, un sistema de administración de pólizas un contrato y una plataforma de siniestros un suceso o una pérdida. Cada uno de ellos actualiza su propia versión según su propio calendario, utilizando lo que el cliente o un compañero haya introducido en ese momento.
Con el paso de los meses y los años, esos registros se van desajustando entre sí. No hay nada que obligue a que coincidan entre sí, ni nada que indique a nadie en qué versión debe confiar.
El resultado puede ser la existencia de varias versiones de una misma persona u organización, con diferentes direcciones, identificadores, funciones y relaciones repartidas por sistemas que nunca se diseñaron para conciliarlas.
¿Qué puede salir mal durante una actualización del KYC, por ejemplo?
- El sistema bancario central recoge una dirección de hace tres años
- El CRM tiene una más reciente
- La plataforma de incorporación indica una entidad jurídica diferente para el mismo titular real, porque el formulario lo rellenó otra persona en un momento distinto de la relación
Es posible que cada registro fuera válido en su contexto original, pero, en conjunto, presentan una imagen contradictoria e incompleta. Antes de que pueda comenzar la revisión, el equipo debe determinar si los registros se refieren a la misma persona, qué fuente está actualizada y en qué información se debe confiar.
Es entonces cuando ya no es posible responder a un organismo regulador en cuestión de minutos.
¿Por qué la IA convierte los datos de clientes de baja calidad en un riesgo de cumplimiento normativo aún mayor?
Un modelo de IA trata cualquier registro de cliente que reciba como un hecho. Toma una decisión en milisegundos, ya sea que dicha decisión sea:
- Una línea de crédito
- Una aprobación de alta
- Una comprobación de idoneidad
- Una alerta de fraude
- Una decisión sobre una reclamación
- Una remisión para la suscripción
- Una evaluación de la vulnerabilidad del cliente
A menos que los registros contradictorios u obsoletos se identifiquen y se gestionen en las fases iniciales, pueden procesarse con la misma confianza aparente que los datos fiables. Por lo tanto, un registro poco fiable puede influir en las decisiones de forma rápida y a gran escala.
Cada vez más, las empresas deben ser capaces de explicar no solo cómo ha funcionado un modelo, sino también qué datos han respaldado sus resultados, de dónde proceden dichos datos y qué controles se han aplicado.
- Los errores manuales pueden permanecer aislados o detectarse caso por caso
- Los procesos automatizados pueden repetir el mismo problema de datos en una población mucho más amplia
La prueba que mencioné anteriormente también se aplica aquí. Pero en este caso el problema se produce a la velocidad de una máquina. Una empresa que no pudiera dar una respuesta a un cliente en cuestión de minutos ahora tiene un modelo que repite esa misma decisión no contrastada con miles de clientes antes de que nadie se dé cuenta.
¿Por qué sigue siendo difícil demostrar la eficacia de unas políticas de cumplimiento estrictas?
Muchas empresas del sector BFSI ya cuentan con políticas detalladas, marcos de gobernanza de datos y controles documentados.
El problema surge a la hora de demostrar que se ha cumplido la política:
- Para un cliente
- Un día
- Para una decisión
La verdadera prueba consiste en determinar si los datos, los controles y las autorizaciones que sustentan una decisión se registraron y estaban disponibles en el momento en que alguien los solicitó. La mayoría de las empresas comprueban si existen políticas y controles, pero pueden estar menos preparadas para comprobar la rapidez con la que se pueden reunir las pruebas justificativas para un cliente o una decisión reales.
Y ese es el verdadero reto.
Un estudio reciente de McKinsey sobre la preparación de los datos para la IA llega a una conclusión similar desde un punto de vista técnico: la IA no rebaja el listón de la calidad de los datos, sino que aumenta el coste y la rapidez con la que se pueden cometer errores. El mismo estudio reveló que solo el 7 % de las empresas ha implantado plenamente la IA en toda su organización. En gran medida porque los datos subyacentes no estaban preparados para respaldarla.
Cómo pueden las empresas del sector BFSI facilitar la presentación de pruebas de cumplimiento normativo
La solución pasa por tratar los datos fiables de los clientes y de terceros como una infraestructura compartida.
Customer Experience Data Cloud, la solución de datos de clientes basada en STEP, la plataforma de inteligencia de confianza de Stibo Systems, ofrece a las empresas del sector BFSI una base de datos maestros regulada que les ayuda a vincular identidades, aplicar reglas transparentes y conservar pruebas de cómo se crearon los registros fiables. La solución:
- Aplica reglas transparentes de correspondencia y supervivencia, lo que ayuda a las empresas a comprender por qué se vincularon los registros y qué valores se seleccionaron
- Realiza un seguimiento del linaje, mostrando de dónde procede cada dato del cliente y cuándo se modificó por última vez
- Gestiona las relaciones y jerarquías entre clientes, cuentas, pólizas, organizaciones, corredores y partes relacionadas
- Admite flujos de trabajo de gestión y de excepciones, de modo que las decisiones importantes sobre identidades puedan revisarse en lugar de permanecer ocultas dentro de la lógica del sistema
Empresas como Royal London ya gestionan los datos de sus clientes de esta manera. Las que superan las preguntas de los reguladores pueden responder al instante, cada vez que se les pregunta, independientemente de la cantidad de documentación que haya en una carpeta.
Preguntas frecuentes
¿Cuál es la diferencia entre un CRM, un data lake y una capa de identidad gobernada para fines de cumplimiento?
Un CRM registra las interacciones con un cliente. Un data lake almacena y analiza datos en bruto. Tampoco están diseñados para decidir cuál versión de un registro de cliente es correcta, o para hacer que esa decisión sea explicable, que es para lo que está diseñada una capa de identidad gobernada.
¿Cuándo se aplica la Ley de IA de la UE a las empresas BFSI que utilizan IA en las decisiones de los clientes?
El Reglamento de IA de la UE será plenamente aplicable en agosto de 2026, con obligaciones específicas para los sistemas de IA de alto riesgo, que cubren muchas decisiones de crédito, incorporación, reclamaciones y suscripción impulsadas por IA en BFSI.
¿Una capa de identidad gobernada reemplaza la necesidad de un programa de gobernanza de datos?
No. Le da a un programa de gobernanza algo que hacer cumplir. La política establece las reglas; la capa de identidad es lo que hace que esas reglas sean verificables contra un registro real de cliente.
¿Puede una empresa cumplir con los requisitos en papel pero aún así fallar en una auditoría de IA?
Sí, y esto se está convirtiendo en una de las brechas más comunes que los reguladores están encontrando. La política documentada muestra la intención. Una auditoría de IA prueba si los datos detrás de una decisión real coinciden con esa intención, lo cual es una pregunta completamente diferente.
¿Qué pasa con los datos de clientes heredados creados antes de que se aplicaran las reglas actuales?
Los datos heredados no obtienen una exención. Si aún alimenta una decisión del cliente hoy, un regulador aún puede pedir pruebas al respecto, independientemente de cuándo se creó originalmente el registro.
¿Con qué frecuencia debe una empresa probar si puede producir esta evidencia?
No hay un intervalo regulatorio fijo, pero las empresas líderes lo tratan como un simulacro de incendio, realizando la prueba internamente en un escenario real con un cliente en lugar de esperar a que un regulador la realice primero.
