)
¿Qué es la IA soberana para las industrias reguladas?
La IA soberana para industrias reguladas significa desplegar sistemas de IA en infraestructura que satisfaga los requisitos legales de cada sector en materia de localización de datos, control de acceso, auditabilidad y autoridad jurisdiccional.
Las finanzas exigen que los sistemas de IA cumplan los estándares de resiliencia y retención de DORA y MiFID II. La sanidad exige un procesamiento conforme con HIPAA y, para la IA clínica, la supervisión de la FDA sobre las decisiones algorítmicas. La administración pública exige la autorización FedRAMP y los controles NIST SP 800-53 para cualquier IA que maneje datos federales o clasificados.
Los tres sectores comparten un requisito común: la propia infraestructura de IA, no solo las políticas de datos, debe estar libre de accesos extranjeros no autorizados.
TL;DR - Puntos clave
- "Gobernanza de IA empresarial" no es un único problema. Las finanzas, la sanidad y la administración pública tienen distintos reguladores, distintas sanciones y distintas restricciones técnicas.
- DORA (Reglamento (UE) 2022/2554) es aplicable a las entidades financieras desde enero de 2025 y regula directamente los sistemas de IA clasificados como sistemas TIC críticos o importantes.
- HIPAA no distingue entre IA y software tradicional: si procesa información sanitaria protegida (PHI), se aplican las mismas salvaguardas técnicas del 45 CFR 164.312.
- La autorización FedRAMP es obligatoria para cualquier sistema de IA alojado en la nube que procese datos del gobierno federal de EE. UU. Sin FedRAMP, no hay despliegue posible.
- El Reglamento de IA de la UE (Reglamento (UE) 2024/1689), Anexo III, clasifica los sistemas de IA en puntuación crediticia, software de dispositivos médicos y aplicación de la ley como de alto riesgo, añadiendo una capa de gobernanza obligatoria sobre las normas sectoriales específicas.
- Los tres sectores exigen un registro de auditoría de las decisiones de IA. Ni resúmenes ni logs de aplicación, sino registros de auditoría a nivel de decisión con entrada, salida y versión del modelo documentadas.
Tres industrias. Tres regímenes regulatorios. Un problema compartido: todas necesitan IA que funcione donde puedan controlarla, auditarla y demostrar a un regulador que se ha comportado correctamente. Las finanzas se preocupan por DORA y MiFID II. La sanidad se preocupa por HIPAA y la guía de la FDA. La administración pública se preocupa por FedRAMP y los datos clasificados.
La respuesta técnica es la misma en los tres casos: infraestructura soberana, aplicación en tiempo de ejecución y registros de auditoría documentados. El marco regulatorio es diferente en cada caso.
)
Todo el mundo trata el cumplimiento de IA como un único problema. Son tres.
Escucho "cumplimiento de IA" como una única categoría constantemente. Los CISO lo hablan como si existiera un único marco, una única lista de verificación, una única respuesta.
No es así.
Un banco que utiliza un LLM para la detección de fraudes tiene un problema de cumplimiento diferente al de un hospital que usa IA para diagnóstico por imagen, y diferente también al de una agencia gubernamental que ejecuta NLP sobre registros ciudadanos. Los principios subyacentes de soberanía de datos se solapan. Las normas específicas no.
Este artículo lo desglosa por sector. Finanzas primero. Luego sanidad. Luego administración pública. Para cada uno: cuáles son las normas reales, qué exigen técnicamente y cómo es un despliegue de IA soberana en la práctica.
Si quieres la teoría de base, empieza con La guía completa de soberanía de datos para IA empresarial. Este artículo asume que ya sabes por qué importa la soberanía y quieres el detalle específico por sector.
)
Finanzas: DORA, MiFID II y el problema del registro de auditoría
El sector financiero obtuvo su marco de gobernanza de IA antes de que la mayoría de los sectores supiera que lo necesitaba.
DORA (Ley de Resiliencia Operativa Digital, Reglamento (UE) 2022/2554) está en vigor desde enero de 2025. Se aplica a bancos, entidades de pago, empresas de inversión y una larga lista de otras entidades financieras que operan en la UE. DORA trata los sistemas de IA clasificados como funciones TIC críticas o importantes como infraestructura regulada. Eso significa requisitos de pruebas, notificación de incidentes, gestión de riesgos de terceros y obligaciones de continuidad operativa.
El artículo 28 de DORA regula el riesgo TIC de terceros. Si tu sistema de IA funciona en un proveedor de nube externo, ese proveedor está sujeto a los requisitos de supervisión de DORA. No solo tus políticas. La infraestructura del proveedor, la documentación de resiliencia y los términos contractuales deben satisfacer DORA.
MiFID II (Directiva 2014/65/UE) añade un ángulo de retención de datos. El artículo 25 exige a las entidades retener registros de transacciones y órdenes de clientes durante cinco años, y hasta siete en algunas jurisdicciones. Si un sistema de IA tomó o influyó en una decisión de negociación, esa decisión debe poder reconstruirse. Necesitas los datos de entrada, la versión del modelo, el output y la marca de tiempo.
Eso no es una cuestión de política. Es una cuestión de infraestructura.
¿Cómo es la IA soberana en finanzas?
Despliegue en local o en nube privada para los sistemas de IA que afectan a decisiones de negociación, puntuación crediticia y detección de fraudes. Enrutamiento de datos con alcance jurisdiccional para que ningún dato financiero de la UE transite por infraestructura de nube de EE. UU. a menos que haya cobertura legal documentada. Registros de auditoría inmutables en la capa de inferencia: no logs de aplicación, sino registros a nivel de modelo de entrada, salida y versión. El Anexo III del Reglamento de IA de la UE también clasifica los sistemas de IA para puntuación crediticia como de alto riesgo, añadiendo requisitos de evaluación de conformidad además de DORA.
Cómo los AI Gateways ayudan a mantener la soberanía de datos cubre la arquitectura de aplicación del enrutamiento que hace esto viable sin reconstruir toda la infraestructura.
Sanidad: HIPAA, guía de IA de la FDA y la brecha de soberanía de la que nadie habla
La sanidad tiene un problema diferente al de las finanzas. Los datos son más sensibles. Las consecuencias son mayores. Y el marco regulatorio no fue diseñado pensando en la IA.
HIPAA (Health Insurance Portability and Accountability Act, 45 CFR Partes 160 y 164) no tiene una categoría especial para la IA. No la necesita. Si tu sistema de IA procesa información sanitaria protegida (PHI), se aplican las salvaguardas técnicas de la Regla de Seguridad del 45 CFR 164.312. Controles de acceso. Controles de auditoría. Integridad. Seguridad en la transmisión.
Parece manejable. Aquí es donde se complica.
La mayoría de los LLM y modelos fundacionales están alojados por proveedores de nube de EE. UU. o de la UE. En el momento en que envías un registro de paciente a un endpoint LLM externo para su procesamiento, incluso para algo tan básico como resumir notas clínicas, se trata de una transmisión de datos HIPAA. Necesitas un Business Associate Agreement (BAA) con ese proveedor. Necesitas verificar que maneja la PHI en condiciones conformes con HIPAA. Y si la infraestructura del proveedor está sujeta a la jurisdicción de la CLOUD Act de EE. UU., tienes una exposición de soberanía que un BAA por sí solo no soluciona.
La FDA añade una segunda capa para la IA clínica. La guía de la agencia sobre Software de IA/ML como Dispositivo Médico (SaMD) trata los algoritmos de IA adaptativos utilizados en apoyo a la decisión clínica como software médico regulado. Un modelo que cambia su comportamiento con el tiempo, que es lo que hacen la mayoría de los sistemas ML en producción, requiere un Plan de Control de Cambios Predeterminado. Debes documentar qué puede cambiar, bajo qué condiciones y cómo se valida el cambio antes de que llegue a los pacientes.
¿Cómo es la IA soberana en sanidad?
Inferencia en local para la IA clínica que maneja PHI. BAA con todos los proveedores de IA externos. Detección de PII y PHI en la capa de entrada antes de que ningún dato llegue a un endpoint externo. Registros de auditoría a nivel de decisión que registran la versión del modelo, las características de entrada y la recomendación de salida para cualquier sistema de IA que influya en decisiones clínicas. Para las organizaciones sanitarias de la UE, el Reglamento de IA de la UE clasifica los sistemas de IA utilizados en dispositivos médicos bajo el Anexo III como de alto riesgo, lo que requiere una evaluación de conformidad antes del despliegue.
La arquitectura práctica: un AI gateway que detecta y enmascara la PHI antes del enrutamiento, combinado con monitorización en tiempo de ejecución que marca cualquier anomalía en los outputs que pueda indicar una desviación del modelo. Mejores prácticas de soberanía de datos para aplicaciones RAG cubre los controles específicos para sistemas de IA que recuperan información de bases de conocimiento clínico.
Administración pública: FedRAMP, NIST SP 800-53 y el problema de los datos clasificados
La administración pública es el sector más estricto de los tres. Y el más fragmentado.
FedRAMP (Federal Risk and Authorization Management Program) es la base para cualquier servicio alojado en la nube utilizado por agencias federales de EE. UU. Si tu producto de IA es de nube y una agencia federal de EE. UU. quiere desplegarlo, la autorización FedRAMP es el requisito de entrada. El proceso de autorización evalúa los controles de NIST SP 800-53 y puede tardar entre 12 y 18 meses. No hay atajo.
NIST SP 800-53 Rev 5 tiene 20 familias de controles. Las más relevantes para los sistemas de IA son SI (Integridad del Sistema y la Información), PT (Procesamiento de Información de Identificación Personal y Transparencia) y AC (Control de Acceso). SI-19 cubre los requisitos de desidentificación. PT-3 cubre la transparencia en el procesamiento de información de identificación personal. Estos controles no son directrices aspiracionales. Son requisitos binarios para el despliegue federal.
Para los sistemas de IA que manejan datos clasificados, los requisitos se elevan significativamente. Las cargas de trabajo de IA clasificadas requieren personal con habilitación de seguridad, infraestructura con espacio de aire y, en muchos casos, entornos de computación soberana específicos. El concepto de "IA soberana" comenzó precisamente en contextos de seguridad nacional porque el riesgo de acceso extranjero a los outputs de inferencia clasificados no es teórico.
El equivalente europeo es un mosaico: las agencias de seguridad nacional aplican sus propios marcos. La ANSSI francesa, el BSI alemán y el NCSC del Reino Unido publican guías de seguridad de IA con requisitos de infraestructura que superan los estándares de nube comercial.
¿Cómo es la IA soberana en la administración pública?
Despliegue en local o en nube privada gubernamental para cualquier sistema de IA que maneje Información No Clasificada Controlada (CUI) o datos clasificados. Proveedores autorizados por FedRAMP para cargas de trabajo adyacentes a la nube. Documentación del cumplimiento de los controles NIST SP 800-53 para todos los sistemas de IA. Arquitectura de red de confianza cero con los nodos de inferencia de IA tratados como activos de alto valor. Para los despliegues gubernamentales en la UE, Requisitos de soberanía de datos en el Reglamento de IA de la UE cubre las obligaciones aplicables de los artículos 10 y 12 para los sistemas de IA utilizados en la administración pública.
)
Comparativa intersectorial
| Dimensión | Finanzas | Sanidad | Administración pública |
|---|---|---|---|
| Regulación principal | DORA, MiFID II, Reglamento de IA de la UE Anexo III | HIPAA, guía SaMD de la FDA, Reglamento de IA de la UE Anexo III | FedRAMP, NIST SP 800-53, marcos nacionales sectoriales |
| Clasificación de datos | Datos de transacciones financieras, registros de negociación | Información Sanitaria Protegida (PHI) | CUI, datos clasificados, registros ciudadanos |
| Clasificación de riesgo IA (Reglamento de IA de la UE) | Alto riesgo: puntuación crediticia, detección de fraude | Alto riesgo: dispositivos médicos, apoyo a la decisión clínica | Alto riesgo: aplicación de la ley, administración pública, control fronterizo |
| Requisito de registro de auditoría | Reconstrucción de transacciones (5 a 7 años) | Auditoría de decisiones clínicas con versión del modelo | Logs de acceso, registros de inferencia, documentación de cambios |
| Restricción de despliegue | Jurisdicción UE para datos financieros de la UE | BAA obligatorio para el procesamiento de PHI; despliegue local para IA clínica | Autorización FedRAMP; despliegue local o en nube gubernamental para CUI |
| Requisito de riesgo de terceros | Supervisión del proveedor TIC por DORA Artículo 28 | BAA con todos los proveedores de IA que manejan PHI | Cadena de autorización FedRAMP |
Lo que comparten los tres sectores
Normas diferentes. El mismo requisito de arquitectura subyacente.
Toda industria regulada necesita: una capa de aplicación en tiempo de ejecución que monitorice las entradas y salidas de IA, un enrutamiento con consciencia jurisdiccional que mantenga los datos dentro de los límites autorizados, registros de auditoría de nivel de inferencia, y pruebas previas al despliegue que documenten el riesgo antes de que un modelo entre en producción.
Para eso están diseñados TrustGuard, TrustGate, TrustLens y TrustTest de NeuralTrust. No para un sector. Para los tres.
TrustGate gestiona el enrutamiento y la detección de PII. TrustGuard gestiona la aplicación de políticas en tiempo de ejecución y la detección de anomalías. TrustLens mapea los sistemas de IA que se ejecutan en tu entorno. TrustTest ejecuta pruebas adversariales antes del despliegue.
Para las decisiones de arquitectura que hay detrás del despliegue soberano, consulta Cómo construir una arquitectura de IA soberana y On-Prem vs Nube Privada vs Nube Pública para IA Soberana.
FAQs acerca de la IA Soberana para Industrias Reguladas
1. ¿Cuáles son los requisitos de IA soberana para los servicios financieros?
Las instituciones financieras en la UE deben cumplir con DORA (Reglamento (UE) 2022/2554) para los sistemas de IA clasificados como funciones TIC críticas o importantes. Esto incluye pruebas de resiliencia, supervisión de proveedores TIC externos bajo el artículo 28 y notificación de incidentes. MiFID II exige la reconstrucción de las decisiones de negociación influenciadas por IA durante hasta siete años. El Reglamento de IA de la UE Anexo III clasifica la puntuación crediticia y la detección de fraudes como de alto riesgo, añadiendo requisitos de evaluación de conformidad. El requisito técnico: despliegue en local o en nube privada con alcance jurisdiccional, con registros de auditoría inmutables en la capa de inferencia.
2. ¿Cuáles son los requisitos de cumplimiento de IA para la sanidad?
HIPAA se aplica a cualquier sistema de IA que procese información sanitaria protegida (PHI), exigiendo salvaguardas técnicas bajo el 45 CFR 164.312: controles de acceso, controles de auditoría, controles de integridad y seguridad en la transmisión. Todos los proveedores de IA externos que manejan PHI necesitan un Business Associate Agreement. La guía de la FDA sobre Software de IA/ML como Dispositivo Médico añade requisitos regulatorios para los sistemas de IA clínica que se adaptan con el tiempo, incluyendo Planes de Control de Cambios Predeterminados. Las organizaciones sanitarias de la UE se enfrentan a la clasificación de alto riesgo del Reglamento de IA de la UE Anexo III para la IA en dispositivos médicos.
3. ¿Necesita una agencia gubernamental FedRAMP para usar IA?
Para las agencias federales de EE. UU., sí. Cualquier sistema de IA alojado en la nube utilizado por una agencia federal requiere autorización FedRAMP. FedRAMP evalúa los controles de NIST SP 800-53 y el proceso de autorización suele tardar entre 12 y 18 meses. Los sistemas de IA que manejan Información No Clasificada Controlada (CUI) tienen requisitos adicionales bajo los controles SI-19 y PT-3 de NIST SP 800-53. Para las cargas de trabajo clasificadas, se requiere infraestructura con espacio de aire y personal con habilitación de seguridad, independientemente del estado FedRAMP.
4. ¿Cómo interactúa el Reglamento de IA de la UE con las regulaciones sectoriales específicas?
El Reglamento de IA de la UE no sustituye las regulaciones sectoriales específicas. Se suma a ellas. El Anexo III identifica categorías de IA de alto riesgo, incluyendo la puntuación crediticia (finanzas), el software de dispositivos médicos (sanidad) y la aplicación de la ley y la administración pública (gobierno). Para los sistemas en estas categorías, el Reglamento de IA de la UE añade requisitos de gobernanza de datos (artículo 10), requisitos de transparencia y registro (artículo 12) y disposiciones de supervisión humana (artículo 14) además de las normas de DORA, el equivalente a HIPAA o las normas de seguridad nacional que ya se apliquen.
5. ¿Cuál es la diferencia entre residencia de datos e IA soberana para las industrias reguladas?
La residencia de datos significa almacenar datos en una ubicación geográfica específica. La IA soberana va más lejos: significa que la propia infraestructura de IA, incluido el modelo, el cómputo de inferencia y los logs de output, debe operar bajo una autoridad legal definida y estar libre de accesos extranjeros no autorizados. Una institución financiera puede almacenar datos en un centro de datos de la UE (residencia de datos) y aun así tener una brecha de IA soberana si la inferencia se ejecuta en infraestructura de nube con sede en EE. UU. sujeta a la jurisdicción de la CLOUD Act. Consulta Soberanía de datos vs Residencia de datos vs Localización de datos para la distinción completa.
Artículos relacionados
- La guía completa de soberanía de datos para IA empresarial (2026)
- Soberanía de datos vs Residencia de datos vs Localización de datos
- Soberanía de datos en IA: Por qué las empresas la necesitan antes de desplegar LLMs
- Cómo construir una arquitectura de IA soberana
- Requisitos de soberanía de datos en el Reglamento de IA de la UE
- Cómo los AI Gateways ayudan a mantener la soberanía de datos
- On-Prem vs Nube Privada vs Nube Pública para IA Soberana
- Mejores prácticas de soberanía de datos para aplicaciones RAG
- Privacidad de datos de IA vs Soberanía de datos: ¿Cuál es la diferencia?
- Checklist de soberanía de datos para CISOs empresariales (2026)
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización LLM. Está especializado en búsqueda potenciada por IA, estrategia de contenido, desarrollo de backlinks y SEM. Conéctate en LinkedIn.
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en el Gartner Hype Cycle for Application Security 2026, el Gartner Hype Cycle for Infrastructure Security 2026, la Guía de mercado de Gartner 2025 para AI Gateways y Agentes Guardianes y el Compás de liderazgo KuppingerCole 2025 para Defensa de IA Generativa. Certificada ISO 27001. Con sede en Barcelona.