7 min. de lectura<\/p>\n
La inteligencia artificial se convierte para las empresas en una cuesti\u00f3n estrat\u00e9gica de infraestructura. En la conversaci\u00f3n con Alexander Hendorf, consultor de IA y experto en c\u00f3digo abierto, queda claro: quien quiera utilizar la IA con soberan\u00eda debe poder comprender, operar y controlar lo que ocurre en su propio sistema. El c\u00f3digo abierto no es una opci\u00f3n secundaria, sino un requisito previo para el control, la capacidad operativa y la competitividad a largo plazo.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>Platform Engineering ya no es un proyecto de DevEx<\/a> \/<\/span> SAP Sovereign Cloud France<\/a><\/p>\n El 3 de junio de 2026, la Comisi\u00f3n Europea present\u00f3 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\u00f3digo abierto. El previsto Cloud and AI Development Act establecer\u00e1 niveles graduales de soberan\u00eda para cargas de trabajo sensibles y ampliar\u00e1 la capacidad europea de centros de datos. La estrategia de c\u00f3digo abierto trata expl\u00edcitamente el software abierto como un instrumento clave para reducir la dependencia de terceros pa\u00edses en materia de nube, IA y ciberseguridad.<\/p>\n Para Hendorf, la direcci\u00f3n es correcta, pero el enfoque resulta incompleto. La capacidad por s\u00ed 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.<\/p>\n \u201eLos cuellos de botella de Europa no son solo los modelos o los centros de datos. El cuello de botella de Europa es la capacidad de construir sistemas de IA de forma controlada, operarlos de manera productiva, evaluarlos con seguridad y adaptarlos a casos de uso concretos: de forma local, neutral respecto al fabricante y bas\u00e1ndose en c\u00f3digo abierto. Solo los modelos abiertos y el software abierto permiten comprender realmente los sistemas de IA, examinarlos, adaptarlos y operarlos con control propio. Las cajas negras propietarias no pueden controlarse con soberan\u00eda.\u00bb<\/p>\n Alexander Hendorf, experto en IA y director del grupo de trabajo de c\u00f3digo abierto en la Asociaci\u00f3n Federal de IA, en su declaraci\u00f3n sobre el paquete de soberan\u00eda tecnol\u00f3gica de la UE<\/p>\n<\/div>\n \u00bfQu\u00e9 es la soberan\u00eda en IA?<\/strong> La soberan\u00eda en IA describe la capacidad de una empresa para seleccionar, integrar, operar y evaluar por s\u00ed 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\u00e1s de \u00e9l.<\/p>\n Muchos empresarios est\u00e1n debatiendo actualmente sobre IA soberana, modelos europeos como Mistral y el uso de c\u00f3digo abierto. Sin embargo, ya no se trata solo de aplicaciones individuales o chatbots. La IA interviene m\u00e1s profundamente en procesos empresariales, plataformas de datos y arquitecturas en la nube: desde el an\u00e1lisis de contratos hasta la comunicaci\u00f3n con clientes y la b\u00fasqueda interna de conocimientos.<\/p>\n Tambi\u00e9n 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\u00e9n en temas como agentes de IA, est\u00e1ndares de API, arquitecturas de datos y ingenier\u00eda de software. Por eso mismo, la pregunta se desplaza de la elecci\u00f3n del modelo a la capacidad operativa.<\/p>\n La discusi\u00f3n sobre IA soberana suele llevarse a cabo de forma unilateral. A menudo surge la impresi\u00f3n de que las empresas deben decidirse fundamentalmente entre nube y on-premise. Seg\u00fan Hendorf, esto es demasiado limitado.<\/p>\n Lo decisivo es, en cambio, si las empresas entienden y pueden controlar su infraestructura, independientemente de d\u00f3nde 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.<\/p>\n \u00abEl software no es el activo, est\u00e1 disponible en todas partes. Incluso los grandes proveedores de nube trabajan con c\u00f3digo abierto y lo promueven activamente\u00bb, dice Hendorf. \u00abEl 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\u00bb.<\/p>\n Lo que esta capacidad operativa significa en la pr\u00e1ctica se puede fijar con un t\u00e9rmino que ya es est\u00e1ndar en c\u00edrculos de ingenier\u00eda, pero rara vez aparece en directivas empresariales: la Harness. Se refiere a un entorno de prueba y evaluaci\u00f3n propio de la empresa, donde cada modelo de IA se prueba sistem\u00e1ticamente contra casos de uso propios, muestras de datos y criterios de calidad antes de su implementaci\u00f3n productiva.<\/p>\n \u00abLa Harness es el verdadero activo\u00bb, afirma Hendorf. \u00abEs la protecci\u00f3n contra cambios de modelos y actualizaciones. Sin ella, cada cambio es un vuelo ciego. Solo semanas despu\u00e9s en la operaci\u00f3n se descubre si el nuevo modelo sigue haciendo exactamente lo que hac\u00eda el anterior. Con ella, el cambio se convierte en una decisi\u00f3n rutinaria t\u00e9cnica\u00bb.<\/p>\n 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\u00f3n en marcha.<\/p>\n Los modelos, marcos de trabajo e infraestructuras son hoy tan ampliamente disponibles como nunca antes: desde modelos ling\u00fc\u00edsticos abiertos como Llama o Mistral hasta servidores de inferencia como vLLM y Ollama, pasando por bases de datos vectoriales para la b\u00fasqueda interna de conocimiento empresarial. Con ello, la discusi\u00f3n sobre la inteligencia artificial se desplaza de la pregunta puramente sobre qui\u00e9n tiene acceso al modelo m\u00e1s potente. Lo que resulta m\u00e1s importante es qui\u00e9n puede comprender, adaptar y operar de forma confiable los sistemas de inteligencia artificial.<\/p>\n La brecha con la punta propietaria se reduce. Hendorf menciona evaluaciones del entorno PyCon, seg\u00fan las cuales los modelos comerciales est\u00e1n solo meses, no a\u00f1os, por delante de alternativas abiertas. Para las empresas, esto representa un cambio relevante: pueden configurar cada vez m\u00e1s los sistemas de inteligencia artificial por s\u00ed mismas, operarlos localmente, integrarlos en sus procesos y tener un control m\u00e1s fuerte. Esta nueva libertad incrementa sin embargo tambi\u00e9n la responsabilidad dentro de su propia organizaci\u00f3n.<\/p>\n Porque el c\u00f3digo abierto no elimina autom\u00e1ticamente la dependencia de proveedores individuales. Desplaza las exigencias. Quien quiera utilizar inteligencia artificial abierta necesita conocimientos t\u00e9cnicos, decisiones claras sobre arquitectura, gobernanza y la capacidad de evaluar realista mente la calidad, seguridad y costes de operaci\u00f3n.<\/p>\n Con ello, una pregunta pasa a primer plano, que suele quedar en segundo plano en el entusiasmo por modelos europeos o estadounidenses: \u00bfseg\u00fan qu\u00e9 criterios deben elegirse realmente los sistemas de inteligencia artificial? Fundamental no es \u00fanicamente la procedencia de un modelo, sino si se adapta al caso concreto de aplicaci\u00f3n, a la base de datos existente, a los requisitos regulatorios y a la propia capacidad operativa.<\/p>\n \u201e\u00bfQu\u00e9 modelo entre los actualmente ampliamente disponibles utiliza una empresa, se decide no por su procedencia, sino por su aplicaci\u00f3n\u201d, dice Hendorf. \u201eLos modelos de China, por ejemplo de DeepSeek o Qwen, pertenecen t\u00e9cnicamente a la punta, son accesibles p\u00fablicamente y en muchas tareas son igual de buenos o incluso superiores a los modelos de c\u00f3digo abierto occidentales. Si sus datos de entrenamiento han sido filtrados pol\u00edticamente, no es un criterio decisivo para la mayor\u00eda de los casos de uso empresariales como an\u00e1lisis de contratos, b\u00fasqueda de conocimiento o clasificaci\u00f3n. El sesgo existe en cada modelo. La pregunta relevante no es de d\u00f3nde viene, sino si uno puede manejarlo en su propia aplicaci\u00f3n.\u201d<\/p>\n C\u00f3mo relevante esta pregunta ha llegado a ser, lo muestra un ejemplo pr\u00e1ctico del \u00e1mbito financiero. Un gestor de activos quer\u00eda entrenar sus propios modelos de inteligencia artificial y pens\u00f3 inicialmente en una soluci\u00f3n en la nube. Sin embargo, en un entorno altamente regulado, los procesos de gobernanza y cumplimiento habr\u00edan tardado doce a veinticuatro meses. En este periodo, muchos proyectos quedan pospuestos antes de llegar a producci\u00f3n.<\/p>\n Tras analizar el caso de uso real, la decisi\u00f3n fue diferente: en lugar de un gran modelo generalista, se cre\u00f3 una soluci\u00f3n mucho m\u00e1s peque\u00f1a basada en la propiedad, con propio servidor y dos GPUs de consumo de Nvidia en una red protegida. Seg\u00fan Hendorf y su equipo, llevaron la soluci\u00f3n a producci\u00f3n en cuatro semanas.<\/p>\n El efecto: la soluci\u00f3n total cost\u00f3 menos de seis meses de operaci\u00f3n en la nube. Al mismo tiempo, los empleados pudieron trabajar inmediatamente con el sistema, sin esperar a largas liberaciones.<\/p>\n Para Hendorf, este ejemplo muestra un problema fundamental de muchos proyectos de inteligencia artificial. Las empresas suelen orientarse a la m\u00e1xima escalabilidad, aunque sus necesidades sean claramente m\u00e1s especializadas: \u201eNo todo caso de uso necesita un Porsche, a veces basta con un patinete.\u201d Especialmente los modelos m\u00e1s peque\u00f1os con pocos miles de millones de par\u00e1metros pueden ser m\u00e1s eficientes, econ\u00f3micos y m\u00e1s f\u00e1ciles de controlar para tareas claramente definidas que los grandes sistemas universales. Y funcionan en hardware que la empresa posee ella misma.<\/p>\n Con la aparici\u00f3n de los agentes de IA, esta tendencia se agrava a\u00fan m\u00e1s. Los agentes acceden a datos, utilizan APIs y automatizan procesos. Para ello, necesitan entornos t\u00e9cnicos estructurados.<\/p>\n Las soluciones aisladas de crecimiento hist\u00f3rico, las interfaces mal documentadas y los complejos ecosistemas de herramientas se convierten as\u00ed en un problema creciente. Seg\u00fan Hendorf, los agentes de IA funcionan mucho mejor con APIs estandarizadas y estructuras de datos coherentes. Nuevos est\u00e1ndares abiertos como el Model Context Protocol requieren que los sistemas subyacentes est\u00e9n limpiamente documentados y sean accesibles. Donde esto falta, los agentes no fracasan por el modelo, sino por la arquitectura interna.<\/p>\n Esto obliga a las empresas a reevaluar su infraestructura. El Open Source puede ayudar, ya que los sistemas se vuelven m\u00e1s transparentes y flexibles. Sin embargo, sin una arquitectura limpia y un buen Software Engineering, surge r\u00e1pidamente una nueva complejidad.<\/p>\n Tambi\u00e9n en el tema de la seguridad y la protecci\u00f3n de datos, Hendorf observa muchos malentendidos. El Open Source no es autom\u00e1ticamente seguro. Quien descarga un modelo de un hub de modelos en la red sin verificar su origen, importa la misma l\u00f3gica de riesgo que en cualquier otra cadena de suministro de software. Al mismo tiempo, una infraestructura local no es per se m\u00e1s arriesgada que los complejos entornos Cloud con flujos de datos dif\u00edciles de rastrear.<\/p>\n 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\u00e9cnica. A esto tambi\u00e9n pertenece la cuesti\u00f3n de qui\u00e9n puede rastrear forensemente, en caso de duda, qu\u00e9 entradas ha procesado un modelo y cu\u00e1ndo.<\/p>\n Con ello, la IA tambi\u00e9n cambia el papel de los equipos de TI y de seguridad. Deben permitir la innovaci\u00f3n y, al mismo tiempo, garantizar que las empresas mantengan el control sobre los datos, los modelos y los procesos.<\/p>\n Por lo tanto, el debate sobre la IA Open Source es mucho m\u00e1s que una cuesti\u00f3n de modelos. Las empresas deben decidir qu\u00e9 tan dependientes quieren ser en el futuro de plataformas externas y qu\u00e9 conocimientos t\u00e9cnicos y organizativos deben desarrollar por s\u00ed mismas.<\/p>\n Las plataformas Cloud y los modelos propietarios seguir\u00e1n desempe\u00f1ando 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\u00eda digital.<\/p>\n Lo que agrava a\u00fan m\u00e1s la discusi\u00f3n es la situaci\u00f3n regulatoria. El EU AI Act clasifica ciertas aplicaciones de IA, por ejemplo en recursos humanos, concesi\u00f3n de cr\u00e9ditos o infraestructuras cr\u00edticas, como de alto riesgo y exige flujos de datos rastreables, decisiones de modelos documentadas y procesos operativos auditables.<\/p>\n O dicho de otro modo: quien quiera utilizar la IA de forma estrat\u00e9gica a largo plazo, no solo necesita acceso a los modelos, sino control sobre la infraestructura subyacente.<\/p>\n Tres preguntas antes de cada nueva iniciativa de IA<\/p>\n Quien no pueda responder a estas preguntas en el plazo de un d\u00eda, no tiene un problema de modelo, sino un problema de arquitectura. Ah\u00ed es donde comienza el verdadero trabajo hacia una IA soberana.<\/p>\n La IA soberana significa que una empresa puede controlar los modelos, los flujos de datos, la calidad y las operaciones. La ubicaci\u00f3n por s\u00ed sola no es determinante. Una soluci\u00f3n en la nube tambi\u00e9n puede ser soberana si se dominan la arquitectura, la gobernanza y las v\u00edas de migraci\u00f3n.<\/p>\n<\/details>\n Un harness eval\u00faa 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\u00f3n.<\/p>\n<\/details>\n Muchos casos de uso empresariales no necesitan un modelo grande gen\u00e9rico. Los modelos m\u00e1s peque\u00f1os y especializados pueden ser m\u00e1s econ\u00f3micos, r\u00e1pidos y f\u00e1ciles de controlar en tareas claramente delimitadas.<\/p>\n<\/details>\n M\u00e1s de la red de MBF Media<\/p>\n\n
El paquete de la UE apuesta por el c\u00f3digo abierto, el cuello de botella est\u00e1 en otro lugar<\/h2>\n
La soberan\u00eda en IA comienza con la infraestructura<\/h2>\n
\u00bfNube o on-premise es la pregunta equivocada?<\/h2>\n
El c\u00f3digo abierto cambia la situaci\u00f3n inicial<\/h2>\n
Por qu\u00e9 soluciones m\u00e1s peque\u00f1as suelen ser m\u00e1s adecuadas<\/h2>\n
Los agentes de IA aumentan la presi\u00f3n por poner orden<\/h2>\n
La seguridad no se genera autom\u00e1ticamente<\/h2>\n
La infraestructura se convierte en una ventaja competitiva<\/h2>\n
\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 diferencia a la IA soberana de la IA en la nube cl\u00e1sica?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 es tan importante contar con un harness propio?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 suelen bastar las configuraciones on-premise m\u00e1s peque\u00f1as?<\/strong><\/summary>\n