Cloud IA vs IA local en proyectos SAP: cuándo cada una (y cuánto cuesta de verdad)

Si trabajas en un proyecto SAP en 2026, la pregunta sobre inteligencia artificial ya no es si la vas a usar. Esa decisión está tomada. Analizar IDocs, resumir facturas, montar un sistema de RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) sobre tu documentación interna: todo eso ya forma parte del backlog. La pregunta que de verdad importa es otra, mucho más incómoda y mucho menos discutida en las reuniones de arranque: ¿dónde corre esa IA?

Y resulta que esa decisión tiene dos caras que casi nadie se molesta en poner sobre la mesa al mismo tiempo. Una es legal. La otra es económica. Por separado parecen problemas de departamentos distintos: una del responsable de compliance, otra del CFO. Juntas cuentan una historia que cambia el diseño técnico de raíz.

Porque en muchos escenarios SAP, la nube sale cara por las dos. Cara en euros, mes a mes. Y cara en riesgo, día a día. Este artículo es el marco de decisión que deberías tener encima de la mesa antes de elegir dónde ejecutas tus modelos: cuándo la nube es la opción correcta, cuándo el modelo local es obligatorio, y cuánto cuesta de verdad cada camino.

El coste real, sin maquillaje

Empecemos por el dinero, porque es el argumento que suele despertar a quien todavía cree que “esto de la IA es barato”.

Según Spendhound, el gasto medio anual de los clientes reales de OpenAI ronda los 561.564 USD/año, y el de Anthropic se sitúa en torno a 85.044 USD/año. Ojo: no son tarifas de lista ni precio por asiento —ni OpenAI ni Anthropic publican el precio de sus planes Enterprise—, sino el gasto medio observado en empresas que ya los usan. Y en un entorno SAP real, el consumo intensivo no es la excepción: es el día a día.

Piensa en lo que procesa de verdad una empresa que mete IA en su backbone SAP. Análisis automático de IDocs entrantes. Resumen de facturas de proveedor. RAG sobre miles de páginas de documentación interna, notas de cliente y manuales de proceso. Sumado todo, ese tipo de carga consume con facilidad entre 1 y 2 mil millones (1-2B) de tokens al mes.

Un token es la unidad mínima que un modelo de lenguaje procesa: aproximadamente un fragmento de palabra. Mil millones de tokens equivalen, muy por encima, a la documentación de varios proyectos SAP completos pasando por el modelo cada mes.

A precios de API en la nube, ese volumen se traduce en 30.000-60.000 €/mes, asumiendo modelos premium y prompts/respuestas extensos; con modelos económicos la factura baja uno o dos órdenes de magnitud. No es una errata. En el escenario caro son entre trescientos sesenta mil y setecientos veinte mil euros al año en facturas de API, solo por procesar texto que, en buena parte, ni siquiera debería salir de tu red.

Frente a eso, pon un Mac Studio con M3 Ultra sobre la mesa. La configuración de 192 GB rondaba los 7.000 €, una sola vez, y con esa máquina ejecutas modelos abiertos de gran tamaño en local, sin pagar por token. Un matiz importante: esa configuración de 192 GB se descontinuó en marzo de 2026 por la escasez global de memoria, así que hoy el Mac Studio con M3 Ultra se configura hasta 96 GB (desde unos 3.999 USD). El M3 Ultra sigue siendo el chip tope de la gama —no hay un M4 Ultra—, de modo que el argumento no cambia: el hardware propio se amortiza frente al uso intensivo de API. ¿La cuenta? Frente a un uso intensivo como el descrito, una inversión de ese orden se amortiza en semanas. A partir de ahí, cada token que procesas es coste hundido: ya lo pagaste.

Y un último número para calibrar la escala. El coste de montar una PoC (Proof of Concept, prueba de concepto) seria, o de hacer un taller práctico con tu equipo, equivale a alrededor del 0,2% de un solo mes de ese gasto medio en OpenAI. Dicho de otro modo: explorar bien la alternativa cuesta una fracción ridícula de lo que cuesta no explorarla.

Las dos columnas: comparativa Cloud vs Local

El dinero es solo una de las dos caras. La otra es todo lo demás. Esta tabla pone las dos opciones frente a frente en los ejes que de verdad mueven la decisión en un proyecto SAP:

Léela despacio. La nube gana en dos casillas claras: la calidad absoluta del modelo de frontera y la comodidad operativa (mantenimiento cero, escalabilidad instantánea). El local gana en todo lo que tiene que ver con control, coste sostenido y cumplimiento. No hay un ganador universal. Hay un ganador por caso de uso. Y de eso va el resto del artículo.

Cuándo la nube es válida

Que la nube tenga riesgos no significa que esté prohibida. Hay escenarios en los que es la opción correcta, y conviene reconocerlos sin prejuicios. La nube es válida cuando:

Cuándo el local es obligatorio

Hay otro grupo de escenarios donde la palabra no es “recomendable”, sino obligatorio. Aquí ejecutar en local deja de ser una preferencia técnica y pasa a ser un requisito legal o de negocio:

• Datos personales (GDPR). En cuanto el modelo procesa información que identifica a una persona, mandarla a un tercero fuera de tu control abre un frente de RGPD / GDPR (Reglamento General de Protección de Datos) que pocos comités de dirección quieren firmar.
• Casos de alto riesgo del EU AI Act. RRHH, credit scoring (evaluación de solvencia), atención al cliente automatizada: el EU AI Act los clasifica como alto riesgo, con obligaciones reforzadas.
• Secreto comercial. Tu lógica de pricing, tus márgenes, tus condiciones con proveedores. Nada de eso debería viajar a la API de un tercero.
• Sectores regulados. Marcos como DORA, NIS2 o el ENS (Esquema Nacional de Seguridad) imponen control sobre dónde y cómo se procesan los datos.
• Entornos air-gapped (aislados de internet). Si el sistema no tiene salida a la red por diseño, la nube sencillamente no es una opción técnica.
• Volumen alto y sostenido. Aquí el argumento es económico, no legal: cuando procesas miles de millones de tokens cada mes, el coste por token mata. El hardware propio se amortiza y a partir de ahí ganas en cada ejecución.

Si tu caso encaja en cualquiera de estas casillas, la conversación sobre “qué cómodo es llamar a una API” ha terminado.

El patrón híbrido: lo que hacen los que saben

Entre el “todo a la nube” y el “todo en local” hay un tercer camino, y es el que adoptan los equipos que ya han pasado por esto. Se llama patrón híbrido, y consiste en no tratar todos los datos por igual.

La idea es sencilla de explicar y potente en la práctica:

• Anonimizar antes de salir. Antes de mandar nada a la nube, se aplica un proceso de redact (redactar/ocultar) sobre los datos sensibles: nombres, identificadores fiscales, importes, cualquier dato que comprometa. A la API solo viaja lo que ya no identifica a nadie.
• Local para lo confidencial, nube para lo público. Lo que quema se procesa en casa con un modelo local. Lo inofensivo aprovecha la potencia y comodidad de la nube.
• Un enrutado que decide por tipo de dato. En lugar de que un humano elija caso a caso, un flujo de orquestación clasifica cada entrada y la dirige al destino correcto de forma automática.

El híbrido es donde se juntan las dos columnas a tu favor: aprovechas el razonamiento de frontera donde puedes permitírtelo y blindas el dato sensible donde toca. No es un compromiso a medias; es la arquitectura adulta.

Comparativa de modelos por tarea

Decidir “nube o local” es el primer corte. El segundo es elegir qué modelo concreto para qué tarea, porque pagar por un modelo caro para una tarea predecible es tirar dinero, igual que usar un modelo barato para una conversación crítica es jugártela. Esta tabla compara cuatro opciones representativas (precios por 1 millón de tokens):

Tres lecturas rápidas de esta tabla. DeepSeek V4-Flash y la familia Gemini Flash son las opciones de bajo coste: ideales para volumen alto donde la tarea es lineal y predecible (resúmenes, clasificaciones, extracciones), con la variante Flash-Lite como la más barata cuando solo necesitas procesar mucho texto. Claude Haiku 4.5 cuesta más, pero su tool calling (llamada a herramientas) fiable lo hace la opción para un chat conversacional donde el modelo tiene que invocar funciones de tu SAP sin equivocarse. Y Qwen 3 en local no tiene coste por token —solo el del hardware— y mantiene el dato dentro de tu red: la elección obligada para lo confidencial.

Precios orientativos por 1M de tokens a junio de 2026; verifícalos en origen, cambian a menudo, y los nombres de modelo evolucionan rápido (DeepSeek V4, Gemini 3.5, familia Claude 4.x, GPT-5.5…).

De ahí sale una regla práctica que cabe en una frase:

Modelo barato para lo predecible, modelo fiable para lo conversacional, modelo local para lo confidencial.

Checklist de decisión

Cuando tengas un caso de uso concreto sobre la mesa, no hace falta un comité de tres horas. Hazte estas cuatro preguntas en orden:

Conclusión

La diferencia entre los dos enfoques no es de gustos tecnológicos. Es de resultados. El equipo que sabe cuándo usar cada una gana en las dos columnas: paga menos cada mes porque no quema dinero enviando a la nube lo que podría procesar en casa, y duerme tranquilo porque el dato sensible nunca sale de su red. El que mete todo a la nube por comodidad paga de más cada mes y se la juega legalmente cada día.

La buena noticia es que esta decisión es aprendible, no adivinable. Cuatro preguntas, dos tablas y un patrón híbrido bien montado bastan para acertar. En IA para SAP, la arquitectura inteligente no es la que usa el modelo más caro, sino la que pone cada dato donde le corresponde.

Fuentes

• Spendhound — OpenAI enterprise pricing.
• Anthropic — precios públicos oficiales.
• EU AI Act — Reglamento (UE) 2024/1689.
• DeepSeek — página de precios oficial.
• Google — página de precios oficial de Gemini.
• Anthropic — página de precios oficial de Claude.