Estrategia de AI · 23 de mayo de 2026 · 24 min. de lectura · Mohsen Ghulami, GTM Engineer, Amplifa

Estrategia de AI: Build vs. Buy en las medianas empresas

Estrategia de AI en las medianas empresas: decida Build vs. Buy con cifras, casos y criterios claros antes de que su PoC consuma el presupuesto.

Hace tres semanas me encontraba en Gütersloh, en una sala de reuniones que olía a café de filtro y plástico caliente. Thomas, CTO de un fabricante de maquinaria con 280 empleados, me desliza su iPad y dice: "Ahora estamos construyendo nuestra propia plataforma de AI". En el patio pita un montacargas dando marcha atrás; dentro, parpadea una diapositiva de PowerPoint con el logotipo de Azure, la serpiente de Python y un bloque de presupuesto de 1,2 millones de euros. Mi primera pregunta no fue técnica, sino brutalmente simple: ¿es esto realmente una estrategia de AI o solo un desvío costoso hacia el próximo software estándar?

Escribo sobre la industria desde 1998. He visto en Trumpf, en Ditzingen, cómo los datos de los sistemas de corte por láser se convierten en un negocio de servicios. He presenciado en pequeños talleres de subcontratación en la Jura de Suabia cómo la falta de una sola exportación MES detiene un proyecto de AI completo. Y he visto a suficientes CFO apretar los labios al oír la palabra "desarrollo propio", como si hubieran mordido un limón.

Por tanto, Build vs. Buy en AI no es una cuestión de fe. Es una cuestión de asignación de capital. Una mediana empresa de 50 a 500 empleados que quiera construir cada modelo de forecasting por sí misma quemará tiempo, salarios y nervios. Pero quien compre cada función de AI, aunque esta marque la diferencia en su propio producto, regalará margen a proveedores que no entienden el negocio. He visto ambas cosas. Ambas duelen.

Por qué la estrategia de AI se convierte ahora en una prioridad de la dirección

En marzo de 2025 estuve con un proveedor cerca de Heilbronn, 410 empleados, mucho mecanizado, poca paciencia. Andrea, Head of Operations, me mostró una línea con seis centros de mecanizado de DMG Mori. El sonido era ese canto metálico y duro característico de las naves donde nadie habla del futuro porque el pedido debe salir el viernes. "Tenemos cuatro PoC de AI", dijo Andrea. "Ninguno funciona en producción".

Exactamente ahí se encuentra la mediana empresa. No al principio del debate sobre la AI, sino tras el primer desencanto. ChatGPT abrió la puerta en 2023, Microsoft Copilot ha llegado a muchas empresas, SAP introduce funciones de AI en su suite y uno de cada dos proveedores de software ya pega una etiqueta de AI en su hoja de ruta. Solo que: en la nave, en ventas, en el servicio, ocurre menos de lo que afirman los escenarios de las conferencias.

Las cifras coinciden con esta observación. Según el estudio de Bitkom de 2024, alrededor del 15 al 20 por ciento de las empresas en Deutschland utilizan la AI de forma productiva; en empresas de entre 100 y 499 empleados, la cuota se sitúa más bien en el rango inferior, aproximadamente del 10 al 15 por ciento. BCG y VDMA llegaron en 2023 en la construcción de maquinaria a un patrón que escucho constantemente en las conversaciones: más del 60 por ciento experimenta con PoC de AI, pero menos del 15 por ciento tiene aplicaciones escaladas en la empresa. Es decir: mucho piloto, poca operación.

Esto no es una ley natural en Deutschland. A menudo es una mala toma de decisiones. La mediana empresa trata la AI con demasiada frecuencia como una adquisición tecnológica y con muy poca como una cuestión de creación de valor. En una empresa de 180 empleados de Augsburg, Jens, director comercial, me dijo en enero de 2025: "No podemos permitirnos un error". Cierto. Pero no decidir también es un error. Solo que más silencioso.

Estrategia de AI en la mediana empresa: qué significa realmente Build vs. Buy

Build no significa que tres Data Scientists entrenen un Foundation Model en el sótano. Bueno, casi nunca. Build significa en la mediana empresa generalmente: pipelines de datos propios, modelos propios o al menos lógica de dominio propia, procesos de MLOps propios, monitoreo propio, responsabilidad propia. El proveedor quizás entrega la infraestructura de Cloud, pero la empresa asume el riesgo del producto y de la operación.

Buy no significa que se compre un software y el lunes se ahorre un 15 por ciento de mermas. Quien crea eso, nunca ha visto una interfaz entre un ERP antiguo, una exportación de Excel y el control de una máquina. Buy significa: comprar software estándar, SaaS o componentes de plataforma, configurar, integrar, formar, medir. Eso es trabajo. Pero es un trabajo diferente al de la construcción de modelos.

La frontera más nítida no discurre entre Cloud y On-Prem. Discurre entre Commodity y diferenciación. Forecasting, NLP estándar, clasificación de imágenes, optimización de rutas, asistencia en ofertas, motores de recomendación simples: para eso existen productos útiles. La AI en el núcleo del producto, como sensores inteligentes, navegación autónoma, control de procesos propietario o un algoritmo de servicio que aprende de 15 años de datos de máquinas: ahí Build puede tener sentido. Puede. No debe.

PwC y Roland Berger describen desde 2023 un patrón que también aparece en mis conversaciones: las medianas empresas más pequeñas optan predominantemente por Buy o Configure, las medianas empresas más grandes eligen con más frecuencia Hybrid. La empresa de 300 personas suele comprar Microsoft, SAP, Cognex, Celonis, o9, PTC o un proveedor especializado. El proveedor de 3.000 personas quizás construye un Analytics Competence Center y desarrolla allí donde reside la creación de valor. Esto suena banal. Sin embargo, se ignora constantemente.

Las cifras duras: costes, cronogramas, tasas de éxito

En los últimos dos años he hablado en München, Stuttgart, Bielefeld y Linz con responsables digitales que gestionan sus presupuestos de AI en Excel, no en comunicados de prensa. Los rangos son sorprendentemente estables. Un PoC de Build en la mediana empresa suele situarse entre 100.000 y 300.000 euros por tres a seis meses. Hasta que un MVP funciona de forma productiva, son realistas entre 300.000 y 800.000 euros, sin contar siempre correctamente los costes de personal interno. Y es precisamente ahí donde comienza el autoengaño.

Porque el Data Scientist no es gratuito solo porque ya esté en nómina. El ingeniero de producción que revisa etiquetas ocho horas a la semana, tampoco. La arquitecta de IT que aclara las autorizaciones de seguridad, mucho menos. En una planta cerca de Ulm, en febrero de 2025, olía a lubricante refrigerante mientras Martin, director de IT, me decía: "Externamente solo hemos gastado 180.000 euros". Dos horas después me mostró la estimación de esfuerzo interno. Con la prestación propia, el proyecto se situaba en 520.000 euros.

Buy o Configure comienza más bajo. Licencia piloto más integración: frecuentemente de 50.000 a 250.000 euros. Despliegue en varias plantas o áreas: de 150.000 a 800.000 euros. Los costes de licencia recurrentes para muchos escenarios de medianas empresas se sitúan entre 50.000 y 200.000 euros al año, dependiendo de los usuarios, el volumen de datos y el humor del proveedor. Sí, el humor del proveedor. Quien haya negociado una renovación de SaaS en el tercer año de contrato sabe a qué me refiero.

Las tasas de éxito son el verdadero golpe de realidad. McKinsey informó en el State of AI 2023 que solo entre el 20 y el 30 por ciento de las empresas obtienen beneficios financieros significativos de los proyectos de AI. En la fabricación y bienes industriales, según mi experiencia y los benchmarks de consultoras, entre el 50 y el 70 por ciento de los PoC mueren antes de ver una operación real. En Build, a menudo solo el 30 al 40 por ciento logra el salto a la producción. En Buy o Configure, más bien del 50 al 70 por ciento. No porque los proveedores hagan magia. Sino porque hay menos riesgo base en el modelo.

Build vale la pena, pero con menos frecuencia de lo que afirman las diapositivas de los fundadores

Me gusta el desarrollo propio. De verdad. Existe ese momento en que un equipo no solo entrena un modelo, sino que lo integra en un proceso, los usuarios lo tocan, el indicador se mueve y el director de planta ya no habla de "esa cosa de la AI", sino de su nueva herramienta. Eso es potente. Solo que no ocurre porque alguien haya instalado PyTorch.

Trumpf es un buen ejemplo, pero también una advertencia. La empresa familiar de Ditzingen tiene unos 16.500 empleados, datos profundos de máquinas, historia propia de plataformas con AXOOM y un ecosistema alrededor de TruConnect. Desde aproximadamente 2017, Trumpf invierte continuamente en servicios digitales, mantenimiento predictivo y funciones de Smart Factory. En presentaciones públicas, Trumpf habla de hasta un 20 a 30 por ciento menos de tiempos de inactividad en ciertas instalaciones gracias al mantenimiento predictivo. Esto no es un proyecto secundario de IT. Es negocio de productos y servicios.

Kärcher, de Winnenden, es igualmente interesante. El KIRA B 50, un robot de limpieza autónomo, necesita Computer Vision, navegación, fusión de sensores y software robusto en el producto físico. Un recomendador estándar de la Cloud ayuda poco ahí. Kärcher ha desarrollado competencias digitales desde aproximadamente 2018, entre otros en el Digital Hub, y combina el desarrollo propio con componentes de Cloud. Aquí Build no es prestigio. La AI está en el dispositivo, en el precio, en el contrato de servicio.

Ese es el punto: Build compensa cuando la AI cambia el beneficio para el cliente o refleja un proceso que los competidores no pueden copiar fácilmente. Un fabricante de máquinas herramienta con miles de millones de datos históricos de sensores tiene un punto de partida diferente al de un mayorista de 220 personas que quiere mejorar el cross-selling en la tienda web. Quien desdibuja estas diferencias, empieza la casa por el tejado.

Solo desarrollamos nosotros mismos allí donde vemos una ventaja competitiva clara y nuestro conocimiento de procesos o productos es único. El análisis estándar y los modelos de lenguaje los compramos.

— según el sentido de las palabras de un CDO de un fabricante de maquinaria alemán, conversación con Handelsblatt 2024

Nicole Büttner, de Merantix Momentum, ha enfatizado algo similar en formatos de EY sobre el "Futuro de Deutschland": la mediana empresa tiene una ventaja con sus propios datos, pero a menudo debería comprar modelos y plataformas y dominar ella misma la lógica del dominio. Suscribo esto. Los datos por sí solos no son un foso defensivo. Solo cuando se unen datos, conocimiento del proceso y canal de distribución, Build se vuelve interesante.

Buy-first no es una capitulación, sino disciplina

En Münster conocí en noviembre de 2024 a un gerente de logística, Ralf, que anteriormente participó en proyectos de pronóstico en Fiege. Estábamos en una cantina, olía a salsa de asado y del almacén llegaba ese rodar sordo de la tecnología de transporte. "Podríamos haberlo construido todo nosotros mismos", dijo. "¿Pero para qué?". Fiege utiliza en diversas áreas servicios de Cloud, componentes de Azure y soluciones de socios, por ejemplo para pronósticos y optimización. Los casos de uso publicados hablan de una reducción de existencias del 2 al 5 por ciento y de una mejora de la Forecast Accuracy del 3 al 8 por ciento, según el campo.

Esa es la realidad de la mediana empresa, solo que a una escala mayor. Un forecast rara vez es único. Una optimización de rutas tampoco. Una inspección de calidad basada en imágenes con clases de error definidas es técnicamente exigente, pero a menudo no es motivo para crear un equipo de Vision propio. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx o proveedores especializados tienen sus fallos. Por supuesto. Pero no empiezan de cero.

Un caso anonimizado del sur de Deutschland muestra la lógica con claridad. Fabricante de maquinaria, 800 empleados, inspección visual manual, falta de personal, alta presión de retrabajo. La empresa compró un sistema comercial de Vision AI en lugar de un desarrollo propio. Inversión inicial: unos 350.000 euros para hardware, licencias, integrador y formación. Cuatro meses de PoC, tres meses de despliegue en dos líneas. Tras doce meses, la tasa de error era aproximadamente un 30 por ciento menor, amortización en menos de 18 meses. Sin premio a la innovación. Pero con dinero.

Sé que Buy suena demasiado pequeño para algunos CTO. No se quiere simplemente "configurar". Se quiere crear. Comprensible. Solo que el cliente no paga por el orgullo del departamento de IT. Paga por la capacidad de entrega, calidad, servicio, estabilidad de precios. Si el software estándar aporta el 80 por ciento del beneficio en un tercio del tiempo, entonces el desarrollo propio es a menudo vanidad con planificación de sprint.

La segunda verdad: Buy puede volverse caro, lento y peligroso

Ahora la autocorrección. Buy-first no significa Vendor-first. He visto proyectos de SaaS que después de dos años parecían un piso de alquiler tras diez subarrendatarios: adaptadores por todas partes, ya nadie sabe de quién es la llave. Un proveedor de 260 personas de la Baja Baviera pagó en 2024 licencias moderadas por tres herramientas cercanas a la AI en ventas, servicio y planificación. Junto con las interfaces, la consultoría y los administradores internos, los costes anuales se situaron de repente en 310.000 euros. ¿Utilidad? Difícil de medir. "Ahora tenemos Dashboards", dijo el jefe de ventas. Sentí lástima por él.

El mayor error de Buy es la fe ciega en las funciones. Una demo de software siempre muestra datos limpios. Siempre. En la operación real aparecen bases de clientes duplicadas, falta de jerarquías de artículos, modelos de turnos divergentes y un campo de ERP llamado "Otros" que desde 2009 contiene todo lo que nadie quería clasificar. SAP, Microsoft, Siemens o PTC pueden amortiguar mucho. Pero no reparan una organización que desprecia sus datos maestros.

El segundo error es el Lock-in sin contraprestación. Si un proveedor controla todo el almacenamiento de datos, la lógica del modelo, la interfaz de usuario y la integración de procesos, la empresa se vuelve dependiente. Esto puede ser aceptable si el caso de uso es Commodity y el proveedor entrega de forma estable. En procesos centrales críticos, se debe ser más cauteloso. Exportación de datos, capacidad de auditoría, costes al escalar, escenario de salida: temas aburridos, sí. Precisamente por eso se leen demasiado tarde.

Dónde mueren los proyectos de Build en la mediana empresa

Hay una escena que se repite. Sala de reuniones, alfombra gris, pizarra blanca con restos de un taller, en algún lugar aún pone "Priorización de casos de uso". En la sala están IT, el área especializada y un consultor externo. Tras 14 meses de proyecto, alguien pregunta: "¿Quién es realmente el Product Owner?". Entonces se hace el silencio. He vivido esto en Köln, Nürnberg y St. Gallen.

La primera causa de muerte se llama calidad de datos. No es sexy, pero es letal. Un proveedor de automoción con unos 3.000 empleados inició durante tres años varios PoC de mantenimiento predictivo junto con un instituto de investigación. Esfuerzo: más de un millón de euros, incluyendo tiempo interno. Todos los pilotos se quedaron estancados en instalaciones individuales. OT e IT estaban separadas, no había un Lakehouse central, el mantenimiento se integró tarde y el histórico de datos no coincidía con la lógica de fallos. Tras un cambio en la dirección de IT, se pasó a una plataforma estándar. Nueve meses después funcionaban los primeros casos de uso productivos; tras 18 meses, se reportaron alrededor de un 15 por ciento menos de fallos no planificados en instalaciones seleccionadas.

La segunda causa de muerte se llama falso orgullo. Un distribuidor B2B de la región DACH con unos 1.200 empleados quería construir su propio motor de recomendación, también para reducir la dependencia de las plataformas Cloud de EE. UU. Equipo de Data Science de cinco personas, Python, Scikit-Learn, más tarde TensorFlow. Dieciocho meses de desarrollo, aproximadamente de 1 a 1,5 millones de euros. Al final, el rendimiento según las pruebas internas era solo del 60 al 70 por ciento de un recomendador de Cloud estándar. El proyecto se detuvo, la solución SaaS llegó de todos modos. Solo que más tarde y más cara.

La tercera causa de muerte es la falta de mentalidad de producto. La AI se inicia como un proyecto, no se opera como un producto. Hay un PoC, un informe final, aplausos en el comité de dirección. Después, el modelo deriva, nadie mide la cuota de usuarios, nadie planifica el reentrenamiento, nadie se siente responsable de las falsas alarmas. Tras seis meses, el jefe de turno dice: "Esta cosa falla". Y de repente la aceptación desaparece.

MLOps no es aquí una palabra de moda, sino trabajo de mantenimiento para modelos. Monitoreo, versionado de datos, procesos de aprobación, rollback, responsabilidades, rastro de auditoría. Suena seco. Lo es. Pero sin estas rutinas, la AI se convierte en software de un solo uso. Se construye, se muestra, se olvida.

La matriz Build-vs.-Buy para una estrategia de AI sólida

En las conversaciones me gusta usar una matriz 2×2 simple. Sin magia. En el eje X está el potencial de diferenciación: ¿esta función de AI nos hace más difíciles de copiar en el mercado? En el eje Y está la estandarizabilidad: ¿existe software maduro que cubra del 70 al 80 por ciento de la tarea? Si ambos ejes se evalúan con honestidad, muchos proyectos favoritos caen.

Cuadrante uno: alto potencial de diferenciación, baja estandarizabilidad. Aquí se puede considerar seriamente Build o Co-Build. Ejemplos: AI en un dispositivo médico con sensores especiales, funciones autónomas en una máquina de limpieza, control de procesos en un procedimiento de producción propio. Kärcher, Trumpf, Wittenstein o Festo piensan en tales categorías. Ahí la AI está cerca del producto o del secreto del proceso.

Cuadrante dos: bajo potencial de diferenciación, alta estandarizabilidad. Comprar. Punto. Forecasting estándar, clasificación de textos en atención al cliente, chatbots simples, revisión de gastos, Lead Scoring, inspección de imágenes con patrones de error conocidos. Quien predique Build aquí, debería poner los costes de oportunidad sobre la mesa. No como una diapositiva. Como una cantidad en euros.

Cuadrante tres: alto potencial de diferenciación, alta estandarizabilidad. Esta es la zona híbrida emocionante. Un LLM puede generar borradores de ofertas, pero la lógica de producto propia, las reglas de descuento, la capacidad de entrega y las cláusulas de responsabilidad deben provenir de la empresa. Microsoft Copilot o SAP Joule pueden entregar interfaces, pero el cerebro del negocio reside en el modelo de datos propio. Es precisamente ahí donde las medianas empresas deben desarrollar competencia.

Cuadrante cuatro: bajo potencial de diferenciación, baja estandarizabilidad. Generalmente una señal de advertencia. Si algo no es ni estratégicamente importante ni fácil de comprar, ¿por qué debería hacerse? ¿Porque un jefe de área lo quiere? ¿Porque hay un programa de subvenciones a la vista? El dinero de las subvenciones no es un Business Case. No hay vuelta de hoja.

Cálculo del ROI: por qué el inicio más barato puede terminar siendo caro

En junio de 2025 me llamó un gerente de Ravensburg. 120 empleados, construcción de maquinaria especial, EBIT decente, pero IT escasa. Preguntó: "¿Cuánto nos cuesta una AI para la automatización de ofertas?". Yo le pregunté: "¿Cuánto cuesta una oferta hoy?". Silencio. Luego, paso de hojas. Luego, la cifra: aproximadamente 1.800 euros de esfuerzo interno en máquinas complejas, cuando participan ventas, diseño y compras.

Solo con tales cifras Build vs. Buy se vuelve tangible. Si una empresa escribe 900 ofertas complejas al año y un sistema de asistencia de AI reduce el tiempo de ciclo en un 25 por ciento, no estamos hablando de un juego. Estamos hablando de capacidad, reacción más rápida, menos errores en listas de materiales, mejor seguimiento. Si la solución se compra, se construye o es híbrida, se decide por el payback, no por el instinto del CTO.

Comparativa sectorial: construcción de maquinaria, comercio, logística, automoción

La construcción de maquinaria es Build-seductora. Las empresas tienen autoconfianza técnica, muchos ingenieros, buenos datos de producto y a menudo una cultura de hacerlo uno mismo. En DMG Mori, Trumpf, Wittenstein o Festo, esta actitud tiene sentido en funciones de AI cercanas al producto. En un fabricante de instalaciones de 180 personas de la Alta Franconia que quiere construir su propia AI de texto para informes de servicio, más bien no. El olor a aceite hidráulico no hace que un modelo de NLP sea propietario.

El comercio y la distribución B2B deberían pensar casi siempre en Buy-first. Recomendación, Pricing, pronóstico de existencias, clústeres de clientes, gestión de campañas: estos son campos con muchos proveedores y mucha experiencia. La diferenciación reside allí menos en el algoritmo que en la calidad de los datos, la lógica del surtido, las condiciones de compra y la ejecución de ventas. Un comerciante de Essen me dijo en abril de 2025: "Queríamos replicar la lógica de Amazon nosotros mismos". Yo pregunté: "¿Por qué no empezar vendiendo como Amazon?". No se rió.

La logística es más pragmática. Quizás porque allí cada punto porcentual se traduce inmediatamente en palés, kilómetros y planes de turnos. Fiege, Dachser o Rhenus trabajan con plataformas, socios y equipos propios allí donde encaja. Buy para optimización estándar, Build o Co-Build en datos de red especiales y planificación específica del cliente. El suelo de la nave decide. No el departamento de estrategia.

Los proveedores de automoción están entre dos aguas. Tienen volumen, presión de calidad, requisitos de Traceability y directrices de OEM. Predictive Quality, mantenimiento, inspección visual y AI de planificación son atractivos. Pero muchas plantas han crecido históricamente, los datos OT están fragmentados y al comité de empresa se le debe consultar pronto. Quien inicie Build allí sin una plataforma de datos, acabará en el pantano de los PoC. Lo he visto demasiadas veces.

Ejemplo práctico: 320 empleados, 14 meses, un híbrido honesto

Un caso que puedo contar de forma anonimizada: fabricante de componentes de Baden-Württemberg, 320 empleados, facturación de casi 75 millones de euros, clientes de construcción de maquinaria y tecnología médica. Estuve allí en octubre de 2024. En el control de calidad olía a limpiador de alcohol; bajo una lámpara LED había piezas fresadas en bandejas grises. Sabine, directora de calidad, dijo: "Perdemos tiempo porque vemos los errores demasiado tarde".

La empresa tenía tres ideas de AI: Vision AI para inspección de calidad, forecasting en compras, asistencia en ofertas para piezas especiales. Antes probablemente se habrían iniciado tres PoC. Esta vez no. El gerente pasó cada idea por la matriz. Vision AI: Buy. Forecasting: Buy/Configure. Asistencia en ofertas: Hybrid, porque la lógica de viabilidad técnica y las reglas de variantes eran realmente propias de la empresa.

Las cifras tras 14 meses: el piloto de Vision AI para dos familias de piezas costó unos 210.000 euros, incluyendo cámara, iluminación, integrador y formación. El escape de errores bajó un 28 por ciento, el retrabajo un 11 por ciento. El forecasting se introdujo a través de un módulo del socio de ERP existente más una pipeline de datos externa, coste aproximado de 95.000 euros; la Forecast Accuracy aumentó en las piezas A en 6 puntos porcentuales. La asistencia en ofertas costó más: unos 380.000 euros, porque se integraron CPQ, reglas cercanas a CAD e históricos de precios. A cambio, el tiempo de ciclo promedio de ofertas complejas bajó de 9,5 a 6,8 días laborables.

Más importante que las cifras individuales fue la gobernanza. Hubo un Product Owner por caso de uso, revisión mensual de KPI, criterios de interrupción claros y un pequeño núcleo de datos: un Data Engineer, una Analytics Engineer, un arquitecto externo por seis meses. Sin laboratorio de AI con pufs. Sin circo de innovación. Solo trabajo.

Amplifa ICP Playbook — Playbook práctico para definir limpiamente clientes objetivo, fuentes de datos y prioridades antes de que la AI en ventas o en la generación de leads queme dinero.

FAQ: ¿Cuándo debería una mediana empresa construir AI por sí misma?

Una mediana empresa debería construir AI por sí misma cuando se cumplen tres condiciones simultáneamente: la función crea diferenciación ante el cliente, los datos necesarios son propietarios y sólidos, y la empresa puede financiar la operación, el monitoreo y el desarrollo posterior. Si falta una de estas condiciones, yo solo permitiría Build con un socio y una línea de parada estricta. Un ejemplo: el diagnóstico de estado inteligente para máquinas propias con datos de sensores exclusivos puede justificar Build. Un chatbot estándar para consultas de servicio, no.

FAQ: ¿Cuál es la mejor estrategia de AI para 50 a 500 empleados?

Para empresas de entre 50 y 500 empleados, la mejor opción suele ser una estrategia híbrida Buy-first. Software estándar para casos de uso Commodity, lógica de dominio propia para procesos diferenciadores, pequeño equipo interno central para datos y responsabilidad del producto. Esto suena menos heroico que "estamos construyendo nuestra propia plataforma". Funciona con más frecuencia. Según Bitkom 2024, el uso productivo de AI en la mediana empresa alemana es aún bajo; precisamente por eso el Time-to-Value cuenta más que el orgullo técnico.

FAQ: ¿Cómo se evita la trampa del PoC en la AI?

Se evita con criterios de parada antes de que comience el primer taller. Ejemplo: si una solución de Vision AI no muestra una detección al menos un 10 por ciento mejor que el muestreo manual tras doce semanas, se detiene o se redefine. Si una asistencia en ofertas no aporta un ahorro de tiempo medible tras seis meses, sale de la cartera. Suena duro. Pero es más barato que 18 meses de esperanza.

Recomendaciones de acción: 7 pasos para la decisión Build-vs.-Buy

Como gerente, CTO o responsable digital, yo no empezaría con la selección de herramientas. Tampoco con un taller de AI donde al final 47 casos de uso cuelguen en post-its y nadie sepa quién los paga. Haría siete cosas. Exactamente en este orden.

1. Inventaríe posibles casos de uso de AI en producción, ventas, servicio y back office. Escriba junto a cada caso de uso un indicador: merma, parada, duración de oferta, conversión, existencias, costes de reclamación. Sin indicador no hay caso de uso.
2. Evalúe cada caso de uso con la matriz 2×2: potencial de diferenciación frente a estandarizabilidad. Realice la evaluación en un círculo pequeño con la gerencia, el área especializada e IT. No en un taller de 18 personas.
3. Defina una regla de Buy-first para temas Commodity. Forecasting, análisis de texto estándar, Vision Inspection simple, automatización de CRM y recomendación solo deberían ser Build si existe una razón de negocio por escrito.
4. Establezca criterios de parada. Límite de tiempo, KPI mínimo, disponibilidad de datos, aceptación del usuario. Un PoC sin línea de parada no es un experimento, sino un riesgo de costes con un nombre amable.
5. Cree un pequeño equipo central. Para 50 a 500 empleados suele bastar: un Data Engineer o Analytics Engineer, un Product Owner fuerte por caso de uso, un arquitecto de IT a tiempo parcial, especialistas externos para fases limitadas.
6. Integre la AI en los sistemas existentes. Nada de portales de AI aislados si los usuarios trabajan en el ERP, CRM, MES, CPQ o sistema de tickets. La AI debe aparecer allí donde el trabajo ocurre de todos modos.
7. Informe trimestralmente sobre aplicaciones de AI productivas, no sobre PoC. Muestre el impacto de negocio, la cuota de usuarios, los costes, los riesgos abiertos. El CFO debería entender la tabla sin tener que buscar en Google "Embedding".

Amplifa Producto — Automatización de ventas asistida por AI para equipos B2B que no quieren plantear la generación de leads, el refinamiento de ICP y el Outreach como un proyecto de bricolaje.

Gobernanza: ¿quién decide, quién responde, quién detiene?

La gobernanza de AI suena a gran corporación. No es del todo cierto. Precisamente la mediana empresa la necesita porque los caminos son cortos y los errores se vuelven personales rápidamente. Si una AI recomienda aprobaciones de calidad erróneas, el tema no acaba en un comité de riesgos anónimo. Acaba en Sabine en QS, en Thomas en ingeniería y en el gerente si el cliente reclama.

Una gobernanza útil para 50 a 500 empleados no tiene por qué ser extensa. Necesita cuatro roles: Business Owner, Product Owner, responsable técnico, revisor de riesgos o cumplimiento. El Business Owner responde por la utilidad. El Product Owner responde por el uso y la hoja de ruta. La técnica mantiene limpia la operación, la seguridad y el flujo de datos. Cumplimiento revisa la protección de datos, temas del comité de empresa, relevancia del EU AI Act y capacidad de auditoría. Cuatro nombres. No "la IT".

El EU AI Act será más perceptible gradualmente a partir de 2025 y 2026, especialmente en aplicaciones de alto riesgo. Muchos casos de uso de medianas empresas no entran en la clase de riesgo más alta, pero la documentación, la transparencia y la responsabilidad ganarán importancia. Quien introduzca hoy una AI en decisiones de calidad, procesos de personal o pasos de producción cercanos a la seguridad, no debería esperar a que el auditor esté en el vestíbulo.

La gobernanza también decide Build vs. Buy. En Buy, usted debe auditar al proveedor: procesamiento de datos, transparencia del modelo, hosting, conceptos de borrado, acceso, logs de auditoría. En Build, usted debe poder hacer todo eso por sí mismo. ¿Sinceramente? Muchas empresas de 200 personas no pueden. Esto no es un reproche. Es un criterio de decisión.

Stack tecnológico: lo que las medianas empresas necesitan realmente

Si Build o Hybrid tienen sentido, no se necesita un zoológico tecnológico. Veo con demasiada frecuencia imágenes de arquitectura con Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes y otros cinco logotipos, aunque la empresa todavía envíe archivos CSV del ERP por correo electrónico. Eso no es estrategia. Eso es coleccionar logotipos.

Para muchas medianas empresas basta con un stack claro: almacenamiento de datos central o Lakehouse, interfaces estables con ERP/CRM/MES, una herramienta de MLOps para versionado de modelos y monitoreo, concepto de permisos, reporting. Azure es fuerte en la mediana empresa de la región DACH, a menudo debido a los contratos de Microsoft 365 y la competencia de IT existente. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core o Siemens Industrial Edge pueden encajar. La pregunta no es qué logotipo suena más moderno. La pregunta es quién lo opera.

El Open Source no es comida gratis. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow: todas son buenas herramientas. Pero alguien debe mantener las dependencias, revisar las actualizaciones de seguridad, supervisar los modelos, detectar derivas, reparar pipelines. En un turno de tarde, a nadie le importa si el error proviene del Feature Store o de la interfaz del PLC. La línea está parada.

En Buy/Configure, el stack se ve diferente. Siemens Industrial Edge o Insights Hub para datos industriales, PTC ThingWorx para escenarios cercanos al IoT, SAP AI Core y Joule en el entorno ERP, Microsoft Dynamics 365 con Copilot para procesos de CRM, Celonis para Process Mining, o9 o SAS para planificación, Cognex o Landing AI para Vision. Estos productos no resuelven todos los problemas, pero dan estructura. Para muchas medianas empresas, la estructura ya es la mitad del ROI.

Amplifa para estrategia de ventas con AI — Para empresas B2B medianas que quieren utilizar la AI de forma productiva en las ventas, sin tener que construir primero su propia plataforma de Outreach y datos.

Change Management: la nave también decide

En diciembre de 2024 estuve en una empresa cerca de Pforzheim. 160 empleados, piezas de precisión, mucho trabajo manual en la inspección. Un joven jefe de proyecto explicaba en un monitor una detección de errores asistida por AI. A mi lado estaba un inspector, quizás de unos cincuenta y tantos años, con los bordes de los dedos negros. Dijo en voz baja: "Si la caja se equivoca, la culpa es mía". Esa fue la frase más importante del día.

La introducción de la AI rara vez fracasa solo por la técnica. Fracasa por la responsabilidad. Si las personas creen que la AI les quita el trabajo, les endosa errores o devalúa su conocimiento empírico, no la usarán. Entonces se eludirá el sistema, se ignorarán las advertencias, los datos se mantendrán mal. Change Management no significa colgar carteles. Significa aclarar limpiamente los roles, la responsabilidad y la utilidad.

En Vision AI en el control de calidad debe estar claro: ¿la AI autoriza o recomienda? ¿Quién decide en casos límite? ¿Cómo se tratan los falsos negativos? ¿Cómo fluye el feedback de los inspectores al modelo? En la asistencia de ofertas en ventas debe estar claro: ¿puede la AI proponer precios? ¿Quién revisa los descuentos? ¿Qué afirmaciones a los clientes son tabú? Estas preguntas no son frenos. Son requisitos operativos.

El comité de empresa debe participar pronto, no después del piloto. Especialmente con la AI en la medición del rendimiento, planificación de turnos, HR o sistemas de asistencia con datos de uso. Conozco empresas que han perdido tres meses porque creían que la participación era un acto formal. No lo era. Era el despliegue real.

Lo que espero para 2026: menos teatro de PoC, más selección dura

Mi pronóstico es tajante: para finales de 2026, muchas medianas empresas reducirán sus carteras de AI a la mitad. No porque la AI decepcione. Sino porque las listas de proyectos de 2023 y 2024 eran demasiado amplias, demasiado técnicas y estaban mal calculadas. El CFO preguntará qué aplicaciones funcionan de forma productiva. Ventas preguntará por qué el asistente de ofertas aún no está en el CRM. Producción preguntará por qué el piloto solo funciona en la línea 3. Entonces se hará limpieza.

Al mismo tiempo, las buenas empresas serán más rápidas. No perseguirán 30 casos de uso, sino cinco. Tomarán software estándar allí donde baste y desarrollarán conocimiento propio allí donde duela si el competidor también lo tiene. No "harán AI". Reducirán mermas, acelerarán ofertas, aumentarán ingresos por servicios, reducirán existencias. Ese es otro tono.

El CTO de SAP, Jürgen Müller, ha enfatizado públicamente en varias ocasiones la integración de la AI generativa en la Business Suite. El mensaje para la mediana empresa es claro: no todos los clientes deben construir sus propios Foundation Models. Muchos deben consumir, integrar y controlar la AI. Considero que esto es saludable. Quien en 2026 todavía crea que una empresa de 250 personas debe fundar primero su propio laboratorio de AI antes de ver beneficios, confunde mediana empresa con instituto de investigación.

Al final queda la escena de Gütersloh. Thomas, el CTO con el plan de 1,2 millones de euros, me llamó dos semanas después de nuestra conversación. Habían detenido la idea de la plataforma, iniciado dos pilotos de Buy y mantenido un único caso de uso híbrido para su lógica de máquinas. "Se siente menos visionario", dijo. Al fondo volví a oír el pitido del montacargas. Quizás ese era precisamente el progreso.