El primer proyecto de automatización con IA debería resolver una tarea frecuente, con un resultado fácil de comprobar y un error que puedas corregir. Clasificar solicitudes o preparar borradores para revisión permite aprender cómo funciona el sistema dentro de un proceso real.
Piensa en un equipo que recibe peticiones por correo y copia sus datos a una herramienta de gestión. Antes de elegir un modelo, conviene entender qué lee la persona, qué información necesita y qué hace cuando falta algo. Ese recorrido permite separar lo que se puede automatizar de las decisiones que necesitan criterio y contexto.
Elige una tarea que puedas describir
«Queremos incorporar IA» todavía no define un proyecto. «Queremos extraer el producto, la cantidad y la fecha solicitada de los correos de pedidos» sí describe una entrada y una salida. Puedes reunir ejemplos, acordar qué significa acertar y comparar el resultado con el trabajo actual.
Empieza con quien realiza la tarea cada día. Pídele que enseñe varios casos recientes, incluidos los que dieron problemas. Observa dónde consulta información, cuánto tiempo dedica a corregirla y qué excepciones requieren hablar con otra persona. El proceso documentado suele necesitar más detalle que el diagrama inicial.
- Frecuencia: la tarea se repite lo suficiente para justificar una prueba.
- Entrada disponible: puedes acceder a ejemplos representativos y utilizarlos en el entorno acordado.
- Resultado verificable: alguien puede explicar por qué una respuesta es correcta o incorrecta.
- Responsable definido: hay una persona que resolverá las excepciones y revisará el piloto.
- Alcance acotado: puedes probar una parte del proceso sin cambiar todos los sistemas.
Tres candidatos para una primera prueba
Puedes estudiar la clasificación de solicitudes por departamento, la extracción de campos de documentos o la preparación de respuestas a partir de una base de conocimiento. Son candidatos, no garantías de ahorro: la calidad de los datos y el trabajo de revisión pueden cambiar por completo su utilidad.
Decide qué parte necesita IA
Si una regla fija resuelve una tarea, resulta más sencillo mantenerla como regla. Por ejemplo, comprobar que una fecha tiene el formato correcto o que un identificador existe en el catálogo. Reserva la evaluación de un modelo para pasos en los que haya que interpretar lenguaje, variaciones de formato o contexto.
En su guía sobre agentes y flujos de trabajo, Anthropic distingue los recorridos predefinidos de los sistemas en los que el modelo decide sus propios pasos. También recomienda aumentar la complejidad cuando mejora el resultado. Esa distinción ayuda a concretar qué autonomía necesita cada proyecto.
Para el ejemplo de los pedidos, proponemos un flujo delimitado: recibir un correo, extraer campos, contrastar el producto con el catálogo y presentar un borrador. Un servicio convencional puede encargarse de las comprobaciones y del registro; el modelo interpreta el mensaje. Así puedes localizar qué parte falla y corregirla por separado.
El valor de una automatización se comprueba en el trabajo que deja resuelto y en el esfuerzo que exige revisarlo.
Prepara ejemplos y define qué es un acierto
Reúne una muestra que incluya entradas habituales y casos difíciles. En una extracción de pedidos, guarda ejemplos con productos ambiguos, cambios de fecha, archivos adjuntos y cantidades incompletas. Usa datos sintéticos o anonimizados cuando los originales no sean necesarios para la prueba.
Para cada ejemplo, anota el resultado esperado. Si el cliente escribe «lo mismo que la última vez», decide qué debería pasar cuando el sistema no tiene acceso al pedido anterior. Una salida válida puede ser pedir revisión, en lugar de rellenar campos con una suposición.
Separa la preparación de la evaluación
Utiliza un grupo de ejemplos para ajustar las instrucciones y otro para comprobar el comportamiento después. Si solo pruebas con los mensajes que has usado para preparar el sistema, te faltará información sobre cómo responde a entradas nuevas. Conserva también casos que hayan provocado errores para revisarlos tras cada cambio.
- Define los campos obligatorios y el formato de la salida.
- Anota qué información puede obtenerse de fuentes autorizadas.
- Especifica qué hacer cuando faltan datos o hay contradicciones.
- Clasifica los errores según su impacto: una etiqueta equivocada no tiene el mismo coste que una cantidad incorrecta.
- Acuerda quién revisa los resultados y registra las correcciones.
Diseña la revisión humana dentro del flujo
En el piloto de pedidos, la persona revisora debería ver el mensaje original junto al borrador, los campos extraídos y las advertencias. Añadir un botón de aprobación aporta poco si obliga a buscar la evidencia en otra aplicación. El diseño de esa pantalla forma parte del trabajo de automatización.
Nuestra recomendación para esta primera prueba es mantener la creación definitiva del pedido detrás de una aprobación. El modelo propone datos; el sistema aplica validaciones; una persona confirma. Podrás estudiar más autonomía cuando tengas resultados suficientes y hayas definido qué errores son aceptables en ese proceso.
El marco de gestión de riesgos de IA del NIST plantea incorporar la evaluación y la gestión del riesgo a lo largo del uso de los sistemas. Como aplicación práctica al piloto, documenta qué puede hacer, quién responde por él y cuándo debe detenerse o escalar una incidencia.
Define también permisos, conservación de datos y accesos antes de conectar herramientas. Un piloto de lectura y propuesta puede funcionar sin credenciales capaces de modificar todo el ERP. El trabajo de desarrollo de aplicaciones a medida puede cubrir esa integración y la interfaz de revisión cuando las herramientas disponibles no encajan.
Mide el ahorro después de revisar
Compara el tiempo completo del proceso: preparación, ejecución, revisión y correcciones. Un borrador instantáneo puede aportar poco si comprobarlo exige releer todo el expediente. Mide además cuántos casos terminan bien, cuáles se derivan a revisión y qué errores se repiten.
Ejemplo ilustrativo: si una tarea requiere ocho minutos y el nuevo flujo consume uno de preparación, tres de revisión y uno de corrección media, el ahorro sería de tres minutos por caso. Es una cuenta hipotética para explicar el método; habría que medir los tiempos y su variación en tu equipo.
- Tiempo neto por caso: incluye la supervisión y las correcciones.
- Calidad: distingue resultados correctos, incompletos y errores con impacto.
- Coste operativo: suma consumo del modelo, herramientas e infraestructura.
- Mantenimiento: registra el esfuerzo de actualizar instrucciones, catálogos e integraciones.
- Uso real: observa si el equipo utiliza el flujo o vuelve al procedimiento anterior.
Acordad los criterios de continuidad antes de empezar. Podrían incluir una reducción medible de tiempo y la ausencia de errores críticos en el conjunto evaluado. Superar una prueba no demuestra que nunca habrá fallos; sirve para decidir el siguiente paso con más información.
De la prueba al trabajo diario
Organiza un primer ciclo con entregables claros. Como propuesta de planificación, dedica una fase a entender la tarea, otra a preparar ejemplos y otra a probar el flujo con revisión. La duración dependerá de los accesos, las integraciones y la disponibilidad de las personas que conocen el proceso.
- Documenta el proceso actual y elige una única tarea.
- Prepara la muestra, los resultados esperados y las reglas de revisión.
- Prueba el sistema sin ejecutar cambios definitivos en las herramientas de negocio.
- Compara calidad, tiempo y coste con el procedimiento anterior.
- Decide si ampliar, corregir o descartar la solución, dejando constancia de los motivos.
Antes de llevarlo al día a día, asigna el mantenimiento, prepara una vuelta al proceso manual y define cómo se registrarán las incidencias. Revisa de nuevo el comportamiento cuando cambien las instrucciones, el modelo o las fuentes de información. La responsabilidad no termina al cerrar la demostración.
Si quieres concretar una primera prueba, el servicio de IA y automatización es el punto de partida para valorar tareas, datos e integración. Trae un ejemplo del trabajo que hoy haces a mano: podemos hablar sobre tu proceso y definir qué tendría que demostrar el piloto para merecer la pena.
Fuentes y referencias
Preguntas frecuentes
¿Necesito un agente autónomo para automatizar una tarea?
Depende de las decisiones que deba tomar el sistema. Para extraer datos y preparar un borrador puede bastar un flujo con pasos definidos. Estudia la autonomía cuando el proceso necesite elegir acciones de forma dinámica y puedas evaluar sus resultados, permisos y condiciones de parada.¿Cuántos ejemplos hacen falta para empezar?
No hay una cantidad única que sirva para todos los procesos. Importa cubrir las variantes habituales y las excepciones relevantes. Empieza con una muestra que puedas revisar con el equipo, reserva casos para evaluar y amplíala cuando aparezcan errores o situaciones que no habías contemplado.¿Cómo sé si la automatización merece la pena?
Compara la calidad y el coste completo con el trabajo actual. Cuenta el tiempo de preparación, revisión y corrección, además del consumo de herramientas y el mantenimiento. La decisión debería apoyarse en medidas del piloto y en criterios acordados previamente con quien se responsabiliza del proceso.