El framework de 5 fases para implementar IA en una empresa B2B

En los últimos años hemos pasado por suficientes proyectos de IA como para reconocer un patrón claro. Los que funcionan siguen una secuencia. Los que fallan se la saltan, normalmente al principio, y no la recuperan después. Vale la pena explicar las cinco fases con concreción, qué entrega cada una y qué errores la acechan, porque ese conocimiento ahorra meses cuando se aplica antes y no después.

Fase 1: diagnosticar

La primera fase no construye nada. Sirve para entender. Se entrevistan los responsables de las áreas relevantes, se mapean los procesos críticos, se mide cuánto tiempo consume cada tarea y se identifican los puntos donde la repetición o el cuello de botella son más visibles. El entregable es un mapa de oportunidades con esfuerzo estimado e impacto esperado para cada una.

Suena simple. Lo es. Y aun así es la fase que más se salta. La razón habitual es que el comité que aprueba el presupuesto ya tiene una idea de lo que quiere, y tratar el diagnóstico como algo serio se siente como demorar el proyecto. La consecuencia es que se construye la solución equivocada, con mucha disciplina técnica, sobre el problema equivocado.

Una buena fase de diagnóstico dura entre dos y cuatro semanas. Termina con una lista priorizada, no con una visión grandiosa. La trampa más cara es saltársela.

Fase 2: priorizar

Con el mapa en la mano, hay que elegir por dónde empezar. Esta fase parece obvia y casi nunca lo es. La tentación natural es empezar por lo más importante. Suele ser una mala idea. Lo más importante normalmente es lo más complejo, con más actores implicados, más datos sensibles y mayor riesgo de error visible. Empezar ahí es maximizar las probabilidades de que el primer proyecto fracase y de que el siguiente nunca llegue.

En los proyectos donde trabajamos, los primeros proyectos exitosos comparten tres rasgos. Tienen alcance acotado y resultado medible en semanas, no en meses. Tienen un patrocinador funcional con tiempo asignado y autoridad real. Y tienen un coste de error contenido, de modo que el aprendizaje compense aunque la primera versión no sea perfecta.

• Buen primer proyecto: clasificación automática de tickets entrantes con revisión humana.
• Mal primer proyecto: agente que envía propuestas comerciales a clientes sin supervisión.
• Buen primer proyecto: redacción asistida de respuestas para soporte interno.
• Mal primer proyecto: rediseño completo del flujo financiero de la empresa.

La trampa de esta fase es la ambición mal calibrada. Se evita teniendo a alguien con experiencia previa en proyectos de IA participando en la decisión, no solo el comité interno.

Fase 3: prototipar

La fase de prototipo es donde se construye una primera versión funcional del sistema, con datos reales, integrada de forma básica y operada por un grupo pequeño de usuarios. El objetivo no es ganar la demo. Es validar que el sistema, en condiciones reales, hace lo que se esperaba.

Aquí la trampa más extendida es construir el prototipo con datos sintéticos o curados a propósito. Funciona. Genera entusiasmo. Y oculta exactamente los problemas que aparecerán en producción. Un buen prototipo trabaja con datos reales, aunque sean limitados, y deja visibles los casos en que el sistema falla, en lugar de esconderlos. Esa visibilidad es lo que hace útil al prototipo.

Un prototipo serio dura entre cuatro y ocho semanas. Termina con un sistema usado por entre cinco y diez personas reales, con métricas de calidad medidas y con una lista clara de lo que hay que mejorar antes de pasar a producción. Si esa lista no existe, el prototipo no se hizo bien.

Fase 4: desplegar

El despliegue es el paso más subestimado. Se asume que es una cuestión de empaquetar el prototipo y darle acceso a más gente. En realidad es una reconstrucción parcial, donde aparecen requisitos que no estaban presentes en la fase anterior: gestión de permisos, observabilidad seria, manejo de errores en producción, formación de los usuarios, integraciones más profundas con los sistemas existentes.

En los proyectos donde trabajamos, esta fase suele costar entre el 40 y el 60 por ciento del esfuerzo total. Quien presupuesta solo el prototipo y deja el despliegue como "una semana al final" termina con un sistema que vive en demos pero que nunca llega a usarse. La diferencia entre un piloto que muere en su entusiasmo inicial y un sistema que se convierte en infraestructura es casi siempre lo que ocurre en esta fase.

• Definir quién es el dueño operativo del sistema antes del despliegue, no después.
• Diseñar la observabilidad como parte del producto, no como un añadido.
• Planificar la formación con el equipo afectado, con tiempo dedicado, no con un email.
• Establecer un canal explícito para que los usuarios reporten resultados raros sin fricción.

Fase 5: operar

La quinta fase es la que decide si todo lo anterior se sostiene. Operar significa que alguien observa el sistema cada semana, decide qué ajustes hacer, gestiona los incidentes, mantiene actualizada la documentación y propone mejoras antes de que la organización las pida. Sin esa función, el sistema empieza a degradarse el primer mes y termina apagado en doce.

Esta es la fase donde la consultoría tradicional se desentiende y donde, en realidad, vive la mayor parte del valor. Operar no es soporte. Es producto vivo. Implica una conversación recurrente entre el equipo técnico y el negocio, decisiones explícitas sobre qué priorizar, y disciplina para no dejar que el sistema entre en la zona gris donde sigue funcionando lo justo para que nadie lo apague pero no lo suficiente como para que la gente lo use con convicción.

En los proyectos donde trabajamos, esta es la fase a la que dedicamos más tiempo, y la que mejor predice si el sistema va a estar vivo y mejorando dos años después. Si el modelo de proveedor que se contrata no cubre esta fase de forma explícita, conviene buscar otro modelo. La operación no es un detalle. Es la diferencia entre una entrega y un activo.

Una idea para llevarse

Las cinco fases no son originales. Aparecen, con nombres distintos, en cualquier libro serio sobre proyectos. La diferencia en IA es que el coste de saltarse alguna se manifiesta tarde, normalmente cuando ya hay mucho dinero gastado y mucha credibilidad comprometida. Quien las respeta, aunque sea de forma ligera y proporcional al tamaño del proyecto, llega a operar con un sistema que aporta. Quien se las salta, llega a una conferencia dos años después contando una historia frustrada. La diferencia rara vez es el modelo, ni el equipo técnico, ni el caso de uso. Es el orden.