Estrategia de IA: Construir vs. Comprar en PYMES

KI-Strategie · 23. Mai 2026 · Mohsen Ghulami

Estrategia de IA en PYMES: Decida Construir vs. Comprar con números, casos y criterios claros antes de que su PoC devore el presupuesto.

Hace tres semanas, estoy en Gütersloh, en una sala de reuniones que huele a café de filtro y plástico caliente. Thomas, CTO de un fabricante de maquinaria con 280 empleados, me empuja su iPad y dice: “Ahora vamos a construir nuestra propia plataforma de IA”. En el patio, una carretilla elevadora pita al retroceder, dentro, una diapositiva de PowerPoint parpadea con el logotipo de Azure, una serpiente 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 IA, o solo un costoso desvío hacia el próximo software estándar?

Escribo sobre la industria desde 1998. He visto en Trumpf en Ditzingen cómo los datos de las máquinas de corte por láser se convierten en negocio de servicios. He experimentado en pequeños fabricantes por contrato en la región de Suabia cómo un solo MES-export faltante detiene todo un proyecto de IA. Y he visto suficientes CFOs que aprietan los labios al oír la palabra “desarrollo propio” como si hubieran mordido un limón.

Construir vs. Comprar en IA no es, por lo tanto, una cuestión de fe. Es una cuestión de asignación de capital. Una PYME con 50 a 500 empleados que quiera construir cada modelo de pronóstico por sí misma, quema tiempo, salarios y nervios. Pero quien compra cada función de IA, aunque sea lo que marca la diferencia en su propio producto, regala margen a proveedores que no entienden el negocio. Ambas cosas las he visto. Ambas duelen.

Por qué la estrategia de IA se convierte ahora en asunto de la dirección

En marzo de 2025, estuve en un proveedor cerca de Heilbronn, 410 empleados, mucho mecanizado, poca paciencia. Andrea, Jefa de Operaciones, me mostró una línea con seis centros de mecanizado de DMG Mori. El sonido era ese canto metálico y duro que se conoce de las naves donde nadie habla del futuro porque el pedido debe salir antes del viernes. “Tenemos cuatro PoCs de IA”, dijo Andrea. “Ninguno funciona productivamente”.

Ahí es donde se encuentran las PYMES. No al principio del debate sobre la IA, sino después de la primera desilusión. ChatGPT abrió la puerta en 2023, Microsoft Copilot ha llegado a muchas empresas, SAP está impulsando funciones de IA en su suite, y cada dos proveedores de software ahora pegan una etiqueta de IA en su hoja de ruta. Solo que: en la nave, en ventas, en servicio, sucede menos de lo que afirman los escenarios de conferencias.

Las cifras coinciden con esta observación. Según el estudio Bitkom 2024, alrededor del 15 al 20 por ciento de las empresas alemanas utilizan la IA de forma productiva; en empresas entre 100 y 499 empleados, la tasa se encuentra más bien en el rango inferior, aproximadamente del 10 al 15 por ciento. BCG y VDMA llegaron en 2023 en la ingeniería mecánica a un patrón que escucho constantemente en las conversaciones: más del 60 por ciento experimenta con PoCs de IA, 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 alemana. A menudo es una mala toma de decisiones. Las PYMES tratan la IA con demasiada frecuencia como una adquisición tecnológica y con demasiada poca frecuencia como una cuestión de creación de valor. En una empresa de 180 empleados de Augsburgo, Jens, director comercial, me dijo en enero de 2025: “No podemos permitirnos un error”. Es cierto. Pero no decidir también es un error. Solo que más silencioso.

Estrategia de IA en PYMES: Lo que realmente significa Construir vs. Comprar

Construir no significa que tres científicos de datos entrenen un modelo fundacional en el sótano. Bueno, casi nunca. Construir en las PYMES suele significar: propias tuberías de datos, propios modelos o al menos propia lógica de dominio, propios procesos MLOps, propio monitoreo, propia responsabilidad. El proveedor puede proporcionar infraestructura en la nube, pero la empresa asume el riesgo del producto y la operación.

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

La línea más nítida no se traza entre la nube y el entorno local. Se traza entre la mercancía y la diferenciación. Pronóstico, PNL estándar, clasificación de imágenes, optimización de rutas, asistencia de ofertas, motores de recomendación simples: para esto existen productos útiles. La IA en el núcleo del producto, como la sensorización inteligente, la navegación autónoma, el control de procesos propietario o un algoritmo de servicio que aprende de 15 años de datos de máquinas, ahí construir puede ser útil. Puede. No tiene por qué.

PwC y Roland Berger describen desde 2023 un patrón que también aparece en mis conversaciones: las PYMES más pequeñas y medianas optan predominantemente por Comprar o Configurar, las PYMES más grandes eligen con mayor frecuencia un enfoque híbrido. La empresa de 300 empleados tiende a comprar Microsoft, SAP, Cognex, Celonis, o9, PTC o un proveedor especializado. El proveedor de 3.000 empleados quizás construye un Centro de Competencia de Análisis y desarrolla donde reside la creación de valor. Esto suena trivial. Sin embargo, se ignora constantemente.

Los números duros: Costos, plazos, tasas de éxito

En los últimos dos años, he hablado en Múnich, Stuttgart, Bielefeld y Linz con responsables digitales que gestionan sus presupuestos de IA no en comunicados de prensa, sino en Excel. Los rangos son sorprendentemente estables. Un PoC de construcción en las PYMES suele costar entre 100.000 y 300.000 euros durante tres a seis meses. Hasta que un MVP funcione productivamente, entre 300.000 y 800.000 euros son realistas, sin contar siempre limpiamente los costes de personal interno. Y ahí es donde comienza el autoengaño.

Porque el científico de datos no es gratuito solo porque ya esté en la nómina. El ingeniero de producción que revisa etiquetas ocho horas a la semana, tampoco. La arquitecta de TI que aclara las autorizaciones de seguridad, mucho menos. En una fábrica cerca de Ulm, en febrero de 2025, olía a refrigerante mientras Martin, jefe de TI, me decía: “Externamente, solo gastamos 180.000 euros”. Dos horas después, me mostró la estimación de esfuerzo interno. Con el trabajo propio, el proyecto ascendía a 520.000 euros.

Comprar o Configurar comienza más bajo. Licencia piloto más integración: a menudo entre 50.000 y 250.000 euros. Despliegue en varias fábricas o áreas: entre 150.000 y 800.000 euros. Los costes de licencia continuos para muchos escenarios de PYMES oscilan entre 50.000 y 200.000 euros al año, dependiendo de los usuarios, el volumen de datos y el estado de ánimo del proveedor. Sí, el estado de ánimo 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. 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 IA. En la fabricación y los bienes industriales, según mi experiencia y los puntos de referencia de los consultores, entre el 50 y el 70 por ciento de los PoCs mueren antes de ver una operación real. En la construcción, a menudo solo entre el 30 y el 40 por ciento logran pasar a producción. En la compra o configuración, entre el 50 y el 70 por ciento. No porque los proveedores hagan magia. Sino porque hay menos riesgo fundamental en el modelo.

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

Me gusta el desarrollo propio. De verdad. Hay un 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 “la cosa de la IA”, sino de su nueva herramienta. Eso es potente. Solo que no sucede porque alguien haya instalado PyTorch.

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

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

Ese es el punto: Construir vale la pena cuando la IA cambia el valor para el cliente o representa 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 una situación inicial diferente a la de un mayorista de 220 empleados que quiere mejorar la venta cruzada en la tienda web. Quien confunde estas diferencias, empieza la casa por el tejado.

Solo desarrollamos internamente donde vemos una clara ventaja competitiva y nuestro conocimiento del proceso o producto es único. Compramos análisis estándar y modelos de lenguaje.

— en el sentido 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 “Zukunft Deutschland” (Futuro Alemania): las PYMES tienen una ventaja con sus propios datos, pero a menudo deberían comprar modelos y plataformas y dominar la lógica de dominio por sí mismas. Estoy de acuerdo. Los datos por sí solos no son una ventaja competitiva. Solo cuando los datos, el conocimiento del proceso y el canal de distribución se unen, construir se vuelve interesante.

La estrategia de “comprar primero” no es una capitulación, sino disciplina

En Münster, en noviembre de 2024, me reuní con un gerente de logística, Ralf, quien anteriormente había participado en proyectos de pronóstico en Fiege. Estábamos sentados en un comedor, olía a salsa de carne asada, y del almacén llegaba el sordo rodar de la tecnología de transporte. “Podríamos haberlo construido todo nosotros mismos”, dijo. “¿Pero para qué?” Fiege utiliza servicios en la nube, componentes de Azure y soluciones de socios en diversas áreas, 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 una mejora de la precisión de los pronósticos del 3 al 8 por ciento, según el campo.

Esta es la realidad de las PYMES, solo que a mayor escala. Un pronóstico rara vez es único. Una optimización de rutas tampoco lo es. Una inspección de calidad basada en imágenes con una clase de error definida es técnicamente exigente, pero a menudo no es motivo para establecer un equipo de visión propio. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx o proveedores especializados tienen sus peculiaridades. Por supuesto. Pero no parten de cero.

Un caso anónimo del sur de Alemania muestra la lógica claramente. Fabricante de maquinaria, 800 empleados, inspección visual manual, escasez de personal, alta presión de retrabajo. La empresa compró un sistema comercial de visión artificial en lugar de desarrollarlo internamente. Inversión inicial: alrededor de 350.000 euros para hardware, licencias, integrador y formación. Cuatro meses de PoC, tres meses de despliegue en dos líneas. Después de 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 dinero.

Sé que “comprar” suena demasiado pequeño para algunos CTOs. Uno no quiere simplemente “configurar”. Uno quiere diseñar. Comprensible. Solo que el cliente no paga por el orgullo del departamento de TI. Paga por la capacidad de entrega, la calidad, el servicio, la 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 sprints.

La segunda verdad: Comprar puede ser caro, lento y peligroso

Ahora la autocorrección. “Comprar primero” no significa “proveedor primero”. He visto proyectos SaaS que después de dos años parecían un apartamento de alquiler después de diez subarrendatarios: adaptadores por todas partes, nadie sabe ya de quién es la llave. Un proveedor de 260 empleados del sur de Baviera pagó en 2024 licencias moderadas por tres herramientas relacionadas con la IA en ventas, servicio y planificación. Junto con interfaces, consultoría y administradores internos, los costes anuales ascendieron de repente a 310.000 euros. ¿Beneficio? Difícil de medir. “Ahora tenemos paneles de control”, dijo el jefe de ventas. Sentí pena por él.

El mayor error al comprar es la fe ciega en la funcionalidad. Una demostración de software siempre muestra datos limpios. Siempre. En la operación real, aparecen bases de clientes duplicadas, jerarquías de artículos faltantes, modelos de turnos diferentes 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 bloqueo 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 una mercancía y el proveedor entrega de forma estable. En procesos críticos del núcleo, se debe ser más cauteloso. Exportación de datos, capacidad de auditoría, costes de escalado, escenario de salida: temas aburridos, sí. Precisamente por eso se leen demasiado tarde.

Dónde mueren los proyectos de construcción en las PYMES

Hay una escena que se repite. Sala de reuniones, alfombra gris, pizarra con restos de un taller, en algún lugar todavía se lee “Priorización de casos de uso”. En la sala están TI, el departamento especializado y un consultor externo. Después de 14 meses de proyecto, alguien pregunta: “¿Quién es realmente el Product Owner?” Entonces se hace el silencio. Lo he vivido en Colonia, Núremberg y St. Gallen.

La primera causa de muerte es la calidad de los datos. No es sexy, pero es letal. Un proveedor automotriz con aproximadamente 3.000 empleados inició varios PoCs de mantenimiento predictivo durante tres años, junto con un instituto de investigación. Costo: más de un millón de euros, incluyendo el tiempo interno. Todos los pilotos se quedaron atascados en instalaciones individuales. OT y TI estaban separadas, no había un lakehouse central, el mantenimiento se involucró tarde y el historial de datos no coincidía con la lógica de fallos. Después de un cambio en la dirección de TI, se pasó a una plataforma estándar. Nueve meses después, los primeros casos de uso productivos estaban en marcha, después de 18 meses se reportaron alrededor de un 15 por ciento menos de fallos no planificados en las instalaciones seleccionadas.

La segunda causa de muerte es el falso orgullo. Un distribuidor B2B de la región DACH con alrededor de 1.200 empleados quería construir su propio motor de recomendación, también para reducir la dependencia de las plataformas en la nube de EE. UU. Equipo de ciencia de datos de cinco personas, Python, Scikit-Learn, más tarde TensorFlow. Dieciocho meses de tiempo de desarrollo, aproximadamente 1 a 1,5 millones de euros. Al final, el rendimiento, según las pruebas internas, solo era del 60 al 70 por ciento de un recomendador estándar en la nube. 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 pensamiento de producto. La IA se inicia como un proyecto, no se opera como un producto. Hay un PoC, un informe final, aplausos en el comité directivo. Luego el modelo se desvía, nadie mide la tasa de usuarios, nadie planifica el reentrenamiento, nadie se siente responsable de las falsas alarmas. Después de seis meses, el jefe de turno dice: “Esta cosa está fallando”. Y la aceptación desaparece.

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

La matriz Build-vs.-Buy para una estrategia de IA robusta

Me gusta usar una matriz simple de 2x2 en las conversaciones. No hay magia. En el eje X está el potencial de diferenciación: ¿Esta función de IA nos hace más difíciles de copiar en el mercado? En el eje Y está la estandarización: ¿Existe software maduro que cubra el 70 al 80 por ciento de la tarea? Si ambos ejes se evalúan honestamente, muchos proyectos favoritos fracasan.

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

Cuadrante dos: bajo potencial de diferenciación, alta estandarización. Comprar. Punto. Pronóstico estándar, clasificación de texto en el servicio al cliente, chatbots simples, verificación de gastos, puntuación de leads, inspección de imágenes con patrones de error conocidos. Quien predica Build aquí, debería poner los costos de oportunidad sobre la mesa. No como una diapositiva. Como una cantidad en euros.

Cuadrante tres: alto potencial de diferenciación, alta estandarización. Esta es la emocionante área híbrida. 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 proporcionar interfaces, pero el cerebro del negocio reside en el propio modelo de datos. Precisamente ahí es donde las PYMES deberían desarrollar competencias.

Cuadrante cuatro: bajo potencial de diferenciación, baja estandarización. Generalmente una señal de advertencia. Si algo no es estratégicamente importante ni fácil de comprar, ¿por qué hacerlo? ¿Porque un gerente de área lo quiere? ¿Porque un programa de financiación lo promete? El dinero de la financiación no es un caso de negocio. No hay nada que hacer al respecto.

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

En junio de 2025, me llamó un director general de Ravensburg. 120 empleados, construcción de maquinaria especial, un EBIT decente, pero una TI escasa. Me preguntó: “¿Cuánto nos costaría una IA para la automatización de ofertas?” Le respondí: “¿Cuánto cuesta una oferta hoy?” Silencio. Luego, un hojeo. Luego, la cifra: aproximadamente 1.800 euros de esfuerzo interno para máquinas complejas, si participan ventas, ingeniería y compras.

Solo con estas cifras, la decisión de construir o comprar se vuelve tangible. Si una empresa redacta 900 ofertas complejas al año y un sistema de asistencia de IA reduce el tiempo de procesamiento en un 25 por ciento, no estamos hablando de un juego. Estamos hablando de capacidad, respuesta más rápida, menos errores en las listas de materiales, mejor seguimiento. Si la solución se compra, se construye o es híbrida, se decide entonces por el retorno de la inversión, no por la intuición del CTO.

Comparación por sectores: Ingeniería mecánica, comercio, logística, automoción

La ingeniería mecánica es seductora para el “Build”. Las empresas tienen confianza técnica, muchos ingenieros, buenos datos de productos y a menudo una cultura de “hacerlo uno mismo”. En DMG Mori, Trumpf, Wittenstein o Festo, esta actitud tiene sentido en funciones de IA cercanas al producto. En un fabricante de instalaciones de 180 empleados de la Alta Franconia que quiere construir su propia IA de texto para informes de servicio, no tanto. El olor a aceite hidráulico no hace que un modelo de PNL sea propietario.

El comercio y la distribución B2B casi siempre deberían pensar en “Buy-first”. Recomendación, precios, pronóstico de existencias, clústeres de clientes, control de campañas: estos son campos con muchos proveedores y mucha experiencia. La diferenciación reside 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 las ventas. Un comerciante de Essen me dijo en abril de 2025: “Queríamos recrear la lógica de Amazon nosotros mismos”. Le pregunté: “¿Por qué no vender primero como Amazon?” No se rió.

La logística es más pragmática. Quizás porque allí cada punto porcentual se traduce inmediatamente en palets, kilómetros y turnos. Fiege, Dachser o Rhenus trabajan con plataformas, socios y equipos propios donde sea apropiado. Comprar para la optimización estándar, construir o co-construir para datos de red especiales y planificación personalizada. El suelo del almacén decide. No el departamento de estrategia.

Los proveedores de automoción están entre dos aguas. Tienen volumen, presión de calidad, requisitos de trazabilidad y especificaciones de los OEM. La calidad predictiva, el mantenimiento, la inspección visual y la IA de planificación son atractivos. Pero muchas fábricas han crecido históricamente, los datos de OT están fragmentados y el comité de empresa quiere ser consultado con antelación. Quien inicia el “Build” allí sin una plataforma de datos, termina 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 anónima: fabricante de componentes de Baden-Württemberg, 320 empleados, facturación de casi 75 millones de euros, clientes de ingeniería mecánica y tecnología médica. Estuve allí en octubre de 2024. En el control de calidad olía a limpiador de alcohol, bajo una luz LED había piezas fresadas en bandejas grises. Sabine, jefa de calidad, dijo: “Perdemos tiempo porque detectamos los errores demasiado tarde”.

La empresa tenía tres ideas de IA: visión artificial para el control de calidad, pronóstico en compras, asistencia de ofertas para piezas especiales. Antes, probablemente habrían iniciado tres PoCs. Esta vez no. El director general hizo pasar cada idea por la matriz. Visión artificial: Comprar. Pronóstico: Comprar/Configurar. Asistencia de ofertas: Híbrido, porque la lógica de viabilidad técnica y las reglas de variantes eran realmente propias de la empresa.

Las cifras después de 14 meses: el piloto de visión artificial para dos familias de piezas costó alrededor de 210.000 euros, incluyendo cámara, iluminación, integrador y formación. La tasa de defectos se redujo en un 28 por ciento, el retrabajo en un 11 por ciento. El pronóstico se introdujo a través de un módulo del socio ERP existente más una tubería de datos externa, con un coste de aproximadamente 95.000 euros; la precisión del pronóstico en las piezas A aumentó en 6 puntos porcentuales. La asistencia de ofertas costó más: alrededor de 380.000 euros, porque se integraron CPQ, reglas cercanas a CAD e historiales de precios. A cambio, el tiempo medio de procesamiento de ofertas complejas se redujo de 9,5 a 6,8 días hábiles.

Más importante que las cifras individuales fue la gobernanza. Había un Product Owner por caso de uso, una vista mensual de KPI, criterios de interrupción claros y un pequeño núcleo de datos: un ingeniero de datos, una ingeniera de análisis, un arquitecto externo durante seis meses. Sin laboratorio de IA con pufs. Sin circo de innovación. Solo trabajo.

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

Preguntas frecuentes: ¿Cuándo debería una PYME construir su propia IA?

Una PYME debería construir su propia IA si se cumplen tres condiciones simultáneamente: la función crea diferenciación para el cliente, los datos necesarios son propietarios y fiables, y la empresa puede financiar la operación, el monitoreo y el desarrollo continuo. Si falta alguna de estas condiciones, solo permitiría la construcción con un socio y una línea de parada estricta. Un ejemplo: el diagnóstico inteligente del estado de las propias máquinas con datos de sensores exclusivos puede justificar la construcción. Un chatbot estándar para consultas de servicio no.

Preguntas frecuentes: ¿Cuál es la mejor estrategia de IA para empresas de 50 a 500 empleados?

Para empresas entre 50 y 500 empleados, una estrategia híbrida de “comprar primero” suele ser la mejor opción. Software estándar para casos de uso comunes, lógica de dominio propia para procesos diferenciadores, un pequeño equipo central interno para datos y responsabilidad del producto. Esto suena menos heroico que “construimos nuestra propia plataforma”. Funciona con más frecuencia. Según Bitkom 2024, el uso productivo de la IA en las PYMES alemanas todavía es bajo; precisamente por eso, el tiempo de valorización es más importante que el orgullo técnico.

Preguntas frecuentes: ¿Cómo evitar la trampa del PoC en la IA?

Se evita con criterios de eliminación antes de que comience el primer taller. Ejemplo: si una solución de visión artificial no muestra una mejora de al menos el 10 por ciento en el reconocimiento en comparación con una muestra manual después de doce semanas, se detiene o se reajusta. Si una asistencia de ofertas no genera un ahorro de tiempo medible después de seis meses, se elimina del portfolio. 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 director general, CTO o responsable digital, no empezaría con la selección de herramientas. Tampoco con un taller de IA en el que al final 47 casos de uso estén pegados 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 IA en producción, ventas, servicio y back office. Escriba un indicador clave de rendimiento al lado de cada caso de uso: residuos, tiempo de inactividad, duración de la oferta, conversión, existencias, costes de reclamación. Sin indicador clave de rendimiento, no hay caso de uso.
2. Evalúe cada caso de uso con la matriz 2x2: potencial de diferenciación frente a estandarización. Realice la evaluación en un círculo pequeño con la dirección, el departamento especializado y TI. No en un taller de 18 personas.
3. Defina una regla de “comprar primero” para temas de productos básicos. La previsión, el análisis de texto estándar, la inspección visual simple, la automatización de CRM y la recomendación solo deben ser “construidos” si existe una razón comercial por escrito.
4. Establezca criterios de eliminación. 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. Forme un pequeño equipo central. Para 50 a 500 empleados, a menudo es suficiente: un ingeniero de datos o ingeniero de análisis, un Product Owner fuerte por caso de uso, un arquitecto de TI a tiempo parcial, especialistas externos para fases limitadas.
6. Integre la IA en los sistemas existentes. No hay portales de IA aislados si los usuarios trabajan en ERP, CRM, MES, CPQ o sistemas de tickets. La IA debe aparecer donde el trabajo ya se realiza.
7. Informe trimestralmente sobre las aplicaciones de IA productivas, no sobre los PoCs. Muestre el impacto comercial, la tasa de usuarios, los costos, los riesgos abiertos. El CFO debe entender la tabla sin tener que buscar “Embedding” en Google.

Producto Amplifa Automatización de ventas impulsada por IA para equipos B2B que no quieren configurar la generación de leads, la mejora del ICP y el alcance como un proyecto de bricolaje.

Gobernanza: ¿Quién decide, quién es responsable, quién detiene?

La gobernanza de la IA suena a corporación. No del todo cierto. Precisamente las PYMES la necesitan, porque los caminos son cortos y los errores se vuelven personales rápidamente. Si una IA recomienda aprobaciones de calidad incorrectas, el tema no termina en un comité de riesgo anónimo. Termina con Sabine en el control de calidad, con Thomas en ingeniería y con el director general, si el cliente se queja.

Una gobernanza útil para 50 a 500 empleados no tiene por qué ser extensa. Necesita cuatro roles: Propietario de Negocio, Propietario de Producto, Responsable Técnico, Auditor de Riesgos o Cumplimiento. El Propietario de Negocio es responsable del beneficio. El Propietario de Producto es responsable del uso y la hoja de ruta. El equipo técnico mantiene la operación, la seguridad y el flujo de datos limpios. El cumplimiento verifica la protección de datos, los temas del comité de empresa, la relevancia de la Ley de IA de la UE y la capacidad de auditoría. Cuatro nombres. No “la TI”.

La Ley de IA de la UE se hará sentir gradualmente a partir de 2025 y 2026, especialmente en aplicaciones de alto riesgo. Muchos casos de uso de PYMES no caen en la clase de riesgo más alta, pero la documentación, la transparencia y la responsabilidad serán más importantes. Quien hoy introduce una IA en decisiones de calidad, procesos de personal o pasos de producción relacionados con la seguridad, no debería esperar a que el auditor esté en el vestíbulo.

La gobernanza también decide entre Construir y Comprar. Al comprar, debe examinar al proveedor: procesamiento de datos, transparencia del modelo, alojamiento, conceptos de eliminación, acceso, registros de auditoría. Al construir, debe poder hacer todo eso usted mismo. ¿Honestamente? Muchas empresas de 200 empleados no pueden. Esto no es una crítica. Es un criterio de decisión.

Pila tecnológica: Lo que realmente necesitan las PYMES

Si Construir o Híbrido tiene sentido, no se necesita un zoológico tecnológico. Demasiado a menudo veo imágenes de arquitectura con Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes y cinco logotipos más, aunque la empresa todavía envía archivos CSV desde el ERP por correo electrónico. Eso no es estrategia. Eso es coleccionar logotipos.

Para muchas PYMES, una pila clara es suficiente: almacenamiento central de datos o lakehouse, interfaces estables a ERP/CRM/MES, una herramienta MLOps para el versionado y monitoreo de modelos, concepto de derechos, informes. Azure es fuerte en las PYMES de DACH, a menudo debido a los contratos de Microsoft 365 y la experiencia en TI 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 código abierto no es una comida gratis. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow, todas son buenas herramientas. Pero alguien tiene que mantener las dependencias, verificar las actualizaciones de seguridad, monitorear los modelos, detectar la deriva, reparar las tuberías. En un turno de noche, a nadie le importa si el error proviene del Feature Store o de la interfaz PLC. La línea está parada.

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

Producto Amplifa para estrategia de ventas con IA Para empresas B2B de tamaño medio que quieren utilizar la IA de forma productiva en ventas, sin tener que construir primero su propia plataforma de divulgación y datos.

Gestión del cambio: La planta 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 IA. A mi lado estaba un inspector, quizás de unos cincuenta años, con las manos manchadas de negro en los bordes de los dedos. Dijo en voz baja: “Si la caja está mal, yo tengo la culpa”. Esa fue la frase más importante del día.

La introducción de la IA rara vez falla solo por la tecnología. Falla por la responsabilidad. Si la gente cree que la IA les quita trabajo, les atribuye errores o devalúa su conocimiento experiencial, no la usarán. Entonces el sistema se elude, las advertencias se ignoran, los datos se gestionan mal. La gestión del cambio no significa colgar carteles. Significa aclarar claramente los roles, la responsabilidad y los beneficios.

En la visión artificial para el control de calidad, debe quedar claro: ¿La IA aprueba o recomienda? ¿Quién decide en casos límite? ¿Cómo se tratan los falsos negativos? ¿Cómo se incorpora la retroalimentación de los inspectores al modelo? En la asistencia de ofertas en ventas, debe quedar claro: ¿Puede la IA sugerir precios? ¿Quién verifica los descuentos? ¿Qué declaraciones a los clientes están prohibidas? Estas preguntas no son frenos. Son requisitos operativos.

El comité de empresa debe participar desde el principio, no después del piloto. Especialmente en la IA para la medición del rendimiento, la planificación de turnos, los recursos humanos o los sistemas de asistencia con datos de uso. Conozco empresas que perdieron tres meses porque creyeron que la participación era un acto formal. No lo era. Era el verdadero despliegue.

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

Mi pronóstico es contundente: para finales de 2026, muchas PYMES reducirán a la mitad sus carteras de IA. No porque la IA 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 están funcionando productivamente. El departamento de ventas preguntará por qué el asistente de ofertas aún no está en el CRM. La producción preguntará por qué el piloto solo funciona en la línea 3. Entonces se hará una selección.

Al mismo tiempo, las buenas empresas serán más rápidas. No perseguirán 30 casos de uso, sino cinco. Utilizarán software estándar donde sea suficiente y desarrollarán conocimientos propios donde duela si el competidor también los tiene. No “harán IA”. Reducirán los residuos, acelerarán las ofertas, aumentarán los ingresos por servicios, reducirán las existencias. Ese es un tono diferente.

Jürgen Müller, CTO de SAP, ha enfatizado públicamente en varias ocasiones la integración de la IA generativa en la Business Suite. El mensaje para las PYMES es claro: no todos los clientes deben construir sus propios modelos fundacionales. Muchos deben consumir, integrar y controlar la IA. Creo que esto es saludable. Quien en 2026 todavía cree que una empresa de 250 empleados debe primero fundar su propio laboratorio de IA antes de ver beneficios, confunde a las PYMES con un 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 compra y mantenido un único caso de uso híbrido para su lógica de máquinas. “Se siente menos visionario”, dijo. De fondo, volví a oír el pitido de la carretilla elevadora. Quizás ese fue precisamente el progreso.