El problema fundamental que esta arquitectura aborda es la incapacidad de los sistemas de personalización tradicionales para responder a la pregunta "¿Por qué se entregó esta recomendación a este cliente, a través de este canal, con esta intensidad, en este momento?". Las arquitecturas existentes se centran en la relevancia del modelo, pero fallan en integrar la gobernanza, el consentimiento, la fatiga del cliente y la sensibilidad del canal en el camino crítico de la decisión. Esto conduce a riesgos operacionales, de cumplimiento, de coste y de confianza.

La tesis central es que la gobernanza debe influir en el ranking antes de que se entregue una experiencia, no después. Esto transforma la personalización de una simple salida de modelo a una decisión trazable, consciente del contexto y operacionalmente defendible. La necesidad de esta arquitectura surge de la creciente complejidad de los entornos empresariales, donde múltiples modelos de IA, regulaciones estrictas y la expectativa de transparencia del cliente exigen un enfoque más estructurado y auditable para las decisiones de personalización.

Arquitectura del Sistema

La arquitectura propuesta es un pipeline de decisión gobernado que descompone el proceso de recomendación en seis componentes independientes: Experience Memory Layer (EML), Temporal Knowledge Graph Engine (TKGE), Hybrid AI Orchestration Engine (HAOE), Experience DNA Score (EDS), Trust-Aware Personalization Layer (TAPL) y Outcome Simulation Engine (OSE). Cada componente tiene una responsabilidad clara y produce una salida inspeccionable que puede influir en el ranking final.

El flujo de una solicitud comienza con el enriquecimiento del contexto, donde EML recupera el estado de sesión cruzada (confianza, fatiga, preferencias) de un almacén SQLite, y TKGE construye un grafo temporal ponderado por la actualidad a partir de eventos de sesión. HAOE selecciona dinámicamente el nivel de inferencia más simple y fiable (Reglas, SLM, ML o LLM) basándose en políticas externas en YAML, confianza, ambigüedad y presupuesto de coste. Luego, en el bucle de puntuación, EDS calcula la relevancia, TAPL aplica la gobernanza de confianza (consentimiento, fatiga, canal) mediante un motor de políticas externo, y OSE estima los resultados potenciales. Finalmente, un ranker híbrido ajusta el orden de los candidatos combinando señales de relevancia, gobernanza y resultados simulados. La persistencia del estado actualiza EML y TKGE con el historial de recomendaciones y la retroalimentación del cliente. La arquitectura utiliza FastAPI para las APIs, SQLite para la persistencia de estado y archivos YAML para la configuración de políticas, permitiendo la evolución independiente de modelos y políticas.

Pipeline de Decisión Gobernado

  1. 1 Solicitud Cliente POST /recommend o POST /recommend-from-scenario
  2. 2 Enriquecimiento Contexto EML recupera memoria cross-session; TKGE construye grafo temporal; HAOE selec...
  3. 3 Scoring EDS Calcula relevancia del candidato (intención, engagement, valor negocio, etc.).
  4. 4 Gobernanza TAPL Aplica políticas de confianza (consentimiento, fatiga, canal) y acciones (sho...
  5. 5 Simulación OSE Estima impacto en conversión, ingresos, confianza, cumplimiento.
  6. 6 Ranking Híbrido Combina relevancia, gobernanza y simulación para el orden final.
  7. 7 Persistencia Estado EML.record_recommendations(), EML.record_feedback(), TKGE.save_snapshot().
  8. 8 Respuesta Explicable Retorna recomendaciones con tier, reglas, acción de confianza, desglose de sc...
CapaTecnologíaJustificación
orchestration FastAPI Framework para la implementación de la API REST y el manejo de solicitudes.
storage SQLite Almacén de datos para mantener el estado de sesión cruzada (confianza, fatiga, preferencias, historial).
orchestration YAML Formato para externalizar políticas de gobernanza, enrutamiento de inferencia y configuraciones, permitiendo auditoría y evolución sin cambios de código. vs JSON, TOML
compute Rules Engine Tier de inferencia para escenarios estructurados y de alta confianza, ofreciendo determinismo y bajo coste.
compute SLM (Small Language Models) Tier de inferencia para patrones locales repetibles y tareas de lenguaje restringidas, con latencia predecible. vs Modelos ML más grandes
compute Classical ML Models Tier de inferencia para modelos de intención, viaje, resultado y ranking, con coste moderado y buena testabilidad. vs LLMs para todas las tareas
compute LLM (Large Language Models) Tier de inferencia opcional para resolución de ambigüedad y explicación en lenguaje natural, con mayor flexibilidad pero también mayor coste y latencia. vs Reglas o ML para todas las tareas

Trade-offs

Ganancias
  • ▲ Control y auditabilidad de decisiones
  • ▲ Resiliencia a fallos de modelos/servicios
  • ▲ Explicabilidad de las recomendaciones
  • ▲ Adaptabilidad a cambios de políticas y regulaciones
  • ▲ Gestión de costes de inferencia
Costes
  • ▲ Complejidad arquitectónica y de mantenimiento
  • ▲ Coste inicial de implementación y configuración
# Condensed from HAOEOrchestrator.decide(...)
if forced_mode in PUBLIC_INFERENCE_TIERS:
    return decision(forced_mode, "forced for benchmark or control")
if scenario_rules_ready(context) and combined_rules >= rules_min:
    return decision("rules", "structured context met confidence threshold")
if high_ambiguity and llm_is_healthy and budget_allows_llm:
    return decision("llm", "ambiguity justifies teacher reasoning")
if high_ambiguity and not budget_allows_llm:
    return decision("ml", "LLM budget would be exceeded")
if llm_circuit_open:
    return decision("ml", "provider circuit is open")
if slm_allowed:
    return decision("slm", "distilled pattern or deployed local SLM")
return decision("ml" if use_ai_models else "rules", "bounded fallback")
Extracto condensado de la lógica de orquestación (HAOE) que muestra el orden de decisión para seleccionar el tier de inferencia (rules, SLM, ML, LLM) basado en políticas, confianza y presupuesto.

Fundamentos Teóricos

La necesidad de una gobernanza explícita y trazable en sistemas distribuidos, especialmente aquellos que toman decisiones automatizadas, resuena con principios de sistemas confiables y explicables (XAI). Aunque el artículo no cita directamente un paper específico, la separación de preocupaciones y la modularidad del diseño se alinean con los principios de diseño de sistemas distribuidos robustos, como los discutidos en trabajos sobre microservicios y arquitecturas orientadas a servicios. La gestión del estado de sesión y entre sesiones, y la construcción de un grafo temporal, tienen paralelismos con la investigación en bases de datos temporales y sistemas de gestión de contexto, donde la validez y el significado de los datos dependen del tiempo y la secuencia de eventos. La idea de que la confianza debe cambiar el rango, y no solo anotarlo, se relaciona con el concepto de "accountability" en sistemas de IA, donde las decisiones deben ser defendibles y auditables, un tema central en la ética de la IA y la regulación de algoritmos.