Un sistema prepara en segundos una tarea que antes llevaba varios minutos. Parece una mejora evidente. Pero alguien debe revisar el resultado, corregir lo que falta y resolver los casos que el sistema no entiende. Hasta medir ese trabajo, todavía no conocemos el ahorro operativo.

Para evaluar un piloto de IA conviene comparar el recorrido completo antes y después. El resultado debe permitir decidir si se amplía, se corrige o se detiene.

Definir qué cuenta como una tarea terminada

«Documento generado» y «documento aceptado» son estados distintos. En una propuesta comercial, terminar podría significar que contiene la información necesaria, utiliza las condiciones vigentes y ha pasado la revisión del responsable. Escribe esa definición antes de medir.

Registra también el tipo de caso. Comparar diez peticiones sencillas asistidas por IA con diez peticiones complejas del proceso anterior produciría una conclusión engañosa.

Medir cinco cosas en los mismos casos

MedidaQué permite comprobar
Tiempo de trabajo humanoPreparación, revisión, corrección y seguimiento.
Tiempo hasta resolverLo que espera quien necesita el resultado, incluidas las colas.
Aceptación sin rehacerCuántos resultados cumplen el criterio acordado a la primera.
Errores y excepcionesQué falla, con qué frecuencia y qué consecuencias tiene.
Uso realQué parte del trabajo elegible pasa efectivamente por el sistema.

Un ejemplo numérico, expresamente hipotético

Supongamos 100 solicitudes comparables al mes. Antes del piloto, cada una requiere 12 minutos de trabajo humano: 1.200 minutos en total. Con el sistema, la revisión inicial requiere 5 minutos por solicitud y 20 de ellas necesitan 8 minutos adicionales de corrección.

El trabajo humano del nuevo recorrido sería 100 × 5 + 20 × 8 = 660 minutos. La diferencia son 540 minutos, es decir, 9 horas. Si mantener y revisar el sistema durante ese mes requiere otras 2 horas, quedan 7 horas de capacidad recuperada en ese ejemplo.

Son cifras inventadas para explicar el cálculo, no resultados de NorteIA. Tampoco equivalen automáticamente a dinero ahorrado: hay que saber qué se hace con esa capacidad y qué costes de operación e implantación tiene el sistema.

Acordar la decisión antes de ver la demostración

Define qué fallos son inaceptables y qué nivel de revisión puedes asumir. Un error que obliga a corregir una etiqueta no tiene la misma consecuencia que enviar información al destinatario equivocado.

La decisión puede ser ampliar un único tipo de solicitud y mantener otros fuera. También puede ser simplificar el proceso antes de automatizarlo. Un piloto que demuestra que una idea no compensa puede evitar una inversión mayor, siempre que produzca evidencia útil y no solo impresiones.

Guardar una referencia que permita comparar después

Conserva la definición de tarea terminada, el periodo observado, la selección de casos, el número de excepciones y las versiones utilizadas. Si más adelante cambia el modelo, la plantilla o el catálogo, repite la comparación con casos equivalentes.

El cuadro de evaluación debe caber en una conversación con quien hace el trabajo. Si solo entiende las métricas el proveedor técnico, falta conexión con la operación de la empresa. En nuestro recorrido de consultoría y desarrollo, los criterios de aceptación forman parte del alcance del proyecto.