La Ley de IA de la UE entró en vigor en agosto de 2024, con disposiciones que se implementan de forma gradual en un periodo de dos a tres años [1][2]. Hasta ahora, la mayoría de las conversaciones sobre cumplimiento empresarial se han centrado en si un flujo de trabajo entra en la categoría de «alto riesgo». Para mediados de 2026, la conversación se está desplazando hacia una cuestión más práctica: dado que el flujo de trabajo está dentro del alcance, ¿qué arquitecturas de despliegue permiten realmente cumplir con las obligaciones del desplegador, y cuáles no lo hacen en absoluto?

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

Lo que la Ley exige a los desplegadores de IA de alto riesgo

La Ley distingue entre el proveedor de un sistema de IA y el desplegador del mismo [1]. Un banco que utiliza una API de LLM de terceros para evaluar solicitudes de préstamo es el desplegador, no el proveedor. Los desplegadores de sistemas de alto riesgo tienen obligaciones que incluyen: garantizar supervisión humana, monitorear la operación del sistema, conservar registros durante un período adecuado, suspender el uso si el sistema representa un riesgo para derechos fundamentales y demostrar estas capacidades a solicitud.

Varias de esas obligaciones son sencillas cuando el desplegador controla el entorno de ejecución. La obligación de «conservar registros durante un período adecuado» es mecánicamente simple si la inferencia ocurre en un servidor que el desplegador posee y los registros se almacenan en el SIEM del desplegador. La obligación de «suspender el uso» es igualmente trivial si el desplegador puede apagar el modelo en su propia infraestructura.

Las mismas obligaciones se vuelven más difíciles cuando la inferencia se realiza en una API de LLM en la nube que el desplegador no opera. Los registros que el desplegador puede producir se limitan a lo que el proveedor expone. Suspender el uso requiere la cooperación del proveedor. Demostrar, de forma contemporánea, qué datos fluyeron a través del sistema requiere confiar en la cadena de procesamiento del proveedor.

Dónde encajan las APIs de LLM en la nube en la regulación

Nada de esto hace que las API de LLM en la nube incumplan la normativa. Artículo por artículo, los proveedores y desplegadores de IA alojada en la nube pueden cumplir con las obligaciones del Acta. La fricción es operativa, no legal: el desplegador debe ensamblar, auditar y demostrar el cumplimiento a través de un límite de proveedor, a menudo para flujos de trabajo que ejecutan miles de inferencias por día.

El Índice longitudinal de IA de Stanford HAI ha seguido el cambio correspondiente en el gasto empresarial [3]: el crecimiento más pronunciado entre 2023 y 2025 no fue 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 jailbreak. La mayor parte de ese gasto existe para cerrar la brecha entre lo que las API de LLM en la nube exponen de forma nativa y lo que un desplegador necesita evidenciar en un contexto regulatorio.

Esa brecha es la ventaja estructural de ejecutar inferencias en hardware que el desplegador posee. Cada pregunta de “¿esto ocurrió?” se reduce a una pregunta que el desplegador puede responder desde sus propios registros.

Lo que un despliegue on-prem no te da gratis

Tres obligaciones del desplegador según el AI Act no se satisfacen automáticamente con un despliegue on-prem, y vale la pena nombrarlas explícitamente:

  • Supervisión humana. El Acta requiere una supervisión significativa de la IA de alto riesgo, con humanos capaces de interpretar resultados e intervenir. Ejecutar el modelo localmente no pone a un humano en el ciclo; el diseño del flujo de trabajo sí.
  • Monitoreo de deriva y comportamiento inseguro. El desplegador debe monitorear continuamente el sistema. El despliegue on-prem hace que la infraestructura sea trivial (los datos están locales), pero la política (“¿cómo se ve la deriva para este flujo de trabajo?”) aún debe definirse.
  • Obligaciones del proveedor transferidas. Cuando el despliegue on-prem se basa en un modelo de terceros (por ejemplo, un modelo de pesos abiertos bajo licencia no comercial, o un modelo de proveedor entregado como binario), el desplegador aún debe mostrar las divulgaciones requeridas por el proveedor.

La ventaja estructural del on-prem está en los ejes de manejo de datos y demostrabilidad, no en la política. La política debe redactarse y aplicarse independientemente de dónde esté la GPU.

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

El AI Act de la UE es el más prescriptivo de los principales marcos. El NIST AI RMF de EE. UU. [4] adopta un enfoque voluntario basado en marcos, y el Observatorio de Políticas de IA de la OCDE [5] sigue cómo los gobiernos nacionales fuera de la UE convergen en principios ampliamente similares (supervisión basada en riesgos, obligaciones de transparencia, reglas de manejo de datos).

Para un desplegador multinacional, el efecto práctico es que la jurisdicción más estricta establece la arquitectura. Si un flujo de trabajo debe cumplir con el AI Act de la UE 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 estándar de la UE. Diseñar el despliegue según el estándar más estricto — incluyendo la capacidad del desplegador para evidenciar el manejo de datos por solicitud — es lo que hace que el on-prem sea la opción estructuralmente más simple por defecto en la IA empresarial de 2026.

Cómo es un despliegue de IA on-prem listo para cumplir en 2026

La forma que entregamos — y la forma que los revisores de cumplimiento con los que trabajamos solicitan — es:

  • Inferencia local al cliente. Ya sea en el dispositivo del usuario o en un servidor operado por el cliente. Ningún prompt sale del perímetro.
  • Registros de auditoría sin contenido. Cada acción administrativa se registra con marca de tiempo + actor; no aparecen prompts ni respuestas en la fila de auditoría. La fila de auditoría es la evidencia; el contenido es responsabilidad del desplegador conservarlo según su propia política de retención.
  • Identidad a través del IdP del cliente. OIDC contra Microsoft Entra ID o Google Workspace, aplicando sin cambios los controles de acceso existentes del desplegador.
  • No hay inquilino de inferencia operado por el proveedor. Software Tailor no opera el runtime del modelo ni recibe prompts, respuestas o documentos del cliente en esta ruta. La identidad de la organización, licencias, políticas, estado del servidor, uso agregado, auditoría y registros de soporte pueden seguir usando un plano de control del proveedor y deben evaluarse como una dependencia separada.

Esa última propiedad de inferencia es la que las APIs de LLM en la nube estructuralmente no pueden replicar. No hace que un producto on-premises sea automáticamente conforme ni elimina la necesidad de evaluar su plano de control, rutas de soporte, cadena de suministro del modelo y responsabilidades operativas del cliente.

El trasfondo de cómo construimos esto desde el inicio está en Por qué entregamos AI como binarios instalables, no como SaaS en la nube. Las capacidades que implementan la auditoría, identidad y superficie de políticas residen en AI Admin Console.

Referencias

  1. Comisión Europea. "AI Act — Marco regulatorio sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultado el 15-06-2026.
  2. Comisión Europea. "Entrada en vigor del AI Act." https://digital-strategy.ec.europa.eu/. Accedido el 15-06-2026.
  3. Stanford HAI. "Informe del Índice de IA." https://aiindex.stanford.edu/. Accedido el 15-06-2026.
  4. NIST. "Marco de Gestión de Riesgos de IA (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Accedido el 15-06-2026.
  5. Observatorio de Políticas de IA de la OCDE. "Políticas nacionales de IA." https://oecd.ai/. Accedido el 15-06-2026.