Proyectos que nunca se aprobaban y que ahora tienen ROI en semanas

Toda organización tiene una lista. Proyectos que todo el mundo sabe que aportarían valor, pero que nunca pasan del PowerPoint al presupuesto. La IA ha cambiado el denominador de esa ecuación y esos proyectos ya no tienen excusa. 

No es un problema de ideas. En casi cualquier organización con más de cincuenta personas, existe una lista no escrita de proyectos que llevan años en espera. Automatizaciones que ahorrarían horas cada semana. Herramientas internas que el equipo pide y nunca llegan. Procesos manuales que nadie ha tenido el coraje de calcular en euros reales. 

La razón por la que no se ejecutan nunca es la misma: el coste de hacerlos no justificaba el retorno. Un desarrollo a medida requería meses de trabajo y un presupuesto que el consejo no estaba dispuesto a aprobar sin certeza de retorno a 18 o 24 meses. 

Ese cálculo ya no es válido. La inteligencia artificial ha comprimido drásticamente tanto el coste como el tiempo de validación. Y eso cambia qué proyectos merecen estar en el backlog — y cuáles merecen ejecutarse ya. 

Por qué los proyectos «buenos» no se aprobaban 

La parálisis no era irracionalidad. Era una respuesta lógica a una estructura de costes concreta. Durante años, desarrollar software a medida tenía tres características que lo hacían difícil de justificar para proyectos de impacto moderado: 

• Coste fijo, valor variable. El coste de desarrollo era alto y fijo, independiente del valor del proyecto. Un proceso que ahorraba 10 horas semanales costaba casi lo mismo que uno que ahorraba 100. 
• Payback a largo plazo. El período de recuperación se calculaba entre 18 y 24 meses. Demasiado riesgo para proyectos que no eran estratégicos de primer nivel, y demasiado para la mayoría de los consejos de administración. 
• El ciclo que se perpetúa. Año tras año, los mismos proyectos aparecían en la lista de «prioridades para el próximo ejercicio». Y año tras año, volvían al cajón. El coste de oportunidad acumulado nunca se contabilizaba. 

El verdadero problema no era el coste de los proyectos no ejecutados. Era el coste acumulado de mantener procesos ineficientes durante años, multiplicado por el número de personas involucradas. Ese número rara vez aparecía en el análisis de presupuesto. 

¿Qué ha cambiado exactamente?

La irrupción de modelos de lenguaje avanzados y herramientas de desarrollo asistido por IA no es un cambio incremental. Es una ruptura en la curva de coste-retorno que afecta directamente a la ecuación de aprobación de proyectos. 

Pero la cifra más importante no es el ahorro en desarrollo. Es el cambio en el riesgo percibido. Antes, aprobar un proyecto significaba comprometer todo el presupuesto antes de saber si funcionaría. Ahora, se puede construir un piloto funcional en dos semanas, medir el impacto real, y decidir si escalar — con datos, no con suposiciones. 

El coste de equivocarse se ha reducido tanto que la pregunta ya no es si tiene ROI, sino por qué no se está ejecutando.

Esto no significa que todos los proyectos tengan sentido ahora. Significa que el umbral de rentabilidad necesaria para aprobar un proyecto ha bajado de forma estructural, y que muchos proyectos que antes no pasaban ese umbral, ahora sí lo hacen. 

Tres tipos de proyectos a reconsiderar ahora

No todos los proyectos del cajón son igual de recuperables. Hay tres categorías que concentran la mayor parte del potencial de retorno rápido:

1. Automatizaciones internas de alto consumo humano. Tareas repetitivas que consumían horas de personas valiosas pero que no justificaban un proyecto formal. Consolidación de informes, clasificación de solicitudes, generación de respuestas estándar, extracción de datos de documentos. Individualmente, cada tarea parece menor. Sumadas, representan decenas de horas semanales de trabajo de alta cualificación destinadas a trabajo de baja cualificación. 
2. Herramientas propias que IT nunca tenía tiempo de construir. Aplicaciones internas que el equipo lleva años pidiendo: buscadores sobre documentación interna, asistentes de onboarding, paneles de estado en tiempo real. Proyectos que siempre perdían frente a las prioridades urgentes de mantenimiento. Con IA asistiendo en el desarrollo, el tiempo necesario para construirlas se ha reducido a una fracción de lo que requería antes. 
3. Procesos «que siempre se han hecho a mano». Workflows que nadie ha cuestionado porque siempre han funcionado así. Revisión manual de contratos, categorización de tickets de soporte, preparación de briefings para reuniones. El coste nunca se ha calculado en términos reales porque nunca ha habido una alternativa económicamente viable. Ahora la hay. 

¿Cómo evaluar si un proyecto paralizado ahora tiene ROI?

No hace falta un business case de cuarenta páginas. El análisis inicial puede hacerse en menos de una hora con tres preguntas concretas.

Señales de alerta: cuándo ejecutar sin más análisis

→ ¿Tu equipo dedica más de un día a la semana a una tarea repetitiva? Probablemente tiene ROI positivo con IA.

→ ¿El proceso implica extraer, clasificar o resumir información de documentos o sistemas? Seguro que el potencial de automatización es muy alto.

→ ¿La respuesta a «¿por qué se hace así?» es «siempre se ha hecho así»? Calcula el coste real antes de asumir que no hay alternativa.

→ Si el proyecto lleva más de dos años en el backlog, el coste acumulado de no haberlo ejecutado ya supera casi con certeza el coste de desarrollo actual.

La recomendación no es aprobar todos los proyectos del cajón de golpe. Es revisar la lista con la nueva estructura de costes en mente, identificar los dos o tres proyectos con mayor ratio impacto/esfuerzo, y lanzar un piloto de dos semanas. El piloto da la respuesta real — no una estimación, sino datos de uso, velocidad de adopción y ahorro medible.

El riesgo de equivocarse es ahora suficientemente bajo como para que el coste de análisis prolongado supere al coste de simplemente probar.

Preguntas frecuentes 

¿Qué diferencia hay entre automatización tradicional y automatización con IA? 

La automatización tradicional (RPA, scripts) requiere que el proceso sea perfectamente estructurado y predecible: si el formato cambia, la automatización falla. La automatización con IA puede manejar variabilidad, lenguaje natural, documentos no estructurados e incluso tomar decisiones contextuales. Esto amplía enormemente el tipo de tareas automatizables — y elimina la fricción de mantenimiento que hacía que muchas automatizaciones RPA resultaran más costosas de mantener que el propio proceso manual. 

¿Cuánto cuesta realmente un piloto de dos semanas? 

Depende del alcance, pero los rangos han cambiado de forma sustancial. Proyectos que hace dos años requerían entre 80.000 y 150.000 euros de desarrollo inicial hoy pueden validarse con pilotos funcionales entre 8.000 y 25.000 euros. Ese es el punto de inflexión: el piloto ya no requiere comprometer el presupuesto completo. Si el piloto no demuestra ROI suficiente, el coste de haberlo probado es un orden de magnitud inferior al coste de haberlo desarrollado completamente sin validar antes. 

¿Qué pasa si el proyecto requiere integración con sistemas legacy? 

La integración con sistemas legacy sigue siendo el factor que más dilata los proyectos — eso no ha cambiado. Sin embargo, hay una distinción importante: muchos proyectos del cajón no requieren integración profunda en los sistemas de registro. Pueden funcionar sobre outputs de esos sistemas (archivos, exportaciones, correos) sin necesidad de acceso API. Para los que sí requieren integración, el enfoque de piloto primero con datos de muestra sigue siendo válido para validar el impacto antes de acometer la integración completa. 

¿Cómo convenzo al consejo de aprobar un proyecto cuando el ROI no está garantizado? 

El cambio de marco es clave: no se está pidiendo aprobar el proyecto, se está pidiendo aprobar el piloto. La diferencia no es semántica — es presupuestaria. Un piloto de dos semanas requiere una aprobación de gasto pequeño, con un criterio de éxito medible y una decisión de continuidad explícita al finalizar. Ese formato reduce la fricción de aprobación drásticamente. Si el piloto demuestra el ROI esperado, la aprobación del proyecto completo ya llega con datos reales, no con proyecciones en PowerPoint. 

¿Cómo se prioriza qué proyectos del backlog revisar primero? 

La matriz más simple es cruzar dos variables: frecuencia de la tarea (cuántas veces ocurre por semana) y grado de estructuración (qué tan predecible y estandarizado es el proceso). Por un lado, los proyectos con alta frecuencia y proceso razonablemente estructurado tienen el mayor potencial de ROI rápido y menor complejidad de implementación. Por otro, los de alta frecuencia, pero muy poco estructurados requieren más inversión en diseño. Los de baja frecuencia raramente justifican el esfuerzo, salvo que el impacto por ocurrencia sea excepcionalmente alto. 

¿El equipo de IT necesita capacidades nuevas para ejecutar estos proyectos? 

Depende del punto de partida. Los proyectos de menor complejidad — automatizaciones sobre flujos de documentos o integraciones vía API con modelos de lenguaje — pueden ejecutarse con un equipo de desarrollo intermedio que tenga acceso a los modelos adecuados. Los proyectos más complejos, especialmente los que requieren fine-tuning, RAG sobre bases de conocimiento propias o integración con infraestructura de datos, sí requieren perfiles especializados. La recomendación práctica es empezar con proyectos que el equipo actual pueda ejecutar, y usar esos primeros resultados para justificar la inversión en capacidades adicionales. 

¿Tienes proyectos en el cajón que podrían tener ROI con IA? Cuéntanos el caso. En una llamada de 30 minutos te ayudamos a identificar cuáles tienen más potencial y cómo validarlos. 

Te lo explicamos con detalle en nuestro webinar ‘Desarrolla software hasta 10x con IA’. Accede aquí.