El dato que dice que algo se ha movido de verdad
La cifra mejor documentada viene de agosto de 2026, de 97 países y 1.719 personas encuestadas:
«Casi un tercio de quienes responden (el 32 por ciento) cuenta que su organización decidió no comprar al menos un producto o funcionalidad de software porque pudo construir esa funcionalidad en casa con herramientas agénticas de programación.»
A la cabeza están el sector tecnológico y el sanitario, y detrás los servicios profesionales y la energía. Pero esa misma encuesta tiene otra cifra que no se ha movido: solo el 37 % de las organizaciones puede declarar un efecto demostrable y atribuible a la IA en sus resultados operativos, exactamente el mismo porcentaje que hace un año. O sea: construir salió más barato, pero el retorno no mejoró.
Otra encuesta, a 817 desarrolladores, muestra el mismo patrón:
- el 35 % de quienes responden ya ha sustituido al menos una herramienta comprada por desarrollo propio;
- el 78 % planea más herramientas propias en 2026;
- la presión por sustituir es mayor donde menos integración hay: por categorías, automatización de flujos de trabajo 35 % y herramientas internas de administración 33 %, que es otro desglose y no el 35 % de antes;
- el 60 % construyó alguna herramienta fuera de la supervisión de TI el año pasado, y los motivos son rapidez 31 %, necesidad no cubierta 25 %, TI lenta 18 %;
- y un tercer 35 %, independiente de los dos anteriores: esa proporción de quienes responden no tiene ninguna métrica de productividad con IA.
(La segunda encuesta viene de un fabricante de herramientas, o sea, de parte interesada.)
El último dato es el más elocuente. Una de cada tres empresas toma una decisión de build-or-buy sin medir cuánto ayudó la IA.
Qué ha bajado y qué no
Lo que ha bajado: el coste de sacar la primera versión. No lo podemos medir en dinero, pero las dos cifras de arriba muestran que quien decide lo percibe.
Lo que no ha bajado, y de esto sí hay medición:
| Partida de coste | Qué se mide |
|---|---|
| Seguridad | el 45 % de las muestras de código generado suspende una prueba de seguridad; en un gran lenguaje empresarial la tasa de suspensos es del 72 % |
| Mantenibilidad | la proporción de refactorización cayó del 21 % al 3,8 % y la duplicación creció un 81 % (623 millones de cambios de código) |
| Estabilidad de entrega | el uso de IA se correlaciona negativamente con ella |
| Seguridad de infraestructura | la densidad de vulnerabilidades de la configuración generada es entre 3,2 y 3,9 veces la humana |
| Operación | con diez mil peticiones al mes, la inferencia cuesta entre 15 y 350 dólares según el nivel de modelo |
| Gestión de incidentes | resolver un fallo propio, 96 minutos de mediana; uno de un proveedor, 247 minutos |
La última fila es interesante porque juega en contra del proveedor: tu propio fallo lo arreglas antes. Solo que tu turno de guardia no se monta solo.
Y hay una cosa que conviene decir aparte: construir un prototipo y mantener un sistema que ya existe no son el mismo trabajo. En un experimento controlado sobre una base de código madura y grande, la IA ralentizó un 19 % a los desarrolladores con experiencia, mientras ellos sentían una aceleración del 20 %. La decisión de build-or-buy va justo de eso: el primer mes salió barato, el tercer año no.
La línea que el cálculo clásico omite: quién es el proveedor
Esta es la parte más importante y menos conocida del post.
Según las definiciones del Reglamento de IA de la UE:
- Proveedor es quien desarrolla un sistema de IA, o encarga desarrollarlo, y lo introduce en el mercado o lo pone en servicio con su propio nombre.
- Responsable del despliegue es quien utiliza un sistema de IA bajo su propia autoridad.
- Y la definición decisiva: la «puesta en servicio» incluye también ponerlo a disposición para uso propio.
De ahí se sigue que quien desarrolla él mismo un sistema de IA para su empresa es a la vez proveedor Y responsable del despliegue, con los dos paquetes de obligaciones. Quien compra lo mismo es solo responsable del despliegue, con bastantes menos obligaciones.
Y hay un artículo donde el argumento de «nosotros solo envolvemos el modelo» se cae. Según el Reglamento, el distribuidor, el importador, el responsable del despliegue u otro tercero pasa a ser proveedor respecto de un sistema de alto riesgo si
- le pone su propio nombre o su marca;
- hace una modificación sustancial que afecta al cumplimiento;
- o cambia la finalidad prevista —incluida la de un sistema de IA de uso general— de modo que pase a ser de alto riesgo.
Pongámoslo en proporción, para que no suene alarmista. El paquete completo de obligaciones rige para los sistemas de alto riesgo, y la mayoría de las herramientas internas no lo son.
Pero. Entre las categorías de alto riesgo está el empleo: selección, promoción, asignación de tareas, monitorización de la plantilla. Es decir, justo el terreno en el que las empresas construyen herramientas internas más a menudo.
Y una precisión de fechas, porque hay muchas fuentes desactualizadas: en el verano de 2026 el plazo de las obligaciones de los sistemas de alto riesgo se aplazó a diciembre de 2027. Quien siga poniendo agosto de 2026 para esas obligaciones trabaja con una fuente vieja. El aplazamiento solo las afecta a ellas: la aplicación general y las reglas de transparencia están en vigor desde agosto de 2026, y la obligación de alfabetización en IA desde febrero de 2025.
(El Reglamento se aplica directamente en todos los Estados miembros, no hay que transponerlo.)
Un cálculo de ejemplo concreto
Tomemos una empresa de treinta personas que busca una herramienta interna de aprobaciones y flujos de trabajo. La versión que se puede comprar: treinta puestos, a 25 dólares por persona al mes, 9.000 dólares al año.
| Partida | Año 1 | Desde el año 2 / año |
|---|---|---|
| Desarrollo: 120 horas × 60 dólares | 7.200 | — |
| Mantenimiento (20 % del desarrollo) | — | 1.440 |
| Uso de modelo: 10.000 peticiones al mes, nivel medio | 1.680 | 1.680 |
| Hosting, base de datos, monitorización | 600 | 600 |
| Revisión de seguridad | 2.000 | 1.000 |
| Desarrollo propio, total | 11.480 | 4.720 |
| Comprado | 9.000 | 9.000 |
(Cálculo propio con parámetros supuestos. Solo están verificados los precios de modelo y las proporciones de seguridad y mantenibilidad: las horas, la tarifa por hora y el coste de hosting son estimaciones.)
El primer año, el desarrollo propio sale más caro. A partir del segundo, más barato. El punto de equilibrio cae más o menos por el mes diecinueve, siempre que la herramienta no cambie.
Y la trampa está justo ahí. Según las mediciones de arriba, la línea de mantenimiento no se hace menor, sino mayor: la refactorización se hunde y la duplicación sube. Quien cuenta con un retorno a los diecinueve meses suele haber escrito la línea de mantenimiento más optimista posible.
El objetivo de la tabla no es darte la respuesta, sino enseñarte dónde están las líneas que el cálculo clásico omite: ejecutar el modelo, la revisión de seguridad, el papel regulatorio y el mantenimiento, que en la era de la IA tampoco se ha hecho más pequeño.
Una línea que la tabla de arriba no contiene: el dinero público. En varios Estados miembros parte del software comprado y de la consultoría la cubre una ayuda a fondo perdido, y eso inclina directamente la balanza entre comprar y construir, porque lo que se suele financiar es la compra, no el desarrollo propio. Despliega el que te afecte:
Hungría — no hay ayuda específica de IA; la IA va de acompañante en un programa de webs
En septiembre de 2026 no existe una ayuda autónoma de implantación de IA para pymes. Lo que hubo: la segunda convocatoria del programa «que toda empresa tenga su propia web» abrió el 3 de febrero de 2026 con 1.200 millones de forintos, bonos de entre 400.000 y 2 millones de forintos al 100% de intensidad, y ahí apareció la IA, en forma de un «paquete de IA» de 500.000 forintos.
Ese presupuesto se agotó en cuatro días: la convocatoria se cerró el 6 de febrero de 2026 por agotamiento de fondos, con más de mil solicitudes presentadas.
La otra vía viva es la ayuda a la digitalización de pymes, con 30.000 millones de forintos de presupuesto, entre 3 y 12 millones por solicitante, hasta un 90% de intensidad, para micro y pequeñas empresas fuera de Budapest, entre el 31 de marzo y el 30 de junio de 2026. La inteligencia artificial, en cambio, no aparece nombrada entre las actividades subvencionables; sí el equipamiento, el software, la seguridad informática y la formación.
España — sí hay bono de asesoramiento en IA, solo que está cerrado
España tiene un programa estatal en el que el asesoramiento en IA es un producto separado y nombrado: en el Kit Consulting la pyme recibe 12.000 euros entre 10 y 49 empleados, 18.000 entre 50 y 99 y 24.000 entre 100 y 249, y dentro de eso el «servicio de asesoramiento en inteligencia artificial» son 6.000 euros en los tres segmentos. No es solo análisis: el pliego incluye la implantación efectiva de un caso de uso adaptado al negocio.
Su programa hermano, el Kit Digital, incorporó por primera vez herramientas de IA a su catálogo a finales de 2024, con bonos de 25.000 euros entre 50 y 99 empleados y 29.000 entre 100 y 249.
La situación práctica, eso sí, es que en septiembre de 2026 ninguno de los dos está abierto: la convocatoria del Kit Consulting cerró en febrero de 2025, las últimas convocatorias ordinarias del Kit Digital en octubre de 2025, y ningún documento oficial fija un nuevo plazo. El marco jurídico está vivo, el grifo cerrado.
Lo que conviene llevarse: si eres una pyme española y te inclinas por comprar, la reapertura de los bonos puede ser la mayor partida individual del cálculo: 6.000 euros de consultoría son más o menos el coste completo del primer año de un desarrollo interno pequeño.
La regla de decisión
CONSTRÚYELO SI
es una herramienta interna con pocas integraciones
el proceso es único EN TU CASA (por eso no hay producto)
si se muere, nadie pierde dinero
y hay alguien que lo mantenga TRES AÑOS después
CÓMPRALO SI
hay datos, dinero o cumplimiento de otros por medio
hacen falta muchas integraciones
necesita certificación (en el SaaS es una característica
del producto; por tu cuenta, empiezas de cero)
afecta a una decisión de EMPLEO -> aquí la carga
regulatoria es de otro orden de magnitud
EN LOS DOS CASOS
escribe DE ANTEMANO qué vas a medir. Un tercio de las
empresas no tiene ninguna métrica de productividad con
IA - y toma esta misma decisión.
Malentendidos habituales
- «Construirlo con IA siempre sale más barato.» La primera versión, sí. En el cálculo de ejemplo, el primer año aun así sale más caro que la versión comprada.
- «Nosotros solo envolvemos el modelo, no somos fabricantes.» Si modificas la finalidad prevista de forma que pase a ser de alto riesgo, según el Reglamento te conviertes en proveedor.
- «La herramienta interna no está regulada.» La mayoría no lo está. Pero una herramienta que apoya una decisión de empleo cae en la categoría de alto riesgo, y es justo la que se suele construir en casa.
- «El mantenimiento saldrá más barato con IA.» En un experimento controlado sobre una base de código madura, la IA ralentizó un 19 %. La proporción de refactorización cayó del 21 % al 3,8 % en cuatro años.
- «Cada vez construye más gente, así que es el camino bueno.» En esa misma encuesta, el efecto demostrable en resultados está en el 37 %, igual que hace un año.
Lo que conviene llevarse
Una línea del cálculo de build-or-buy sí ha bajado de verdad: el precio de la primera versión. El resto sigue igual, y encima han llegado dos que antes no había que escribir: ejecutar el modelo y el papel regulatorio. Quien construye para sí mismo es, según el Reglamento, proveedor y responsable del despliegue a la vez; quien compra es solo lo segundo.
Y el mejor filtro práctico no es el coste, sino una pregunta: ¿va a haber alguien que mantenga esto dentro de tres años?
Dónde se detiene el prototipo rápido lo explica el post el muro del 70 % , con detalle; y la cuestión de la responsabilidad la recorre el post la realidad del vibe coding , marcando los límites.