Gobernanza antes del ranking: un patrón de arquitectura para personalización empresarial

Un patrón de arquitectura para personalización empresarial sostiene que la gobernanza debe modificar el ranking antes de que la recomendación llegue al cliente, en lugar de evaluarse después o quedar solo anotada en logs y paneles. La propuesta viene con una implementación de referencia en código abierto montada sobre FastAPI, con políticas externalizadas en YAML, puntuación modular, memoria de viaje con estado y escalado opcional a un LLM.

El punto de partida es una pregunta que, según el texto, la mayoría de las API de personalización no sabe responder: por qué se entregó esa recomendación a ese cliente, por ese canal, con esa intensidad y en ese momento. El motor sabe qué es relevante; no sabe si es apropiado. En muchos despliegues, el consentimiento, la fatiga de ofertas, la sensibilidad del canal, el coste de la inferencia y la explicabilidad se evalúan una vez ordenados los candidatos, o directamente se vuelcan a un cuadro de mando.

Acciones de confianza sobre la puntuación

Aquí la gobernanza se considera real solo cuando cambia la puntuación del candidato. El patrón define cinco acciones que la política puede aplicar sobre la recomendación: mostrarla, suavizarla, retrasarla, suprimirla o sustituirla por un genérico. Todas operan antes de la entrega, no como un sidecar analítico posterior.

La memoria de sesión y entre sesiones permite que la misma oferta se comporte distinto según avance el recorrido del cliente y evolucionen su nivel de confianza y su fatiga. Los niveles de inferencia son explícitos y los selecciona la política, de forma que un modelo pequeño, uno de ML clásico y un LLM opcional se pueden probar y operar por separado. Eso da una vía de escape cuando el proveedor preferido no está disponible sin tocar el resto del pipeline.

La explicabilidad forma parte del contrato de la API. Cada respuesta identifica el nivel seleccionado, las reglas que se activaron, la acción de confianza aplicada, el desglose de la puntuación y el origen de la explicación. Con eso, la traza deja de estar repartida entre CRM, prompts y dashboards.

El diseño se presenta como independiente del dominio, aunque la implementación de referencia use un escenario de alquiler de coches. El texto lo sitúa como aplicable a comercio minorista, servicios financieros, telecomunicaciones, seguros y comercio digital, y dice que el patrón nace de programas de personalización a gran escala en viajes y sanidad. El repositorio incluye el código de los manejadores de recomendación, y hay una demo del escenario publicada en línea.

Lo interesante para quien opera esto no es el modelo, sino dónde vive la decisión. Si las condiciones de confianza se resuelven después del ranking, cualquier cambio de política obliga a tocar código de aplicación y la auditoría se convierte en arqueología de logs. Moverlas a políticas seleccionadas por el orquestador deja el pipeline inspeccionable y permite degradar a un nivel de inferencia más barato cuando la política lo autorice.

Lo que el material no trae es ningún dato de rendimiento: ni latencias, ni comparativa con pipelines convencionales, ni cifras de coste. Tampoco hay métricas de adopción del repositorio. La propuesta es un patrón con código, no un producto con resultados medidos.