Cambió una política de crédito. Hay que ajustar el límite de endeudamiento. Se necesita crear una nueva regla para un determinado perfil de cliente. El cutoff del score debe ser revisado. El equipo de crédito sabe exactamente qué necesita cambiar — pero no puede hacerlo.
Abre una solicitud para TI. Explica la regla. Espera que sea priorizada. Alguien la desarrolla. Después vienen las pruebas, la homologación y, finalmente, la publicación en producción.
Un cambio que podría tomar algunos minutos termina consumiendo días — a veces semanas.
Así siguen funcionando muchas operaciones de crédito. Y ese es precisamente el problema que una nueva generación de plataformas de decisión busca resolver.
Sí, hoy existen plataformas que permiten al propio equipo de crédito configurar, probar y publicar políticas sin depender de desarrolladores para cada cambio. Sinky es una de ellas.
Pero existe una diferencia importante entre tener una interfaz para configurar algunas reglas y realmente dar autonomía al área de crédito.
El problema no es TI. Es la arquitectura.
Cuando una empresa dice que “depende demasiado de TI” para modificar sus políticas de crédito, es fácil pensar que se trata de un problema de procesos o de priorización.
En muchos casos, no es así.
El problema está en cómo fue construido el motor de decisión.
En arquitecturas tradicionales, buena parte de la inteligencia de la política está implementada en código, scripts, procedimientos, APIs o configuraciones que requieren conocimientos técnicos.
Imaginemos que el director de crédito decide que, a partir de mañana, las empresas de un determinado sector solo podrán acceder a un límite mayor si tienen más de 24 meses de actividad y no presentan antecedentes negativos relevantes.
La lógica de negocio es relativamente sencilla:
sector + antigüedad de la empresa + señales de riesgo = nueva regla de límite.
Pero si esa lógica está dentro del código, el equipo que creó la política no puede implementarla directamente.
Entonces aparece una cadena innecesaria:
Crédito define la regla → Producto o Proyectos la documenta → TI la interpreta → Desarrollo la implementa → Crédito la homologa → TI la publica.
Además de ser lento, este modelo crea otro problema: quien mejor conoce la política no necesariamente es quien configura la decisión.
Es aquí donde las plataformas de decisioning no-code o low-code cambian la dinámica.
¿Qué debe ofrecer una plataforma realmente independiente de TI?
El término “no-code” se ha convertido en una categoría demasiado amplia. Prácticamente cualquier sistema con una pantalla de configuración puede utilizarlo.
Para una operación de crédito, eso no es suficiente.
Una plataforma de decisión que realmente dé autonomía al negocio debe permitir que analistas, responsables de riesgo y gestores de políticas trabajen visualmente con los elementos que forman parte de una decisión.
Esto incluye reglas, scores, datos del cliente, información de burós, documentos, variables financieras, modelos de machine learning y criterios de aprobación, rechazo o revisión manual.
Y todos esos elementos deben formar parte de un flujo comprensible.
En Sinky, por ejemplo, una política puede construirse visualmente en Studio, conectando diferentes etapas de la decisión.
El usuario puede definir entradas de datos, conectar fuentes externas, crear reglas condicionales, utilizar scores o modelos, establecer diferentes caminos según el perfil del cliente y determinar el resultado de la evaluación.
En lugar de escribir código para representar una política, la propia política se convierte en el flujo.
Autonomía no significa falta de gobernanza
Existe una preocupación legítima cuando se habla de permitir que el área de crédito modifique políticas directamente.
Si cualquier persona puede cambiar cualquier regla y publicarla inmediatamente en producción, la velocidad puede generar un problema aún mayor.
Por eso, autonomía y gobernanza deben avanzar juntas.
Una plataforma madura de decisión debe permitir controlar quién puede visualizar, editar, aprobar y publicar cambios. También debe mantener un historial de versiones.
Si una política fue modificada un martes a las 14:32, la empresa debería poder responder preguntas simples:
- ¿Quién realizó el cambio?
- ¿Cuál era la regla anterior?
- ¿Qué cambió?
- ¿Quién lo aprobó?
- ¿Qué versión estaba en producción cuando se tomó una determinada decisión?
Esa combinación es la que realmente importa: reducir la dependencia técnica sin perder el control operativo.
No se trata de eliminar procesos de aprobación. Se trata de sacar el código del camino cuando el código no debería ser necesario.
Antes de publicar una regla, hay que saber qué impacto tendrá
Este puede ser uno de los puntos más importantes — y menos discutidos — al evaluar un motor de decisión de crédito.
Cambiar rápidamente una política es útil. Cambiarla rápidamente sin conocer su impacto puede ser peligroso.
Imaginemos que una entidad financiera quiere reducir el cutoff mínimo de un determinado score de 650 a 620. La tasa de aprobación puede aumentar. ¿Pero cuánto? ¿Y cuál sería el impacto esperado sobre el riesgo, la morosidad o la composición de la cartera?
En una infraestructura moderna de decisión, la empresa debería poder probar una nueva política sobre datos históricos antes de llevarla a producción. Ese es el principio del backtesting.
En lugar de discutir un cambio basándose únicamente en hipótesis, el equipo puede analizar cómo se habría comportado la nueva regla sobre solicitudes y decisiones anteriores.
La misma lógica se aplica a pruebas A/B y estrategias champion-challenger.
La pregunta deja de ser:
“¿Creemos que esta política funcionará mejor?”
Y pasa a ser:
“¿Qué muestran los datos cuando comparamos ambas estrategias?”
Parece una diferencia pequeña. No lo es. Cambia la forma en que se gestiona el crédito.
¿Qué ocurre cuando la política depende de datos externos?
Este es otro punto en el que la promesa de autonomía suele encontrar una barrera.
Es relativamente fácil crear una interfaz visual que permita definir: “Si score > 700, entonces…”
El verdadero desafío aparece antes: ¿de dónde viene ese score?
¿Y si la política también necesita consultar burós de crédito, datos bancarios, información antifraude, KYC, estados financieros, registros públicos u otras fuentes externas?
Si cada nueva fuente requiere un proyecto de integración con TI, la empresa sigue dependiendo del equipo técnico. Simplemente cambió el cuello de botella de lugar.
Por eso, la capa de decisión debe estar conectada a una capa de datos.
En Sinky, esto ocurre a través del Data Marketplace, que permite conectar diferentes proveedores y fuentes de información con la infraestructura de decisión.
En la práctica, el dato deja de ser una integración aislada y se convierte en un componente disponible para construir políticas.
Esto también facilita una estrategia cada vez más importante: evitar una dependencia excesiva de un único proveedor de datos. Una empresa puede utilizar una fuente como principal y otra como alternativa, o combinar información de diferentes proveedores dentro de una misma estrategia.
No todas las decisiones deberían ser automáticas
Existe otro error común al hablar de motores de crédito: pensar que el objetivo final es automatizar el 100% de las solicitudes.
En la práctica, una buena política también sabe identificar aquello que no debería decidirse automáticamente.
Hay operaciones sencillas que pueden recibir una respuesta en segundos. Hay operaciones que deben rechazarse automáticamente. Y existe una zona intermedia en la que el contexto y el criterio humano siguen siendo relevantes.
En esos casos, la decisión puede enviarse a una mesa de crédito.
Por eso Sinky Studio se conecta con AI Case Management.
Una política puede determinar que determinados casos sean enviados automáticamente a revisión humana, acompañados de los datos, documentos, resultados de consultas y contexto necesarios para tomar la decisión.
El analista no necesita reconstruir el caso buscando información en diferentes sistemas, hojas de cálculo, correos electrónicos o portales de proveedores. La automatización no necesariamente sustituye al analista: define dónde el criterio del analista realmente aporta valor.
Entonces, ¿qué plataforma permite configurar políticas de crédito sin depender de TI?
Al evaluar una plataforma de decisión de crédito, conviene ir más allá de la pregunta: “¿Es no-code?”. Pregunte si su equipo de crédito puede, de manera autónoma:
- Crear y modificar reglas;
- Construir flujos de decisión;
- Utilizar diferentes fuentes de datos;
- Configurar criterios de aprobación y rechazo;
- Enviar excepciones a revisión manual;
- Probar una política antes de publicarla;
- Mantener diferentes versiones;
- Comparar estrategias;
- Gestionar permisos y niveles de acceso;
- Entender por qué se tomó una determinada decisión;
- Monitorear el desempeño de las políticas después de su publicación.
Si varias de estas actividades todavía requieren desarrollo, probablemente no haya eliminado la dependencia de TI. Simplemente colocó una interfaz delante de ella.
¿Dónde entra Sinky?
Sinky fue creada precisamente para convertir las políticas de decisión en una infraestructura que pueda ser operada por el negocio, sin excluir a tecnología de las áreas donde realmente aporta valor.
En Sinky Studio, los equipos de crédito y riesgo pueden construir visualmente flujos de decisión utilizando reglas, integraciones, scores, modelos de machine learning, decisiones, webhooks y otros componentes.
Las políticas pueden versionarse, auditarse, probarse y evolucionar continuamente.
Cuando una operación requiere análisis humano, el flujo puede continuar hacia AI Case Management. Cuando necesita información externa, puede utilizar fuentes conectadas a través del Data Marketplace. Y cuando la empresa quiere evaluar continuamente a los clientes que ya forman parte de su cartera, la mesma infraestructura puede utilizarse para procesos de monitoreo y reevaluación.
El objetivo no es simplemente crear otro “motor de reglas”. Es construir una capa de infraestructura entre los datos disponibles y las decisiones que la empresa necesita tomar.
TI sigue siendo fundamental. Simplemente deja de ser el cuello de botella.
Dar autonomía al equipo de crédito no significa eliminar a tecnología del proceso. Todo lo contrario.
TI sigue siendo fundamental para arquitectura, seguridad, integraciones corporativas, gobernanza tecnológica y disponibilidad.
Lo que deja de tener sentido es exigir desarrollo cada vez que alguien quiere modificar un cutoff, añadir una condición, cambiar un nivel de aprobación o probar una nueva estrategia de crédito.
Esas son decisiones de negocio. Y una infraestructura moderna debería permitir que quienes entienden esas decisiones también puedan construir, probar y evolucionar las políticas que las sustentan.
Porque, en mercados que cambian rápidamente, una política de crédito no puede tardar semanas en adaptarse a la realidad.
La tecnología debería acelerar la decisión — no convertirse en una fila antes de ella.
