Por Qué el 93% de las Empresas Están Moviendo la AI Fuera de la Nube

Durante la mayor parte de la última década, el consejo predeterminado para cualquier carga de trabajo intensiva en cómputo era el mismo: ponla en la nube. Escala bajo demanda. Paga por uso. No te preocupes por el hardware.

Ese consejo se está quebrando para las cargas de trabajo de AI. No porque la nube no funcione — funciona bien para muchas cosas — sino porque la AI empresarial tiene características específicas que hacen que el despliegue exclusivamente en la nube sea cada vez más impráctico.

Los números cuentan la historia: el 93% de las empresas están activamente repatriando cargas de trabajo de AI o evaluando hacerlo. El 79% ya han movido al menos algunas cargas de trabajo de AI fuera de la nube. Este no es un movimiento marginal. Es un cambio estructural en cómo las grandes organizaciones piensan sobre la infraestructura de AI.

Este artículo cubre las tres fuerzas que impulsan el cambio, lo que significa para la preparación de datos y el despliegue de modelos, y cómo está respondiendo la industria.

Las Tres Fuerzas Detrás de la Repatriación de AI

Fuerza 1: Soberanía de Datos y Presión Regulatoria

El panorama regulatorio para AI ha cambiado más rápido de lo que la mayoría de las organizaciones anticiparon. El EU AI Act, DORA (Digital Operational Resilience Act) y regulaciones específicas del sector en salud, finanzas y defensa han creado una red de requisitos sobre dónde pueden procesarse los datos y por quién.

El 91% de las empresas ahora prefieren infraestructura on-premise para procesar datos sensibles con sistemas de AI. Esa preferencia no es ideológica — es práctica. Cuando tu equipo de cumplimiento necesita demostrar que los registros de pacientes, las transacciones financieras o los documentos clasificados nunca salieron de tu entorno controlado, la prueba más simple es que la infraestructura que los procesó nunca estuvo conectada a una red externa.

Los números sobre cómo esto afecta proyectos reales de AI son llamativos:

• El 58% de las empresas reportan que preocupaciones de residencia de datos han retrasado o bloqueado iniciativas de AI completamente
• El 74% señalan shadow AI — empleados usando herramientas de AI en la nube no autorizadas — como una preocupación crítica de seguridad
• El 91% prefieren on-premise para cargas de trabajo de AI que involucran datos sensibles

Shadow AI merece atención especial. Cuando los empleados no pueden usar las herramientas de AI aprobadas por la empresa porque las herramientas aprobadas requieren enviar datos sensibles a una API en la nube, encuentran alternativas. Pegan datos de clientes en ChatGPT. Suben contratos a Claude. Usan claves de API personales. El equipo de seguridad no lo sabe, el equipo de cumplimiento no puede auditarlo, y la exposición al riesgo se compone invisiblemente.

Las organizaciones que despliegan herramientas de AI on-premise — donde los empleados pueden usar AI sin que los datos salgan del edificio — reportan un uso de shadow AI mediblemente más bajo. El beneficio de cumplimiento es un efecto secundario de hacer que la herramienta aprobada sea más fácil de usar que la no autorizada.

Fuerza 2: Imprevisibilidad de Costos

Los precios de AI en la nube parecen directos hasta que estás ejecutando cargas de trabajo de producción a escala.

El 40% de las empresas reportan que el gasto real en AI en la nube excede sus proyecciones iniciales de presupuesto. No por poco — muchos reportan costos 2-3x sus estimaciones una vez que se contabilizan egreso de datos, crecimiento de almacenamiento, picos de consumo de tokens y los servicios auxiliares (logging, monitoreo, bases de datos vectoriales) que requiere un despliegue de AI en producción.

El problema no es que la nube sea costosa per se. Es que los costos de AI en la nube son difíciles de predecir y más difíciles de limitar. Un trabajo de procesamiento por lotes que ejecuta inferencia en 10 millones de documentos costará lo que cueste, y no sabrás el número exacto hasta que llegue la factura. Un clúster GPU on-premise tiene un costo de capital fijo y un costo operativo predecible (energía, refrigeración, personal). Para cargas de trabajo sostenidas, las matemáticas se inclinan hacia on-premise sorprendentemente rápido — frecuentemente dentro de 7-12 meses.

Esto es especialmente cierto para la preparación de datos, que es la fase más intensiva en cómputo de la mayoría de los proyectos de AI. Limpiar, transformar y estructurar datos empresariales para entrenamiento o fine-tuning implica ejecutar esos datos a través de múltiples pasos de procesamiento, cada uno de los cuales consume cómputo. A precios de tokens en la nube, preparar un corpus grande puede costar más que entrenar el modelo con él.

Fuerza 3: Requisitos de Latencia y Rendimiento

El 75% de las empresas reportan que el despliegue on-premise es necesario para cumplir requisitos aceptables de latencia para sus aplicaciones de AI.

Esto tiene sentido intuitivo para ciertas cargas de trabajo. Un sistema de inspección de calidad de manufactura que necesita clasificar defectos en tiempo real en una línea de producción no puede tolerar el ida y vuelta de 200-500ms a un endpoint en la nube, más la variabilidad de infraestructura compartida. Un sistema de soporte a decisiones clínicas embebido en un flujo de trabajo de EMR agrega fricción si cada sugerencia asistida por AI requiere una llamada de red a un centro de datos a 800 km de distancia.

Pero los requisitos de latencia van más allá de solo velocidad. Incluyen:

• Rendimiento determinista: La inferencia on-premise te da latencia consistente porque no compartes recursos con otros inquilinos
• Capacidad offline: Muchos entornos empresariales — fábricas, hospitales, operaciones de campo, instalaciones seguras — no tienen conectividad a internet confiable o ninguna
• Control de throughput: Cuando eres dueño del hardware, puedes priorizar cargas de trabajo sin competir por capacidad

De "Nube Primero" a "Ubicación Específica por Carga de Trabajo"

El cambio no es anti-nube. Es post-nube-primero. Las empresas están pasando de una suposición por defecto ("todo va a la nube") a una evaluación deliberada ("esta carga de trabajo específica pertenece a este entorno específico").

El patrón emergente se ve así:

Esta es "ubicación específica por carga de trabajo", y es la estrategia dominante entre las empresas con programas de AI maduros. El 86% de las empresas esperan que sus presupuestos de AI aumenten en 2026, con el 40% proyectando aumentos del 25% o más. Ese dinero se está dividiendo cada vez más entre infraestructura en la nube y on-premise en lugar de dirigirse exclusivamente a proveedores de nube.

Respuesta de la Industria: La Infraestructura Está Alcanzando

Hace un año, ejecutar AI on-premise requería ingeniería personalizada significativa. La brecha de herramientas entre las plataformas de AI en la nube y las alternativas on-premise era amplia. Esa brecha se está cerrando rápido.

Microsoft Foundry Local proporciona un runtime local para ejecutar modelos de AI en hardware empresarial sin conectividad a la nube. Es el reconocimiento de Microsoft de que "todo en Azure" no es lo que sus clientes empresariales quieren para cada carga de trabajo.

Red Hat y Telenor construyeron una fábrica de AI soberana — una arquitectura de referencia para ejecutar AI completamente dentro de una frontera nacional, usando la plataforma OpenShift de Red Hat. Está diseñada para clientes de telecomunicaciones y gobierno donde la soberanía de datos no es opcional.

Las arquitecturas de AI Factory de NVIDIA proporcionan diseños de referencia para clústeres GPU on-premise optimizados para inferencia, entrenamiento y preparación de datos. Han pasado de vender GPUs a vender patrones de despliegue completos.

Estos no son proyectos experimentales. Son ofertas de infraestructura de grado de producción de empresas que apostaron por la nube durante una década y ahora están construyendo productos on-premise porque ahí es donde va la demanda del cliente.

Lo Que Esto Significa para la Preparación de Datos

Aquí está la parte que muchas organizaciones pasan por alto al planificar migraciones de la nube a on-premise: necesitas preparación de datos on-premise antes de poder ejecutar modelos on-premise.

Un modelo ejecutándose en hardware local solo es útil si tiene datos con los que trabajar. Para inferencia, eso significa que los datos de entrada necesitan limpiarse, estructurarse y formatearse antes de llegar al modelo. Para fine-tuning, eso significa que tus datos de entrenamiento — frecuentemente extraídos de documentos empresariales sensibles — necesitan pasar por pipelines de extracción, limpieza, anotación y formateo.

La preparación de datos es donde ocurren los contactos con datos más sensibles. Es donde estás procesando registros crudos de clientes, archivos médicos, documentos legales y transacciones financieras. Si tu modelo corre on-premise pero tu pipeline de preparación de datos corre en la nube, has enviado todos tus datos sensibles a un proveedor de nube de todas formas. El modelo on-premise no te da nada desde la perspectiva de soberanía.

Por eso las herramientas de preparación de datos que corren completamente on-premise — sin dependencia de la nube, sin datos saliendo de la red — son un prerrequisito para una repatriación significativa de la nube. No puedes simplemente mover el modelo. Tienes que mover todo el pipeline.

Lo Que Esto Significa para Fine-Tuning y Entrenamiento

Entrenar modelos foundation grandes desde cero todavía requiere cómputo a escala de nube para la mayoría de las organizaciones. Pocas empresas tienen los miles de GPUs y el equipo de ingeniería necesario para entrenar un modelo desde cero.

Pero el fine-tuning es una historia diferente. Ajustar un modelo open-weight existente con datos propietarios puede hacerse en un solo servidor con 1-4 GPUs. Los requisitos de cómputo son órdenes de magnitud menores que el pre-entrenamiento, y los datos involucrados son casi siempre propietarios y sensibles — exactamente el tipo de datos que los requisitos de soberanía dicen que deben quedarse on-premise.

El patrón práctico para la mayoría de las empresas en 2026:

1. Seleccionar un modelo base del ecosistema open-weight (Llama, Mistral, Qwen, etc.)
2. Preparar datos de entrenamiento on-premise usando herramientas locales de preparación de datos
3. Ajustar on-premise usando infraestructura GPU local
4. Desplegar on-premise para inferencia
5. Usar la nube solo para experimentación inicial y cargas de trabajo no sensibles

Este patrón mantiene los datos sensibles completamente dentro del entorno controlado de la organización mientras aprovecha el ecosistema de modelos open-source.

La Frontera Air-Gapped

La versión más extrema de esta tendencia es la AI air-gapped — sistemas que operan con cero conectividad a internet. Este era antes un requisito de nicho limitado a agencias de defensa e inteligencia. Se está expandiendo.

Sistemas de salud procesando datos de pacientes bajo HIPAA. Instituciones financieras manejando algoritmos de trading. Operadores de infraestructura crítica. Agencias gubernamentales a todos los niveles. Estas organizaciones están construyendo capacidades de AI que corren en redes físicamente aisladas, y necesitan cada componente del pipeline de AI — preparación de datos, entrenamiento, fine-tuning, inferencia, evaluación — que funcione sin ninguna llamada de red externa.

La AI air-gapped es el punto final lógico de la tendencia de repatriación. No todas las organizaciones llegarán allí, pero las herramientas y arquitecturas que se construyen para despliegues air-gapped benefician a todos en el espectro. Si tu pipeline funciona en un entorno air-gapped, definitivamente funciona en un entorno on-premise estándar.

Lo Que Viene

El número del 93% seguirá subiendo. La presión regulatoria está aumentando, no disminuyendo. Los presupuestos de AI están creciendo, y las organizaciones que han estado ejecutando AI en la nube por 2-3 años ahora tienen suficientes datos para calcular su TCO real — y a muchas no les gusta lo que ven.

Las organizaciones que se muevan más rápido serán las que:

• Auditen su gasto actual de AI en la nube honestamente, incluyendo todos los costos ocultos
• Clasifiquen cargas de trabajo por sensibilidad, requisitos de latencia y características de costo
• Construyan capacidades de preparación de datos on-premise primero, porque la preparación de datos es donde los requisitos de soberanía muerden más fuerte
• Comiencen con la migración de inferencia, que tiene la mejor relación costo-complejidad
• Mantengan la nube para lo que la nube hace bien: cómputo por ráfaga, experimentación y cargas de trabajo elásticas

La pregunta no es si tu organización moverá algunas cargas de trabajo de AI fuera de la nube. Es cuáles cargas de trabajo, en qué orden, y qué tan bien preparado estarás cuando lo hagas.

Las empresas que traten esto como una estrategia de infraestructura deliberada — en lugar de una reacción a una auditoría de cumplimiento o una sorpresa presupuestaria — serán las que obtengan los beneficios sin la disrupción.