Cómo crear un plan de pruebas de IA antes de un go-live

Llega el momento de poner tu agente de IA frente a clientes y alguien hace la pregunta que importa: ¿cómo sabemos que está listo? Si la respuesta es “lo probamos un rato y anda bien”, no tienes un plan de pruebas: tienes una corazonada. Y las corazonadas no aprueban un go-live en una empresa seria —ni resisten una auditoría si algo sale mal después.

Un plan de pruebas de IA es el documento que convierte “creemos que funciona” en “podemos demostrar que funciona”. Esta guía te lleva paso a paso a armarlo, con una estructura que puedes reutilizar en cada lanzamiento.

Por qué un plan, y no solo “probar un rato”

La tentación de saltarse esto es real, pero los datos no acompañan: se proyecta que más del 40% de los proyectos de IA agéntica se cancelarán para fines de 2027, a menudo porque los equipos no tienen la infraestructura de evaluación para detectar fallas antes de producción.^[1] Dicho de otro modo: la mayoría de los proyectos que fracasan no fracasan por mala tecnología, sino por no haber probado de forma sistemática antes de exponerse.

Un plan de pruebas hace tres cosas que una prueba informal no: define qué significa “listo” antes de mirar resultados (para no mover el arco), cubre los casos que importan y no solo los felices, y deja evidencia de que se hizo. Vamos a construirlo.

Paso 1 — Define el alcance y los riesgos

Antes de escribir un solo caso de prueba, respondé: ¿qué hace este agente y qué es lo peor que podría pasar si se equivoca?

Lista las funciones que va a cumplir (responder sobre productos, gestionar un reclamo, dar información de cuenta) y, al lado de cada una, el riesgo asociado. Un agente que solo informa horarios tiene un perfil de riesgo distinto a uno que confirma saldos o interpreta una póliza. Esta lista de riesgos es la que define dónde concentrar el esfuerzo de prueba: no todo merece la misma profundidad.

Paso 2 — Define los criterios de éxito (antes de probar)

Este es el paso que más se saltea y el más importante. Para cada dimensión que vas a evaluar, define de antemano qué umbral tiene que alcanzar para aprobar. Por ejemplo: precisión factual por encima de cierto nivel, tasa de alucinaciones por debajo de otro, derivación correcta a un humano en el 100% de los casos críticos.

¿Por qué antes? Porque si defines el criterio después de ver los resultados, inconscientemente vas a ajustar el arco a donde pegó la flecha. Los criterios fijados de antemano son los que vuelven al plan honesto —y los que le dan al responsable del go-live una base objetiva para decir sí o no.

Paso 3 — Diseña los casos de prueba (los tres tipos)

Un buen plan no prueba solo lo que esperas que funcione. Cubrí tres tipos de casos:

• Casos felices: las consultas típicas que el agente va a recibir el 80% del tiempo. Lo básico tiene que funcionar.
• Casos borde: lo inusual pero posible —preguntas ambiguas, fuera de alcance, con datos incompletos. Acá es donde un agente empieza a improvisar.
• Casos adversarios: los diseñados para romperlo a propósito —intentar que invente una política, que se salga de su rol, que dé una respuesta que no debería. Si no lo atacas vos, lo va a hacer un usuario real.

Para cada caso, define la pregunta, el contexto necesario y el comportamiento esperado. Un caso de prueba sin comportamiento esperado no es un caso: es una pregunta suelta.

Paso 4 — Organiza los casos en planes temáticos

Con decenas o cientos de casos, necesitas estructura. Agrupalos por tema o por función: un plan de “precisión de datos”, uno de “manejo de reclamos”, uno de “escalamiento”, uno de “seguridad”. Esto sirve para dos cosas: cubrir cada área de forma deliberada (y ver dónde tienes huecos) y, después del lanzamiento, poder reutilizar cada plan como prueba de regresión cuando cambies el prompt o el modelo.

Paso 5 — Ejecuta, mide y documenta

Corre los casos, mide cada dimensión contra los criterios del Paso 2, y registra los resultados. La documentación no es burocracia: es la evidencia que respalda la decisión de lanzar. Si más adelante hay una auditoría, un reclamo o simplemente una revisión interna, ese registro es lo que demuestra que la calidad se verificó de forma sistemática y no por intuición.

La checklist del go-live

Antes de aprobar el lanzamiento, verifica:

• [ ] Están definidas las funciones del agente y sus riesgos asociados.
• [ ] Hay criterios de éxito con umbrales, fijados antes de probar.
• [ ] Los casos cubren situaciones felices, borde y adversarias.
• [ ] Las dimensiones críticas (precisión, alucinaciones, escalamiento, tono) están evaluadas.
• [ ] El escalamiento a un humano funciona en el 100% de los casos críticos.
• [ ] Los resultados están documentados como evidencia.
• [ ] Hay un plan de monitoreo para después del lanzamiento (el testing no termina en el go-live).

Ese último punto es clave y suele olvidarse: aprobar el go-live no es el final. Los modelos se degradan, así que el plan tiene que incluir cómo vas a seguir midiendo en producción.

Cómo lo resuelve ArtificialQA

Armar y ejecutar todo esto a mano —diseñar casos, correrlos, medir cada dimensión, documentar— es justo lo que vuelve inviable un plan de pruebas serio sin las herramientas adecuadas. ArtificialQA te deja conectar tu agente —por URL o por API, sin código—, organizar tus casos en planes temáticos, ejecutarlos y evaluarlos con jueces calibrados sobre las dimensiones que definiste, y obtener un registro auditable de cada corrida. Los mismos planes quedan listos para reusarse como pruebas de regresión y para el monitoreo posterior.

El resultado es que la pregunta “¿cómo sabemos que está listo?” deja de responderse con una corazonada y pasa a responderse con evidencia. Que es, al final, la única respuesta que debería habilitar un go-live.

Preguntas frecuentes

¿Qué es un plan de pruebas de IA? Es el documento que define cómo se va a evaluar un agente de IA antes de un lanzamiento: su alcance y riesgos, los criterios de éxito, los casos de prueba y los resultados. Convierte “creemos que funciona” en “podemos demostrar que funciona”.

¿Por qué hay que definir los criterios de éxito antes de probar? Para no ajustar el objetivo a los resultados. Si defines el umbral después de ver cómo le fue al agente, inconscientemente lo acomodas. Los criterios fijados de antemano mantienen el plan honesto y dan una base objetiva para aprobar o no el go-live.

¿Qué tipos de casos de prueba debe incluir un plan? Tres: casos felices (las consultas típicas), casos borde (situaciones inusuales o ambiguas) y casos adversarios (diseñados para romper el agente a propósito). Probar solo los felices deja fuera lo que de verdad falla.

¿El testing de IA termina en el lanzamiento? No. Los modelos se degradan con el tiempo, así que el plan debe incluir cómo se va a monitorear la calidad en producción después del go-live.

¿Para qué sirve documentar los resultados de las pruebas? Son la evidencia que respalda la decisión de lanzar. Ante una auditoría, un reclamo o una revisión interna, demuestran que la calidad se verificó de forma sistemática y no por intuición.