Hay una diferencia importante entre dos preguntas que suenan parecidas: "¿cómo ampliamos el volumen de este agente dentro del mismo proceso?" y "¿cómo llevamos lo que funcionó en un departamento al resto de la empresa?". La primera va de crecer en profundidad dentro de un mismo caso de uso, y la tratamos con detalle en cómo escalar la IA una vez que el piloto funciona. Esta segunda pregunta, la de este artículo, va de crecer en anchura: coger un éxito puntual en atención al cliente, por ejemplo, y decidir con criterio si tiene sentido llevar algo parecido a ventas, a operaciones o a RRHH, y en qué orden.
Por qué "funcionó aquí" no significa "funcionará igual allí"
El error más frecuente al querer llevar un piloto exitoso a toda la empresa es asumir que el mismo diseño, replicado sin más, va a funcionar en otro departamento porque "es la misma tecnología". No lo es, porque lo que hizo funcionar el piloto casi nunca fue solo la tecnología: fue una combinación de un proceso bien delimitado, datos accesibles, un equipo receptivo y un problema real que dolía lo suficiente como para justificar el cambio. Esas cuatro condiciones rara vez se repiten idénticas en el siguiente departamento.
Antes de replicar, conviene diseccionar honestamente por qué funcionó el piloto original. Si la respuesta incluye "porque el responsable de ese equipo se implicó desde el primer día" o "porque los datos ya estaban limpios y centralizados", esas condiciones específicas son las que hay que verificar que existen (o construir) en el siguiente departamento, no dar por hecho que estarán ahí.
Cómo elegir el siguiente departamento, no solo el siguiente caso de uso
Con un piloto exitoso en la mano, suele haber presión interna para "llevarlo a todas partes a la vez". Resistir esa tentación y elegir un único siguiente departamento con criterio da mejores resultados que repartir el esfuerzo en tres frentes simultáneos. Los criterios que más pesan a la hora de elegir:
- Similitud del proceso, no del departamento. Un proceso de atención a proveedores en compras puede parecerse más, en estructura, al piloto de atención al cliente que un proceso de análisis financiero en el departamento contable, aunque este último "suene" más cercano por ser también de back-office.
- Disponibilidad y calidad de los datos en ese departamento concreto. Un departamento con procesos aún en papel o repartidos entre hojas de cálculo sueltas necesita un trabajo previo de orden que no tenía el piloto original si este ya partía de sistemas digitalizados.
- Nivel de apertura del equipo, algo que se puede sondear con una conversación honesta antes de comprometer presupuesto: un equipo escéptico o sobrecargado necesita una gestión del cambio distinta a la de un equipo que ya está pidiendo la herramienta.
Qué del piloto original se puede reutilizar y qué no
Hay partes del trabajo hecho en el primer piloto que sí viajan bien a un segundo departamento: la infraestructura técnica de base, el modelo de gobierno y supervisión que ya se validó, la forma de medir el impacto y comunicarlo a dirección, y el aprendizaje sobre qué preguntas hacer a un proveedor. Reconstruir estas piezas desde cero en cada departamento nuevo es un desperdicio de lo aprendido.
Lo que no viaja igual es el diseño concreto del caso de uso: los flujos de conversación, las excepciones del proceso, las integraciones con los sistemas específicos de ese departamento. Tratar esta parte como si fuera "copiar y pegar" el piloto original es la causa más habitual de que la segunda implantación decepcione después de que la primera generase tanto entusiasmo.
El papel de una plataforma común frente a soluciones sueltas por departamento
A medida que crece el número de departamentos con IA en marcha, aparece una decisión de fondo: mantener cada implantación como un proyecto independiente, o construir una base común (infraestructura, políticas de datos, criterios de supervisión) sobre la que cada departamento monta su caso de uso concreto. La segunda opción cuesta más planificarla al principio, pero evita el escenario habitual de empresas con media docena de agentes de IA que no se hablan entre sí, cada uno con su propio criterio de calidad y su propio nivel de riesgo, sin que nadie tenga una vista completa de qué está pasando con la IA en la empresa.
Cómo mantener el impulso sin perder el rigor del piloto
El riesgo de escalar rápido a varios departamentos es diluir el mismo rigor que hizo funcionar el piloto original: menos tiempo de pruebas, menos revisión humana en las primeras semanas, menos disciplina midiendo resultados frente a una línea base. Escalar a toda la empresa no debería significar repetir el piloto a la vez en todas partes con menos cuidado; debería significar aplicar la misma disciplina, departamento a departamento, con el beneficio añadido de la experiencia ya acumulada.
Conclusión
Llevar un piloto de IA que funcionó bien a toda la empresa no es una decisión de "activarlo en todas partes", es una secuencia de decisiones informadas: qué hizo funcionar el piloto original, qué departamento se parece más en sus condiciones reales, qué infraestructura conviene compartir y qué gestión del cambio necesita cada equipo concreto. Las empresas que hacen bien esta expansión llegan a un año vista con varios departamentos usando IA con solidez; las que se precipitan llegan con varios pilotos abandonados y la sensación de que "la IA no terminó de cuajar".
En MG Solutions acompañamos tanto el primer piloto como su expansión ordenada al resto de la empresa. Si tu piloto ha funcionado y quieres decidir con criterio el siguiente paso, reserva una primera reunión y lo planificamos juntos.