Cada vez que un empleado pega el contrato de un cliente en un chat de IA de consumo, tu empresa está tomando una decisión regulatoria sin saberlo. La pregunta ya no es si vas a usar IA generativa —eso está decidido—, sino dónde van a vivir el modelo y los datos que lo alimentan. Este artículo pone orden en tres cosas que suelen mezclarse en la misma frase: qué es la soberanía del dato, qué exige el marco normativo europeo y cuánto cuesta de verdad cada alternativa.
Qué significa de verdad soberanía del dato
Soberanía del dato no es un eslogan de ciberseguridad: es la capacidad de tu empresa de decidir y demostrar dónde están sus datos, quién accede a ellos y bajo qué jurisdicción. Cuando envías información a la API de un proveedor de IA, esa capacidad se diluye en tres niveles:
- Físico: no controlas en qué centro de datos ni en qué país se procesa cada petición.
- Jurídico: el tratamiento queda sujeto a los términos del proveedor y, a menudo, a legislaciones de fuera de la Unión Europea que pueden obligarle a entregar datos a terceros.
- Operativo: dependes de sus cambios de precio, de sus límites de uso, de sus caídas y de sus decisiones de retirar un modelo del que ya dependen tus procesos.
Un despliegue on-premise —en tus servidores o en tu cloud privado— invierte la ecuación: el modelo trabaja donde están los datos, en lugar de mover los datos hasta donde está el modelo. Los prompts, los documentos y las respuestas no cruzan nunca el perímetro de tu red. Para un hospital, un despacho, una aseguradora o un fabricante con propiedad industrial sensible, esa frase resume el 80 % de la decisión. Si quieres ver cómo se materializa técnicamente, lo contamos en nuestra página de SLM on-premise.
RGPD e IA generativa: los cuatro frentes
El RGPD no prohíbe usar IA generativa, pero sí obliga a responder preguntas incómodas antes de hacerlo. Sin entrar en tecnicismos jurídicos —para eso está tu asesoría legal—, los frentes que aparecen en casi cualquier proyecto son cuatro:
- Minimización. Solo deberías tratar los datos personales estrictamente necesarios para la finalidad. Enviar tickets de soporte enteros, con nombres, direcciones y números de pedido, a una API externa "porque el modelo funciona mejor con contexto" choca de frente con este principio. On-premise, la minimización se convierte en una decisión de diseño, no en una negociación con un tercero.
- Transferencias internacionales. Si el proveedor procesa datos fuera del Espacio Económico Europeo, necesitas garantías adicionales, y la validez de esos mecanismos ha cambiado varias veces en la última década. Un modelo que corre en tu propia infraestructura elimina la transferencia de raíz: no hay que justificar lo que no ocurre.
- Evaluaciones de impacto (DPIA). Cuando un tratamiento puede suponer alto riesgo para los derechos de las personas —perfilados, datos de salud, decisiones con efectos significativos—, toca evaluar el impacto antes de empezar. Esa evaluación es mucho más sencilla de superar cuando puedes describir con precisión dónde está cada dato y quién puede verlo, algo casi imposible con una caja negra ajena.
- Relación con encargados del tratamiento. Usar una API convierte al proveedor en parte de tu cadena de tratamiento, con contratos, auditorías y subencargados que revisar. Con IA propia, la cadena se acorta drásticamente: menos actores, menos papeles, menos superficie de riesgo.
La pregunta correcta no es «¿este proveedor cumple el RGPD?», sino «¿puedo demostrar yo, ante un cliente o un regulador, qué pasa con cada dato que entra en el sistema?». On-premise, la respuesta cabe en un diagrama de tu propia red.
AI Act: pensar por niveles de riesgo
El Reglamento europeo de IA (AI Act) añade una segunda capa: clasifica los sistemas de IA por niveles de riesgo —prácticas prohibidas, alto riesgo, obligaciones de transparencia y riesgo mínimo— y gradúa las exigencias según dónde caiga tu caso de uso. La mayoría de los agentes internos de una empresa (clasificar documentos, redactar borradores, conciliar facturas) quedan lejos del alto riesgo; otros, como los sistemas que influyen en decisiones sobre personas (selección, crédito, acceso a servicios esenciales), sí acarrean obligaciones serias de documentación, supervisión humana y gobernanza de datos.
¿Qué tiene que ver el despliegue con esto? Mucho. Las obligaciones de los casos sensibles giran en torno a trazabilidad, registro de actividad, control de los datos de entrenamiento y supervisión humana efectiva. Todo eso es abordable cuando el sistema es tuyo: sabes con qué se ajustó el modelo, guardas cada log, defines quién aprueba qué. Cuando el motor es una API opaca de un tercero, parte de esa documentación sencillamente no está a tu alcance. La soberanía técnica se convierte en soberanía regulatoria.
TCO: on-premise frente a API por tokens
Vamos con el dinero, que es donde más mitología hay. La comparación honesta no es «gratis frente a comprar servidores», sino coste total de propiedad (TCO) a dos o tres años vista. Esta tabla resume las diferencias estructurales; los números finales dependen de tu volumen, por eso hablamos de comportamiento y no de cifras cerradas:
| Dimensión | API LLM por tokens | SLM on-premise |
|---|---|---|
| Inversión inicial | Casi nula: una clave y a facturar | Proyecto + hardware (desde una GPU profesional; CPU viable en muchos casos) |
| Coste recurrente | Variable: cada petición suma, crece con la adopción | Fijo y acotado: energía, mantenimiento, soporte |
| Comportamiento al escalar | Lineal o peor: el éxito interno dispara la factura | Coste marginal por petición que tiende a cero |
| Predictibilidad | Baja: precios y límites los fija un tercero | Alta: presupuesto conocido a principio de año |
| Datos | Salen de tu infraestructura en cada llamada | No abandonan tu red (aire-gapped posible) |
| Cuándo compensa | Uso esporádico, pruebas, volúmenes muy bajos | Uso intensivo y sostenido: el punto de equilibrio suele medirse en meses |
La lectura práctica: si estás experimentando, la API es un buen laboratorio. Pero en cuanto un proceso de negocio real —soporte, back-office, documentación— pasa a depender de la IA a diario, el coste por token deja de ser una anécdota y se convierte en una partida creciente e imposible de presupuestar. Ahí es donde un SLM propio, ajustado a tu tarea, amortiza la inversión inicial y estabiliza el gasto. Sobre por qué un modelo pequeño especializado rinde más que uno gigante generalista, tienes el análisis completo en SLM vs LLM: qué modelo necesita tu empresa.
Cuatro mitos que conviene jubilar
«On-premise es solo para gigantes»
Era cierto cuando la única opción era entrenar modelos enormes. Hoy un SLM de pocos miles de millones de parámetros, cuantizado y ajustado a una tarea concreta, corre en una GPU profesional o incluso solo en CPU. Hablamos de hardware al alcance de una pyme, no de un centro de datos.
«Me quedaré anclado a un modelo viejo»
Solo si el sistema está mal diseñado. Una arquitectura on-premise bien hecha es agnóstica al modelo: el día que aparece una base mejor, se reajusta con tu conocimiento y se sustituye la pieza sin tocar el resto del sistema.
«La API siempre sale más barata»
Sale más barata el primer mes. Con volumen sostenido, la curva se cruza: el coste fijo del on-premise se diluye entre millones de peticiones mientras la factura por tokens sigue subiendo con cada usuario nuevo.
«Con firmar un contrato de encargo con el proveedor ya cumplo»
Un buen contrato reduce riesgo jurídico, pero no cambia los hechos técnicos: tus datos siguen saliendo de tu red, siguen existiendo transferencias que justificar y sigues dependiendo de la cadena de subencargados de otro. Cumplir no es solo firmar; es poder demostrar.
Checklist: qué necesitas para desplegar IA en casa
Si te planteas dar el paso, esto es lo que revisamos con cada cliente antes de escribir una línea de código:
- Caso de uso concreto y medible. Un proceso, un volumen, una métrica de éxito. "Poner IA" no es un proyecto; "clasificar y responder el 60 % de los tickets N1" sí.
- Inventario y clasificación de datos. Qué información va a tocar el sistema, qué parte es personal o confidencial y qué principio de minimización aplica.
- Evaluación de impacto cuando proceda. Si el tratamiento puede ser de alto riesgo para las personas, la DPIA se hace antes, no después.
- Hardware dimensionado al caso. Ni sobredimensionar "por si acaso" ni ahogar el modelo: se calcula con el volumen real de peticiones y la latencia objetivo.
- Integración con tus sistemas. El modelo solo es útil conectado a tu ERP, CRM, gestor documental o correo, con permisos y auditoría.
- Trazabilidad y supervisión humana. Logs de cada decisión, umbrales de confianza y circuitos de aprobación para lo delicado.
- Evaluación continua y plan de evolución. Métricas de calidad en producción y un camino claro para reentrenar o sustituir el modelo.
- Propiedad total. Código, pesos y documentación a tu nombre. Si mañana cambias de proveedor, el sistema sigue siendo tuyo.
Conclusión: soberanía es capacidad de decidir
La IA on-premise no es un capricho técnico ni una moda contra el cloud: es la forma de adoptar IA generativa sin hipotecar el control sobre tus datos, tu cumplimiento y tu presupuesto. El marco europeo —RGPD y AI Act— no castiga a quien usa IA, sino a quien no puede explicar qué hace su IA con los datos de las personas. Y esa explicación es infinitamente más fácil cuando el sistema entero vive dentro de tu perímetro.
La decisión, como casi todo en ingeniería, no es dogmática sino de contexto: volumen de uso, sensibilidad de los datos y horizonte temporal. Pero si tu empresa maneja información que no debería salir de casa y ya depende de la IA a diario, los números y la norma apuntan en la misma dirección.