Durante la mayor parte de los últimos dos años, la elección práctica para los equipos de TI europeos que desplegaban modelos de lenguaje era sencilla: llamar a una API. OpenAI, Anthropic, Google Gemini y sus competidores ofrecían capacidades que ninguna alternativa autoalojada podía igualar, y la exposición de cumplimiento parecía manejable. Ese cálculo está cambiando. Los modelos de pesos abiertos de Mistral, Meta y otros han cerrado la brecha de capacidades lo suficiente como para que la pregunta ya no sea si la inferencia autoalojada es viable, sino si las APIs propietarias siguen mereciendo las concesiones que implican.

La concesión no es solo técnica. Cada solicitud de inferencia que lleva datos personales a un endpoint de API fuera de la UE es una transferencia internacional de datos bajo el RGPD. Cada modelo integrado en un producto que sirve a usuarios de la UE está dentro del ámbito del Reglamento de IA de la UE, en vigor desde agosto de 2024 y con obligaciones que se despliegan en fases hasta 2027. Entender exactamente qué exige cada tipo de modelo, tanto operativa como legalmente, es ahora un requisito previo para cualquier estrategia seria de despliegue de IA.

Qué significa realmente «pesos abiertos»

El término código abierto se usa de forma laxa en la IA, y esa laxitud importa. Un modelo puede publicar sus pesos y al mismo tiempo restringir el uso comercial, prohibir el ajuste fino o limitar la escala de despliegue. A efectos del Reglamento de IA de la UE, las exenciones del artículo 53(2) se aplican únicamente a los modelos publicados bajo una licencia que permita explícitamente el acceso, uso, modificación y distribución libres, sin pago ni otras condiciones restrictivas. Si la licencia cobra por el uso comercial a partir de un umbral de usuarios, la exención no se aplica.

Los modelos que sí cumplen los requisitos para la exención quedan liberados de ciertas obligaciones del proveedor: concretamente, la obligación de elaborar y mantener la documentación técnica completa sobre los procesos de entrenamiento y prueba. Sin embargo, dos obligaciones persisten independientemente de la licencia: el cumplimiento en materia de derechos de autor y la publicación de un resumen de los datos de entrenamiento utilizando la plantilla de la Oficina de IA. Estas no se eliminan por el carácter de código abierto.

La exención también tiene un techo absoluto. Cualquier modelo entrenado con más de 10²⁵ FLOPs se clasifica como modelo GPAI de riesgo sistémico según el artículo 51. Para esos modelos, la exención de código abierto del artículo 53(2) desaparece por completo. El proveedor se enfrenta a la totalidad de las obligaciones del artículo 53 más los requisitos adicionales del Capítulo V: pruebas adversariales, notificación de incidentes a la Oficina de IA de la UE, medidas de ciberseguridad e informes anuales de consumo energético. El umbral se calibró en torno a la capacidad de cómputo de la clase GPT-4 en el momento de la redacción; los modelos de pesos abiertos de frontera se están acercando a él.

La obligación del desplegador que la licencia no puede tocar

Este es el punto que la mayoría de los equipos pasa por alto. Las exenciones de código abierto del Reglamento de IA cubren las obligaciones del proveedor del modelo, no las tuyas. Cuando descargas Llama o Mistral y lo integras en un producto que sirve a usuarios de la UE, eres un desplegador y potencialmente un proveedor según el Reglamento. La licencia del modelo es irrelevante para tu condición regulatoria.

Desplegar un modelo de código abierto en un contexto de alto riesgo te convierte en el proveedor de un sistema de IA de alto riesgo. Las once obligaciones de alto riesgo se aplican en su totalidad. La licencia upstream no cambia nada.

Los contextos de alto riesgo incluyen la selección de personal, la calificación crediticia, el diagnóstico médico y el apoyo a las fuerzas del orden. Si tu caso de uso toca alguno de esos ámbitos, la carga de cumplimiento es idéntica tanto si usas GPT-4 a través de una API como si usas Mistral en tu propio hardware. La elección de arquitectura afecta a la residencia de datos y al control operativo, no a la clasificación regulatoria del sistema que estás construyendo.

El RGPD y la cuestión de las transferencias en la inferencia

El RGPD no prescribe dónde deben almacenarse los datos, pero restringe las transferencias de datos personales a países sin protección adecuada. Una solicitud de inferencia que incluya datos personales, el nombre de un cliente, un fragmento de historial médico, un ticket de soporte, constituye una transferencia si se procesa fuera de la UE. Incluso los metadatos y la telemetría pueden constituir datos personales según la amplia definición del RGPD.

Ejecutar la inferencia en local elimina por completo la cuestión de la transferencia. Cuando el modelo se ejecuta dentro de tu red, los datos de los clientes nunca cruzan una frontera. El artículo 46 del RGPD sencillamente no se aplica porque no hay ninguna transferencia que regular. No se trata de una solución alternativa de cumplimiento; es el resultado arquitectónico que el reglamento fue diseñado para incentivar.

El riesgo estructural de las APIs propietarias va más allá de la residencia de datos. El artículo 48 del RGPD prohíbe entregar datos personales a autoridades de fuera de la UE sin un acuerdo internacional. El CEPD finalizó sus directrices sobre el artículo 48 en junio de 2025, aclarando las condiciones en las que las organizaciones pueden responder lícitamente a solicitudes de autoridades de terceros países. Cualquier pipeline de inferencia enrutado a través de un proveedor con sede en EE. UU. se sitúa dentro de esta tensión estructural, independientemente de las salvaguardas contractuales vigentes.

Dónde siguen ganando las APIs propietarias

La honestidad intelectual exige reconocer dónde el argumento del modelo propietario se sostiene. La capacidad de frontera absoluta, el razonamiento multimodal, las tareas de contexto largo que requieren cientos de miles de tokens y las tareas que demandan los datos de entrenamiento más recientes siguen favoreciendo a los modelos propietarios más grandes. La carga operativa de ejecutar inferencia GPU a escala es real: la adquisición de hardware, la gestión de controladores, la infraestructura de servicio de modelos y la planificación de capacidad no son triviales.

Para casos de uso donde los datos son genuinamente no personales, el volumen es bajo y el requisito de capacidad se sitúa en la frontera, una API propietaria con los términos de DPA adecuados puede ser la elección pragmática. El Marco de Privacidad de Datos UE-EE. UU. proporciona un mecanismo legal para las transferencias a proveedores estadounidenses certificados, aunque su estabilidad a largo plazo sigue siendo una cuestión abierta para cualquier equipo que planifique infraestructura más allá de un horizonte de dos años.

La arquitectura de inferencia en local

Para los equipos que han decidido que la inferencia autoalojada es la opción correcta, la arquitectura es más accesible de lo que era hace dieciocho meses. Los frameworks modernos de servicio gestionan la carga del modelo, el batching, la cuantización y el enrutamiento de solicitudes. Las preguntas restantes son el dimensionamiento del hardware, la selección del modelo y dónde se sitúa la inferencia en relación con el resto de tu pipeline de datos.

La inferencia y el entrenamiento en GPU son una parte central de lo que operamos en DIVERSITY, sobre hardware dedicado en nuestros centros de datos de la UE. Los equipos que no quieren gestionar la capa de GPU pero necesitan que la inferencia permanezca dentro de la jurisdicción europea pueden ejecutar sus cargas de trabajo en nuestra infraestructura, manteniendo la garantía de residencia de datos sin asumir ellos mismos las operaciones sobre hardware bare-metal.

La selección de modelos es ahora genuinamente competitiva. Para la mayoría de las tareas de inferencia empresarial, un modelo de pesos abiertos de 70 mil millones de parámetros bien cuantizado ejecutándose en cuatro u ocho A100 igualará la calidad de una API propietaria en extracción estructurada, clasificación, resumen y generación aumentada por recuperación. La brecha se estrecha aún más cuando la tarea es específica del dominio y el modelo puede ajustarse con datos internos, algo que las APIs propietarias hacen difícil o imposible.

Cómo tomar la decisión de construir o comprar

El marco de decisión no es complicado, pero requiere respuestas honestas a tres preguntas. Primera: ¿tu carga de trabajo de inferencia procesa datos personales? Si es así, la infraestructura en local o soberana dentro de la UE es el camino de menor riesgo. Segunda: ¿tu contexto de despliegue califica como de alto riesgo según el Reglamento de IA? Si es así, las obligaciones de cumplimiento son las mismas independientemente del tipo de modelo, por lo que la decisión se reduce a la capacidad y el encaje operativo. Tercera: ¿necesitas capacidad de frontera absoluta que los modelos de pesos abiertos aún no pueden igualar? Si es así, una API propietaria puede estar justificada, con los controles contractuales y arquitectónicos adecuados.

Para la mayoría de las cargas de trabajo de inferencia empresarial, los modelos de pesos abiertos ejecutándose en infraestructura de la UE satisfacen ahora los tres criterios mejor que una API propietaria. La brecha de capacidades se ha cerrado lo suficiente como para que la concesión en soberanía ya no sea un precio razonable a pagar por la comodidad. Los equipos que lo reconozcan antes serán los que tengan mayor flexibilidad operativa cuando comience la fase de aplicación del Reglamento de IA en agosto de 2026.