Cuando comencé a diseñar el motor de decisiones para el “Proyecto Fénix”, mi tarea parecía puramente técnica. El objetivo era automatizar el proceso de aprobación de solicitudes académicas, un trabajo que hasta entonces dependía de revisiones manuales, papeleo y, seamos honestos, la subjetividad del evaluador de turno. Pensé en términos de servicios, entidades y endpoints. Sin embargo, muy pronto me di cuenta de que mi verdadero desafío no era escribir código, sino codificar la burocracia. Y más importante aún, hacerlo con empatía.
El Espejismo de la Lógica Pura
La primera tentación en un proyecto así es la simplificación extrema. Crear un par de reglas sencillas: si el promedio del estudiante es mayor a 8.5, se aprueba; si es menor, se rechaza. Si no tiene adeudos, procede; si los tiene, se detiene. Sería rápido de implementar y técnicamente funcional.
Pero también sería fundamentalmente injusto.
Un sistema así no distingue entre un estudiante de primer semestre que lucha por adaptarse y uno de último semestre con un historial impecable. No comprende que un “conflicto de horario” es un fallo del sistema que no debería penalizar al usuario, mientras que un “problema de salud” es una situación delicada que ninguna máquina debería juzgar de forma automática.
Me di cuenta de que no estaba construyendo un simple validador. Estaba diseñando un proxy digital de un ser humano que toma decisiones. Y para que fuera justo, ese proxy necesitaba entender el contexto.
Las Capas de una Decisión Justa
Decidí estructurar el motor de evaluación no como una lista de condiciones, sino como una serie de filtros o capas concéntricas, cada una con un propósito específico, imitando cómo una persona razonable analizaría un caso.
La Primera Puerta: Elegibilidad
Esta fue la capa más externa y sencilla. Eran las reglas binarias, el “sí” o “no” rotundo. ¿Está abierto el periodo de solicitudes? ¿El usuario ha excedido su límite de peticiones? Este filtro era el guardia de seguridad a la entrada: su trabajo no era juzgar, sino verificar credenciales. Si no las cumples, no puedes pasar. Simple y eficiente.
El Filtro Crítico: Viabilidad
Una vez dentro, la solicitud se enfrentaba a las condiciones no negociables. ¿El estatus académico del estudiante es “activo”? ¿Tiene algún bloqueo administrativo grave? Estas eran las banderas rojas. Un “no” aquí significaba un rechazo casi inmediato. El sistema tenía que ser capaz de identificar los casos que, bajo las normativas existentes, eran inviables desde el principio.
El Corazón del Sistema: El Contexto
Aquí es donde residía la verdadera inteligencia del sistema. En lugar de tratar todos los motivos de solicitud por igual, creé una lógica específica para cada uno.
- Un Conflicto de Horario casi siempre se aprobaba. Era un problema logístico que el sistema debía facilitar, no juzgar.
- Una Situación Laboral se evaluaba con una variable clave: el semestre. Para un estudiante avanzado, compaginar trabajo y estudio es una realidad común y esperada. Para uno de los primeros semestres, podría ser una señal de alerta que merecía una revisión más detallada. El algoritmo tenía que reflejar esa madurez.
- Un Problema de Salud, por otro lado, era un límite claro para la automatización. La decisión aquí era no tomar una decisión. La solicitud se marcaba automáticamente para revisión humana. La empatía del algoritmo consistía en reconocer su propia incompetencia para juzgar una situación humana tan compleja.
La Tercera Vía: El Arte de Decir “No Sé”
Quizás la decisión de diseño más importante fue la creación de un tercer estado más allá de “Aprobada” y “Rechazada”: el estado de “Pendiente de Revisión”.
Este se convirtió en la válvula de escape del sistema, su red de seguridad. Era la forma que tenía el algoritmo de levantar la mano y decir: “He procesado toda la información que tengo, pero este caso se sale de los patrones claros. Necesito un humano”.
Los casos con promedios en el límite, los motivos ambiguos, o las combinaciones de factores que no llevaban a una conclusión clara caían en esta categoría. Esto liberaba al personal administrativo del 80% de los casos rutinarios y predecibles, permitiéndoles enfocar toda su atención y juicio en el 20% de las solicitudes que realmente lo necesitaban.
Al final, el motor de decisiones del Proyecto Fénix no fue solo una pieza de software. Fue mi intento de traducir un proceso administrativo a un flujo lógico que fuera eficiente sin ser insensible. La meta nunca fue reemplazar el juicio humano, sino potenciarlo, filtrando el ruido para que las personas pudieran dedicarse a las decisiones que de verdad importan. Y en ese proceso, aprendí que el mejor código no es solo el que funciona, sino el que recuerda para quién funciona.