Por qué los agentes de riesgo necesitan un historial de clientes compartido

Última actualización: septiembre de 2026

La memoria compartida para los agentes de riesgo de IA es un registro de cliente único, resuelto, con permisos y auditable del cual cada agente lee y escribe en el momento de la decisión. No se trata de una ventana de contexto más amplia, ni tampoco de la vista de cliente 360 que un equipo de datos recopila para informes. Sin esto, un agente de fraudes y uno de prevención de lavado de dinero (AML) pueden mirar a la misma persona, leer sus propios datos correctamente y, aun así, llegar a conclusiones que se contradicen entre sí.

Resumen rápido

• El hecho de que dos agentes de riesgo no se pongan de acuerdo sobre un cliente suele ser un problema de registros, no de modelos. Cada agente lee una parte diferente y razona correctamente a partir de ella.

• Hay tres cosas distintas a las que se les llama memoria: la ventana de contexto de un agente, el perfil de cliente 360 de un almacén de datos y un registro de riesgo regulado. Solo la tercera es lo que realmente necesita una función de riesgo.

• Un registro compartido tiene tres requisitos previos que el vocabulario técnico suele ocultar: las identidades deben resolverse, las definiciones de los campos deben acordarse y el registro debe tener un propietario designado.

• Normalmente, ese propietario no es la plataforma de agentes. En la mayoría de las instituciones, la capa compartida es una copia sincronizada de un registro que reside en otro lugar, lo que hace que la escritura diferida, la obsolescencia y la conciliación sean decisiones clave de diseño.

• No hay nada en las directrices de supervisión que indique qué debe contener el registro de un cliente para un agente. Las directrices revisadas sobre riesgo de modelos, publicadas el 17 de abril de 2026, dejan fuera de su alcance a la IA agéntica, por lo que la institución decide y luego debe defender esa decisión.

Memoria compartida para agentes de riesgo de IA: la respuesta corta

La memoria compartida para agentes de riesgo de IA significa que cada agente que trabaja con un cliente lee y escribe en el mismo registro. Además, ese registro se resuelve en una única identidad, incluye definiciones acordadas para cada campo y registra lo que cada agente y cada persona hicieron con él. La prueba no es cuánto puede retener un agente en una sola consulta, sino si el agente de fraudes, el de AML y el de crédito están razonando sobre el mismo cliente, y si alguien puede reconstruir después lo que vio cada uno de ellos.

Dos agentes, un cliente, dos respuestas

Un agente de fraudes marca una cuenta como de bajo riesgo mientras que un agente de AML considera que vale la pena derivar el caso de la misma persona. Ninguno se equivoca desde su posición. El agente de fraudes tiene el historial de dispositivos y transacciones de un producto; el de AML tiene datos de contrapartes y geografía de otro.

Este desacuerdo no es un problema de modelos. Ambos agentes leyeron sus datos correctamente y razonaron de manera lógica. Sin embargo, leyeron registros diferentes, y ningún sistema sabe que el otro existe.

Cada agente que se añade a una función de riesgo hace que esto sea más probable en lugar de evitarlo, que es justo lo contrario de lo que se buscaba al adquirir el segundo agente. La postura de producto de Oscilar se basa en agentes coordinados que "mantienen el contexto a través de las alertas, conectan los puntos entre los datos de fraude, crédito y cumplimiento, y derivan los casos de forma inteligente". Mantener el contexto a través de las alertas solo tiene sentido si hay un único lugar donde resida ese contexto.

Tres cosas llamadas memoria, y solo una es la correcta

Tres conceptos distintos comparten la palabra "memoria" en las conversaciones sobre agentes de riesgo de IA, y confundirlos es la forma en que un proyecto de plataforma de datos se vende erróneamente como un proyecto de agentes.

La tabla describe tres capas que responden a tres preguntas diferentes, y solo la tercera responde a "qué sabe esta institución sobre este cliente en este preciso momento".

Los almacenes de vectores, las estrategias de recuperación y la clasificación de memoria episódica frente a semántica quedan fuera de esto. Esas preguntas corresponden al equipo que diseña un agente. Una función de riesgo que implementa varios agentes tiene un problema diferente: su registro de clientes está disperso en sistemas que nunca se diseñaron para estar de acuerdo.

Requisito uno: las identidades deben resolverse

Un registro compartido no sirve de nada si las áreas de fraude, AML y crédito tienen claves diferentes para la misma persona. La resolución de entidades es el requisito previo indispensable, y debe ocurrir antes de que cualquier proceso posterior tenga sentido. Una vista única de cliente construida a partir de tres identificadores sin coincidencia no es más que tres vistas de cliente metidas en una sola tabla.

La resolución es una evaluación y puede fallar de dos maneras. Una coincidencia omitida oculta una relación real, por lo que el agente razona con información fragmentada. Una fusión falsa inventa una relación inexistente, por lo que el agente razona sobre una persona que no está ahí. En un contexto de riesgo, la fusión falsa es peor, porque genera una decisión errónea tomada con total seguridad sobre un cliente real.

Esta página no garantiza la tasa de acierto de ningún producto en particular, incluido el de Oscilar, ya que dicha cifra no está verificada. Pregunte a cualquier proveedor cómo se midió la suya, en qué población y cuál fue la tasa de fusiones falsas en esa misma prueba. Es una de las preguntas que vale la pena hacerse antes de implementar un agente de riesgo.

Requisito dos: hay que acordar las definiciones, no solo los datos

Consolidar los valores no define su significado. Un responsable de operaciones de una firma de servicios financieros digitales describió el problema con claridad: "equipos diferentes definen una métrica específica de forma ligeramente distinta, por lo que contar con una herramienta centralizada será clave para nosotros. De este modo, los cálculos se realizarán de manera uniforme en todos los equipos".

Dos agentes pueden leer el mismo campo y no estar de acuerdo, porque el campo significa algo diferente para el equipo que lo introduce. Un cliente marcado como "revisado" por un equipo puede significar que se verificaron los documentos; para otro, puede significar que el caso se cerró. Ningún agente puede saber cuál de las dos opciones está leyendo.

Esta es la razón más clara por la que una vista de cliente 360 de almacén de datos no basta para la gestión de riesgos. Consolida valores sin unificar significados, y los significados son la base sobre la que razona el agente.

El mismo ponente señaló el coste de dejar esto sin resolver: sin una fuente central de confianza, "gran parte del trabajo posterior que se realiza en segundo plano" se destina a verificar la información recopilada de múltiples almacenes de datos.

Requisito tres: el registro tiene un propietario, y probablemente no sea la plataforma del agente

Que sea compartido no significa que no tenga dueño. Un director de I+D de una plataforma de pagos global, al describir una implementación real, fue explícito sobre dónde reside la copia maestra: "nuestras listas no se usan solo para el flujo [de la plataforma de riesgo]. En algunos casos, se transmiten a diferentes equipos. Por lo tanto, en este caso no podemos permitir que [la plataforma de riesgo] sea la fuente única de información para la gestión de listas. Tiene que ser una copia de nuestra propia fuente de información".

En la mayoría de las instituciones de cierto tamaño, la capa compartida es una copia sincronizada de un registro que reside en otro lugar. Las listas, los maestros de clientes y las jerarquías de cuentas son utilizados por equipos que no tienen nada que ver con el riesgo, y esos equipos no aceptarán una plataforma de riesgo como su sistema de registro principal. Esta es la misma limitación que define lo que un agente necesita de los sistemas de riesgo que ya utiliza: el agente lee de esos sistemas, no los sustituye.

Esto convierte la escritura diferida, la obsolescencia de los datos y la conciliación en decisiones de diseño clave, en lugar de simples detalles de implementación. Si un agente escribe una resolución en la copia compartida, algún proceso debe decidir si eso se transmite al original, cuánto retraso puede tener la copia y qué ocurre si ambos no coinciden.

Resuelva una pregunta antes de añadir un segundo agente: qué sistema tiene la autoridad para cada campo. La respuesta variará campo por campo, y documentarla representará la mayor parte del trabajo.

Qué debe contener el registro y durante cuánto tiempo

Un registro sobre el cual varios agentes pueden razonar contiene cuatro cosas: la identidad (incluyendo las pruebas de cómo se resolvió), las definiciones acordadas para cada campo, el historial de decisiones (indicando qué persona confirmó qué acción) y lo que escribió cada agente, debidamente atribuido a este.

La gestión de permisos debe estar dentro del propio registro y no en una capa superior. No todos los agentes deberían leer todos los campos, y un registro que no pueda gestionar esto acabará sufriendo filtraciones de datos o se limitará tanto que dejará de ser compartido.

El historial no es opcional. Un agente que evalúa la relación con un cliente necesita conocer su pasado, y cargar esa información es una tarea más compleja de lo que parece. El mismo director de I+D incluyó "la carga de datos históricos" entre las tareas pendientes de su proyecto, calificándola de "un asunto más estratégico que táctico por el momento".

En cuanto a la escritura de datos, la postura pública de Oscilar es clara y conviene detallarla de forma sencilla: los agentes nunca cierran ni derivan alertas de forma autónoma; cada recomendación es revisada y confirmada por un analista humano antes de tomar cualquier medida. Lo que queda grabado en el registro es una recomendación junto con una decisión humana, nunca un agente actuando por su cuenta.

Por qué es una cuestión de gobernanza y no de ingeniería de datos

No hay nada en las directrices de supervisión actuales que indique a una institución qué debe contener el registro de un cliente para un agente. El 17 de abril de 2026, la Reserva Federal, la FDIC y la OCC publicaron de forma conjunta directrices revisadas sobre la gestión de riesgos de modelos (SR 26-2 en la Reserva Federal, Boletín 2026-13 en la OCC y FIL-15-2026 en la FDIC), sustituyendo la norma SR 11-7 y la declaración conjunta de 2021 sobre el riesgo de modelos BSA/AML. Estas directrices dejan fuera de su alcance a la IA agéntica: "Los modelos de IA generativa e IA agéntica son novedosos y evolucionan rápidamente. Por lo tanto, no entran en el ámbito de aplicación de estas directrices". Las agencias señalan que tienen previsto publicar una solicitud de información sobre el uso de la IA por parte de los bancos, la cual no se ha emitido hasta el día de hoy.

Por tanto, la institución decide qué contiene el registro, documenta la decisión y la defiende. Nada de esto elimina las obligaciones fundamentales de la normativa BSA/AML sobre la decisión en sí, las cuales permanecen intactas.

Ya existe una prueba útil en las directrices. La norma SR 26-2 mantiene el principio de "desafío eficaz" y define quién puede realizarlo: personas con la experiencia para llevar a cabo una evaluación crítica y objetiva, con la independencia suficiente para mantener la objetividad y con "la influencia y posición organizativa necesarias para implementar cualquier cambio". Aplique estas tres mismas condiciones al registro. ¿Puede un revisor independiente, con la autoridad para cambiar algo, reconstruir lo que vio cada agente en el momento de hacer su recomendación? Si la respuesta depende de qué sistema decida abrir, el registro no está compartido.

Para esto sirven también las pistas de auditoría. La plataforma de Oscilar registra el razonamiento que hay detrás de cada recomendación, lo que facilita mostrar a los reguladores dónde toman las decisiones las personas. Esto solo funciona si hay un único registro al que asociar dicho razonamiento, por lo que el registro compartido y la pista de gobernanza que debe dejar un agente de riesgo de IA resultan ser el mismo problema.

Qué ocurre cuando falta el registro

Este fallo se manifiesta como una fricción operativa común mucho antes de que nadie lo considere un problema de gobernanza. Diferentes personas gestionan el mismo caso, las notas no se guardan en un único lugar y la persona que trabaja en ello no está consultando el sistema adecuado.

La consecuencia va más allá de la ineficiencia. Un responsable de operaciones de una empresa de servicios financieros digitales lo planteó en función de dónde deben sostenerse finalmente los registros: "Quiero asegurarme de que nuestra documentación y todos nuestros registros sean claros, porque, por razones obvias, no podemos presentarnos ante un tribunal con información que falte". Un agente que trabaja más rápido que un humano amplía esa brecha, porque se acumulan más decisiones sobre un registro que no puede justificarlas.

Hay un ejemplo cuantificable en sentido contrario. Un banco en fase de implementación muestra un 92 % de coincidencia de los agentes con su equipo de analistas en la resolución de alertas y un 75 % menos de tiempo por revisión. Esta coincidencia solo se puede medir porque el agente y el analista estaban mirando exactamente lo mismo, que es lo primero que aporta el registro compartido. Cabe destacar que se trata de una implementación específica y no de una referencia estándar de la industria.

Dónde falla esto

Un registro compartido no elimina las discrepancias, sino que hace que estas tengan sentido. Es posible que dos agentes sigan llegando a conclusiones diferentes sobre el mismo cliente; la ventaja es que ahora se puede saber el porqué, en lugar de descubrir la contradicción durante una inspección regulatoria.

Consolidar el registro es una tarea más larga que consolidar los agentes, y puede durar más que el propio programa de agentes que la impulsó. Un director de gestión de fraudes de una empresa global de pagos y prepago describió la versión interna de este trabajo: un sistema central que distribuye datos a los proveedores y coordina lo que se recibe, construido de forma que "en algún momento antes de que yo muera, todos estén conectados" a él. Su empresa tiene "probablemente unas 30 plataformas diferentes en la lista de espera para intentar integrarlas en el sistema consolidado de fraude". Se trata de un sistema real, descrito por la persona que lo construyó, con una cola de espera que se mide en plataformas.

Hay dos vacíos de información que conviene mencionar con total honestidad. No existen datos publicados sobre la frecuencia con la que los agentes de riesgo se contradicen entre sí, ni en Oscilar ni en ningún otro sitio. Además, esta página no afirma cómo ningún producto, incluido el de Oscilar, resuelve identidades o sincroniza registros, ya que no hay datos verificados que lo respalden.

Por dónde empezar

Elija un cliente que esté activo en dos colas de trabajo diferentes e intente armar su registro único de forma manual. El tiempo que tarde y el número de sistemas que deba consultar serán su medida real. Esto aporta mucha más información que cualquier diagrama de arquitectura de un proveedor.

A continuación, defina el sistema que tiene la autoridad para cada campo antes de añadir un segundo agente, no después. Los campos en los que ningún sistema sea claramente el de referencia serán la fuente de futuras contradicciones.

Lo que los agentes deben compartir más allá del registro del cliente, como el estado de las tareas y las reglas de derivación, es una cuestión aparte que requiere un análisis independiente.

Existe una limitación práctica que facilita las cosas: los agentes pueden funcionar como una capa independiente sobre la infraestructura que ya tiene, o como parte de una plataforma unificada. El problema del registro se resuelve desde esa capa, sin necesidad de sustituir los sistemas propietarios de los datos.

Si prefiere poner a prueba este enfoque antes que el software, realice una prueba de concepto de agentes de una semana centrada exclusivamente en el registro: un segmento de clientes, una identidad resuelta y una respuesta por escrito sobre qué sistema tiene la autoridad para cada campo.

Preguntas frecuentes

¿Qué es la memoria compartida de clientes para agentes de riesgo de IA?

La memoria compartida de clientes es un registro de cliente único, resuelto, con permisos y auditable que cada agente de riesgo consulta y en el que escribe al momento de tomar decisiones. Contiene la identidad del cliente, las pruebas de cómo se resolvió, las definiciones acordadas para cada campo, el historial de decisiones (incluyendo las confirmaciones humanas) y lo que escribió cada agente. Se trata de un registro regulado en lugar de una memoria caché o una tabla de informes.

¿Por qué necesitan los agentes de riesgo una memoria compartida de clientes?

Porque un agente no puede analizar correctamente a un cliente si solo ve una parte de él. Cuando un agente de fraudes y uno de AML manejan versiones distintas de la misma persona, ambos pueden interpretar sus datos correctamente y, aun así, llegar a conclusiones opuestas. Cada agente adicional que se sume aportará otra vista parcial en lugar de una ayuda real.

¿Cuál es la diferencia entre la ventana de contexto de un agente y un registro de cliente compartido?

La ventana de contexto es la memoria de trabajo de un solo agente para una tarea específica y desaparece cuando esta finaliza. En cambio, un registro de cliente compartido permanece en el tiempo, es consultado y actualizado por todos los agentes, y está sujeto a reglas sobre quién puede ver cada campo. Ampliar la ventana de contexto solo da más margen a un agente, pero no ayuda en nada a los demás.

¿Es lo mismo una vista de cliente 360 que la memoria compartida para agentes de riesgo?

No. Una vista de cliente 360 de un almacén de datos se diseña para generar informes y análisis; normalmente se crea a posteriori y no está disponible con la rapidez que requiere una toma de decisiones. Además, consolida valores sin unificar sus significados, que es el principal factor de error para los agentes. Un registro de riesgos debe poder leerse y modificarse en tiempo real y debe contar con definiciones acordadas.

¿Cómo se mantiene la memoria a través de varios agentes de IA?

Ofreciendo a los agentes un registro compartido externo en lugar de intentar sincronizar sus memorias individuales. Resuelva el cliente en una única identidad, acuerde la definición de cada campo, designe el sistema de referencia para cada uno de ellos y exija que cada agente escriba sus resultados indicando su autoría. De este modo, la permanencia de los datos pasa a ser responsabilidad del registro y no de los agentes.

¿Cómo se regula y audita lo que un agente recuerda de un cliente?

Trate el registro como el elemento principal de la auditoría. Registre lo que leyó cada agente, lo que recomendó, qué analista humano lo confirmó o modificó y qué información se guardó de vuelta. Así, un revisor independiente podrá reconstruir el estado de los datos en el momento exacto de la decisión. Aplique la prueba de "desafío eficaz" de la norma SR 26-2: el revisor debe contar con experiencia, independencia y la autoridad para cambiar el resultado.

¿Pueden los agentes de riesgo de IA con memoria compartida integrarse con los sistemas de riesgo existentes de una institución?

Sí, y en la mayoría de las instituciones es la única opción viable. Los agentes pueden funcionar como una capa independiente sobre la infraestructura que ya tiene o integrarse en una plataforma unificada. Así, el registro compartido se sitúa por encima de los sistemas que contienen los datos originales en lugar de sustituirlos. El trabajo de diseño consiste en decidir qué sistema tiene la autoridad sobre cada campo y cómo se gestionan la escritura de datos y la conciliación.

¿Cómo se gestionan la revisión humana, la auditabilidad y el rendimiento cuando los agentes comparten un registro?

La supervisión humana se mantiene en el proceso de decisión: los agentes nunca cierran ni derivan alertas por sí solos; un analista humano revisa y confirma cada recomendación antes de actuar. La auditabilidad se logra al registrar el razonamiento de cada recomendación en un único registro, facilitando mostrar a los reguladores el punto donde intervienen las personas. El rendimiento se mide sobre ese mismo registro, que es lo que hace que las tasas de coincidencia entre agentes y analistas tengan verdadero sentido.

Un registro sólido antes de sumar otro agente

Un agente no puede razonar sobre un cliente si solo ve una parte de él. La memoria compartida para agentes de riesgo de IA no consiste en ampliar la ventana de contexto ni en una vista de cliente 360 para informes. Es un registro único, resuelto, con permisos y auditable, con definiciones claras y un propietario asignado. Mientras esto no exista, cada nuevo agente que sume solo aportará otra vista parcial de la misma persona.

El orden de los pasos es clave. Resuelva la identidad, acuerde las definiciones, asigne un propietario para cada campo y, solo entonces, sume al segundo agente. Si quiere comprobar cómo funciona esto con sus propios datos, los agentes de IA de Oscilar son el punto de partida ideal, y una prueba de concepto de una semana basada en un único registro de cliente le aportará más claridad que cualquier demostración de producto.