El plan de pruebas de una función con IA

Todo el curso en un documento

Las lecciones anteriores son piezas. El plan de pruebas las junta en algo que se puede presentar, aprobar y auditar. Cabe en una página y tiene siete secciones.

1. Alcance

Qué hace la función y, sobre todo, qué no hace. Con qué modelo (y versión), qué documentos consulta, qué herramientas puede usar y con qué permisos. Si el alcance no está escrito, cada persona del equipo prueba una función distinta.

2. Riesgos

Los riesgos de OWASP que aplican, priorizados por impacto para este negocio. No todos aplican siempre; un asistente de preguntas frecuentes sin herramientas no tiene riesgos de agencia, pero sí de desinformación y de inyección indirecta. Tres o cuatro riesgos bien elegidos valen más que los veinte copiados.

3. Evals

El set (cuántos casos de cada tipo), la rúbrica con ejemplos, cuántas corridas por caso y quién o qué puntúa. Si hay un juez automático, cómo y cuándo se calibró (lección 2).

4. Criterios de salida

Escritos para que un gerente los entienda y los pueda verificar:

• promedio mínimo en la rúbrica (por ejemplo, 1,6 sobre 2);
• cero fallas en los casos críticos, en cualquier corrida;
• cero acciones irreversibles sin confirmación de la persona;
• todos los casos sin respuesta responden "no sé" o derivan, sin inventar.

El último punto merece estar aparte porque es el que más se negocia: "solo inventó 2 de 50". En producción, con miles de conversaciones, esos 2 de 50 son cientos de respuestas falsas.

5. Regresión

El set de evals corre antes de cada cambio de prompt, de modelo, de documentos o de herramientas. Quién lo corre, dónde (idealmente en el pipeline) y qué pasa si baja del umbral: el cambio no sale.

6. Monitoreo en producción

En una función con IA, el sistema sigue cambiando después del lanzamiento: el proveedor actualiza el modelo, se suben documentos nuevos, llegan usuarios que preguntan cosas que nadie imaginó. Por eso el monitoreo es parte del plan de pruebas, no un anexo:

• una muestra periódica de conversaciones reales, anonimizadas, puntuada con la misma rúbrica;
• un canal para que el usuario marque una respuesta como incorrecta;
• y la regla de que cada falla real se convierte en un caso nuevo del set.

7. Quién firma

El nombre de quien firma el Go. No "el equipo": una persona. Es la misma regla del curso de liderazgo: la IA propone, una persona decide y responde.

El veredicto

Con el plan escrito, la decisión deja de ser una sensación ("se ve bien en la demo") y pasa a ser una verificación: ¿se cumplieron los criterios de salida? Si sí, Go. Si un crítico falló, No-Go, aunque la demo haya impresionado a todos. Si algo falla de forma acotada, Go con condiciones: por ejemplo, salir sin la herramienta de cupones hasta corregirla.

Ese es el trabajo de QA en un sistema con IA: no prometer que nunca va a fallar, sino saber cómo falla, cuánto, y dejar la decisión en manos de quien corresponde, con evidencia.