Startups de seguimiento: sí a la velocidad, no al riesgo operativo

27.07.2026

7 min de lectura

Las startups especializadas en visibilidad entregan en semanas lo que plataformas corporativas suelen liberar en trimestres. Para CIO y CDO, tras la demo pesan más integración, exportación de datos y continuidad si el proveedor quiebra o se vende. Quien dirige la visibilidad como función operativa evalúa startups como proveedores de software con riesgo de salida. La interfaz de demo queda atrás.

Lo más importante en resumen

Enfoque en un caso de uso concreto. La visibilidad desde startups aporta velocidad en lagunas medibles en el seguimiento de contenedores, activos y excepciones, cuando el componente se integra deliberadamente como satélite junto a TMS y ERP.
Due diligence antes que UX. Los CIO verifican roles y permisos, cifrado, certificaciones CAIQ y C5, APIs versionadas, runway, concentración de inversores y referencias operativas con interfaces reales.
La integración genera el valor. Los eventos requieren un mapeo canónico según GS1 EPCIS, datos maestros limpios y un modelo operativo para incidentes, cambios de esquema y monitorización de pipelines más allá de la interfaz de la startup.
Capacidad de salida antes del piloto. El depósito en garantía con manual de construcción, cláusulas de cambio de control, plazos de migración y exportaciones legibles por máquina según el Reglamento de Datos de la UE garantizan la continuidad operativa y la portabilidad de datos en caso de venta o fallo.

RelacionadoCompromiso con la IA en la nube: el ritmo del capex se vuelve incómodo / VMware bajo Broadcom: el plan de salida como palanca

Cuándo las soluciones de startups tienen sentido

Las soluciones de startups son adecuadas donde un caso de uso concreto genera valor más rápido que un módulo de plataforma amplio. Son típicas las lagunas en el seguimiento de contenedores y activos, en la gestión de excepciones en cadenas multimodales o en datos de IoT que, en el actual Transportation Management System (TMS) -el software para planificación y ejecución de transportes-, solo llegan de forma incompleta. El beneficio surge cuando la laguna es medible y el área especializada ya conoce el proceso.

Gartner define el mercado de las plataformas de visibilidad en tiempo real del transporte (RTTVP) como aquellas que proporcionan la ubicación y el estado en tiempo real de pedidos y envíos, conectándose con TMS y ERP. GS1 EPCIS, el estándar de eventos para la visibilidad en la cadena de suministro, estructura estos eventos mediante el modelo «qué, cuándo, dónde, por qué y cómo». Los patrones de priorización son específicos de cada empresa: los CIO ponderan las lagunas de procesos medibles, el esfuerzo de integración y la proximidad a la facturación o el control de SLAs.

Las startups no son adecuadas como sustituto silencioso de procesos clave en ERP y TMS. Tan pronto como el seguimiento se integra en la facturación, el control de SLAs o el cumplimiento normativo, aumentan los costes de integración y de fallos. En ese caso, la estabilidad prima sobre el ritmo de la demo.

Su uso tiene sentido cuando el CIO integra el componente de la startup de manera deliberada como satélite. Esto implica soberanía limitada sobre los datos en el propio stack, interfaces claras y un modelo operativo predefinido. Sin esta integración, la visibilidad queda como una solución aislada con un elevado coste de sustitución.

Due Diligence: seguridad, hoja de ruta y señales de financiación

La Due Diligence comienza con la seguridad y las identidades, no con la vista de mapa. Se requieren conceptos de roles y permisos, cifrado en tránsito y en reposo, registros de actividad (logging), separación de datos de inquilinos (tenant) y pruebas de penetración, así como respuestas a incidentes. Para los proveedores de IoT, se añaden la identidad de los dispositivos, las rutas de actualización y el manejo de puntos finales comprometidos.

Como marco de evaluación se utilizan marcos de referencia consolidados. El Consensus Assessments Initiative Questionnaire (CAIQ) de la Cloud Security Alliance documenta los controles de seguridad de proveedores IaaS, PaaS y SaaS según la Cloud Controls Matrix e integra el nivel 1 del registro STAR. La norma ISO/IEC 27001:2022 regula las relaciones con proveedores en los controles del Anexo A (5.19 a 5.23), incluyendo el uso de la nube y el monitoreo de servicios de proveedores. El Catálogo de Criterios de Cumplimiento de Computación en la Nube del BSI (C5:2026) especifica requisitos mínimos para la computación en la nube segura: 168 criterios verificables en 17 áreas temáticas, como sucesor de C5:2020 con 121 criterios. Las directrices de la ENISA sobre seguridad en IoT complementan la identidad de los dispositivos, las rutas de actualización seguras y los aspectos de la cadena de suministro a lo largo de todo el ciclo de vida.

La hoja de ruta debe alinearse con la propia arquitectura y no terminar en presentaciones para inversores. Los CIOs verifican si las APIs están versionadas, si los cambios disruptivos (breaking changes) se anuncian y si los modelos de datos permanecen estables. Una promesa de funcionalidad sin disciplina de lanzamiento vinculante no es un objeto de planificación para la operación.

Las señales de financiación son señales de riesgo operativo. El tiempo de supervivencia (runway), la concentración de inversores, la dependencia de un cliente clave y los rumores de venta deben incluirse en el catálogo de riesgos de TI. Las noticias de captación de fondos (fundraising) demuestran acceso a capital. Los CIOs no derivan de ellas la madurez operativa. La NIST SP 800-161 Rev. 1 (Cybersecurity Supply Chain Risk Management) exige evaluar, clasificar y supervisar a los proveedores a lo largo del ciclo de vida -incluyendo dependencias organizativas y financieras-. Las noticias públicas sobre propiedad y financiación se integran en esta evaluación. No existe una puntuación sectorial vinculante para el riesgo de proveedores en soluciones SaaS de visibilidad; cada empresa calibra internamente los umbrales.

Las referencias deben cubrir el mismo nivel de integración que requiere la propia operación. Una demostración exitosa en una pyme sin integración con ERP dice poco sobre la operación en un grupo con TMS, datos maestros y roles de Active Directory. Se requieren referencias operativas con interfaces, tiempos de soporte y gestión real de excepciones.

Ruta de integración en ERP y TMS

La visibilidad genera valor solo cuando los eventos llegan a la planificación, ejecución y control. La ruta de integración suele partir de la telemetría y eventos de estado a través de una capa de integración hacia el TMS y el ERP. Sin un modelo de eventos canónico, surgen verdades paralelas entre el portal de la startup y el sistema central.

Como referencia sirve GS1 EPCIS 2.0: el estándar describe eventos de trazabilidad interoperables y soporta JSON, REST y patrones OpenAPI además de XML. Así se pueden compartir eventos de estado, ubicación y custodia entre socios y sistemas. Las arquitecturas de referencia, como la de cadena de suministro de Microsoft Fabric, muestran el camino desde feeds de ERP y logística hasta flujos de eventos en una capa de procesamiento común. La visibilidad sin un mapeo canónico sigue siendo un panel paralelo.

Los datos maestros deciden sobre la calidad del rastro. Los contenedores, envíos, pedidos, socios y ubicaciones deben estar correctamente mapeados; de lo contrario, las alertas operativas resultan inservibles. Los CIOs deben definir con antelación la responsabilidad del mapeo y el tratamiento de errores, incluyendo la propiedad en caso de mensajes de estado contradictorios.

Técnicamente, se recomienda una capa API estrecha y versionada con reglas claras de reintentos, idempotencia y reprocesamiento. Los eventos push para excepciones y los pull para actualizaciones posteriores reducen la improvisación en el día a día. El monitoreo debe observar la propia tubería (pipeline), no solo la interfaz de usuario de la startup.

A nivel organizativo, la ruta requiere un modelo operativo: ¿quién recibe los incidentes?, ¿quién mantiene los mapeos?, ¿quién decide ante cambios de esquema? Sin estos roles, la integración sigue siendo un artefacto de proyecto. Con ellos, la visibilidad se convierte en parte de la cadena de suministro y no en un panel paralelo.

Componentes contractuales: depósito en garantía, cláusula de salida y portabilidad de datos

Los contratos con proveedores críticos de software garantizan la continuidad del servicio más allá de la fase de demostración. El depósito en garantía del código fuente o de los artefactos de despliegue solo surte efecto si incluye instrucciones documentadas de compilación y operación, así como los casos desencadenantes definidos. Sin viabilidad técnica, el depósito en garantía carece de valor real.

Los motivos típicos de liberación, según las guías y prácticas habituales de depósito en garantía, incluyen la insolvencia, la interrupción del soporte, la suspensión temporal o definitiva de la actividad comercial y el incumplimiento prolongado de las obligaciones de mantenimiento en curso. El alcance del depósito debe abarcar el código fuente, los artefactos de despliegue, las dependencias y la documentación de compilación. Las obligaciones de verificación -desde la revisión estructural hasta la comprobación funcional de compilación y operación- determinan si el depósito es utilizable en caso de emergencia.

Las cláusulas de salida regulan la rescisión, la migración y los plazos de transición en meses, adaptados a la arquitectura del sistema. Resultan clave las obligaciones de apoyo en la exportación de datos, los precios por asistencia en migración y el tratamiento de los subprocesadores tras un cambio de proveedor o una adquisición. Un cambio de control debe activar un derecho de inspección y, en su caso, un derecho de rescisión especial.

La portabilidad de datos es la moneda fuerte en la salida de un servicio SaaS. Desde el 12 de septiembre de 2025, rige el Reglamento de Datos de la UE (Reglamento (UE) 2023/2854). El capítulo VI obliga a los proveedores de servicios de tratamiento de datos -incluidos los SaaS- a facilitar el cambio: los datos y activos digitales exportables deben ser portables, sin obstáculos técnicos o contractuales innecesarios. Los contratos deben especificar formatos, integridad, frecuencia y pruebas de exportación, incluyendo eventos históricos y configuraciones. Los informes en PDF no garantizan capacidad de salida. Los formatos legibles por máquina junto con la documentación del esquema permiten reconfigurar la visibilidad.

La responsabilidad, los acuerdos de nivel de servicio (SLA) y las pruebas de seguridad deben tratarse en la misma mesa que el alcance funcional. En el caso del hardware IoT, cuentan el suministro de repuestos, el soporte de firmware y las obligaciones de fin de vida útil. De lo contrario, la salida terminará en puntos ciegos vinculados al dispositivo, aunque la migración del software se haya realizado correctamente.

Matriz de decisión: plataforma corporativa versus especialista

La decisión se basa en el perfil de riesgo del caso de uso. La experiencia de usuario en la demo queda en un segundo plano. Las plataformas corporativas destacan en procesos estándar, base de datos compartida, contratos de operación existentes y rutas de auditoría. Los especialistas sobresalen en ventajas funcionales específicas, madurez en el mercado y conexión con fuentes de datos de nicho.

Una matriz sólida pondera la proximidad estratégica al proceso clave, el esfuerzo de integración, el riesgo del proveedor, el tiempo hasta el valor (Time-to-Value), el coste total de propiedad (TCO) a lo largo del ciclo de vida y los costes de salida. Gartner define el TCO como una visión holística de los costes más allá de los límites empresariales y temporales: adquisición, operación, integración, formación y sustitución. En la práctica, para la visibilidad, los bloques de costes incluyen licencias y alojamiento, esfuerzo de integración y mapeo, operación y monitorización, pruebas de seguridad, costes de migración y depósito en garantía, así como el esfuerzo de salida y reconfiguración. Los importes concretos en euros son específicos de cada empresa. Además, cuentan la madurez en seguridad, la alineación con la hoja de ruta y la capacidad de procesar los datos en el contexto propio del ERP y el TMS.

Donde el seguimiento solo genera visibilidad y es fácilmente intercambiable, el especialista puede ser la mejor opción. Donde el seguimiento tiene un impacto en el control y la facturación, aumenta la presión hacia una plataforma o, al menos, una arquitectura estricta de satélites. Las formas híbridas son legítimas si la propiedad, las interfaces y la capacidad de sustitución están establecidas por escrito.

La trampa reside en el criterio de evaluación. La experiencia de usuario en la demo y las noticias de captación de fondos miden la madurez comercial. La madurez operativa se demuestra con pruebas de seguridad, referencias de integración, capacidad de exportación y continuidad de servicio garantizada contractualmente. Los CIO priorizan la capacidad de salida como criterio de selección antes del piloto.

Para el CIO y el CDO, esto implica una consecuencia clara: las startups de visibilidad pueden aportar velocidad, siempre que la estrategia TI garantice conectividad, portabilidad de datos y salida como entregables de igual rango. Quien integre estos aspectos en la due diligence, la arquitectura y el contrato, incorporará la agilidad del especialista sin asumir riesgos operativos descontrolados en el ecosistema DACH.

Preguntas frecuentes

¿Cuándo es viable un modelo mixto entre la plataforma corporativa y una *startup* de visibilidad?

Los modelos mixtos funcionan cuando el seguimiento proporciona visibilidad y gestión de excepciones, mientras que la facturación y el control de SLA se mantienen en el ERP o el TMS. La propiedad, las interfaces y la capacidad de desvinculación deben quedar establecidas por escrito. La matriz de decisión pondera la proximidad al proceso central, el esfuerzo de integración, el riesgo del proveedor, el tiempo hasta el valor, el TCO y los costes de salida a lo largo del ciclo de vida.

¿Qué certificados de seguridad deben presentar los proveedores de IoT y visibilidad?

Se requieren conceptos de roles y permisos, cifrado en tránsito y en reposo, registros (*logging*), separación de inquilinos (*mandantentrennung*), así como certificados de pruebas de penetración y respuesta a incidentes. Como referencia, se utilizan el CAIQ de la Cloud Security Alliance, la norma ISO/IEC 27001:2022 Anexo A 5.19 a 5.23, el BSI C5:2026 con 168 criterios y las directrices de ENISA sobre identidad de dispositivos y rutas de actualización. Para IoT, se añaden la identidad de los dispositivos, las rutas de actualización y el manejo de puntos finales comprometidos.

¿Qué hace técnicamente utilizable un depósito en garantía (*Escrow*) en caso de emergencia?

Se depositan el código fuente o los artefactos de despliegue, incluyendo dependencias y documentación de compilación. Los desencadenantes típicos son la insolvencia, la interrupción del soporte, el cese de la actividad comercial y el incumplimiento sostenido del mantenimiento. La verificación hasta la compilación funcional y la inspección operativa, así como las instrucciones documentadas de compilación y operación, determinan la ejecutabilidad.

¿Qué contenidos de exportación exige el Reglamento de Datos de la UE (*EU Data Act*) para la salida de SaaS?

Desde el 12 de septiembre de 2025, el capítulo VI del Reglamento de Datos de la UE obliga a los proveedores de servicios de procesamiento de datos a facilitar el cambio. Los contratos deben especificar formatos, integridad, frecuencia y pruebas de exportación, incluyendo eventos históricos y configuraciones. Las exportaciones legibles por máquina con documentación de esquema permiten la reconfiguración de la tubería (*pipeline*) de visibilidad.