Fine-Tuning Privado de IA bajo el RGPD sin Clúster de GPUs
Adapta IA con datos de clientes bajo el RGPD sin GPUs propias. Cuándo RAG supera al fine-tuning, qué exige la ley y cómo servir con residencia en UE/LATAM.
Fine-Tuning Privado de IA bajo el RGPD sin Clúster de GPUs Propio
Sí, puedes hacer fine-tuning de IA con datos de clientes bajo el RGPD sin comprar una sola GPU. La ruta más rápida, económica y conforme para la mayoría de los equipos no es el fine-tuning en absoluto: la generación aumentada por recuperación (RAG) alcanza el mismo resultado manteniendo los datos personales en una base de datos que controlas, en lugar de integrarlos en pesos del modelo que no puedes inspeccionar, editar ni eliminar fácilmente.
Esa distinción lo determina todo lo que sigue. Cuando el fine-tuning es realmente la herramienta adecuada, los métodos eficientes en parámetros se ejecutan en una sola GPU de nube alquilada por unos pocos dólares por trabajo, y una capa de inferencia gestionada con residencia de datos en la UE o LATAM sirve el resultado sin necesidad de instalar hardware propio. Esta guía recorre la decisión en el orden que realmente ahorra dinero y problemas de auditoría: decide si necesitas fine-tuning, comprende qué exigen el RGPD y la Ley de IA de la UE si lo haces, y luego elige cómo ejecutarlo y servirlo sin poseer un clúster.
Empieza aquí: ¿realmente necesitas fine-tuning?
El fine-tuning y el RAG resuelven problemas distintos, y confundirlos es el error más costoso en la IA privada.
El fine-tuning integra patrones en los pesos del modelo. Es la herramienta adecuada cuando necesitas cambiar cómo se comporta el modelo: un tono de voz consistente, un formato de salida estricto, un vocabulario de dominio especializado o una tarea de clasificación. Es la herramienta incorrecta para enseñarle al modelo hechos sobre tus clientes, porque esos hechos quedan integrados en los pesos y son muy difíciles de eliminar.
El RAG mantiene tus datos propietarios en una base de datos vectorial (como Qdrant) y recupera los fragmentos relevantes en el momento de la consulta, inyectándolos en el prompt. El modelo base nunca memoriza nada. Para «responder preguntas sobre nuestra base de conocimiento», «redactar respuestas basadas en el historial de este cliente» o «buscar en nuestros documentos internos», el RAG suele ser más rápido de implementar, más económico de ejecutar y mucho más sencillo de defender bajo el RGPD.
La diferencia en materia de cumplimiento es decisiva. Bajo el Artículo 17 (Derecho de Supresión), un interesado puede pedirte que elimines sus datos personales. Con RAG, eliminas una fila y los datos desaparecen. Con un modelo con fine-tuning, esos mismos datos personales pueden estar distribuidos entre miles de millones de pesos sin forma quirúrgica de extraerlos, lo que puede obligar a un reentrenamiento completo. Si tu caso de uso trata realmente sobre conocimiento y no sobre comportamiento, lee nuestro tutorial sobre cómo construir un chatbot RAG en producción antes de recurrir al fine-tuning.
Qué exige el RGPD cuando haces fine-tuning con datos personales
Si tu caso de uso realmente necesita fine-tuning con datos personales, el RGPD se aplica en su totalidad al pipeline de entrenamiento, no solo al servicio en producción.
Base jurídica. El consentimiento es poco práctico para el entrenamiento de modelos, porque honrar su retirada una vez que los datos están integrados en los pesos es técnicamente muy difícil. La mayoría de las organizaciones se apoyan en el interés legítimo bajo el Artículo 6(1)(f), que requiere una prueba de ponderación documentada que demuestre que tu interés no prevalece sobre los derechos de las personas en el conjunto de datos.
Evaluación de Impacto sobre la Protección de Datos. El Artículo 35 hace obligatoria una EIPD para este tipo de tratamiento a gran escala. La evaluación debe nombrar los riesgos reales (memorización del modelo, reidentificación, inferencia de atributos sensibles) y las medidas de mitigación aplicadas a cada uno.
Minimización de datos y limitación de la finalidad. Filtra, seudonimiza o anonimiza el conjunto de entrenamiento antes del fine-tuning. Cuantos menos datos personales lleguen a los pesos, menor será cada riesgo posterior. Las directrices de 2025 del CEPD son explícitas en que no puedes asumir el cumplimiento automático, especialmente para datos extraídos mediante scraping o reutilizados.
Para una visión más amplia de cómo mantener la inferencia dentro de la ley, nuestra guía sobre alojamiento de LLM conforme al RGPD cubre en detalle el lado del servicio.
El umbral de la Ley de IA de la UE que casi con certeza no superas
Un temor habitual es que hacer fine-tuning de un modelo te convierta en «proveedor de un modelo de IA de uso general» regulado bajo la Ley de IA de la UE. Para casi todas las empresas, no es así.
Las directrices de la Comisión Europea de julio de 2025 establecen una línea indicativa: un modificador posterior solo se convierte en proveedor del modelo modificado cuando el fine-tuning utiliza más de un tercio del cómputo de entrenamiento del modelo original (o, cuando esa cifra es desconocida, más de un tercio de 10²³ FLOP). Un trabajo de fine-tuning eficiente en parámetros se sitúa órdenes de magnitud por debajo de ese umbral. Incluso en ese caso, las obligaciones resultantes se limitan a la modificación en sí (documentación de los datos de entrenamiento adicionales y el cómputo), no al modelo base completo. La conclusión práctica: registra tu cómputo de entrenamiento para poder demostrar que estás por debajo del umbral, y las obligaciones de proveedor de la Ley de IA quedan fuera del alcance. Nuestro análisis más detallado sobre cumplimiento de la Ley de IA para inferencia de LLM cubre las obligaciones del operador que sí aplican.
Fine-tuning sin GPUs propias: la ruta eficiente en parámetros
No necesitas un clúster para hacer fine-tuning de un modelo de pesos abiertos. Los métodos eficientes en parámetros (LoRA y su variante cuantizada QLoRA) congelan el modelo base y entrenan un pequeño conjunto de pesos adaptadores, lo que reduce drásticamente los requisitos de hardware.
Un modelo de clase 7B se ajusta cómodamente en una sola GPU de nube alquilada de 24 GB. Una ejecución completa de QLoRA de ese tamaño suele costar entre 3 y 15 dólares, y una ejecución corta de adaptadores puede quedar por debajo de un dólar; las búsquedas completas de hiperparámetros siguen situándose en las decenas de dólares bajas. Compara eso con el fine-tuning completo del mismo modelo, que necesita aproximadamente entre 100 y 120 GB de VRAM y decenas de miles de dólares en aceleradores por ejecución. QLoRA es lo que hace realista el «sin clúster».
Dos decisiones mantienen esto conforme y portable:
- Alquila GPUs alojadas en tu jurisdicción. Usa instancias de nube con sede en la UE o LATAM para que los datos de entrenamiento nunca salgan de la región. La GPU se alquila por horas y se libera al terminar el trabajo, sin desembolso de capital ni hardware inactivo.
- Usa modelos de pesos abiertos. Los modelos abiertos como la familia Qwen te permiten mantener los pesos base, el adaptador y la capa de servicio bajo tu control, y cambiar de infraestructura más adelante sin reescribir nada. Esa portabilidad es en sí misma un activo de protección de datos.
Residencia de datos y transferencias transfronterizas: UE y LATAM
Dónde se encuentran físicamente los datos y qué régimen jurídico puede acceder a ellos son dos preguntas distintas.
Para la UE, mover datos de entrenamiento o inferencia fuera del bloque requiere un mecanismo de transferencia: una decisión de adecuación para el país de destino, o Cláusulas Contractuales Tipo respaldadas por una evaluación del impacto de la transferencia. La LGPD de Brasil y la LFPDPPP de México siguen este modelo de cerca. Ninguna exige una localización física estricta, pero ambas esperan salvaguardas adecuadas (cláusulas equivalentes a las CCT y una base de seguridad documentada) antes de que los datos personales crucen una frontera.
La residencia por sí sola no es soberanía. Un proveedor con sede en EE. UU. puede almacenar tus datos en hardware de la UE o LATAM y seguir estando sujeto al acceso legal extranjero bajo marcos como la CLOUD Act. La solución es elegir un proveedor cuyo control corporativo e infraestructura estén fuera de ese alcance, y verificar que no haya saltos intermedios que enruten tus datos a través de una región no conforme. Nuestra guía de construir vs. comprar para IA privada explica cómo evaluar eso para tu propio stack.
Servir el modelo de forma privada sin un clúster de GPUs
Cualquiera que sea la ruta que elijas (RAG sobre un modelo base potente, o un adaptador QLoRA sobre uno), aún tienes que servir el modelo en producción, y ahí es donde poseer hardware suele volver a aparecer. No tiene por qué ser así.
Tessera ejecuta modelos de código abierto, incluido Qwen3.6-35B-A3B, en GPUs de centro de datos con memoria de alto ancho de banda, con residencia de datos en la UE y LATAM y una API compatible con OpenAI. Apuntas tu aplicación a un único endpoint, mantienes tus datos dentro de la región elegida y te saltas por completo la adquisición de GPUs, la planificación de capacidad y el mantenimiento de controladores. El precio es una tarifa mensual fija en lugar de medición por token, por lo que una ventana de contexto RAG más amplia o una semana más activa no generan una factura sorpresa. Para un despliegue RAG basado en conocimiento, esa combinación (modelo de pesos abiertos, región controlada, coste predecible) cubre la gran mayoría de los requisitos de «IA privada sobre nuestros datos» sin una sola línea de partida para hardware.
Si tu requisito es realmente inferencia con residencia en la UE en lugar de entrenamiento personalizado, nuestra guía sobre dónde alojar inferencia de LLM con residencia de datos en la UE compara las opciones, y el desglose de precios de IA privada muestra lo que cuesta realmente la tarifa plana. Los términos de tratamiento de datos están en nuestra lista de DPA y subencargados.
Preguntas frecuentes
¿El fine-tuning de un modelo te convierte en proveedor de IA bajo la Ley de IA de la UE?
No en casos normales. Según las directrices de la Comisión de 2025, solo te conviertes en proveedor del modelo modificado si tu fine-tuning utiliza más de un tercio del cómputo de entrenamiento del modelo base (o un tercio de 10²³ FLOP cuando esa cifra es desconocida). El fine-tuning eficiente en parámetros se sitúa muy por debajo de ese umbral, así que registra tu cómputo y conserva la evidencia.
¿Cómo se gestiona el Derecho de Supresión cuando los datos están integrados en los pesos del modelo?
La respuesta más limpia es mantener los datos personales fuera de los pesos desde el principio usando RAG, donde eliminar un registro elimina los datos. Si debes hacer fine-tuning, aplica minimización de datos y seudonimización antes del entrenamiento y documenta un plan de reentrenamiento, porque extraer quirúrgicamente los datos de una persona de los pesos entrenados no es actualmente viable.
¿Se requiere consentimiento para hacer fine-tuning con datos de clientes bajo el RGPD?
Generalmente no. La mayoría de las organizaciones se apoyan en el interés legítimo bajo el Artículo 6(1)(f) respaldado por una prueba de ponderación, porque el consentimiento es difícil de retirar una vez que los datos están integrados en los pesos. Aun así necesitas una EIPD y documentación clara de la necesidad.
¿Puedo hacer fine-tuning de modelos con datos de clientes en Brasil o México?
Sí, bajo la LGPD y la LFPDPPP, siempre que apliques salvaguardas adecuadas como cláusulas equivalentes a las CCT para cualquier transferencia transfronteriza. Ninguna ley exige localización física, pero ambas esperan una postura documentada de seguridad y base jurídica.