Nvidia adquiere Hugging Face por más de 11.000 millones de euros
Eva Mickler
4 Min. de lectura Nvidia adquiere Hugging Face por unos 11.100 millones de euros, contrato del 2 de septiembre ...
Leer artículo
6 min de lectura
Los programas de visibilidad suelen empezar como pilotos con hardware y terminan como carga operativa y de licencias sin cobertura. Quien compra dispositivos sin aprobación separada para conectividad, plataforma e integración financia la escala con el presupuesto operativo. CIO y CDO en DACH necesitan antes del despliegue una lógica Capex que separe costes recurrentes y líneas de inversión.
Lo más importante en resumen
- Separar cuatro bloques de costes. El hardware es solo el inicio del Capex; la conectividad, la plataforma y la integración suelen operar como OPEX y crecen con la flota de forma lineal o desproporcionada.
- El piloto demuestra la funcionalidad. El hardware de prueba en campo y la falta de responsabilidad global sobre el TCO generan islas y frenan la escalabilidad entre plantas y socios.
- Fabricar o comprar gestiona la propiedad. Desarrollar internamente consume entre 18 y 24 meses de capacidad; el Reglamento de Datos de la UE garantiza cambios con un plazo máximo de dos meses y obligaciones de exportación.
- Tres puertas presupuestarias controlan el despliegue. El piloto, la decisión de escalar y la expansión por oleadas requieren rutas separadas de Capex y OPEX, así como criterios de interrupción predefinidos.
RelacionadoCadena de suministro bajo presión geopolítica: lecciones para los CIOs del salto del 74% en 2026 / Las obligaciones de la cadena de suministro necesitan una arquitectura de datos
Bloques de costes: hardware, conectividad, plataforma e integración
El hardware es la entrada visible y, a menudo, el único concepto con una posición de pedido clara. Los dispositivos de seguimiento, sensores y pasarelas aparecen en las solicitudes de Capex y pueden amortizarse a través de la contabilidad de activos. El error comienza cuando este bloque se interpreta como proxy del programa completo. Los precios de los dispositivos no cubren ni la transmisión de datos, ni el uso de la plataforma, ni la conexión con ERP, WMS o TMS.
La conectividad es el segundo bloque y tiene una estructura diferente. Las tarifas de las SIM, los perfiles de roaming, la gestión de eSIM y los contingentes de datos se gestionan mediante contratos con operadores y suelen ser OPEX. Las listas de precios y los modelos contractuales varían según el corredor de países, el volumen de datos y la duración del contrato. Deutsche Telekom, por ejemplo, en su familia de tarifas IoT Business (según las páginas públicas de tarifas), incluye entre otras opciones el IoT Business Classic desde 1,43 euros al mes por SIM con volumen de datos flexible en Europa, el IoT Business Data Best desde 26,50 euros al mes por pool de datos para hasta 50 SIM, y la tarifa LPWA con un pago único de 14,50 euros por SIM durante diez años y 6,5 MB al mes en Europa. 1NCE promociona su IoT Lifetime Flat con un pago único de 12 euros por diez años de conectividad, que incluye 500 MB y 250 SMS; el hardware de la SIM cuesta entre 1 y 2,50 euros según el tipo. Sin estos datos de ancho de banda y sin las condiciones concretas de roaming y duración del propio corredor, el cálculo de escalabilidad se convierte en una estimación basada en el mes piloto.
El bloque de la plataforma abarca licencias, cuentas de usuario, gestión de dispositivos, reglas y, a menudo, el almacenamiento de datos en función del uso. Las plataformas de visibilidad y seguimiento suelen facturar por número de dispositivos, eventos o llamadas a la API. Un marco de TCO que IoT Business News resume en marzo de 2026 modela esta capa como coste por año y dispositivo. En él se incluyen conectividad, plataforma, gestión de dispositivos y soporte. Microsoft factura Azure IoT Central por dispositivo en tres niveles estándar, escalonados según los contingentes de mensajes de 400 a 30.000 mensajes por dispositivo y mes. Lo que en el piloto con pocos activos pasa desapercibido, crece de forma lineal o desproporcionada con la flota.
La integración es el bloque que los presupuestos de Capex suelen subestimar con mayor frecuencia. Las interfaces con sistemas existentes y de transporte, el mantenimiento de datos maestros, la lógica de eventos y la operación de middleware generan costes únicos y recurrentes. La capacidad interna del personal y las empresas externas de sistemas rara vez aparecen en la misma línea de aprobación que los dispositivos. Tratar la integración como una posición secundaria genera, más adelante, retrasos en el mantenimiento y presupuestos ocultos en los departamentos.
Trampas del piloto y frenos en la escalabilidad
Los equipos suelen vender el piloto como una prueba técnica y lo malinterpretan como una decisión comercial. Un Proof of Concept con un número limitado de activos y un equipo de proyecto acompañante demuestra funcionalidad, no madurez operativa. El éxito en el piloto solo significa que los sensores y el panel de control proporcionan datos en condiciones controladas. Para la expansión de la red, faltan entonces criterios de obligatoriedad en cuanto a calidad de datos, precisión de alarmas y vinculación de procesos.
Una trampa típica mezcla el hardware del piloto con la arquitectura objetivo. Los dispositivos del PoC permanecen en el campo, aunque la tarifa, el firmware y el contrato de plataforma no estén aprobados para su uso masivo. Así surgen islas con vías de soporte divergentes y ciclos de vida no uniformes. El freno en la escalabilidad se activa tan pronto como TI y el área especializada operan en paralelo y nadie asume la responsabilidad del TCO total.
Un segundo freno se encuentra en la canalización de datos. La visibilidad genera conjuntos de eventos que terminan en análisis, reglas y archivos. Sin un propietario claro de los datos y sin un modelo operativo para el mantenimiento de reglas, el esfuerzo manual de reprocesamiento aumenta con cada corredor adicional. La organización solo se da cuenta cuando el piloto se expande a varias plantas o socios logísticos.
Fabricar o comprar plataformas de seguimiento
La decisión de fabricar o comprar plataformas de seguimiento no es una mera cuestión tecnológica. Las plataformas desarrolladas internamente o muy personalizadas prometen control sobre el modelo de datos y las interfaces de integración. Sin embargo, consumen capacidad de desarrollo, revisiones de seguridad y gestión de releases durante años. Particle describe el camino típico interno hasta alcanzar la madurez comercial en aproximadamente 18 a 24 meses e indica los costes indirectos para seguridad, gestión del cambio y tiempo de comercialización que suelen omitirse en las primeras tablas de TCO. Para muchas empresas industriales y comerciales, el cuello de botella reside en la capacidad de gestionar en paralelo el funcionamiento de la plataforma y la flota de dispositivos. En estos casos, la sensorización suele estar suficientemente disponible.
Las opciones de compra trasladan la complejidad al contrato. Los modelos de licencia, cláusulas de salida, exportación de datos y definición de SLAs determinan si más adelante será posible cambiar de proveedor. Desde septiembre de 2025, las normas de cambio del Reglamento de Datos de la UE para servicios de procesamiento de datos, incluidos SaaS y PaaS, son de obligado cumplimiento. Los clientes pueden exigir el cambio con un preaviso máximo de dos meses. Los proveedores deben poner a disposición los datos exportables y los activos digitales en formatos comunes. Las tarifas de cambio quedarán suprimidas tras la fase de transición a partir de enero de 2027. Sigue siendo crucial la separación entre el hardware de los dispositivos y la plataforma de software: un paquete acoplado puede abaratar la inversión en Capex pero estrechar la vía del OPEX.
Una forma intermedia pragmática es la plataforma estándar con partes claramente delimitadas de integración desarrolladas internamente. En este caso, la plataforma principal sigue siendo un modelo de suministro externo, mientras que la lógica de eventos y la conexión del sistema se gestionan internamente o a través de un integrador de sistemas. Lo decisivo es que, antes del despliegue, se designe la propiedad de los datos maestros, las reglas de alarma y las cuentas de costes. De lo contrario, la responsabilidad oscilará entre TI, logística y compras.
Puertas de presupuesto del Proof of Concept a la red
La disciplina en el Capex requiere puertas que autoricen financiación. Los hitos controlan el calendario, las autorizaciones, el presupuesto. La primera puerta verifica si el PoC aborda un problema comercial definido con un impacto medible en el proceso. Sin objetivos cuantificables en fiabilidad de suministro, tiempos de búsqueda, pérdidas o desviaciones en el transporte, la visibilidad sigue siendo un proyecto técnico. La autorización implica aquí: presupuesto limitado, número limitado de activos y fecha de finalización fija.
La segunda puerta separa la finalización del piloto de la decisión de escalar. En este punto, el hardware, la conectividad, la plataforma y la integración deben presentarse cada uno con sus propias vías de costes. Las consecuencias en OPEX para los próximos años presupuestarios deben incluirse en el mismo bloque de documentación de decisión que la inversión en dispositivos. Los programas de IoT y OT deben autorizarse como inversiones en TI, con consecuencias visibles en OPEX. El marco de TCO con costes por año y dispositivo y capas separadas de Capex y OPEX sigue siendo la lógica de trabajo sólida para el comité directivo.
La tercera puerta se aplica a la expansión de la red por oleadas. Cada oleada requiere una recalculación de la anterior: fallos reales de dispositivos, desviaciones tarifarias, esfuerzo de integración y calidad de datos. Sin esta puerta, el despliegue se convierte en una prolongación del piloto con una base de costes en crecimiento. En este punto, los CIO deberían verificar explícitamente si la suposición original del caso de negocio sigue vigente o si es necesario corregir el alcance.
Criterios de interrupción aplicables en el comité de dirección
Los criterios de interrupción solo surten efecto si el comité de dirección los aprueba antes de la primera compra de equipos. Los criterios técnicos se refieren a la disponibilidad de datos, la tasa de falsas alarmas y la estabilidad de integración bajo carga. Los criterios económicos afectan a la desviación de los costes planificados de conectividad y plataforma, así como al esfuerzo de integración por sistema conectado. Los criterios organizativos entran en juego cuando los departamentos especializados no asumen la responsabilidad del proceso para alarmas y el manejo de excepciones.
El comité de dirección necesita umbrales que activen automáticamente una pausa sin forzar un debate prolongado. Puntos de referencia útiles son una desviación predefinida del camino planificado de OPEX, la falta de uso del proceso tras una fase de estabilización definida o la incapacidad de exportar datos en el contrato de plataforma. Este último aspecto se ve respaldado por el Reglamento de Datos de la UE, que establece obligaciones concretas de cambio y exportación.
Igualmente importante es separar la interrupción del proyecto de la continuidad operativa de los equipos. Una implementación detenida puede dejar un parque limitado en campo si se resuelven las cuestiones de soporte y centro de costes. En cambio, la continuación descontrolada sin estado de programa genera compromisos silenciosos en licencias y tarifas. Por ello, el comité de dirección debería gestionar la interrupción, la congelación y el desmantelamiento ordenado como tres decisiones distintas.
La visibilidad sin disciplina en CAPEX no genera transparencia en la cadena de suministro. Genera opacidad en el presupuesto de TI. Quien separa hardware, conectividad, plataforma e integración antes de la PoC solo escala lo que es viable desde el punto de vista económico y organizativo. La consecuencia para CIO y CDO: los programas de visibilidad deben gestionarse como proyectos de inversión con consecuencias en OPEX, no como proyectos de equipos con demostraciones en dashboard.
Preguntas frecuentes
¿Cómo se integran los cuatro bloques de costes en una misma aprobación?
El hardware se registra como solicitud de Capex con amortización a través de la contabilidad de activos. La conectividad y las licencias de plataforma se incluyen como partidas de OPEX en el mismo documento de decisión, incluyendo bandas tarifarias y costes por año de dispositivo. La integración con capacidad interna y el gasto en servicios de sistemas recibe una línea de aprobación propia. Así, la compra de dispositivos no financia en silencio la escalabilidad con cargo al presupuesto operativo.
¿Puede seguir funcionando el hardware de PoC en la red objetivo?
La continuidad requiere tarifas aprobadas, firmware y contratos de plataforma para su uso generalizado. Las desviaciones generan islas con vías de soporte separadas y ciclos de vida no uniformes. En caso de interrupción o congelación, solo queda un stock limitado con soporte aclarado y centro de coste fijo en campo.
¿Qué cambia concretamente el Reglamento de Datos de la UE en el contrato de plataforma?
Desde septiembre de 2025, los clientes pueden exigir el cambio de servicios SaaS y PaaS con un preaviso máximo de dos meses. Los proveedores deben facilitar los datos exportables y activos digitales en formatos comunes. Las comisiones por cambio quedarán eliminadas tras la fase de transición a partir de enero de 2027. Esto refuerza los criterios de interrupción relacionados con la capacidad de exportación de datos y mantiene separable el hardware de los dispositivos de la salida de la plataforma.
¿Cuándo se aplica la interrupción en lugar del congelamiento o el desmantelamiento ordenado?
La interrupción detiene el programa cuando se incumplen umbrales técnicos, económicos u organizativos, como desviaciones en OPEX, falta de uso del proceso o incapacidad de exportación. El congelamiento mantiene el stock de forma controlada, mientras que el desmantelamiento ordenado retira del mercado y cancela contratos de manera estructurada. El comité de dirección gestiona las tres opciones como decisiones independientes para que las obligaciones de licencias y tarifas tras la parada sigan siendo visibles y asignables.
Más para leer en Digital Chiefs
Digital ChiefsEl seguimiento de contenedores proporciona datos, no controlDigital ChiefsAccesos huérfanos: la brecha cibernética silenciosaDigital ChiefsPor qué la factura de la nube nunca disminuyeMás de la red MBF Media
cloudmagazin
mybusinessfuture
securitytoday
Fuente de la imagen: Generada por IA (julio 2026)