Saque la lógica de decisión de su código
La política de crédito vive en sentencias if repartidas por tres servicios, en una hoja de cálculo en el portátil de alguien y en la cabeza de una persona. Cambiar un umbral significa un ticket, un sprint y un despliegue, y nadie sabe decir cuál es la política actual.
Autoríaasistida por IA
Análisisde impacto
Aprobaciónantes del release
Trazas dedecisión
Cuatro cosas tienen que cumplirse en una lógica de decisión sobre la que se pueda operar un negocio regulado. Hay que poder construirla sin un ingeniero, demostrar que un cambio es seguro antes de publicarlo, explicar cualquier resultado meses después y ser dueño de lo que ha construido.
Entra una política de crédito. Sale un flujo de decisión.
Noventa segundos de principio a fin. Entra el documento, el asistente propone cada artefacto que va a crear, y una persona lo aprueba antes de que se cree nada.
Transcripción
Esta es una política de crédito. Tres páginas de reglas, criterios de scoring y políticas de pricing. Escrita por un equipo de riesgos, no por un programador.
Vea lo que ocurre cuando se la entrega a Decisimo.
Lee el documento y extrae todos los requisitos. Después determina cuáles son reglas, cuál es un scorecard y cuál es un árbol de pricing.
Y le dice exactamente qué va a crear, dibujando el flujo antes de construir nada.
Cada valor se contrasta con su documento. No puede inventarse ninguno.
Y nada se crea hasta que usted lo aprueba.
Ahora construye la lógica real y ejecutable.
Abra cualquiera de ellas y ahí están las reglas reales, con sus condiciones. Edad. Capacidad de pago. Todas editables.
Y el árbol de pricing recoge cada rama del documento. Tipo de préstamo, categoría de producto, importe. Cada tipo de interés tal como estaba escrito.
Todos los objetos creados, a partir de un solo PDF. Versionados, verificables y listos para revisar.
Con un endpoint activo, una clave de API y datos de prueba tomados de la propia lógica.
De un documento de política a un flujo de decisión en marcha. Sin programar.
Decisimo. Lógica de decisión fácil de crear, y fácil de cambiar.
La IA escribe el primer borrador. Usted aprueba cada línea.
Cuando la mayoría de proveedores dice IA se refiere a un chatbot de soporte. Aquí es la forma en que se escribe y se mantiene la lógica de decisión, con una persona aceptando cada cambio.
Desde un documento de política
Suba la política de crédito o el manual de suscripción en PDF. El sistema lo lee, descompone los requisitos y propone un flujo de decisión completo: conjuntos de reglas, tablas de decisión, consultas y enrutamiento, como entidades reales listas para revisar.
Cámbiela en lenguaje natural
Cada artefacto tiene su propia conversación. Describa el cambio ("añadir un corte de deuda sobre ingresos del 45% para autónomos") y el asistente propone la edición exacta sobre la lógica que ya existe.
Un plan, no un botón de guardar
Las propuestas llegan como una lista de cambios discretos, cada uno aprobable por separado y con un diff visual de lo que va a cambiar. Nada se aplica en silencio. La persona no es un sello de goma dentro del flujo: la persona es el flujo.
Los artefactos por debajo
Conjuntos de reglas, tablas de decisión con intervalos abiertos y cerrados, árboles de decisión, scorecards, funciones de fórmula matemática, modelos de ML importados y consultas REST o XML ejecutadas en paralelo.
No puede inventarse sus números
Cada propuesta de la IA pasa por una capa de verificación que contrasta todos los valores declarados (umbrales, límites, identificadores y códigos) con lo que usted ha dicho y con lo que existe en sus datos. Lo que no queda respaldado se detecta y se devuelve para corregirlo. Es un control de ingeniería, no una instrucción en un prompt, y responde a lo primero que piensa un responsable de riesgos sobre una política escrita por IA.
Demuestre que el cambio es seguro antes de publicarlo
Cada cambio en decisiones en producción es un evento de riesgo. Casi ningún equipo puede cuantificarlo por adelantado.
- Tests unitarios en cada artefacto, con datos de prueba generados a partir de los propios umbrales de la lógica en lugar de escritos a mano.
- Validación de tablas de decisión que detecta filas solapadas e inalcanzables antes de que lleguen a producción.
- Suites de regresión capturadas de ejecuciones reales. Guarde una ejecución real como caso de prueba y vuelva a lanzar la suite tras cualquier cambio para ver qué se movió y contra qué expectativa.
- Análisis de impacto antes de desplegar. Pase un conjunto de escenarios por la lógica actual y por la propuesta, y vea qué decisiones cambian y cuánto.
- Champion y challenger con tráfico real, para que una política nueva se demuestre antes de convertirse en la política.
- Secuencias de aprobación y diffs calculados entre releases. Nada llega a producción fuera de un release, y el diff se calcula en lugar de recordarse.
Responda la pregunta meses después
La pregunta nunca es si hay logs. Es si alguien que no es ingeniero puede abrir una decisión y explicársela a quien la reclame.
- Traza de ejecución paso a paso. Qué pasos se ejecutaron, en qué orden, qué recibió y devolvió cada uno y cuánto tardó.
- Explicación a nivel de regla y de scorecard. Qué regla se activó, sobre qué valor y desde qué ruta de entrada, y la contribución de cada predictor a una puntuación.
- Trazabilidad de la transformación de datos. Fase a fase: cuántos registros entraron, cuántos se filtraron y por qué, qué se agrupó y agregó, y qué salió.
- Historial de versiones en cada entidad. La versión de la lógica que tomó una decisión hace seis meses sigue ahí, y sigue siendo legible.
- Log de auditoría de la plataforma. Cada consulta, edición, prueba, exportación, despliegue e inicio de sesión, con actor, hora e IP.
Márchese cuando quiera
Una estrategia de salida que puede archivar, en lugar de la promesa de ayudar en una migración.
- Resultados de decisión en una base de datos suya. Configure un destino en su propio Postgres y los resultados se escriben en una tabla de su infraestructura.
- La lógica de decisión se exporta como archivo Markdown. Legible, portable y revisable, no bytecode compilado que nunca podría reconstruir.
- Ejecución donde la necesite. Endpoints regionales por latencia y residencia, o un nodo de ejecución en su propio entorno.
- Integración ordinaria. REST y JSON de entrada y de salida. Nada de su arquitectura se adapta a la forma de Decisimo.
- Sus contratos de datos siguen siendo suyos. Las credenciales de burós y proveedores viven en un vault que usted controla y apuntan a sus propios contratos.
Qué hay realmente dentro
La superficie completa, para la hoja de evaluación.
| Área | Capacidades |
|---|---|
| Artefactos de decisión | Conjuntos de reglas con comparaciones numéricas, de texto y de fecha, incluidas coincidencias por inicio y por final · tablas de decisión con intervalos abiertos y cerrados · árboles de decisión · scorecards · funciones construidas como fórmulas matemáticas, sin escribir código · modelos de ML importados · objetos de datos y vectores de atributos |
| Datos | Fuentes REST/JSON y XML llamadas en paralelo · fuentes con OAuth2 · integraciones de proveedores listas · OCR para extracción documental · servicios LLM invocables dentro de un flujo · mapeo con JSONPath, timeouts y alternativas |
| Flujo | Constructor visual de flujos de decisión · ramificación condicional · bifurcaciones champion/challenger · componentes reutilizados entre flujos |
| Pruebas y aseguramiento | Tests unitarios en cada artefacto · datos de prueba generados desde los propios umbrales · tests de regresión capturados de ejecuciones reales · análisis de impacto sobre conjuntos de escenarios · validación de solapamientos y huecos |
| Gobierno | Releases versionados con trazabilidad · diffs calculados entre releases · secuencias de aprobación · historial de versiones en cada entidad · log de auditoría · permisos por rol |
| Ejecución | Endpoints regionales en tiempo real · lotes por FTP, S3 y GCS · nodos de ejecución on-premise · gestión de despliegues |
| Explicabilidad | Trazas de ejecución paso a paso · explicación a nivel de regla y de scorecard · trazabilidad fase a fase de la transformación de datos |
| Seguridad | Vault de credenciales cifrado con autenticación reforzada y rotación · SSO · doble factor · restricciones por IP · permisos por rol · destinos de resultados en infraestructura del cliente |
| IA | Ingesta de documentos de política y propuesta de flujo · autoría conversacional por artefacto con diffs · verificación de valores · aprobación humana paso a paso · datos de prueba, notas de release y explicaciones generadas |
| Trabajo por casos | Expedientes con orden derivado · tareas de revisión humana, IA, OCR, lógica de decisión, datos externos y memo · análisis de impacto sobre casos abiertos · pruebas en sandbox · releases inmutables de diseño |
Decisiones de milisegundos y decisiones de semanas
Los mismos artefactos, el mismo gobierno, dos modelos de ejecución.
- Decisiones en tiempo real para la lógica que se completa sin intervención: llega una petición, se ejecuta el flujo y vuelve una respuesta.
- Trabajo por casos para decisiones que necesitan una persona o esperan evidencia: el expediente se acumula y reejecuta lo que la evidencia nueva invalidó.
Tres cosas distintas se llaman motor de decisiones
Resuelven problemas diferentes a precios muy diferentes. Averiguar cuál tiene delante es la mayor parte de la evaluación.
La plataforma de reglas empresarial
Profunda, probada y diseñada cuando se daba por hecho que IT era dueño de las reglas. Potente para casi todo, y hace falta un especialista formado para cambiar un umbral. Presupuesto de seis cifras, implantación en trimestres y un partner certificado haciendo la implantación.
La tabla de decisión inteligente
Rápida de arrancar y realmente agradable de usar. Llega al techo la primera vez que necesita un modelo dentro del flujo, tres proveedores llamados en paralelo, una aprobación antes del release o una suite de regresión que demuestre que el cambio era seguro.
El recién llegado bien financiado
Moderno, capaz y con precio de presupuesto de gran empresa, normalmente con un forward deployed engineer que lo construye con usted. Eso es un consultor con otro nombre, y una dependencia que se queda en la factura. Póngale precio con su volumen real de decisiones y no con el de la demo, y pregunte cuánto cuesta el segundo año.
Dónde encajamos
Plataforma suficiente para operar decisiones reguladas (pruebas, aprobaciones, trazas, releases) manejada por quienes son dueños de la política, no por un especialista, a un precio que una cartera mid-market puede sostener. Donde las plataformas más nuevas envían un forward deployed engineer a construirlo con usted, nosotros apuntamos el asistente de IA a su documento de política y es su propio equipo quien aprueba lo que propone. Si tiene presupuesto y equipo de gran empresa, la primera categoría puede servirle bien. Y si sus decisiones caben cómodamente en una tabla de decisión, una herramienta más ligera le costará menos y le dará menos trabajo. No tiene sentido pagar por un gobierno que todavía no necesita.
Preguntas para cualquiera, nosotros incluidos
Cada una separa las tres categorías. Hágalas en una demo, no en un RFP, y pida ver la respuesta en lugar de escucharla.
- ¿Puede un analista de riesgos cambiar un umbral y ponerlo en producción sin un ingeniero? Pida ver a alguien hacerlo de principio a fin durante la demo.
- Enséñeme el diff antes de guardar. Si la herramienta no puede mostrar qué va a cambiar, nadie puede aprobarlo.
- Vuelva a ejecutar las decisiones del último trimestre contra la lógica propuesta. ¿Qué decisiones cambian y cuánto? Una herramienta que no responde a esto convierte cada cambio de política en un salto al vacío.
- Abra una decisión de hace ocho meses y explíquemela. En la interfaz, sin un desarrollador, contra la versión de la lógica que estaba viva entonces.
- Llega evidencia nueva que invalida una conclusión a la que un caso ya había llegado. ¿Qué pasa? Si la respuesta pasa por que alguien se dé cuenta, esa es la respuesta.
- ¿Qué dice el contrato sobre marcharse? ¿Dónde van los resultados de decisión, en qué formato se exporta la lógica y puede la ejecución correr en nuestro propio entorno?
- ¿Quién construye la lógica y quién la mantiene en el año dos? Si la respuesta es un forward deployed engineer, pregunte qué pasa cuando termina ese contrato y si su propio equipo puede cambiar una regla sin él.
- ¿Cuánto cuesta con nuestro volumen? No con el de la demo. Pida el número con las decisiones mensuales de hoy y con el triple.
Versión larga: cómo y por qué elegir un motor de decisiones.
Puede vibecodear un motor de reglas este fin de semana
Es cierto, y no es lo interesante. Evaluar condiciones contra un payload nunca fue lo caro, y con una IA al lado son un par de tardes. Esto es lo que aparece en el mes seis.
- El analista sigue sin poder tocarlo. Ha movido el cuello de botella de "ingeniería escribe las reglas" a "ingeniería vibecodea las reglas". Quien entiende la política sigue abriendo un ticket y esperando.
- Un solo autor, ningún revisor. Código generado tomando decisiones de crédito, con el historial de revisión de un proyecto personal. Seis meses después nadie sabe decir por qué el umbral es 45% ni quién lo aprobó.
- El historial de Git no es el historial de decisiones. Dice que el código cambió. No dice qué versión de la lógica tomó la decisión que un cliente está reclamando, qué datos vio ni qué regla se activó.
- El aseguramiento es el producto. Suites de regresión capturadas de ejecuciones reales, análisis de impacto antes de desplegar, diffs calculados entre releases, secuencias de aprobación y una traza que puede leer alguien que no es ingeniero. Eso es lo que cuesta trimestres, y es por lo que pregunta un auditor.
- Alguien tiene que mantenerlo vivo. Las APIs de buró cambian, hay que sustituir un modelo, un regulador pide evidencia. Eso pasa a ser su guardia, para siempre, en un sistema que decide quién recibe crédito.
Constrúyase el motor: esa parte hoy es barata de verdad. Luego ponga precio a los dieciocho meses de todo lo que va alrededor, y pregunte quién lo sostiene cuando se marche quien lo escribió.
Preguntas que nos hacen
¿Hay que usar la IA para construir la lógica de decisión?
No. Todo lo que propone el asistente se puede construir a mano en los mismos editores, y muchos equipos lo hacen. El asistente redacta y mantiene; nunca tiene la última palabra.
¿Qué impide que la IA se invente un umbral?
Una capa de verificación contrasta cada valor de una propuesta con su documento fuente y con sus datos antes de ofrecérsela, y lo que no queda respaldado se devuelve para corregirlo. Después sigue siendo usted quien aprueba cambio a cambio.
¿En qué se diferencia del motor de reglas que ya tenemos?
Los motores clásicos entregaron las reglas a IT. Además no tienen autoría asistida por IA, ni pruebas de regresión integradas, ni análisis de impacto, ni diff calculado entre releases, ni una traza que pueda leer alguien que no sea ingeniero.
¿Por qué no construirlo internamente?
El motor lo tendrán en un trimestre. Lo que no van a construir es el versionado, las aprobaciones, las suites de regresión, el análisis de impacto, la interfaz de trazas y las comprobaciones de verificación, que es justo por lo que pregunta un auditor.
¿De verdad puede cambiar la política en producción alguien que no sea ingeniero?
Ese es el diseño. Un analista de riesgos edita la lógica, lanza la suite de regresión, lee el análisis de impacto y lo envía a la secuencia de aprobación que usted definió. Ingeniería integró una sola vez.