El término «IA privada» se usa para todo, desde «hemos desactivado el entrenamiento en nuestra cuenta de SaaS» hasta «ejecutamos modelos de pesos abiertos en nuestra propia infraestructura». No son el mismo límite de control.
Para las pymes, la arquitectura adecuada de IA privada depende de los datos, la tarea, el requisito de calidad y la capacidad del equipo para operar la infraestructura. La opción más privada no siempre es la mejor. La opción más capaz no siempre es aceptable para los datos. La opción más barata puede resultar costosa si requiere una atención constante por parte de ingeniería.
Este artículo ofrece un mapa de decisiones. Combínalo con el texto oficial del RGPD, el Marco de Gestión de Riesgos de IA de NIST, los contratos de proveedores y la documentación de control de datos, así como la guía de seguridad del motor de servicio seleccionado, como la seguridad de vLLM.
Comienza con la clasificación de datos, no con la preferencia por el modelo. Un modelo menos potente en el límite de privacidad adecuado es mejor que un modelo de vanguardia alimentado con datos a los que no debería tener acceso.
Los cinco patrones de despliegue
| Patrón | Qué es | Casos adecuados | Limitación principal |
|---|---|---|---|
| SaaS empresarial | Nivel empresarial con administración, SSO, retención y opción de exclusión del entrenamiento | La mayor parte del trabajo habitual de la empresa | Los datos siguen saliendo de tu entorno |
| VPC o nube privada | Punto final de modelo gestionado dentro de un límite de nube controlado | Cargas de trabajo confidenciales que necesitan mayor aislamiento | Coste y configuración más elevados |
| Inferencia alojada en infraestructura propia | Ejecutas modelos abiertos en tu propia infraestructura | Datos restringidos, modelos personalizados, economías de escala | Carga operativa |
| Modelos para dispositivos locales | El modelo se ejecuta en un portátil, estación de trabajo o dispositivo edge | Tareas acotadas sin conexión, sensibles y de baja latencia | Modelos más pequeños y límites del dispositivo |
| Enrutamiento híbrido | Dirige cada caso de uso al límite correspondiente | Conjuntos de casos con distintos niveles de sensibilidad | Requiere disciplina en la clasificación |
Las cuentas personales de consumo no suelen ofrecer la configuración centralizada de identidad, retención, conectores, contratos y auditoría que controla la organización. La política de la empresa debe definir si se permiten y, en tal caso, para qué datos.
Una organización puede necesitar un solo patrón o un conjunto gestionado de ellos. El objetivo es elegir y volver a validar un límite para cada caso de uso aprobado, en lugar de tratar una etiqueta de producto como una garantía permanente.
Clasifica los datos primero
Las cuatro categorías siguientes son una taxonomía ilustrativa inicial. Ajusta los nombres y las reglas de tratamiento a la clasificación real de información de la organización y sus requisitos legales:
| Datos | Ejemplos | Límite de IA por defecto |
|---|---|---|
| Públicos | Texto del sitio web, documentos publicados, investigación pública | Herramienta aprobada tras verificar derechos, autenticidad, inyección de prompts y términos |
| Internos | Notas de procesos, ejemplos anonimizados, borradores no sensibles | SaaS empresarial |
| Confidenciales | Datos de clientes, contratos, código fuente, información financiera, estrategia | SaaS empresarial con controles, VPC o alojamiento en infraestructura propia |
| Restringidos | Datos de salud, información protegida por secreto profesional, investigaciones de RR. HH., registros regulados | Revisión jurídica y de seguridad; puede ser necesaria una ruta aprobada local, en VPC, en infraestructura propia o sin IA |
Esta clasificación evita un error común: usar el mismo asistente para borradores públicos del blog y registros confidenciales de clientes por comodidad.
Las credenciales, claves privadas, tokens de autenticación y códigos de recuperación no son una categoría de enrutamiento de modelos. Exclúyelos de los prompts, corpus de recuperación, telemetría y herramientas accesibles al modelo; utiliza un gestor de secretos e inyección en tiempo de ejecución con alcance acotado cuando una integración determinista requiera una credencial.
Patrón 1: SaaS empresarial como opción por defecto
El SaaS empresarial puede ser el candidato de menor complejidad operativa. Los nombres de productos, las prestaciones del plan y los términos contractuales cambian; verifica en cada plan preseleccionado:
- Términos contractuales de uso de datos y entrenamiento de modelos.
- Controles de administración.
- SSO y gestión de accesos.
- Controles de retención.
- Registros de auditoría.
- Documentación de seguridad.
- Soporte del proveedor.
Estos controles pueden apoyar el trabajo aprobado, pero comprar un plan no establece que una categoría de datos o un flujo de trabajo concretos sean lícitos o seguros.
La clave es la configuración. Comprar el plan para equipos no es suficiente. Configura la retención, la compartición, el acceso a conectores, los espacios de trabajo aprobados y las reglas de datos.
Patrón 2: VPC o nube privada
Los patrones de VPC/nube privada son candidatos cuando los datos pueden salir de la aplicación pero deben permanecer dentro de un límite de nube y contractual definido. «Dentro de una VPC» no prueba que cada plano de control, servicio de modelo, registro, soporte o ruta de copia de seguridad permanezca allí; mapea y prueba el flujo completo de datos.
- Asistente de atención al cliente sobre tickets confidenciales.
- Asistente de conocimiento interno sobre documentos sensibles.
- Extracción de documentos para contratos o facturas.
- Asistente específico del dominio donde necesitas un aislamiento de datos mayor que en SaaS.
Ventajas potenciales a verificar:
- Mayor aislamiento bajo el diseño de servicio seleccionado.
- Más control sobre la red y los registros.
- Evidencia que puede satisfacer requisitos de adquisición definidos.
- Una división operativa diferente respecto al alojamiento completo en infraestructura propia.
Limitaciones potenciales a valorar y probar:
- El precio puede superar el de un plan SaaS compartido para la carga medida.
- Integración adicional y trabajo de plataforma.
- La elección del modelo puede ser más limitada.
- Sigues dependiendo de la infraestructura del proveedor.
Trata esto como un candidato intermedio, no como la opción por defecto para toda pyme.
Patrón 3: Inferencia alojada en infraestructura propia
Alojar en infraestructura propia significa que ejecutas el tiempo de ejecución del modelo: vLLM, TGI, SGLang, llama.cpp, Ollama u otra pila de servicio. Tiene sentido cuando:
- Los datos no pueden salir de tu entorno.
- Necesitas un modelo abierto personalizado o con ajuste fino.
- El volumen de inferencia es lo suficientemente alto como para justificar la infraestructura.
- Las necesidades de latencia o disponibilidad requieren control directo.
- Tienes personal capaz de operarlo.
No alojes en infraestructura propia solo porque parezca más «puro». El coste operativo es real: capacidad de GPU, monitorización, actualizaciones, parches de seguridad, evaluación del modelo, escalado y respuesta a incidentes.
El alojamiento en infraestructura propia es una opción sólida para la organización adecuada. Para un equipo pequeño sin experiencia en infraestructura de aprendizaje automático, puede convertirse en un proyecto secundario frágil.
Patrón 4: Modelos para dispositivos locales
Los modelos locales son candidatos para trabajo individual sensible a la privacidad cuando se controla por completo el límite de dispositivo, actualización, telemetría, copia de seguridad y acceso:
- Resumen de notas locales.
- Redacción basada en documentos privados.
- Clasificación de fragmentos internos.
- Trabajo de campo sin conexión.
- Flujos de trabajo edge donde la latencia es importante.
La compensación de calidad depende de la tarea y del modelo concreto. Evalúa el candidato local en tareas representativas de resumen, clasificación, extracción o redacción, en lugar de asumir paridad o inferioridad por defecto.
Utiliza un modelo local solo cuando cumpla la evaluación de la tarea y se haya aprobado el límite local completo; que «se ejecute en el dispositivo» no prueba por sí mismo la privacidad.
Patrón 5: Enrutamiento híbrido
Un candidato híbrido puede enrutar cargas de trabajo según la clase de datos aprobada:
- Las tareas públicas y de bajo riesgo van a SaaS empresarial.
- La recuperación confidencial ocurre dentro de un sistema RAG privado.
- La extracción restringida utiliza únicamente una ruta específicamente aprobada —local, en VPC, alojada en infraestructura propia o sin IA— tras revisar el flujo completo de datos.
- La redacción final puede usar un modelo de vanguardia después de eliminar los campos sensibles.
- Los registros y evaluaciones deciden si cada ruta está funcionando correctamente.
El enrutamiento híbrido puede asignar diferentes registros a diferentes límites aprobados. Requiere una política que se pueda aplicar de forma efectiva, no solo una clasificación por prompt:
- Clasificación de datos antes del enrutamiento.
- Enmascaramiento de datos cuando sea posible.
- Lista de permitidos (allowlist) clara para modelos y herramientas.
- Registros que indiquen qué límite se utilizó.
- Alternativa (fallback) cuando el modelo privado no pueda realizar la tarea.
Marco de decisiones
Hazte seis preguntas:
- ¿Qué datos entran en el modelo? Públicos, internos, confidenciales, restringidos.
- ¿Qué impacto tiene la salida? Borrador, recomendación, decisión, acción visible para el cliente.
- ¿Qué calidad se requiere? Define objetivos específicos de tarea para precisión, seguridad, latencia, rechazo y revisión humana en lugar de etiquetas como «nivel experto».
- ¿Qué latencia se requiere? Interactiva, por lotes, tiempo real, sin conexión.
- ¿Qué capacidad operativa existe? Sin equipo de infraestructura, equipo de aplicaciones, equipo de plataforma, operaciones ML.
- ¿Qué prueba necesitan los clientes o reguladores? Documentos del proveedor, registros, residencia de los datos, rastro de auditoría, aislamiento.
A continuación, elige el patrón de menor complejidad que satisfaga las necesidades de datos y calidad.
No hagas esto aún
No alojes en infraestructura propia antes de medir la carga y el requisito de calidad.
No envíes datos restringidos a herramientas para consumidores.
No asumas que «código abierto» significa privado. Solo es privado si el despliegue, los registros, el acceso y el flujo de datos son privados.
No despliegues una puerta de enlace de IA sin una clasificación de datos vinculada a la identidad, aplicada mediante políticas y con rutas denegadas por defecto. Una puerta de enlace centralizada puede aplicar políticas, pero solo si se prueban las elusiones, las alternativas (fallback), los registros y el comportamiento ante fallos.
No ignores las evaluaciones (evals). Que sea privado pero incorrecto sigue siendo incorrecto.
Un punto de partida práctico para pymes
Una posible secuencia inicial para una pyme, sujeta a revisión:
- Aprueba un asistente SaaS empresarial general para el trabajo habitual.
- Escribe una regla de clasificación de datos.
- Bloquea los datos restringidos salvo que se revisen.
- Construye un flujo RAG privado o en VPC para el caso confidencial más valioso.
- Utiliza modelos locales para tareas sensibles acotadas donde la calidad sea aceptable.
- Reconsidera el alojamiento en infraestructura propia solo cuando la privacidad, personalización o coste lo justifiquen claramente.
Esto produce un camino de decisiones escalonado. La privacidad por diseño y por defecto sigue requiriendo propósitos documentados, minimización, accesos, retención, eliminación, encargados del tratamiento, transferencias y decisiones de seguridad (guía de la Comisión Europea).
Arquitectura adaptada a los datos, el riesgo y las operaciones
La IA privada es una arquitectura adaptada a los datos, el riesgo y las operaciones. Puede resultar apropiado combinar varios patrones, pero cada ruta necesita una persona responsable identificada y un límite verificado.
Elige basándote en los datos, impacto, calidad, latencia, operaciones y evidencia.
