7 min. de lectura

La inteligencia artificial se convierte para las empresas en una cuestión estratégica de infraestructura. En la conversación con Alexander Hendorf, consultor de IA y experto en código abierto, queda claro: quien quiera utilizar la IA con soberanía debe poder comprender, operar y controlar lo que ocurre en su propio sistema. El código abierto no es una opción secundaria, sino un requisito previo para el control, la capacidad operativa y la competitividad a largo plazo.

Relacionado:Platform Engineering ya no es un proyecto de DevEx  /  SAP Sovereign Cloud France

El paquete de la UE apuesta por el código abierto, el cuello de botella está en otro lugar

El 3 de junio de 2026, la Comisión Europea presentó su European Tech Sovereignty Package: un conjunto que incluye el Chips Act 2.0, un Cloud and AI Development Act y una estrategia propia de código abierto. El previsto Cloud and AI Development Act establecerá niveles graduales de soberanía para cargas de trabajo sensibles y ampliará la capacidad europea de centros de datos. La estrategia de código abierto trata explícitamente el software abierto como un instrumento clave para reducir la dependencia de terceros países en materia de nube, IA y ciberseguridad.

Para Hendorf, la dirección es correcta, pero el enfoque resulta incompleto. La capacidad por sí sola no genera control. Lo decisivo es si las empresas y las administraciones pueden comprender, operar y auditar los sistemas que se ejecutan sobre esta infraestructura.

La soberanía en IA comienza con la infraestructura

¿Qué es la soberanía en IA? La soberanía en IA describe la capacidad de una empresa para seleccionar, integrar, operar y evaluar por sí misma sistemas de IA. Esto incluye el control sobre los flujos de datos, modelos, infraestructura, calidad, seguridad y rutas alternativas. Lo decisivo no es el nombre del modelo, sino la capacidad operativa detrás de él.

Muchos empresarios están debatiendo actualmente sobre IA soberana, modelos europeos como Mistral y el uso de código abierto. Sin embargo, ya no se trata solo de aplicaciones individuales o chatbots. La IA interviene más profundamente en procesos empresariales, plataformas de datos y arquitecturas en la nube: desde el análisis de contratos hasta la comunicación con clientes y la búsqueda interna de conocimientos.

También en conferencias clave sobre IA como la PyCon DE y PyData se muestra este cambio. Ahora no solo se centran en modelos y frameworks, sino también en temas como agentes de IA, estándares de API, arquitecturas de datos y ingeniería de software. Por eso mismo, la pregunta se desplaza de la elección del modelo a la capacidad operativa.

¿Nube o on-premise es la pregunta equivocada?

La discusión sobre IA soberana suele llevarse a cabo de forma unilateral. A menudo surge la impresión de que las empresas deben decidirse fundamentalmente entre nube y on-premise. Según Hendorf, esto es demasiado limitado.

Lo decisivo es, en cambio, si las empresas entienden y pueden controlar su infraestructura, independientemente de dónde se ejecute. Quienes dependen exclusivamente de proveedores de nube y servicios SaaS corren pronto el riesgo de distintas dependencias: las versiones de modelos cambian sin previo aviso, los precios y cuotas se ajustan unilateralmente, y los flujos de datos terminan en regiones que los equipos de cumplimiento no autorizan. Al mismo tiempo, un funcionamiento local solo tiene sentido si existe internamente el conocimiento necesario.

«El software no es el activo, está disponible en todas partes. Incluso los grandes proveedores de nube trabajan con código abierto y lo promueven activamente», dice Hendorf. «El activo es la capacidad operativa: entender un sistema, instalarlo por uno mismo y, en caso de duda, cambiar entre nube y hardware propio. Exactamente este conjunto de habilidades le falta a muchos».

Lo que esta capacidad operativa significa en la práctica se puede fijar con un término que ya es estándar en círculos de ingeniería, pero rara vez aparece en directivas empresariales: la Harness. Se refiere a un entorno de prueba y evaluación propio de la empresa, donde cada modelo de IA se prueba sistemáticamente contra casos de uso propios, muestras de datos y criterios de calidad antes de su implementación productiva.

«La Harness es el verdadero activo», afirma Hendorf. «Es la protección contra cambios de modelos y actualizaciones. Sin ella, cada cambio es un vuelo ciego. Solo semanas después en la operación se descubre si el nuevo modelo sigue haciendo exactamente lo que hacía el anterior. Con ella, el cambio se convierte en una decisión rutinaria técnica».

Exactamente esta brecha es una de las mayores debilidades cuando las empresas quieren cambiar de proveedor o actualizar un modelo. Quienes no tienen su propia Harness dependen de lo que prometen las notas de lanzamiento y deben creerlo durante la operación en marcha.

El código abierto cambia la situación inicial

Los modelos, marcos de trabajo e infraestructuras son hoy tan ampliamente disponibles como nunca antes: desde modelos lingüísticos abiertos como Llama o Mistral hasta servidores de inferencia como vLLM y Ollama, pasando por bases de datos vectoriales para la búsqueda interna de conocimiento empresarial. Con ello, la discusión sobre la inteligencia artificial se desplaza de la pregunta puramente sobre quién tiene acceso al modelo más potente. Lo que resulta más importante es quién puede comprender, adaptar y operar de forma confiable los sistemas de inteligencia artificial.

La brecha con la punta propietaria se reduce. Hendorf menciona evaluaciones del entorno PyCon, según las cuales los modelos comerciales están solo meses, no años, por delante de alternativas abiertas. Para las empresas, esto representa un cambio relevante: pueden configurar cada vez más los sistemas de inteligencia artificial por sí mismas, operarlos localmente, integrarlos en sus procesos y tener un control más fuerte. Esta nueva libertad incrementa sin embargo también la responsabilidad dentro de su propia organización.

Porque el código abierto no elimina automáticamente la dependencia de proveedores individuales. Desplaza las exigencias. Quien quiera utilizar inteligencia artificial abierta necesita conocimientos técnicos, decisiones claras sobre arquitectura, gobernanza y la capacidad de evaluar realista mente la calidad, seguridad y costes de operación.

Con ello, una pregunta pasa a primer plano, que suele quedar en segundo plano en el entusiasmo por modelos europeos o estadounidenses: ¿según qué criterios deben elegirse realmente los sistemas de inteligencia artificial? Fundamental no es únicamente la procedencia de un modelo, sino si se adapta al caso concreto de aplicación, a la base de datos existente, a los requisitos regulatorios y a la propia capacidad operativa.

„¿Qué modelo entre los actualmente ampliamente disponibles utiliza una empresa, se decide no por su procedencia, sino por su aplicación”, dice Hendorf. „Los modelos de China, por ejemplo de DeepSeek o Qwen, pertenecen técnicamente a la punta, son accesibles públicamente y en muchas tareas son igual de buenos o incluso superiores a los modelos de código abierto occidentales. Si sus datos de entrenamiento han sido filtrados políticamente, no es un criterio decisivo para la mayoría de los casos de uso empresariales como análisis de contratos, búsqueda de conocimiento o clasificación. El sesgo existe en cada modelo. La pregunta relevante no es de dónde viene, sino si uno puede manejarlo en su propia aplicación.”

Por qué soluciones más pequeñas suelen ser más adecuadas

Cómo relevante esta pregunta ha llegado a ser, lo muestra un ejemplo práctico del ámbito financiero. Un gestor de activos quería entrenar sus propios modelos de inteligencia artificial y pensó inicialmente en una solución en la nube. Sin embargo, en un entorno altamente regulado, los procesos de gobernanza y cumplimiento habrían tardado doce a veinticuatro meses. En este periodo, muchos proyectos quedan pospuestos antes de llegar a producción.

Tras analizar el caso de uso real, la decisión fue diferente: en lugar de un gran modelo generalista, se creó una solución mucho más pequeña basada en la propiedad, con propio servidor y dos GPUs de consumo de Nvidia en una red protegida. Según Hendorf y su equipo, llevaron la solución a producción en cuatro semanas.

El efecto: la solución total costó menos de seis meses de operación en la nube. Al mismo tiempo, los empleados pudieron trabajar inmediatamente con el sistema, sin esperar a largas liberaciones.

Para Hendorf, este ejemplo muestra un problema fundamental de muchos proyectos de inteligencia artificial. Las empresas suelen orientarse a la máxima escalabilidad, aunque sus necesidades sean claramente más especializadas: „No todo caso de uso necesita un Porsche, a veces basta con un patinete.” Especialmente los modelos más pequeños con pocos miles de millones de parámetros pueden ser más eficientes, económicos y más fáciles de controlar para tareas claramente definidas que los grandes sistemas universales. Y funcionan en hardware que la empresa posee ella misma.

Los agentes de IA aumentan la presión por poner orden

Con la aparición de los agentes de IA, esta tendencia se agrava aún más. Los agentes acceden a datos, utilizan APIs y automatizan procesos. Para ello, necesitan entornos técnicos estructurados.

Las soluciones aisladas de crecimiento histórico, las interfaces mal documentadas y los complejos ecosistemas de herramientas se convierten así en un problema creciente. Según Hendorf, los agentes de IA funcionan mucho mejor con APIs estandarizadas y estructuras de datos coherentes. Nuevos estándares abiertos como el Model Context Protocol requieren que los sistemas subyacentes estén limpiamente documentados y sean accesibles. Donde esto falta, los agentes no fracasan por el modelo, sino por la arquitectura interna.

Esto obliga a las empresas a reevaluar su infraestructura. El Open Source puede ayudar, ya que los sistemas se vuelven más transparentes y flexibles. Sin embargo, sin una arquitectura limpia y un buen Software Engineering, surge rápidamente una nueva complejidad.

La seguridad no se genera automáticamente

También en el tema de la seguridad y la protección de datos, Hendorf observa muchos malentendidos. El Open Source no es automáticamente seguro. Quien descarga un modelo de un hub de modelos en la red sin verificar su origen, importa la misma lógica de riesgo que en cualquier otra cadena de suministro de software. Al mismo tiempo, una infraestructura local no es per se más arriesgada que los complejos entornos Cloud con flujos de datos difíciles de rastrear.

Precisamente con datos sensibles, las redes internas protegidas pueden ofrecer ventajas. Sin embargo, lo decisivo sigue siendo el control de acceso, la gobernanza y la arquitectura técnica. A esto también pertenece la cuestión de quién puede rastrear forensemente, en caso de duda, qué entradas ha procesado un modelo y cuándo.

Con ello, la IA también cambia el papel de los equipos de TI y de seguridad. Deben permitir la innovación y, al mismo tiempo, garantizar que las empresas mantengan el control sobre los datos, los modelos y los procesos.

La infraestructura se convierte en una ventaja competitiva

Por lo tanto, el debate sobre la IA Open Source es mucho más que una cuestión de modelos. Las empresas deben decidir qué tan dependientes quieren ser en el futuro de plataformas externas y qué conocimientos técnicos y organizativos deben desarrollar por sí mismas.

Las plataformas Cloud y los modelos propietarios seguirán desempeñando un papel importante. Al mismo tiempo, crece la importancia de la capacidad operativa propia. Precisamente en esto ve Hendorf la verdadera base de la soberanía digital.

Lo que agrava aún más la discusión es la situación regulatoria. El EU AI Act clasifica ciertas aplicaciones de IA, por ejemplo en recursos humanos, concesión de créditos o infraestructuras críticas, como de alto riesgo y exige flujos de datos rastreables, decisiones de modelos documentadas y procesos operativos auditables.

O dicho de otro modo: quien quiera utilizar la IA de forma estratégica a largo plazo, no solo necesita acceso a los modelos, sino control sobre la infraestructura subyacente.

Quien no pueda responder a estas preguntas en el plazo de un día, no tiene un problema de modelo, sino un problema de arquitectura. Ahí es donde comienza el verdadero trabajo hacia una IA soberana.

Preguntas frecuentes

¿Qué diferencia a la IA soberana de la IA en la nube clásica?

La IA soberana significa que una empresa puede controlar los modelos, los flujos de datos, la calidad y las operaciones. La ubicación por sí sola no es determinante. Una solución en la nube también puede ser soberana si se dominan la arquitectura, la gobernanza y las vías de migración.

¿Por qué es tan importante contar con un harness propio?

Un harness evalúa los modelos frente a los casos de uso y criterios de calidad propios. Sin este entorno de pruebas, cualquier cambio de modelo sigue siendo arriesgado, ya que las desviaciones suelen hacerse visibles solo en el entorno de producción.

¿Por qué suelen bastar las configuraciones on-premise más pequeñas?

Muchos casos de uso empresariales no necesitan un modelo grande genérico. Los modelos más pequeños y especializados pueden ser más económicos, rápidos y fáciles de controlar en tareas claramente delimitadas.

Fuente de la imagen: generada por IA (mayo de 2026), certificado C2PA integrado en la imagen