Un proyecto de IA parado es más complejo de evaluar que un proyecto de software clásico. La tecnología cambia rápido. Lo que se construyó hace 18 meses puede estar técnicamente obsoleto aunque funcione. El mercado se ha movido. Lo que era diferenciador ya es estándar.
Decidir si retomar o cancelar requiere análisis técnico, de mercado y de oportunidad, todos cruzados. Este artículo describe cómo se hace esa evaluación sin emocionalidad (la inversión ya está hecha; lo que importa ahora es la decisión hacia adelante).
Las 4 dimensiones a evaluar
Dimensión 1 — Viabilidad técnica de lo construido
Tres preguntas concretas.
¿El modelo base (LLM, fine-tuning, embeddings) sigue siendo competitivo? En 2026 hay modelos significativamente mejores que los de 2024. Un proyecto construido sobre un modelo viejo puede estar obsoleto sin que el código del proyecto en sí esté mal.
¿La arquitectura es portable a modelos nuevos? Un proyecto bien diseñado abstrae el modelo IA detrás de interfaces y puede sustituirse sin reescribir todo. Un proyecto mal diseñado tiene el modelo acoplado al código y migrar exige reescritura.
¿Las integraciones funcionan? Las APIs externas a las que el proyecto se conectaba pueden haber cambiado, encarecido o desaparecido. Verificar cada integración antes de asumir que el código sirve.
Dimensión 2 — Vigencia del problema que resolvía
Una pregunta única: ¿el problema operativo que motivó el proyecto sigue siendo prioridad de la empresa?
Si la respuesta es no (cambio de negocio, problema resuelto por otra vía, ya no es estratégico), el proyecto no debe retomarse aunque técnicamente sea viable. El coste de oportunidad de seguir invirtiendo es alto.
Si la respuesta es sí, la siguiente pregunta es: ¿la solución del proyecto sigue siendo la mejor disponible? En 18 meses pueden haber aparecido SaaS que cubren ese caso al 80% por un precio mucho menor.
Dimensión 3 — Estado del mercado de soluciones alternativas
Específico para IA en 2026: el mercado de herramientas y modelos avanza muy rápido. Una solución a medida que tenía sentido en 2024 puede competir mal contra SaaS especializados aparecidos en 2025-2026.
Ejercicio: listar las 5 alternativas SaaS que cubrirían el caso de uso del proyecto parado. Si alguna de ellas resuelve el 80%+ del problema por menos coste total, retomar a medida puede no tener sentido.
Dimensión 4 — Capacidad operativa de la empresa para mantener lo recuperado
Pregunta crítica que muchos saltan. Asumiendo que se rescata el proyecto, ¿quién lo mantiene después?
Si la empresa no tiene equipo técnico interno y va a depender de un proveedor externo recurrente, hay que sumar el coste operativo recurrente. Si no tiene presupuesto para ese coste recurrente, el proyecto vuelve a pararse en 6-12 meses por desatención.
Los 3 criterios de decisión
Cruzando las 4 dimensiones, hay tres rutas posibles.
Ruta A — Rescatar y modernizar
Cuando la viabilidad técnica es buena (arquitectura portable, integraciones recuperables), la vigencia del problema sigue, y la empresa tiene cómo mantener lo recuperado.
Acción: rescate con modernización selectiva. Migrar el modelo IA a versión actual, refactorizar componentes obsoletos, mantener el grueso del código. Las 6 fases de un rescate ordenado aplican también aquí.
Coste típico: 30-50% del coste original del proyecto. Plazo: 8-16 semanas.
Ruta B — Reescribir desde cero con la experiencia
Cuando la viabilidad técnica es mala (arquitectura no portable, integraciones imposibles de recuperar) pero el problema sigue vigente y la empresa quiere resolverlo.
Acción: reescritura usando la documentación y el aprendizaje del proyecto anterior como punto de partida. No se aprovecha código pero sí decisiones de diseño que ya se validaron.
Coste típico: 70-90% del coste original. Plazo: 12-20 semanas. Mejor que empezar a ciegas porque la empresa ya tiene claridad sobre qué quiere.
Ruta C — Cancelar y migrar a SaaS o solución alternativa
Cuando aparecieron SaaS competitivos que cubren el caso, o el problema ya no es estratégico, o no hay capacidad de mantener custom.
Acción: documentar el proyecto cancelado (qué se hizo, qué se aprendió), exportar datos relevantes, migrar el caso de uso a SaaS si sigue vigente.
Coste de cancelación: bajo (10-20% del coste original en una transición ordenada).
El error de «ya invertimos mucho, no podemos parar»
La falacia de coste hundido aplicada a proyectos IA cuesta más que la inversión original. Un proyecto que ya consumió 150.000€ no merece retomarse «porque ya invertimos 150.000€». Merece retomarse si los próximos 100.000€ tienen mejor retorno que invertirlos en otra cosa.
La decisión es siempre hacia adelante. Lo invertido es coste perdido o coste recuperable según el caso, no argumento para seguir.
Cómo se documenta una decisión de cancelación bien hecha
Si la conclusión es cancelar, hay que hacerlo bien para no tirar todo el aprendizaje.
Documento 1 — Aprendizaje técnico. Qué se intentó construir, qué arquitectura, qué decisiones de diseño se tomaron y por qué. Documento de 10-15 páginas que evita que un proyecto futuro repita los mismos errores.
Documento 2 — Aprendizaje de negocio. Qué hipótesis sobre el problema operativo se validaron y cuáles se desmintieron. Esto vale para futuras decisiones estratégicas.
Documento 3 — Inventario de activos recuperables. Datos generados, modelos entrenados, herramientas o componentes que sí podrían reutilizarse en otros proyectos.
Cancelar bien convierte un proyecto fracasado en aprendizaje organizativo. Cancelar mal lo deja en pérdida pura.
La conversación inicial sobre un proyecto IA parado
En Nexus, cuando una empresa contacta por un proyecto IA parado, la primera conversación cubre estas 4 dimensiones en 60-90 minutos. No es comercial; es diagnóstico preliminar para decidir si tiene sentido contratar el rescate completo o si la respuesta honesta es «cancelar y rehacer en otra plataforma».
Esta honestidad de alcance es deliberada. Aceptar rescates donde la viabilidad es baja perjudica al cliente y a nuestra reputación. Decir «no rescates esto» cuando la evaluación lo indica también es trabajo profesional, aunque no lo facturemos.
Si la conclusión del diagnóstico preliminar es que el rescate sí encaja, propuesta cerrada en 5 días laborables con plan de fases, plazo y precio. Bajo el NDA desde el primer contacto.
Sigue leyendo
- Heredar un stack técnico tras una M&A: guía de supervivencia para el nuevo CTO
- Migración Inacabada de ERP/CRM: Cómo Retomarla Sin Romper el Negocio Mientras Opera
- Por qué fracasan los proyectos de IA en empresas españolas (y cómo rescatarlos)
- Guía de rescate de proyectos
- Rescate de proyectos parados
- Software a medida con IA