Cómo elegir el primer proceso que merece la pena automatizar con IA

“Automatizar atención al cliente” es demasiado amplio para una primera prueba. “Preparar la ficha de una solicitud a partir de su correo, para que una persona la revise y asigne” sí tiene un principio, un final y un resultado que comparar.

Describe qué entra, qué debe salir y quién utiliza esa salida. Si el equipo todavía discute qué significa resolver bien una solicitud, toca aclararlo antes de automatizar. Una respuesta que suena convincente no resuelve esa discrepancia.

Después distingue qué parte necesita IA. Trasladar datos de un formulario con campos fijos puede resolverse con una integración y unas reglas. Interpretar correos redactados de formas distintas puede justificar una prueba con IA. El resto del circuito puede seguir siendo previsible: comprobar campos, evitar duplicados y pedir aprobación.

Esta preferencia por la sencillez también aparece en la guía de Anthropic: recomienda aumentar la complejidad solo cuando haga falta y distingue los flujos predefinidos de los agentes que deciden cómo ejecutar una tarea. Es orientación de un proveedor, no una garantía de resultado. Building effective agents, Anthropic.

Tampoco confundas adopción con mejora del trabajo. El análisis europeo que OpenAI publicó el 14 de octubre de 2026 describe actividad de sus clientes y mide, entre otras cosas, tokens de salida: las unidades de texto que genera el modelo. Ese indicador no demuestra cuánto ahorrará tu empresa. The EU’s next chapter in AI is agentic, OpenAI.

Reúne tres tareas que el equipo repita y completa la tabla para cada una. Es una propuesta de selección práctica, no una escala validada ni una fórmula universal. Cada respuesta necesita una evidencia: un registro de trabajo, ejemplos de entradas o la persona que asumirá la revisión.

No compenses un error incontrolable con mucho volumen. La posibilidad de detectar fallos y comprobar el resultado funciona como condición de entrada. Entre las tareas que la cumplen, da prioridad a la que permita una prueba útil con menos dependencias y mayor carga recuperable.

Por ejemplo, reunir cifras ya estructuradas para un informe puede ser una buena automatización convencional. Preparar fichas desde correos variables puede encajar con IA y revisión. Autorizar devoluciones y ejecutarlas añade consecuencias económicas y excepciones: como primera prueba, conviene limitarlo a preparar información para quien decide.

Imagina un equipo que recibe solicitudes de soporte por correo. Una persona lee cada mensaje, identifica el asunto, copia las referencias y prepara una ficha en la herramienta de trabajo. Todo el caso y sus cifras son didácticos; no describen a un cliente ni resultados de BEOS.

Para este escenario usamos un mes de cuatro semanas, con 400 solicitudes y seis minutos de trabajo activo por solicitud. Son 40 horas. La situación inicial debe medirse de verdad antes de cualquier implantación: incluye las correcciones habituales y registra por separado la espera hasta que alguien atiende cada caso.

Qué hará la IA y dónde termina su intervención

La IA prepara un borrador con el tipo de solicitud, un resumen, las referencias que aparecen en el correo y una propuesta de equipo destinatario. La persona revisa el original y la ficha antes de guardarla y asignarla. En este piloto todas las solicitudes pasan por revisión; la IA no responde al cliente ni ejecuta cambios en su cuenta.

Los campos ausentes quedan señalados como pendientes. Los mensajes ambiguos, incompletos o fuera de alcance vuelven al circuito manual. Ese desvío forma parte del proceso: hay que contar el tiempo que lleva detectar la excepción y resolverla. Tampoco basta con que el modelo se declare seguro de su respuesta para saltarse una revisión.

Cómo ponerlo a prueba

1. Prepara ejemplos del trabajo real. Incluye solicitudes habituales, mensajes incompletos, duplicados y casos que deban escalarse. Usa solo los datos necesarios en un entorno autorizado. Reserva casos que no hayas utilizado para ajustar las instrucciones.
2. Comprueba el resultado antes de operar. La persona que conoce el trabajo contrasta cada campo con el correo. Un resumen fluido que inventa una referencia es un fallo.
3. Prueba durante dos semanas de actividad normal. En el escenario son 200 solicitudes. Mantén la revisión de todas y el circuito manual disponible. Si solo has probado casos sencillos, la conclusión solo sirve para esos casos.
4. Registra también lo que falla. Anota las entradas recibidas, las fichas correctas, las corregidas, las excepciones, las solicitudes omitidas o duplicadas y el tiempo de cada intervención. El total recibido debe cuadrar con el total atendido o pendiente.

Asigna una persona responsable de la prueba y otra que pueda cubrirla. Deja escrito quién detiene el flujo, cómo se recuperan las solicitudes pendientes y quién actualiza las instrucciones cuando cambia el proceso.

El marco voluntario AI RMF del NIST contempla definir la supervisión humana, medir en condiciones similares a las de uso y prever seguimiento y recuperación. Estos principios respaldan la necesidad de evaluar el proceso completo; no establecen una duración ni un número universal de casos para el piloto. AI RMF Core, NIST: MAP 3.5, MEASURE 2.3 y MANAGE 4.1.

Supongamos que en esas dos semanas 150 solicitudes se resuelven revisando y, cuando hace falta, corrigiendo el borrador, con una media de dos minutos de trabajo humano. Las otras 50 necesitan seis minutos por el circuito manual, incluido el tiempo dedicado a detectar y desviar la excepción. Mantener y supervisar el sistema consume otras dos horas.

El trabajo recurrente suma 12 horas: cinco de revisión, cinco de excepciones y dos de mantenimiento. Frente a las 20 horas que requeriría ese volumen con el método inicial, quedarían ocho horas disponibles. Si el volumen y la mezcla de casos se mantienen, la proyección al mes de cuatro semanas sería esta:

El ahorro de trabajo recurrente sería del 40 %: 16 horas sobre las 40 iniciales. Si preparar, conectar, probar y formar al equipo consume además 12 horas, el primer ciclo completo de cuatro semanas deja cuatro horas netas recuperadas. Esas 12 horas iniciales se cuentan una vez; las cuatro de mantenimiento, en cada ciclo.

Recuperar horas no significa ahorrar automáticamente ese dinero en caja. Hay que decidir a qué se dedicará la capacidad disponible y sumar los gastos reales de licencias, uso del modelo, integraciones y soporte externo. La cuenta anterior solo mide trabajo humano; no es una previsión de rentabilidad.

La prueba también puede salir mal. Si revisar cada borrador exige cuatro minutos en lugar de dos, el trabajo recurrente sube a 34 horas y solo recuperas seis, un 15 %. La rapidez con la que la IA genera la ficha no cambia esa cuenta.

Acuerda las condiciones de éxito antes de ver los resultados. Así evitas cambiar la definición de “funciona” para dar por bueno un piloto que ha costado montar. Para este caso didáctico proponemos cuatro condiciones:

• Tiempo: reducir al menos un 25 % el trabajo humano recurrente total, incluyendo revisión, excepciones y mantenimiento.
• Calidad: no aumentar la proporción de fichas finales que necesitan rehacerse respecto a la situación manual medida. Cuenta aparte los borradores corregidos antes de guardarlos, porque también consumen capacidad.
• Servicio: no empeorar la espera hasta la asignación ni acumular solicitudes sin atender. Una ficha preparada antes sirve de poco si luego pasa horas esperando revisión.
• Control: cero acciones externas sin aprobación y todas las solicitudes localizadas. Un envío indebido o una solicitud perdida obliga a detener el flujo y resolver la causa.

El 25 % es un umbral elegido para este ejemplo, no un estándar del sector. Tu empresa debe fijarlo según la carga que necesita recuperar y el esfuerzo que está dispuesta a mantener. Una prueba sin incidentes tampoco demuestra que el sistema no pueda fallar después.

Con el escenario de dos minutos de revisión, la condición de tiempo se cumple. Faltaría comprobar calidad, servicio y control antes de ampliar. Con cuatro minutos de revisión, el 15 % queda por debajo del umbral: toca reducir el alcance, mejorar la preparación de las entradas o cerrar la prueba si corregirla no compensa.

Si continúas, conserva la medición durante un ciclo completo de trabajo. Revisa especialmente los cambios de volumen, tipo de solicitud, herramienta o modelo. La autorización para seguir con un circuito supervisado no justifica retirar la revisión humana.

Elige tres tareas con la persona que las realiza y completa la matriz. Para la mejor candidata, redacta una página con la entrada, la salida esperada, el volumen, el tiempo actual, los errores que no se pueden aceptar, el responsable y la condición de continuidad.

Si faltan tiempos o ejemplos, empieza por recogerlos. Si están disponibles, ya tienes un encargo concreto para quien prepare el piloto. La primera automatización debe permitirte decidir con datos si merece quedarse en el trabajo diario.