IA local: gobernanza antes de la compra de hardware
Benedikt Langer
10 min de lecturaCuatro desarrollos en dos semanas demuestran que la IA operada en local va mucho más ...
Leer artículo
5 min de lectura
Los hyperscalers siguen construyendo. Sin embargo, analistas y llamadas sobre resultados describen un ritmo de crecimiento más lento en el gasto de inversión. En los contratos de cloud con IA a varios años, el escenario en el compromiso es clave: qué ocurre si la capacidad, el precio o la salida ya no se ajustan a la decisión estratégica.
Lo más importante en resumen
- Situación: Los niveles absolutos de Capex de los hyperscalers siguen siendo altos. El ritmo de crecimiento se ralentiza en varios escenarios – los contratos con una duración de 3 a 5 años lo notan antes que los informes trimestrales.
- Palancas: La escalonación del compromiso, las ventanas de salida y la capacidad reservada deben incluirse en el mismo contrato que el descuento – con la inferencia on-premise como interruptor de escenario.
- Primer paso: Calcular tres escenarios (arranque, meseta, ralentización) con los mismos KPI antes de firmar el próximo contrato marco.
RelacionadoEl hardware supera a los acuerdos de software – Reorganizar el Capex / Token-OPEX: La inferencia dirige, no el presupuesto por asiento
Contrato de cloud con IA se refiere aquí al acuerdo plurianual sobre capacidad de computación, modelos o rendimiento de inferencia: volumen, precio, capacidad reservada y salida. Vincula el presupuesto a un escenario de uso y, por tanto, necesita escalonamientos, cláusulas de reapertura, portabilidad y costes de salida a lo largo de varios años de operación.
El debate público se centra en la cotización bursátil y en semanas puntuales de resultados. En la compra, sin embargo, importa otra cosa: los compromisos plurianuales para capacidad de cloud e IA. Quien asegura 2027 y 2028, compra en un mundo donde los gastos de inversión de los hyperscalers pueden seguir siendo altos en términos absolutos – mientras que el ritmo de crecimiento de la curva de Capex se ralentiza en varios escenarios de mercado.
Esto no es una contradicción. Es la diferencia entre nivel y pendiente. Un contrato que solo maximiza el descuento actual ignora la pendiente. Un contrato que solo teme a la pendiente desperdicia capacidad. Útil es una matriz de escenarios que traduzca ambas dimensiones en cláusulas.
El nivel se mantiene. La pendiente cambia la negociación.
Los niveles absolutos de Capex de los grandes proveedores de infraestructura cloud y IA siguen en una magnitud que define la capacidad regional, la disponibilidad de GPU y el margen de descuento para empresas. Al mismo tiempo, los analistas y las guías de resultados describen con mayor frecuencia una desaceleración del ritmo de crecimiento, no una paralización de la expansión.
Para las compras en la región DACH, esto no implica pánico ni un cheque en blanco. Plantea una cuestión de planificación: ¿qué ritmo incluye el modelo interno de TCO de IA? Quien presupuesta un crecimiento lineal y obtiene una meseta, se queda con compromisos sin uso. Quien presupuesta una meseta y se encuentra con un escenario de crecimiento, se queda sin capacidad y paga precios spot.
Unidad de decisión
La unidad es el compromiso por escenario. Más la salida anual y el umbral a partir del cual la inferencia interna resulta más económica y controlable que la ruta predeterminada por API.
Los costes de tokens y runtime (véase artículo relacionado sobre OPEX de tokens) siguen siendo la capa variable. El ritmo de Capex de los proveedores controla la capa inferior: cuán caro y escaso se vuelve el acceso a capacidad física y contractual sobre la que se ejecuta la inferencia. Ambas capas deben incluirse en el mismo documento de decisión: medidas por separado, negociadas conjuntamente.
Tres escenarios, una lógica contractual
En lugar de un pronóstico, bastan tres escenarios sólidos. Cada uno necesita los mismos KPI: horas de GPU/TPU utilizadas, coste por resultado de los flujos de trabajo clave, proporción de Reserved frente a On-Demand, costes de salida y tiempo hasta la replataforma en meses.
| Escenario | Qué ocurre en el mercado | Qué debe permitir el contrato |
|---|---|---|
| Crecimiento | El Capex y la capacidad regional siguen creciendo con fuerza; la Reserved Capacity escasea. | Ventanas de opción tempranas para contingentes adicionales; topes de precio en caso de exceso; respaldo multi-región. |
| Meseta | El nivel se mantiene alto, pero el ritmo se desacelera; los descuentos y la disponibilidad se estabilizan de forma desigual. | Escalonamiento en lugar de compromiso único; reaperturas anuales; definición clara de «compromiso no utilizado». |
| Desaceleración | El crecimiento frena de forma notable; los proveedores priorizan el margen y la ocupación de los parques existentes. | Salida sin penalización automática; portabilidad de las cargas de trabajo; inferencia on-prem/privada como vía negociada. |
Los escenarios son marcos de planificación. No son una previsión de mercado. Las cifras de resultados e informes de investigación solo sirven como supuestos iniciales, nunca como verdad contractual.
Quien completa los tres escenarios con los mismos KPI identifica al instante dónde el marco contractual planificado solo funciona en fase de crecimiento. Ese es el punto en el que compras y arquitectura deben hablar el mismo idioma: menos «más descuento» y más «qué cláusula sobrevive a la meseta».
Cuatro cláusulas que marcan la diferencia
Los descuentos son visibles. Los errores caros se esconden en otro lugar. Cuatro tipos de cláusulas separan un marco negociable de IA en la nube de un simple papel de buenas intenciones.
1. Escalonamiento de compromiso en lugar de carga frontal. En vez de comprometer el 100 % del volumen de tres años en el primer año, el escalonamiento vincula tramos a hitos de uso. Cada tramo incluye una cláusula de salida con plazo. Esto suele costar algo de descuento, pero evita el error más caro: comprometerse sin carga de trabajo.
2. Salida y portabilidad con punto de medición. Una salida sin portabilidad de datos y modelos es pura fachada. El contrato especifica formatos, plazos de exportación y una prueba anual. Quien evita la prueba, sabe que la salida no existe.
3. Capacidad reservada con fecha de caducidad y reasignación. Las reservas sin opción de reasignación a SKU relacionadas y sin lógica de caducidad generan contingentes muertos. La regla de reasignación debe figurar en el cuerpo principal, no en un FAQ del proveedor.
4. Disparadores de precio y capacidad. Si la capacidad de una región cae por debajo de un umbral acordado o el precio de referencia de una SKU definida aumenta más de un X %, se abre una renegociación. X se fija internamente, no por defecto del proveedor.
El descuento en la nube más barato resulta caro si asume un escenario que el despliegue de IA propio no puede sostener.
Dónde la inferencia on-premise supera al API por defecto
La inferencia on-premise o privada no es una alternativa a la nube, sino el interruptor en escenarios de estancamiento o escalada con capacidad limitada. La decisión depende de tres métricas cuantificables: carga de trabajo estable con alta densidad de tokens, requisitos predecibles de latencia y la capacidad de operar internamente suites de evaluación y enrutamiento.
Quien no pueda medir estas tres métricas, seguirá comprando el API por defecto -y debería llamarlo así sin rodeos-. Quien sí pueda medirlas, negocia un tramo en la nube más reducido y mantiene abierto un camino interno. Hacer o comprar modelos de IA es el segundo eje: un modelo alemán o europeo suele compensar solo cuando los costes de inferencia y la residencia de datos entran en la misma ecuación.
La inversión en hardware propio (servidores, refrigeración, contratos eléctricos) traslada el riesgo, no lo elimina. El artículo relacionado sobre la reorganización de CAPEX en hardware vs. software sigue siendo el debate paralelo. Aquí solo importa la interfaz: ¿qué cargas de trabajo tienen un cálculo de punto de equilibrio sólido frente a la ruta del hiperescalador -y están recogidas en el contrato como opción, no como una diapositiva de PowerPoint?
90 días hasta la próxima firma
La prueba es sencilla: ¿se mantendría la misma firma si el crecimiento del CAPEX de los proveedores en 2027 fuera significativamente más plano que en 2025/26? Si la respuesta depende de un único descuento, el contrato es demasiado frágil.
Preguntas frecuentes
¿Basta un contrato multi-nube como protección contra el ritmo de Capex?
Solo si las cargas de trabajo son realmente portátiles y el segundo proveedor es accesible en capacidad. Multi-nube sin prueba de salida y sin ruta de datos es un doble compromiso. No es una protección.
¿Deberían los resultados trimestrales de los hyperscalers guiar el contrato?
Como supuesto inicial sí, como variable de control no. El contrato se rige por el uso, la escalabilidad y los desencadenantes, no por la próxima diapositiva de resultados.
¿Cuándo vale la pena la inferencia privada frente a la API por defecto?
Con carga estable, suite de evaluación clara y coste por resultado medible. Sin estas tres variables, la API por defecto sigue siendo más honesta -y más barata en gobernanza-.
¿Cuál es el error más común en los contratos marco de IA en la nube?
Compromisos iniciales elevados sin escalonamiento y sin prueba anual de portabilidad. El descuento parece bueno. La parte no utilizada, no.
¿Cómo se relaciona esto con el OPEX de tokens?
El OPEX de tokens controla la capa de uso variable. El ritmo de Capex de los proveedores regula la disponibilidad y la disciplina de precios de la capacidad subyacente. Ambos deben incluirse en la misma propuesta de decisión.
Más del MBF Media Netzwerk
Más para leer en Digital Chiefs
Digital ChiefsRígidos contratos de red fija frente a la fluida Ley de Energías RenovablesDigital ChiefsCuándo la nube no es la mejor opciónDigital ChiefsCómo frenar el código abierto sin prohibirloFuente de la imagen: generada por IA (julio 2026)