Acuerdos entre empresas y startups sin salida de TI

07.07.2026

6 min de lectura

Las startups aportan velocidad. Los departamentos especializados quieren ese mismo ritmo en los pilotos y la escalabilidad. Sin un plan de salida y de integración, la TI queda atrapada en stacks en la sombra, flujos de datos poco claros y contratos que, en caso de emergencia, apenas sirven para algo.

Lo más importante en resumen

Pocas colaboraciones con startups. Según Bitkom 2025, solo el 31 % de las empresas cooperan con startups; donde se logra, la seguridad y la arquitectura suelen aplicarse después del piloto, generando TI en la sombra.
Seguridad e identidades antes del piloto. El estándar mínimo C5:2026, IAM corporativo con SSO y MFA, así como la residencia de datos y los subprocesadores documentados por escrito deben estar definidos antes del primer usuario productivo.
Trampas en la escalabilidad: APIs y licencias. APIs inestables, cláusulas de true-up y soporte sin SLAs medibles encarecen el crecimiento; la due diligence técnica debe realizarse antes de autorizar la escalabilidad.
Salida operativa y cuadro de mando del CIO. Formatos de exportación, certificados de eliminación y servicios de transición hacen tangible la salida de TI; el cuadro de mando evalúa IAM, residencia, API, licencia, soporte y salida antes del piloto y la escalabilidad.

RelacionadoCorporate Venture Building: startups dentro del grupo / Por qué las startups pierden clientes pese a contar con miles de millones

Motivos típicos de los acuerdos y puntos ciegos en TI

Los motivos detrás de los acuerdos entre grupos y startups suelen ser comprensibles. Los departamentos especializados buscan rapidez en la generación de valor, acceso a capacidades de nicho o una prueba de concepto que internamente podría tardar meses. Según el estudio de Bitkom «Digitalización de la economía» (2025), solo el 31 % de las empresas cooperan de alguna forma con startups; dos tercios (67 %) no lo hacen. Donde sí se colabora, las áreas de compras y de innovación suelen gestionarlo mediante contratos marco, presupuestos de innovación o formatos de corporate venture, evaluando principalmente la capacidad de entrega y el precio. La guía «Winning Together» de Nesta (con Startup Europe Partnership) señala que la compra a startups exige un enfoque distinto en procesos y gestión de riesgos que el clásico aprovisionamiento de proveedores, y que registros de proveedores rígidos y condiciones de pago suelen bloquear estas colaboraciones.

Los puntos ciegos en TI rara vez surgen por mala intención. Aparecen porque la seguridad, la arquitectura y el modelo operativo solo se activan tras el piloto. Para entonces, la startup ya está integrada en los procesos especializados, las cuentas de usuario existen en paralelo y los datos residen en regiones cloud no autorizadas por el grupo. Una reestructuración posterior resulta más costosa que una aprobación limpia antes del lanzamiento.

Los puntos ciegos típicos afectan a identidades, registros, copias de seguridad y a la pregunta de quién puede gestionar realmente el stack en caso de incidencia. Con frecuencia también faltan definiciones claras sobre subprocesadores, residencia de datos y conexión con sistemas existentes. Lo que comienza como un piloto aislado acaba convirtiéndose en una TI paralela con su propia gobernanza.

Seguridad, identidades y residencia de datos antes del piloto

La diligencia debida en materia de seguridad debe realizarse antes del piloto, no después del primer usuario productivo. Basado en el catálogo de criterios C5:2026 del BSI -el catálogo de criterios de cumplimiento para computación en la nube del Bundesamt für Sicherheit in der Informationstechnik-, un estándar mínimo incluye un concepto de roles y permisos, cifrado en tránsito y en reposo, registro con plazos de conservación verificables, así como la clarificación de qué datos personales y de negocio procesa la startup. El C5 proporciona a los clientes de cloud una base auditable para su propio gestión de riesgos y exige transparencia sobre ubicaciones, subproveedores y responsabilidades compartidas.

Las identidades son el factor más común de riesgo y el error más frecuente. Sin integración con el IAM corporativo (Identity and Access Management, es decir, la gestión centralizada de identidades y derechos de acceso), surgen cuentas locales, contraseñas compartidas y usuarios huérfanos tras cambios de personal. El inicio de sesión único (Single Sign-On), la autenticación multifactor (MFA) obligatoria y un proceso documentado de desvinculación deben figurar en el contrato y en el concepto operativo antes de que fluyan datos reales de clientes o de producción.

La residencia de datos y el tratamiento por encargo no son un mero apéndice en la región DACH. La Comisión Europea, mediante la Decisión de Ejecución (UE) 2021/915, ha establecido cláusulas contractuales tipo entre responsables y encargados del tratamiento según el artículo 28 del RGPD; estas regulan, entre otros aspectos, la obligación de seguir instrucciones, los subprocesadores y el manejo de los datos al finalizar el contrato. Los lugares de procesamiento, los subprocesadores, la ubicación de las copias de seguridad y la posibilidad de que el soporte acceda desde terceros países deben quedar fijados por escrito antes del piloto. Quien espere a aclarar estos puntos durante la fase de escalado, negociará bajo presión temporal y con el negocio en marcha.

Trampas en APIs, licencias y soporte durante el escalado

En la fase de escalado, muchos acuerdos fracasan en la interfaz. La idea puede ser viable, pero la integración suele ser lo primero en fallar. APIs ausentes o inestables obligan a realizar exportaciones manuales, integraciones paralelas no documentadas y duplicación de datos. Los límites de tasa (rate limits), campos no documentados y cambios disruptivos sin estrategia de versiones encarecen la operación y hacen que los informes sean poco fiables. Por ello, una revisión de APIs e integraciones debe formar parte de la diligencia debida técnica antes de autorizar la escalabilidad.

Las trampas en licencias suelen manifestarse con el crecimiento de usuarios. Modelos de asignación por asiento (seat), paquetes de módulos, precios basados en métricas y tarifas por entornos adicionales pueden superar significativamente los costes inicialmente calculados. En contratos de SaaS y software son habituales las cláusulas de ajuste (true-up): el proveedor compara periódicamente el uso real con la cantidad licenciada y factura el exceso. Los derechos de auditoría suelen complementarse con plazos de preaviso y asunción de costes si la sublicencia supera un umbral (normalmente entre el 5 y el 10 por ciento). Igualmente crítico es restringir la cesión de derechos de uso a sociedades del grupo.

El soporte es un riesgo operativo durante el escalado. Deben aclararse con antelación los tiempos de respuesta, las vías de escalado, la disponibilidad en modo *on-call* y si el soporte solo opera en inglés y en determinadas zonas horarias. Sin un SLA con objetivos medibles y sin un interlocutor claro, el área técnica se verá en problemas en caso de incidencias, aunque el contrato prometa «soporte incluido».

Cláusulas de salida que realmente funcionan

Una salida tecnológica solo es tan buena como su viabilidad operativa. Los plazos de rescisión por sí solos no bastan. El artículo 28, apartado 3, letra g del RGPD exige que, tras la finalización del tratamiento, el encargado elimine los datos personales a elección del responsable o los devuelva, eliminando las copias existentes en la medida en que no exista una obligación de conservación. Las cláusulas contractuales tipo de la Comisión Europea (2021/915) abordan este aspecto operativamente. Por ello, son necesarias plazos y formatos para la exportación de datos, la integridad de la devolución, pruebas de eliminación y el tratamiento de datos derivados, así como de los registros (logs).

El depósito en garantía (*escrow*) y el acceso al código fuente no son una panacea, pero en dependencias críticas constituyen una herramienta útil. El *escrow* solo tiene sentido si los desencadenantes están claramente definidos, la versión depositada se mantiene actualizada y el equipo interno tiene capacidad para operar el código. Sin documentación de compilación y operación, el *escrow* es un gasto caro para calmar conciencias.

Los servicios de transición tras la rescisión determinan el éxito real de la salida. Entre ellos se incluyen la operación paralela temporal, las obligaciones de colaboración de la startup durante la migración y la prohibición de dificultar artificialmente la exportación. También es relevante aclarar quién podrá mantener las interfaces y conectores tras la salida. Quien no regule esto con antelación, se verá abocado a un segundo proyecto de sustitución además del ya en curso.

Ficha técnica para el punto de aprobación del CIO

Una ficha técnica del CIO traduce los puntos mencionados en una lógica de aprobación previa al piloto y antes de la escalabilidad. La norma ISO/IEC 27001:2022 exige, en los controles del Anexo A A.5.19 a A.5.22, procesos para la seguridad de la información en las relaciones con proveedores, requisitos de seguridad en contratos, control de la cadena de suministro y supervisión continua. El BSI-C5 complementa, para los clientes de cloud, una orientación verificable para la selección y el control de riesgos. Al menos deben evaluarse: integración IAM, clasificación y residencia de datos, pruebas básicas de seguridad, madurez de APIs e integraciones, modelo de licencias y costes durante el escalado, modelo de soporte y operaciones, así como capacidad de salida, incluyendo exportación y eliminación.

Cada punto requiere un responsable y un estado claro: aprobado, aprobado con condiciones o bloqueado. Las condiciones sin plazo ni obligación de justificación no constituyen un control real. Para el paso de escalabilidad, la ficha técnica debe ser más estricta que para el piloto aislado, ya que aumentan el número de usuarios, el volumen de datos y la dependencia de los procesos.

La ficha técnica no frena la innovación. Evita que la retórica innovadora de los departamentos de negocio posponga riesgos de TI como si fueran resolubles más adelante. El punto de aprobación del CIO es el momento en que se equilibran velocidad y capacidad de control. Si falta este punto, surge una TI corporativa tipo startup sin una debida diligencia de startup sólida ni cláusulas de salida de TI efectivas.

Aprueba acuerdos con startups sin una salida de TI equivale a comprar velocidad a crédito. El precio se paga después con stacks en la sombra, sorpresas en licencias y proyectos de migración bajo presión. La consecuencia lógica para el CIO y el CDO es sencilla: cada piloto necesita una base de seguridad e identidad; cada escalado, claridad en APIs, licencias y soporte; y cada contrato, una salida operativamente verificable.

Preguntas frecuentes

¿Qué nivel de exigencia debe tener la CIO-Scorecard para un piloto aislado en comparación con la fase de escalado?

Para el piloto, la aprobación mínima incluye vinculación IAM, clasificación de datos, residencia y comprobantes básicos de seguridad antes de que fluyan datos del cliente. El proceso de escalado debe ser más estricto, ya que aumentan el número de usuarios, el volumen de datos y la dependencia de los procesos, además de incorporar claridad en APIs, licencias y soporte. Cada punto requiere un responsable y un estado: aprobado, aprobado con condiciones o bloqueado. Las condiciones sin plazo ni obligación de justificación no gestionan el acuerdo.

¿Cuándo merece la pena un depósito de código fuente (escrow) en caso de dependencia crítica de una startup?

El escrow es una herramienta para dependencias críticas cuando los desencadenantes están claramente definidos, la versión depositada se mantiene actualizada y el área de TI cuenta con capacidad interna para construir y operar. Si falta la documentación operativa, el escrow se convierte en un gasto innecesario. Complementa la salida, pero no sustituye la exportación de datos en los formatos acordados ni los servicios de transición temporal tras la rescisión.

¿Cómo verificar antes de firmar si las cláusulas de salida operan correctamente?

Antes de la firma, definir y, si es posible, simular: plazos y formatos para la exportación de datos, integridad de la devolución, certificados de eliminación, así como el manejo de datos derivados y registros. Asegurar contractualmente un funcionamiento paralelo temporal, las obligaciones de colaboración durante la migración y la prohibición de dificultar artificialmente la exportación. También hay que aclarar quién podrá mantener las interfaces y conectores tras la salida.

¿Por qué los procesos estándar de compras suelen llegar tarde en acuerdos con startups?

Departamentos de compras e innovación suelen evaluar capacidad de entrega y precio mediante contratos marco o presupuestos de innovación, mientras que seguridad, arquitectura y modelo operativo solo se revisan tras el piloto. Iniciativas como Nesta y Startup Europe Partnership destacan que la compra de startups requiere un enfoque distinto en procesos y gestión de riesgos que la adquisición clásica de proveedores. Registros rígidos de proveedores y condiciones de pago bloquean colaboraciones, mientras que identidades no aclaradas, subprocesadores y APIs generan sombra de TI más adelante.

Más para leer en Digital Chiefs

Digital ChiefsAlemania como ubicación necesita productividad Digital ChiefsIT de la cadena de suministro sin soberanía de datos Digital ChiefsModernización de WAN: el ancho de banda no es la solución

Más de la red MBF Media