600 millones de euros anunciados, 25.000 empresas como objetivo y una pregunta decisiva: ¿quién se responsabiliza del sistema cuando la inteligencia artificial entra en el negocio?

Una ayuda pública puede facilitar la compra de tecnología. No decide qué datos debe utilizar esa tecnología, quién revisará sus resultados ni cómo responderá la empresa cuando algo falle. Esas decisiones siguen perteneciendo al proyecto y a quienes lo desarrollan y utilizan.

El Plan IA360 sitúa esa cuestión en una escala distinta. Su bono empresarial de inteligencia artificial prevé una dotación global de 600 millones de euros y persigue transformar 25.000 empresas. El objetivo no es repartir cuentas de acceso a una herramienta, sino incorporar soluciones que mejoren procesos y produzcan resultados medibles.

La oportunidad merece atención. También su consecuencia jurídica: si más organizaciones utilizan sistemas de IA bajo su propia autoridad, aumenta el número de responsables del despliegue y la necesidad de identificar sus obligaciones. La democratización de la IA debe ir acompañada de una democratización del cumplimiento. No mediante expedientes idénticos para todos, sino con medidas proporcionadas al sistema, su finalidad, sus riesgos y el papel de cada empresa.

Esta es la idea que conecta el nuevo bono con nuestra línea de análisis sobre adopción de IA: la financiación puede impulsar el despliegue; no sustituye su adecuación jurídica.

Qué es el Bono de IA y qué no es todavía

El bono es el proyecto tractor 11 del Plan IA360, dentro del ámbito «Difusión. De la adopción social al tejido productivo». Forma parte de una hoja de ruta más amplia que conecta infraestructuras, seguridad, educación, talento, desarrollo tecnológico, adopción empresarial, Administración y alianzas. Para las pymes, su interés está en reducir la distancia entre probar una herramienta y transformar realmente un proceso.

Conviene distinguir tres niveles: el anuncio, las reglas de la ayuda y la convocatoria que permita solicitarla. El Plan describe el primero y anticipa elementos de los siguientes, pero no sustituye sus instrumentos de desarrollo. A la fecha de cierre de este artículo, la documentación disponible no permite presentar el bono como una convocatoria general abierta ni anunciar una vía oficial de solicitud.

Tampoco permite prometer una cuantía individual. Dividir 600 millones entre 25.000 empresas produce una media aritmética de 24.000 euros, no un importe reconocido a cada beneficiario. No equivale a un máximo, un mínimo ni un porcentaje de financiación. Las cuantías, la elegibilidad, los gastos admisibles y las condiciones de justificación dependerán de lo que se publique.

Kit Digital y Kit Consulting pueden ayudar a entender la idea de acompañamiento administrativo, pero sus reglas no se trasladan automáticamente a este programa. Tampoco debe confundirse este bono con el instrumento de 40 millones que analizamos anteriormente en el blog de Delvy. Una denominación parecida no crea identidad de procedimiento.

La consecuencia práctica es sencilla: preparar un proyecto no es reservar una ayuda. Contratar asesoramiento, dejar datos en un formulario privado o empezar una implantación no acredita prioridad ni garantiza que esos gastos vayan a ser financiables.

El diseño anunciado: transformar procesos, no acumular licencias

El Plan prevé financiar servicios y soluciones prestados por empresas tecnológicas europeas que utilicen modelos fundacionales como insumo y aporten valor propio mediante desarrollo, integración, conocimiento sectorial, tratamiento de datos o rediseño de procesos. Excluye expresamente la mera suscripción a licencias.

Ese matiz importa. Una cosa es contratar acceso a una herramienta; otra, integrarla con los sistemas de la empresa, definir un uso concreto, ordenar los datos, formar a las personas y comprobar el resultado. La exclusión de una simple suscripción no permite afirmar, sin las futuras bases, que cualquier coste de licencia integrado en un proyecto vaya a ser admisible o quede necesariamente excluido.

El diseño incluiría pagos por hitos y condiciones relacionadas con formación e incorporación de la IA a los procesos internos. También contempla diagnóstico previo de madurez, identificación de un caso de uso y medición posterior de productividad. Son orientaciones del Plan, no un catálogo definitivo de conceptos subvencionables.

Nuestra recomendación es empezar por el problema empresarial: reducir errores en documentación, mejorar la previsión de necesidades o apoyar una atención al cliente que sigue teniendo responsables humanos. Después se elige la solución. Hacerlo al revés puede dejar una tecnología atractiva sin utilidad demostrable ni reglas claras de utilización.

No basta con medir cuánto se acelera una tarea. También conviene comprobar si aumentan los errores, las reclamaciones o las intervenciones necesarias para corregir resultados. Recomendamos evaluar productividad y calidad juntas: una respuesta más rápida no aporta el mismo valor si exige después más tiempo de reparación o perjudica a quien la recibe.

Red NEURONA y calendario: dos iniciativas conectadas, no un único piloto

El bono se vincula con la Red NEURONA, concebida como una red público-privada de centros de demostración y despliegue. El Plan propone aprovechar capacidades existentes, incluidos centros tecnológicos, supercomputación, espacios de datos y Acelera Pyme, para que las empresas puedan conocer, probar e incorporar soluciones.

Los calendarios son distintos. Para NEURONA se anuncia un piloto con 100 pymes en dos comunidades autónomas antes de terminar 2026 y una extensión durante 2027 hasta diez comunidades y 5.000 empresas. Para el bono se prevén diseño, preparación normativa y piloto controlado en el primer semestre de 2027, con convocatoria general antes de finalizar ese año.

Son hitos programáticos, no plazos abiertos de solicitud. Tampoco permiten dar por confirmado un órgano gestor, un registro de proveedores homologados o una concesión por orden de llegada. La futura instrumentación determinará esos extremos.

Para una empresa, esperar a las bases es necesario para conocer los requisitos definitivos. Esperar a ellas para descubrir qué sistema utiliza, qué datos necesita o qué decisiones automatiza es una opción muy distinta.

Más adopción significa más responsables del despliegue

El Reglamento europeo de IA (RIA o AI Act) no se dirige exclusivamente a quienes desarrollan modelos. Su artículo 3.4 también contempla a quien utiliza un sistema bajo su propia autoridad, fuera del uso personal no profesional. Por eso, una pyme puede ser responsable del despliegue aunque no haya programado el sistema ni controle su tecnología de base.

Contratar una solución externa no elimina ese papel. Ni recibir financiación lo traslada al órgano concedente. El proveedor, el integrador y la empresa usuaria pueden tener responsabilidades diferentes, que deben identificarse atendiendo a lo que realmente hacen.

La expansión prevista puede aumentar significativamente el número de organizaciones con obligaciones. Pero sería incorrecto traducir el objetivo de 25.000 empresas en 25.000 nuevos responsables del despliegue: algunas ya utilizarán IA y una misma empresa puede desplegar varios sistemas. El cambio de escala es una consecuencia razonable de la adopción, no una cifra jurídica que el Plan haya calculado.

También puede cambiar el rol. Desarrollar o encargar un sistema y ponerlo en servicio bajo nombre propio exige analizar la condición de proveedor. En alto riesgo, el artículo 25 regula supuestos específicos relacionados con marca propia, modificación sustancial o cambios de finalidad. No toda configuración convierte al cliente en proveedor, pero tampoco basta llamar «usuario» al cliente en el contrato para resolver la cuestión.

El contrato debe reflejar esa realidad y concretar colaboración, documentación y responsabilidades. No puede borrar una obligación legal simplemente atribuyéndola a otra parte.

Tampoco debe confundirse el responsable del despliegue con un puesto interno que la empresa deba crear necesariamente. El concepto identifica al operador que utiliza el sistema bajo su autoridad; no convierte a cada empleado en un nuevo sujeto regulado por abrir una aplicación. Organizar responsables internos es una medida de gobernanza distinta de determinar quién ocupa ese rol jurídico.

Adecuación masiva no significa imponer lo mismo a todas las empresas

La primera comprobación es si la solución encaja en la definición de sistema de IA. Después deben examinarse su finalidad, el contexto, las personas afectadas y el rol de cada operador. Finalmente se identifican prohibiciones, obligaciones de transparencia y, cuando corresponda, el régimen de alto riesgo. Estas obligaciones no siempre forman categorías excluyentes: un sistema de alto riesgo también puede quedar sujeto a transparencia.

Pensemos en tres ejemplos ilustrativos, sin anticipar su elegibilidad para el bono.

Una distribuidora utiliza IA para prever reposiciones. El análisis se centra en el uso concreto, la información empleada, los contratos y la fiabilidad necesaria para el proceso; no corresponde tratarla automáticamente como un sistema de alto riesgo.

La misma empresa incorpora un asistente de atención al cliente. Habrá que revisar la interacción, el papel del proveedor, el tratamiento de datos y los mecanismos para gestionar respuestas incorrectas o derivar consultas.

Después decide utilizar IA para filtrar candidaturas. La finalidad cambia: selección y evaluación de personas exigen analizar el anexo III y las condiciones del artículo 6, además de protección de datos y normativa laboral. La intervención humana no elimina por sí sola la posible clasificación de alto riesgo.

La pregunta útil no es «¿cumple esta herramienta?», de manera abstracta. Es «¿podemos utilizar este sistema, para esta finalidad, con estos datos y estos controles?». Esa es la adecuación proporcional que necesita una adopción a gran escala.

El calendario del bono no aplaza el del Reglamento de IA

El Ómnibus digital sobre IA modifica determinados plazos y obligaciones, pero no establece una suspensión general. Con la reforma introducida por el Reglamento (UE) 2026/1744, las principales obligaciones del capítulo III, secciones 1 a 3, se desplazan al 2 de diciembre de 2027 para el alto riesgo del artículo 6.2 y anexo III, y al 2 de agosto de 2028 para el artículo 6.1 y anexo I. Deben revisarse también las disposiciones transitorias aplicables a cada sistema.

No todo espera a esas fechas. La alfabetización y las prohibiciones inicialmente previstas comenzaron a aplicarse el 2 de febrero de 2025. El artículo 4 reformado exige medidas para apoyar la alfabetización del personal y de quienes operan sistemas por cuenta de la organización, atendiendo a conocimientos, contexto y personas afectadas. No impone garantizar un nivel individual específico ni convierte un diploma en acreditación de cumplimiento.

El artículo 50 se aplica desde el 2 de agosto de 2026, con matices por obligación y régimen transitorio. El apartado 1 se dirige a los proveedores de sistemas destinados a interactuar directamente con personas: deben diseñarlos para que estas sepan que interactúan con IA, salvo las excepciones previstas. La información debe ser clara y facilitarse, como máximo, en la primera interacción. La empresa que incorpora el asistente necesita comprobar cómo se materializa esa obligación, sin confundir su rol con el del proveedor.

El apartado 2 regula el marcado técnico de contenido sintético por los proveedores. La transición hasta el 2 de diciembre de 2026 afecta a los sistemas introducidos en el mercado antes del 2 de agosto de 2026; no es una prórroga general de toda transparencia. El apartado 4 establece obligaciones específicas para determinados contenidos difundidos por responsables del despliegue, con sus propias excepciones.

En consecuencia, el proyecto debe tener dos calendarios coordinados: financiación y cumplimiento. La fecha de solicitud de una ayuda no decide cuándo comienza a aplicarse una obligación regulatoria.

Alto riesgo: obligaciones concretas, no un expediente universal

Cuando resulte aplicable el régimen de alto riesgo, el artículo 26 exige al responsable del despliegue medidas técnicas y organizativas para utilizar el sistema conforme a sus instrucciones. También contempla supervisión humana con competencia, formación y autoridad; pertinencia y representatividad de los datos de entrada en la medida en que estén bajo su control; vigilancia del funcionamiento y actuación ante riesgos o incidentes.

La conservación de registros automáticos debe analizarse en sus términos: al menos seis meses cuando estén bajo control del responsable del despliegue, salvo que el Derecho aplicable disponga otra cosa. En el entorno laboral existen obligaciones específicas de información a representantes y trabajadores afectados. Son exigencias con ámbito y calendario propios, no requisitos que deban atribuirse indiscriminadamente a cualquier pyme que use IA.

Lo mismo sucede con la evaluación de impacto en derechos fundamentales, o FRIA. El artículo 27 la exige a determinados responsables del despliegue y usos; no a cualquier beneficiario potencial del bono ni automáticamente a todo sistema de alto riesgo. Debe distinguirse de la evaluación de impacto en protección de datos, cuya necesidad se determina conforme al RGPD.

Las guías de la AESIA ayudan a organizar este trabajo. Su utilidad es metodológica: relacionar riesgos, datos, supervisión, documentación y seguimiento. Las propias guías advierten que no son vinculantes ni sustituyen la normativa. Hay que leerlas junto con las modificaciones normativas posteriores. Una lista de comprobación puede orientar el expediente; no certifica por sí sola que un proyecto cumple.

Datos, contratos y ciberresiliencia también forman parte del proyecto

El RIA no desplaza al RGPD ni a la normativa española de protección de datos. Antes de conectar una solución a información de clientes o trabajadores, deben examinarse finalidad, base jurídica, minimización, información, conservación y seguridad. Si un proveedor trata datos por cuenta de la empresa, corresponde analizar el encargo; si intervienen terceros países, las transferencias. El carácter europeo del proveedor no resuelve automáticamente esas cuestiones.

También importa qué decisiones produce el sistema. No toda recomendación está prohibida, pero una decisión exclusivamente automatizada con efectos jurídicos o similares debe examinarse conforme al artículo 22 del RGPD, con sus excepciones y garantías. Una aprobación humana meramente formal no debe utilizarse como sustituto de ese análisis.

El contrato tecnológico debe concretar usos permitidos, acceso a documentación, utilización de datos para entrenamiento, confidencialidad, licencias, pruebas de aceptación, cambios de modelo y condiciones de salida. Son decisiones de proyecto que recomendamos resolver antes de depender operativamente de la solución.

Cuando existan productos con elementos digitales incluidos en el Cyber Resilience Act, será necesario analizar además producto, operador y obligaciones correspondientes. Desde el 11 de septiembre de 2026, su artículo 14 impone a los fabricantes sujetos a él la notificación de determinadas vulnerabilidades aprovechadas activamente e incidentes graves: alerta temprana en un máximo de 24 horas y notificación ampliada en 72, desde el conocimiento y sin demora indebida, seguidas de los informes pertinentes. Usar IA de terceros no convierte automáticamente a la pyme en fabricante obligado a notificar.

Por ello, conviene relacionar el inventario de IA con productos, versiones, proveedores y responsables cuando proceda. No son necesariamente el mismo inventario ni todos sus elementos están sujetos a ambos reglamentos.

Preparar el proyecto sin inventar la futura convocatoria

Nuestra propuesta práctica es trabajar desde ahora sobre decisiones útiles con independencia de que finalmente se obtenga financiación.

1) Concretar el caso de uso. Identificar qué proceso cambia, qué resultado se busca y qué decisiones permanecerán en manos humanas. «Queremos incorporar IA» no basta para decidir una inversión.

2) Ordenar roles, datos y riesgos. Documentar quién proporciona el sistema, quién lo utiliza, con qué información y para qué finalidad. La clasificación preliminar permite detectar problemas antes de comprometer presupuesto.

3)  Fijar una situación de partida. Elegir indicadores verificables de tiempo, errores, calidad o productividad. Es una recomendación preparatoria coherente con el Plan, no una afirmación sobre las métricas que exigirá la convocatoria.

4) Definir la continuidad. Presupuestar mantenimiento, consumo, soporte y formación; acordar exportación de datos y documentación, gestión de cambios y salida del proveedor. La pregunta no termina en cuánto cuesta implantar: también incluye cuánto cuesta mantener un proceso útil después de la ayuda.La continuidad no tiene un «mes trece» fijado por el Plan. Es una cuestión económica y contractual que proponemos analizar: qué conserva la empresa, qué servicios necesitará contratar y cómo podrá cambiar de proveedor sin perder datos, evidencias o capacidad operativa. La subvención puede ser temporal; el proceso transformado necesita una decisión de mantenimiento.

5) Separar preparación y gasto subvencionable. Iniciar trabajos puede tener sentido empresarial, pero su utilidad no asegura el reembolso. Incluso los gastos preparatorios deberán examinarse conforme a las reglas que se publiquen. No debe confundirse preparación con prioridad de acceso.

Este trabajo permite construir dos expedientes relacionados: el que explica la inversión y sus resultados, y el que acredita las medidas jurídicas aplicables. Compartir información evita duplicidades; justificar una subvención no equivale a acreditar todo el cumplimiento, ni sucede a la inversa.

Cómo acompaña Delvy: financiación y adecuación en un mismo proyecto

En Delvy planteamos un acompañamiento jurídico y administrativo para pymes y autónomos que conecta la preparación del Bono empresarial de IA con la adecuación del sistema. No esperamos a que exista un formulario para analizar el proyecto, ni presentamos como disponible una solicitud que depende de futuros instrumentos.

En la fase previa, ayudamos a ordenar el caso de uso, la documentación y el presupuesto en coordinación con los equipos técnicos y financieros. Identificamos roles, riesgos y obligaciones; revisamos datos y contratos; y definimos el plan de medidas, las políticas y la formación que correspondan al uso previsto.

Cuando se publiquen las bases y se habilite la convocatoria, analizaremos el encaje del proyecto, los requisitos, los gastos financiables y la compatibilidad con otras ayudas. Con la aprobación del cliente y la representación admitida, podremos asumir la preparación y presentación de la solicitud, la interlocución administrativa, los requerimientos y las subsanaciones, según el alcance acordado.

Durante la ejecución y el seguimiento, podremos acompañar la contratación, organizar evidencias, preparar la justificación y atender las comprobaciones incluidas en el encargo. En paralelo, la adecuación al RIA y a los demás regímenes aplicables debe mantenerse cuando cambien usos, proveedores, datos o funcionalidades. La implantación y validación técnicas se coordinan con los especialistas del proyecto.

Nuestro papel es el de asesor privado: no garantizamos elegibilidad ni concesión, no reservamos ayudas y no presumimos que nuestros honorarios sean subvencionables. Precisamente por eso, el acompañamiento tiene que aportar valor antes, durante y después del expediente.

El Plan IA360 ofrece la posibilidad de ampliar el acceso empresarial a la IA. Aprovecharla exige algo más que incorporar tecnología: requiere saber qué se despliega, quién responde y cómo se mantiene bajo control.

La adopción masiva necesita adecuación a la misma escala, pero proporcionada a cada proyecto. La mejor preparación para el bono es un proyecto que la empresa pueda justificar, utilizar y gobernar.

José Morato (IP-IT & AI Partner) y Pablo Sáez Hurtado (AI Senior Counsel)

¿Tu empresa está valorando un proyecto de IA?

En Delvy te ayudamos a preparar su posible financiación y su adecuación jurídica desde el principio.