Durante los primeros años de la IA generativa, la conversación sobre seguridad dentro de las empresas era relativamente fácil de entender. Alguien abría ChatGPT en el navegador, copiaba un fragmento de texto, lo pegaba y hacía una pregunta. Los equipos de seguridad respondían con políticas sobre qué podía y qué no podía introducirse en un chatbot, mientras que algunas empresas iban más allá y bloqueaban estas herramientas por completo.
Esa conversación ya parece desfasada. No tiene que ver con la realidad.
La IA ya no es un destino al que los empleados envían información de vez en cuando. Se está convirtiendo en parte de la infraestructura a través de la que circula la información.
Un agente de programación puede leer un repositorio, inspeccionar dependencias, buscar documentación, modificar archivos y ejecutar comandos. Un asistente interno puede recuperar información de miles de documentos de la empresa antes de responder a una pregunta. Las herramientas de reuniones procesan automáticamente conversaciones con clientes. Los agentes están empezando a conectarse a bases de datos, CRMs, sistemas de soporte y APIs internas, y la cantidad de contexto que les proporcionamos no deja de crecer porque resultan considerablemente más útiles cuando entienden mejor la empresa para la que están trabajando.
El resultado es un cambio sutil, pero importante, en la pregunta de seguridad. Antes la cuestión era si debías pegar una determinada información en ChatGPT.
Cada vez más, la pregunta es adónde va la información de tu empresa cuando la IA la utiliza.
Todo sistema de IA útil necesita contexto. Un agente de programación sin acceso a tu base de código es considerablemente menos útil. Un agente de atención al cliente sin acceso a conversaciones anteriores y a la documentación del producto no puede responder a demasiado. Un asistente interno de investigación adquiere valor precisamente cuando puede buscar información que no está disponible en Internet.
Cuanto mejores se vuelven estos sistemas, más partes de nuestras empresas conectamos a ellos. Y a más información acceden.
Por eso algunas de las conversaciones más interesantes sobre IA que están teniendo lugar dentro de grandes empresas están empezando a alejarse de la calidad del modelo como único criterio. Durante los últimos años, la pregunta dominante ha sido cuál es el mejor modelo. Las empresas comparaban benchmarks, ventanas de contexto, precios y capacidades de razonamiento, y cambiaban de proveedor cada vez que un nuevo modelo ofrecía una mejora significativa.
Cuando los modelos se convierten en infraestructura, los criterios cambian.
Las empresas ahora tienen que entender no solo qué puede hacer un modelo, sino también dónde ocurre la inferencia, qué información se envía con cada petición, durante cuánto tiempo puede conservarse esa información, quién puede acceder a ella, qué se registra y qué ocurre si la empresa quiere trasladar esa carga de trabajo a otro sitio en el futuro.
Algunas decisiones recientes de empresas que están adoptando la IA de forma especialmente agresiva sugieren que esta conversación ya está cambiando. Según se ha publicado, Palantir ha pedido a Anthropic un compromiso irrevocable de zero-data-retention. NVIDIA ha restringido el uso de Claude para trabajos más sensibles, mientras que Booz Allen ha limitado su uso para determinadas tareas de ciberseguridad propietarias. [1]
Estas decisiones son interesantes precisamente porque ninguna de ellas supone un rechazo de la IA externa. Son decisiones sobre dónde se permite ejecutar determinadas cargas de trabajo y bajo qué condiciones.
Al mismo tiempo, los propios proveedores están respondiendo a esa misma presión. La IA empresarial ofrece cada vez más configuraciones distintas de retención, procesamiento de datos y despliegue, incluidas opciones de retención cero de datos para clientes que cumplen determinados requisitos. Pero no para todos. [2] [3]
La dirección en la que se mueve el mercado es, por tanto, más interesante que cualquier polémica concreta. Las empresas se están volviendo más exigentes con el perímetro que rodea la inferencia, mientras que los proveedores de modelos están creando nuevas formas de reducirlo.
Y eso exige cierta precisión. Si lees esto en los términos y condiciones de tu IA, tienes que entender que describen garantías diferentes:
«No utilizado para entrenamiento», «retención cero de datos» e «inferencia privada».
Un proveedor puede comprometerse a no utilizar los datos del cliente para entrenar mientras conserva temporalmente las peticiones por motivos de seguridad o detección de abuso. Una configuración de retención cero de datos puede eliminar o reducir de forma sustancial esa persistencia sin cambiar dónde ocurre físicamente la inferencia. La inferencia privada modifica, de nuevo, otra parte de la arquitectura.
Tratar todos estos conceptos como si fueran intercambiables es una de las razones por las que las conversaciones sobre seguridad de IA empresarial terminan siendo confusas.
ChatGPT para consumidores no es ChatGPT Enterprise; un despliegue empresarial mediante API no equivale a un chatbot para consumidores. El entrenamiento de modelos, la detección de abuso, el logging operativo, el acceso humano y la retención de datos son cuestiones relacionadas, pero distintas.
Reducir todo ello a una única conversación sobre «privacidad» sirve de poco para ayudar a una empresa a tomar mejores decisiones de infraestructura.
Pero esto no es nuevo. Las empresas ya confían información extremadamente sensible a infraestructuras externas. El código fuente vive en plataformas cloud. La información de clientes reside en CRMs. Los datos financieros pasan por procesadores de pagos. Empresas enteras funcionan sobre infraestructura propiedad de AWS, Microsoft o Google.
Las empresas modernas se construyen sobre dependencias cuidadosamente gestionadas, no sobre la ausencia de ellas.
Con la IA ocurre lo mismo.
Lo que sí cambia es la cantidad y la variedad de información que puede converger en un único flujo de trabajo de IA.
Un agente de programación puede ver código fuente, decisiones de arquitectura, información del entorno, logs de errores y documentación interna durante una misma sesión. Si le das acceso a más herramientas, el perímetro vuelve a ampliarse: puede consultar un gestor de incidencias, inspeccionar el esquema de una base de datos o interactuar con un sistema de despliegue.
Aunque lo más importante es que tiene acceso a mucha información que, mal utilizada, puede crear un perfil de tu empresa, recoger tu inteligencia más importante y utilizarla sin tu consentimiento.
Eso no hace que estos sistemas sean inseguros de por sí. Pero sí hace que su arquitectura sea importante.
Existe una diferencia considerable entre decidir que un proveedor externo es suficientemente fiable para una carga de trabajo concreta y construir tu infraestructura de IA de manera que todas las cargas de trabajo tengan que confiar en ese proveedor.
Es en esa distinción donde la conversación sobre soberanía de la IA empieza a resultar útil.
El problema no es OpenAI ni Anthropic. Es la frontera de confianza.
Sería fácil convertir esta conversación en un argumento contra OpenAI, Anthropic o cualquier otro proveedor comercial de IA cerrada.
También sería una conclusión equivocada.
La nube no hizo que las empresas se tomaran menos en serio la seguridad. Las obligó a ser más precisas sobre qué estaban delegando. La IA requiere la misma madurez.
Cuando la información pasa de un sistema gobernado por tus controles a otro gobernado, al menos parcialmente, por un tercero, cruza una frontera de confianza. Esto significa que algunas garantías pasan a depender de otra persona.
La pregunta importante nunca ha sido si existe confianza, porque la infraestructura moderna hace que sea inevitable. La cuestión es qué estás confiando exactamente a otra parte, bajo qué garantías técnicas y contractuales, y si esas garantías son adecuadas para esa carga de trabajo.
Con la IA, responder a eso puede ser sorprendentemente difícil.
Que los prompts se utilicen o no para entrenamiento es una pregunta. Cuánto tiempo se retienen los prompts y las respuestas es otra. Si existen logs operativos o de seguridad, es otra. [4] Si determinadas personas pueden acceder a la información bajo ciertas circunstancias, introduce otra capa, igual que la ubicación de la inferencia y los subprocesadores que participan en el servicio.
Un contrato empresarial puede cambiar muchas de estas condiciones. Las configuraciones de zero-data retention pueden modificarlas todavía más. Los despliegues dedicados y la infraestructura privada pueden reducir o desplazar de nuevo esa frontera.
Por eso preguntar si «OpenAI guarda mis datos» o si «Anthropic puede ver mi código» suele ser demasiado impreciso como para resultar útil en una decisión de infraestructura. La respuesta depende del producto, de la configuración, del contrato y de la carga de trabajo. [5]
Hay además otra pregunta que recibe mucha menos atención:
¿Qué ocurre si más adelante quieres cambiar alguna de esas decisiones?
Imagina una empresa que construye una plataforma interna de programación alrededor de un modelo comercial. La decisión es perfectamente razonable. El proveedor tiene el mejor modelo para esa tarea, la API es fácil de integrar y el equipo de seguridad está cómodo con las garantías ofrecidas.
Con el tiempo, la plataforma se vuelve más útil. Más desarrolladores la adoptan. El agente recibe acceso a más repositorios y documentación. Los equipos construyen flujos de trabajo alrededor de funcionalidades específicas del proveedor. Los prompts, las herramientas, la observabilidad y la lógica de aplicación se van acumulando poco a poco alrededor de la API original.
No ha ocurrido nada malo. De hecho, el proyecto ha sido un éxito.
Pero la decisión de confianza tomada al principio se ha convertido silenciosamente en una dependencia arquitectónica.
Quizá un año después un repositorio especialmente sensible tenga que permanecer dentro de la infraestructura de la empresa. Tal vez un contrato con un cliente introduzca nuevos requisitos de residencia de datos. El proveedor puede cambiar sus precios o sus condiciones. O puede aparecer simplemente otro modelo mejor.
La empresa todavía puede migrar, pero la pregunta relevante es cuánto de su stack de IA tiene que moverse.
¿Quién conserva la capacidad de tomar la siguiente decisión?
Una empresa puede decidir conscientemente que enviar una carga de trabajo a un modelo externo es aceptable. Puede ser una decisión perfectamente soberana si entiende la frontera y conserva alternativas reales.
El problema aparece cuando una decisión arquitectónica va eliminando poco a poco esas alternativas.
Qué significa realmente la soberanía de la IA
Soberanía es una palabra incómoda en tecnología porque puede significar prácticamente cualquier cosa. Se asocia con frecuencia a la geografía, la regulación o la idea de que la infraestructura debe permanecer dentro de las fronteras nacionales. En IA también está empezando a utilizarse como sinónimo de self-hosting.
Las dos lecturas capturan una parte del problema, pero ninguna resulta especialmente útil por sí sola.
Una empresa no se vuelve soberana simplemente porque sea propietaria de GPUs, del mismo modo que tampoco pierde su soberanía cada vez que llama a una API externa.
Lo importante es si la empresa entiende y controla el recorrido entre sus datos y la inteligencia que opera sobre ellos, y si conserva la capacidad de cambiar ese recorrido cuando sea necesario.
Ese control puede entenderse a través de cuatro partes del stack: datos, modelos, cómputo y operaciones.
Datos
Los datos son la capa más evidente, pero incluso aquí el perímetro es más amplio de lo que parece a primera vista.
Los sistemas de IA consumen mucho más que el prompt visible en una interfaz de chat. Documentos recuperados, código fuente, historial de conversaciones, resultados de herramientas, instrucciones de sistema e información obtenida de sistemas internos pueden pasar a formar parte de una petición.
Parte de esa información puede existir únicamente en memoria durante la inferencia. Otra parte puede escribirse en logs de la aplicación o del proveedor. El historial de conversaciones puede almacenarse en otro lugar, mientras que los embeddings residen en una base de datos vectorial y las trazas se envían a una plataforma de observabilidad.
Una arquitectura descrita de forma informal como «IA privada» puede, por tanto, seguir creando copias de información de la empresa en varios sistemas.
Una arquitectura soberana hace que esas decisiones sean explícitas.
El objetivo no es conseguir retención cero en todas partes. Existen razones legítimas para conservar información por motivos de auditoría, debugging, seguridad o funcionalidad del producto.
El objetivo es una retención intencional. Que tú decidas o puedas decidir qué datos, dónde, cómo y hasta cuándo se almacenan.
Modelos
La segunda capa es el propio modelo.
El mejor modelo para una carga de trabajo hoy puede no ser el mejor dentro de seis meses. Un modelo más pequeño puede llegar a ser suficientemente bueno como para ejecutarse de forma privada. Un modelo abierto puede ofrecer una calidad comparable con una economía distinta. Un nuevo modelo propietario puede generar suficiente valor adicional como para justificar su uso. La regulación o los requisitos de un cliente pueden convertir un despliegue existente en inadecuado para determinadas cargas de trabajo.
La soberanía sobre los modelos no exige utilizar exclusivamente modelos abiertos.
Exige tratar los modelos como componentes que pueden sustituirse en lugar de como dependencias permanentes.
Cómputo
El cómputo introduce otra decisión.
Existe un amplio espectro entre enviar cada petición a una API pública y comprar un rack lleno de GPUs. La inferencia puede ejecutarse mediante APIs alojadas, infraestructura dedicada, la propia cuenta cloud de una empresa, entornos cloud soberanos o hardware físicamente controlado por la compañía.
La capacidad importante no consiste necesariamente en poseer el cómputo. Lo más importante es poder decidir dónde se ejecuta una carga de trabajo.
Operaciones
Por último, las operaciones determinan de qué es capaz realmente el sistema de IA.
Un agente puede leer un repositorio pero no modificarlo, consultar información de clientes a través de una interfaz restringida o ejecutar código únicamente dentro de un sandbox aislado. Identidad, permisos, acceso a herramientas, aislamiento, observabilidad y auditabilidad pasan por tanto a formar parte también del perímetro de soberanía.
Esto cobra cada vez más importancia a medida que las empresas pasan de interfaces de chat a agentes.
Un sistema de IA que únicamente puede generar texto tiene una superficie de riesgo muy distinta a la de uno que puede leer sistemas de la empresa, ejecutar herramientas y realizar acciones. La pregunta ya no es únicamente qué información llega al modelo, sino qué autoridad vuelve junto con la respuesta.
Al juntar estas capas, la soberanía empieza a parecer menos una decisión de despliegue y más una propiedad de la arquitectura. Hay que diseñar primero las políticas de operaciones de la IA.
Existe además una distinción importante entre garantías contractuales y garantías arquitectónicas.
Un proveedor puede garantizar contractualmente que los datos del cliente no se conservarán, respaldando esa promesa con contratos, certificaciones y auditorías. Esas garantías importan.
Pero los sistemas también pueden diseñarse de forma que ciertas garantías sean consecuencia directa de cómo funciona la infraestructura. Si el contexto existe únicamente en memoria mientras dura la inferencia, habrá menos información del cliente disponible para ser conservada después. Si la capa de inferencia no crea logs con los prompts, no existe una base de datos histórica de prompts cuyo periodo de retención haya que gestionar.
Los sistemas más sólidos combinan ambos enfoques.
El diseño técnico reduce la cantidad de confianza que hay que depositar en el proveedor, mientras que los contratos, auditorías y certificaciones verifican los controles que no pueden observarse de forma independiente.
Ninguno elimina la necesidad del otro.
Esto ofrece a las empresas una forma más útil de evaluar la soberanía: ¿dónde existen los datos de una carga de trabajo?, ¿qué persiste después de la inferencia?, ¿qué modelo los procesa?, ¿dónde se ejecuta ese modelo?, ¿a qué puede acceder? y ¿puede cambiarse cualquiera de esas respuestas más adelante?
La respuesta no tiene por qué ser la misma para todas las cargas de trabajo.
De hecho, probablemente no debería serlo.
No todas las cargas de trabajo necesitan el mismo nivel de control
Las empresas no protegen hoy toda la información de la misma manera.
Una nota de prensa pública y un plan de adquisición pueden ser ambos documentos, pero no deberían estar sujetos a la misma política de seguridad. Un directorio de empleados, una base de datos de clientes y unas credenciales de producción presentan riesgos diferentes y están rodeados de controles distintos.
Las cargas de trabajo de IA deberían tratarse de una manera similar.
Pensemos en un empleado que pide a un modelo mejorar la redacción de una oferta de empleo pública. La información ya es pública, las consecuencias de una exposición son insignificantes y añadir infraestructura dedicada aportaría muy poco valor adicional.
Ahora pensemos en el mismo empleado analizando datos salariales de toda la empresa, o en un desarrollador que proporciona a un agente de programación acceso a un repositorio propietario.
La interfaz puede parecer prácticamente idéntica (entra un prompt y sale una respuesta), pero la decisión de infraestructura que hay debajo no debería serlo.
Antes de decidir cómo debe ejecutarse una carga de trabajo, una empresa puede evaluar un número relativamente pequeño de características: la sensibilidad y el valor empresarial de la información implicada, los sistemas a los que puede acceder el modelo, las acciones que puede realizar y las consecuencias si algo sale mal.
| Carga de trabajo | Sensibilidad típica | Nivel de control de ejemplo |
|---|---|---|
| Resumir investigación pública | Baja | API alojada |
| Escribir o traducir contenido público | Baja | API alojada |
| Asistente de conocimiento interno | Media | API empresarial |
| Atención al cliente con contexto de cuenta | Media a alta | Endpoint compatible con ZDR |
| Agente de programación sobre repositorios propietarios | Alta | ZDR / inferencia dedicada |
| Análisis contractual y financiero | Alta | Inferencia dedicada / controlada |
| I+D y propiedad intelectual todavía no publicada | Muy alta | Inferencia aislada |
| Material de M&A o del consejo de administración | Muy alta | Inferencia aislada |
Estas categorías no pretenden ser absolutas. Ni siquiera tienen por qué ser ejemplo, pero te ayudan a entender el nivel de riesgo.
La regulación, la geografía, las obligaciones contractuales y el valor de la información subyacente pueden desplazar una misma carga de trabajo considerablemente hacia arriba o hacia abajo en la tabla.
El cambio importante consiste en dejar de seleccionar infraestructura de IA a nivel de empresa y empezar a seleccionarla a nivel de carga de trabajo.
Una empresa no necesita necesariamente una estrategia de OpenAI, una estrategia de Anthropic o siquiera una estrategia de modelos abiertos.
Necesita entender qué quiere que haga la IA y definir el perímetro aceptable para cada carga de trabajo.
Para algunas, un modelo frontier alojado será la respuesta evidente. Otras pueden requerir garantías más estrictas sobre retención. A medida que aumenta la sensibilidad, la inferencia dedicada u operada de forma privada puede empezar a estar justificada.
El objetivo es encontrar el nivel mínimo suficiente de control para cada carga de trabajo.
Y eso importa tanto desde un punto de vista económico como de seguridad.
La soberanía máxima tiene un coste. Hay que aprovisionar GPUs, operar infraestructura, servir modelos y planificar capacidad. Hacer todo eso para resumir investigación pública sería difícil de justificar. Hacerlo para procesar la propiedad intelectual de la que depende el valor de la empresa puede ser considerablemente más fácil.
El mismo razonamiento funciona en sentido contrario.
La comodidad también crea dependencias. Construir todos los flujos de trabajo de IA alrededor de un único proveedor externo puede reducir la complejidad hoy al mismo tiempo que reduce la opcionalidad mañana.
Una buena estrategia de soberanía, por tanto, no intenta minimizar las dependencias externas a cualquier precio. Hace que esas dependencias sean proporcionales a la carga de trabajo.
Esto resulta especialmente importante para empresas cuya información más valiosa no está necesariamente regulada.
El código fuente propietario, la investigación todavía no publicada, los procesos de fabricación, la arquitectura de producto o el conocimiento acumulado en miles de documentos internos pueden no encajar claramente dentro de una categoría de compliance, pero pueden representar una parte considerable del valor de la empresa.
Un stack de IA maduro debería debería poder tener en cuenta todas estas opciones.
De seleccionar modelos a enrutar inferencia
La mayoría de aplicaciones de IA actuales empiezan eligiendo un modelo.
Un equipo decide construir con GPT, Claude, Gemini o un modelo abierto, integra la API correspondiente y desarrolla la aplicación alrededor de ella. Para un experimento o una pequeña herramienta interna, suele ser la forma más rápida y sensata de empezar.
El problema aparece cuando esa aplicación se convierte en infraestructura.
Cuando varios equipos, agentes y herramientas internas dependen de la misma integración, la elección inicial del modelo empieza a determinar mucho más que la calidad del modelo. Influye en dónde ocurre la inferencia, qué políticas de datos se aplican, cómo se comportan los costes, qué capacidades pueden utilizar los desarrolladores y lo difícil que será trasladar una carga de trabajo a otro lugar.
Una arquitectura diferente separa dos decisiones que habitualmente se toman a la vez:
¿Qué necesita hacer la aplicación y de dónde debería proceder la inteligencia necesaria para hacerlo?
Una herramienta interna de búsqueda no necesita saber necesariamente qué proveedor responde a cada consulta. Necesita un modelo capaz de entender su contexto, producir una respuesta suficientemente buena y cumplir las políticas asociadas a esa carga de trabajo.
Lo mismo ocurre con un agente de programación. Los repositorios, los permisos, las herramientas y las tareas pertenecen a la aplicación. Que el razonamiento que hay detrás de esas tareas ocurra en un modelo comercial frontier, en un endpoint dedicado o en un modelo abierto ejecutándose dentro de la infraestructura de la empresa puede ser una decisión independiente.
Aquí es donde empezamos a dibujar el stack de IA:
Las aplicaciones y los agentes se sitúan arriba. Debajo de ellos aparece una capa de control responsable de aplicar identidad, permisos y políticas de carga de trabajo, y de determinar qué destinos de inferencia son aceptables.
La capa de inferencia situada debajo ya no necesita estar formada por un único proveedor. Puede contener APIs comerciales, endpoints operando bajo garantías de retención cero de datos, despliegues dedicados y modelos abiertos ejecutándose sobre infraestructura privada o self-hosted.
El cambio arquitectónico importante es que la aplicación deja de estar permanentemente acoplada a uno de ellos.
La inferencia se convierte en un recurso que puede gobernarse, en lugar de ser un proveedor alrededor del cual se construyen las aplicaciones.
Una petición que contiene información pública podría estar autorizada a utilizar cualquier proveedor aprobado. Un agente de programación trabajando sobre un repositorio sensible podría estar limitado únicamente a endpoints que cumplan determinados requisitos de retención. Una carga de trabajo con propiedad intelectual especialmente valiosa podría quedar restringida a modelos ejecutándose dentro de infraestructura controlada.
Dentro de esos límites, el sistema puede seguir optimizando calidad, latencia y coste.
Esto crea una jerarquía importante:
Las políticas de seguridad y datos determinan dónde puede ejecutarse una carga de trabajo. El rendimiento y la economía ayudan después a decidir dónde debería ejecutarse.
Una empresa podría, por tanto, tener acceso a diez modelos sin que todas las aplicaciones estén autorizadas a utilizar los diez. El pool de inferencia disponible para un asistente de marketing podría ser muy amplio, mientras que un agente conectado a infraestructura de producción podría funcionar dentro de un conjunto mucho más reducido de despliegues autorizados.
Es una solución considerablemente más flexible que intentar encontrar un único modelo capaz de satisfacer todos los requisitos de la organización.
También refleja mejor cómo es probable que evolucione la IA.
Hay pocos motivos para pensar que un único proveedor de modelos seguirá siendo la mejor opción simultáneamente para programación, razonamiento, procesamiento de documentos, tareas multimodales, agentes e inferencia de gran volumen. Las capacidades de los modelos cambian demasiado rápido y la economía varía demasiado entre diferentes cargas de trabajo.
Un modelo innecesariamente caro para millones de clasificaciones sencillas puede seguir mereciendo la pena para una tarea de razonamiento difícil. Un modelo abierto más pequeño puede funcionar perfectamente bien para un flujo interno que no necesita inteligencia frontier.
La infraestructura debería ser capaz de expresar esas diferencias.
Con el tiempo, el routing puede incorporar más factores además de la sensibilidad: límites de coste, requisitos de latencia, restricciones geográficas, disponibilidad y rendimiento medido sobre tareas específicas de la empresa pueden influir también en dónde ocurre la inferencia.
Sin embargo, esta idea tiene una limitación importante.
Los modelos no son perfectamente intercambiables.
Distintos modelos soportan distintos tamaños de contexto, formatos de herramientas, modos de razonamiento, salidas estructuradas y capacidades multimodales. Responden de forma diferente al mismo prompt, y las aplicaciones construidas alrededor de funcionalidades específicas de un proveedor pueden alcanzar un rendimiento superior precisamente porque aprovechan esas diferencias.
Una arquitectura soberana no puede fingir que esas diferencias no existen: limitan lo fácil que es cambiar una pieza del puzle. Lo que sí está en tu mano es que el acoplamiento sea una decisión consciente y no un accidente, sin aplanar todos los modelos hasta un mínimo común denominador.
Un equipo debería poder utilizar una capacidad específica de un proveedor cuando su beneficio justifique la portabilidad que sacrifica a cambio, manteniendo al mismo tiempo una infraestructura capaz de soportar alternativas.
Esto también se aplica al comportamiento de fallback.
Una carga de trabajo sensible dirigida hacia un entorno de inferencia controlado no debería hacer fallback silenciosamente hacia un endpoint público sin restricciones simplemente porque el modelo preferido no esté disponible. El routing solo es soberano si todas las rutas permitidas respetan la política asociada a la carga de trabajo.
Bien implementada, esta arquitectura reconcilia dos objetivos que a menudo se presentan como opuestos: utilizar la mejor IA disponible y mantener el control sobre cómo se despliega esa IA.
Una empresa puede utilizar modelos comerciales frontier allí donde sus capacidades importan, modelos más baratos donde importa la escala y modelos desplegados de forma privada donde importa el control, sin exigir que ninguna de esas decisiones defina todo el stack de IA.
Es probable que la infraestructura de IA se vuelva heterogénea.
Los modelos abiertos cambian la ecuación de soberanía
Los modelos abiertos no resuelven por sí solos el problema de la soberanía.
Una empresa puede enviar información sensible a un modelo abierto ejecutándose sobre infraestructura de un tercero, conservar cada prompt indefinidamente y rodear el despliegue de controles de acceso deficientes. Que los pesos estén disponibles no hace más seguras ninguna de esas decisiones.
Lo que cambian los modelos de pesos abiertos es algo más fundamental:
Separan el modelo de la empresa que lo creó.
Con un modelo cerrado, el acceso al modelo y la dependencia de su proveedor están estrechamente conectados. Los contratos empresariales y los distintos acuerdos de despliegue pueden modificar sustancialmente las condiciones, pero el modelo sigue ligado a la infraestructura proporcionada por su desarrollador o por socios autorizados.
Los pesos abiertos rompen esa relación.
Crean una separación entre tres funciones que suelen tratarse como si fueran una sola: quién crea el modelo, quién opera la inferencia y quién controla el cómputo.
No tienen por qué ser la misma organización.
Un modelo puede desarrollarlo una organización, servirlo otra y ejecutarse sobre infraestructura controlada por una tercera. Sujeto a su licencia y a sus requisitos técnicos, los mismos pesos pueden servirse a través de un proveedor especializado de inferencia, GPUs dedicadas, el entorno cloud de una empresa o hardware operado internamente.
La inteligencia puede seguir siendo, en términos generales, la misma mientras cambia la frontera de confianza que la rodea.
Esta es la contribución estructural que los modelos abiertos hacen a la soberanía de la IA. Introducen un grado adicional de libertad en la arquitectura.
También por eso la conversación empresarial sobre modelos abiertos no debería reducirse a si superan al mejor modelo propietario en un leaderboard.
Para determinadas cargas de trabajo lo harán; para otras no. Los modelos cerrados frontier pueden seguir justificando su uso cuando su capacidad adicional genera suficiente valor para el negocio.
La pregunta más interesante es si todas las cargas de trabajo necesitan realmente capacidades frontier. La mayoría no.
Extracción, clasificación, procesamiento de documentos, retrieval, resumen, traducción y un conjunto cada vez mayor de tareas agénticas pueden realizarse a menudo con modelos que son más fáciles de operar bajo condiciones controladas.
A medida que mejoran los modelos abiertos, aumenta el conjunto de cargas de trabajo para las que las empresas cuentan con una alternativa creíble a la inferencia frontier externa.
Esto no elimina los modelos cerrados del stack de IA. Solo cambia cuándo resulta necesario depender de ellos.
Una misma capacidad puede además trasladarse entre distintos entornos de infraestructura a medida que cambian sus requisitos.
Imaginemos que una empresa ha evaluado un modelo abierto para análisis documental y sabe que rinde suficientemente bien para esa tarea. Durante el desarrollo, el equipo puede consumir ese modelo mediante una API de inferencia alojada porque tiene poco sentido operar GPUs mientras el producto sigue en fase de pruebas.
A medida que crece el uso, la economía puede justificar trasladar la misma carga de trabajo a capacidad dedicada. Un cliente especialmente sensible puede exigir inferencia en una región concreta. Otro despliegue puede tener que ejecutarse dentro del propio cloud del cliente, mientras que un entorno regulado podría exigir que el modelo y todo el pipeline de datos que lo rodea funcionen sin acceso externo a red.
Son cambios importantes de infraestructura, pero no tienen por qué exigir cambiar el modelo subyacente ni reconstruir la aplicación alrededor de una inteligencia completamente distinta.
El modelo se vuelve portable de una manera que los modelos cerrados normalmente no pueden ser.
Sin embargo, portabilidad no debe confundirse con reproducibilidad perfecta.
Ejecutar los mismos pesos a través de dos proveedores de inferencia distintos no garantiza un servicio idéntico. Los proveedores pueden diferir en cuantización, configuración de serving, límites de contexto, throughput, latencia, fiabilidad y funcionalidades compatibles.
Aunque el nombre del modelo sea idéntico, las características operativas que lo rodean pueden no serlo.
Los pesos abiertos, por tanto, no eliminan mágicamente las dependencias de infraestructura.
Las hacen más granulares.
El self-hosting también merece un tratamiento más realista del que suele recibir.
Ejecutar tú mismo la inferencia transfiere control, pero también transfiere responsabilidad. Hay que aprovisionar GPUs y utilizarlas de forma eficiente. La infraestructura de serving tiene que escalar. Los modelos tienen que actualizarse. La fiabilidad, la monitorización, la seguridad y la planificación de capacidad pasan a ser tu problema en lugar del problema del proveedor.
Para muchas empresas, asumir toda esa carga operativa tendría poco sentido.
Existe un punto intermedio importante entre utilizar una API pública de un modelo y construir una plataforma interna de GPUs. Los modelos abiertos pueden ejecutarse sobre infraestructura operada por proveedores especializados y seguir permitiendo diferentes garantías de aislamiento, retención y ubicación del despliegue. Pueden funcionar sobre capacidad dedicada sin obligar al cliente a contratar un equipo de ingenieros de inferencia, y pueden volver a trasladarse si cambian los requisitos.
Por eso no debería tratarse la propiedad de los pesos y la propiedad del hardware como si fueran la misma cosa.
La ventaja estratégica consiste en que una empresa pueda decidir cuánto del stack de inferencia quiere operar y cuánto quiere delegar.
Esa distinción cambia la naturaleza del riesgo de proveedor.
Con un modelo propietario, sustituir al proveedor suele significar sustituir también el modelo. Con un modelo abierto, cambiar quién lo sirve puede dejar intacta una mayor parte del stack. La empresa puede seguir dependiendo de cómputo, red o infraestructura externos, pero esas dependencias pueden separarse y evaluarse individualmente en lugar de estar empaquetadas dentro de un único proveedor de modelos.
Eso no elimina el vendor lock-in del todo. La infraestructura rara vez lo hace.
Pero hace que cambiar de proveedor sea más sencillo. Y sobre todo, que tú conserves la decisión.
Y esa es una propiedad importante de un sistema soberano. La soberanía no exige eliminar todas las dependencias externas; exige evitar que esas dependencias se conviertan en decisiones irreversibles.
Si las aplicaciones están separadas de la inferencia, los modelos abiertos ofrecen destinos al final de esa ruta que la empresa puede llegar a controlar por completo. Una carga de trabajo puede empezar en infraestructura compartida, trasladarse a capacidad dedicada a medida que crece y terminar ejecutándose completamente dentro del entorno de la empresa si su sensibilidad lo requiere.
Así, la empresa es la que determina la frontera de confianza.
Por eso los modelos abiertos importan incluso para organizaciones que siguen utilizando GPT, Claude o Gemini todos los días. Hace que los modelos cerrados sean opcionales, no la única opción.
La soberanía es opcionalidad
Existe cierta tendencia a hablar de soberanía tecnológica en términos de propiedad: quién posee la infraestructura, dónde están ubicados los servidores, quién desarrolló el modelo o si el software es abierto.
Esas preguntas importan, pero propiedad no es exactamente lo mismo que control.
Una empresa puede poseer su infraestructura y aun así depender enormemente de un proveedor, modelo o stack de software concreto. También puede depender ampliamente de infraestructura externa y, al mismo tiempo, mantener un control considerable sobre cómo se despliegan sus sistemas y dónde se permite que circulen sus datos.
Una medida más útil de soberanía es la libertad de decisión o la opcionalidad. Tener opciones.
¿Puede la empresa cambiar de opinión?
¿Puede trasladar una carga de trabajo de un proveedor a otro? ¿Puede decidir que una información que ayer era aceptable procesar externamente mañana debe permanecer dentro de un entorno controlado? ¿Puede adoptar un modelo mejor sin reconstruir la aplicación alrededor de él? ¿Puede acercar la inferencia a sus datos si cambian la regulación, la economía o los requisitos de sus clientes?
Si la respuesta es sí, la organización mantiene un control significativo sobre su infraestructura de IA incluso cuando una parte importante de esa infraestructura está operada por otras empresas.
Si la respuesta es no, puede que el proveedor actual sea perfectamente seguro y fiable y el problema esté en otro sitio: una decisión técnica se ha vuelto difícil de revertir. Solemos hablar de deuda técnica pensando en código, pero esto también lo es. Y de la peor clase.
Esta distinción es especialmente importante porque nadie sabe cómo será el mercado de modelos dentro de unos años.
La actual generación de infraestructura de IA se está construyendo mientras las capacidades, los precios y las arquitecturas de los modelos cambian a una velocidad extraordinaria. Modelos que requerían cantidades enormes de cómputo se están volviendo más pequeños y eficientes. Los modelos abiertos están reduciendo diferencias que parecían enormes apenas unos meses antes. Nuevo hardware cambia la economía de la inferencia, mientras que la regulación y los requisitos de los clientes cambian dónde pueden ejecutarse determinadas cargas de trabajo.
Construir dependencias permanentes durante este periodo supone una apuesta considerable sobre un futuro difícil de predecir.
Una arquitectura soberana intenta conservar la capacidad de responder a lo que va a pasar.
Eso puede significar seguir utilizando ampliamente modelos propietarios frontier porque ofrecen las mejores capacidades disponibles. Puede significar ejecutar cargas de gran volumen sobre modelos abiertos más baratos. Puede significar trasladar inferencia especialmente sensible a infraestructura dedicada, o mantener completamente aisladas algunas cargas de trabajo críticas.
Todas esas decisiones pueden coexistir porque la soberanía vive un nivel por encima de ellas. Es la capacidad de seguir tomándola.
Esto también explica por qué la soberanía no debería tratarse únicamente como un proyecto de seguridad.
Los equipos de seguridad se preocuparán, naturalmente, por retención, controles de acceso, residencia de datos y auditabilidad. Los equipos de infraestructura se preocuparán por fiabilidad y despliegue. Finanzas se preocupará por el coste de inferencia. Producto se preocupará por la calidad del modelo y la latencia. Legal se preocupará por contratos, regulación y procesamiento de datos.
Una buena arquitectura de IA tiene que acomodar a todos ellos.
El despliegue más soberano sirve de poco si el modelo no puede realizar la tarea. El despliegue más barato no resulta atractivo si expone información que la empresa considera crítica. El mejor modelo de un benchmark puede ser irrelevante si utilizarlo crea una dependencia que la organización no puede aceptar.
La soberanía ofrece un marco para negociar estos trade-offs pero hay que entender que no uno de ellos tiene que ganar siempre.
Un test práctico de soberanía de la IA
Existe una forma sencilla de que las empresas empiecen a evaluar dónde se encuentran hoy.
Elige una carga de trabajo de IA que ya sea importante para la organización, preferiblemente alguna conectada a datos internos, y sigue una única petición desde el momento en que la realiza el usuario hasta que vuelve la respuesta.
Después intenta responder a siete preguntas.
1. ¿Sabes exactamente qué información sale de tu entorno?
No solo el prompt del usuario, sino también documentos recuperados, historial de conversaciones, system prompts, resultados de herramientas, código fuente y cualquier otro contexto que se añada antes de la inferencia.
2. ¿Sabes qué persiste una vez termina la petición?
Esto incluye logs de la aplicación, logs del proveedor, prompts, respuestas, trazas, datos cacheados e historial de conversaciones. La respuesta no tiene que ser «nada». Simplemente tiene que ser deliberada.
3. ¿Puedes decidir dónde se ejecuta esa carga de trabajo?
¿Podría la misma aplicación utilizar una API alojada, un endpoint con retención cero, infraestructura dedicada o un modelo ejecutándose dentro de tu propio entorno si cambiase la sensibilidad de esa carga de trabajo?
4. ¿Puedes cambiar de modelo sin reconstruir la aplicación?
Casi siempre será necesaria cierta adaptación, especialmente cuando las aplicaciones dependan de capacidades específicas de un modelo. La pregunta es si cambiar de modelo es una tarea de ingeniería o una migración arquitectónica.
5. ¿Puedes controlar a qué puede acceder el modelo y qué puede hacer?
En los sistemas agénticos, el endpoint de inferencia es solo una parte del perímetro de seguridad. Los permisos de las herramientas, el acceso a datos, los entornos de ejecución y la identidad importan igual.
6. ¿Puedes verificar las garantías de las que dependes?
Algunas garantías pueden proceder de la arquitectura. Otras requieren contratos, auditorías o certificaciones. Una empresa debería saber cuáles son cuáles en lugar de depender de suposiciones sobre cómo funciona probablemente un servicio.
7. Si mañana cambiasen tus requisitos, ¿podría cambiar tu arquitectura con ellos?
En última instancia, esta es la pregunta que conecta todas las anteriores.
Que una empresa no pueda responder hoy a todas estas preguntas no significa necesariamente que tenga un problema de seguridad con la IA. La mayoría de organizaciones todavía están construyendo esta infraestructura, y muchas cargas de trabajo simplemente no justifican los niveles de control más elevados.
Pero las respuestas muestran dónde se ha delegado la confianza y dónde las decisiones técnicas están empezando a convertirse en dependencias.
Es información útil antes de que esas dependencias resulten difíciles de revertir.
Cómo pensamos sobre esto en Helmcode: nuestra idea de soberanía
Estos principios han influido en cómo estamos construyendo Helmcode.
Queremos que las empresas puedan utilizar modelos abiertos sin tener que convertirse ellas mismas en empresas de infraestructura de inferencia. Eso significa ofrecer la comodidad de una API conservando al mismo tiempo algunas de las propiedades que hacen atractiva la inferencia operada de forma privada.
Una de esas decisiones tiene que ver con cómo se gestionan los datos del cliente.
La inferencia en Helmcode está diseñada alrededor de una arquitectura de zero logs. Los prompts y el contexto de los clientes se procesan en memoria durante la sesión de GPU, en lugar de acumularse como un dataset histórico de clientes. Los prompts de los clientes no se utilizan para entrenar modelos futuros y la capa de inferencia está diseñada para evitar crear detrás de la API una colección histórica con el contenido de los prompts.
Nuestro objetivo es hacer que zero logs sea una propiedad de la arquitectura y no simplemente una política de retención.
Existe una diferencia importante entre prometer borrar posteriormente los datos del cliente y diseñar un sistema para que exista la menor cantidad posible de datos del cliente que puedan conservarse en primer lugar.
La arquitectura, sin embargo, no elimina la necesidad de confianza.
Los clientes siguen teniendo que confiar en que operamos la infraestructura tal y como la describimos, por eso las garantías técnicas deberían acompañarse de verificación independiente en lugar de tratarse como un sustituto de ella. Estamos trabajando en ese proceso, incluida certificación externa sobre cómo gestionamos los datos y la infraestructura.
Tampoco creemos que todas las cargas de trabajo tengan que ejecutarse a través de Helmcode.
Habrá cargas de trabajo para las que un modelo propietario frontier sea la decisión correcta, otras en las que un modelo abierto ofrezca mejores costes y otras cuya sensibilidad justifique una infraestructura controlada completamente por la empresa que la utiliza.
La arquitectura en la que creemos es una en la que esas decisiones no tengan que ser permanentes.
La IA se está integrando demasiado profundamente en las empresas como para que la inferencia siga siendo un simple detalle de implementación. Los modelos se sitúan cada vez más entre los empleados y los documentos, entre los desarrolladores y el código, entre los agentes y los sistemas internos.
A medida que eso ocurre, la pregunta de dónde se ejecuta la inteligencia pasa a formar parte de la propia arquitectura de la empresa.
El objetivo de la soberanía de la IA es saber dónde se ejecuta tu inteligencia, entender qué estás delegando y conservar la capacidad de elegir de otra manera cuando sea importante. No consiste en replegarse de la infraestructura externa ni en guardar cada token dentro de tu propio edificio.
El objetivo no es eliminar la confianza de la infraestructura de IA. Sería imposible. Es entender dónde existe esa confianza, reducirla allí donde la carga de trabajo lo exija y mantener la capacidad de modificar la arquitectura cuando cambie la respuesta.
Las empresas que consigan hacerlo seguirán dependiendo de proveedores de IA.
Pero no tendrán que depender de ninguno en particular. Podrán elegir.
Notas
Las llamadas [1] a [5] del texto corresponden a estas fuentes, todas consultadas el 15 de septiembre de 2026.
[1] Palantir pidió a Anthropic un compromiso irrevocable de retención cero de datos antes de servir sus modelos dentro de su software; NVIDIA limita el uso de los modelos de Anthropic a tareas menos sensibles y recurre a sus propios modelos Nemotron para el trabajo interno; Booz Allen prohibió a sus empleados usar el modelo comercial de Anthropic para trabajo propietario de ciberseguridad. Reuters, 14 de septiembre de 2026, sobre una exclusiva de The Information: Palantir, Nvidia curb AI model use over data fears .
[2] OpenAI indica que los datos enviados a su API no se utilizan para entrenar ni mejorar sus modelos salvo que el cliente opte explícitamente por compartirlos, y que los logs de detección de abuso se generan para todo uso de la API y se conservan hasta 30 días, salvo que la ley exija más. La retención cero excluye el contenido del cliente de esos logs y está sujeta a aprobación previa de OpenAI: Your data, OpenAI API .
[3] Anthropic ofrece retención cero de datos para la Claude API y declara que el contenido de la conversación no se retiene por defecto, pero la cobertura se define funcionalidad a funcionalidad: las que almacenan trabajos, ficheros o estado de contenedor quedan fuera, y usar una de ellas es, en sus propias palabras, salirse del acuerdo de retención cero para esos datos concretos: API and data retention .
[4] Que exista retención cero no significa que no se registre nada. OpenAI documenta que los logs de detección de abuso pueden contener metadatos derivados del contenido del cliente, como las salidas de sus clasificadores, y que los datos de sistema se procesan aparte. Anthropic documenta que, si se activa el logging de métricas en Claude Code, los datos de productividad quedan exentos de la retención cero y pueden conservarse. La pregunta útil es qué no se retiene, no si la etiqueta ZDR aparece en el contrato.
[5] Las condiciones dependen del modelo y del producto, no solo del proveedor. Anthropic designa Claude Fable 5, Fable 5.1, Mythos 5 y Mythos 5.1 como Covered Models: exigen 30 días de retención para trabajo de seguridad en todas las plataformas donde se ofrecen, y no están disponibles bajo retención cero salvo autorización expresa, una política en vigor desde el 9 de junio de 2026. Las interfaces de Claude Teams y Claude Enterprise tampoco son elegibles para retención cero. Por eso no se puede escribir simplemente que Anthropic guarda tus datos: Data retention practices for Covered Models .
