Cuando empecé a diseñar el motor de decisiones del “Proyecto Fénix”, un sistema para gestionar solicitudes académicas, la tarea parecía puramente técnica: automatizar la aprobación de solicitudes, algo que hasta entonces dependía de revisiones manuales, papeleo y del criterio del evaluador de turno. Yo pensaba en servicios, entidades y endpoints. El problema de fondo resultó ser otro: cómo convertir un trámite que evaluaban personas en reglas que un sistema pueda aplicar sin ser injusto.
Por qué no bastaban dos reglas
La primera tentación era resolverlo con un par de condiciones: si el promedio pasa de 8.5, se aprueba; si no, se rechaza. Si no hay adeudos, procede; si los hay, se detiene. Rápido de implementar y técnicamente funcional.
También sería injusto. Un sistema así no distingue entre un estudiante de primer semestre que apenas se está adaptando y uno de último semestre con buen historial. No entiende que un “conflicto de horario” es una falla del propio sistema de horarios y no debería penalizar a nadie, mientras que un “problema de salud” es un caso que ninguna máquina debería juzgar en automático.
No estaba construyendo un simple validador: estaba reemplazando el criterio de una persona con código. Y para que el resultado fuera justo, ese código necesitaba contexto.
Las capas de una decisión
Estructuré el motor de evaluación como una serie de filtros, cada uno con un propósito, siguiendo el orden en que una persona razonable revisaría un caso.
Elegibilidad
La capa más externa y sencilla: las reglas binarias. ¿Está abierto el periodo de solicitudes? ¿El usuario ya llegó a su límite de peticiones? Este filtro no juzga, solo verifica requisitos. Si no los cumples, no pasas.
Viabilidad
Ya adentro, la solicitud se enfrentaba a las condiciones no negociables. ¿El estatus académico del estudiante es “activo”? ¿Tiene algún bloqueo administrativo grave? Un “no” aquí significaba rechazo casi inmediato: son los casos que la normativa vuelve inviables desde el inicio.
Contexto
Aquí estaba la parte interesante. En lugar de tratar todos los motivos por igual, escribí lógica específica para cada uno:
- Un conflicto de horario casi siempre se aprobaba. Es un problema logístico que el sistema debía facilitar, no juzgar.
- Una situación laboral se evaluaba junto con el semestre. Para un estudiante avanzado, compaginar trabajo y estudio es normal; en los primeros semestres puede ser señal de que el caso merece una revisión más detallada.
- Un problema de salud marcaba el límite de la automatización: la decisión era no decidir. La solicitud pasaba directo a revisión humana.
El tercer estado: “Pendiente de revisión”
La decisión de diseño más importante fue agregar un estado más allá de “Aprobada” y “Rechazada”: “Pendiente de revisión”.
Era la válvula de escape del sistema. Los promedios en el límite, los motivos ambiguos y las combinaciones de factores sin conclusión clara caían ahí, con toda la información ya procesada y lista para que una persona la revisara. En la práctica, esto le quitaba al personal administrativo cerca del 80% de los casos rutinarios y predecibles, y les dejaba el tiempo para el 20% que de verdad necesitaba criterio humano.
Al final, el motor del Proyecto Fénix quedó en eso: un flujo lógico que resuelve lo predecible y aparta lo que no le toca decidir. La meta nunca fue reemplazar el juicio humano, sino filtrar el ruido para que se use donde hace falta.