Trabajo por casos
Un banco de trabajo, no un workflow. IA, APIs, lógica de decisión y personas trabajan sobre el mismo expediente, en el orden en que la evidencia llega de verdad, y cada parte de cómo se alcanzó la decisión es trazable, explicable y auditable.
La evidencia no llega en orden
Algunas decisiones no se resuelven en 200 milisegundos. La decisión tarda días o semanas. La evidencia gotea desde una docena de sitios en momentos impredecibles. Una persona revisa una parte. Una IA lee un documento. Un buró responde. Alguien sube un archivo corregido el día nueve que invalida una conclusión del día dos.
La gestión de casos clásica te pide dibujar eso como un diagrama por adelantado. Cada "¿y si esto llega tarde?" se convierte en otra rama y otra flecha de vuelta, hasta que el diagrama tiene doscientas cajas, nadie se atreve a tocarlo y la lógica real vive en el tratamiento de excepciones.
Sin diagrama. Sin puntero. Nada que rebobinar.
Una tarea declara solo qué lee y qué produce. Nada declara qué se ejecuta a continuación.
No hay un puntero de posición en el caso ni transiciones entre tareas. En su lugar hay un expediente, todo lo que se sabe del caso hasta ahora, y un conjunto de tareas que lo observan. Una tarea se ejecuta cuando sus entradas están en el expediente y su propia salida falta o está desactualizada. Nunca porque algo anterior la haya llamado.
El orden se deriva de los datos. Nadie lo escribe. Todas las ventajas de este diseño salen de esa única decisión.
Un caso de alta de empresa, día a día
| Cuándo | Qué ocurre |
|---|---|
| Día 1 | Una empresa solicita. El expediente tiene la solicitud y el número de registro. Una consulta al registro se ejecuta, nada se lo ordenó, simplemente llegó su entrada, y produce la ficha de la empresa y tres titulares reales. |
| Día 1, instantes después | Tres cribados de sanciones se ejecutan en paralelo, uno por titular, porque ahora existen esos registros. Una tarea de IA lee los estatutos aportados y extrae los porcentajes de propiedad. |
| Día 1, todavía | Una tarea de lógica de decisión evalúa las reglas de riesgo contra todo lo reunido y concluye: derivar a una persona. Aparece una tarea de revisión en la cola correcta, enrutada por rol y no por nombre. |
| Día 9 | El cliente sube un registro de accionistas corregido. Uno de los titulares reales era incorrecto. |
Y aquí está toda la diferencia
En un motor de workflow el caso está parado en la casilla siete del diagrama. El documento corregido no rebobina nada. O alguien se da cuenta manualmente de que el cribado del día uno se hizo contra una persona que nunca fue titular real, o no se da cuenta nadie y el caso se aprueba sobre evidencia que lleva una semana siendo inválida.
Aquí, el documento corregido llega al expediente y todo lo que leyó los datos antiguos del titular queda desactualizado automáticamente. La IA vuelve a extraer. El cribado se repite con el nuevo titular. Las reglas de riesgo se reevalúan. La revisión humana se reabre con la evidencia cambiada marcada. Nadie escribió "si llega un registro corregido, vuelve atrás y repite el cribado". Nadie habría podido. Ocurre porque la respuesta dependía de la entrada, y la entrada cambió.
Seis tipos de tarea, un expediente
No son sistemas separados unidos con integraciones. Son tipos de tarea sobre el mismo expediente, y por eso componen.
Revisión humana
Leer lo que ha llegado, valorar qué significa o aportar lo que falta en un formulario construido con exactamense lo que al caso le sigue faltando. El trabajo se enruta por rol, así que un caso nunca queda esperando a una persona concreta.
IA
Un modelo de lenguaje lee, extrae, clasifica, resume o redacta, ejecutando una configuración de IA gobernada y versionada en lugar de un prompt improvisado.
OCR de documentos
Los documentos se convierten en registros estructurados en el expediente.
Lógica de decisión
Un conjunto de reglas, una tabla de decisión, un scorecard o un flujo de decisión completo: los mismos artefactos versionados y probados que usan las decisiones en tiempo real.
Datos externos
Burós, registros mercantiles, listas de sanciones, proveedores KYC, cualquier API REST.
Memo
Valores derivados y cálculos.
Tres cosas que se siguen de no lener orden fijo
- Colaboran en ambos sentidos. La respuesta de una persona puede disparar una tarea de IA, una extracción de IA puede disparar una evaluación de reglas, y la respuesta de un buró que llega el día cuatro puede reabrir una revisión humana completada el día dos. En un motor de workflow, ir hacia atrás es un camino de excepción que alguien tuvo que dibujar. Aquí es el mecanismo normal.
- La IA y las reglas son artefactos gobernados. Cuando una tarea llama a un modelo de lenguaje o evalúa un scorecard, ejecuta una entidad real de la plataforma: versionada, testable, revisable, publicable y compartida con sus decisiones en tiempo real. El prompt no se escribe en una caja de texto de la tarea. Su trabajo por casos y sus decisiones instantáneas no pueden decir cosas distintas sobre la misma política.
- Nada bloquea. Una llamada externa lenta y una persona tienen la misma forma para el motor: ambas escriben un hecho pendiente en el expediente y el caso sigue haciendo todo lo demás que puede. Cuando llega la respuesta, de una persona o de una API, se despierta lo que dependía de ella. Ningún hilo espera y ningún caso se atasca porque una consulta sea lenta.
Como el orden se deriva, el sistema sabe por qué ocurrió cada cosa
La auditabilidad aquí no es una función de logging añadida después. Sale de la arquitectura.
- Cada hecho sabe de dónde vino: qué tarea lo produjo, cuándo y en qué ejecución. No hay estado anónimo en un caso.
- Cada ejecución de tarea se puede justificar. No solo que se ejecutó, sino por qué: qué evidencia cambió y dejó su respuesta anterior desactualizada.
- El rastro completo de actividad, en el orden en que ocurrieron las cosas, incluidas las reejecuciones. Una conclusión alcanzada, invalidada por nueva evidencia y vuelta a alcanzar se ve exactamente así, en lugar de sobrescribirse en silencio.
- Cada tarea automatizada lleva su propia traza. Una tarea de lógica de decisión trae la explicación regla a regla y predictor a predictor del motor de decisiones. Abra el caso, abra la tarea y mire qué regla se activó sobre qué valor.
- La versión exacta del diseño que se ejecutó. Los diseños de caso se compilan en releases inmutables. Un caso de marzo se ejecutó contra el release de marzo, y ese release sigue ahí y sigue siendo legible.
Construido como software, por gente que no escribe software
En otros sitios los procesos de casos se configuran en caliente, a mano, sin historial de versiones y sin forma de probar un cambio salvo dejarlo correr sobre clientes reales.
- Construido con ayuda de IA. Describa el proceso, o apunte el asistente al procedimiento escrito, y revisa lo que propone cambio a cambio contra un diff visible antes de que se guarde nada.
- Análisis de impacto antes de tocar nada. Elija cualquier entrada, un atributo de registro o una clave de datos externos, y la plataforma le dice qué tareas se reejecutarían y si se reabrirían casos abiertos. Lo calcula con la misma extracción de dependencias que usa el runtime, así que la respuesta no puede desviarse de la realidad. Un diagrama no puede responder a esto, porque allí las dependencias están implícitas en el dibujo.
- Prueba con escenarios reales en un sandbox. Pasa un caso entero por el diseño y observa cada tarea dispararse y cada evidencia acumularse, antes de publicar.
- Versionado y publicado. Historial completo del diseño y de cada tarea, tests de regresión capturados de ejecuciones reales y releases inmutables con trazabilidad y comparación entre versiones.
Pensado para
Alta y KYB · suscripción comercial y compleja · gestión de siniestros · revisión de alertas AML · investigación de fraude · disputas y reclamaciones · reestructuración de crédito.
Preguntas que nos hacen
Llega evidencia nueva que invalida una conclusión a la que el caso ya había llegado. ¿Qué pasa?
Todo lo que dependía de la evidencia antigua queda desactualizado automáticamente y se reejecuta. Es la pregunta que merece la pena hacerle a cualquier proveedor que evalúes. En otros sitios la respuesta pasa por que alguien se dé cuenta.
¿En qué se diferencia de una suite BPM?
Una suite BPM te pide dibujar el proceso por adelantado. Nosotros preguntamos qué necesita y qué produce cada tarea, y derivamos el resto. Sus caminos de excepción son nuestra operación normal.
¿No basta con una cola y un campo de estado?
Eso es lo que da un módulo de casos dentro de un CRM. Funciona hasta que la evidencia del día uno resulta ser errónea el día nueve, momento en el que nada le dice qué ha dejado de ser fiable.
¿Las reglas de aquí son distintas de las de nuestras decisiones en tiempo real?
No, y esa es la idea. Una tarea de lógica de decisión ejecuta el mismo conjunto de reglas o scorecard versionado que usan sus decisiones instantáneas, así que ambas no pueden decir cosas distintas sobre la misma política.
¿Podemos probar un cambio en un diseño de caso antes de publicarlo?
Sí. Pase casos completos por el diseño en un sandbox, captura tests de regresión de ejecuciones reales y usa el análisis de impacto para ver qué tareas se reejecutarían y qué casos abiertos se reabrirían antes de publicar.
¿Dónde viven los datos del caso?
El expediente entero se queda de su lado, en una base de datos Postgres suya. La ejecución puede correr en su propio entorno y los documentos se quedan en almacenamiento que usted controlas, con credenciales en un vault que usted tiene. Los datos de ejecución llegan al endpoint para poder decidir sobre ellos, y no se conservan allí.
Decisiones que responden en milisegundos
Cuando una decisión se puede tomar en una sola petición, debería tomarse así. Los mismos conjuntos de reglas y scorecards se ejecutan también allí.