On-Premise vs Auto-Alojado vs Air-Gapped: Cómo Elegir el Despliegue de IA Correcto para Datos Sensibles

Tres términos aparecen constantemente en la documentación de proveedores, listas de verificación de adquisiciones y revisiones de arquitectura: on-premise, auto-alojado y air-gapped. Se usan indistintamente. No deberían usarse así. Cada uno describe un modelo de despliegue significativamente diferente con distintas implicaciones de cumplimiento, distintos costos operativos y distintas garantías sobre dónde van realmente tus datos.

La imprecisión importa porque los proveedores la explotan. Una herramienta comercializada como "compatible con on-premise" podría significar Docker en AWS. Una "opción auto-alojada" podría aún requerir que el servidor de licencias del proveedor se comunique con su servidor al iniciar. "Soporte air-gapped" podría significar que el binario funciona sin internet, pero la documentación de configuración asume conectividad de red para actualizaciones.

Este artículo define cada término con precisión, explica las implicaciones de cumplimiento de cada modelo de despliegue y ofrece orientación práctica para elegir el correcto según tu contexto regulatorio.

Definiciones Precisas

On-Premise

On-premise significa que el software se ejecuta en hardware que tu organización posee o alquila, en una ubicación física que tú controlas: tu edificio, tu sala de servidores, tu centro de datos. El hardware es tuyo. El espacio físico es tuyo. El tráfico de red permanece dentro de tu perímetro.

Característica clave: el centro de datos es tuyo. Los servidores son tuyos (o alquilados bajo tu control). No estás alquilando cómputo de un proveedor en la nube. Los despliegues en AWS, Azure y GCP nunca son on-premise, sin importar cuánto control tengas sobre la configuración.

Esto importa porque los requisitos de soberanía de datos en algunos marcos regulatorios se preocupan específicamente por la propiedad de la infraestructura física y la jurisdicción, no solo por el control de acceso lógico.

Auto-Alojado

Auto-alojado significa que tu equipo gestiona el despliegue, incluyendo instalación, configuración, actualizaciones y mantenimiento. La distinción crítica con on-premise: auto-alojado no dice nada sobre dónde vive la infraestructura. Docker en AWS EC2 es auto-alojado. Kubernetes en GKE es auto-alojado. Un VPS en Hetzner es auto-alojado. Ninguno de estos es on-premise.

Auto-alojado implica responsabilidad operativa, no propiedad de infraestructura. Tu equipo ejecuta el software, no el proveedor. Pero el hardware físico puede ser propiedad de Amazon, Microsoft, Google u otro proveedor en la nube en un centro de datos en cualquier jurisdicción.

Aquí es donde la brecha terminológica de los proveedores es más dañina. Muchas herramientas se comercializan como "auto-alojadas" como si eso implicara las garantías de privacidad de un despliegue on-premise. No es así. Un despliegue auto-alojado en un proveedor de nube significa que tus datos residen en hardware propiedad de ese proveedor, sujeto a los acuerdos de datos de ese proveedor, potencialmente accesible bajo el proceso legal de esa jurisdicción.

Air-Gapped

Air-gapped significa sin conectividad de red en tiempo de ejecución. El sistema está física o lógicamente aislado de redes externas, incluyendo internet, servidores de actualización del proveedor y endpoints de validación de licencias. Los datos no pueden entrar ni salir del sistema a través de una conexión de red porque no existe conexión de red durante la operación.

Air-gapped es el modelo de despliegue más restrictivo y proporciona la garantía más fuerte contra la exfiltración de datos a través de canales de red. Es obligatorio en algunos contextos de defensa, inteligencia e infraestructura crítica, y cada vez más relevante en contextos de salud y finanzas donde la sensibilidad de los datos justifica la complejidad operativa.

Nota: air-gapped no significa que nunca haya red. Significa que la red está ausente o aislada en tiempo de ejecución, cuando se procesan los datos sensibles. Las actualizaciones, parches e instalación inicial típicamente ocurren en redes separadas o a través de medios físicos (USB, disco óptico) bajo procedimientos controlados.

Por Qué los Proveedores Difuminan Estas Distinciones

El incentivo de marketing es directo: "auto-alojado" suena como "on-premise" para compradores que no han pensado cuidadosamente en la distinción, y "auto-alojado" es mucho más fácil de construir y vender que un software genuinamente on-premise o air-gapped.

El software genuinamente on-premise debe funcionar sin dependencias de la nube: sin servidores de licencias, sin telemetría, sin verificaciones de actualización, sin activos alojados en CDN. Debe ser empaquetable para distribución interna, instalable en redes sin conectividad a internet, y mantenible sin acceso del proveedor a la infraestructura. Esto es más costoso de construir.

El software air-gapped debe ir más allá: sin suposiciones de conectividad de red en ningún momento durante la operación, sin búsquedas DNS, sin llamadas a API externas, sin URLs de CDN codificadas, sin servicios en segundo plano que intenten alcanzar internet. Muchas herramientas de software que afirman soporte air-gap fallan en la práctica porque una dependencia en algún lugar del stack intenta alcanzar un endpoint externo.

Al evaluar las afirmaciones de los proveedores, las preguntas correctas son:

• ¿El software hace alguna llamada de red durante la operación? ¿Puedes verificar esto?
• ¿La validación de licencia requiere conectividad a un servidor del proveedor?
• ¿El software transmite telemetría, informes de errores o datos de uso?
• ¿El software funcionará sin ninguna conectividad a internet durante 90 días sin intervención manual?
• ¿Qué pasa cuando no puede alcanzar un servidor de actualizaciones: se degrada o falla?

Implicaciones de Cumplimiento por Modelo de Despliegue

GDPR y Restricciones de Transferencia de Datos

El Capítulo V del GDPR restringe las transferencias de datos personales a terceros países (países fuera de la UE/EEE) que no tienen una decisión de adecuación. Ejecutar una carga de trabajo en AWS EU-West-1 (Irlanda) puede satisfacer los requisitos de residencia de datos del GDPR, pero es un despliegue auto-alojado, no on-premise. Los datos residen en hardware de AWS, y AWS es una empresa con sede en EE.UU. sujeta al proceso legal de EE.UU. bajo marcos como el CLOUD Act.

Si esto es aceptable depende de tus datos específicos, la interpretación de tu equipo legal y la tolerancia al riesgo de tu organización. Lo que no es, es equivalente al almacenamiento on-premise bajo tu control físico.

Para organizaciones sujetas a requisitos de soberanía de datos nacionales más estrictos que la línea base del GDPR (regulaciones BSI alemanas, requisitos SecNumCloud franceses, ciertos mandatos de agencias gubernamentales) "auto-alojado en nube europea" puede no satisfacer el requisito. Solo el hardware bajo tu control físico los satisface.

HIPAA: Entidades Cubiertas y Socios Comerciales

Bajo HIPAA, cuando usas un proveedor de servicios en la nube para almacenar o procesar PHI, ese proveedor se convierte en un Socio Comercial. Se requiere un Acuerdo de Socio Comercial (BAA). La existencia de un BAA significa que los datos fluyen hacia ese proveedor: tienen obligaciones contractuales al respecto, pero los reciben.

Auto-alojado en una nube que proporciona un BAA (AWS, Azure y GCP lo hacen) satisface el requisito de BAA de HIPAA. Pero los datos aún viven en el hardware del proveedor de nube. El proveedor de nube aún puede recibir demandas legales por datos bajo la ley de EE.UU. Sus empleados (bajo controles estrictos) aún pueden acceder a la infraestructura donde se ejecutan tus datos.

El despliegue on-premise significa que la PHI nunca llega a la infraestructura de un proveedor de nube. No hay BAA que negociar porque no hay procesador externo. Para los datos clínicos más sensibles, particularmente en contextos de investigación donde la privacidad del paciente es primordial, esta es una postura significativamente diferente.

El despliegue on-premise air-gapped va más allá: no hay ruta de red a través de la cual la PHI pueda ser exfiltrada, ni siquiera accidentalmente. Este es el modelo apropiado para los entornos de investigación clínica de mayor sensibilidad.

Artículo 10 de la Ley de IA de la UE: Gobernanza de Datos de Entrenamiento

Los requisitos del Artículo 10 de la Ley de IA de la UE para sistemas de IA de alto riesgo incluyen obligaciones de gobernanza de datos a lo largo de todo el ciclo de vida de los datos de entrenamiento. La regulación requiere que los proveedores documenten los procesos de recolección, preparación, etiquetado y aseguramiento de calidad de datos.

Esto no es un requisito de modelo de despliegue per se: es un requisito de documentación y gobernanza. Pero el modelo de despliegue afecta tu capacidad para satisfacerlo. Si tu preparación de datos de entrenamiento ocurre en una plataforma de nube con infraestructura compartida, reconstruir un rastro de auditoría completo de decisiones de manejo de datos es más difícil que si todo el pipeline se ejecuta en infraestructura que tú controlas y registras completamente.

Para organizaciones basadas en la UE que construyen sistemas de IA de alto riesgo, el despliegue on-premise del pipeline de preparación de datos (no solo el paso de entrenamiento del modelo) hace que la obligación de documentación del Artículo 10 sea más manejable.

Servicios Financieros: FCA, DORA y Residencia de Datos

Los reguladores de servicios financieros en el Reino Unido (FCA), la UE (DORA) y EE.UU. (OCC, FINRA) tienen requisitos variados sobre dónde pueden residir los datos financieros y cómo debe mantenerse la continuidad operativa. DORA aborda específicamente la gestión de riesgos de TIC y requiere que las entidades financieras mantengan control sobre sus dependencias críticas de TIC.

El despliegue en la nube para servicios financieros está permitido bajo la mayoría de estos marcos, pero requiere términos contractuales específicos, estrategias de salida y documentación de resiliencia operativa. Para los datos más sensibles (algoritmos de trading, modelos de crédito, registros financieros de clientes) algunas instituciones eligen el despliegue on-premise para mantener un control inequívoco.

Requisitos Air-Gapped: Defensa e Infraestructura Crítica

Los contratistas de defensa, proveedores de la comunidad de inteligencia y operadores de infraestructura crítica (redes eléctricas, sistemas de agua, sistemas de salud) pueden estar obligados a operar sistemas de IA en entornos clasificados o compartimentados sensibles. Estos entornos están físicamente aislados de redes no clasificadas por diseño.

En estos contextos, "auto-alojado en una nube gubernamental" (GovCloud, C2S, etc.) no es air-gapped: sigue siendo infraestructura con conexión de red. El verdadero air-gap significa que el sistema se ejecuta en hardware sin conexión de red externa, y los datos se mueven a través de medios físicos controlados bajo procedimientos documentados de cadena de custodia.

El software que afirma soporte air-gap para estos entornos debe ser probado, no confiado. Los modos de fallo comunes incluyen verificaciones de activación/licencias al iniciar, telemetría que intenta comunicarse y expira, y bibliotecas de dependencias que hacen búsquedas DNS.

Tabla Comparativa

Orientación Práctica por Contexto Regulatorio

Entidades cubiertas por HIPAA que procesan PHI para entrenamiento de IA: Auto-alojado en una nube cubierta por BAA de HIPAA es técnicamente conforme, pero significa que la PHI llega a la infraestructura del proveedor de nube. On-premise es más limpio. On-premise air-gapped es apropiado para los datos de investigación más sensibles.

Organizaciones de la UE sujetas a GDPR y Ley de IA de la UE: Auto-alojado en nube de región europea satisface la mayoría de los requisitos para datos no soberanos. Para contextos de seguridad nacional o sectores con mandatos de soberanía de datos más estrictos (investigación en salud, sistemas de IA gubernamentales), on-premise es apropiado.

Instituciones financieras con requisitos de gestión de riesgo de modelos: La nube con contratos apropiados y documentación de resiliencia operativa es aceptable para la mayoría de los marcos regulatorios. Para modelos propietarios donde la sensibilidad competitiva es extrema, on-premise es preferible.

Contratistas de defensa y agencias gubernamentales con requisitos clasificados: Solo air-gapped. Los entornos auto-alojados y on-premise con red no son equivalentes a los requisitos de instalaciones clasificadas.

Servicios legales (privilegio y confidencialidad): Auto-alojado en tu propia infraestructura suele ser suficiente. On-premise proporciona argumentos de privilegio más limpios (los datos nunca salen del control físico del despacho). Air-gapped raramente es requerido pero existe en contextos legales de seguridad nacional.

Qué Preguntar a los Proveedores

Cuando un proveedor te dice que su herramienta soporta tu modelo de despliegue, pregunta:

1. "¿El software hace alguna conexión de red saliente durante la operación?" Obtén una respuesta específica, no "se puede configurar para funcionar offline."
2. "¿La validación de licencia requiere conectividad a sus servidores?" Si sí, esa es una dependencia de la infraestructura del proveedor.
3. "¿Puede proporcionar documentación de todos los endpoints externos que contacta el software?" Los equipos de seguridad pueden verificar esto con monitoreo de red.
4. "¿Se ha desplegado esto en un entorno air-gapped certificado? ¿Puede proporcionar una referencia?" El soporte air-gap declarado y los despliegues air-gap verificados son diferentes.
5. "¿Cuál es su política de telemetría de datos? ¿Qué datos transmite el software y a dónde?" Esto debe estar documentado en la política de privacidad o DPA, no solo como garantía verbal.

Las respuestas a estas preguntas revelan qué modelo de despliegue realmente soporta una herramienta, independientemente de lo que digan los materiales de marketing.

---

Lecturas Relacionadas

• On-Premise AI Data Preparation for Compliance — Por qué la elección del modelo de despliegue es fundamental para equipos de IA en industrias reguladas
• EU AI Act Article 10: Training Data Requirements — Las obligaciones específicas de gobernanza de datos para sistemas de IA de alto riesgo
• HIPAA-Compliant AI Training Data Guide — Qué requiere realmente HIPAA para flujos de trabajo de datos de entrenamiento de IA
• Air-Gapped Machine Learning Pipelines — Consideraciones prácticas para operar pipelines de ML sin conectividad de red
• Data Sovereignty in Enterprise AI (2026) — Cómo los requisitos de soberanía de datos están moldeando las decisiones de despliegue de IA empresarial