# Reglas de decisión y umbrales

Source: https://help.didit.me/es/workflows/decision-rules
Updated: 2026-10-12

Cada comprobación produce avisos, y tú decides qué hace cada aviso - pasar, revisar o rechazar. Ese mapeo es donde vive de verdad tu apetito de riesgo.

Cada paso mapea sus **avisos** a una acción: pasar, revisar o rechazar. Un paso
configurado para rechazar **detiene el flujo de trabajo**: los pasos posteriores
nunca se ejecutan, y no se te factura por ellos. Eso hace que el orden de las
reglas sea a la vez una decisión de riesgo y una decisión de coste.

[Video: Flujos condicionales: dirige a los usuarios según la puntuación de riesgo AML - Didit Academy](https://www.youtube.com/watch?v=Qp3qzFDvTC8&t=91)

## Dónde se toman de verdad las decisiones

Es tentador pensar en un flujo de trabajo como "las comprobaciones que ejecuto". Las comprobaciones son solo la mitad. La otra mitad, y la mitad que determina tu tasa de aprobación, es lo que están configurados para hacer los **avisos** de cada comprobación.

![El creador de flujos de trabajo de Didit con nodos de función y el botón Publish](https://help.didit.me/screenshots/workflow-builder-light.webp)

*Cada nodo decide su propio desenlace; el flujo de trabajo decide qué significa eso.*

Para cada paso, cada aviso que pueda generar se mapea a una de tres acciones:

| Acción | Efecto |
|---|---|
| **Aprobar** (o ignorar) | El aviso queda registrado pero no cambia el resultado |
| **Revisar** | La sesión pasa a En revisión para que una persona decida |
| **Rechazar** | La sesión se rechaza y el flujo de trabajo se detiene |

Ese mapeo es tu política, expresada como configuración.

## Un rechazo detiene el flujo de trabajo

Este es el comportamiento que más sorprende a la gente, así que merece la pena decirlo explícitamente: cuando un paso rechaza, la ejecución se detiene ahí. Los pasos posteriores **nunca se ejecutan**.

Dos consecuencias:

1. **Al resultado le faltarán comprobaciones que esperabas.** No fallaron, nunca se ejecutaron. Una sesión rechazada en la verificación de ID no tendrá prueba de vida, ni coincidencia facial, ni AML.
2. **No se te factura por ellas.** La facturación es por función completada, así que un paso que nunca se ejecutó no cuesta nada.

## Usar el orden de las reglas para controlar el coste

Como un rechazo detiene el flujo, el orden de los pasos es una palanca de gasto. Poner una comprobación de riesgo barata delante de un paquete caro hace que el tráfico que de todas formas nunca iba a pasar se detenga antes de que pagues por la parte cara.

El análisis de dispositivo e IP a 0,03 $ delante de un flujo de KYC completo es el ejemplo estándar: filtra el tráfico que rechazarías de todas formas, de forma barata.

> **Warning:** La contrapartida es la experiencia de usuario y los falsos positivos. Las señales
> de dispositivo e IP son las comprobaciones más ruidosas que ofrece Didit: las
> redes corporativas, el NAT de los operadores móviles y los navegadores en la nube
> ponen a usuarios genuinos detrás de direcciones compartidas. Condicionar todo un
> flujo a ellas bloqueará a clientes reales, así que envíalos a **review** en lugar
> de rechazar a menos que hayas medido tu propio tráfico.

## Reglas que necesitan criterio, no automatización

Algunos avisos son inequívocos y deberían rechazar: un checksum de MRZ fallido, un chip cuya firma no encadena con su emisor, una cara en tu lista de bloqueo. Esos son fallos de integridad.

Otros casi siempre son mejores como revisión:

- Coincidencias parciales de dirección en el comprobante de domicilio: los formatos varían según el país.
- Coincidencias parciales de nombre en la validación de base de datos: las fuentes autorizadas registran los nombres de forma distinta.
- Coincidencias candidatas de AML de baja confianza: los nombres comunes las generan constantemente.
- Una coincidencia facial límite: consulta [puntuaciones y umbrales de coincidencia facial](https://help.didit.me/es/liveness-biometrics/face-match-thresholds).
- Un aviso de cara duplicada: que es fraude para una cuenta nueva y normal para un cliente recurrente.

Y algunos son fallos de usabilidad que merecen un **reintento**, no un veredicto: un chip NFC no leído, una captura borrosa, un fotograma de cámara perdido.

## Políticas de edad

La edad mínima y máxima se configuran por flujo de trabajo, y la acción ante una infracción la eliges tú. `MINIMUM_AGE_NOT_MET` puede rechazar directamente, o dirigirse a revisión si tu política permite una excepción con evidencia. Ambas son legítimas; elige de forma deliberada.

## Reglas personalizadas sobre datos extraídos

Más allá del mapeo por aviso, puedes escribir reglas contra los datos que extrajo un paso; por ejemplo, rechazar cuando un campo extraído toma un valor concreto. Dos cosas a tener en cuenta:

- La regla solo puede actuar sobre datos que el paso realmente produjo. Si el OCR no extrajo el campo, la regla no tiene nada que evaluar.
- Una regla que rechaza sigue deteniendo el flujo de trabajo, con las mismas consecuencias que arriba.

Si estás construyendo una regla que se activa sobre una característica protegida, trátala como una cuestión legal para tu equipo de cumplimiento antes que como una cuestión de ingeniería.

## Prueba las reglas, no solo los pasos

Los pasos de un flujo de trabajo son fáciles de verificar a simple vista. Sus reglas no lo son: la única forma de saber que un aviso se dirige a donde crees es producir ese aviso.

Sandbox existe para esto. Cada escenario fuerza un aviso concreto, así que puedes confirmar la acción de cada regla de principio a fin: `decline_document_expired`, `review_face_match_borderline`, `decline_aml_hit`, `review_poa_partial_match`, y así sucesivamente. Consulta [probar en sandbox](https://help.didit.me/es/getting-started/sandbox-and-testing).

> **Tip:** Prueba la ruta de **revisión** con tanto cuidado como la ruta de rechazo. Una regla
> que dirige a revisión solo es útil si alguien realmente trabaja la cola, y la
> forma de saber si tu proceso de revisión funciona es hacer pasar una sesión
> sintética por él antes de que un cliente real esté esperando.

## Los cambios se aplican a las sesiones nuevas

Editar un flujo de trabajo no cambia retroactivamente las sesiones ya creadas. Una sesión lleva la configuración con la que se creó, así que después de un cambio de regla, prueba con una sesión **nueva** en lugar de volver a comprobar una antigua.