Inteligencia Artificial 05.06.2026

Make-or-Buy en IA: ¿construir por cuenta propia o comprar?

8 min. de lectura

Cuando en la mediana empresa se menciona la IA, el debate suele volverse demasiado estrecho: ¿lo desarrollamos nosotros o lo compramos? Construirlo internamente suena a control; comprarlo, a dependencia. En la práctica, el desarrollo propio es con frecuencia el reflejo más caro. Para muchas empresas, la mejor respuesta se encuentra entre la solución estándar y la adaptación propia.

Lo más importante en resumen

Buy supera a Build en la mayoría de los casos de mediana empresa. Los proyectos de IA liderados por proveedores tienen el doble de éxito que los desarrollos puramente internos. Quien construye por su cuenta necesita una buena razón, no solo el deseo de control.
El cálculo cambia en el tercer año. El desarrollo propio parece más económico el primer año; luego llegan el mantenimiento, el reentrenamiento, la gobernanza y la retención de personal. Solo una perspectiva a tres años permite una valoración honesta.
Entre Make y Buy está Boost. Una plataforma estándar cubre a menudo la mayor parte; el resto lo complementan las empresas con sus propios datos y controles. Para muchas medianas empresas, este es el camino más realista.

Relacionado:Primero las personas, luego las herramientas / Por qué la IA fracasa por culpa del orden

Tres enfoques clarifican el reflejo Make-or-Buy

¿Qué es Make-or-Buy en IA? Make-or-Buy designa la decisión de desarrollar una capacidad de IA internamente o adquirirla como solución ya lista. En IA se añade una tercera opción: complementar una plataforma estándar con datos, prompts y controles propios. La pregunta binaria se convierte así en una elección entre Make, Buy y Boost.

Muchos proyectos de IA no arrancan con una valoración sobria, sino con un sentimiento: el orgullo del desarrollo propio o el temor a la dependencia. Ambos son comprensibles. Pero para una inversión que debe sostenerse durante tres años, no son suficientes.

Esta clasificación ha demostrado su utilidad en la práctica. Buy encaja cuando el caso de uso está extendido, existen proveedores maduros y la velocidad importa. Make encaja cuando la capacidad constituye el núcleo de la propia ventaja competitiva o se basa en datos que ningún proveedor puede replicar. Boost encaja cuando una plataforma cubre la mayor parte y solo un segmento claramente delimitado debe permanecer en manos propias. Para la mayoría de los casos de mediana empresa, esto describe la situación mejor que un pensamiento puramente Build-versus-Buy.

Donde el desarrollo propio se cobra la factura: el cálculo a tres años

El error más frecuente no es la decisión equivocada, sino el cálculo demasiado corto. El desarrollo propio parece a menudo más barato en el primer año, porque los costes evidentes parecen menores que una licencia. El cálculo se invierte en el tercer año. Para entonces se han acumulado el mantenimiento, el reentrenamiento del modelo, la gobernanza, las auditorías de seguridad y la retención de los pocos especialistas que son capaces de operar el sistema.

Esta retención de talento es la partida más subestimada. Un sistema de IA construido internamente es tan estable como el equipo que lo comprende. Si se marcha la persona que entrenó el modelo, la capacidad queda atada a un cuello de botella. Un sistema adquirido no tiene ese cuello de botella, pero sí otro: la dependencia del proveedor. Lo decisivo es de quién depende la empresa y cuánto costaría salir.

42 por ciento

de las empresas abandonaron en 2025 la mayoría de sus iniciativas de IA, frente al 17 por ciento del año anterior.

Fuente: estudios sectoriales actuales sobre proyectos de IA

El dato no es un argumento contra la IA. Muestra lo caro que puede resultar elegir la vía de aprovisionamiento equivocada. Los proyectos liderados por proveedores alcanzan su objetivo con una frecuencia aproximadamente el doble de alta que los desarrollos puramente propios, según los mismos estudios. Quien en la mediana empresa construye por su cuenta asume complejidad técnica y un riesgo de proyecto sensiblemente mayor.

Cuatro criterios que aclaran la decisión antes de la demo

Una parrilla concisa ayuda más que el instinto. Cuatro criterios separan los tres caminos con más fiabilidad que cualquier demo de herramienta. Lo decisivo es responder estas preguntas antes de la primera conversación con un proveedor.

Criterio	Make	Buy	Boost
Núcleo competitivo	sí, lo diferenciador	no, tarea estándar	en parte, adaptación selectiva
Tiempo hasta el beneficio	meses o años	días o semanas	semanas
Soberanía de datos	completamente en casa	en el proveedor, regulada contractualmente	compartida, controlable
Costes a tres años	elevados, a menudo subestimados	previsibles, recurrentes	medios, bien controlables

La parrilla no resuelve la decisión por sí sola, pero sí desmonta los costosos autoengaños. Quien anota un honesto «no» en el núcleo competitivo y aun así quiere construir debería detenerse. En la gran mayoría de los casos en que la mediana empresa cree necesitar algo propio, lo que quiere en realidad es únicamente el control que también proporciona un contrato bien negociado.

Lo que los equipos deben aclarar antes de comprar

Incluso la decisión de base correcta puede fracasar en la implementación. Con los años han surgido algunas condiciones que marcan regularmente la diferencia.

Lo que frena

La decisión se toma por orgullo o miedo en lugar de por criterios
Solo se calcula el primer año, sin una visión completa a tres años
Desarrollo propio sin una sucesión clara para los pocos especialistas disponibles
Compra sin cláusula de salida y sin considerar los costes de cambio

Lo que sostiene

Una respuesta honesta a la pregunta sobre la ventaja competitiva antes de cada demo
El cálculo a tres años, incluidos mantenimiento, gobernanza y talento
Boost como opción consciente, no como solución de emergencia
Un contrato que regule con claridad la soberanía sobre los datos y la salida

La columna izquierda rara vez tiene que ver con la tecnología. Tiene que ver con la disciplina. Primero los criterios, luego los proveedores, luego la demo. Quien respeta este orden toma la decisión de fabricar o comprar una sola vez de forma correcta, en lugar de corregirla a un alto coste dieciocho meses después.

Preguntas frecuentes

¿Cuándo debería la mediana empresa desarrollar realmente su propia solución de IA?

Solo cuando la capacidad constituye la propia ventaja competitiva o se basa en datos que ningún proveedor puede replicar. Si se trata de una tarea habitual como reconocimiento de texto, clasificación o un asistente, existen proveedores maduros y el desarrollo propio inmoviliza dinero y especialistas sin necesidad.

¿Por qué el desarrollo propio suele ser más caro en el tercer año?

Los costes evidentes del primer año son solo una parte. Después se acumulan el mantenimiento, el reentrenamiento del modelo, la gobernanza, las auditorías de seguridad y, sobre todo, la dependencia de los pocos especialistas que operan el sistema. Estas partidas no figuran en el cálculo inicial y dan la vuelta al balance.

¿Qué significa Boost en concreto?

Una plataforma estándar cubre la mayor parte de un caso de uso, y la aportación propia es la última pieza: datos internos, prompts adaptados, una integración en el sistema especializado, un nivel de control humano. Se compra la base y se añade solo lo que realmente debe ser propio.

¿Cómo se evita la dependencia de un proveedor?

No mediante el desarrollo propio, sino a través de un buen contrato. Lo importante es una regulación clara sobre la soberanía de los datos, una exportación acordada de los propios datos y una visión realista de los costes de cambio. La dependencia no se puede evitar, pero sí se puede gestionar.

¿Qué pregunta está al inicio de la decisión?

¿Esta capacidad forma parte de nuestra ventaja competitiva o es una tarea estándar? Esta única respuesta clasifica la mayoría de los casos de antemano. Solo después siguen el time-to-value, la soberanía sobre los datos y los costes a tres años. Quien empieza con la demo del proveedor ya ha perdido el orden.