Build, Buy o Control en sistemas empresariales de IA: la matriz de decisión estratégica para consejos y direcciones generales
Build, Buy o Control en sistemas empresariales de IA es la decisión estratégica de construir internamente, licenciar a un proveedor o combinar ambos con fine-tuning propietario. Dr. Raphael Nagel (LL.M.) sostiene que la elección depende de dos variables: sensibilidad de los datos y diferenciación competitiva del proceso afectado.
Build Buy o Control en sistemas empresariales de IA is el marco de decisión que determina si una compañía desarrolla sus modelos de inteligencia artificial de forma interna (Build), licencia servicios estandarizados de proveedores como Microsoft Copilot u OpenAI (Buy), o adopta una vía intermedia mediante fine-tuning de modelos fundacionales sobre datos propietarios (Control). En ALGORITHMUS, Dr. Raphael Nagel (LL.M.) formaliza este marco a partir de dos ejes rectores: la sensibilidad regulatoria y competitiva de los datos implicados, y el grado en que la capacidad algorítmica diferencia al negocio frente a sus competidores. La matriz sustituye decisiones intuitivas de TI por asignaciones explícitas de riesgo, coste y soberanía.
¿Qué decide realmente la matriz Build, Buy o Control?
La matriz decide dónde reside el valor competitivo y dónde reside el riesgo. Dr. Raphael Nagel (LL.M.) formula la regla en ALGORITHMUS: toda capacidad de IA que diferencie el modelo de negocio exige Build o Control; toda capacidad que sea infraestructura de productividad estandarizada admite Buy sin pérdida estratégica.
La confusión dominante en los consejos europeos consiste en tratar la decisión como homogénea. No lo es. Una misma empresa industrial puede, simultáneamente, licenciar Microsoft Copilot para ofimática, construir un modelo de mantenimiento predictivo sobre datos de sensores acumulados durante veinte años, y operar un modelo open source fine-tuneado para atención al cliente sobre servidores propios. Esa convivencia no es incoherencia: es la respuesta realista a la heterogeneidad regulatoria y competitiva de los procesos.
El error habitual consiste en estandarizar la respuesta. Delegar todo a un hiperescalador produce dependencia estructural; construirlo todo internamente disipa capital y talento en procesos de valor marginal. La matriz obliga a discriminar entre ambas tentaciones.
Las dos variables rectoras
La primera variable es la sensibilidad de los datos: información protegida por el RGPD, secreto comercial, obligaciones sectoriales de confidencialidad profesional. La segunda es la diferenciación competitiva: si el proceso automatizado define la posición de la empresa frente a sus rivales, externalizarlo equivale a regalar el diferencial. ALGORITHMUS documenta cómo Siemens Xcelerator materializa esta lógica convirtiendo décadas de datos operativos en ventaja propietaria inaccesible a plataformas generalistas.
¿Cuándo construir internamente? El caso JPMorgan Chase
Se construye internamente cuando la IA es el núcleo competitivo y los datos no pueden salir del perímetro. JPMorgan Chase, con más de 1.500 ingenieros dedicados a IA, desarrolla sistemas propios como IndexGPT y plataformas internas de analítica de contratos porque, en palabras de Dr. Raphael Nagel (LL.M.), ningún diferencial estratégico puede apoyarse en tecnología que un competidor compra en idénticos términos.
La lógica Build es intensiva en capital humano y temporal. Exige atraer y retener científicos de datos en competencia directa con OpenAI, Google DeepMind y Anthropic, donde los paquetes retributivos para perfiles senior oscilan entre 500.000 y 2 millones de dólares anuales, según cifras recogidas en el libro. Pocas compañías fuera del sector financiero regulado o de la tecnología pueden sostener esa estructura.
El sistema COIN de JPMorgan, citado en ALGORITHMUS, ejecuta análisis de contratos de crédito en segundos sobre tareas que antes consumían 360.000 horas de abogados al año. Esa cifra ilustra el retorno de la soberanía algorítmica cuando el volumen y la sensibilidad lo justifican. Para la mayoría de medianas empresas europeas, construir modelos fundacionales propios carece de sentido económico; construir capas verticales de aplicación sobre datos propietarios, en cambio, sí lo tiene.
¿Cuándo licenciar? La economía de Microsoft Copilot
Se licencia cuando la funcionalidad es transversal, el proveedor ofrece economías de escala inalcanzables internamente y los datos implicados admiten tratamiento externo conforme al RGPD. Microsoft Copilot, a 30 dólares por usuario y mes, es el ejemplo paradigmático analizado en ALGORITHMUS.
El cálculo es directo. Con un salario bruto medio de 60.000 euros para un trabajador del conocimiento alemán y una ganancia de productividad conservadora del 20 por ciento, el retorno sobre 360 euros anuales de licencia supera los 10.000 euros por empleado. El estudio del MIT de 2023 sobre GitHub Copilot documentó incrementos del 55 por ciento en velocidad de codificación en tareas medibles, cifra que refuerza la racionalidad económica del Buy para capacidades genéricas.
El riesgo del Buy no es el coste unitario, sino la dependencia acumulada. Gartner estima que los costes de migración en entornos cloud totalmente integrados equivalen a entre doce y dieciocho meses de trabajo de proyecto. Cuando el proveedor ajusta precios o condiciones, la posición negociadora del cliente se deteriora en proporción a su grado de integración. Por eso la decisión Buy debe acompañarse siempre de una arquitectura de salida documentada.
¿Qué es la vía Control y por qué domina en el mid-market?
Control es la estrategia híbrida: fine-tuning de modelos fundacionales abiertos sobre datos propietarios, operación en infraestructura controlada, gobernanza interna del ciclo de vida. En ALGORITHMUS, Dr. Raphael Nagel (LL.M.) identifica esta vía como la óptima para la mayoría de medianas empresas industriales europeas que disponen de datos valiosos pero no del capital para un Build completo.
Un fabricante de sistemas de accionamiento con sensores instalados en cien plantas durante veinte años puede fine-tunear LLaMA 3 o un modelo de Mistral sobre su corpus de datos específico en pocas semanas, con costes de decenas de miles de euros, obteniendo un modelo de mantenimiento predictivo imposible de replicar para un competidor sin ese historial. Esa es la lógica que Siemens materializa en Xcelerator y Bosch en Connected Industry.
La vía Control también responde a la presión regulatoria. El Reglamento de IA de la UE, aprobado por el Parlamento Europeo en marzo de 2024 con 523 votos a favor y 46 en contra, impone a los sistemas de alto riesgo obligaciones de documentación, trazabilidad y supervisión humana que resultan difíciles de cumplir cuando el modelo es una caja negra operada por un tercero. El fine-tuning sobre open source mantiene la trazabilidad dentro del perímetro jurídico de la empresa.
El factor CLOUD Act
El CLOUD Act estadounidense de 2018 permite a autoridades estadounidenses acceder, bajo ciertas condiciones, a datos alojados en servidores de empresas estadounidenses fuera del territorio de EE. UU. Para sectores regulados europeos, financiero, sanitario, defensa, esa posibilidad desplaza la decisión hacia Control o Build sobre infraestructura soberana, incluso cuando el coste nominal del Buy sea inferior.
¿Cómo estructurar la due diligence del proveedor de IA?
La due diligence del proveedor de IA va más allá de la compra tradicional de software. Tactical Management aplica cuatro dimensiones: transparencia del modelo, arquitectura de protección de datos, estrategia de salida y estabilidad financiera del proveedor. Ninguna de ellas es accesoria.
La transparencia del modelo exige documentación sobre datos de entrenamiento, pruebas de sesgo y límites de rendimiento. Sin esta información, la empresa usuaria asume riesgos bajo el Reglamento de IA que pueden traducirse en multas de hasta el siete por ciento de la facturación global anual. La arquitectura de protección de datos responde a quién accede a los inputs y si se reutilizan para reentrenar el modelo, cuestión crítica bajo el artículo 5 del RGPD.
La estrategia de salida se evalúa antes de contratar, no después. Capas de abstracción como LangChain o LlamaIndex permiten diseñar aplicaciones que aíslan el modelo subyacente, de modo que una subida de precios o una interrupción de servicio no paralice la operación. La estabilidad financiera del proveedor es una variable infravalorada: OpenAI, Anthropic y Mistral operan aún con pérdidas significativas según las cifras recogidas en ALGORITHMUS, y el colapso de un proveedor activo puede desencadenar crisis operativas en cadena.
¿Qué gobierno corporativo exige la matriz en el consejo?
El consejo no decide modelos; decide principios y umbrales. Dr. Raphael Nagel (LL.M.) propone tres preguntas que deben formalizarse en acta para cada dominio funcional: ¿es diferencial competitivamente?, ¿son los datos demasiado sensibles para externalizarlos?, ¿disponemos internamente de la capacidad para construir o controlar?
La responsabilidad de administradores en esta materia se ha densificado. La Directiva NIS2, que debía transponerse en octubre de 2024, establece responsabilidad personal de consejos y direcciones generales en la implementación de medidas de ciberseguridad en sectores esenciales, con sanciones de hasta diez millones de euros o el dos por ciento de la facturación global. Una delegación ligera de la decisión Build, Buy o Control expone directamente al órgano de administración.
Tactical Management recomienda que el consejo reciba un informe trimestral que inventaríe los sistemas de IA en uso, su clasificación bajo el Reglamento de IA, la decisión Build, Buy o Control aplicada a cada uno y la estrategia de salida documentada. Ese reporting convierte la matriz en instrumento de supervisión real, no en marketing corporativo. La alternativa, como advierte ALGORITHMUS, es descubrir la dependencia el día en que el proveedor sabe que es insustituible.
La decisión Build, Buy o Control no es una cuestión técnica delegable a la dirección de sistemas. Es una decisión de soberanía competitiva y jurídica que corresponde al consejo y a la dirección general. Dr. Raphael Nagel (LL.M.) insiste en ALGORITHMUS, Quien controla la IA, controla el futuro en que la empresa que no formaliza esta matriz termina aplicando, sin saberlo, la matriz que su proveedor elige por ella. Esa asimetría no se manifiesta en el primer contrato, sino cuando el proveedor ajusta precios, modifica condiciones o interrumpe un servicio del que depende la operación. En un mercado donde la ventana regulatoria se cierra con el Reglamento de IA, la NIS2 y las obligaciones derivadas del CLOUD Act, la matriz Build, Buy o Control es el instrumento que permite distinguir entre infraestructura comprable y ventaja defendible. Tactical Management acompaña a consejos y direcciones en esta formalización, integrando la decisión en la estrategia financiera, la due diligence de proveedores y la gobernanza reportable al órgano de administración. Quien aplaza esta decisión, delega su posición competitiva en terceros que responden ante sus propios accionistas, no ante los de la empresa.
Preguntas frecuentes
¿Cuándo justifica una mediana empresa la estrategia Build frente a Buy?
La estrategia Build se justifica cuando la capacidad algorítmica define el núcleo competitivo, los datos de entrenamiento son propietarios y no pueden compartirse, y existe capital humano suficiente para mantener el sistema en el tiempo. Para la mayoría de medianas empresas industriales europeas, Build completo carece de sentido económico; la vía realista es Control mediante fine-tuning sobre modelos open source como LLaMA 3 o Mistral, preservando la soberanía sobre los datos.
¿Qué papel juega el Reglamento de IA en la decisión Build, Buy o Control?
El Reglamento de IA de la UE, aprobado en marzo de 2024, clasifica ciertos sistemas como de alto riesgo, incluidos los de recursos humanos, crédito, infraestructura crítica y servicios esenciales. Estos sistemas exigen documentación técnica, trazabilidad, supervisión humana y auditoría. Cuando un proceso entra en esa categoría, la vía Buy con una API opaca resulta inviable y desplaza la decisión hacia Control o Build sobre infraestructura auditable.
¿Cómo afecta el CLOUD Act estadounidense a esta matriz?
El CLOUD Act de 2018 permite a autoridades estadounidenses requerir, bajo determinadas condiciones, datos alojados por empresas estadounidenses incluso en servidores europeos. Para sectores regulados como banca, sanidad o defensa, esa posibilidad jurídica desplaza la decisión hacia Control en infraestructura soberana europea, aunque el coste nominal de un hiperescalador estadounidense sea menor. La prima de soberanía se paga como seguro frente a escenarios de conflicto regulatorio.
¿Qué riesgos acumula la estrategia Buy pura?
La estrategia Buy pura acumula tres riesgos: dependencia de precios, inestabilidad del proveedor y pérdida de competencia interna. OpenAI modificó precios y condiciones varias veces entre 2022 y 2024; Gartner estima en doce a dieciocho meses la migración completa desde un hiperescalador. Sin capas de abstracción como LangChain y sin una estrategia de salida documentada, el Buy se convierte en dependencia estructural que erosiona la posición negociadora de la empresa.
¿Qué responsabilidad asume el consejo de administración al aprobar la matriz?
Bajo la Directiva NIS2 y el Reglamento de IA, el consejo asume responsabilidad personal por la implementación de medidas de seguridad y gobernanza en sistemas esenciales. Esto incluye aprobar explícitamente la clasificación Build, Buy o Control para sistemas de alto riesgo, exigir documentación de la estrategia de salida y recibir reporting periódico. Tactical Management recomienda formalizar estas decisiones en acta, ya que las sanciones alcanzan diez millones de euros o el dos por ciento de la facturación global.
Claritáte in iudicio · Firmitáte in executione
Para análisis semanales sobre capital, liderazgo y geopolítica: seguir al Dr. Raphael Nagel (LL.M.) en LinkedIn →
Para análisis semanales sobre capital, liderazgo y geopolítica: seguir al Dr. Raphael Nagel (LL.M.) en LinkedIn →