IA privada para datos sensibles: un LLM local que supera la revisión de seguridad
Historias clínicas, contratos de clientes, cifras financieras sin publicar: hay datos que nunca deben llegar a una API pública de IA, y tu equipo de seguridad tiene razón en exigirlo. Normalmente ahí termina la conversación sobre IA, y quienes más se beneficiarían siguen copiando texto a mano. No tiene por qué ser así. Esta es la arquitectura que uso para IA privada dentro de tu propia red: primero un conjunto de pruebas, luego el modelo más pequeño que lo supere, recuperación que respeta los permisos, un anonimizador en el borde y una auditoría de todo.
Actualizado 11 min de lectura
1. Clasificar los datos y la tarea
Empieza con dos listas cortas. La primera nombra las clases de datos implicadas: datos personales, de salud, secretos comerciales, datos financieros regulados. La segunda nombra las tareas: clasificar, extraer de documentos, resumir, redactar respuestas, responder preguntas sobre documentos internos. Juntas deciden lo estricto que debe ser el montaje y lo grande que tiene que ser el modelo.
La tarea importa más de lo que se cree. Clasificar, extraer y resumir funcionan bien con modelos pequeños de pesos abiertos, a menudo con una calidad que sorprende al negocio. El razonamiento en varios pasos sobre muchos documentos largos necesita un modelo más grande y más hardware. El NIST AI Risk Management Framework y la guía de Azure Well-Architected para cargas de IA empiezan aquí por una razón: entender el caso de uso y sus riesgos antes de elegir tecnología.
Consejo práctico
Escribe las clases de datos en el diseño del sistema, no solo en un PDF de políticas. Así el gateway puede enrutar por clase: lo público puede ir a un modelo alojado, lo confidencial nunca.
2. Crear el conjunto de pruebas antes de elegir modelo
Reúne de 30 a 50 ejemplos reales con la respuesta que esperas y que alguien del negocio los revise. Incluye a propósito los casos difíciles: PDF escaneados, idiomas mezclados, tablas, el contrato con la cláusula rara, el hilo de correos donde la respuesta está en el tercer mensaje. Guárdalos como líneas JSON sencillas, un caso por línea, con el archivo fuente y la respuesta esperada.
Puntúa cada modelo y cada prompt candidato con ese conjunto: precisión, latencia y coste por petición. Ese conjunto decide el modelo, no un ranking, porque los benchmarks públicos rara vez se parecen a tus documentos. Y sigue decidiendo: cada vez que alguien cambia un prompt, un ajuste de recuperación o el propio modelo, el mismo conjunto vuelve a ejecutarse. Sin él, cada cambio es cuestión de opiniones; con él, es una cifra en un panel.
{"id": "contract-017", "file": "contracts/017.pdf",
"question": "What is the notice period?",
"expected": "3 months to the end of a quarter",
"must_cite": "section 9.2", "data_class": "confidential"}3. Ajustar el modelo al hardware
La memoria de la GPU decide qué se puede ejecutar. Como regla práctica, los pesos ocupan parámetros por bytes por peso: un modelo de 14.000 millones de parámetros son unos 28 GB a 16 bits, 14 GB a 8 bits y 7 GB a 4 bits. A eso se suman la caché KV, que crece con la longitud de contexto y el número de usuarios en paralelo, y algo de memoria del propio motor. Prueba la calculadora de abajo con tus cifras antes de hablar con un proveedor de hardware.
La cuantización es la palanca que lo hace asequible. Los modelos a 4 bits pierden algo de precisión en la mayoría de tareas, a veces tan poco que tu conjunto de pruebas no lo nota, y funcionan en una sola GPU de estación de trabajo. Para prototipos basta una GPU de escritorio o un Mac con suficiente memoria unificada. Para producción, planifica un nodo GPU con margen para los picos, porque un modelo que cabe justo pondrá peticiones en cola en cuanto tres personas lo usen a la vez.
Consejo práctico
Prueba el modelo cuantizado que vas a usar de verdad, no el de precisión completa de la ficha del modelo. Los benchmarks publicados casi siempre se miden a 16 bits.
Interactivo
¿Qué GPU necesita tu modelo?
Elige tamaño del modelo y precisión. Los pesos ocupan parámetros × bytes por parámetro; un 20 % más cubre la caché KV con contextos normales.
Tamaño del modelo (miles de millones de parámetros)
Precisión
≈ 19 GB
memoria de GPU necesaria
1×
cabe en 24 GB (RTX 4090)
- 1× 24 GB (RTX 4090)
- 1× 32 GB (RTX 5090)
- 1× 48 GB (L40S)
- 1× 80 GB (H100)
- 1× 96 GB (RTX PRO 6000 Blackwell)
- 1× 141 GB (H200)
Regla práctica para planificar, no un benchmark. Contextos largos y muchos usuarios en paralelo necesitan más caché KV; 4 bits cuesta algo de calidad.
Todas las calculadoras y checklists4. Servirlo como cualquier otra API interna
Para unos pocos usuarios, Ollama o llama.cpp es el camino más rápido a un endpoint que funcione. En cuanto muchas personas o agentes usan el mismo modelo, pasa a vLLM: el continuous batching y la paged attention sacan mucho más rendimiento de la misma GPU, y ofrece una API compatible con OpenAI, así que a tus aplicaciones les da igual qué modelo hay detrás. Cambiar de modelo más adelante se convierte en un cambio de configuración, no en un proyecto.
Ejecuta el servidor en tu propia red o nube privada, detrás del mismo gateway, TLS, monitorización y rutina de parches que cualquier otro servicio. Fija la versión del modelo y la imagen del contenedor, guarda los pesos en tu propio registro u object storage y trata una actualización de modelo como una de base de datos: primero el conjunto de pruebas, luego staging, luego producción. La Generative AI Lens del AWS Well-Architected Framework describe la misma disciplina de operación para modelos alojados; en tu propio hardware se aplica igual.
# OpenAI-compatible endpoint on an internal GPU node (example model;
# pick yours with the test set)
vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \
--quantization awq \
--max-model-len 32768 \
--gpu-memory-utilization 0.90 \
--host 0.0.0.0 --port 8000
# Any OpenAI client can now talk to it, inside your network only
curl http://llm.internal:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Qwen/Qwen2.5-14B-Instruct-AWQ",
"messages": [{"role": "user", "content": "Summarise clause 9.2"}]}'5. Traer tus documentos, con sus permisos
La recuperación da al modelo las páginas adecuadas para cada pregunta, en lugar de entrenarlo con tus datos. Divide los documentos en fragmentos, crea embeddings con un modelo de embeddings local y guárdalos en pgvector dentro del Postgres que probablemente ya tienes. Guarda la fuente, la versión y la lista de acceso de cada fragmento junto al vector, porque necesitarás las tres al consultar.
El detalle clave es el orden. Filtra por lo que el usuario puede ver antes de ordenar por similitud, para que el modelo nunca reciba un párrafo que esa persona no podría abrir en el sistema original. Después cita la fuente en cada respuesta, con enlace, para que la gente pueda comprobar en vez de confiar. OWASP incluye la divulgación de información sensible entre los principales riesgos de las aplicaciones con LLM, y la recuperación sin permisos es la forma más habitual de que ocurra.
-- Chunks with their source and who may read them
create extension if not exists vector;
create table doc_chunks (
id bigserial primary key,
source text not null,
allowed_groups text[] not null,
content text not null,
embedding vector(1024)
);
-- Nearest chunks the user is allowed to see
select source, content
from doc_chunks
where allowed_groups && $1 -- the user's groups
order by embedding <=> $2 -- cosine distance
limit 8;Consejo práctico
Indexa los permisos, no solo el texto. Una recuperación que ignora los permisos es una fuga de datos con pasos extra.
6. Anonimizar en el borde
A veces un paso sí se beneficia de un gran modelo alojado, por ejemplo para pulir un texto final o para un razonamiento difícil sobre un resumen. Entonces la parte local hace primero el trabajo sensible: quita nombres, direcciones, números de cuenta e identificadores de caso, los sustituye por marcadores, envía solo el texto anonimizado y vuelve a poner los valores reales en la respuesta en local.
Herramientas como Microsoft Presidio detectan los tipos de entidad habituales de serie; añade tus propios reconocedores para números de cliente, identificadores de contrato o códigos internos, y pruébalos con la misma disciplina que el modelo. Registra cada petición que sale de la red: cuándo, qué modelo, qué clase de dato y cuántas entidades se sustituyeron. Si el registro muestra alguna vez una clase confidencial saliendo, tienes un fallo, y lo encontrarás el mismo día en vez de en una auditoría un año después.
7. Identidad, auditoría y nada de salidas inesperadas
Pon el modelo detrás de tu inicio de sesión único, para que cada petición lleve una identidad de persona o de servicio. Escribe un registro de auditoría con usuario, modelo, clase de dato y fuentes recuperadas, y consérvalo tanto tiempo como exijan tus normas de cumplimiento. Ese registro responde a las dos preguntas que hace todo auditor: ¿quién vio qué?, ¿salió algo?
Después cierra las puertas que no necesitas. Bloquea por defecto el tráfico saliente de los nodos GPU, salvo hacia los registros que usas para actualizar, y convierte cada excepción en un cambio revisado. Da a los agentes de IA sus propias identidades de servicio, primero solo con lectura; la escritura llega después, herramienta a herramienta, con aprobación humana. La revisión de seguridad se acorta cuando puedes enseñar el diagrama de arquitectura, el registro de auditoría y las reglas de firewall en una sola reunión, que es justo lo que pide el pilar de seguridad del Azure Well-Architected Framework: defensa en profundidad, mínimo privilegio y evidencias.
Consejo práctico
Haz una prueba de salida a propósito antes de producción: desde un nodo GPU, intenta llegar a una API pública de IA. Si funciona, tu regla de firewall no.
8. Medir y después escalar
Ejecuta el conjunto de pruebas en cada cambio de modelo o de prompt y sigue precisión, latencia y coste por petición en un panel junto a tus otros servicios. Vigila el uso de la GPU: como orientación, muy por debajo de un tercio significa que pagas silicio parado, y por encima del 85 % de forma constante significa colas y latencia creciente. Ambas son señales para redimensionar, no para alarmarse.
Cuando la calidad se mantenga y la gente lo use a diario, pasa del equipo de prototipo a un pequeño node pool con GPU en tu propio centro de datos o nube privada, con autoescalado según la longitud de la cola en vez de la CPU. Añade un segundo modelo solo cuando el conjunto de pruebas muestre una tarea que el primero no resuelve. El resultado es aburrido en el mejor sentido: un servicio interno con responsable, batería de pruebas, auditoría y un coste por petición que puedes explicar a finanzas.
Conclusión
La IA privada es sobre todo disciplina de ingeniería: un conjunto de pruebas, el modelo más pequeño que lo supere, permisos en la recuperación y un registro de auditoría. Con eso bien hecho, los datos sensibles y la IA se llevan perfectamente.
Proyectos reales relacionados
Pruébalo tú mismo
Fuentes y guías oficiales
- Azure Well-Architected Framework: AI workloads
- Azure Well-Architected Framework: Security pillar
- AWS Well-Architected: Generative AI Lens
- NIST AI Risk Management Framework
- OWASP Top 10 for Large Language Model Applications
- vLLM documentation
- pgvector: vector similarity search for Postgres
- Microsoft Presidio: data protection and de-identification
Más artículos
- 3.025 pull requests en diez meses: un proceso de entrega con IA, desde dentro
- La Ley de IA de la UE para medianas empresas: qué te aplica y desde cuándo
- FinOps para el gasto en IA: tokens, caché, enrutado y presupuestos que aguantan
- Hacer visible una red de restaurantes en las respuestas de la IA: un proyecto GEO paso a paso
- Cómo está hecha esta web: estática donde se puede, en streaming donde hace falta
- Costes de Kubernetes en EKS y GKE: el mismo método, otras palancas
- Una landing zone para empresas medianas, en Terraform o Bicep: las piezas que importan
- El manual de migración de sistemas heredados: oleadas, ejecución en paralelo y recuentos y checksums idénticos
- Seguridad de MCP a fondo: dejar entrar a los asistentes de IA en tu producto sin abrir las puertas
- Monitorizar resultados de negocio: paneles en verde, caja vacía
- Agentes de IA por teléfono: la arquitectura y los tropiezos que ninguna demo enseña
- Pruebas de restauración: un backup que nunca has restaurado es solo una esperanza
- Respuestas de IA en streaming en Azure Static Web Apps: la cabecera que lo retenía todo
- Construir un asistente de IA para WhatsApp de principio a fin: lo que hace falta más allá de la demo
- Sistemas air-gapped: software crítico sin conexión a internet
- IA en producción en AWS: Amazon Bedrock y AgentCore en una configuración privada
- IA en producción con Microsoft Foundry: una configuración de referencia privada para agentes
- /goal, /loop o rutinas: deja de vigilar a tu agente de programación
- Los nuevos planes de Claude: Max, Ultra y lo que significan para los equipos
- OpenAI Codex a finales de 2026: goal mode, dots y cómo blindarlo
- ¿GitHub Copilot, Claude Code o Codex? Cómo elegiría para una empresa
- Fundamentos de GEO: cómo aparecer en las respuestas de la IA
- IA en producción en Google Cloud: de Vertex AI a Gemini Enterprise Agent Platform
- LLM locales en una red air-gapped: IA para tus datos más sensibles
- Quiero ejecutar un LLM local: ¿qué servidor compro?
- MiniMax M3: ¿un modelo puntero que puedes ejecutar tú mismo?
- Investigación de prompts a gran escala con un modelo abierto
- SEO y GEO juntos: una auditoría práctica en 6 pasos
- Dimensionar bien Kubernetes: el método que llevó un clúster de 7 a 4 nodos
- Del prototipo con IA a producción: las ocho capas que añado, en este orden
