Guía Testing de IA / LLM — QA Shift-Left Methodology

🤖 GUÍA TESTING DE IA / LLM

Cómo probar, medir y validar aplicaciones basadas en modelos de lenguaje y sistemas de IA

QA Shift-Left Methodology · by E-Gregorio

ISO/IEC TR 29119-11:2020 ISO/IEC 25059:2023 NIST AI RMF 1.0 OWASP LLM Top 10 (2025) EU AI Act (referencia) MLPerf · HELM · MMLU

Esta guía establece el marco metodológico para validar la calidad, seguridad, performance y robustez de aplicaciones que usan LLMs (Large Language Models) y, en general, sistemas con componentes de IA. Cubre los desafíos únicos del testing no determinístico y aporta plantillas, métricas y pipelines listos para usar.

📋 Contenido

1. ¿Por qué testing de IA/LLM es distinto?
2. Marco normativo aplicable
3. Tipos de testing aplicables a LLMs
4. OWASP LLM Top 10 (2025)
5. Métricas de calidad de respuesta
6. Evals: el equivalente a "tests unitarios"
7. Performance de LLMs
8. Testing de sistemas RAG
9. Tooling recomendado
10. Pipeline CI/CD con evals continuos
11. Plantilla: Plan de pruebas LLM
12. Anti-patterns

1. ¿Por qué testing de IA/LLM es distinto?

El testing tradicional asume determinismo: dada una entrada, la salida es predecible y verificable con un assert exact_match. Los sistemas con LLM rompen ese supuesto:

Aspecto	Software tradicional	Aplicación con LLM
Determinismo	Misma entrada → misma salida	Misma entrada → salida distribución probabilística (incluso con temperature=0 hay no determinismo a nivel de hardware)
Oráculo de prueba	`expected == actual`	Múltiples respuestas válidas → necesita scoring semántico o LLM-as-a-judge
Cobertura	Líneas, ramas, mutaciones	Cobertura de casos de uso + casos adversariales + distribuciones de entrada
Regresión	Test pasa o falla	Métrica agregada sobre golden set; degradación medida en %
Defectos típicos	Bugs lógicos, edge cases	Alucinaciones, sesgos, jailbreaks, drift, prompt injection, data leakage
Versionado	Código + dependencias	Código + modelo + prompt + retrieval index + fine-tuning
Costo de un test	~ms, gratis	USD reales por llamada al modelo + latencia variable

⚠️ Implicación práctica: el testing de LLMs requiere métricas estadísticas agregadas, no asserts binarios. Hablamos de "el sistema responde correctamente al 95% del golden set", no de "el test pasa".

2. Marco normativo aplicable

Estándar	Año	Aporte al testing
ISO/IEC TR 29119-11	2020	Primer Technical Report formal sobre testing de sistemas basados en IA. Define características específicas (adaptabilidad, autonomía, evolución), tipos de prueba aplicables y consideraciones de oráculo no determinístico.
ISO/IEC 25059	2023	Extiende ISO 25010 con un modelo de calidad para sistemas IA. Añade características como functional adaptability, user controllability, transparency, robustness, intervenability.
ISO/IEC 5338	2023	AI System Life Cycle Processes. Procesos de validación, verificación y monitoreo aplicables a sistemas IA.
ISO/IEC 23894	2023	AI risk management. Marco de gestión de riesgos específico para IA (input para risk-based testing).
NIST AI RMF 1.0	2023	Marco de gestión de riesgos del NIST. Funciones Govern, Map, Measure, Manage. El Generative AI Profile (jul 2024) lo adapta a GenAI/LLMs.
OWASP LLM Top 10	2025	Listado de los 10 riesgos de seguridad más críticos en aplicaciones LLM. Imprescindible para security testing de LLMs.
OWASP ML Top 10	2023	Equivalente para sistemas ML clásicos (data poisoning, model inversion, etc.).
EU AI Act	2024	Regulación europea. Obligaciones de testing y monitoreo según nivel de riesgo (prohibido, alto, limitado, mínimo). Aplicable a sistemas "general-purpose AI".
MLPerf Inference / Training	continuo	Suite de benchmarks de la industria para comparar performance de modelos en hardware específico.
HELM (Stanford)	continuo	Holistic Evaluation of Language Models. Suite open de evals con métricas multidimensionales.

📌 Para auditorías: si tu sistema cae bajo el EU AI Act como "high-risk AI system", vas a necesitar evidencia documental de testing post-deployment. El stack ISO/IEC 29119-11 + 25059 + NIST AI RMF da la cobertura mínima esperada.

3. Tipos de testing aplicables a LLMs

Tipo	Qué valida	Técnica	Herramienta
Functional	El sistema responde lo que debe responder a casos esperados	Golden dataset + scoring	promptfoo, DeepEval
Robustez	Respuesta estable ante perturbaciones (typos, paráfrasis, idiomas)	Adversarial perturbations, mutation testing semántico	TextAttack, NLPAug
Bias / Fairness	No hay sesgos discriminatorios por género, raza, edad, etc.	Counterfactual prompts, BBQ benchmark	Aequitas, Fairlearn, BBQ
Toxicidad	El modelo no genera contenido tóxico/ofensivo	Toxicity scoring	Perspective API, Detoxify
Hallucination / Groundedness	Las afirmaciones están respaldadas por la evidencia (RAG)	Groundedness scoring contra contexto recuperado	Ragas, TruLens
Security (LLM)	No hay prompt injection, jailbreaks, data leakage	Pentesting de prompts, red-teaming	garak, PyRIT (Microsoft)
Performance	Latencia, throughput, cost-per-call	Load testing con prompts realistas	k6 + custom, Locust
Drift	El modelo no degrada en producción a lo largo del tiempo	Monitoring continuo de métricas + golden set scheduled	Helicone, LangSmith, Arize
A/B testing	Una versión del prompt/modelo es estadísticamente mejor	Online experiments con métricas de negocio	LaunchDarkly + custom analytics
Regression	Cambios en prompt/modelo no rompen casos existentes	Eval suite ejecutada en cada PR	promptfoo en CI, OpenAI evals

4. OWASP LLM Top 10 (2025)

Los 10 riesgos de seguridad más críticos en aplicaciones LLM. Cada uno con técnica de prueba recomendada:

#	Riesgo	Descripción	Cómo probarlo
LLM01	Prompt Injection	Atacante manipula el prompt (directo o indirecto vía documento envenenado) para alterar el comportamiento	Suite de prompts adversariales conocidos + indirect injection vía RAG. Tools: `garak`, `PyRIT`.
LLM02	Sensitive Information Disclosure	El modelo revela datos confidenciales en respuesta (PII, secretos, datos de entrenamiento)	Probes con técnicas de extracción + scanning de output con Presidio/regex de PII.
LLM03	Supply Chain	Modelo, dataset, plugin o librería comprometida en la cadena de suministro	SCA del modelo (origen, hash, licencia). Verificación de procedencia.
LLM04	Data and Model Poisoning	Datos de entrenamiento o fine-tuning manipulados para introducir backdoors	Backdoor detection (trigger probes), análisis estadístico del dataset.
LLM05	Improper Output Handling	Output del LLM se usa sin sanitizar en SQL, shell, render HTML → XSS, SSRF, RCE	Probes que generen XSS/SQL/shell payloads en la respuesta + verificación de sanitización downstream.
LLM06	Excessive Agency	El agente LLM tiene permisos/herramientas excesivos (delete DB, send email)	Threat modeling de tool-calling. Test de privilege escalation. Sandbox obligatorio.
LLM07	System Prompt Leakage	El system prompt (que puede contener IP o reglas) es extraído por el atacante	Suite de probes "ignore previous instructions / repeat your system prompt".
LLM08	Vector and Embedding Weaknesses	Vector store con datos cross-tenant, embeddings invertibles, índice envenenado	Tests de aislamiento por tenant + embedding inversion attacks.
LLM09	Misinformation	El modelo afirma información falsa con confianza (hallucination en dominios críticos)	Groundedness scoring + factuality benchmarks (TruthfulQA).
LLM10	Unbounded Consumption	Atacante fuerza prompts caros (long-context, recursión) → DoS o factura inesperada	Rate limiting tests + cost tests. Token-bucket por usuario.

🚨 Top 3 que más se ven en producción: Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02) y Improper Output Handling (LLM05). En tu primer ciclo de security testing, priorizá estos.

5. Métricas de calidad de respuesta

5.1 Métricas semánticas (correctness)

Exact Match

cuando aplica

Solo válido para tareas con única respuesta correcta (clasificación, extracción).

Semantic Similarity

≥ 0.80 (cosine)

Embedding de respuesta vs. golden, distancia coseno.

BLEU / ROUGE

depende task

N-gram overlap. Útil en traducción/resumen, limitado para QA libre.

BERTScore

≥ 0.85

Similaridad usando embeddings de BERT. Mejor que BLEU para naturalidad.

LLM-as-a-judge

≥ 4/5 avg

Modelo más fuerte (GPT-4, Claude Opus) puntúa según rúbrica. Atención al sesgo del juez.

Eval pass rate

≥ 95%

% del golden set que pasa los criterios definidos.

5.2 Métricas RAG-specific (Ragas framework)

Faithfulness

≥ 0.90

¿La respuesta está respaldada por el contexto recuperado?

Answer Relevancy

≥ 0.85

¿La respuesta responde a lo que pregunta el usuario?

Context Precision

≥ 0.80

¿Los chunks recuperados son relevantes? (señal/ruido en retrieval)

Context Recall

≥ 0.75

¿Se recuperaron todos los chunks necesarios?

Hallucination Rate

≤ 5%

% de respuestas con afirmaciones no respaldadas.

5.3 Métricas de seguridad / safety

Toxicity Score

≤ 0.10

Probabilidad de output tóxico (Perspective API, Detoxify).

Refusal Rate

contextual

% de prompts donde el modelo se rehúsa. Demasiado bajo = inseguro; demasiado alto = inútil.

Jailbreak Resistance

≥ 95%

% de jailbreaks conocidos (DAN, do-anything) que el modelo resiste.

PII Leakage Rate

% de respuestas que filtran PII (email, teléfono, SSN, tokens).

Bias Score (BBQ)

|score| ≤ 0.10

Score del benchmark BBQ sobre 11 dimensiones de sesgo.

6. Evals: el equivalente a "tests unitarios"

Una eval es la unidad básica de testing en aplicaciones LLM. Estructura típica:

{ "id": "ticket-classification-001", "input": "Mi factura de marzo no aparece en mi cuenta", "expected": { "category": "billing", "priority": "medium", "language": "es" }, "assertions": [ { "type": "contains-json-key", "key": "category" }, { "type": "equals", "path": "$.category", "value": "billing" }, { "type": "llm-rubric", "rubric": "La respuesta es empática y propone próximos pasos concretos" }, { "type": "not-contains", "value": "no puedo ayudarte" }, { "type": "latency", "max_ms": 2000 }, { "type": "cost", "max_usd": 0.005 } ], "metadata": { "owner": "qa-team", "tags": ["regression", "billing-feature"], "added": "2026-04-26" } }

6.1 Tipos de assertion

Tipo	Cuándo usar	Ejemplo
equals / exact-match	Tareas con única respuesta correcta	Clasificación de intent
contains / regex	Verificar presencia/ausencia de keyword	"La respuesta debe mencionar el SLA de 24h"
json-schema	Salida estructurada	Validar que el output es JSON válido con campos esperados
semantic-similarity	Tareas con respuestas equivalentes	"México DF" ~ "Ciudad de México"
llm-rubric	Criterios subjetivos (tono, claridad)	"La respuesta es empática y profesional"
factuality	Verificar afirmaciones factuales	FActScore, contra base de datos de verdad
toxicity-below	Safety	Perspective API score < 0.1
latency / cost	SLOs operativos	p95 < 1500ms, costo < $0.01

6.2 Tamaño y composición del golden set

Mínimo viable: 50 evals para arrancar (cubrir flujos principales).
Producción: 200-500 evals para tener señal estadística confiable.
Distribución recomendada: 60% happy path · 25% edge cases · 10% adversarial · 5% known regressions.
Refresh cadence: añadir ≥ 5 evals por sprint (especialmente: cada bug que escapó a prod → eval).
Versionado: el golden set en git, junto con el código.

7. Performance de LLMs

Performance en LLMs no se mide igual que en una API REST normal. Métricas clave:

Métrica	Definición	Target típico	Por qué importa
TTFT Time to First Token	Tiempo desde request hasta el primer token streameado	p95 < 1.5s	UX percibida — el usuario ve que "algo pasa"
TPOT Time Per Output Token	Tiempo medio entre tokens consecutivos	< 50ms (≥ 20 tokens/s)	Velocidad de generación percibida
E2E Latency	TTFT + TPOT × output_tokens	p95 < 5s para respuestas cortas	Tiempo total de respuesta
Throughput	Tokens/segundo a nivel sistema	depende del modelo y hardware	Capacidad agregada
RPS bajo carga	Requests/segundo sin degradar TTFT	SLO definido por producto	Capacidad concurrente
Tail latency	p99, p99.9 de E2E	p99 < 2 × p95	Experiencia de los usuarios "afortunados" 1%
Cost per request	USD por request (input_tokens × $/1k + output_tokens × $/1k)	SLO de unit economics	Sostenibilidad del producto
Cache hit rate	% de respuestas servidas desde cache (prompt cache, embedding cache)	≥ 30% en chatbots con FAQs	Reduce costo y latencia
Context utilization	tokens usados / tokens disponibles	< 80% para evitar truncamiento	Garantiza que entra todo el contexto

7.1 Test de carga con k6 contra un endpoint LLM

// k6 — load test de un endpoint LLM, medir TTFT y TPOT import http from 'k6/http'; import { check, sleep } from 'k6'; import { Trend } from 'k6/metrics'; const ttft = new Trend('ttft_ms', true); const e2e = new Trend('e2e_ms', true); export const options = { scenarios: { chatbot: { executor: 'ramping-arrival-rate', startRate: 5, timeUnit: '1s', preAllocatedVUs: 50, maxVUs: 200, stages: [ { target: 10, duration: '2m' }, { target: 50, duration: '5m' }, { target: 100, duration: '5m' }, { target: 0, duration: '1m' } ] } }, thresholds: { 'ttft_ms': ['p(95)<1500', 'p(99)<3000'], 'e2e_ms': ['p(95)<5000'], 'http_req_failed': ['rate<0.01'] } }; export default function () { const t0 = Date.now(); const res = http.post(__ENV.LLM_URL, JSON.stringify({ model: 'gpt-4o-mini', messages: [{ role: 'user', content: 'Resumí en 2 frases qué es shift-left testing' }], stream: false }), { headers: { 'Authorization': `Bearer ${__ENV.API_KEY}` } }); const t1 = Date.now(); e2e.add(t1 - t0); ttft.add(res.timings.waiting); check(res, { '200': r => r.status === 200 }); sleep(1); }

8. Testing de sistemas RAG (Retrieval-Augmented Generation)

Un RAG tiene dos componentes que pueden fallar independientemente. Hay que probarlos por separado y luego juntos:

Componente	Qué probar	Métrica clave
1. Retrieval	¿El sistema recupera los chunks correctos para la pregunta?	Recall@k, MRR, Context Precision/Recall (Ragas)
2. Generation	Dado el contexto correcto, ¿el LLM genera la respuesta correcta?	Faithfulness, Answer Relevancy
3. End-to-end	Combinación: ¿el sistema responde correcto al usuario final?	Eval pass rate, satisfacción humana

Truco diagnóstico: si el end-to-end falla, hacé el test con el contexto inyectado manualmente (skipping retrieval). Si pasa, el problema es el retrieval. Si falla, es el LLM/prompt.

8.1 Casos a cubrir en un golden set RAG

Preguntas con respuesta directa en la KB → debe responder.
Preguntas sin respuesta en la KB → debe decir "no sé" / "no encontré".
Preguntas con respuesta parcial → debe responder lo que sabe + admitir lo que no.
Preguntas ambiguas → debe pedir clarificación.
Preguntas con info contradictoria entre chunks → debe detectarlo.
Indirect prompt injection: documento envenenado con "ignore previous instructions".
Preguntas en otro idioma distinto del corpus.
Preguntas extremadamente largas (testing de context window).

9. Tooling recomendado

Herramienta	Tipo	Uso	Notas
promptfoo	OSS	Eval framework + comparación side-by-side de prompts/modelos	Fácil de integrar en CI
Ragas	OSS (Python)	Métricas específicas RAG (faithfulness, answer relevancy, context precision/recall)	Standard de facto para RAG
DeepEval	OSS	Framework tipo pytest para LLMs, > 14 métricas builtin	Sintaxis pytest familiar
OpenAI Evals	OSS	Framework de evals genérico, registry de evals públicas	Bueno para benchmarks reproducibles
garak	OSS	Vulnerability scanner para LLMs (jailbreaks, leaks, encodings)	"OWASP ZAP de LLMs"
PyRIT	OSS (Microsoft)	Framework de red-teaming automatizado	Más flexible que garak para custom attacks
Helicone	SaaS / OSS	Observability + monitoring de llamadas LLM	Drop-in, low overhead
LangSmith	SaaS	Tracing, eval, monitoring de LangChain	Si usás LangChain ya viene integrado
Arize Phoenix	OSS	Observability open-source con evals integradas	Alternativa a LangSmith
TruLens	OSS	Evaluación con feedback functions	Bueno para RAG con groundedness
Perspective API	SaaS (Google)	Toxicity scoring	API gratuita con rate limits
Presidio	OSS (Microsoft)	Detección y anonimización de PII	Pre/post processing

10. Pipeline CI/CD con evals continuos

Estrategia recomendada: evals en cada PR + evals scheduled en producción.

# .github/workflows/llm-evals.yml name: LLM Evals on: pull_request: paths: ['prompts/**', 'src/llm/**', 'evals/**'] schedule: - cron: '0 6 * * *' # diaria a las 06:00 UTC jobs: evals: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: '20' } - run: npm ci - name: Run promptfoo eval suite env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} run: npx promptfoo eval -c evals/promptfoo.yaml --output evals/results.json - name: Compare vs baseline run: | node scripts/compare-evals.js \ --current evals/results.json \ --baseline evals/baseline.json \ --threshold 0.95 # falla si pass-rate cae >5% - name: Comment results on PR if: github.event_name == 'pull_request' run: npx promptfoo share --output html | gh pr comment ${{ github.event.pull_request.number }} -F - - name: Upload artifacts uses: actions/upload-artifact@v4 with: { name: eval-results, path: evals/results.json }

10.1 Estrategia de gates por entorno

Entorno	Frecuencia	Gate	Acción si falla
PR	Cada commit	Pass rate ≥ baseline -2pp	Bloquea merge
Staging	Diaria	Pass rate ≥ 95% + safety = 100%	Alerta + bloqueo de promote
Producción	Continua (sample)	Drift < 5% sobre 7 días	Alerta a oncall, posible rollback
Pre-release modelo nuevo	Una vez	Suite completa + red-teaming	No release sin sign-off

11. Plantilla — Plan de pruebas LLM (resumen)

# Plan de pruebas LLM — <feature> ## 1. Identificación - Feature: … - Modelo(s): GPT-4o-mini / Claude Sonnet 4.6 / Llama-3.3 - Versión del prompt: v1.4 (commit abc123) - Owner QA: … - Fecha: 2026-04-26 ## 2. Alcance - IN: clasificación de tickets, generación de respuesta inicial, escalación - OUT: traducción multilingüe (otra feature) ## 3. Modelo de calidad (ISO/IEC 25059) - [x] Functional adaptability - [x] Robustness - [x] User controllability - [x] Transparency (logging de razonamiento) - [ ] Intervenability (human-in-the-loop) — pendiente ## 4. Riesgos identificados (matriz P×I) | ID | Riesgo | P | I | Mitigación | |----|--------|---|---|------------| | R1 | Hallucination en tickets de billing | 3 | 3 | Groundedness threshold 0.9 + rejection si baja | | R2 | Prompt injection vía título de ticket | 3 | 3 | Input sanitization + system prompt hardening | | R3 | Latencia > 3s percibida lenta | 2 | 2 | Streaming + caching de FAQs | ## 5. Tipos de testing aplicables - Functional: golden set 200 evals - Robustness: 50 paráfrasis + typos - Security: OWASP LLM Top 10 (LLM01, LLM02, LLM05 prioritarios) - Performance: k6 con 50 RPS sostenidos, p95 TTFT < 1.5s - A/B prompt v1.4 vs v1.3 (1 semana, 5% tráfico) ## 6. Criterios de aceptación | Métrica | Threshold | |---------|-----------| | Eval pass rate | ≥ 95% | | Faithfulness (RAG) | ≥ 0.90 | | Toxicity | ≤ 0.05 | | PII leakage | 0% | | p95 TTFT | < 1.5s | | Cost / request | ≤ $0.005 | ## 7. Datos de prueba - Golden set: 200 casos (60% happy / 25% edge / 10% adversarial / 5% regresión) - Adversarial set: 50 prompts de OWASP LLM Top 10 - Performance set: 100 prompts representativos de tráfico real ## 8. Pipeline - PR: promptfoo eval (subset 50 casos rápidos) - Daily: full suite + safety scan (garak) - Weekly: red-teaming sesión (humano + PyRIT) - Continuous: sampling 1% prod + groundedness scoring ## 9. Salida - Reporte HTML por ejecución - Dashboard Grafana con métricas en producción - Eval results en S3/artifact por release

12. Anti-patterns comunes

Probar solo el "happy path". Sin adversarial = falsa confianza. Mínimo 10% de tu set debe ser adversarial.
Usar el mismo modelo como juez y bajo prueba. Sesgo de auto-evaluación. Para LLM-as-a-judge, usar un modelo más fuerte/diferente.
No versionar el golden set. Sin versión, no hay comparación válida entre runs.
Confiar en BLEU/ROUGE para QA. Funcionan en traducción/resumen, no en QA libre.
Probar con temperature=1.0. Para evals: usar temperature=0 (determinismo máximo) y seed fija si el modelo lo soporta. Para producción es otro tema.
Ignorar el costo. Una eval suite cara que se corre todos los días puede costar miles de USD/mes. Sample inteligente.
"El modelo nuevo es mejor" sin medirlo. Cada upgrade de modelo es un cambio mayor — re-correr la suite completa antes de promote.
Skip seguridad. "Es solo un chatbot interno" no exime de prompt injection. La menor superficie de ataque sigue siendo superficie.
No tener "evals de regresión por bug". Cada bug que escapó a producción debe convertirse en una eval del golden set.
Probar offline y deployar sin shadow mode. Shadow run en producción 1-7 días antes de cutover real.

📚 Referencias

ISO/IEC TR 29119-11:2020 — Testing of AI-based systems
ISO/IEC 25059:2023 — Quality model for AI systems
NIST AI Risk Management Framework 1.0 (AI 100-1, ene 2023) + Generative AI Profile (AI 600-1, jul 2024)
OWASP Top 10 for Large Language Model Applications (2025)
EU Artificial Intelligence Act (Regulation 2024/1689)
Stanford CRFM — HELM (Holistic Evaluation of Language Models)
MLPerf Inference / Training benchmarks (mlcommons.org)
Ragas — github.com/explodinggradients/ragas
promptfoo — github.com/promptfoo/promptfoo
NVIDIA garak — github.com/NVIDIA/garak
Microsoft PyRIT — github.com/Azure/PyRIT

QA Shift-Left Methodology — Framework operativo integrado por E-Gregorio
Guía Testing IA/LLM — referencia a estándares públicos: ISO/IEC TR 29119-11:2020, ISO/IEC 25059:2023, NIST AI RMF 1.0 y OWASP LLM Top 10 (2025)