Hay una diferencia grande entre comprar una herramienta de IA y tener un socio para implementarla. El proveedor de herramienta te entrega un acceso y una documentación. El socio de implementación entra en tu proceso, entiende cómo trabaja tu gente, decide contigo qué automatizar primero y se queda hasta que el sistema funciona en producción con tus datos y tus casos raros.
La mayoría de las implantaciones que fracasan no lo hacen por la tecnología. Fracasan porque nadie tradujo el problema de negocio a un caso de uso concreto, porque el equipo no supo usar lo que se le entregó o porque el proyecto se dio por terminado el día del despliegue. Este artículo describe cómo debería trabajar un socio de implementación de IA para que eso no pase.
Qué hace un socio de implementación y qué no
Lo que hace:
- Diagnostica antes de proponer. Mapea procesos, mide volúmenes y tiempos reales, y localiza dónde hay trabajo repetitivo suficiente para justificar una automatización.
- Elige el caso de uso. No el más vistoso, sino el que combina alto volumen, reglas razonablemente estables, datos disponibles y un dueño interno dispuesto a implicarse.
- Diseña la solución completa, incluidas las integraciones con los sistemas que ya tienes y el circuito de excepciones.
- Construye, prueba con datos reales y despliega por fases.
- Forma al equipo que va a convivir con el sistema, no solo a quien lo administra.
- Mide y ajusta después, con indicadores acordados desde el principio.
- Documenta y transfiere, de forma que la empresa no quede secuestrada.
Lo que no hace: prometer que la IA resolverá problemas que en realidad son de proceso, de datos sucios o de organización. Si tu maestro de clientes tiene duplicados y tus procedimientos no están escritos, ningún modelo lo arregla. Un buen socio te lo dice en la primera reunión, aunque suponga vender menos ese mes.
¿Cómo se estructura un proyecto de implantación de IA en una empresa?
En cinco fases con puertas de decisión entre ellas, para que la empresa pueda parar en cualquier punto sin haber gastado de más. La primera es el diagnóstico: dos o tres semanas de entrevistas, observación de procesos y medición del punto de partida, que termina con una lista priorizada de casos de uso y una estimación de retorno para cada uno. La segunda es la prueba de concepto sobre un caso acotado, con datos reales de la empresa y criterios de éxito definidos por escrito antes de empezar: no vale "funciona bien", vale "clasifica correctamente el 90 % de los correos entrantes de una muestra de 500". La tercera es el piloto en producción con un grupo reducido de usuarios y un alcance limitado, donde aparecen los casos raros que ninguna prueba en laboratorio detecta. La cuarta es el despliegue y la integración completa, con formación y con el circuito de excepciones ya definido. Y la quinta, la que casi nadie contrata y la que determina el resultado, es la fase de estabilización y mejora: tres a seis meses midiendo, corrigiendo y ampliando cobertura. Un proyecto que termina el día del despliegue es un proyecto a medio hacer.
Un ejemplo concreto: implementación de IA para atención al cliente
Es el caso de uso más demandado y también el que más veces se hace mal, así que sirve bien de ilustración. Una implantación seria sigue este orden:
Primero, leer lo que ya existe
Antes de escribir una sola instrucción, se analizan los últimos miles de conversaciones reales: correos, tickets, chats. De ahí sale la única lista que importa, la de motivos de contacto ordenados por frecuencia. Suele descubrirse que entre seis y diez motivos concentran el 70 % del volumen, y que la mitad de ellos se resuelven con información que la empresa ya tiene estructurada.
Segundo, decidir el alcance por motivo
Para cada motivo se decide una de tres cosas: lo resuelve el agente de principio a fin, lo prepara y lo confirma una persona, o va directo a una persona. Esa tabla es el corazón del proyecto y la firma atención al cliente, no el proveedor.
Tercero, conectar con los datos reales
Un agente que no puede consultar el estado de un pedido, la factura o el histórico del cliente solo puede dar respuestas genéricas, y las respuestas genéricas irritan más que el silencio. La integración con el ERP, el CRM o la plataforma de comercio es lo que separa un asistente útil de un buscador de preguntas frecuentes.
Cuarto, definir el traspaso a persona
Cuándo escala, con qué contexto y a quién. Un buen traspaso incluye el resumen de lo hablado, para que el cliente no tenga que repetir. Un mal traspaso es la principal causa de que los usuarios acaben odiando el sistema.
Quinto, medir lo correcto
No el número de conversaciones atendidas, sino la tasa de resolución sin intervención humana, el tiempo de primera respuesta, la satisfacción medida después de la conversación y, sobre todo, el porcentaje de escalados que llegan con contexto completo.
¿Qué tiene que aportar la empresa y qué el socio?
Es la conversación que evita el 80 % de los conflictos, y conviene tenerla antes de firmar. La empresa aporta tres cosas que nadie puede aportar por ella: acceso a los datos y a los sistemas, una persona interna con autoridad para tomar decisiones sobre el proceso, y tiempo real de las personas que conocen el trabajo. Un proyecto en el que el responsable interno solo puede dedicar dos horas al mes se retrasa siempre, y no es culpa del proveedor. El socio aporta el método, el criterio técnico sobre qué es viable, la construcción, la integración, la formación y la responsabilidad sobre el resultado acordado. Y hay una cuarta responsabilidad compartida que suele quedar sin dueño: la gestión del cambio. Explicar al equipo para qué se automatiza, qué pasa con su trabajo y qué se espera de ellos. Cuando esa conversación no se tiene, el sistema técnicamente funciona y nadie lo usa, que es la forma más cara de fracasar.
Señales de un buen socio y señales de alarma
Buenas señales: te hace preguntas incómodas sobre tus procesos antes de hablar de tecnología; te propone empezar pequeño; pone por escrito los criterios de éxito; te explica qué no va a funcionar; incluye formación en el alcance; te entrega la documentación y los accesos; y acepta hablar de qué pasa el día que decidas cambiar de proveedor.
Señales de alarma: presupuesto cerrado sin haber visto tus datos; promesas de porcentajes de ahorro concretos antes del diagnóstico; negativa a explicar dónde se procesan tus datos; dependencia total de una plataforma propia sin posibilidad de exportar; formación vendida como extra opcional; y un discurso centrado en el modelo de IA que usa en lugar de en el problema que resuelve.
Cómo se contrata
Los modelos habituales son tres, y cada uno encaja en un momento distinto. Diagnóstico a precio cerrado, que es la forma sensata de empezar sin comprometerse a nada. Proyecto por fases con precio por fase y punto de decisión entre ellas, que es lo más razonable para la construcción. Y una cuota de servicio recurrente para la fase de operación y mejora continua, que cubre monitorización, ajustes y soporte. Desconfía del proyecto único a precio cerrado por todo, porque obliga al proveedor a cerrar alcance en un momento en el que ni tú ni él sabéis aún qué hace falta.
Lo que de verdad decide el resultado
Después de muchos proyectos, el patrón se repite: los que salen bien tienen un dueño interno con nombre y apellidos, un caso de uso aburrido pero de alto volumen, criterios de éxito escritos antes de empezar y una fase de estabilización contratada. Los que salen mal empezaron por el caso de uso más impresionante, sin dueño claro y con la expectativa de que la tecnología se ocuparía del resto.
En MG Solutions trabajamos como socio de implementación: diagnóstico primero, casos de uso priorizados por retorno, construcción por fases con tus datos y tus sistemas, formación del equipo y acompañamiento después del despliegue. Si tienes claro el problema pero no por dónde entrar, esa primera conversación es gratis y sirve para decidir si hay proyecto o no.