Por Qué Les Estoy Diciendo a Clientes Empresariales que Reconsideren On Premise para IA

Hace cinco años, si me hubieras dicho que iba a estar entrando a directorios empresariales en 2026 y haciendo el caso por IA on premise, me habría reído. La conversación de cloud estaba cerrada. 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.

He cambiado de opinión sobre eso, al menos para la capa de IA, y quiero explicar por qué sin sobrevenderlo. On premise no es la respuesta correcta para cada carga de trabajo y no es la respuesta correcta para la mayoría de las empresas. La postura correcta para la mayoría de las compañías sigue siendo híbrida, con las cargas de trabajo de agentes más pesadas viviendo donde tenga más sentido operativo. Lo que estoy argumentando es que la pregunta ha vuelto a la mesa por un conjunto específico de razones, y las empresas que reflexivamente la descartan están tomando una decisión que está uno o dos años atrasada.

Aquí están las cinco razones por las que estoy diciéndoles a clientes que hagan el análisis.

Razón uno. Economía de ejecución a escala real. 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 empieza a cerrar. No para todos. No para la mayoría de las cargas de trabajo. Pero para el puñado de cargas que son de volumen alto, sensibles a latencia, y ancladas por gravedad de datos, el punto de equilibrio se movió.

Razón dos. Gobernanza a nivel de acción. Esta es sobre la que me siento más fuerte. 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 controles totalmente. 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, la superficie de control tiene que estar en algún lugar que puedas inspeccionar al nivel más bajo. Para muchas empresas, eso las empuja 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. Para algunas, las empuja más lejos.

Razón tres. Latencia compuesta. 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, como un agente de cara al cliente o un flujo de trabajo de piso de producción, 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. Treinta segundos es una mala experiencia de usuario, y también es una ventana en la cual otras cosas pueden salir mal. Mover el runtime del agente más cerca de los sistemas sobre los que está actuando elimina esa latencia compuesta. A veces eso significa cloud en la misma región. A veces significa algo más cercano.

Razón 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 hipo de red o límite de tasa 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 a los que estás expuesto. No los elimina. Saca una clase de problemas de la mesa, lo que importa cuando el resto del trabajo ya es lo suficientemente difícil.

Razón cinco. Responsabilidad. Esta es la más blanda de las cinco y la más importante. 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 que renegociás cada ciclo de contrato, 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 quiere poder decir "somos dueños de esto de punta a punta" de una manera que una postura de cloud compartida no permite. Esa es una posición razonable de sostener, y es una conversación que ahora estoy teniendo con clientes con los que nunca esperé tenerla.

Quiero ser honesto sobre lo que no estoy diciendo. No estoy diciendo que cloud está muerto. No lo está. No estoy diciendo que cada empresa debería reconstruir 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 se leerá diferente. Lo que estoy diciendo es que la postura reflexiva de cloud first que nos sirvió bien de 2018 a 2023 merece una mirada fresca específicamente para la capa de IA, y el análisis ya no es tan limpio como solía ser.

Cuando estaba corriendo el portafolio de IA en Restaurant Brands International, tuve que tomar esta decisión en serio. Algunas cargas de trabajo pertenecían a la nube y se quedaron ahí. Otras tenían suficientes de las cinco razones de arriba apiladas que la respuesta no era obvia, y la matriz de decisión que usamos para evaluarlo era más matizada que la matriz de decisión que habría usado en 2022. No voy a pretender que cada empresa con la que hablo termina on premise para algo. La mayoría no. Lo que sí voy a decir es que las que hacen el análisis están construyendo una mejor postura de IA que las que se niegan a reabrir la pregunta.

Si no has hecho la pregunta on premise en los últimos 12 meses, la haría. Podés terminar en el mismo lugar donde estabas antes, lo cual está bien. O podés encontrar que una o dos de tus cargas de trabajo de más alto valor y más sensibles a gobernanza pertenecen a algún lugar donde no esperabas que pertenecieran. De cualquier manera, vas a tener una respuesta que podés defender.