Decisiones en tiempo real
Decisiones directas, sin intervención humana. Llega una petición, se ejecuta un flujo de decisión y la respuesta vuelve en milisegundos, construida y modificada por el equipo de riesgos y no por un tren de releases.
Artefactos, no una caja negra
La lógica de decisión se compone de artefactos con nombre: cada uno se puede abrir, revisar, probar y versionar.
Conjuntos de reglas y tablas de decisión
Reglas de negocio que comparan números, texto y fechas, incluidas coincidencias por inicio y por final, y tablas de decisión con intervalos abiertos y cerrados, que se leen como una hoja de cálculo y se ejecutan como código de producción, con validación de solapamientos y huecos que ninguna hoja de cálculo le dará.
Árboles de decisión y scorecards
Lógica de ramificación y scoring, con la contribución de cada predictor a la puntuación final disponible después en la explicación.
Funciones personalizadas
Fórmulas matemáticas para los cálculos que no caben en una tabla. Se construyen en un editor, no se escriben como código, y viven dentro del flujo de decisión en lugar de esconderse en una aplicación.
Modelos de ML importados
Traiga un modelo entrenado, llámelo como parte del flujo y mantenga la política, los cortes y las anulaciones manuales en el mismo sitio. Sin un proyecto de puesta en producción de dos trimestres.
Consultas de datos en paralelo
Burós, scores de fraude, comprobaciones de dispositivo y sus propios servicios por REST y JSON o XML, llamados en paralelo dentro del flujo, mapeados con JSONPath, con timeouts y planes alternativos.
Llamadas a LLM y agentes
Llamadas a modelos de lenguaje y agentes con guardarraíles, donde aporta criterio, gobernados como artefactos versionados y no como un prompt escrito en una caja de texto.
De una idea a una decisión en producción
En otros sitios este camino pasa por un motor de reglas, una hoja de cálculo, un wiki, un gestor de tickets, un script de pruebas que hizo alguien y un agregador de logs. Las costuras entre ellos son donde vive el riesgo.
| Etapa | Qué hace la plataforma |
|---|---|
| Diseñar | Constructor visual de flujos de decisión, con componentes reutilizables compartidos entre flujos y bifurcaciones champion/challenger incorporadas |
| Probar | Tests unitarios en cada artefacto, datos de prueba generados a partir de los propios umbrales de la lógica, validación de solapamientos y huecos en tablas de decisión |
| Regresión | Guarde una ejecución real como caso de prueba y vuelve a lanzar toda la suite tras cualquier cambio para ver qué se movió y contra qué expectativa |
| Analizar impacto | Pase un conjunto de escenarios por la lógica actual y por la propuesta antes de desplegar, y comprueba qué decisiones cambian y cuánto |
| Comparar | Un diff calculado entidad por entidad entre el release desplegado y el siguiente, no un changelog que alguien se acordó de escribir |
| Aprobar | Secuencias de aprobación configurables. Un release llega a producción por el proceso que definiste y con las personas que nombraste |
| Publicar | Snapshots de release versionados y compilados, con notas generadas y trazabilidad completa |
| Ejecutar | El mismo flujo de decisión en tiempo real en endpoints regionales y en lote por FTP, S3 o GCS |
| Trazar | Cada ejecución se puede abrir y leer: qué reglas se activaron, sobre qué valores, qué puntuó cada modelo |
| Revisar | Historial completo de versiones en cada entidad: quién cambió qué, cuándo y qué decía antes |
El valor está en la ausencia de costuras
No has ensamblado esto con seis herramientas, así que no hay hueco por el que se cuele un cambio. La lógica que probaste es la que se aprobó, es la que se publicó, es la que se ejecutó, es la que puede releer seis meses después.
Ejecución
El mismo flujo de decisión en todos los modos. El lote y el tiempo real no pueden divergir, porque no son dos implementaciones.
- Endpoints regionales. Endpoints REST en tiempo real, en la región que elija, por latencia y por residencia.
- Lotes por FTP, S3 o GCS. El rescoring nocturno de la cartera ejecuta el mismo flujo de decisión que la decisión en el momento de la solicitud.
- Ejecución en su propio entorno. Un nodo de ejecución puede correr en su infraestructura bajo petición; el control de diseño permanece en el portal.
- Integración ordinaria. REST y JSON de entrada y de salida. Una sola llamada desde su sistema core.
Preguntas que nos hacen
¿Cuánto tarda una decisión?
Milisegundos para un flujo que evalúa reglas y modelos localmente. Lo que domina la latencia real son los datos externos que consultas, un buró o un proveedor antifraude, y por eso las consultas se ejecutan en paralelo dentro del flujo, con timeouts y planes alternativos que usted controlas.
¿Necesitamos ingenieros para cambiar una regla?
No. Esa es la idea. Los analistas de riesgos y los responsables de política construyen y cambian la lógica de decisión en el portal, la prueban y la pasan por aprobación. Sus ingenieros integran una vez, con una sola llamada REST.
¿En qué se diferencia del motor de reglas que ya tenemos?
La mayoría de los motores clásicos entregaron las reglas a IT. Además no tienen pruebas de regresión integradas, ni análisis de impacto, ni un diff calculado entre releases, ni una traza que pueda leer alguien que no sea ingeniero. Justo lo que pregunta un auditor.
¿Podemos demostrar que un cambio es seguro antes de publicarlo?
Sí, y es la parte que hoy la mayoría de equipos no puede hacer. Capture tests de regresión de ejecuciones reales, lanza un análisis de impacto sobre un conjunto de escenarios para ver qué decisiones cambiarían, lee el diff entre releases y pon una política nueva en producción como challenger antes de que sea la champion.
¿El lote y el tiempo real usan la misma lógica?
Sí. Son el mismo flujo de decisión, así que el rescoring nocturno y la decisión en el momento de la solicitud no pueden divergir. En otros sitios suelen hacerlo, porque los construyeron personas distintas en momentos distintos.
¿Podemos traer nuestro propio modelo?
Sí. Importe un modelo entrenado y llámelo como parte del flujo, con las reglas de política, los cortes y las anulaciones a su alrededor en el mismo sitio.
Decisiones que tardan días, no milisegundos
Algunas decisiones no se resuelven en una sola petición: la evidencia llega durante días, en desorden y a veces equivocada. Ese es otro tipo de problema y tiene su propia superficie de producto.