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.
Equipos que deciden solicitudes, límites, precios, fraude y cartera en crédito de consumo y pymes, finanzas integradas y seguros.
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.
Un cambio de política puede probarse en otro lugar distinto de donde se ejecuta; una decisión en producción puede no coincidir con la hoja de cálculo de origen. Meses después, nadie puede reconstruir el razonamiento ante una solicitud del regulador, y el riesgo sigue activo mientras espera una ventana de lanzamiento.
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
Un flujo de decisión responde a cada llamada realizada a su endpoint
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.
De qué está hecha la lógica de decisión
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. 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, sin escribir código, y viven dentro del flujo de decisión donde cualquiera puede verlas.
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
Los bureaus de crédito, las puntuaciones de fraude, las comprobaciones de dispositivos y sus propios servicios mediante REST y JSON o XML se consultan en paralelo dentro del flujo y se integran mediante JSONPath. Las llamadas fallidas quedan visibles para las reglas, que determinan qué significa cada una.
Llamadas a LLM y agentes
Llamadas a modelos de lenguaje y agentes con límites que usted define, donde aporta criterio, gobernados como artefactos versionados, revisados y publicados como el resto de la lógica.
Dónde se ejecuta
Un flujo de decisión responde a llamadas de cualquier sistema, en un endpoint regional o en su propio entorno.
- Endpoints regionales. Endpoints REST en tiempo real, en la región que elija, por latencia y por residencia.
- 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?
Una decisión local tarda milisegundos. Los datos externos suelen determinar la latencia en situaciones reales, por lo que las consultas se ejecutan en paralelo dentro del flujo de decisiones y las llamadas fallidas devuelven un indicador de error para que sus reglas lo gestionen.
¿Necesitamos ingenieros para cambiar una regla?
No. Los analistas de riesgos y los responsables de las políticas pueden crear y modificar la lógica de decisiones en el portal, probarla y enviarla para su aprobación. Sus ingenieros se integran una sola vez mediante una única llamada REST.
¿En qué se diferencia esto del motor de reglas que ya tenemos?
La mayoría de los motores clásicos dejaban los cambios de reglas en manos de TI. También carecen de pruebas de regresión integradas, análisis de impacto, una diferencia calculada entre versiones y un registro de ejecución que una persona no técnica pueda leer. Estas son las partes por las que pregunta un auditor.
¿Podemos demostrar que un cambio es seguro antes de ponerlo en producción?
Sí. Puede capturar pruebas de regresión a partir de ejecuciones reales, realizar un análisis de impacto en un conjunto de escenarios para ver qué decisiones cambiarían, consultar la diferencia entre versiones y poner una nueva política en producción como challenger antes de convertirla en la versión principal.
¿Podemos utilizar nuestro propio modelo?
Sí. Puede importar un modelo entrenado y utilizarlo como parte del flujo de decisiones, con las reglas de la política, los umbrales y las anulaciones que lo rodean en el mismo lugar.
Cuando la decisión tarda días
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.
Verlo decidir
La forma más rápida de juzgar esto es ver un flujo de decisión ejecutarse y luego abrir su traza.