Una tarea puede parecer fácil de automatizar porque sus pasos se repiten y la herramienta consigue reproducirlos en una prueba. Aun así, yo intentaría mirar una situación menos cómoda antes de darle permiso: qué ocurriría si uno de esos pasos saliera mal durante el trabajo real y nadie lo viera enseguida.
Preparar una respuesta equivocada, enviarla a un cliente y cambiar un registro a partir de ella tienen consecuencias diferentes. Aunque las tres acciones formen parte del mismo proceso, no necesitan necesariamente la misma autonomía. Separarlas permite probar una mejora con más claridad y entender qué responsabilidad conserva quien dirige el servicio.
Preguntar cómo descubriríamos y corregiríamos un fallo
La primera pregunta que me haría es cómo nos enteraríamos del error. Puede haber una comprobación fiable, una persona que revise el resultado o una señal que advierta de una situación extraña. Si ninguna existe, un fallo pequeño puede repetirse durante bastante tiempo antes de que alguien lo relacione con el sistema.
Después pensaría cómo se corrige. Recuperar una versión anterior de un documento puede ser sencillo; deshacer una comunicación que ya ha leído un cliente es otra cosa. Aunque podamos rectificar el contenido, la persona ya ha organizado una expectativa o ha dedicado tiempo a seguir una instrucción equivocada.
La tercera pregunta es qué consecuencias habría mientras detectamos y corregimos el problema. Un resumen que omite una incidencia parece menos activo que un sistema que modifica datos, pero también puede retrasar una decisión necesaria. Me interesa valorar para qué se usa el resultado, además de lo que hace técnicamente la herramienta.
Usaría las tres respuestas juntas. Si el fallo se detecta pronto, se corrige con facilidad y tiene un efecto limitado, puede ser un buen lugar para empezar a probar. Si no sabemos contestar alguna de esas preguntas, todavía necesitamos entender mejor el proceso antes de ampliar los permisos.
Separar el trabajo de preparación de las acciones posteriores
Pensemos en un servicio que recibe solicitudes. Un sistema puede reunirlas, ordenar la información y señalar cuáles parecen incompletas. Después podría preparar una propuesta para distribuirlas. Hasta ahí está ayudando a observar y preparar trabajo que alguien puede contrastar.
Cambiar el estado de una solicitud, enviar una respuesta o darla por cerrada son acciones adicionales. Yo las revisaría por separado con quienes conocen la actividad. Necesitamos entender qué condiciones deben cumplirse, quién tiene la atribución y qué ocurre con las excepciones, tanto en una empresa como en un servicio público.
En el primer periodo podría dejar que el sistema propusiera una clasificación y compararla con la revisión habitual. Eso permitiría descubrir si confunde un dato ausente con uno incorrecto, o si trata igual situaciones que requieren respuestas distintas. El conocimiento de quienes atienden esas solicitudes resulta esencial para interpretar los errores.
También tendría en cuenta el volumen. Preparar y mantener una automatización compleja para una tarea que aparece muy pocas veces puede no compensar. A veces una instrucción mejor, una regla sencilla o apoyo especializado resuelven la necesidad con menos trabajo de supervisión.
Ampliar el margen cuando las pruebas lo justifiquen
Antes de permitir más acciones, probaría casos normales y situaciones que complican el encargo: información ausente, dos fuentes que se contradicen o un dato que deja de estar disponible. Querría observar si el sistema reconoce la dificultad y se detiene cuando debe hacerlo, en lugar de completar el hueco con una respuesta plausible.
Mantendría una forma de revisar lo ocurrido, una persona que reciba las excepciones y un modo claro de parar el proceso. Esa persona necesita tiempo y contexto. Una cola de propuestas que nadie puede examinar con atención no se vuelve fiable únicamente por incluir una aprobación al final.
Después compararía la ayuda obtenida con la supervisión y las correcciones que introduce. Si las dudas se repiten, quizá haga falta mejorar la fuente o reducir el encargo. Si los resultados son consistentes dentro del alcance probado, podremos valorar un margen mayor con información más concreta.
El permiso también debe poder reducirse. Un cambio en la tarea, en los datos o en las consecuencias puede dejar antiguo el acuerdo anterior. Para mí, automatizar incluye cuidar esa revisión: el sistema seguirá siendo útil mientras comprendamos qué hace y podamos responder cuando deja de hacerlo como esperábamos.
Un primer paso
Divide una tarea en acciones concretas, desde preparar información hasta actuar sobre ella. Para cada una, describe un fallo posible, cómo lo detectarías y a quién afectaría. Elige una parte que puedas comprobar bien y pruébala con casos normales y dudosos antes de decidir qué autonomía merece.