Un agente de investigación de fraude que consulta TigerGraph y no se inventa lo que no sabe
El sistema encadena consultas GSQL sobre un grafo de conocimiento, pide la respuesta del titular cuando la política lo exige y registra que no la hubo en lugar de rellenar el hueco. En 50 casos cerrados no falló ningún fraude.
Un equipo ha publicado el diseño y los resultados de un agente que investiga fraude con tarjeta sobre un grafo de conocimiento en TigerGraph. Sobre 50 casos cerrados que no usaron para ajustar nada, no se le escapó ninguno de los 40 fraudes, acertó el patrón en 37 de ellos y dio por legítimos los 10 casos limpios. Lo interesante no es el porcentaje: es que el problema que atacan no es detectar, sino el trabajo lento de reunir pruebas mientras el dinero ya se ha ido.
La pieza se presentó a un reto, así que las cifras son del propio equipo y sobre un conjunto pequeño. No hay despliegue en producción detrás.
El modelo propone, el código decide
Se le da al agente un disparador —una puntuación de riesgo, un aviso del cliente, una petición del analista— y lo trabaja hasta una acción defendible. Abre el caso, resuelve el disparador a una tarjeta, lee el historial, busca anillos de tarjetas que comparten dispositivo, región o correo, y recupera casos previos. Después pesa hipótesis competidoras con su probabilidad y decide si sabe lo suficiente para actuar. Si la política manda preguntar al titular, pregunta; como el conjunto de datos no trae respuestas, anota que no llegó ninguna y vuelve a recomendar aplicando la regla de "sin respuesta". Cuando toca, redacta el informe de actividad sospechosa y escribe el caso de vuelta al grafo.
La arquitectura es una máquina de estados explícita, no un bucle libre: TRIGGERED, CASE_OPENED, INVESTIGATING, ASSESSING, EVIDENCE_PLANNING, AWAITING_EVIDENCE, EVIDENCE_RECEIVED, DECIDING, APPROVAL_ROUTING, EXPLAINING, MEMORY_UPDATE y DONE. Las llamadas a herramientas tienen presupuesto y las rondas de evidencia están acotadas. El modelo propone; el código decide qué se permite.
Ahí están los guardarraíles que más me llaman la atención. El código limita la confianza que el modelo puede declarar según cuántos tipos independientes de evidencia haya mirado de verdad: menos de dos, la deja en 0,45 como máximo; dos, en 0,65. Un modelo de 7B no puede discutir ese techo y el prompt se lo dice. Hay un segundo tope: si un caso se apoya en una sola señal independiente, aunque sea un detector disparando a 1,0, el código mantiene la probabilidad justo por debajo de la línea de bloqueo, de forma que aplique la regla de verificar antes de bloquear.
El detalle del que menos se habla y más importa: cada herramienta acepta un as_of y descarta todo lo posterior. Un caso abierto el 12 de noviembre no ve nada del 13. Lo aplican dentro de las consultas en lugar de fiarse de quien llama, porque en un banco de pruebas de fraude una fuga temporal se parece mucho a un buen resultado.
Las consultas como investigación
El grafo no es una tabla de consulta, es la investigación. El esquema cubre tarjetas, clientes, transacciones, dispositivos, direcciones, dominios de correo, identidades y casos de fraude. Una arista NEXT encadena las transacciones de cada tarjeta en el tiempo, así que medir velocidad o picos es un recorrido corto en vez de un escaneo. Las herramientas del agente son consultas GSQL instaladas a las que llega a través del servidor tigergraph-mcp oficial, sin driver directo: historial, entorno a uno a tres saltos, anillos compartidos, desviación sobre la línea base de la propia tarjeta, puntuaciones de patrones documentados, comunidades y casos previos conocidos en ese instante.
El stack es TypeScript de punta a punta (espacios de trabajo con pnpm, Turborepo, zod en cada frontera, vitest y una interfaz de analista en Next.js), GSQL sobre TigerGraph Community Edition 4.3 en Docker, y Qwen2.5-7B-Instruct en cuantización Q4_K_M sobre llama.cpp con temperatura 0 y la respuesta constreñida a un esquema JSON. Hay GraphRAG para trocear e incrustar la política y las tipologías y entregar evidencia resumida en lugar de filas crudas.
Lo reutilizable no es el caso de uso, es el patrón: separar contratos congelados entre flujos de trabajo, cerrar el paso al grafo por un único servidor MCP y poner los topes de confianza en código en vez de pedírselos por favor al prompt. Queda por ver si algo así aguanta carteras reales, donde los patrones no documentados son la norma y no la excepción.
