Cómo involucrar al equipo en un proyecto de IA

Muchas iniciativas de inteligencia artificial piden la opinión del equipo cuando la herramienta ya está elegida, el proceso ya está dibujado y el piloto casi decidido. En ese momento no se está involucrando a las personas: se les está pidiendo que validen una solución ajena. Si queremos que la IA funcione en el trabajo real, la experiencia operativa tiene que entrar antes.

He visto esta secuencia muchas veces en proyectos de transformación. Un grupo reducido analiza el procedimiento, revisa los datos disponibles y diseña una mejora con toda la lógica del mundo. Después convoca a quienes hacen el trabajo cada día para presentarles el resultado.

Sobre el papel, el proceso está bien. En la operación aparecen las preguntas incómodas: ¿qué ocurre si el camión llega fuera de ventana?, ¿quién comprueba ese pedido cuando faltan datos?, ¿qué prioridad se aplica si coinciden dos incidencias?, ¿quién responde cuando la recomendación automática contradice lo que está sucediendo delante de nosotros?

Esas preguntas no son resistencia al cambio. Son conocimiento del negocio. Y si llegan al final, cualquier corrección será más cara, más lenta y más difícil de aceptar.

El error de pedir validación cuando ya está todo decidido

Hay una diferencia importante entre informar, consultar e involucrar. Informar es explicar qué se va a hacer. Consultar es pedir una opinión. Involucrar significa permitir que la experiencia de las personas modifique el diagnóstico y, por tanto, el diseño de la solución.

Cuando un equipo operativo entra únicamente en la fase de pruebas, sus aportaciones se reciben como excepciones que retrasan el proyecto. Cuando entra en la fase de diagnóstico, esas mismas aportaciones se convierten en requisitos de diseño.

Este matiz cambia mucho. Una herramienta de IA puede producir una respuesta técnicamente correcta y ser operativamente inútil. También puede ahorrar minutos en una tarea y añadir después horas de revisión, coordinación o reparación. El problema no está necesariamente en el modelo. Está en haber definido el trabajo como debería suceder, no como sucede de verdad.

Lo que el procedimiento no cuenta

Un procedimiento describe el recorrido previsto. La experiencia revela qué ocurre cuando ese recorrido se rompe. Ahí suele estar la parte más valiosa para un proyecto de IA.

En operaciones, logística o administración, buena parte del trabajo experto no aparece en un manual. Está en pequeñas decisiones acumuladas: cuándo desconfiar de un dato, a quién llamar antes de confirmar una acción, qué señal anticipa un problema, qué excepción puede esperar y cuál exige intervenir ya.

Ese conocimiento tácito suele concentrarse en cuatro zonas:

Si solo analizamos las tareas repetitivas, encontraremos oportunidades de automatización. Si además estudiamos estas cuatro zonas, podremos diseñar una solución que no se rompa al primer día complicado.

Cómo involucrar al equipo en un proyecto de IA

Involucrar no significa reunir a veinte personas para hacer una tormenta de ideas sobre herramientas. Tampoco consiste en preguntar: «¿Qué os gustaría automatizar?». Una conversación tan abierta suele generar una lista de deseos, no un diagnóstico.

Propongo trabajar sobre una unidad concreta: una decisión, un flujo o una incidencia frecuente. A partir de ahí, el proceso puede organizarse en seis pasos.

1. Elegir una decisión observable

«Mejorar la atención» o «automatizar la logística» son objetivos demasiado amplios. Es mejor comenzar con algo que podamos observar: asignar una incidencia, confirmar una entrega, revisar una desviación o preparar una respuesta interna.

Cuanto más concreta sea la unidad de trabajo, más fácil será identificar qué información utiliza hoy el equipo, qué dudas aparecen y qué resultado debería mejorar.

2. Reunir tres perspectivas

Necesitamos, como mínimo, a quien responde por el proceso, a quien lo ejecuta y a quien entiende los datos, los sistemas o el riesgo. Ninguna de las tres perspectivas sustituye a las demás.

El responsable conoce el objetivo y las consecuencias. La persona que opera conoce los atajos, los fallos y las excepciones. El perfil técnico ayuda a separar lo deseable de lo viable y a detectar restricciones de seguridad, calidad o integración.

3. Dibujar el recorrido estándar y luego romperlo

Primero se representa el caso normal. Después se trabaja deliberadamente sobre situaciones que lo ponen a prueba: datos que faltan, peticiones contradictorias, retrasos, cambios de prioridad, permisos insuficientes o una respuesta que necesita confirmación humana.

Las mejores preguntas no buscan que el equipo describa todas sus tareas. Buscan los momentos en los que deja de seguir el procedimiento porque sabe algo que el procedimiento no sabe.

4. Convertir experiencia en requisitos

La conversación debe terminar en decisiones de diseño. Qué datos son imprescindibles. Qué respuesta puede generar la IA. Qué acciones puede ejecutar. Qué situaciones exigen escalar a una persona. Qué evidencia debe conservarse. Y quién asume la responsabilidad final.

Así evitamos que el conocimiento del equipo quede reducido a notas de una reunión. Se convierte en límites, reglas y pruebas concretas para la solución.

5. Probar con casos reales, incluidos los incómodos

Un piloto no debería evaluarse solo con ejemplos limpios. Tiene que incluir casos habituales, casos límite y casos en los que dos profesionales razonables tomarían decisiones distintas.

El desacuerdo no es un fallo del piloto. Es información útil. Nos ayuda a saber si falta una regla, si la decisión depende de contexto o si la IA debe limitarse a preparar información sin ejecutar ninguna acción.

6. Diseñar el cambio de trabajo

La implantación no termina cuando la herramienta responde bien. Hay que definir qué tarea desaparece, cuál cambia, quién supervisa, cómo se registra un error y qué aprendizaje necesita el equipo.

Este enfoque conecta con una idea que desarrollo al hablar de cómo aplicar IA al negocio sin caer en humo tecnológico: la tecnología solo importa cuando mejora una forma concreta de trabajar.

Un ejemplo hipotético en logística

Imaginemos un sistema que recomienda cómo reorganizar las entregas cuando aparece un retraso. El procedimiento indica las ventanas horarias, la disponibilidad de vehículos y la prioridad de los pedidos. Con esos datos, el sistema propone mover una entrega al final de la jornada.

La recomendación parece impecable. Pero una persona del almacén pregunta quién descargará ese vehículo a esa hora. El sistema ha optimizado el transporte sin considerar la capacidad del muelle, el turno disponible o el tiempo necesario para cerrar la recepción.

El problema aparente era encontrar una nueva hora de entrega. La pregunta decisiva revela que la decisión afecta a una red de recursos. A partir de ahí, el diseño cambia: incorpora capacidad de descarga, reglas de escalado y confirmación humana cuando la propuesta desplaza trabajo fuera de la ventana operativa.

No hace falta atribuir al sistema una inteligencia extraordinaria ni culpar al equipo por no haber explicado antes cada detalle. Hace falta analizar la decisión completa. Esa mirada de extremo a extremo también es esencial para mejorar una supply chain de verdad.

Cinco errores que conviene evitar

La alternativa es sencilla de explicar y exigente de ejecutar: entender primero el trabajo, decidir después el papel de la IA y medir al final el efecto sobre el negocio. Para profundizar en esa última parte, puede ser útil revisar cómo usar la IA para tomar mejores decisiones empresariales.

Qué debería producir el diagnóstico

En SmartWorkIA no planteamos estas conversaciones como una actividad de participación sin consecuencias. El diagnóstico debe producir entregables útiles para decidir si conviene avanzar y cómo hacerlo.

Con estos elementos, la dirección puede comparar oportunidades y riesgos sin depender de una demostración llamativa. También puede decidir no automatizar todavía, simplificar primero el proceso o limitar la IA a una función de apoyo.

Escuchar antes no significa renunciar a dirigir

Involucrar al equipo no convierte cada decisión en una votación. La dirección sigue siendo responsable de priorizar, asignar recursos y aceptar determinados riesgos. Lo que cambia es la calidad de la información con la que decide.

Además, la participación temprana mejora la adopción por una razón muy práctica: las personas reconocen en la solución los problemas que realmente viven. No se les pide que confíen en una promesa abstracta. Pueden ver qué tarea cambia, qué límite se ha respetado y qué ocurre cuando la herramienta no sabe responder.

La confianza no nace de asegurar que la IA acertará siempre. Nace de diseñar qué hacemos cuando no acierta, quién puede intervenir y cómo aprendemos del error.

Por eso, antes de preguntar qué agente, modelo o plataforma necesita una empresa, prefiero formular otra pregunta: ¿qué saben las personas que sostienen este proceso y todavía no hemos incorporado al diseño?

La experiencia no debe entrar al final para corregir la solución. Debe entrar al principio para ayudar a decidir si esa solución merece existir.