Testing de sistemas de IA: evaluación, regresión y red teaming

Publicado: 2026-07-06 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Cómo probar un sistema de IA: banco de evaluación con respuestas esperadas, métricas de calidad, regresión al cambiar de modelo, red teaming y monitorización.

Probar un sistema de IA no consiste en comprobar que funciona una vez, sino en medir con qué frecuencia acierta sobre un conjunto de casos representativo y vigilar que esa cifra no empeore. Hacen falta cinco piezas: un banco de evaluación con casos reales y su respuesta esperada; métricas que reflejen lo que importa, como la precisión, la fidelidad a las fuentes y la capacidad de decir «no lo sé»; pruebas de regresión con cada cambio de modelo, prompt o datos; red teaming para encontrar inyecciones de prompts antes que un atacante, y monitorización en producción que convierta los fallos reales en casos nuevos.

Conviene que el banco de evaluación y sus resultados vivan en tu repositorio, no en una plataforma: OpenAI cierra su plataforma de Evals, que pasa a solo lectura el 31 de octubre de 2026 y se apagará el 30 de noviembre.

Por qué el testing de sistemas de IA es distinto

En el software tradicional, la misma entrada produce la misma salida y un test pasa o falla. Un modelo de lenguaje puede dar respuestas distintas a la misma pregunta y acertar casi siempre mientras falla de forma grave en unos pocos casos. Corregir un caso cambiando el prompt puede estropear otros, y el sistema cambia aunque no lo toques: los proveedores retiran modelos —Anthropic avisa con al menos 60 días de antelación—, los documentos se actualizan y los usuarios preguntan cosas nuevas.

El marco de riesgos de IA del NIST lo recoge en su función Medir (Measure): probar antes del despliegue y de forma periódica durante la operación, con procesos objetivos, repetibles y documentados, y monitorizar el comportamiento en producción. En la práctica hay dos capas:

Determinista: troceado de documentos, validación de la salida contra un esquema, permisos, llamadas a herramientas y reintentos. Se prueba con tests unitarios y de integración, como cualquier software.
Probabilística: la calidad de las respuestas, la recuperación de documentos y las decisiones de un agente. Se mide sobre un banco de casos, con métricas y umbrales de aceptación.

El banco de evaluación: casos reales con respuesta esperada

Un banco de evaluación es una colección de entradas con la respuesta correcta, o con el criterio que la define, que se ejecuta contra el sistema para obtener una puntuación. La guía de Anthropic para diseñar evaluaciones pide que refleje la distribución real de la tarea, casos límite incluidos, y prefiere muchas preguntas con corrección automática a pocas corregidas a mano. Las buenas prácticas de OpenAI añaden evaluar pronto y a menudo, y registrarlo todo para extraer casos de los logs.

Qué casos incluir

Habituales: lo que más se repite, en la proporción en que llega.
Difíciles: entradas ambiguas, largas, mal escritas o en otro idioma.
Sin respuesta en las fuentes: para medir si el sistema reconoce que no lo sabe.
Fuera de alcance: peticiones que debe rechazar o derivar a una persona.
Adversarios: intentos de saltarse las instrucciones o de extraer datos.
Fallos conocidos: cada error detectado, para que no vuelva.

Qué guardar en cada caso

Cada caso necesita su criterio de acierto: el valor de cada campo, los datos que la respuesta debe contener, la fuente que debe citar o la acción que no debe ejecutar. En un sistema con RAG, también los fragmentos que deberían recuperarse. Reserva una parte del banco que no se use para ajustar prompts, para que el sistema no aprenda el examen, y anonimiza los casos que salen de conversaciones reales, como se explica en seguridad y privacidad en proyectos de IA.

Métricas de calidad: qué medir en cada tarea

No hay una métrica universal. Anthropic recomienda criterios específicos y medibles —su ejemplo es un F1 de al menos 0,85 sobre un conjunto reservado— y casi siempre de varias dimensiones:

Precisión. En clasificación y extracción, el porcentaje de respuestas o campos correctos. Si unas clases son mucho más frecuentes que otras, el acierto global engaña: mide por clase cuántos positivos son correctos y cuántos se detectan (precision y recall).
Fidelidad. En sistemas con RAG, qué parte de la respuesta está respaldada por el contexto recuperado. Ragas la calcula dividiendo las afirmaciones de la respuesta que se pueden inferir del contexto entre el total, de 0 a 1.
Recuperación. Si los fragmentos correctos llegan al modelo. La exhaustividad del contexto (context recall) penaliza lo que el buscador no encontró; sin ella es fácil culpar al modelo de un fallo del buscador.
Rechazo cuando no sabe. Cuántas preguntas sin respuesta en las fuentes reconoce el sistema y cuántas con respuesta rechaza sin motivo. Anthropic propone permitir que el modelo diga «no lo sé» para reducir invenciones; esta métrica comprueba que lo hace cuando toca.
Formato y herramientas. Salidas que cumplen el esquema, herramienta correcta y argumentos bien rellenados; Ragas incluye métricas para agentes.
Seguridad y operación. Intentos adversarios bloqueados, latencia, coste por tarea y casos escalados a una persona.

Fija el umbral de cada métrica antes de probar, no después de ver los resultados, y marca como bloqueantes los casos cuyo fallo no se tolera aunque la media suba.

Cómo se puntúa: código, modelo evaluador o revisión humana

Anthropic aconseja elegir para cada criterio el método más rápido, fiable y escalable que sirva. Esta tabla compara las opciones:

Método	Qué mide bien	Coste	Límites	Cuándo usarlo
Comparación por código	Campos, clases, formato, herramienta llamada	Casi nulo	No capta respuestas correctas redactadas de otra forma	Siempre que haya una respuesta verificable
Similitud con una referencia	Parecido con una respuesta modelo	Bajo	Premia la forma, no la exactitud	Señal secundaria en respuestas abiertas
Modelo evaluador	Fidelidad, completitud, tono, rúbricas	Moderado; escala	Sesgos de posición y de longitud	Criterios subjetivos, tras calibrarlo con personas
Revisión humana experta	Criterio de negocio y casos dudosos	Alto	No escala	Calibrar al evaluador y revisar muestras
Pruebas adversarias	Inyecciones, fugas y abusos	Medio o alto	Nunca son exhaustivas	Antes de producción y tras cada cambio relevante

El modelo evaluador no es un oráculo. OpenAI advierte de sus sesgos de posición y de longitud y recomienda escalarlo solo cuando coincide de forma consistente con personas expertas. Anthropic sugiere rúbricas detalladas, salidas concretas —correcto o incorrecto, o una escala de 1 a 5— y, en general, evaluar con un modelo distinto del que generó la respuesta.

Pruebas de regresión al cambiar el modelo o el prompt

Una prueba de regresión ejecuta el banco completo antes de publicar un cambio y compara el resultado con la versión en producción. Se lanza con cualquier cambio que afecte a la respuesta: prompt, modelo, parámetros, troceado, embeddings, índice, herramientas o versión de la API del proveedor. Anthropic, por ejemplo, eliminó los parámetros temperature, top_p y top_k en la versión de su API del 21 de octubre de 2026: una integración que dependía de ellos debe revisarse y volver a evaluarse.

Fija versiones: identificador concreto del modelo y prompts versionados junto al código.
Guarda la línea base: el resultado de cada caso, no solo la media.
Ejecuta el banco con el cambio, varias veces si las respuestas varían.
Compara caso a caso: una mejora global puede esconder casos críticos que ahora fallan.
Aplica la puerta: si baja una métrica crítica o falla un caso bloqueante, no se publica.
Automatízalo en la integración continua. Herramientas de código abierto como Promptfoo, que OpenAI propone como ruta de migración desde Evals, ejecutan evaluaciones y pruebas adversarias en el pipeline.

Para comparar proveedores, mira cómo elegir GPT, Claude o Gemini; para decidir si ajustar el modelo, fine-tuning o RAG.

Red teaming e inyección de prompts

Hacer red teaming es intentar romper el sistema a propósito antes de que lo haga otro. OWASP sitúa la inyección de prompts (LLM01:2025) en el primer puesto de su lista para aplicaciones con LLM —directa, si la escribe el usuario; indirecta, si llega en un documento o una web— y recomienda simulaciones de ataque periódicas que traten al modelo como un usuario no confiable. Una batería básica incluye:

Inyección directa: variantes de «ignora las instrucciones anteriores», el ejemplo de las buenas prácticas de seguridad de OpenAI, cambios de rol y texto codificado.
Inyección indirecta: documentos indexados, adjuntos o páginas con instrucciones ocultas.
Fugas: intentos de obtener el prompt de sistema o documentos sin permiso.
Acciones no autorizadas: en agentes, que una instrucción escondida en un dato dispare una herramienta con escritura; los controles están en seguridad en agentes de IA en producción.

La guía de red teaming de OWASP, de enero de 2025, propone cubrir el modelo, la implementación, la infraestructura y el comportamiento en ejecución. El objetivo realista no es que ningún ataque funcione, sino que los que funcionen tengan poco impacto gracias a permisos mínimos, validación de salidas y confirmación humana en lo sensible.

Si el sistema puede ser de alto riesgo según el Reglamento europeo de IA, el artículo 15 exige precisión, solidez y ciberseguridad adecuadas, con las métricas de precisión declaradas en las instrucciones de uso. Para los sistemas del anexo III, esa obligación se aplica desde el 2 de diciembre de 2027; la clasificación de cada caso conviene confirmarla con asesoría especializada.

Monitorización en producción

En producción aparecen las preguntas que nadie previó; para OpenAI, la evaluación es un proceso continuo. En la práctica:

Trazas por petición: versión del modelo y del prompt, contexto recuperado, herramientas, tokens, latencia y coste. Las convenciones de OpenTelemetry para IA generativa las estandarizan sin atarse a un proveedor.
Evaluación sobre una muestra del tráfico con un modelo evaluador, y revisión humana de lo que puntúe bajo.
Señales de uso: valoraciones, correcciones, preguntas reformuladas y escalados.
Deriva: temas nuevos sin documentación o una tasa de «no lo sé» que se dispara o desaparece.
Despliegues graduales: la versión nueva corre primero en sombra o con parte del tráfico.

Cierra el ciclo: los fallos que detecte la monitorización pasan al banco con su respuesta correcta. Como las trazas guardan lo que escriben los usuarios, necesitan permisos y un plazo de conservación; qué registrar está en IA generativa en producción.

Ejemplo hipotético: un asistente de soporte con RAG

El escenario siguiente es hipotético e ilustrativo, no un caso de cliente. Un distribuidor de maquinaria quiere un asistente que responda a su equipo de soporte sobre garantías y recambios con la documentación técnica como fuente. Antes del primer prompt, reúne unas 200 preguntas anonimizadas de tickets antiguos, las clasifica por tipo y añade intentos de inyección, entre ellos un manual con una instrucción oculta. Los umbrales se acuerdan con soporte: cita obligatoria de la fuente, rechazo correcto en preguntas sin respuesta y ninguna inyección con éxito; los plazos de garantía son casos bloqueantes.

Meses después, el proveedor anuncia la retirada del modelo. El sustituto mejora en las preguntas habituales, pero redondea algunos plazos; el cambio no se publica hasta corregir el prompt y que esos casos vuelvan a pasar. En producción, una muestra semanal se revisa a mano y cada error nuevo entra en el banco.

Cuánto cuesta montar la evaluación

Nuestro informe de precios 2026 no publica un rango para la evaluación por separado, porque forma parte del proyecto: un sistema que no se puede medir no está terminado. Como referencia, proyectos que la incluyen:

Chatbot o asistente con RAG: 10.000-25.000 €, en 4-8 semanas.
Agente acotado a una tarea: 20.000-35.000 €, en 6-8 semanas.
Sistema multiagente sobre procesos críticos, con evaluación continua y observabilidad: 60.000-100.000 € o más, en 12-16 semanas.

Después, la evaluación entra en los costes recurrentes: el uso de modelos por API —desde unos 100 € al mes con poco volumen y 2.000-5.000 € al mes con volumen alto—, que incluye los tokens de los evaluadores, y el mantenimiento, del 15 al 25 % del coste de desarrollo al año. El tiempo de quien revisa muestras no tiene rango publicado. Más detalle en cuánto cuesta desarrollar un agente de IA y sistemas RAG para empresas.

Errores frecuentes

Evaluar por impresiones, un antipatrón que cita OpenAI: probar diez preguntas a mano y dar el sistema por bueno.
Un banco solo con casos fáciles, que da cifras que no se sostienen con usuarios reales.
Mirar solo la media, que oculta regresiones en los casos que más importan.
Fiarse de un modelo evaluador sin calibrar.
No fijar la versión del modelo, de modo que un cambio del proveedor altera los resultados sin aviso.

Preguntas frecuentes

¿Por qué probar un sistema de IA es distinto de probar software tradicional?

Porque un modelo no falla de forma binaria: puede responder bien a casi todo, equivocarse en una parte de los casos y dar respuestas distintas a la misma pregunta. Por eso se mide la calidad sobre un banco de casos representativo, con métricas y umbrales, además de los tests unitarios de la parte determinista.

¿Qué es un banco de evaluación y cuántos casos necesita?

Es una colección de casos reales o realistas con su respuesta esperada o su criterio de acierto: habituales, difíciles, sin respuesta en las fuentes y adversarios. No hay una cifra mínima universal; se empieza con unas decenas bien elegidas, se automatiza la corrección y se amplía con cada fallo detectado.

¿Qué métricas sirven para evaluar un sistema RAG?

Como mínimo, la calidad de la recuperación (si llegan los fragmentos correctos), la fidelidad de la respuesta al contexto recuperado y el rechazo correcto cuando la respuesta no está en las fuentes. Herramientas como Ragas las calculan de forma automática. Ver cómo funciona un sistema RAG.

¿Hay que repetir las pruebas al cambiar de modelo o de prompt?

Sí. Cualquier cambio de modelo, versión, prompt, documentos o herramientas puede mejorar unos casos y empeorar otros. El banco completo se ejecuta antes de publicar y el cambio se bloquea si baja una métrica crítica o falla un caso que no admite error.