Respuesta breve: Define la línea base y el umbral de aceptación antes de probar; después mide calidad, tiempo, coste, adopción, excepciones y correcciones humanas.
Escribe la decisión antes de ejecutar la prueba
Indica qué decisión respalda el piloto: pasar a una fase limitada de producción, revisar y volver a probar, pausar por falta de datos o por trabajo pendiente sobre el proceso, elegir una solución más sencilla o detenerse. Sin esa decisión, un equipo puede celebrar una demostración llamativa mientras evita las evidencias importantes.
Establece la línea base actual
Mide el proceso antes de introducir IA. Algunas medidas útiles son:
- volumen y tiempo de finalización;
- tiempo de espera y trabajo pendiente;
- tasa de corrección, repetición y escalado;
- calidad o precisión evaluada por revisores cualificados;
- coste por caso completado;
- impacto en clientes o personal;
- número y gravedad de las excepciones.
Utiliza las mismas definiciones durante el piloto. Un resultado más rápido no supone una mejora si los revisores dedican más tiempo a corregirlo.
Define los umbrales de aceptación
Antes de probar, fija la calidad mínima, la tasa máxima de errores dañinos, el tiempo máximo de revisión, el coste aceptable y la latencia permitida. Separa los fallos críticos de las imperfecciones ordinarias. Un único error grave relacionado con la privacidad, la seguridad o los compromisos asumidos puede importar más que una puntuación media alta.
Evalúa casos representativos
Crea un conjunto de prueba fijo con ejemplos normales, ejemplos difíciles, entradas incompletas, casos multilingües cuando corresponda y situaciones en las que la acción correcta sea abstenerse o escalar. Mantén el conjunto de evaluación separado de los ejemplos usados para ajustar la solución.
Registra para cada ejecución el modelo y versión, configuración, instrucciones, fuentes, resultado, decisión del revisor, corrección, latencia y coste de uso.
Mide el proceso completo
| Dimensión | Medida práctica |
|---|---|
| Calidad | Resultados aceptados, errores críticos, afirmaciones sin respaldo, gravedad de los errores y esfuerzo de corrección |
| Tiempo | Tiempo total, incluida la revisión humana y gestión de excepciones |
| Coste | Uso del proveedor, infraestructura, revisión, soporte y mantenimiento |
| Adopción | Uso apropiado por el personal previsto, no el número bruto de accesos |
| Riesgo | Excepciones de privacidad, seguridad y sesgo, acciones dañinas e incumplimientos contractuales |
| Fiabilidad | Variación entre pruebas repetidas, idiomas y casos difíciles |
Mantén visible la revisión humana
Registra con qué frecuencia los revisores aceptan, editan, rechazan o escalan un resultado y cuánto tarda cada acción. Si el proceso depende de un experto que corrige en silencio resultados débiles, el piloto ha trasladado el trabajo en vez de eliminarlo.
Utiliza criterios explícitos de cierre
Detén o aísla el piloto cuando use datos prohibidos, produzca un fallo crítico con consecuencias, eluda la revisión, supere el presupuesto aprobado, no pueda reproducirse o deje de tener una persona responsable. Pausar es un resultado válido cuando primero hay que mejorar el proceso o los datos de origen.
Haz que la recomendación final sea auditable
El informe de cierre debe incluir línea base, conjunto de prueba, resultados, fallos, correcciones, coste completo, riesgos sin resolver y una recomendación con condiciones. Conserva las evidencias de la decisión. «A los usuarios les gustó» y «la demostración funcionó» son observaciones, no criterios de aceptación para producción.
