Right to Explanation para LLMs

Descripción

GDPR Art. 22 requiere "meaningful information about the logic involved" en decisiones automatizadas. Para modelos clásicos (random forests, regresiones, simpler ML), explicar es manejable. Para LLMs es fundamentalmente más difícil.

Un LLM tiene billones de parámetros. Su "razonamiento" emerge de gradient descent sobre data masiva. No hay feature importances obvias, no hay decision tree path, no hay coeficientes lineales que mostrar.

Esta cápsula te da las estrategias prácticas para cumplir right to explanation con LLMs, siendo honesto sobre las limitaciones.

Al terminar vas a poder:

• Reconocer qué tipo de explanation es factible con LLMs
• Implementar logging y observability para reconstruir decisiones
• Diseñar human-in-the-loop como complement
• Comunicar al usuario explanations meaningful aunque imperfectas

El problema fundamental

Modelo clásico (Random Forest):
  Input → Feature extraction → Tree traversal → Decision
  Explanation: "Used these features with these importances"

LLM (RAG system):
  Input → Tokenize → Embed → Retrieve chunks → Prompt construction →
  → Transformer layers (hundreds of millions of parameters) →
  → Token-by-token generation → Output
  Explanation: ???

El LLM no tiene componentes separables que mostrés. Su "decisión" emerge holísticamente.

Estrategias de explanation para LLMs

Estrategia 1: Documentar el proceso (no el razonamiento interno)

No podés explicar por qué el LLM decidió X. Pero podés explicar el proceso que llegó a esa decisión:

Tu pregunta: "¿Puedo expandir mi cobertura a Brasil?"

Proceso:
1. Buscamos en nuestra knowledge base 4 documentos relevantes
2. Los documentos sugieren que la cobertura internacional está disponible
   para clientes con plan premium después de 12 meses
3. Tu plan actual: standard, antigüedad 6 meses
4. Decisión: no elegible actualmente

Documentos consultados:
- Política de cobertura internacional (2024)
- Requisitos para upgrades de plan
- Términos generales del servicio

¿Querés que un agente humano revise esto?

No explicaste el LLM — explicaste el proceso y los inputs. Eso es defensible bajo GDPR.

Estrategia 2: Logging exhaustivo

Para poder explicar después, registrás todo durante:

# Cuando processamos una query
log = {
    "session_id": session.id,
    "user_id": user.id,
    "timestamp": now(),
    "query": original_query,
    "retrieved_chunks": [
        {"id": c.id, "score": c.score, "source": c.source}
        for c in chunks
    ],
    "prompt_template_version": "v3.2",
    "full_prompt": prompt,
    "model_used": "gpt-4o-mini",
    "model_version": "2024-07-18",
    "model_parameters": {"temperature": 0.1, "max_tokens": 500},
    "raw_response": response,
    "extracted_decision": decision,
    "decision_confidence": confidence,
    "tools_called": [tool_calls],
}
db.log_interaction(log)

Cuando un usuario pide explanation 2 meses después, tenés trazabilidad completa.

Estrategia 3: Constrained outputs con reasoning fields

Estructurá la salida del LLM para incluir explicit reasoning:

prompt = """
Evalúa la solicitud del usuario y devolvé JSON con:
- "decision": "approve" | "reject" | "needs_review"
- "key_factors": lista de 3-5 factores que más afectaron la decisión
- "supporting_documents": IDs de documentos consultados que sustentan
- "confidence": 0.0-1.0
- "uncertainty_areas": qué fue ambiguous

Solicitud: {user_query}
Contexto: {retrieved_chunks}
"""

response = call_llm(prompt, response_format="json")
# response.key_factors es lo que mostramos al usuario

El LLM se auto-explica en su output. No es ground truth de su razonamiento interno, pero es defensible.

Estrategia 4: Decision templates pre-escritos

Para decisiones críticas y comunes, usás templates en lugar de free-form LLM generation:

# Para credit denial, usá template fixed
def credit_denial_explanation(scoring_result):
    primary_factor = identify_main_factor(scoring_result)
    return f"""
Tu solicitud no fue aprobada en este momento.

Factor principal: {primary_factor['name']}
- Tu valor: {primary_factor['user_value']}
- Threshold típico: {primary_factor['typical_threshold']}

Otros factores considerados:
{format_factors(scoring_result.factors)}

Podés mejorar tu perfil para próximas solicitudes:
{recommendations(scoring_result)}

[Solicitar revisión humana]
"""

Templates te dan consistencia y defensibility. El LLM puede ayudar a generar el explanation pero no es el único path.

Estrategia 5: Human-in-the-loop como complemento

Para decisiones críticas, un humano revisa y firma off:

1. LLM genera initial decision + draft explanation
2. Routed a human reviewer para significant decisions
3. Human aprueba/modifica/rechaza
4. Final explanation incluye: AI suggestion + human review notes
5. Logged como decisión "human-supervised"

Esto transforma decisión "solely automated" en "human-supervised", saliendo del scope estricto de Art. 22.

Lo que NO podés hacer

No inventar explanations

❌ Mal: "El sistema decidió X porque consideró Y" — pero el sistema no expuso Y.

Por qué es problema: cuando el regulador inspeccione y vea que tu explanation no matches con logging real, sancionará.

No usar attribution methods sin entender limitations

LIME, SHAP, attention visualization — herramientas que prometen explicar LLMs. Limitations significativas:

• Attention weights ≠ causal importance
• LIME local approximations son frágiles
• SHAP para LLMs es computacionalmente caro y aprox

Si los usás, documentá las limitaciones explícitamente.

No claim "interpretable AI" sin ser exacto

"Nuestro AI es completamente interpretable" → te demandan, tu LLM resulta complejo, daño reputacional.

Diseño de UX para explanations

Layers de información

Diferentes usuarios quieren diferentes niveles:

Nivel 1 (default): "Tu solicitud fue rechazada porque [main factor]."

Nivel 2 (click "more info"): 
"Otros factores considerados: [list]. Comparado con typical thresholds: [comparison]."

Nivel 3 (click "technical details"):
"Documentos consultados: [list with IDs]. Model version: X. 
Decision timestamp: Y. Confidence: Z."

Nivel 4 (admin/audit): full logs

Cada layer progresivamente más técnico. Usuario normal ve N1, lawyer/auditor accede N3-4.

Trampas comunes

Trampa 1 — Asumir que "tenés AI" → "tenés interpretability". Cars y planes funcionan; no podés explicar cada bolt. Aceptá la opacidad mientras documentás proceso.

Trampa 2 — Logging sin retention policy. Logueás todo, pero luego tu DB se llena. Define TTL: logs detallados 90 días, summary indefinido.

Trampa 3 — Templates rígidos que no cubren edge cases. "Si scoring < threshold" pero hay 50 razones distintas. Template debe ser dinámico o tener fallback general.

Trampa 4 — Human reviewer sin SLA. Usuario pide review humana, llega después de 60 días. Defendible legalmente quizá, pero terrible UX.

Trampa 5 — Privacy violations en explanations. Tu explanation incluye datos de otros users: "comparado con usuarios similares, X". Si filtra info personal, violación.

Ejercicio

Tu AI assistant rechaza una solicitud de upgrade de plan. Diseñá la explanation:

1. Nivel 1 (default, 2-3 frases)
2. Nivel 2 (more info)
3. Logging exhaustivo (qué guardás)
4. Procedure si usuario pide human review

{
    "request_id": uuid,
    "user_id": user.id,
    "timestamp": now,
    "request_type": "upgrade_plan",
    "input_data": {
        "current_plan": "Standard",
        "requested_plan": "Premium",
        "tenure_months": 6,
        "payment_status": "current",
        "usage_active": True,
    },
    "evaluation_rules_version": "v2.3",
    "decision": "reject",
    "key_factor": "insufficient_tenure",
    "all_factors": [...],
    "explanation_template_used": "tenure_insufficient_v1",
    "ai_assistance": False,  # rule-based, no LLM
    "next_eligible_date": "2026-XX-XX",
}

Resumen

Aprendiste:

• ✅ Por qué LLMs son fundamentalmente menos explicables
• ✅ 5 estrategias prácticas: proceso, logging, constrained outputs, templates, human-in-the-loop
• ✅ Lo que NO podés hacer (inventar, abuse attribution methods, overclaim)
• ✅ UX en layers (nivel 1-4)
• ✅ Trampas: logging without retention, templates rigid, privacy violations en explanations

Checkpoint: si podés diseñar explanation para un sistema LLM real cumpliendo Art. 22 sin inventar, estás listo.

Siguiente cápsula

04 — Data Minimization aplicada a AI. Otro principio GDPR con tensiones reales: ML quiere más datos, GDPR quiere mínimo. Vamos a resolver el conflicto.

Recursos

1. Edwards & Veale "Slave to the algorithm" — análisis right to explanation.
2. Wachter et al. "Counterfactual Explanations" — método de explanation.
3. GDPR Recital 71 — context para Art. 22.
4. Anthropic's Claude — Constitutional AI — example de design para explainability.