La hoja de ruta de tu proyecto de IA, de hoy a 2027 (con o sin bono)

Estado a 22 de septiembre de 2026. El Plan IA360 se anunció el 21 de septiembre. No hay convocatoria del bono empresarial, ni bases reguladoras, ni plazo de solicitud: el plan sitúa un piloto controlado en el primer semestre de 2027 y la convocatoria general antes de que acabe ese año. Nada de lo que sigue es un trámite. Es la hoja de ruta de tu propio proyecto, con esas fechas como referencia, no como calendario a cumplir.

Todavía no hay dónde pedir el bono. Lo que sí tiene, por escrito, es el método que anuncia: diagnóstico previo de madurez, identificación de un caso de uso concreto, formación de los trabajadores, incorporación de la IA a los procesos internos y medición posterior del impacto en productividad. Ese método no depende de ninguna base reguladora para empezar a aplicarse hoy, y es lo mismo que necesita un proyecto de IA que nunca vea un euro de fondos públicos: la diferencia entre un proyecto que sobrevive y uno que se abandona no suele estar en si hubo subvención, sino en si alguien hizo estos cinco pasos en orden. Esta guía no es el calendario del plan (ese está en el documento oficial del Plan IA360): es el calendario de tu proyecto, con los hitos del plan como puntos de referencia.

Tu proyecto, trimestre a trimestre

Antes de gastar nada: lo que ejecutes y pagues antes de que existan bases puede no ser financiable. Muchas ayudas solo cubren lo que se hace después de solicitarlas o de concederlas. Como las bases del IA360 no existen, nadie puede decirte hoy si contará.

Si tu empresa prefiere no esperar y hacer el proyecto con sus propios recursos, puede adelantar el piloto y la puesta en marcha: el trabajo vale lo mismo con bono que sin él. Lo que no conviene es hacerlo dando por hecho que el bono lo reembolsará después.

No hay ninguna obligación de seguir este ritmo exacto (cada empresa tiene su propio calendario interno), pero alinear las fases propias con los hitos que el plan ya ha fijado tiene sentido: si la convocatoria llega según lo previsto, el proyecto propio ya habrá pasado por diagnóstico, piloto y evaluación antes de que exista ningún formulario que rellenar. Y si se retrasa respecto a lo que hoy anticipa el plan (algo que no se puede descartar, porque no hay bases reguladoras todavía), el trabajo hecho no se pierde: un caso de uso evaluado y una línea base medida siguen siendo útiles el día que llegue, sea antes o después de lo previsto.

Qué datos tienen que estar listos antes del diagnóstico

El diagnóstico de madurez no empieza por elegir un modelo: empieza por mirar los datos y en qué estado están. Revisar eso antes de gastar un euro es precisamente el primer bloque del diagnóstico de madurez y hoja de ruta a 18 meses: con ese mapa hecho, el diagnóstico tiene con qué trabajar qué procesos se benefician de verdad, qué equipo los va a mantener y, a veces, si la respuesta honesta es que ese problema concreto no lo resuelve la IA, sino reorganizar un proceso o formar a una persona. Decir eso a tiempo, antes de construir nada, es lo que separa un diagnóstico útil de uno que solo confirma lo que el cliente quería oír.

Elegir el caso de uso: qué proceso primero

Casi ninguna empresa tiene un único candidato: suele haber varios procesos que parecen automatizables y recursos limitados para abordarlos todos a la vez. El error habitual es empezar por el proceso más visible para dirección —el que más se comenta en las reuniones— en vez de por el que reúne mejor las condiciones técnicas: volumen suficiente para que compense, reglas razonablemente claras en vez de juicio experto puro, datos accesibles y una tolerancia al error que permita una fase de revisión humana mientras se calibra. Priorizar por esos criterios, y no por cuál suena mejor en una presentación, evita construir el piloto equivocado. Es lo que ordena, sin prometer cifras de ahorro que todavía nadie puede calcular, el test de qué proceso automatizar primero.

Poner un número a la decisión

El último elemento que enumera el plan es el que más se pasa por alto: medición posterior del impacto en productividad. Medir después exige haber anotado antes cuánto costaba el proceso, y eso hay que hacerlo mientras el proceso sigue siendo manual, no una vez que ya cambió. Anotar las horas mensuales que consume hoy, el coste de esa hora y una estimación honesta del porcentaje automatizable permite calcular, con la calculadora de ROI de automatización, el punto de equilibrio y un rango pesimista y optimista con los propios números, sin ninguna cifra precargada ni «ahorro típico» inventado.

El recurso que de verdad conviene reservar ahora es el tiempo del equipo que va a participar en el diagnóstico y en el piloto: es lo que decide si esta hoja de ruta se cumple o se queda en una intención. El dinero es distinto: el importe por empresa, los criterios de elegibilidad y qué tiene que cumplir un proveedor para encajar en la expresión «empresas tecnológicas europeas» son piezas que el plan todavía no fija, así que comprometer presupuesto contra un bono sin esas condiciones escritas es apostar a ciegas. Ninguna de esas piezas cambia el trabajo de preparación descrito arriba: el diagnóstico, el caso de uso, la línea base y la formación sirven igual, se resuelvan como se resuelvan esos detalles.

Una aclaración que conviene dejar clara: no tramitamos el bono IA360, porque no hay ninguna solicitud que gestionar todavía, y no te vamos a prometer que lo vayas a conseguir. Lo que sí hacemos es el diagnóstico, el piloto o la formación de esta hoja de ruta, se convoque el bono o no se convoque nunca.

Lo relacionado, dentro del mismo plan, está en qué proyectos de IA encajan en el bono IA360 (y cuáles no) y en probar la IA con tus datos antes de desplegarla. El resto de fases del proyecto que describe el plan completo está en qué proyecto de IA financiará el Plan IA360, y cómo se monta.