Accesos huérfanos: la brecha cibernética silenciosa
Benedikt Langer
5 Min. Lectura Las cuentas de servicio, claves de API y agentes de IA superan a menudo a las cuentas ...
El análisis de HBR de más de 12.000 casos de aplicación reales muestra un patrón claro: las empresas que escalan la IA no la tratan como un proyecto tecnológico, sino como una decisión de presupuesto y propiedad. El otro 70 por ciento produce pilotos que nunca llegan a la cuenta de resultados.
Lo más importante en resumen
Harvard Business Review ha evaluado en 2026 una de las mayores colecciones de implementaciones reales de IA: no encuestas ni escenarios hipotéticos, sino proyectos documentados de empresas con más de 1.000 empleados. El resultado es a la vez desalentador y preciso.
La cifra que marca la dirección
68 por ciento. de los proyectos analizados se quedaron en prototipos o pilotos limitados. Solo el 29 por ciento alcanzó un estado en el que la contribución de valor se medía regularmente y la operación se transfería a la organización lineal. El 3 por ciento restante se canceló más tarde. Fuente: HBR, análisis de más de 12.000 casos de IA, 2026.
Lo decisivo no es la técnica. Los casos exitosos utilizan mayoritariamente los mismos modelos y plataformas que los fracasados. La diferencia radica en el anclaje antes del primer *prompt*. Los datos muestran además que la distancia entre «piloto en vivo» y «contribución de valor en el balance» es de 14 meses de media, y en muchos casos nunca se cierra.
El análisis identifica tres patrones que aparecen repetidamente en proyectos que escalan, y que faltan en la mayoría de los demás.
1. El anclaje en P&L. En los casos que escalan, desde el principio hay un responsable de negocio con responsabilidad sobre los resultados en la mesa. No como «parte interesada», sino como codescisor sobre el alcance, el presupuesto y los criterios de cancelación. En las empresas DACH, suele ser el CFO o un director de área que asume los costes más tarde. Sin este anclaje, la IA se convierte en un centro de costes que nadie defiende cuando llega la siguiente ronda presupuestaria.
2. La regla estricta de los 90 días. Los equipos exitosos definen antes del primer *sprint* tres criterios medibles cuyo incumplimiento conlleva la cancelación automática del proyecto. Ejemplos típicos: alcanzar el punto de equilibrio en una cohorte de usuarios definida en 90 días o reducir un tiempo de proceso concreto en al menos un 18 por ciento manteniendo la calidad. Sin esta regla, los pilotos se convierten en experimentos permanentes que consumen recursos y credibilidad.
3. Plataforma en lugar de colección de casos de uso. Las empresas que escalan construyen pronto una capa de plataforma estrecha pero vinculante (datos, derechos de acceso, *logging*, FinOps). Las demás inician en paralelo docenas de casos de uso en herramientas diferentes y luego se sorprenden por los costes de gobernanza y las inconsistencias. La plataforma no es decoración: es la condición para que el segundo y tercer caso de uso sean más baratos que el primero.
Los datos de HBR son globales. Para las empresas alemanas y austriacas, sin embargo, se añade una dimensión adicional: la fricción organizativa y regulatoria es sistemáticamente mayor.
Los comités de empresa y la codeterminación alargan el tiempo entre el piloto y el despliegue entre cuatro y siete meses de media -esto no es un error, sino una realidad-. Quien lo ignore, planifica con supuestos estadounidenses o asiáticos y fracasa ante la primera escalada. Los procesos de compra y los contratos heredados hacen el resto.
La diferencia decisiva no está en el algoritmo. Está en la pregunta de quién responde al final por el resultado.
En los casos que escalan, hay un patrocinador claramente designado cuyo bonus o presupuesto en el próximo ciclo depende del resultado. Esto genera una disciplina totalmente distinta en cuanto a alcance, calidad de los datos y gestión del cambio que en los proyectos puramente de «oficina digital». Los datos de HBR muestran además que las empresas que empiezan la IA como centro de costes escalan con menos frecuencia que aquellas que la tratan como una inversión con un cálculo claro de amortización.
La diferencia no es semántica: determina si el CFO defiende el proyecto tras nueve meses o lo entierra discretamente. En los casos exitosos, la medición del éxito no la definió el equipo del proyecto, sino el responsable operativo posterior.
«Dejamos de recopilar casos de uso. En su lugar, definimos un único indicador por el que el director del área responde personalmente. De repente, todo lo demás fue mucho más sencillo».
– CIO de un grupo de ingeniería mecánica, DACH, 2026
No todo piloto debe escalar. El análisis también muestra casos en los que se experimentó de forma consciente para desarrollar competencias o entender un riesgo estratégico. La diferencia con los proyectos fallidos radica en la decisión deliberada y en el límite temporal claro.
Sin embargo, quien tras el tercer piloto sigue sin tener una regla de plataforma o de responsabilidad, ya no genera una curva de aprendizaje, sino solo costes. Los 12.000 casos distinguen claramente entre «aprendizaje controlado» y «experimentación difusa sin criterios de cancelación».
Quien inicie ahora un nuevo impulso en IA debería fijar tres cosas antes del primer taller:
Sin estos tres elementos, es muy probable que este proyecto acabe también en la colección de los 12.000 casos como otro piloto sin escalar. La tecnología es, hoy en día, la parte más pequeña de la ecuación.
Las empresas que escalan en el análisis suelen empezar con uno, como máximo tres, y solo amplían tras validar con éxito la plataforma. Más de cinco pilotos paralelos sin infraestructura común se correlaciona fuertemente con el fracaso. Los costes de gobernanza y los cambios de contexto crecen más rápido que el aprendizaje obtenido.
Estas herramientas escalan rápido en productividad individual. Sin embargo, los casos de HBR muestran que el gran valor añadido casi siempre proviene de sistemas integrados en procesos, no de asistentes generales. Ambas opciones son legítimas, pero no deben confundirse. Los aumentos de productividad de empleados individuales son más fáciles de lograr que reducciones sostenibles de costes en procesos.
Ejemplos exitosos en la región DACH han integrado al comité de empresa desde el principio como codesarrollador, no como obstáculo. Esto implica: datos concretos sobre el impacto en los puestos de trabajo y acuerdos claros sobre transparencia y codeterminación antes del primer piloto. Requiere tiempo, pero evita escaladas y renegociaciones posteriores bajo presión.
Solo si este responsable tiene también responsabilidad presupuestaria y de resultados. Los puestos de staff sin vinculación a P&L generan, según el análisis, significativamente más pilotos sin escalar que los responsables de línea con impacto directo en costes.
Más del MBF Media Netzwerk
Más para leer en Digital Chiefs
Digital ChiefsAlemania como ubicación necesita productividadDigital ChiefsMade for Germany: Cuanto valen realmente 735 mil millonesDigital ChiefsEl Chief AI Officer ya está aquí. El problema sigue igualFuente de la imagen: generada por IA (julio de 2026).