La responsabilidad organizacional según NIS2 entra en vigor a pesar del registro
Tobias Massow
9 Min. tiempo de lectura Unos 11.000 empresas afectadas en Alemania siguen sin registro en el BSI a ...
Leer artículo
6 min de lectura
El 41 % de las empresas alemanas ya utilizan IA, más del doble que el año pasado. Sin embargo, en las reuniones de CIO siempre surge la misma frase costosa: el piloto funcionó, pero el proyecto nunca llegó a la fase de operación regular. El cuello de botella rara vez es la tecnología. Reside en la integración, la gestión del cambio y las expectativas que nunca se pusieron a prueba durante el piloto.
Lo más importante en resumen
- El cuello de botella está en el escalado. El 41 % de las empresas utilizan IA, pero el salto del piloto a la operación regular sigue siendo el verdadero obstáculo para la mayoría.
- El fracaso rara vez se debe a la tecnología. La integración, la gestión del cambio y la gestión de expectativas deciden si el piloto se convierte en un sistema productivo.
- Los costes se disparan en la transición. Una de cada tres empresas afirma que la IA es más cara de lo esperado. Los costes de tokens, alojamiento e integración solo se hacen evidentes en el funcionamiento continuo.
Relacionado:Estudio Bitkom: Los proyectos de IA se descontrolan/IA en la junta directiva: ¿Quién decide, quién responde?
Por qué el salto del piloto a la operación regular fracasa tan a menudo
¿Qué es la IA en operación regular? Operación regular significa que una aplicación de IA funciona de forma continua, para todos los usuarios previstos y con datos reales en tiempo real, en lugar de limitarse a un piloto acotado. Solo entonces se demuestra si el sistema soporta la carga, la calidad de los datos y los costes recurrentes. Precisamente esta transición es, en 2026, el punto en el que más se estancan los proyectos de IA.
Un piloto está diseñado para tener éxito. Un pequeño grupo de usuarios motivados, un conjunto de datos cuidadosamente seleccionado y un caso de uso manejable. Estas condiciones desaparecen en la operación regular. El número de usuarios aumenta, los datos se vuelven menos limpios y la carga ya no es predecible. Lo que en el piloto fue un éxito, se convierte en el día a día en una obra interminable si nadie ha planificado antes estas diferencias.
En la práctica, los obstáculos son de naturaleza organizativa: la integración en los sistemas existentes, la implicación de los empleados y las expectativas que nunca se pusieron a prueba durante el piloto. Para el CIO, esto significa que la parte difícil comienza justo después del piloto exitoso.
Cuatro razones por las que los pilotos de IA se estancan
En los postmortems de proyectos aparecen una y otra vez los mismos cuatro patrones. Ninguno de ellos es un problema tecnológico, y precisamente eso los hace tan persistentes.
Primero: el piloto demuestra lo equivocado. Muestra que el modelo puede resolver una tarea. Si la organización la realiza miles de veces al día es otra cuestión. La demo aclara la viabilidad, pero la sostenibilidad queda en el aire. Quien confunde ambas cosas despliega una prueba de viabilidad que nunca se ha probado bajo carga.
Segundo: se subestima la integración. En el piloto, la IA funciona en paralelo a los sistemas existentes. En el funcionamiento regular, debe integrarse en los ERP, CRM y sistemas de gestión de derechos. Este paso suele requerir más esfuerzo que el propio modelo y nunca se incluye en el presupuesto del piloto.
Tercero: nadie asume la operación. El piloto tiene un equipo de proyecto, pero el funcionamiento regular necesita un rol fijo en la línea. Si falta, la aplicación cae en un vacío de responsabilidad en cuanto termina el proyecto. Entonces, nadie parchea, nadie presupuesta, nadie recibe llamadas cuando falla.
Cuarto: los costes se disparan. Alrededor de un tercio de las empresas que utilizan IA afirman que esta resulta más cara de lo esperado. La razón está en la transición: el consumo de tokens, el alojamiento y la integración solo aparecen en toda su magnitud durante el funcionamiento continuo. La previsión del piloto era correcta, pero solo cubría el pequeño volumen de prueba.
Fuente: Análisis del estudio de IA de Bitkom 2026
Dónde divergen el piloto y el funcionamiento regular
El núcleo del problema puede resumirse en una tabla. Casi todo escalado fallido se debe a la confusión entre estas dos columnas.
| Dimensión | Piloto | Funcionamiento regular |
|---|---|---|
| Usuarios | un puñado de voluntarios | todos los usuarios previstos |
| Datos | conjunto de datos de prueba curado | datos reales y sucios en tiempo real |
| Costes | presupuesto del proyecto, único | partida continua por solicitud |
| Responsabilidad | el equipo del proyecto | un rol fijo en la línea |
| Medida de éxito | ¿Funciona la demo? | ¿Aporta valor en el día a día? |
Quien planifica ya en la fase piloto teniendo en cuenta la columna de la derecha no construye un piloto más bonito. Construye uno que sobrevive a la transición. Es más lento e incómodo, pero marca la diferencia entre un proyecto ejemplar y un sistema en funcionamiento.
Qué hacen diferente los CIO que logran dar el salto
Las empresas en las que la IA alcanza el funcionamiento regular rara vez lo deben a un modelo mejor. El factor decisivo son cuatro decisiones que se toman antes del piloto.
Convertir el funcionamiento regular en el requisito de entrada. Un piloto solo se aprueba si desde el principio queda claro cómo será el funcionamiento productivo: quién lo asume, cuánto cuesta y qué indicador lo justifica. Así, la pregunta difícil se resuelve al inicio, no al final.
Designar un rol en la línea antes del lanzamiento. Antes de que se ejecute la primera línea de código, ya está definido en qué departamento residirá la aplicación y quién se encargará de su operación. El equipo del proyecto construye, la línea asume. Sin esta transición, no hay funcionamiento regular, solo un proyecto que se agota.
Calcular los costes según el volumen real. La referencia es el volumen continuo esperado, incluyendo picos, extrapolado al nivel real de uso. Un cálculo honesto previo evita la sorpresa que afecta a alrededor de un tercio de las empresas.
Gestionar el cambio como parte del proyecto. Una IA transforma procesos y roles. Quien involucra a los empleados afectados solo en el despliegue, lucha contra su resistencia. La aceptación se planifica con el proyecto o no se logra.
Ninguno de estos puntos es nuevo ni costoso. La verdadera palanca está en el momento: estas decisiones deben tomarse antes del piloto. Quien las pospone, ya ha dificultado el salto antes de intentarlo.
Preguntas frecuentes
¿Por qué fracasan más los proyectos de IA en la operación regular que por la tecnología?
Porque el piloto funciona en condiciones ideales: pocos usuarios, datos limpios y un caso delimitado. En la operación regular aumentan el número de usuarios, el caos de datos y la carga. Entonces, la integración, la gestión del cambio y la gestión de expectativas deciden el éxito, más que el rendimiento del modelo.
¿Qué significa designar un rol de línea para la operación de IA?
Significa definir, antes de iniciar el proyecto, en qué departamento residirá la aplicación y quién será responsable de ella. El equipo del proyecto desarrolla la solución, pero es la línea quien la opera de forma permanente. Sin esta transición, la IA cae en un vacío de responsabilidad en cuanto finaliza el proyecto.
¿Por qué son más caras las aplicaciones de IA en la operación regular que en la fase piloto?
Porque los costes escalan con el volumen. El consumo de tokens, el alojamiento y la integración se generan por cada solicitud y se acumulan en el funcionamiento continuo. El cálculo del piloto suele considerar solo el pequeño volumen de prueba. Según Bitkom, una de cada tres empresas afirma que la IA resulta más cara de lo esperado.
¿Cómo evitar que un piloto exitoso se quede en nada?
Haciendo que la operación regular sea un requisito para aprobar el piloto. Quien aclare desde el principio quién operará la solución, cuánto costará y qué indicador medirá el éxito, integra la transición desde el inicio. Así, la pregunta difícil se resuelve al principio, cuando aún es económico responderla.
¿Qué papel juega la gestión del cambio en la escalabilidad de la IA?
Uno central. La IA transforma procesos y roles, y sin la aceptación de los empleados afectados, incluso la mejor aplicación queda sin uso. Quien involucra al personal solo en el despliegue, lucha contra la resistencia. Por eso, la gestión del cambio debe formar parte del proyecto desde el principio, no en una fase posterior.
Más del MBF Media Netzwerk
Más para leer en Digital Chiefs
Digital ChiefsServicios de Ciberseguridad Gestionados: El CISO no asume la responsabilidad exclusivaDigital ChiefsDeuda técnica: Por qué la dirección debe actuar ahoraDigital ChiefsEspacios de datos: Donde la industria inteligente y la ciudad inteligente convergenFuente de la imagen: generada por IA (junio 2026)