Evaluación sistémica y riesgo
De probador de prompts a evaluador de sistemas críticos. Aprende a identificar riesgos operativos y cognitivos a escala organizacional.
La diferencia del nivel Masterclass
En la Ruta 3, aprendiste a probar prompts individuales. Aquí, aprendes a evaluar sistemas completos — comportamientos emergentes, riesgos operativos, superficies de ataque a nivel arquitectónico y respuesta a incidentes. El prompt deja de ser solo texto y se convierte en superficie de riesgo.
Evaluación sistémica del comportamiento
Evaluación sistémica examina no solo si los prompts individuales funcionan, sino también si el sistema en su conjunto muestra los comportamientos deseados de forma consistente y predecible.
Dimensiones de evaluación sistémica
Consistencia
¿El sistema produce resultados similares para entradas similares? ¿La variación es aceptable?
Coherencia
¿Los outputs de distintas partes del sistema son compatibles entre sí?
Degradación gradual
¿Cómo se comporta el sistema en casos límite y condiciones de estrés?
Alineación
¿El comportamiento observado corresponde a la intención de diseño?
Métodos de evaluación a escala
- • Conjuntos de evaluación automatizados: suites de pruebas que se ejecutan continuamente
- • Red teaming: intentos deliberados de romper el sistema
- • Pruebas en paralelo: comparar el sistema nuevo con la versión de referencia en producción
- • Pruebas A/B de comportamiento: medir el impacto de los cambios en los prompts
Riesgo operativo y cognitivo
Los sistemas basados en prompts introducen categorías de riesgo que los sistemas tradicionales no tienen. Distinguimos entre riesgo operativo (fallas técnicas) y riesgo cognitivo (fallas de criterio del modelo).
Matriz de Riesgos
| Tipo | Ejemplos | Mitigación |
|---|---|---|
| Operativo | Límites de solicitudes, latencia, costos | Throttling, caching, budgets |
| Cognitivo | Alucinaciones, sesgo, inconsistencia | Fundamentación, validación, guardrails |
| Reputacional | Outputs ofensivos, errores públicos | Content filtering, human review |
| Compliance | Filtración de datos, discriminación | Enmascaramiento de datos, pruebas de sesgo |
Riesgos de alta severidad
- • Decisiones automatizadas irreversibles
- • Acceso a datos sensibles
- • Acciones financieras o legales
- • Comunicación externa automatizada
Riesgos de baja severidad
- • Sugerencias internas revisables
- • Análisis de datos agregados
- • Borradores con aprobación humana
- • Herramientas de productividad personal
Prompt injection a nivel arquitectónico
Prompt injection no es solo un ataque puntual: es una clase de vulnerabilidad que afecta a toda la arquitectura. El arquitecto debe pensar en las superficies de ataque a nivel sistémico.
Vectores de ataque arquitectónicos
Direct Injection
Input malicioso directamente en el prompt del usuario.
Indirect Injection
Carga útil oculta en datos que procesa el sistema (documentos, correos electrónicos, web).
Cross-Agent Injection
Un agente está comprometido e inyecta payloads en otros agentes a través de sus outputs.
Ataque de persistencia
Carga útil almacenada en la memoria/el historial que afecta sesiones futuras.
Defensas arquitectónicas
- • Privilege separation: distintos niveles de acceso para distintos prompts
- • Input sanitization: filtrar o escapar contenido antes de incluirlo en el prompt
- • Validación del output: verificar los outputs antes de ejecutar acciones
- • Context isolation: separar contextos de distintos usuarios/fuentes
- • Canary tokens: detectar cuándo se filtran instrucciones del sistema
⚠️ Realidad incómoda
No existe una defensa perfecta contra la inyección de prompts. Todas las mitigaciones reducen el riesgo, pero no lo eliminan. El arquitecto debe asumir que puede ocurrir una inyección y diseñar sistemas que limiten el daño posible (radio de impacto).
Auditoría de decisiones
Cuando un sistema basado en LLM toma decisiones o influye en ellas, es necesario poder auditar la cadena de razonamiento. Esto es esencial para el compliance, el debugging y la confianza.
Requisitos de auditabilidad
Para cada decisión, registra:
- • Entrada que activó la decisión
- • Prompt/contexto utilizado
- • Salida raw del modelo
- • Transformaciones aplicadas
- • Acción resultante
Metadatos esenciales:
- • Timestamp preciso
- • Versión del modelo
- • Versión del prompt/skill
- • ID de correlación
- • Usuario/sistema que inició
La auditoría no es solo sobre qué ocurrió, pero por qué. Los prompts de cadena de pensamiento facilitan la explicabilidad, pero también aumentan el costo y la latencia.
Niveles de registro de auditoría
| Mínimo | Input, output, timestamp: suficiente para la depuración básica |
| Estándar | + prompt completo, versiones, metadatos — para compliance |
| Completo | + chain-of-thought, alternativas consideradas — para investigaciones |
Observabilidad estratégica
Observabilidad en sistemas LLM va más allá de las métricas tradicionales. Es necesario monitorear el comportamiento semántico, no solo el rendimiento técnico.
Pilares de observabilidad de LLM
Métricas tradicionales
Latencia, throughput, tasa de errores, costo por solicitud
Métricas de calidad
Relevancia, integridad, precisión, correspondencia del tono
Métricas de comportamiento
Rechazos, tasa de alucinaciones, activadores de seguridad
Métricas de negocio
Tasa de finalización de tareas, satisfacción del usuario, tasa de escalamiento
Alertas estratégicas
Alertar de inmediato:
- • Infracciones de seguridad
- • Picos de costos anormales
- • Error rate > threshold
- • Posible filtración de datos
Monitorear tendencias:
- • Deriva de la calidad a lo largo del tiempo
- • Cambios en los patrones de uso
- • Degradación del rendimiento
- • Evolución de la distribución de inputs
Panel ejecutivo
El arquitecto debe diseñar dashboards en varios niveles: operativo (para SREs), de producto (para PMs) y ejecutivo (para el liderazgo). Cada nivel necesita métricas y distintos grados de detalle.
Incidentes y respuesta a fallas
Los sistemas LLM van a fallar. La pregunta no es si fallarán, sino cuándo y cómo respondes. Incident response para sistemas de prompts tiene características únicas que difieren de los sistemas tradicionales.
Categorías de incidentes de LLM
P1 - Crítico
Violación de seguridad, filtración de datos, sistema fuera de línea
P2 - Alto
Degradación grave de la calidad, costo fuera de control
P3 - Medio
Aumento de errores, quejas de usuarios o desviaciones de comportamiento
P4 - Bajo
Edge cases no tratados, mejoras de calidad
Runbook de respuesta
- Detectar: Se activan alertas o se recibe un informe manual
- Clasificación: Clasificar la severidad y el alcance del impacto
- Contener: Deshabilitar la función, hacer rollback del prompt, activar el fallback
- Investigar: Analizar logs, reproducir el problema, identificar la causa raíz
- Remediar: Aplicar el fix, probar en staging, hacer un deploy gradual
- Comunicar: Notificar a los stakeholders con el estado y la cronología
- Análisis post mortem: Documentar, identificar mejoras e implementarlas
⚠️ Error común
No trates los incidentes con LLM como errores de software. La causa raíz puede ser cambio en el modelo del provider, cambio en la distribución de inputs o interacción entre prompts. El debugging requiere un razonamiento diferente.
Preparación proactiva
- • Alternativas listas: versiones simplificadas de prompts que siempre funcionan
- • Feature flags: deshabilitar funciones específicas sin hacer un deploy
- • Rollback automatizado: volver a una versión anterior con un comando
- • Plantillas de comunicación: mensajes preaprobados para distintos escenarios
Puntos clave del módulo
La evaluación sistémica examina la consistencia, la coherencia y la alineación
El riesgo cognitivo es tan importante como el riesgo operativo
La prompt injection es una vulnerabilidad arquitectónica, no un error puntual
La auditabilidad es esencial para el compliance y la depuración
La observabilidad de los LLM incluye métricas semánticas, no solo técnicas
La respuesta a incidentes para LLM requiere un razonamiento diferente