Esta es la versión en español del análisis que publicamos en inglés y en francés sobre el CLOUD Act estadounidense; al final tienes los enlaces a ambas. Aquí va la parte práctica: qué comprobar con un proveedor de IA de Estados Unidos, y qué cambia, y qué no, al mover la inferencia a tu propio equipo.
Empecemos por el uso diario. Copias el correo de un cliente o una tabla con nombres y cifras internas, y lo pegas en un asistente alojado en Estados Unidos. Eso ya es una transferencia internacional: el proveedor pasa a tratar contenido que tú introdujiste, y sus servidores y su jurisdicción están fuera de la Unión. Que el servidor esté en Europa no lo arregla si el acceso desde Estados Unidos sigue siendo posible.
Lo que dice la ley estadounidense, letra por letra
El CLOUD Act, aprobado como Título I de la Ley de Asignaciones Consolidadas de 2018 (Ley Pública 115-141, en marzo de 2018), añadió al capítulo 212 del título 18 del Código de los Estados Unidos una frase que casi todo el mundo resume mal. El texto original en inglés es este, y es el que hay que citar en un expediente:
«Todo proveedor de servicios de comunicaciones electrónicas o de computación remota deberá cumplir las obligaciones de este capítulo de conservar, respaldar o revelar el contenido de una comunicación cable o electrónica y cualquier registro u otra información que conciernan a un cliente o abonado que estén en la posesión, custodia o control de dicho proveedor, con independencia de que dicha comunicación, registro u otra información se encuentre dentro o fuera de los Estados Unidos»., 18 U.S.C. § 2713; traducción propia del texto inglés, que es el que obliga
Es decir: a una empresa estadounidense se la puede obligar a entregar datos que estén en su posesión, custodia o control, estén almacenados dentro o fuera de los Estados Unidos. El servidor europeo no es una frontera legal. Lo único que protege frente a ese acceso es el cauce de defensa que la propia ley prevé: notificar al cliente, darle opción de oponerse y discutir si la solicitud afecta a un abonado no estadounidense sin vínculos suficientes con Estados Unidos.
Qué exige el RGPD, y en qué punto estamos
El capítulo V del RGPD sigue siendo el problema. El TJUE anuló en Schrems II la Decisión del Escudo de Privacidad y validó las cláusulas contractuales; el Comité Europeo de Protección de Datos publicó las Recomendaciones 01/2020 con un itinerario de seis pasos para las transferencias a Estados Unidos: estudiar el destino, identificar la medida legal, ver si hay obstáculos que la impidan, adoptar medidas complementarias y mantenerlas vigiladas en el tiempo. Ese trabajo no se resuelve una vez: es un expediente que hay poder enseñar.
La Decisión de Ejecución (UE) 2023/1795, el DPF para empresas certificadas, sigue vigente mientras se discute: el Tribunal General desestimó el recurso Latombe contra la Comisión (T-553/23) el 3 de septiembre de 2025, sin entrar a valorar la efectividad práctica del régimen y dejando abierta la cuestión de la legitimación. El primer informe periódico de la Comisión sobre el funcionamiento del acuerdo (COM(2024) 451) y el informe del CEPD de 4 de noviembre de 2024 señalaron además problemas persistentes de acceso gubernamental: las autocertificaciones no bastan por sí solas, y los derechos de las personas en la UE dependen de que el proveedor cumpla lo que la Decisión le exige. Y hay un cambio con efectos reales: tras Trump v. Slaughter (29 de junio de 2026, sentencia 6-3), el Tribunal Supremo declaró inconstitucional la cláusula de remoción por causa de la FTC y revirtió el criterio de Humphrey’s Executor; el regulador del que depende la vigilancia del DPF dejó así de ser un organismo independiente en el sentido clásico. Varios bufetes han avisado de que existe una «probabilidad razonable» de que el TJUE anule la Decisión (nota de Skadden, 28 de julio de 2026).
No voy a decir que la Decisión sea inválida: no lo es. Y no hace falta esperar a que caiga para actuar: si hoy dependes del DPF o de cláusulas contractuales con un proveedor estadounidense, necesitas un expediente actualizado, subcontratistas, accesos, plazos, bases de transferencia, y una respuesta preparada ante una posible anulación. Eso es lo que casi ninguna empresa tiene hecho.
Qué hay que comprobar de verdad con un proveedor de IA de EE. UU.
Esta es la lista que yo usaría antes de meter los datos de un cliente en un asistente extranjero; la entrada en inglés desarrolla esa misma lista con detalle:
- Base de transferencia real (DPF si el proveedor está certificado, o cláusulas contractuales con su estudio
del destino), no la primera frase del contrato de autoservicio.
- Subcontratistas y accesos: quién accede desde dónde, qué se conserva, cuánto tiempo, y si el proveedor puede
ver lo que escribes para entrenar modelos.
- Cierre de la salida: una vez generada la respuesta, ¿el contenido se queda en el proveedor, en sus registros,
o viaja a terceros? ¿Puedes suprimirlo y en qué plazo?
- Trabajar con datos mínimos: si la tarea no necesita nombres reales, usa un entorno de pruebas, marcas falsas y
números inventados. Es gratis, y reduce el problema a su menor expresión.
Ninguna de estas cuatro cosas se arregla con el márketing del proveedor: se arreglan con tu documentación y con una decisión documentada sobre qué tipo de datos no van a salir de casa.
Qué cambia la IA local privada, y qué no
Aquí es importante decirlo con precisión para que no venda humo.
Sí cambia la transferencia: si el modelo se ejecuta en un servidor tuyo, no hay proveedor estadounidense que reciba tu prompt. El texto del cliente no viaja a una jurisdicción extranjera, no entra en el sistema de un tercero, y por tanto desaparece el problema del capítulo V para ese flujo concreto: no hace falta notificar a nadie, ni firmar cláusulas, ni escribir un estudio del destino. El dato no sale.
No cambia lo demás: la base jurídica del tratamiento, la minimización, la seguridad, los plazos de conservación y el control de accesos siguen siendo tuyos. Un modelo local no convierte en lícito un uso que no lo era; si tu obligación es cumplir los contratos con tus clientes, el modelo local te da más control sobre ese cumplimiento, pero no lo ejecuta solo.
Tampoco mejora cualquier tarea: los modelos abiertos pequeños y medianos, los que puedes alojar en tu propio hardware, rinden bien en resumen, clasificación, extracción a formato fijo, búsqueda semántica sobre tus documentos y traducción técnica; no son lo mismo que un modelo cerrado puntero para razonamiento largo o para código complejo con miles de tokens. La decisión honesta es por tarea:
- Redacción y revisión interna, resúmenes, clasificación de documentos, RAG sobre tu documentación: un modelo
local bien cuantizado en una GPU de sobremesa rinde suficiente. Aquí la ventaja no es el estado del arte: es que el dato no se mueve.
- Código complejo, agentes con muchas herramientas, análisis largos: ahí un proveedor extranjero sigue dando otra
respuesta; si usas uno, que sea un plan empresarial con contrato de tratamiento de datos y expediente de transferencia hechos, no una cuenta personal.
- Datos sensibles de clientes (salud, nóminas, contratos, expedientes: la regla simple es no subir nada al
proveedor; usa el modelo local o un entorno aislado.
Y hay una ventaja que casi nadie menciona en los folletos legales: el coste y la latencia de una tarea que haces miles de veces. Un flujo local en tu infraestructura, por ejemplo, un servicio de inferencia en un equipo con una GPU razonable, no factura por token ni depende de la disponibilidad del proveedor; si el proceso es repetible, el coste de cada iteración queda en cero después de la primera inversión. Es un argumento operativo, no jurídico, pero es el que hace que la decisión se tome en la práctica.
La lista que yo usaría, en orden
- Inventario rápido: qué herramientas de IA usan tus equipos y con qué contenido; si eso no está escrito, ya hay una
transferencia sin expediente.
- Para lo que sí sale de casa: expediente de transferencia completo y al día (base legal, subcontratistas, plazos,
accesos desde Estados Unidos) y una respuesta preparada ante la posible anulación del DPF.
- Para lo que puede hacerse en casa: prueba un modelo local con tus tareas reales (resumen, RAG, clasificación) y
decide con datos de verdad, no con la demostración del proveedor.
- Reglas escritas para el personal: qué tipo de dato no se sube a un servicio extranjero, y alternativas sin
fricción (un entorno propio, un modelo local, datos anonimizados).
- Documentación: deja probado qué decidiste y por qué; un estudio del destino sin fecha ni responsable que lo firme
no sirve ante una reclamación.
Si todo esto te parece una carga legal, lo es. Pero la parte técnica es más sencilla de lo que parece: un modelo abierto en tu equipo, con tus documentos dentro, reduce el problema a su forma real (menos transferencia, menos terceros, menos dependencias). Y si además sale más barato por tarea repetida, la decisión se toma sola.
Sobre el papeleo, nuestra propia página de privacidad lo resume en una frase que describe la ventaja operativa de un servidor propio: «el límite de auditoría es tu edificio: sin subcontratistas en la nube dentro del perímetro, sin transferencia a terceros de datos médicos o de personal, las garantías HIPAA y los controles ISO/IEC 27001 se demuestran en tu sede, no en la documentación del proveedor».
Versiones en otros idiomas
- Versión en inglés, está la lista de comprobación completa y las fuentes citadas.
- Versión en francés
Fuentes
- 18 U.S.C. § 2713, texto original en inglés (posesión, custodia o control, con independencia de dónde estén los
datos): https://www.law.cornell.edu/uscode/text/18/2713
- CLOUD Act, Título I de la Ley de Asignaciones Consolidadas de 2018 (Ley Pública 115-141):
https://en.wikipedia.org/wiki/CLOUD_Act
- Recomendaciones 01/2020 del CEPD sobre las medidas complementarias de las herramientas de transferencia:
https://www.edpb.europa.eu/system/files/2021-06/edpbrecommendations202001vo.2.0supplementarymeasurestransferstoolsen.pdf
- Decisión de Ejecución (UE) 2023/1795 de la Comisión, relativa al DPF UE-EE. UU.:
https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj/eng
- Informe de la Comisión sobre el funcionamiento del DPF (COM(2024) 451):
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A52024DC0451
- Informe del CEPD sobre la primera revisión del DPF, 4 de noviembre de 2024:
https://www.edpb.europa.eu/system/files/documents/2024-11/edpbreport20241104reportonfirstreviewofeu-u.s.dpfen.pdf
- Sentencia Trump v. Slaughter, 29 de junio de 2026 (texto oficial en PDF), y comentario del bufete Venable:
https://www.supremecourt.gov/opinions/25pdf/25-332_qn12.pdf y https://www.venable.com/insights/publications/2026/06/supreme-court-overrules-humphreys-executor
- Nota de Skadden sobre la consecuencia para el DPF tras esa sentencia (28 de julio de 2026):
https://www.skadden.com/insights/publications/2026/07/supreme-court-decision-raises-new-questions
- Análisis del CITIP de la Universidad de Lovaina sobre lo que realmente dice la desestimación de Latombe
(T-553/23, 3 de septiembre de 2025): https://www.law.kuleuven.be/citip/blog/eu-us-data-transfers-survive-what-latombe-really-tells-us/
Leave a Reply