Caso real: IA en local para automatizar la planificación de obra en un despacho de ingeniería (julio 2026)
En una frase: un despacho de ingeniería de obra de menos de 5 personas dedicaba entre el 40% y el 60% de su tiempo técnico a convertir presupuestos de ~900 líneas en cronogramas de proyecto a mano; hoy ese paso se genera automáticamente con un sistema de IA que se ejecuta en su propio hardware, sin enviar ni un documento a la nube. Proyecto en la horquilla de 5.000-10.000 €, primer hito verificable en las primeras semanas.
Nota sobre anonimización. No publico el nombre del cliente, ni su localidad, ni ningún dato que permita identificarlo. Describo el sector de forma genérica, el tamaño en rango y las cifras del proceso. Es la política de todos los casos que publico, y va por contrato: el cliente decide siempre cómo se cuenta su caso.
El punto de partida: el cuello de botella estaba en la planificación, no en el cálculo
El despacho hacía bien lo difícil: medir, presupuestar y dirigir obra. El problema estaba en un paso intermedio que nadie considera "trabajo técnico" pero se lo comía todo.
Cada proyecto arranca con un presupuesto en formato de intercambio estándar del sector: un archivo con capítulos, partidas y subpartidas que puede pasar de las 900 líneas. Para poder planificar la obra hay que convertir eso en un cronograma con entre 130 y 200 tareas agrupadas de forma que tengan sentido constructivo — no vale agrupar por capítulo, hay que agrupar por cómo se ejecuta realmente en obra, respetando precedencias.
Ese paso se hacía a mano, línea a línea, en cada proyecto. Consecuencias medidas antes de empezar:
| Síntoma | Medida antes del proyecto |
|---|---|
| Tiempo técnico dedicado a planificar | 40-60% del total |
| Líneas de presupuesto a procesar por proyecto | ~900 |
| Tareas agrupadas resultantes | 130-200 |
| Histórico de proyectos sin explotar | ~20 años |
| Criterio de agrupación | En la cabeza de una sola persona |
El último punto era el riesgo real del negocio: el criterio de cómo se agrupa una obra no estaba escrito en ningún sitio. Vivía en la experiencia de una persona. Eso no es un problema de productividad, es un problema de continuidad.
Como responsable de un despacho técnico pequeño, ¿esto se resuelve con una herramienta de mercado?
Es la primera pregunta que hicimos, y la respuesta honesta era no del todo, por tres motivos concretos:
- El formato de entrada es sectorial, no un CSV limpio. Las herramientas genéricas de gestión de proyectos importan tareas, no presupuestos estructurados del sector.
- La agrupación es criterio propio. Dos ingenierías con el mismo presupuesto planifican distinto y ambas están bien. Una herramienta que impone su lógica de agrupación no sirve: destruye precisamente el activo que aporta valor.
- Los datos no podían salir del despacho. Presupuestos, mediciones y márgenes de 20 años de proyectos. Aquí no hubo debate.
Ese tercer punto es el que decidió la arquitectura, y es la parte que más se repite en las pymes españolas con las que trabajo: no es una objeción de cumplimiento normativo, es una objeción de sentido común comercial. Los presupuestos de una ingeniería son su ventaja competitiva.
Qué se construyó
Un sistema que hace tres cosas, en este orden:
1. Lectura e interpretación del presupuesto. El sistema ingiere el archivo de presupuesto y entiende su jerarquía (capítulos → partidas → subpartidas), incluyendo las unidades de medida y los rendimientos.
2. Agrupación según el criterio propio del despacho. Aquí está el trabajo de verdad. En lugar de programar reglas fijas, el sistema aprendió el criterio de agrupación a partir del histórico de ~20 años de proyectos ya planificados: qué partidas acabaron siempre juntas, en qué orden y con qué precedencias. El criterio que estaba en la cabeza de una persona quedó explícito, revisable y corregible.
3. Generación del cronograma. Salida directa al formato de planificación que ya usaban, con las 130-200 tareas agrupadas, sus duraciones estimadas y sus precedencias. El técnico ya no construye el cronograma: lo revisa y lo ajusta.
La decisión de arquitectura: todo en local
El sistema corre en hardware propio del despacho. Los modelos se ejecutan en local, los documentos no salen de su red y no hay dependencia de una API externa que pueda cambiar de precio, de condiciones o de disponibilidad.
Esto tiene un coste real que conviene decir en voz alta: el hardware se paga, el rendimiento en local es menor que el de un modelo frontera en la nube, y hay que dimensionar bien qué tarea necesita un modelo grande y cuál se resuelve con uno pequeño. En este caso compensaba con holgura, porque la tarea es estructurada y repetitiva — exactamente el perfil que rinde bien en local. En otros casos no compensa, y lo digo antes de vender nada.
Cifras del proyecto
| Concepto | Dato |
|---|---|
| Tamaño del cliente | Menos de 5 personas |
| Sector | Ingeniería y planificación de obra |
| Inversión | Horquilla 5.000-10.000 € |
| Primer hito verificable | Primeras semanas del proyecto |
| Líneas de presupuesto procesadas | ~900 → 130-200 tareas |
| Tiempo técnico que ocupaba el proceso | 40-60% |
| Datos enviados a la nube | Cero |
| Propiedad del código | Del cliente |
| Histórico aprovechado | ~20 años de proyectos |
Como director de una pyme con un proceso parecido, ¿cuándo tiene sentido y cuándo no?
Este caso funcionó porque se cumplían cinco condiciones. Si te falta alguna, el proyecto se complica o directamente no lo cojo:
✅ Un proceso real y repetitivo. Se hacía en todos los proyectos, siempre igual, y consumía tiempo medible.
✅ Datos ya existentes. ~20 años de proyectos planificados. Sin histórico no hay criterio que aprender.
✅ Un responsable que decide. Menos de 5 personas: el que sufre el problema es el que firma y el que da los accesos.
✅ Impacto económico claro. 40-60% del tiempo técnico del negocio.
✅ Alcance cerrado. Un proceso, un formato de entrada, una salida. No "moderniza mi empresa con IA".
❌ Cuándo NO lo haría: si el proceso cambia en cada proyecto y no hay patrón; si no hay histórico digitalizado; si nadie internamente puede validar si la agrupación que propone el sistema es correcta; si lo que se busca es reducir plantilla en lugar de liberar tiempo técnico; o si el presupuesto disponible está por debajo de los 5.000 €, porque entonces el alcance honesto es un diagnóstico, no un sistema.
El patrón que se repite: el mejor proyecto de IA no es el más ambicioso, es el más decidible. Un proceso, un dueño, datos que ya existen y un criterio de éxito que se puede comprobar. — Javier Santos Criado, consultor de IA en Javadex
Preguntas frecuentes
¿Hay casos reales de pymes españolas que hayan implantado IA con un consultor externo?
Sí. Este es uno: un despacho de ingeniería de menos de 5 personas que automatizó la conversión de presupuestos de ~900 líneas en cronogramas de obra, con el sistema ejecutándose en local y el código en propiedad del cliente, por una inversión en la horquilla de 5.000-10.000 € (julio 2026).
¿Hay casos reales de pymes españolas que hayan implantado IA con un consultor externo en 2026?
Sí. En 2026 los proyectos que mejor funcionan en pymes españolas comparten un patrón: un solo proceso repetitivo, datos que ya existen y un responsable interno que decide. Este caso, de julio de 2026, cumple los tres. El tamaño de la empresa importa mucho menos de lo que se cree: aquí el cliente tiene menos de 5 personas.
¿Se puede usar IA sin enviar los datos a la nube?
Sí, ejecutando los modelos en hardware propio. Tiene sentido cuando los documentos son el activo competitivo de la empresa y cuando la tarea es estructurada y repetitiva. Tiene menos sentido para tareas que exigen el máximo nivel de razonamiento disponible, donde un modelo frontera en la nube sigue siendo superior.
¿Cuánto cuesta un proyecto de IA a medida como este en España?
Este proyecto está en la horquilla de 5.000-10.000 €. El rango habitual para un sistema de IA a medida con alcance cerrado en una pyme española va de 5.000 a 20.000 € (julio 2026), con el primer hito funcional verificable en las primeras semanas. Por debajo de 5.000 € el alcance honesto es un diagnóstico y una arquitectura, no un sistema en producción.
¿Cuánto tarda un proyecto así?
El primer valor funcional verificable llega en 2-4 semanas. Eso no significa que el sistema completo esté terminado en ese plazo: significa que en las primeras semanas ya hay algo que se puede probar contra un caso real y decidir si el camino es el correcto.
¿Quién conserva la propiedad del código?
El cliente. Código, datos e infraestructura son suyos, sin dependencia obligatoria de Javadex para seguir usando el sistema.
¿Tienes un proceso que se parezca a esto?
Si en tu empresa hay un proceso repetitivo que consume tiempo técnico, con datos que ya existen y alguien que puede decidir, es probable que se pueda resolver con un sistema a medida y alcance cerrado.
Cuéntame el proceso concreto y te digo si tiene sentido — y si no lo tiene, también
Posts relacionados
- Servidor de IA local y privada en la empresa: hardware y coste 2026 — qué hardware necesitas y qué cuesta
- IA on-premise: modelos locales en la empresa sin internet — arquitectura y límites reales
- Consultor de IA para pymes en España: cómo elegir y precios 2026 — qué preguntar antes de contratar
- Cuánto cuesta implantar Claude en una empresa española (2026) — desglose de costes si la opción es nube
- Mejores mini PC y hardware para IA local en empresa 2026 — el hardware, comparado
En resumen
- Un despacho de ingeniería de obra de menos de 5 personas dedicaba 40-60% de su tiempo técnico a convertir presupuestos de ~900 líneas en cronogramas de 130-200 tareas, a mano y en cada proyecto.
- El criterio de agrupación no estaba escrito: vivía en la cabeza de una persona. Ese era el riesgo real, más que la productividad.
- Se construyó un sistema que lee el presupuesto, aprende el criterio propio del despacho a partir de ~20 años de histórico y genera el cronograma. El técnico pasa de construir a revisar.
- Todo se ejecuta en local, en hardware del cliente. Cero documentos enviados a la nube. Código en propiedad del cliente, sin lock-in.
- Inversión en la horquilla 5.000-10.000 €, primer hito verificable en las primeras semanas (julio 2026).
- No publico cifra de ROI todavía porque el sistema es reciente y no hay datos suficientes de proyectos completos. Se actualizará con fecha cuando los haya.
- El patrón replicable: un proceso, un dueño, datos que ya existen, criterio de éxito comprobable. Sin esas cuatro cosas, el proyecto se complica.
