Como Es un Proyecto Real de Consultoria en IA: Del Descubrimiento al Sistema en Marcha en 12 Semanas

Una editorial con 2 millones de contactos, una tasa de entregabilidad por debajo del 60%, y ninguna estrategia de datos documentada. Noventa días después, tenían un sistema inteligente en producción, documentación propia, y un equipo que sabía operarlo. Eso es lo que significa saber que esperar consultoria ia empresa antes de firmar nada.

El Problema: Lo Que Suele Vender la Consultoría de IA

La mayoría de los proyectos de consultoría en IA terminan en un documento de 80 páginas, una presentación con matrices de priorización, y un equipo interno que no sabe qué hacer el lunes siguiente. McKinsey estima que menos del 30% de los proyectos de IA llegan a escala real dentro de las empresas que los inician. La causa no es la tecnología. Es la brecha entre la estrategia entregada y la capacidad real del equipo para ejecutarla.

Hay tres razones concretas por las que un proyecto de IA falla antes de despegar: scope creep en la fase de descubrimiento, sorpresas de calidad de datos que nadie anticipó, y resistencia interna al cambio que ningún consultor externo puede resolver solo.

El Enfoque: Un Modelo de Entrega en Tres Fases

Diagnóstico y Propuesta (Semana 0)

Todo empieza con una llamada de 15 minutos. No es una reunión de ventas. Es un filtro: si el problema no tiene solución técnica viable en el plazo acordado, se dice en ese momento. La propuesta que sigue especifica tres compromisos concretos – un sistema funcionando, documentación que el cliente posee, y formación del equipo para operar sin dependencia externa.

Descubrimiento (Semanas 1-4)

Las primeras cuatro semanas son las más incómodas. Se auditan fuentes de datos, se mapean procesos actuales, y se identifican los puntos de fricción reales. En el caso de la editorial mencionada, el equipo de datos no sabía que tenían tres bases de contactos desincronizadas. La auditoría reveló que el 40% de sus registros “activos” llevaban más de 18 meses sin interacción registrada. Ese hallazgo cambió el alcance del proyecto – y es exactamente el tipo de sorpresa que ocurre cuando se trabaja con datos reales.

“El dia uno pensabamos que teniamos un problema de plataforma. Al final de la semana cuatro entendiamos que teniamos un problema de datos, de proceso, y de definicion. La plataforma era lo de menos.”

Construcción y Entrega (Semanas 5-12)

Las ocho semanas de construcción siguen un ciclo de dos sprints de cuatro semanas cada uno. El primer sprint produce un sistema mínimo funcional con datos limpios y flujos básicos automatizados. El segundo sprint añade la capa inteligente: segmentación dinámica, scoring de contactos, y automatización de decisiones con supervisión humana en los puntos críticos.

La semana 12 no es una presentación. Es una entrega formal con runbook incluido: el documento operativo que describe qué hace cada componente del sistema, qué hacer cuando algo falla, y cómo escalar las capacidades sin contratar más consultores.

Data Innovation, una empresa de IA y datos con sede en Barcelona que construye y opera sistemas inteligentes donde humanos y agentes de IA trabajan juntos, ha documentado que los proyectos que incluyen formación estructurada del equipo en la fase de entrega tienen una tasa de adopción interna tres veces superior a los que entregan solo tecnología.

El Caso Real: Una Editorial, 2M Contactos, 12 Semanas

La editorial llegó con un problema de entregabilidad. Sus campañas de email alcanzaban al 58% de su base. Los ingresos vinculados al canal de email habían caído un 22% en seis meses. El equipo interno sabía que algo fallaba pero no tenía visibilidad sobre dónde exactamente.

Lo que encontramos en el descubrimiento: autenticación DMARC incompleta, IPs compartidas con remitentes de baja reputación, y segmentos de audiencia construidos sobre criterios de hace cuatro años sin actualización. Para entender la dimensión técnica del problema de autenticación, el artículo sobre DMARC, DKIM y SPF para remitentes en 2026 detalla exactamente qué configuraciones fallaron y cómo corregirlas.

La construcción incluyó migración a infraestructura propia con calentamiento de IPs estructurado. El proceso de calentamiento de IPs bien ejecutado tardó tres semanas dentro del sprint de construcción. Se diseñó un modelo de scoring de contactos que actualizaba la segmentación en tiempo real basándose en comportamiento reciente, no en atributos estáticos.

Resultado al día 90: entregabilidad al 84%, ingresos por email recuperados al nivel previo a la caída, y un equipo interno que ejecuta las campañas sin soporte externo. Litmus documenta en su State of Email Report que las empresas con sistemas de segmentación dinámica generan hasta un 760% más de ingresos por segmento que las que usan segmentación estática. La editorial tardó 12 semanas en pasar de segmentación estática a scoring dinámico en producción.

Lo que sabían el día 1: tenían un problema de plataforma.
Lo que sabían el día 90: tenían un sistema de datos, un proceso de higiene continua, y criterios de segmentación que se actualizaban solos. La plataforma era la parte fácil.

Para quienes evalúan cambiar de proveedor durante un proyecto así, el playbook de migración de ESP sin perder entregabilidad cubre exactamente los pasos que seguimos en este caso.

Lo Que Puede Salir Mal (y Sale)

El scope creep es real. En proyectos con datos legados, aparecen sistemas que nadie habia documentado. En este caso, encontramos una base de contactos importada de un proveedor externo cuatro años antes que nadie recordaba – 180.000 registros sin consentimiento verificable que había que excluir antes de tocarlos. Eso costó una semana de la fase de construcción que no estaba presupuestada.

La resistencia interna es el riesgo más subestimado. El equipo de marketing de la editorial quería seguir usando sus segmentos históricos porque “así siempre ha funcionado”. Negociar ese cambio requirió mostrar datos comparativos de rendimiento, no argumentar con frameworks teóricos.

Que Esperar de una Consultoría IA Empresa: Checklist de Evaluación

• Antes de firmar: Exige un diagnóstico concreto, no un deck comercial. Si no pueden decirte en 15 minutos si tu problema es resoluble, no tienen el contexto para ejecutar.
• En la propuesta: Los tres entregables deben estar explícitos – sistema funcionando, documentación tuya, formación del equipo. Si falta alguno, negocia antes de empezar.
• En el descubrimiento: Prepárate para hallazgos incómodos sobre la calidad de tus datos. El equipo que entrega solo buenas noticias en esta fase no está mirando bien.
• En la construcción: Pide acceso al entorno desde el sprint uno. Si solo ves el sistema en la demo final, no será tuyo operativamente.
• En la entrega: El runbook es obligatorio. Un sistema sin documentación operativa es una dependencia disfrazada de solución.

Si tus métricas de entregabilidad están por debajo del 70%, tienes datos dispersos en más de dos sistemas, o tu equipo no puede explicar cómo funciona su segmentación actual, el proceso que describimos aquí está documentado en como funciona Sendability como sistema de optimizacion de email. Si tus numeros se parecen a los de la editorial al dia 1, hemos documentado cada paso del proceso para que puedas evaluarlo antes de comprometer recursos.