¿IA pública o modelo propio? La combinación adecuada

La pregunta suele plantearse mal. «¿IA pública o modelo propio?» suena a una decisión de principios: nube o soberanía, comodidad o control. En la práctica no es una cuestión de o lo uno o lo otro, sino una cuestión de asignación: qué tarea corresponde a qué modelo, y quién decide eso conforme a qué regla. La IA soberana en el sentido de sector7 no es, por tanto, un purismo de la nube. Es la disciplina de colocar cada modelo en el lugar al que pertenece.

El reflejo de operarlo todo en local por razones de protección de datos es tan caro como el reflejo contrario de entregarlo todo a la nube pública por comodidad. Ambos confunden una decisión de arquitectura con una cosmovisión. Quien quiere trabajar de forma soberana toma la decisión por tarea, y la hace verificable.

Planificar en la nube pública, ejecutar en local

Una regla práctica útil separa según lo que ocurre con los datos. Los modelos de nube pública son superiores allí donde se trata de investigación, borradores, generación de ideas y conocimiento general amplio, tareas en las que ningún contenido digno de protección va a parar al prompt. Llámelo «planificar en internet»: hace que le expliquen un tipo de contrato, esbocen una estructura argumental o contrasten opciones. La entrada no es crítica, y el rendimiento de los grandes modelos propietarios es aquí real.

La ejecución sobre contenidos sensibles pertenece a otro lugar. En cuanto un modelo accede a sus contratos, datos de personal, documentación de diseño o expedientes de clientes, cambia el cálculo. Esos contenidos no deben salir de su casa; aquí trabaja un modelo abierto autoalojado, sobre infraestructura propia u operada de forma soberana en Alemania. «Ejecutar en local» significa: el trabajo propiamente dicho sobre el conjunto de datos digno de protección tiene lugar allí donde usted conserva el control sobre el lugar de almacenamiento, el acceso y el derecho aplicable.

Por qué esto hoy resulta viable en la práctica

Hace dos años, esta división era un compromiso a costa de la calidad. Hoy ya rara vez lo es. La distancia entre los modelos abiertos y los propietarios se ha reducido notablemente en muchas tareas relevantes para producción —codificación, preguntas de conocimiento, resúmenes—. Modelos abiertos como DeepSeek V4, Qwen 3.5, Llama 4 o Mistral Medium 3.5 alcanzan en los benchmarks habituales valores que hasta hace poco estaban reservados a la cúspide propietaria: DeepSeek V4 Pro, por ejemplo, obtiene 80,6 en SWE-Bench Verified y 90,1 en GPQA Diamond con una ventana de contexto de un millón de tokens.

Con sobriedad, conviene señalar dónde persiste la distancia: en el razonamiento exigente de varios pasos, en las largas cadenas de trabajo agénticas y en la fiabilidad en casos límite, los modelos propietarios de cabeza siguen liderando; la ventaja se reduce, pero no ha desaparecido. Precisamente por eso, la combinación no es un remedio de emergencia, sino la respuesta objetivamente correcta: se usa la cúspide pública allí donde cuenta, y el modelo local allí donde la situación de datos lo exige y la calidad abierta es suficiente.

La residencia no es soberanía

Un error muy extendido merece aquí una aclaración clara, porque provoca decisiones equivocadas y costosas. Operar un modelo en una región de AWS o Azure en Frankfurt le proporciona residencia de datos: los datos se ubican geográficamente en Alemania. Eso no es soberanía. La residencia responde a la pregunta «¿Dónde están los datos?»; la soberanía, a la pregunta «¿Qué derecho tiene acceso a ellos, y quién puede forzar su entrega?».

La diferencia es jurídicamente concreta. La US CLOUD Act obliga a las empresas estadounidenses a entregar datos por orden de las autoridades estadounidenses, con independencia de que los servidores estén en Frankfurt o en Virginia. Un proveedor estadounidense con centro de datos alemán está sujeto a ambos ordenamientos jurídicos. La Data Act, aplicable en toda la UE desde el 12 de septiembre de 2025, exige a la inversa a los proveedores de nube adoptar medidas técnicas contra el acceso ilícito de terceros países a los datos almacenados en la UE. Ambos marcos normativos imponen al mismo proveedor obligaciones contrapuestas. Quien necesita soberanía real no puede prescindir de un operador que esté sujeto exclusivamente al derecho de la UE, no basta con una ubicación de centro de datos. Para la ejecución sensible, esa es la razón para operar el modelo local sobre infraestructura de responsabilidad europea.

El gateway convierte la elección de modelo en una decisión

Entre «planificar en público» y «ejecutar en local» se encuentra la tarea realmente difícil: la gobernanza. Sin un punto de control común, en la práctica decide el azar qué modelo recibe una consulta: la desarrolladora que tiene a mano la clave de API más cómoda, o la herramienta con el ajuste preconfigurado por defecto. Así, los contenidos sensibles van a parar al modelo equivocado, no por mala intención, sino por falta de regla.

Un gateway de IA regulado resuelve esto agrupando todo el tráfico de modelos por un único acceso y dirigiéndolo conforme a reglas fijas. Los criterios son enunciables:

Sensibilidad: los contenidos clasificados como confidenciales van al modelo local; las tareas no críticas, al modelo público más capaz que resulte adecuado.
Costes y presupuesto de tokens: las tareas breves de clasificación y rutina se ejecutan en modelos más pequeños y económicos; el razonamiento complejo se dirige de forma selectiva a un modelo potente. Los procedimientos de enrutamiento (router) disponibles públicamente demuestran que así se puede ahorrar una parte considerable de los costes sin reducir de forma apreciable la calidad de los resultados.
Trazabilidad: cada consulta se registra, las consultas recurrentes se almacenan en caché, los presupuestos se aplican. La regla se define una sola vez y rige para cada aplicación conectada.

El efecto decisivo es de gobernanza, no de técnica. El enrutamiento no es un tornillo de configuración, sino una superficie regulada: la elección de modelo se convierte en una decisión documentada en lugar de un subproducto. Y como todas las aplicaciones hablan por el mismo acceso, el cambio de proveedor o de modelo se convierte en un cambio de configuración, no en la reconstrucción de cada integración individual. Precisamente eso es la protección más eficaz frente al vendor lock-in: no la renuncia a un determinado proveedor, sino la libertad de sustituirlo en cualquier momento.

Qué hay de valor real en esto, y qué es marketing

Dos puntos deben separarse con cuidado. La IA soberana se vende en ocasiones como una renuncia a la capacidad de rendimiento: «local, pero más modesto». Eso fue cierto una vez y hoy ya apenas lo es: la gama media abierta basta para una gran parte de la ejecución sobre datos propios. A la inversa, «sovereign cloud» se coloca a menudo como etiqueta sobre ofertas que proporcionan residencia, pero no soberanía. Ambas simplificaciones inducen a error.

El núcleo sólido es poco espectacular: ordene sus tareas según la sensibilidad, elija por cada clase el modelo adecuado, y coloque delante un punto de control que aplique y registre esa asignación. Esto es menos una cuestión de IA que una cuestión de arquitectura limpia y gobernanza vivida, la misma disciplina con la que también se segmentan redes y se controlan accesos.

Cómo apoya sector7

Construimos exactamente esta división como un montaje operado, no como un juego de diapositivas. Nuestra oferta IA soberana comienza con la gobernanza —valoración de casos de uso y de riesgos conforme a la EU AI Act, higiene de datos, conexión con las estructuras ISO 27001 y NIS-2 existentes— y conduce a la operación asegurada: modelos de lenguaje privados protegidos y RAG gestionado sobre sus documentos, operados sobre modelos abiertos autoalojados en nuestro propio parque de servidores en Alemania. La gobernanza intermedia la implementamos como un gateway con enrutamiento basado en reglas: contenidos sensibles en local, no críticos al modelo público adecuado, con transparencia de costes, tokens y registro.

De forma deliberada, no forma parte de ello el entrenamiento de modelos base propios; apostamos por modelos abiertos y públicos probados y los ponemos en marcha de forma segura. Para capacidades de cálculo muy grandes incorporamos socios soberanos. La operación continua la asumimos, si así lo desea, desde nuestro centro de datos; los modelos de SLA vinculantes para ello los estamos construyendo actualmente y acordamos el alcance y los compromisos de forma concreta con usted en cada caso. Al principio no está un modelo, sino una conversación: ordenamos sus proyectos con mente abierta e implementamos lo que aporta utilidad.

Este artículo es una valoración técnica y no sustituye el asesoramiento jurídico en el caso concreto.