SardineCon SF/2026

Learn More

Por qué tu IA antifraude funciona mejor cuando vive dentro de tu plataforma de fraude

Chen Zamir
Chen Zamir
bg-image
bg-image
Un diagrama isométrico de una pila de datos completa con una vista externa, que ilustra cómo la IA nativa de la plataforma para la detección de fraude aprovecha el contexto profundo y el acceso completo a los datos para superar a la IA general.
Subscribe to newsletter
Share

Tu sistema de IA para fraude genera resultados. El agente se ejecuta, salen propuestas, la demostración se veía excelente. Y, sin embargo, en algún punto entre la respuesta del agente y el cierre real del caso (o la implementación real de la regla), las cosas se ralentizan, se descomponen o simplemente no se generalizan como la demo prometía.

Si estás en ese punto, probablemente ya te has empezado a preguntar si necesitas un modelo mejor. Quiero ahorrarte ese desvío. La respuesta casi siempre es que no: el modelo está bien.

Lo que más importa es dónde se ejecuta el modelo.

Lo he visto desde ambos lados: construyendo investigaciones en una plataforma nativa y escuchando a equipos cuyo agente, impresionante en la demostración, se quedó atascado en cuanto llegó a producción.

El patrón es lo bastante consistente como para apostar por él: los equipos que realmente están cerrando casos no están usando modelos más inteligentes. Están ejecutando sus modelos dentro de su plataforma de fraude, en lugar de encima de ella.

Qué significa realmente una IA antifraude nativa de la plataforma

Un agente nativo de la plataforma no tiene por qué ser más inteligente que uno de propósito general. Pero sí tiene el contexto que el de propósito general no tiene. Sabe qué significan las huellas digitales de los dispositivos, las señales de sesión, los IDs de socios, las puntuaciones de riesgo de fraude y los patrones de comportamiento en tu plataforma específica.

No necesitas explicar todo esto en cada instrucción. Se creó con ese entendimiento ya incorporado.

Notas la diferencia en cuanto ves trabajar a un agente nativo. Cuando realizamos una investigación de incorporación de cripto, el analista le dio al agente una ventana de tiempo y una hipótesis. El agente no preguntó qué significaban las sesiones de riesgo medio ni cómo consultar la tabla de transacciones. Fue directamente a los datos correctos, estructuró sus resultados en términos con los que el analista podía actuar y sacó a la luz el patrón: una anomalía de volumen en sesiones de bajo riesgo, concentración geográfica, agrupamiento por monto de transacción, sin ninguna explicación de esquemas.

Entrega los mismos datos a un agente de propósito general y este dedicará la mayor parte de su primera respuesta a entender el entorno. Ese costo no aparece solo una vez, sino que se acumula en cada investigación que realices.

La limitación en una investigación de fraude solía ser SQL: qué tan rápido podías escribir consultas y qué tan bien conocías dónde vivían los datos. El contexto nativo elimina eso. Ahora el analista solo está limitado por la calidad de las preguntas que puede hacer, que es exactamente en lo que quieres que una persona dedique su criterio.

La brecha entre la investigación del fraude y la acción de cumplimiento

Otro punto de fricción que casi todos los desarrollos no nativos acaban encontrando es que el agente vive en un entorno, y las acciones —añadir a una lista de bloqueo, escribir una regla, ajustar un umbral— ocurren en otro. Entonces te toca a ti traducir entre lo que el agente llama una señal y lo que el motor de reglas llama una característica.

Estás comprobando si la característica que el agente utilizó en su análisis siquiera existe en la capa de aplicación. Estás volviendo a verificar los hallazgos antes de actuar porque los dos sistemas no comparten una única fuente de verdad. Y cada nueva verificación es tiempo durante el cual el atacante sigue operando.

Cuando la investigación y la aplicación se realizan en la misma plataforma, ese trabajo se vuelve redundante. La huella que el agente identificó como indicio es la misma huella sobre la que el motor de reglas aplica bloqueos. La lista de bloqueo que el agente recomienda ampliar es la misma que se hace cumplir en el perímetro. La conclusión de la investigación y la acción de aplicación se convierten en un solo movimiento en lugar de dos.

Pero no se trata solo de velocidad o eficiencia, porque esta brecha a menudo implica una ruptura total del proceso.

Si el agente tomó decisiones basadas en una señal que tu plataforma de fraude no tiene, o bien reconstruyes esa señal más adelante en el flujo, o la descartas. En cualquier caso, lo que detectó la banda no es lo que la detiene.

Tu plataforma de prevención de fraude conoce el contexto de las señales de fraude que tu agente no puede

La brecha entre investigación y acción funciona en ambos sentidos. Acabo de describir una dirección, en la que el agente analiza una señal sobre la que tu plataforma de fraude no puede actuar.

Pero lo contrario es más difícil de detectar y causa aún más daño: tu plataforma contiene datos que tu agente nunca llega a ver. Un agente desplegado solo razona sobre los datos a los que puede acceder. Si está fuera de tu plataforma de fraude, solo obtiene una pequeña parte de lo que realmente hay. En el mejor de los casos.

¿Qué falta entonces? Empecemos con la resolución de entidades y los datos de red. Tu plataforma sabe que 12 cuentas “diferentes” se corresponden con una sola entidad gracias a identificadores compartidos, y dispone de información detallada sobre esa entidad. Si tu agente solo ve una cuenta en tus datos, tu contexto se reduce drásticamente y la probabilidad de que cometa errores aumenta en la misma medida. Así es como nacen los falsos positivos.

Luego considera la inteligencia de consorcio: señales de fraude agrupadas entre muchas instituciones, de modo que un dispositivo o identidad que perjudicó a alguien más la semana pasada ya es sospechoso antes incluso de que llegue a ti. Un agente limitado solo a tus datos no puede reconocer a un estafador que es un recién llegado para ti pero alguien bien conocido para todos los demás en la red.

Luego está la velocidad de fraude en tiempo real: recuentos a lo largo de toda tu base de usuarios, como cuántas cuentas ha tocado un dispositivo en la última hora o cuántas tarjetas ha intentado usar una sesión. A menos que estés calculando la velocidad tú mismo (y te felicito si lo haces), tu agente se está perdiendo la señal de fraude más crítica que existe.

Puedes tener un flujo de trabajo de agente de primera, pero si no lo alimentas con todos los datos que tienes disponibles, seguirá cometiendo errores. Y si la mayoría de tus señales críticas viven bajo el capó de tu plataforma de fraude, solo los agentes nativos de la plataforma pueden acceder a ellas y razonar sobre ellas.

No se trata de un modelo más inteligente

Si tus agentes de IA para la detección de fraude están generando resultados pero no cerrando casos, mira más allá del modelo. El problema casi con toda seguridad está en dónde se implementan.

Un agente que se ejecuta sobre tu plataforma se queda sin recursos al recibir información, porque no puede ver todos tus datos, y queda aislado al enviar resultados, porque no puede actuar a través de tu capa de aplicación de medidas.

Todo lo que ocurre entre medias, desde la traducción hasta la nueva verificación y el cambio de contexto, es fricción que se acumula en cada caso.

Los agentes nativos de la plataforma cierran esa brecha y te liberan de la necesidad de crear tus propios flujos de datos, guiar a tus agentes paso a paso o bombardearlos con instrucciones en cada momento.

Si este argumento te resulta convincente, que el lugar donde se ejecuta tu agente importa más que lo inteligente que es, el whitepaper lo desarrolla en mayor profundidad. Explica cómo es en la práctica un sistema agentivo nativo de la plataforma, la dotación de personal y la combinación de habilidades que requiere, el modelo de gobernanza para un aprendizaje continuo seguro y la secuencia de implementación a 18 meses.

Preguntas frecuentes sobre agentes nativos de plataforma de IA contra el fraude

¿Qué significa que la plataforma de IA contra el fraude sea nativa?

Que la plataforma de IA antifraude sea nativa significa que el agente se ejecuta dentro de la propia plataforma de fraude, en lugar de estar encima de ella como una herramienta desconectada. Un agente de IA antifraude nativo de la plataforma puede acceder a las señales de la plataforma, comprender su lógica de riesgo y actuar a través de la misma capa de aplicación que el equipo de fraude ya utiliza.

¿Por qué la IA antifraude nativa de la plataforma funciona mejor que una herramienta de IA independiente?

La IA antifraude nativa de la plataforma funciona mejor porque cuenta con más contexto específico sobre el fraude. Una herramienta independiente puede generar análisis, pero a menudo no puede ver todo el entorno de datos ni actuar por sí sola sobre sus hallazgos. Cuando los agentes de IA para la detección de fraude se ejecutan dentro de la plataforma, la investigación y la acción ocurren en el mismo flujo de trabajo.

¿Cómo ayudan los agentes de IA para la detección de fraude en el cierre de casos de fraude?

Los agentes de IA para la detección de fraude ayudan a cerrar casos de fraude al reducir el tiempo entre encontrar un patrón sospechoso y tomar medidas. Si el agente puede investigar las señales, identificar cuentas relacionadas y recomendar acciones de cumplimiento dentro del mismo sistema, el equipo dedica menos tiempo a traducir los resultados en trabajo manual de casos.

¿Qué es la brecha entre investigación y acción en la IA contra el fraude?

La brecha entre investigación y acción es el espacio entre lo que un agente de IA descubre y lo que el equipo de fraude puede realmente aplicar. Si el agente identifica una señal que no existe en la capa de aplicación de la IA antifraude, el equipo tiene que reconstruirla, traducirla o abandonar el hallazgo antes de poder detener el fraude.

¿Por qué la investigación y la aplicación de medidas contra el fraude deben realizarse en la misma plataforma?

La investigación y la aplicación contra el fraude deben realizarse en la misma plataforma, porque cada traspaso genera demoras y riesgos. Cuando la investigación utiliza un conjunto de señales y la aplicación utiliza otro, los equipos tienen que volver a verificar los hallazgos. Una fuente de verdad compartida de IA contra el fraude hace que la investigación sea más confiable y que las acciones de aplicación sean más fáciles de ejecutar.

¿Qué contexto sobre señales de fraude puede proporcionar una plataforma de prevención de fraude a un agente de IA?

Una plataforma de prevención de fraude puede proporcionar a un agente de IA contexto de señales de fraude, como huellas digitales de dispositivos, señales de sesión, IDs de socios, puntuaciones de riesgo de fraude, patrones de comportamiento, resolución de entidades, datos de red y velocidad. Ese contexto ayuda al agente a entender si una señal es realmente sospechosa o normal para ese entorno.

¿Por qué son importantes las señales de fraude de consorcio para la IA de detección de fraude?

Las señales de fraude de consorcio son importantes para la IA de detección de fraude porque muestran el comportamiento a través de una red más amplia, no solo en los datos de una sola empresa. Un patrón de dispositivo, identidad o cuenta puede ser nuevo para un negocio, pero ya resultar sospechoso en todo el consorcio. Ese contexto más amplio puede ayudar a reducir los puntos ciegos.

¿Qué es la velocidad de fraude en tiempo real?

La velocidad de fraude en tiempo real se refiere al conteo actual de actividades entre usuarios, dispositivos, tarjetas, sesiones o cuentas. Por ejemplo, puede mostrar cuántas cuentas ha tocado un dispositivo en la última hora o cuántas tarjetas ha intentado usar una sesión. Sin velocidad de fraude en tiempo real, un agente de IA puede pasar por alto una de las señales de fraude más importantes.

¿Cómo utilizan las señales de sesión los equipos de fraude para mejorar las decisiones de la IA?

Las señales de sesión que utilizan los equipos de fraude pueden mejorar las decisiones de la IA al mostrar lo que ocurrió durante una interacción del usuario, no solo después. El comportamiento del dispositivo, los patrones de inicio de sesión, los intentos de transacción y la actividad a nivel de sesión pueden ayudar al agente a entender si un evento encaja en un patrón normal o parece estar coordinado.

¿Por qué es importante una puntuación de riesgo de fraude para los agentes de IA nativos de la plataforma?

La puntuación de riesgo de fraude es importante porque le ofrece al agente una visión del riesgo específica de la plataforma. La puntuación resulta más útil cuando el agente entiende cómo se creó, qué señales la influyeron y cómo la plataforma de prevención de fraude utiliza esa puntuación en sus decisiones.

¿De qué manera la IA agéntica en la prevención del fraude depende del contexto de la plataforma?

La IA agéntica en la prevención del fraude depende del contexto de la plataforma, porque los agentes necesitan más que datos en bruto para generar acciones útiles. Necesitan comprender las señales, los flujos de trabajo, las opciones de aplicación y la fuente de la verdad. Sin ese contexto, el agente puede explicar un patrón, pero no logrará ayudar a cerrar el caso.

¿Qué es la investigación de fraude nativa de la plataforma?

La investigación de fraude nativa de la plataforma es un flujo de trabajo de investigación en el que el agente trabaja directamente dentro de la propia plataforma de fraude. Puede utilizar las mismas señales, vínculos entre entidades, puntuaciones de riesgo, listas de bloqueo y reglas de aplicación en las que el equipo ya confía, de modo que la investigación y la acción formen parte de un mismo proceso.