EU AI Act en 2026: qué cambia el despliegue on-premises en el cumplimiento

La EU AI Act entró en vigor en agosto de 2024, con disposiciones implementadas por fases a lo largo de un periodo de entre dos y tres años ^[1][2]. La mayoría de las conversaciones de cumplimiento en la empresa se han centrado, hasta ahora, en si un flujo de trabajo entra o no en la categoría de «alto riesgo». A mediados de 2026, la conversación está cambiando hacia una pregunta más práctica: dado que el flujo de trabajo sí está dentro del ámbito, qué arquitecturas de despliegue le permiten realmente satisfacer las obligaciones del deployer, y cuáles, silenciosamente, no lo hacen.

Esa segunda pregunta es donde el despliegue on-premises deja de ser una preferencia estilística y pasa a ser un encaje estructural.

Qué exige la Ley a los deployers de IA de alto riesgo

La Ley distingue entre el provider de un sistema de IA y el deployer que lo utiliza ^[1]. Un banco que utiliza una API LLM de terceros para evaluar solicitudes de préstamo es el deployer, no el provider. Los deployers de sistemas de alto riesgo asumen obligaciones que incluyen: garantizar la supervisión humana, monitorizar el funcionamiento del sistema, conservar registros durante un periodo apropiado, suspender el uso si el sistema supone un riesgo para los derechos fundamentales y demostrar estas capacidades cuando se solicite.

Varias de esas obligaciones son sencillas cuando el deployer controla el runtime. La obligación de «conservar registros durante un periodo apropiado» es mecánicamente simple si la inferencia ocurre en un servidor que el deployer posee y los registros aterrizan en el SIEM del deployer. La obligación de «suspender el uso» es igualmente trivial si el deployer puede apagar el modelo en su propia infraestructura.

Las mismas obligaciones se vuelven más difíciles cuando la inferencia se ejecuta en una API LLM en la nube que el deployer no opera. Los registros que el deployer puede producir se limitan a lo que el provider expone. Suspender el uso requiere la cooperación del provider. Demostrar, en tiempo real, qué datos pasaron por el sistema requiere confiar en el pipeline del provider.

Dónde se sitúan las APIs LLM en la nube dentro de la regulación

Nada de esto convierte a las APIs LLM en la nube en no conformes. Artículo por artículo, los providers y deployers de IA alojada en la nube pueden satisfacer las obligaciones de la Ley. La fricción es operativa, no legal: el deployer debe ensamblar, auditar y demostrar el cumplimiento a través de un límite con el proveedor, a menudo para flujos de trabajo que ejecutan miles de inferencias al día.

El AI Index longitudinal de Stanford HAI ha rastreado el correspondiente desplazamiento del gasto empresarial ^[3]: el crecimiento más pronunciado entre 2023 y 2025 no se produjo en IA generativa de propósito general, sino en las herramientas de soporte —observabilidad, gobernanza, registro de prompts, clasificación de contenido, detección de jailbreaks. La mayor parte de ese gasto existe para cerrar la brecha entre lo que las APIs LLM en la nube exponen de forma nativa y lo que un deployer necesita poder evidenciar en un contexto regulatorio.

Esa brecha es la ventaja estructural de ejecutar la inferencia en hardware que el deployer posee. Cada pregunta de «¿pasó esto?» se reduce a una pregunta que el deployer puede responder a partir de sus propios registros.

Lo que el on-premises no le da gratis

Tres obligaciones del deployer en la AI Act no quedan satisfechas automáticamente por un despliegue on-premises, y vale la pena nombrarlas explícitamente:

• Supervisión humana. La Ley exige una supervisión significativa de la IA de alto riesgo, con personas capaces de interpretar los resultados e intervenir. Ejecutar el modelo localmente no pone a un humano en el bucle; lo hace el diseño del flujo de trabajo.
• Monitorización de deriva y comportamiento inseguro. El deployer debe monitorizar el sistema de forma continua. El despliegue on-premises hace que la fontanería sea trivial (los datos son locales), pero la política («¿qué aspecto tiene la deriva para este flujo de trabajo?») todavía hay que definirla.
• Obligaciones del provider trasladadas. Cuando el despliegue on-premises se construye sobre un modelo de terceros (por ejemplo, un modelo de pesos abiertos bajo una licencia no comercial, o un modelo de proveedor entregado como binario), el deployer aún necesita exponer las divulgaciones requeridas por el provider.

La ventaja estructural del on-premises está en los ejes de tratamiento de datos y demostrabilidad, no en el de política. La política debe redactarse y aplicarse independientemente de dónde se ubique la GPU.

Cómo encaja esto con EE. UU., Reino Unido y otras jurisdicciones

La EU AI Act es la más prescriptiva de los grandes marcos. El NIST AI RMF estadounidense ^[4] adopta un enfoque voluntario, basado en marco, y el AI Policy Observatory de la OCDE ^[5] rastrea cómo los gobiernos nacionales fuera de la UE están convergiendo en principios ampliamente similares (supervisión basada en riesgo, obligaciones de transparencia, reglas de tratamiento de datos).

Para un deployer multinacional, el efecto práctico es que la jurisdicción más estricta marca la arquitectura. Si un flujo de trabajo debe satisfacer la EU AI Act para usuarios europeos, ese mismo flujo no incumplirá las obligaciones de EE. UU., Reino Unido, Japón o Singapur si se diseña conforme al listón de la UE. Diseñar el despliegue conforme al listón más estricto —incluida la capacidad del deployer para evidenciar el tratamiento de datos por solicitud— es lo que hace del on-premises la opción por defecto estructuralmente más simple en la IA empresarial de 2026.

Cómo es un despliegue de IA on-premises preparado para el cumplimiento de 2026

La forma en la que distribuimos —y la forma que piden los revisores de cumplimiento con los que trabajamos— es:

• Inferencia local al cliente. Bien en el dispositivo del usuario, bien en un servidor operado por el cliente. Ningún prompt sale del perímetro.
• Registros de auditoría sin contenido. Cada acción administrativa queda registrada con marca temporal y actor; ningún prompt y ninguna respuesta aparecen en la fila de auditoría. La fila de auditoría es la evidencia; el contenido queda en manos del deployer para retenerlo bajo su propia política de retención.
• Identidad a través del IdP del cliente. OIDC contra Microsoft Entra ID o Google Workspace, con los controles de acceso existentes del deployer aplicándose sin cambios.
• Sin tenant del lado del proveedor. El proveedor (nosotros) no opera el runtime, no ve los datos y no es un punto único de fallo para la postura de cumplimiento del deployer.

Esa última propiedad es la que las APIs LLM en la nube estructuralmente no pueden replicar, y es la razón por la que el despliegue on-premises es el patrón dominante en el segmento de la empresa regulada del mercado en 2026.

El trasfondo sobre cómo construimos en torno a esto desde el principio se encuentra en Por qué distribuimos IA como binarios instalables, no como SaaS en la nube. Las capacidades que implementan la superficie de auditoría, identidad y política viven en AI Admin Console.

Referencias

1. European Commission. «AI Act — Regulatory framework on AI.» digital-strategy.ec.europa.eu. Consultado el 2026-06-15.
2. European Commission. «AI Act enters into force.» digital-strategy.ec.europa.eu. Consultado el 2026-06-15.
3. Stanford HAI. «AI Index Report.» aiindex.stanford.edu. Consultado el 2026-06-15.
4. NIST. «AI Risk Management Framework (AI RMF 1.0).» nist.gov/itl/ai-risk-management-framework. Consultado el 2026-06-15.
5. OECD AI Policy Observatory. «National AI policies.» oecd.ai. Consultado el 2026-06-15.

Artículos relacionados

• El cambio de cloud-first a residencia-de-datos-first en la compra de IA empresarial
• OECD AI Policy Observatory: qué cambió en los últimos 12 meses
• AI Admin Console: qué hace realmente cada una de las seis capacidades
• Registros de auditoría sin contenido: cómo demostramos lo que hizo el modelo sin conservar los prompts
• Por qué los despliegues de IA on-premises se atascan en compras (y el enfoque que lo resuelve)
• Por qué distribuimos IA como binarios instalables, no como SaaS en la nube
• Todos los artículos →