¿Qué es un sistema basado en reglas?
Un sistema basado en reglas (RBS, por sus siglas en inglés) toma decisiones aplicando reglas predefinidas a las entradas. Normalmente, las reglas toman condiciones (por ejemplo, “si ocurre X”) y las asignan a salidas (por ejemplo, “entonces haz Y”). La idea clave es que la lógica de decisión es explícita y determinista, no aprendida automáticamente de los resultados.
En la práctica, el comportamiento del sistema depende de tres categorías de supuestos: (1) las entradas son correctas y oportunas, (2) las reglas son lógicamente completas para las situaciones que enfrentas, y (3) la asignación de las salidas a las acciones del mundo real se ejecuta según lo previsto.
¿Cómo se manifiestan los principales riesgos?
Riesgos operativos y de ejecución
Incluso si las reglas están bien escritas, la ejecución real puede desviarse de lo que el sistema espera. Los ejemplos incluyen datos retrasados o faltantes, diferencias entre los datos utilizados para las decisiones y los datos utilizados posteriormente para la presentación de informes, y fricciones de ejecución como costos, ejecuciones parciales o deslizamiento (slippage). Otro modo de fallo común son las “condiciones límite”: cuando las entradas están fuera del rango supuesto (formatos inesperados, picos repentinos, flujos de datos detenidos), la regla puede producir un resultado que el diseñador no pretendía.
Un riesgo relacionado es que los componentes operativos pueden fallar de maneras que las reglas no manejan. Por ejemplo, si el sistema no puede alcanzar su entorno de ejecución o no puede confirmar los resultados, puede seguir actuando sobre información obsoleta o dejar de responder.
Riesgos de mercado y de condiciones
Las reglas a menudo se calibran en torno a observaciones pasadas o patrones estables. Cuando el comportamiento del mercado cambia—como cambios en los regímenes de volatilidad, ruptura de correlaciones o debilitamiento de las condiciones de liquidez—las reglas pueden volverse menos representativas de las condiciones actuales. Debido a que un RBS normalmente no se “adapta” automáticamente, puede seguir aplicando la misma lógica incluso cuando sus supuestos subyacentes ya no coinciden con la realidad.
Una forma práctica de pensar en esto es: un RBS es tan robusto como el rango de condiciones cubiertas por sus reglas. Si el sistema no está diseñado explícitamente para escenarios anormales, puede comportarse de manera consistente pero incorrecta.
Riesgos de contraparte y del entorno
Las salidas de las reglas generalmente necesitan una parte externa o un servicio para llevar a cabo las acciones. Eso introduce riesgos de contraparte y del entorno: el proceso que recibe la solicitud podría comportarse de manera diferente a lo que el sistema supone, la disponibilidad de cotizaciones podría cambiar o la conectividad podría degradarse. Incluso sin hablar de ningún proveedor específico, el riesgo general permanece: la “decisión” no es lo mismo que el “resultado”.
Si los acuses de recibo o las confirmaciones se retrasan, se duplican o faltan, el estado interno del sistema puede desincronizarse. Eso puede llevar a repeticiones no intencionadas (hacer la misma acción más de una vez) o a acciones omitidas (creer que una acción ocurrió cuando no fue así).
Limitaciones materiales y cómo verificarlas
Riesgos de interpretación y mantenimiento
Las reglas generalmente son creadas y posteriormente actualizadas por humanos. El riesgo puede entrar a través de definiciones de reglas ambiguas, cobertura incompleta de casos límite o cambios en cómo se representan las entradas. Con el tiempo, los problemas de mantenimiento pueden acumularse: una regla podría seguir siendo lógicamente correcta, pero puede depender de un campo de entrada cuyo significado cambió, o puede que ya no encaje en la lógica más amplia del sistema.
Verificación que puede realizar de forma independiente
Para evaluar el riesgo de forma independiente, verifique el sistema a lo largo de cuatro ejes: (1) validación de entradas—qué sucede cuando las entradas faltan, se retrasan o están fuera de los rangos esperados; (2) cobertura de reglas—si todos los escenarios relevantes se asignan a comportamientos seguros e intencionados; (3) modelado de costos y ejecución—si la ruta de decisión del sistema tiene en cuenta la fricción como los costos de transacción y los resultados parciales; y (4) consistencia del estado—si el sistema puede recuperarse de respuestas externas fallidas o duplicadas.
Siguiente pregunta a plantear
Si está evaluando un RBS, la pregunta de seguimiento más útil no es “¿Funcionará?” sino “¿Qué supuestos requiere para un comportamiento correcto y con qué frecuencia se violan esos supuestos en condiciones realistas?” Dado que los resultados varían según las condiciones y las limitaciones operativas, centre la verificación en el fallo de los supuestos, no en el éxito pasado.