Build vs buy: ¿construir una solución de IA o comprarla?

En una reunión con el director de producción surge la pregunta que vemos en casi todas las empresas que hoy contemplan la IA: «¿Compramos alguna herramienta lista para usar, o tendremos que construirla nosotros?» La pregunta suena sencilla, pero en realidad une tres decisiones distintas — sobre diferenciación, sobre datos y sobre costes en el tiempo. Quien la responde en los primeros quince minutos de la reunión, normalmente la responde mal.

Este artículo ofrece un marco que hemos verificado en la práctica en decenas de implantaciones. No se trata de una guerra de religión entre «comprar todo» y «construir todo» — ambos son extremos y ambos son errores. Se trata de saber qué capa de cada solución concreta comprar, cuál construir y dónde está el límite a partir del cual una u otra deja de ser rentable.

La base del marco — tres capas de toda solución de IA

Toda solución de IA en producción puede dividirse en tres capas:

1. 1.Modelo e inferencia — LLM, modelo de embedding, infraestructura de serving. Esto es una commodity. OpenAI, Anthropic, Google, o modelos open-weight como Qwen 3, Mistral, Llama 4 — todos ofrecen una base sólida que cuesta cientos de millones de dólares desarrollar y que usted obtiene por una fracción de ese precio.
2. 2.Orquestación y retrieval — pipeline RAG, lógica de agentes, memoria, herramientas, guardrails. Esta es la capa donde se decide la calidad del output. Es parcialmente una commodity (frameworks como LangGraph, LlamaIndex, bases de datos vectoriales como Qdrant son open-source y maduros), pero la especificidad del despliegue — sus datos, sus procesos, sus edge cases — requiere trabajo propio.
3. 3.Capa de dominio — prompts, datasets, fine-tuning, evaluaciones, UI, integración con sistemas. Aquí es donde surge la diferenciación. Nadie más tiene sus datos de producción, sus documentos SOP ni su historial de clientes. Esta capa no se puede comprar — solo se puede construir.

En pocas palabras: compre las capas 1 y parte de la 2, construya la capa 3 y el resto de la 2. El problema aparece cuando una empresa compra la capa 1 de un vendor que le empaqueta también las capas 2 y 3 en una plataforma propietaria — y la empresa no se da cuenta de lo que está firmando.

Cuándo comprar

Comprar tiene sentido cuando el caso de uso es una commodity — es decir, cuando su problema lo están resolviendo también otras cincuenta empresas y existe un mercado maduro de soluciones. Ejemplos:

• Soporte al cliente con FAQ (Zendesk AI, Intercom, Freshdesk AI) — tarea estándar, integraciones listas, onboarding rápido.
• Resumen de reuniones y transcripción (Otter.ai, Fireflies, Microsoft Copilot) — sin valor diferenciador, la velocidad de entrega es clave.
• Asistente de código para el equipo (GitHub Copilot, Cursor, Codeium) — caso de uso genérico donde el fine-tuning individual aportará una mejora marginal a un coste desproporcionado.
• Screening de RRHH en primera ronda (existen varias plataformas maduras) — problema commodity, mercado regulado, compliance ya preparado.

Más allá de la commodity se aplica: compre si la velocidad de llegada a producción importa más que el rendimiento. En algunos casos, una solución del 80 % disponible mañana es mejor que una del 95 % disponible en ocho meses.

El último argumento a favor de comprar: si su empresa no tiene ni tendrá en el corto plazo un equipo de IA con las competencias necesarias, el mantenimiento de una solución propia le costará más que una suscripción SaaS, tanto en costes como en fiabilidad.

Cuándo construir

Construir tiene sentido en tres situaciones:

Diferenciación a través de los datos. Si dispone de datos que nadie más tiene — registros de producción de maquinaria, historial de reclamaciones, normas técnicas internas, resultados de mediciones — y si estos datos pueden ser fuente de un rendimiento superior al de la competencia, tiene que construir. Una solución lista no integra esos datos; al comprarla, paga por una calidad genérica. El fine-tuning o el RAG sobre sus propios datos transforma un modelo genérico en un especialista de dominio — pero eso requiere su propio trabajo.

Requisitos de seguridad y regulación. Si opera en un sector donde los datos no pueden salir de la red (sanidad, energía, defensa, instituciones financieras con datos bajo NDA), las soluciones SaaS simplemente están fuera de la mesa. La respuesta aquí es el LLM on-prem — despliegue local de un modelo open-weight con vLLM u Ollama, donde la inferencia corre en su hardware y ningún token abandona la red. Esto no es solo una elección técnica — es un requisito de cumplimiento normativo.

Especificidades de proceso que ningún producto estándar soportará. Si su caso de uso contiene pasos no estándar — por ejemplo, integración con un sistema SCADA heredado, procesamiento de un formato propietario de documentación, o un workflow de agentes en múltiples pasos específicamente ajustado a sus procesos de producción — ninguna plataforma lista cubrirá eso sin una personalización extensa. Y esa personalización le llevará al mismo volumen de trabajo que una solución propia, pero con código ajeno por debajo.

El modelo híbrido — la realidad de la mayoría de implantaciones en producción

En la práctica rara vez hemos visto implantaciones completamente de tipo build o completamente de tipo buy. La arquitectura típica que funciona:

• Comprar: LLM API (Claude Sonnet, GPT, Gemini Flash) o modelo open-weight vía vLLM en servidor propio; base de datos vectorial (Qdrant es el estándar de facto para el mercado europeo — EU-hosted, Apache 2.0); modelo de embedding (la familia open-weight BGE está probada en producción).
• Construir: pipeline RAG con estrategias de retrieval específicas para su tipo de documentos; capa de prompts que refleja los procesos y la terminología de la empresa; fine-tuning sobre vocabulario de dominio cuando la diferencia de calidad es medible; integración con sistemas ERP/SCADA/MES; evaluación y monitorización del rendimiento en producción.

Este enfoque híbrido le aporta la velocidad de las capas comerciales (el modelo y la base de datos están listos el primer día) y la diferenciación de las capas propias (la lógica de dominio sigue siendo suya). Al mismo tiempo reduce el riesgo de lock-in — si mañana sale un modelo mejor, cambia la llamada a la API sin reescribir toda la solución.

Coste total de propiedad — dónde cambia el cálculo

El error más frecuente en la decisión build vs buy es comparar el precio de la suscripción SaaS con el coste único de desarrollo. El cálculo correcto debe incluir el coste total de propiedad (TCO) a 3–5 años:

TCO SaaS / buy: - Suscripción mensual (escala con el número de usuarios o el volumen de datos — vigílela) - Onboarding e integración (normalmente no es gratuito) - Interrupciones por cambios de API o condiciones de servicio (hemos visto precios subidos un 40–80 % al renovar el contrato) - Costes invisibles: los datos salen de la empresa → riesgo de privacidad → posibles costes de cumplimiento normativo

TCO build: - Desarrollo inicial (normalmente la partida dominante en el año 1) - Hardware si es on-prem (servidor GPU — orientativamente 15–60 k EUR para un despliegue en producción según los requisitos, amortizado típicamente en 3 años) - Costes de personal para mantenimiento e iteración (no son nulos — calcule de forma realista) - Dependencia del know-how interno (la salida de un ingeniero clave = riesgo)

Punto clave: el SaaS resulta ventajoso en el año 1, el build se amortiza a partir del año 2–3. Si el caso de uso es temporal (proyecto piloto, validación de hipótesis, uso estacional), compre. Si es estratégico y a largo plazo, el build tiene típicamente un TCO menor y un mayor control.

Lock-in — el riesgo que se subestima

El vendor lock-in tiene en el contexto de la IA tres formas que son peores que el lock-in de software clásico:

Lock-in de datos. Cuando los datos de su empresa (documentos, historiales, anotaciones, feedback) viven exclusivamente en la plataforma del vendor, la migración es dolorosa hasta imposible. Antes de comprar, verifique siempre: ¿puedo exportar el 100 % de mis datos en un formato estándar? Si no, está en lock-in desde el primer día.

Lock-in de modelo. Si ha construido lógica de prompts, un conjunto de fine-tuning o evaluaciones para un modelo concreto (p. ej. clase GPT-4), migrar a otro modelo requiere refactorización aunque el nuevo modelo sea mejor. La solución: una capa de abstracción en la orquestación donde el modelo sea configuración, no código rígido.

Lock-in de integración. Algunas plataformas ofrecen conectores a sus sistemas — ERP, CRM, SCADA. Cuando esos conectores son propietarios y no están documentados, cambiar de plataforma solo es posible a costa de reescribir las integraciones. Siempre prefiera API abiertas y protocolos estándar.

La buena noticia: los modelos open-weight (Llama 4, Qwen 3, Mistral — la mayoría bajo Apache 2.0 o una licencia comercial comparable) han reducido drásticamente el lock-in de modelo en los últimos dos años. El rendimiento frontier es alcanzable localmente sin atarse a ningún proveedor concreto.

Mapa de decisión — 5 preguntas antes de concluir

Antes de la decisión final, recorra con su equipo estas cinco preguntas:

1. 1.¿Es el caso de uso una commodity? Si dos docenas de empresas del mismo sector están resolviendo el mismo problema de la misma manera, una solución lista es probablemente más eficiente.
2. 2.¿Son nuestros datos fuente de diferenciación? Si es así, tiene que construir — un producto listo no los procesará de forma que le den ventaja.
3. 3.¿Pueden los datos salir de la red? Si no, el build/on-prem es la única opción.
4. 4.¿Tenemos (o podemos asegurar) un equipo para construir y mantener? Construir sin un equipo competente es peor que comprar — la composición del equipo para un proyecto de IA es un tema aparte que hay que resolver en paralelo.
5. 5.¿Cuánto tiempo planeamos operar esta solución? Hasta 12 meses o si el caso de uso es incierto → compre. 2+ años con resultados claros → el build o el híbrido saldrá mejor.

Cuando las respuestas a estas preguntas no designan un ganador claro, lo normal es que se trate de un caso híbrido — comprar las capas base, construir la especialización de dominio.

Errores típicos que vemos

Comprar todo el stack a un solo vendor sin verificar si cada capa está realmente a nivel best-in-class. Las plataformas que lo hacen todo no hacen nada de forma excelente. Cada vez más implantaciones exitosas en producción combinan componentes de distintos proveedores: API del modelo por un lado, base de datos vectorial open-source, orquestación propia.

Construir sin un caso de uso definido. «Queremos IA, así que lo construiremos nosotros» es una expedición sin mapa. La mayoría de los proyectos que hemos visto fracasar no tenían definida una métrica de éxito antes de arrancar — y por tanto tampoco una forma de saber si lo que estaban construyendo tiene valor. El ROI de los proyectos de IA hay que medirlo desde el primer día.

Subestimar el coste de los datos. Antes de poder construir, tiene que tener datos — limpios, estructurados, disponibles en un formato que el LLM pueda procesar. Según el Cisco AI Readiness Index, solo ~34 % de las empresas evalúa su madurez de datos como suficiente. Si está en el 66 % restante, el pipeline de datos es su primer proyecto, no la IA en sí.

Ignorar la EU AI Act. A partir de agosto de 2026 entran en vigor obligaciones concretas para las empresas que despliegan sistemas de IA en contextos regulados. Si compra una plataforma, verifique que el vendor proporciona documentación de cumplimiento. Si construye, la documentación de cumplimiento es su responsabilidad. Ignorar este aspecto hoy puede significar tener que rehacer la solución más adelante.

Preguntas frecuentes

¿Tiene sentido probar una solución lista como proof-of-concept y luego reemplazarla con una propia?

Sí, pero con una condición: el piloto debe probar su caso de uso concreto, no una demo genérica. Si el piloto con una solución comprada demuestra que el caso de uso tiene valor, tiene la evidencia para la inversión en una construcción propia. Lo importante es que la arquitectura piloto separe la lógica de datos de la plataforma — así la migración es más sencilla.

¿Qué significa «modelo open-weight» desde el punto de vista de licencia y uso comercial?

Modelos como Qwen 3 o Mistral se publican bajo licencia Apache 2.0 — puede usarlos comercialmente sin pagar royalties. Llama 4 tiene su propia licencia (uso comercial gratuito por debajo de un límite de usuarios activos mensuales). Verifique siempre las condiciones de licencia vigentes para el modelo y la versión concretos antes del despliegue.

¿Es realista un despliegue on-prem para una empresa sin un gran equipo de TI?

Sí, si el caso de uso está bien delimitado. Un único servidor GPU con Ollama y un modelo open-weight de menor tamaño (por ejemplo Qwen 3 8B o Phi-4 14B) lo puede desplegar un ingeniero experimentado en un día. Más exigente es el despliegue en producción con alta disponibilidad, monitorización y CI/CD — eso requiere más. La elección correcta para una empresa sin equipo de IA suele ser una solución on-prem gestionada con soporte externo, no infraestructura self-managed.

¿Cuándo es el fine-tuning parte de una estrategia «build» y cuándo no?

El fine-tuning tiene sentido cuando quiere especializar el modelo en su registro lingüístico, terminología o formato de outputs — y cuando dispone de suficientes datos de entrenamiento de calidad (orientativamente 5 000+ pares de ejemplos para un SFT básico). Si no tiene datos o si el problema lo puede resolver bien un pipeline RAG bien diseñado, el fine-tuning es una optimización prematura. Más sobre esta decisión en el artículo RAG vs fine-tuning.

¿Cuál es la causa más frecuente de que los proyectos build superen el presupuesto?

Según nuestra experiencia: la subestimación de la evaluación y la iteración. Construir la primera versión lleva un tiempo predecible — pero medir si funciona, identificar dónde falla y corregirlo lleva el mismo tiempo de nuevo. Los proyectos que cuentan con esto desde el inicio entregan en tiempo y presupuesto. Los que asumen que la primera versión será la de producción, no.

*MP Industrial Solutions ayuda a las empresas a abordar la decisión build vs buy con números en la mano — desde el mapeo de casos de uso hasta los cálculos de TCO y el primer despliegue en producción. Si está ante esta decisión, con mucho gusto evaluamos su caso concreto juntos.*