Cómo Jarsy reconstruyó el control de riesgos financieros con agentes de IA

Desde agosto de este año, Jarsy construye su sistema de control de riesgos de una forma completamente nueva: investigar, cotejar, redactar reglas, escribir código y verificar mediante reproducción son tareas de los agentes. Las personas hacen una sola cosa: aprobar.

Trabajamos así porque estamos cada vez más convencidos de que el cuello de botella del control de riesgos nunca ha sido la detección, ni la velocidad con que se ponen en producción las reglas, sino el traspaso. Quien detecta un patrón de fraude y quien puede convertirlo en una defensa a menudo no son la misma persona.

Durante los últimos veinte años, todo el sector ha optimizado cada eslabón de esta cadena de traspasos: los motores de reglas permiten a los analistas poner reglas en producción por sí mismos, los almacenes de características evitan que los ingenieros reescriban los flujos de datos cada vez y el reentrenamiento automático permite actualizar los modelos a diario. Pero el traspaso en sí nunca ha desaparecido. Un patrón nuevo sigue teniendo que pasar del analista al ingeniero y de ahí al científico de datos, y cada traspaso cuesta tiempo y puede perder información.

¿Qué pasa cuando el traspaso desaparece? Tras siete semanas:

A finales de agosto descubrimos una red que usaba documentos de identidad ajenos para registrar cuentas en masa y cobrar recompensas por invitación. Esta alerta no solo dejó al descubierto algunos huecos en las reglas, sino problemas antiguos de todo el flujo de KYC. Durante este periodo, todas las decisiones humanas de KYC (aprobaciones, rechazos, revocaciones) las firmó la misma persona.

1Las organizaciones de riesgos se construyen alrededor de los traspasos

Afterpay es una empresa que hace muy bien el control de riesgos financieros y un referente del sector de compra ahora y paga después (BNPL). En el momento del pago, cada pedido pasa por controles en tiempo real de fraude y de capacidad de pago, y la pérdida neta por transacciones se ha mantenido durante años por debajo del 1 % de las ventas^{1Afterpay, FY21 Annual Report, ASX, 25 de agosto de 2021.}. De 2019 a 2023 trabajé casi cinco años en Afterpay; tanto el flujo de pago como los sistemas de préstamos a plazos en los que trabajé exigían una colaboración muy estrecha con el equipo de riesgos, y pude ver de cerca cómo funcionaba ese sistema.

El área de riesgos de Afterpay era una organización con una división del trabajo muy fina:

• analistas de fraude, crédito y riesgo de comercios, que detectaban problemas y definían estrategias;
• científicos de características, que convertían el criterio de los analistas en características calculables;
• ingenieros de la plataforma de características, del backend de riesgos y de la plataforma de aprendizaje automático, que convertían características y reglas en sistemas en producción;
• científicos de datos, que entrenaban y actualizaban los modelos.

Un patrón nuevo solía seguir este recorrido: los analistas revisaban casos y buscaban tendencias a diario, y primero escribían una regla de emergencia para contenerlo; después, junto con el equipo de ciencia de características, proponían características nuevas y las pasaban al equipo de ingeniería para implementarlas y ponerlas en producción; por último, el equipo de modelos reentrenaba. Decenas de personas repartidas entre Melbourne, Sídney, San Francisco y Shanghái sostenían juntas esa única decisión en tiempo real en el momento del pago.

Es un sistema maduro y eficaz, y sus resultados están a la vista. Pero su forma la determinan los traspasos: cada especialidad adicional añade un traspaso, y cada traspaso hay que planificarlo y puede perder algo de información.

No es algo exclusivo de Afterpay. Si se repasan los blogs de ingeniería de distintas empresas de la última década, aparece casi la misma forma:

• Descubrir depende de personas. Los ingenieros de Stripe redactaban informes de investigación detallados sobre cada ataque pasado, se reunían cada semana para analizar las tendencias de fraude, incluida la dark web, y de ahí sacaban ideas para características nuevas. Los primeros analistas de riesgos de Uber revisaban 30 días de datos, descomponían un comportamiento en distribuciones de características y probaban cientos de combinaciones^{2Uber, “Engineering Uber Systems to Combat Fraud”, 30 de junio de 2016.}. En 2017, Coinbase atrapó a una red gracias a que un analista notó que sus miembros siempre usaban la misma resolución de pantalla^{3“Risk at Coinbase”, diapositivas de la charla en QCon New York 2017.}.
• Programar depende de otras personas. Los analistas de Grab escribían antes las reglas en inglés y se las pasaban a los ingenieros para que las tradujeran a código, y en la traducción se colaban errores. En Lyft, alinear las definiciones de características entre científicos e ingenieros llevaba meses de idas y vueltas, y el equipo tuvo que organizar una y otra vez “salas de guerra de características”^{4Lyft, “From shallow to deep learning in fraud”, 9 de julio de 2018.}. Según datos de Airbnb, quienes trabajaban en aprendizaje automático dedicaban el 60 % de su tiempo a preparar datos^{5Airbnb, Zipline, charla en Strata NY 2018.}.
• La escala depende de sumar personas. En 2023, Revolut anunció que su equipo de delitos financieros ya superaba las 2500 personas, más de un tercio de toda su plantilla^{6Revolut, “Revolut doubles financial crime headcount to combat rising industry fraud”, 2023.}.

Cada traspaso lleva implícito un supuesto: quien entiende los datos no sabe escribir código de producción, y quien escribe el código no tiene tiempo de mirar los datos.

2Qué ha optimizado el sector en veinte años

Cada eslabón de esta cadena se ha optimizado a conciencia:

• Poner reglas en producción. Mastermind, de Uber, permitió a los analistas poner reglas en producción por sí mismos en minutos, cuando antes tenían que esperar a que un ingeniero le dedicara una hora. Griffin, de Grab, redujo un cambio de reglas de una semana a un minuto^{7Uber, “Mastermind”, 8 de marzo de 2017; Grab, “Griffin”, 28 de octubre de 2019; Airbnb, “Chronon … is now open source”, 8 de abril de 2024; Stripe, “Shepherd: How Stripe adapted Chronon”, 15 de abril de 2024; Uber, “Project RADAR”, 1 de febrero de 2022.}.
• Desarrollo de características. Zipline, de Airbnb, y su sucesor, Chronon, redujeron la preparación de un conjunto nuevo de características de meses a alrededor de un día, y más tarde Stripe también lo adoptó^{7Uber, “Mastermind”, 8 de marzo de 2017; Grab, “Griffin”, 28 de octubre de 2019; Airbnb, “Chronon … is now open source”, 8 de abril de 2024; Stripe, “Shepherd: How Stripe adapted Chronon”, 15 de abril de 2024; Uber, “Project RADAR”, 1 de febrero de 2022.}.
• Descubrimiento automático. RADAR, presentado por Uber en 2022, extrae automáticamente reglas candidatas de las anomalías en las curvas de pérdidas y luego las pasa a los analistas para que las aprueben^{7Uber, “Mastermind”, 8 de marzo de 2017; Grab, “Griffin”, 28 de octubre de 2019; Airbnb, “Chronon … is now open source”, 8 de abril de 2024; Stripe, “Shepherd: How Stripe adapted Chronon”, 15 de abril de 2024; Uber, “Project RADAR”, 1 de febrero de 2022.}.

Son avances reales. Pero lo que optimizan es el costo del traspaso; no lo eliminan. Un patrón nuevo todavía tiene que verlo primero una persona, y lo que esa persona puede ver depende de qué características le hayan preparado otros de antemano.

3Un experimento de siete semanas

Al diseñar este sistema de control de riesgos centrado en la IA, fijamos un principio:

En control de riesgos, todo lo que puede delegarse en agentes se delega en agentes; las personas solo aprueban.

Tras siete semanas, el principio se ha llevado a la práctica así:

• Desde el 26 de agosto, los 29 cambios de código enviados relacionados con KYC y control de riesgos los han escrito agentes, y una persona los ha revisado y fusionado.
• En cada revocación de cuenta, un agente redacta la evidencia y la lista, y la revocación solo se ejecuta después de que una persona la confirme lote por lote.
• Las investigaciones las lideran los agentes: verifican, cotejan y redactan informes sobre una vista de solo lectura de los datos de producción; qué es cada caso y qué hacer con él lo deciden personas.

El sistema tiene tres capas:

1. Capa de reglas. Un conjunto de reglas deterministas que se ocupan de los conflictos evidentes que no requieren juicio. Esta capa tiene un único poder: detener una solicitud. Nunca puede aprobar a nadie.
2. Agente de revisión. Cada solicitud la revisa un modelo de principio a fin. Lee los documentos de identidad, los verifica y, mediante un conjunto cerrado de herramientas de solo lectura, también puede cotejarlos con otras cuentas de la plataforma. Emite un veredicto: dejar pasar, detener o escalar a una persona. Pero el código es el último respaldo: si no se hizo una comprobación obligatoria, o si la capa de reglas ya detuvo la solicitud, que el agente diga “dejar pasar” no cuenta.
3. Agente de auditoría de cohortes. Cada solicitud, vista por separado, puede no tener nada de malo; el problema está en un grupo de personas, en las relaciones entre ellas. De vez en cuando, Jarsy organiza campañas de recompensas por invitación: un usuario existente invita a un amigo a registrarse y, cuando este supera la verificación de identidad, quien lo invitó recibe una recompensa. Este tipo de campañas atrae de forma natural a quienes buscan cobrar recompensas en masa. Antes de cada liquidación y pago de una campaña, la auditoría de cohortes examina juntos a todos sus participantes: quién está vinculado con quién, cómo se formaron esos vínculos y si el grupo en conjunto parece de usuarios reales. Después recomienda revocar, aplazar o mantener, y adjunta la evidencia. El razonamiento sobre relaciones es justamente donde los modelos tradicionales son más débiles: una investigación que Revolut publicó este año mostró que un modelo fundacional de transacciones que modela a cada usuario por separado rindió un 47 % peor que el sistema de producción que Revolut ya tenía en problemas relacionales como la prevención del lavado de dinero^{8Revolut Research y NVIDIA, PRAGMA, arXiv 2604.08649, abril de 2026 (v2: agosto de 2026).}. Antes, esta parte dependía de analistas veteranos que revisaban los casos uno por uno; ahora la hace un agente.

¿Dónde están las personas? A la salida de cada capa: una persona resuelve las solicitudes detenidas, aprueba las listas de revocación lote por lote y fusiona cualquier cambio en reglas o código.

Límites para los datos y las decisiones. Lo que un agente puede ver y hacer lo fija el código de antemano: solo puede leer datos a través de ese conjunto de herramientas de solo lectura y no puede modificar ningún registro; usa la API comercial de Anthropic, y según los términos comerciales estos datos no se usan para entrenar modelos. Las decisiones también tienen límites: las máquinas solo pueden dejar pasar o detener, rechazar una solicitud siempre lo hace una persona, y toda decisión desfavorable para un solicitante lleva la firma de alguien.

4La cronología de siete semanas

Lo más importante de esta tabla es la columna “Quién lo hizo”.

En una cadena tradicional, la granja de documentos del 26 de agosto probablemente habría seguido este recorrido: un analista detecta la anomalía, redacta un informe de investigación y abre un ticket; un ingeniero lo incluye en su planificación y convierte algunos de los patrones en reglas; un científico de datos evalúa si hay que añadir características y si hay que reentrenar. Entre cada paso y el siguiente hay una cola.

Ninguna empresa ha publicado cuánto tarda esta cadena de principio a fin. Lo que sí se ha publicado son cifras de un solo eslabón después de acortarlo: Grab redujo un cambio de reglas de una semana a un minuto, y Airbnb redujo la preparación de un conjunto nuevo de características de meses a alrededor de un día. Cuánto suma la cadena completa, nadie lo ha informado nunca.

En Jarsy, pasar del descubrimiento a una defensa en producción llevó tres días, sin tickets ni planificación de por medio. La sesión del agente que investigó la red y la sesión del agente que escribió el código de las reglas partían de los mismos hechos.

Un bucle todavía más rápido ni siquiera requiere cambiar código: cuando se revoca una cuenta, la capa de reglas detiene automáticamente las solicitudes posteriores vinculadas a ella y las pasa a revisión humana. El propio acto de revocar se convierte en evidencia para el siguiente juicio.

Una alerta desencadenó una reconstrucción. Aquella granja de documentos no solo dejó al descubierto algunos huecos en las reglas, sino problemas antiguos de todo el flujo de KYC:

• los usuarios subían imágenes de su galería, no fotos tomadas en el momento;
• el modelo se llamaba una sola vez, sin herramientas, y no podía consultar otras cuentas;
• ni las decisiones de la máquina ni las de las personas dejaban registro.

En una organización tradicional, esto sería un proyecto de un trimestre que exige aprobación formal, planificación y coordinación entre varios equipos. Nosotros tardamos nueve días: en los nueve días posteriores a la alerta, el backend de KYC fusionó 24 pull requests relacionados, y todo, desde los requisitos, el diseño y la implementación hasta la validación en el entorno de preproducción y la revisión independiente, lo hicieron agentes. Lo que hicieron las personas fue aprobar cada etapa y dar el visto bueno antes de cada paso a producción.

La experiencia en riesgos reescribió directamente el diseño de la siguiente campaña. La retrospectiva de cada campaña decide directamente cómo será la siguiente: a quién se invita, qué cuentas se excluyen, qué comportamientos no cuentan para la recompensa y hasta qué tamaño puede crecer la lista. El tope de la lista se fija según lo que la revisión humana puede absorber, no según el presupuesto. En una organización tradicional, estas lecciones tendrían que pasar del equipo de riesgos al de crecimiento; aquí, la retrospectiva y el diseño de la siguiente campaña salen del mismo bucle.

Detrás hay otro proceso de desarrollo diseñado también en torno a “eliminar los traspasos”. Ese proceso es el tema de nuestro próximo artículo.

5Qué les queda a las personas

Cuando la investigación y el código pasan a los agentes, el trabajo humano se reduce a tres cosas. De cada una podemos dar un ejemplo concreto de estas siete semanas.

1. Decidir qué cuenta como fraude. En la segunda campaña de recompensas por invitación, a finales de septiembre, el agente de auditoría detectó que un usuario había atraído a un grupo de usuarios nuevos en cinco días. Todos eran personas reales, con documentos auténticos, y vistos uno a uno no tenían nada que objetar; pero en conjunto, el comportamiento de esas cuentas claramente no era el de usuarios reales. A continuación, el agente encontró en internet publicaciones de ese usuario que ofrecían una recompensa por registrarse, a repartir a medias. ¿Es esto fraude? Cada persona es un individuo real, pero sus registros de KYC, en la práctica, se compraron. Es una decisión de política, no un problema de reconocimiento de patrones. El 28 de septiembre, el equipo decidió: pagar a personas para que se registren equivale a comprar registros de verificación aprobados. Después, el agente ejecutó las revocaciones.

También hay ejemplos en sentido contrario. El 7 de octubre, el equipo fijó un principio: una sola señal anómala no constituye evidencia. Un video de un influencer puede traer en un día una oleada de registros reales; lo que parece anómalo no siempre es fraude.

2. Aprobar. En cada lote de revocaciones, el agente presenta primero la lista, la evidencia y cuánto se dejará de pagar en recompensas tras revocar, y una persona confirma lote por lote. Que se haya confirmado el lote anterior no significa que el siguiente pueda ejecutarse automáticamente.

3. Rendir cuentas. En estas siete semanas, todas las decisiones humanas de KYC las firmó la misma persona. Cada decisión queda en el registro de auditoría: quién la tomó, en qué se basó y qué veredicto de la máquina anuló.

Escritos como reglas, los derechos de decisión se resumen así:

• La capa de reglas solo puede detener una solicitud, no aprobarla.
• El agente emite el veredicto y el código lo ejecuta; si falta una comprobación obligatoria, el veredicto se rebaja automáticamente.
• Revocaciones, cambios de reglas y cambios de código: cada uno lleva la firma de una persona.

Una consecuencia directa: ahora el eslabón más lento son las personas. Desde que se envía una solicitud hasta que la máquina emite un veredicto, la mediana es de 1,4 minutos; una solicitud detenida espera una mediana de 21 horas hasta que una persona la resuelve. El cuello de botella se ha desplazado de “ver” y “programar” a “aprobar”.

En su artículo sobre harness engineering, OpenAI defiende que cuantos menos puntos de control haya para fusionar código, mejor^{9OpenAI, “Harness engineering”.}. En finanzas, nuestra postura es justo la contraria: los agentes eliminan los traspasos entre los puntos de control; las personas custodian los puntos de control en sí.

6Evaluación: en qué se apoya una persona para atreverse a aprobar

En una cadena de traspasos, la calidad depende de las muchas manos por las que pasa el trabajo: lo ha visto el analista, lo ha visto el ingeniero, lo ha visto el científico de datos, y entonces se pone en producción. Sin la cadena, esos ojos también desaparecen. Lo único en que puede apoyarse una persona para atreverse a aprobar lo que le entrega un agente es la evaluación. En un negocio financiero, cada cambio en un algoritmo es en sí mismo un cambio que debe auditarse.

Los laboratorios de IA de vanguardia han publicado mucho de lo que han aprendido sobre la evaluación de agentes. “Demystifying evals for AI agents”, que Anthropic publicó en enero de este año^{10Anthropic, “Demystifying evals for AI agents”, 9 de enero de 2026.}, SWE-bench Verified^{11OpenAI, SWE-bench Verified, agosto de 2024.}, HealthBench^{12OpenAI, HealthBench, mayo de 2025.} y GDPval^{13OpenAI, GDPval, septiembre de 2025.}, de OpenAI, y la evaluación de su agente de fraude que Coinbase publicó en octubre de 2026^{14Coinbase, “Part one: how Coinbase built, evaluated and post-trained a fraud agent”; Coinbase, “Owning Intelligence, Part 2”, 7 de octubre de 2026.} se pueden resumir en unos cuantos principios. Hemos contrastado nuestras prácticas con cada uno:

Un ejemplo concreto: la actualización de modelo de septiembre

Antes de pasar el agente de revisión de Opus 5 a Opus 5.5, hicimos una reproducción siguiendo los principios anteriores.

• Conjunto de evaluación. 48 solicitudes de producción ya resueltas por una persona, divididas en tres estratos según el “veredicto humano” y el “veredicto de la máquina en su momento”. Cuatro de las solicitudes rechazadas por una persona ya las había detenido la capa de reglas, así que no ponen a prueba al modelo y se cuentan aparte.
• Cambiar una sola variable. Los prompts, las herramientas, la capa de reglas y el respaldo en código no cambiaron. Claude tiene un parámetro de “esfuerzo de razonamiento” (effort) que determina cuánto piensa el modelo antes de responder: cuanto más alto el nivel, más cuidadoso, pero también más lento y más caro. Opus 5 usa high por defecto; Opus 5.5 usa medium, un nivel por debajo. Para cambiar solo el modelo, fijamos explícitamente Opus 5.5 en high, igual que el modelo anterior; su valor por defecto, medium, se probó aparte como un grupo propio.
• Calificación. Reproducción de solo lectura. La lectura de documentos se califica con los dígitos de control. Los tres casos de rechazo con discrepancias se volvieron a ejecutar tres veces más en cada grupo.

Cómo leer estas tres tablas. Un total de 39 frente a 40 no dice nada; lo que miramos son las discrepancias entre los dos modelos sobre los mismos casos: en 7 casos el veredicto fue distinto, el modelo antiguo acertó en 3 y el nuevo en 4, sin diferencia estadística. La celda de fraude que se deja pasar bajó de 8/9 a 7/9, lo que parece un retroceso; al volver a ejecutarlos, resultó que eran casos límite que ningún modelo resuelve de forma estable: dos de cada tres veces se dejan pasar. Casos así son justo los que más necesita un conjunto de regresión: lo que se exige no es acertar una vez, sino acertar siempre. Conclusión: la calidad del juicio se mantuvo, hubo tres detenciones por exceso de cautela menos, el costo bajó un 37 % y el tiempo se redujo a la mitad. Pusimos en producción Opus 5.5 · high.

Por último, la evaluación es solo una de las capas. La propia producción genera señales de evaluación de forma continua: la proporción de casos que la máquina dejó pasar y que luego una persona revocó, la proporción de veredictos de la máquina que anularon las personas y el motivo de cada anulación quedan en el registro de auditoría. Junto con la evaluación por reproducción, sustituyen a los muchos ojos por los que pasaba el trabajo en la antigua cadena de traspasos.

7Dónde no se aplica

• Volumen. Nuestro volumen no está en el mismo orden de magnitud que el de una gran fintech. Una mediana de 21 horas para la decisión humana es aceptable con nuestro volumen; con uno o dos órdenes de magnitud más, no lo sería. Llegado ese punto, o se amplía el ámbito en el que la máquina decide directamente, o la aprobación humana también tiene que escalonarse.
• Latencia. El KYC es asíncrono: se pueden dedicar decenas de segundos y algo más de diez centavos a examinar con cuidado una solicitud. La autorización de pagos tiene un presupuesto de menos de 100 milisegundos, así que este enfoque no se puede trasladar sin más. Por eso el agente de revisión de transacciones de Coinbase solo examina una parte de las transacciones.
• Etiquetas. La verdad sobre el fraude sigue llegando despacio. Un agente puede proponer hipótesis rápidamente, pero verificarlas sigue exigiendo esperar a los resultados.
• Que firme una sola persona también es un riesgo. Durante estas siete semanas, todas las decisiones humanas recayeron en una sola persona. Eso demuestra que esta forma de organización funciona, y también que hoy tiene un punto único de fallo.
• Regulación. Todavía no está definido cómo encajan los modelos de control de riesgos en los marcos de gobernanza de la banca; la nueva guía de los reguladores estadounidenses de abril de 2026 dejó explícitamente la IA generativa y la IA agéntica para la siguiente ronda de consultas.

8Próximos pasos

Autoevolución. Hoy, mejorar este sistema todavía requiere que una persona dé el primer paso: alguien anula un veredicto, o una auditoría descubre una red nueva, y entonces alguien abre una sesión de agente para cambiar las instrucciones o las reglas. Lo siguiente es que la evolución ocurra por sí sola, pero que cada paso siga esperando la aprobación humana. Pensamos hacerlo en tres etapas:

• Primero, hacer evolucionar las instrucciones y las reglas. Cada semana, un agente lee las discrepancias de esa semana entre la máquina y las personas, usa un método reflexivo de evolución de prompts para buscar mejores instrucciones de revisión sobre casos históricos y las abre, junto con los cambios en las reglas, como un cambio pendiente de aprobación humana (un pull request), con una comparación por reproducción adjunta: qué casos mejoraron y cuáles empeoraron. El ejemplo más representativo de este tipo de métodos es GEPA^{16GEPA, arXiv 2507.19457 (presentación oral en ICLR 2026).}, que con entre cien y doscientas muestras ya supera al aprendizaje por refuerzo, justo el volumen de etiquetas que tenemos ahora.
• Después, ampliar la búsqueda. Cuando se acumulen más etiquetas, evaluar varias versiones candidatas a la vez, ejecutarlas primero en modo sombra sobre el tráfico real y cambiar solo cuando se confirme su rendimiento.
• Por último, entrenar nuestro propio modelo. Cuando un juicio acotado haya acumulado suficientes resultados reales ya maduros, usaremos aprendizaje por refuerzo para entrenar un modelo pequeño y especializado como señal complementaria. Coinbase hizo público este camino en octubre de 2026: un modelo de pesos abiertos de 9000 millones de parámetros, entrenado con resultados reales de fraude, superó a Opus en su benchmark^{14Coinbase, “Part one: how Coinbase built, evaluated and post-trained a fraud agent”; Coinbase, “Owning Intelligence, Part 2”, 7 de octubre de 2026.}. A este camino no le falta capacidad de cómputo, sino una gran cantidad de etiquetas fiables, que es justo lo que todavía no tenemos.

Lleguemos a la etapa que lleguemos, hay líneas que no se moverán: los criterios de calificación son fijos, y el optimizador no puede tocar ni el método de calificación ni el conjunto de prueba reservado para la verificación final; la reproducción solo ve los datos que existían en el momento de la solicitud; y cada evolución es un cambio legible, auditable y reversible que solo entra en producción después de que una persona lo apruebe.

De la identidad a toda la plataforma. Hoy este sistema solo cubre la capa de identidad. El siguiente paso es extenderlo a cada superficie de riesgo de la plataforma, y la unidad del control de riesgos pasará de “una solicitud” a “una persona”: las cuentas, los dispositivos, las cuentas bancarias y las billeteras de una misma persona se agrupan bajo una misma entidad, y la identidad, las relaciones, los fondos y el comportamiento se juzgan dentro de un mismo caso.

• Entradas y salidas de fondos, off-chain y on-chain. El cribado del origen de los depósitos, la puntuación del destino de los retiros, la verificación de la titularidad de las billeteras y la simulación de transacciones antes de firmarlas son capacidades ya maduras en el mercado: las compraremos, no las construiremos. Lo que nos toca es que los agentes juzguen esas puntuaciones externas junto con nuestros propios datos de identidad y relaciones, dentro de un mismo caso.
• Comportamiento económico dentro de la plataforma. En esta capa, los proveedores externos no pueden ayudar: nuestros mecanismos de precios y liquidación los diseñamos nosotros, y las formas de aprovechar sus resquicios solo podemos definirlas nosotros. En septiembre ya hicimos con agentes una auditoría completa de los precios y la liquidación de la plataforma, revisando uno por uno varios tipos de técnicas que podrían aprovechar resquicios de las reglas. La conclusión fue que no había un aprovechamiento sistemático, pero encontramos algunos puntos en los que las propias reglas favorecían cierto tipo de comportamiento, lo que después llevó a modificar el mecanismo de liquidación. El siguiente paso es que esta auditoría deje de ser puntual y pase a ser continua.

Cuanto más nos extendamos, más claro está que algunas cosas no se delegarán en agentes: el bloqueo por listas de sanciones es una regla determinista; la firma, los desembolsos y el cálculo de precios y liquidaciones deben ser código reproducible; un agente solo puede añadir un control más a una transacción, nunca relajar ninguno; y la medida final desfavorable para un usuario siempre la decide una persona. Tampoco afirmaremos que podemos detectar cualquier manipulación: incluso la mayor empresa de análisis on-chain del sector dice solo que lo que encuentra son “patrones”, no “intenciones”. Hasta que los retiros puedan bloquearse de verdad, no diremos que hemos logrado una protección completa desde la identidad hasta los fondos.

Nuestras apuestas

• Para mediados de 2027, el control de riesgos de Jarsy ya no tendrá el paso de “pasarle un patrón a otra persona para que lo implemente”. Del descubrimiento, la programación y la verificación hasta la puesta en producción, cada cambio en una defensa será un cambio redactado por un agente, acompañado de resultados de reproducción y aprobado por una persona.
• Para finales de 2027, el mismo conjunto de agentes cubrirá todas las superficies de riesgo de la plataforma: desde la verificación de identidad, pasando por las entradas y salidas de fondos on-chain y off-chain, hasta la actividad de trading dentro de la plataforma.
• Mirando más lejos, para 2029, creemos que la forma de la mayoría de los equipos de riesgos financieros habrá cambiado: su tamaño ya no crecerá linealmente con el volumen de negocio, sino que dependerá de cuántos juicios necesite hacer la empresa. La capacidad central de un equipo de riesgos pasará de “descubrir y programar” a “definir, aprobar y rendir cuentas”.