Reconstruir el proceso que existe hoy
Antes de discutir tecnología, sigue una ejecución real e identifica entradas, decisiones, salidas y excepciones. Compara el procedimiento escrito con lo que hace el equipo cuando falta información o aparece una urgencia. Esa diferencia muestra el conocimiento que hay que explicitar y ayuda a elegir una tarea suficientemente delimitada para empezar a trabajar.
Alguien puede elegir una versión porque reconoce el nombre del cliente, aunque el procedimiento solo diga «abrir la propuesta». También puede omitir un campo porque sabe que esa oferta ya no lo utiliza. Sin explicarlo, la siguiente persona tendrá que descubrir de nuevo qué diferencia importa.
Un procedimiento útil reúne objetivo, pasos y aprendizajes para que el equipo pueda continuar. Al prepararlo para automatizar, añade qué información consulta cada decisión y cómo se confirma. «Elegir la oferta adecuada» necesita convertirse en preguntas concretas sobre la necesidad, el alcance y las condiciones disponibles.
No conviertas inmediatamente todas las decisiones observadas en reglas. Algunas pueden proceder de una costumbre personal, una excepción antigua o información que ha cambiado. Confirma con el responsable del proceso qué criterios siguen vigentes antes de fijarlos dentro de una ejecución que se repetirá.
Comprobar datos y capacidad de evaluación
La preparación depende de la información disponible y de que alguien sepa reconocer una respuesta adecuada. Reúne ejemplos, comprueba su vigencia e identifica quién puede validar la salida. Si todavía no existen los datos o los criterios, convierte esa ausencia en una tarea concreta de preparación antes de esperar que la IA resuelva la indefinición.
Considera un piloto que transforma una transcripción autorizada de una reunión en un resumen para el equipo. En el ejemplo de la reunión, necesitas una fuente autorizada y suficientemente completa. Quien evalúa debe conocer las decisiones tomadas y detectar cuándo una sugerencia se confunde con un compromiso. Sin esa referencia, una lista bien escrita puede parecer útil aunque asigne responsabilidades que nadie acordó.
Elige algunos ejemplos representativos del trabajo habitual. Incluye un caso sencillo y otro con información menos organizada. La prueba debe mostrar cómo responde el sistema a la variación que encuentra el equipo, en vez de depender solo del ejemplo más fácil de preparar.
Comprueba también qué puede utilizarse en el experimento. Los datos de clientes, mensajes internos y documentos de terceros exigen atención a los accesos y al contexto. Para explorar el funcionamiento inicial, datos ficticios identificados como tales pueden permitir probar la estructura antes de introducir información real autorizada.
La disponibilidad de datos incluye poder encontrarlos y entenderlos. Si el primer esfuerzo consiste en reconstruir archivos dispersos durante semanas, esa preparación forma parte del alcance. Es preferible reconocerlo pronto y decidir si otro piloto permitiría aprender con menos dependencias.
Definir qué exige una decisión humana
Clasifica las acciones previstas por sus efectos, la posibilidad de corregir un error y la información necesaria para decidir. Un diagnóstico útil explica dónde la IA solo prepara trabajo y dónde puede ejecutar. Quienes usan el proceso deben comprender esa frontera, incluido qué ocurre cuando una situación queda fuera del alcance acordado.
En el apoyo comercial, el asistente puede preparar una síntesis, el comercial revisar la solicitud y un responsable aprobar una condición especial. Esa distribución debe coincidir con el funcionamiento real. Configurar la herramienta no concede automáticamente autoridad para modificar las reglas comerciales de la empresa.
Definir quién aprueba cada parte de un proyecto de automatización evita vacíos. Si un resultado llega sin indicar que todavía está pendiente de revisión, alguien puede asumir una validación que nunca ocurrió. El estado de la entrega debe acompañar a su contenido.
Reserva tiempo para la revisión inicial. Dar acceso a la herramienta sin ajustar la carga puede llevar a aceptar respuestas demasiado rápido o a abandonar la prueba por falta de disponibilidad. Necesitas espacio para observar, corregir instrucciones y comentar casos que parecen convincentes pero no sirven a la tarea.
Asignar responsabilidad sobre la operación
Una empresa está mejor preparada cuando alguien se responsabiliza de seguir la utilidad del proceso, sus fallos y los cambios necesarios. Esa persona necesita acceso a la información y capacidad para pedir correcciones o detener la ejecución. El diagnóstico debe hacer visibles estas condiciones, en vez de asumir que la responsabilidad pertenece a la herramienta.
Un técnico puede confirmar que el flujo se ejecutó sin errores y, aun así, no saber si la respuesta enviada al cliente tenía sentido. La persona responsable del proceso necesita conocer el resultado previsto, las reglas vigentes y las situaciones que merecen atención. La evaluación incluye el contenido y las consecuencias de la ejecución.
En un ejemplo hipotético de preparación de propuestas, la persona responsable puede ser quien conoce los servicios, los precios aprobados y los límites de la entrega. Si falla la conexión entre sistemas, esa persona recurre al soporte técnico. Si la propuesta utiliza una condición desactualizada, identifica la regla que necesita revisión.
Definir quién aprueba cada parte de un proyecto ayuda a establecer esta relación. Después de la puesta en marcha, la responsabilidad debe seguir siendo visible, para que el equipo sepa quién decide sin depender de localizar a quien construyó la primera versión.
Elegir un piloto y criterios de continuidad
Cierra el diagnóstico con una tarea delimitada, ejemplos de prueba y una comparación con la forma actual de trabajar. Observa calidad, esfuerzo total y facilidad de corrección, incluida la revisión humana. No asigno una puntuación científica de madurez a esta conversación: busco condiciones concretas para decidir si el piloto debe avanzar, cambiar o esperar.
En el ejemplo elegido, puedes comprobar si se conservaron todas las decisiones, si las tareas identifican correctamente a sus responsables y si quedaron señaladas las dudas. Son criterios más útiles que preguntar solo si el texto parece bueno. La evaluación queda ligada a la función del resumen.
Registra las correcciones brevemente y distingue los errores de contenido de las preferencias de presentación. Una frase larga puede acortarse con facilidad; atribuir una responsabilidad a la persona equivocada exige corregir el sentido. El equipo necesita entender qué errores limitan el uso.
Observa también el recorrido de corrección. Si la persona puede corregir el borrador y avanzar, existe una forma sencilla de recuperarse. Si debe volver al origen y rehacer todo el trabajo, la ventaja puede desaparecer, aunque la mayoría de las frases estén bien escritas.
Mantén la comparación con el proceso anterior proporcionada al experimento. Pocos casos ayudan a identificar problemas y decidir la siguiente prueba, pero no justifican convertir una impresión inicial en una previsión segura para toda la empresa. Registra lo observado y lo que falta probar.
Prepara la solicitud con un ejemplo real de entrada y salida, frecuencia de la tarea, herramientas utilizadas, responsable y dificultad actual. El contexto general está en IA para empresarios; el diseño del trabajo continúa en automatización de procesos. Si buscas apoyo de implementación, presenta el contexto al equipo mediante el formulario de contacto. Si la prioridad es elegir entre oportunidades del negocio, indica esa decisión en la solicitud de mentoría individual.
