IA en la nube vs on-premise: cuál conviene a tu empresa

El proyecto no se frena por tecnología, se frena por una frase sin sustento

He visto proyectos de IA con caso de uso claro y presupuesto aprobado congelarse por una sola frase dicha en una reunión: “nuestros datos no pueden salir de la empresa”. Nadie pregunta qué datos exactamente, ni qué norma lo exige, ni qué significa “salir” cuando esa misma empresa ya tiene su correo, su CRM y su contabilidad en servidores de terceros desde hace años. La frase se acepta como principio, no como una restricción que hay que verificar.

La inconsistencia no es mala fe. La IA se siente distinta: suena a que el modelo “se come” el dato y ya no se recupera. El miedo no es al lugar físico del servidor, es a perder control sobre qué se hace con la información. El problema es que ese miedo se resuelve comprando hardware, cuando era un problema de gobernanza y de contrato.

Qué se está decidiendo de verdad cuando eliges nube u on-premise

Sin el ruido, esta decisión mueve cuatro variables concretas. Ninguna de las cuatro es “qué tan segura es la nube”, que es como suele plantearse en la sala de directorio. Las cuatro tienen dueño, número y consecuencia operativa, y conviene ponerlas por separado antes de discutir cotizaciones.

• Control del dato: dónde reside, quién accede y si se usa para entrenar modelos futuros. En la nube se gobierna por contrato y región; on-premise, por tus políticas internas, lo cual es ventaja solo si esas políticas existen y se auditan.
• Estructura de costo: la nube es costo variable, pagas por uso y escalas sin comprometer capital. On-premise es costo fijo hundido: compras capacidad por adelantado, la uses o no.
• Velocidad de arranque: en la nube pasas de decisión a primer caso funcionando en semanas. On-premise implica cotización, compra, plazos de entrega de hardware especializado, instalación y pruebas.
• Quién opera: la variable que nadie pone en la hoja de cálculo. Alguien tiene que parchear, monitorear y responder cuando el sistema muere un viernes a las once de la noche. En la nube eso está en el precio. On-premise, es tu planilla.

Cómo se ve cada opción en la operación diaria

En la nube tu equipo consume el modelo por una interfaz: cuando el proveedor lanza una versión mejor, la adoptas cambiando un identificador, y si un proceso fracasa, lo apagas y dejas de pagar. On-premise tu equipo además es dueño de todo lo que está debajo: elegir el modelo abierto, optimizarlo para el hardware y vigilar que no se caiga. El control es real, y el trabajo también.

Cuándo on-premise sí es la respuesta correcta y no es negociable

No todo pedido de infraestructura propia es exageración. Hay contextos donde es la única salida, y conviene reconocerlos rápido para no perder tiempo defendiendo la nube por costumbre. La señal común es siempre la misma: el requisito viene por escrito de un regulador, de un contrato con un cliente grande o de una restricción física real, no de una intuición de reunión. Fíjate en que casi ninguna de esas razones es técnica.

• Regulación de residencia o aislamiento explícito: la norma exige que cierta categoría de dato se procese bajo control directo de la entidad. Ocurre en defensa, sector público sensible y ciertos datos clínicos o financieros.
• Contratos de cliente que lo imponen: si tu cliente principal exige que su información no salga de un perímetro específico, la discusión terminó. El costo de on-premise es el costo de mantener esa cuenta.
• Datos que no se pueden anonimizar ni segmentar: el proceso exige información identificable en crudo y no hay forma de trabajar con datos disociados.
• Operación sin conectividad confiable: planta minera remota, embarcación, instalación aislada. Si el proceso debe funcionar cuando el enlace se cae, necesitas cómputo local: eso es continuidad, no seguridad.
• Volumen alto, sostenido y predecible: si ya mediste el gasto variable durante meses y el uso es constante, el hardware propio puede salir más barato. La condición es haber medido, no proyectado.

El costo que nadie pone en la cotización de on-premise

Aquí va la parte incómoda. Cuando una empresa cotiza infraestructura propia para IA, la propuesta que llega tiene servidores, GPUs y quizá licencias. Ese número se compara contra el gasto mensual de la nube y on-premise parece ganar. La comparación está mal hecha: el precio de la nube incluye cosas que la cotización de hardware no menciona.

• Personal especializado: alguien que entienda de infraestructura de IA, no un administrador genérico. Ese perfil es escaso, caro y rotativo. Si se va, el conocimiento se fue con él.
• Cobertura fuera de horario: si el proceso es crítico, necesitas respuesta de madrugada y en feriados. Eso es más de una persona, o un soporte externo contratado.
• Redundancia, energía y espacio: un solo servidor es un punto único de falla, y el equipamiento de IA consume y calienta más que un servidor tradicional. Muchas salas medianas no están dimensionadas para eso.
• Obsolescencia: lo que compras hoy será menos eficiente por unidad de costo en tres o cuatro años. Ese ciclo de renovación es parte del costo real, no un imprevisto.
• Costo de oportunidad: cada hora que tu gente técnica dedica a mantener servidores es una hora que no dedica a mejorar el proceso de negocio.

Lo que la mayoría pide cuando dice “on-premise”, y cómo dárselo

Cuando me siento con el área que exige servidores propios y pregunto qué necesitan garantizar, casi nunca la respuesta es “que el servidor esté en este edificio”. La respuesta real, traducida, es una lista de garantías, y todas tienen respuesta contractual dentro de la nube empresarial, sin comprar un solo equipo.

• “Que nuestros datos no entrenen el modelo de otro”: los contratos empresariales serios lo prohíben explícitamente, a diferencia de los planes de consumo. Se pide por escrito y legal lo verifica.
• “Que sepamos dónde está el dato”: se resuelve eligiendo región de procesamiento y almacenamiento, configuración explícita en todos los proveedores grandes.
• “Que podamos auditar quién accedió a qué”: registros de auditoría y controles de administrador, más completos que los que la empresa suele tener hoy internamente.
• “Que podamos borrar todo si nos vamos”: cláusulas de retención y eliminación, más una prueba real de portabilidad antes de firmar.
• Y si hace falta aislamiento adicional, existe el punto intermedio que muchos ignoran: nube privada o instancia dedicada, con red aislada y residencia en una región definida.

Hay un concepto que ordena esta conversación: la responsabilidad compartida. El proveedor asegura la infraestructura física, la red y el aislamiento entre clientes; tú sigues siendo responsable de quién tiene acceso y qué información se envía. Ese reparto no desaparece con on-premise: simplemente te quedas con las dos mitades.

Errores que veo repetirse en empresas reales

• Decidir la infraestructura antes de validar el caso de uso. Comprar servidores para un proyecto que aún no demostró valor es la forma más cara de descubrir que el proceso estaba mal diseñado.
• Confundir “modelo abierto” con “on-premise”. Un modelo abierto se puede ejecutar en la nube sin comprar nada: son dos decisiones independientes.
• Aceptar el requisito regulatorio de oídas. Si nadie del área legal citó el artículo exacto, ese requisito no está verificado y no debería justificar una compra de capital.
• Amarrar el sistema a la forma específica de invocar a un proveedor. Sin una capa de abstracción, cambiar de nube a on-premise se convierte en una reescritura completa.
• Presuponer que on-premise significa que nadie externo toca la infraestructura: suele terminar habiendo un integrador con acceso privilegiado y menos auditoría que la de un proveedor de nube.
• Olvidar la continuidad: un servidor operado por una sola persona clave es un riesgo de negocio, no una garantía de control.

Cómo saber si tomaste la decisión correcta

Esta decisión no se evalúa por la tranquilidad del área de sistemas ni por lo bien que se ve el rack en la sala de servidores. Se evalúa con señales medibles durante los primeros seis a doce meses de operación real, que son estas:

• Tiempo entre la aprobación del proyecto y el primer proceso funcionando en producción con usuarios reales.
• Costo total por consulta procesada, incluyendo infraestructura, licencias y horas de personal, no solo la factura del proveedor.
• Porcentaje de utilización de la capacidad instalada, si compraste hardware. Un servidor al 15% de uso es capital inmovilizado.
• Horas del equipo técnico dedicadas a mantener infraestructura contra horas dedicadas a mejorar el proceso de negocio.
• Tiempo de recuperación ante fallas, medido en incidentes reales y no en el plan teórico de contingencia.
• Si legal y el cliente final quedaron satisfechos con las garantías, verificado por escrito.

Si a los seis meses tu equipo pasa más tiempo cuidando servidores que mejorando el proceso, la infraestructura ganó y el negocio perdió. Y si estás en la nube pero legal sigue incómodo porque nunca se revisó el contrato, tampoco resolviste el problema: solo lo pospusiste. La corrección es la misma, volver a la pregunta de origen: qué dato hay que proteger, contra qué riesgo, y quién puede sostener esa protección.