Volver a Insights
9 de abril de 2026Por Enrique Guitart

La Pregunta On Premise Está Volviendo para la IA, y Aquí Está Por Qué Podría Importar

Hace cinco años la conversación de cloud estaba resuelta. Nadie serio estaba moviendo cargas de trabajo de vuelta a on premise. Ese consenso sigue vigente para la mayoría del stack empresarial. Pero hay un conjunto de fuerzas acumulándose alrededor de la capa de IA que podrían reabrir la pregunta para un conjunto acotado de cargas de trabajo en los próximos dos a tres años. Esto no es una recomendación. Es un conjunto de observaciones que vale la pena seguir.

Hace cinco años, si me hubieras dicho que iba a estar escribiendo sobre infraestructura de IA on premise en 2026, me habría reído. La conversación de cloud estaba resuelta. Todos con los que trabajaba estaban moviendo cargas de trabajo hacia afuera, no hacia adentro. La economía, la velocidad, la confiabilidad, la postura regulatoria, todo eso favorecía a los hiperescaladores. Lo dije así en muchos decks.

No he cambiado mi recomendación. Para la gran mayoría de las cargas de trabajo de IA empresarial, cloud sigue siendo la respuesta correcta. Lo que he cambiado es mi certeza de que va a seguir siendo la única respuesta para siempre. Hay un conjunto de fuerzas acumulándose alrededor de la capa de IA específicamente que podrían reabrir la pregunta on premise para una franja acotada de cargas de trabajo en los próximos dos a tres años. Ninguna de ellas es decisiva hoy. Todas vale la pena rastrear.

Aquí están las cinco que estoy observando.

Una. Economía de ejecución a escala. Cuando la inferencia era el costo dominante en una carga de trabajo de IA, cloud tenía sentido porque los hiperescaladores estaban pasando amortización de GPU a una tasa que ninguna empresa podía vencer por su cuenta. Eso sigue siendo cierto para la mayoría de las compañías y va a seguir siendo cierto por un tiempo. Pero una vez que empezás a desplegar agentes que razonan a través de flujos de trabajo de múltiples pasos, el perfil de costo cambia. Una sola tarea de agente puede involucrar docenas de llamadas al modelo, múltiples invocaciones de herramientas, y recuperación a través de varios almacenes de conocimiento. El volumen de tokens por unidad de trabajo sube un orden de magnitud. A cierta escala de actividad de agentes, la economía unitaria de correr parte de esa carga de trabajo en infraestructura propia podría empezar a cerrar. No estamos ahí todavía para la mayoría de las organizaciones. Pero la matemática se está moviendo en una dirección que vale la pena observar.

Dos. Gobernanza a nivel de acción. Esta es la que me parece más interesante como driver futuro. Cuando un agente está tomando acciones en tu nombre, querés que la capa de auditoría y política viva en algún lugar que puedas inspeccionar completamente. Los proveedores de cloud son socios razonables en gobernanza de datos. Han invertido dinero real en hacer que esa historia funcione. La gobernanza de acción es más nueva y más difícil. Cuando necesitás probar, a un auditor o a un regulador o a tu propio directorio, exactamente qué vio un agente, sobre qué razonó, y qué hizo, y bajo qué política, en qué orden, con qué reversión, los requisitos de la superficie de control se vuelven muy específicos. Es posible que esto empuje a algunas empresas hacia ser dueñas al menos del plano de gobernanza del sistema operativo de IA incluso si el cómputo pesado sigue corriendo en la nube. No sabemos cómo se va a resolver esto, pero la dirección regulatoria es suficientemente clara como para que valga la pena pensarlo.

Tres. Latencia compuesta en cadenas de agentes. No estoy hablando de la latencia cruda de una sola llamada al modelo, que ha estado volviéndose más rápida para todos. Estoy hablando de lo que pasa cuando un agente tiene que tomar cien decisiones pequeñas en una cadena, cada una de las cuales involucra un viaje de ida y vuelta a un modelo hospedado, cada una de las cuales acumula un poco de costo de red y un poco de costo de cola. Esos números se componen. Para casos de uso interactivos, una cadena que toma seis segundos en un stack colocado puede tomar treinta segundos en un stack de nube que está geográficamente lejos de tus datos. Este es un problema de física más que de proveedor, y es posible que para algunos flujos de trabajo críticos en latencia la respuesta termine siendo mover el runtime del agente más cerca de los datos. Si eso significa cloud en la misma región o algo más cercano sigue siendo una pregunta abierta.

Cuatro. Confiabilidad entre sistemas. Los agentes que trabajan entre múltiples sistemas empresariales acumulan modos de fallo que son diferentes a las cargas de trabajo de un solo sistema. Cuando un agente está encadenando entre tu CRM, tu ERP, tu sistema de tickets, y un data warehouse, cualquier interrupción de red a lo largo de la cadena se vuelve un problema de confiabilidad. Correr el runtime del agente dentro del mismo límite de red que los sistemas que tiene que tocar reduce el número de modos de fallo. Esta es una ventaja teórica hoy y podría volverse práctica a medida que los despliegues de agentes escalen y empiecen a tocar más sistemas en una sola ejecución.

Cinco. Postura de responsabilidad. Esta es la más blanda de las cinco y posiblemente la más importante en el largo plazo. Cuando algo sale mal con un sistema de IA, alguien dentro de la empresa tiene que poder entrar a una sala, reconstruir lo que pasó, explicar por qué, y comprometerse a qué cambia. Si el runtime está corriendo en infraestructura que no controlás, bajo un modelo de responsabilidad compartida, esa conversación de responsabilidad se vuelve más difícil. No imposible, pero más difícil. Para algunas cargas de trabajo, el directorio puede eventualmente querer poder decir "somos dueños de esto de punta a punta" de una manera que una postura de cloud compartida no permite. Esa conversación no está ocurriendo ampliamente todavía, pero espero que empiece a aparecer en industrias reguladas en los próximos dos años.

Quiero ser claro sobre lo que no estoy diciendo. No estoy diciendo que cloud está muerto. No lo está. No estoy diciendo que alguna empresa debería ir y construir un data center. La mayoría no debería. No estoy diciendo que los hiperescaladores no puedan resolver ninguno de estos problemas. Todos están trabajando en todos ellos, y en 18 meses parte de esta lista puede leerse diferente. Lo que estoy diciendo es que la postura reflexiva de "todo en la nube" que nos sirvió bien de 2018 a 2023 merece una mirada fresca a los supuestos específicamente para la capa de IA, y vale la pena hacer ese análisis antes de que necesites la respuesta.

Cuando estaba corriendo el portafolio de IA en una organización Fortune 500, esta fue una de las preguntas con las que tuve que sentarme. Algunas cargas de trabajo claramente pertenecían a la nube y se quedaron ahí. Otras tenían suficientes de las señales de arriba apilándose que la respuesta no era obvia, y la matriz de decisión era más matizada de lo que habría sido en 2022. La mayoría de las empresas con las que hablo van a terminar quedándose completamente en la nube para sus cargas de trabajo de IA, y eso está bien. El punto no es que on premise sea la respuesta. El punto es que la pregunta vale la pena hacerla de nuevo, y las empresas que hayan hecho el análisis van a tener una mejor respuesta que las que se negaron a reabrirla.

Si no has revisitado la pregunta on premise para tu capa de IA en los últimos 12 meses, podría valer la pena hacerlo. Probablemente termines en el mismo lugar. O podrías encontrar que una o dos de tus cargas de trabajo de más alto valor y más sensibles a gobernanza merecen una mirada más cercana. De cualquier manera, vas a tener una respuesta que podés defender.