Local es una ubicación, no una propiedad de seguridad
Ollama documenta que los prompts ejecutados localmente no se envían al servicio, que las funciones cloud se pueden desactivar y que el servidor usa 127.0.0.1 por defecto. Son controles útiles, pero el workflow completo incluye editor, plugins, shell, repositorio, vector store, downloader, package manager, telemetría, herramientas, backups y sistema operativo.
Empieza con un diagrama y clasificación explícita: código, secretos, datos de clientes, evidencia de incidentes, documentos, prompts, embeddings, outputs, traces y patches. Para cada flujo, identifica proceso, identidad, almacenamiento, retención, destino de red y acciones posibles.
Localidad de datosPrompts, chunks, outputs, embeddings, logs y cachés permanecen dentro de la frontera aprobada.
Confianza en artefactosModelos, containers, bibliotecas, extensiones y adapters tienen origen verificado y digest fijado.
Mínimo privilegioEl asistente solo ve repositorios aprobados y recibe permisos limitados de lectura, escritura, ejecución y red.
Conducta auditableSe puede rastrear el contexto recuperado, la herramienta ejecutada, el cambio y la aprobación.
Coloca un gateway de política delante de cada modelo
Las aplicaciones no deberían llamar directamente a Ollama, llama.cpp o vLLM. Un gateway local autentica al cliente, clasifica la solicitud, aplica política por proyecto, elimina secretos evidentes, elige un modelo aprobado, limita contexto y output, registra metadatos mínimos y bloquea herramientas o destinos prohibidos.
La misma interfaz puede enviar trabajo de baja sensibilidad a un proveedor cloud aprobado. La decisión debe depender de sensibilidad, proyecto, residencia, modelo permitido, tarea, tamaño de contexto y autorización. No dependas de que el desarrollador recuerde qué ventana de chat es segura.
Frontera local versus cloudFrontera local confidencialRuta predeterminada para contexto propietario o regulado.- Identidad y dispositivo administrado
- Repositorios aprobados y secret scanner
- RAG local con ACL
- Runtime y modelo fijados
- Herramientas aisladas y patch revisado
- Storage cifrado y evidencia local
Gateway de políticaClasificar, minimizar, enrutarAutenticación, DLP, contexto, allowlist, permisos, budgets, auditoría y egress deny-by-default.
Frontera externa aprobadaRuta opcional para tareas sanitizadas y permitidas.- Contrato enterprise y región aprobada
- Sin código, secretos, datos ni traces crudos
- Solo el contexto mínimo
- Política de identidad, retención y logs
- Aprobación por tarea y correlation ID
- Respuesta tratada como input no confiable
Los pesos son inputs ejecutables de la supply chain
La inferencia local aún descarga artefactos de terceros y ejecuta parsers, tokenizers, templates, bibliotecas nativas, drivers y a veces código personalizado. Hugging Face documenta el riesgo de ejecución arbitraria de pickle. Prefiere safetensors o formatos limitados como GGUF, rechaza remote code no revisado, escanea artefactos y aísla conversiones.
Replica modelos aprobados en un registry interno. Fija revisión, hashes, digest del container, runtime, tokenizer, template, cuantización, licencia y model card. Registra procedencia y vulnerabilidades. SLSA, Sigstore y NIST SSDF aportan patrones reutilizables.
RAG debe aplicar permisos antes del retrieval
Un vector database privado aún puede filtrar datos entre proyectos. La ingesta debe excluir .env, claves, credenciales, dumps, binarios, dependencias, datos personales y directorios fuera del repositorio permitido. Aplica ACL antes del embedding y de nuevo antes de devolver chunks. Un filtro posterior no debe ser la única barrera entre tenants.
Separa índices cuando haga falta, cifra storage, versiona el corpus, propaga eliminaciones y muestra path, commit, líneas y decisión de acceso por chunk. El modelo debe recibir el código mínimo necesario, no todo el repositorio.
La ejecución de herramientas es una frontera más fuerte
Un modelo local con shell arbitrario, home directory, SSH, cloud CLI o APIs internas puede tener más alcance que un chat cloud. OWASP destaca prompt injection y excessive agency. Trata el output como input no confiable y coloca cada herramienta detrás de un adapter tipado y gobernado.
Usa worktrees o containers desechables, identidad non-root, mounts read-only, límites, allowlist de comandos, red denegada, paths restringidos, timeout y aprobación antes de escritura, commit, instalación, cambios de base o comunicación externa. Muestra el diff y comando exactos.
| Superficie | Exposición típica | Control requerido | Evidencia |
|---|
| API de inferencia | Servidor en LAN, identidad débil, origins amplios y uso ilimitado. | Loopback o red privada, gateway autenticado, firewall, TLS, allowlist y rate limit. | Caller, decisión, modelo, clase, tiempo y bloqueos. |
| Artefacto del modelo | Serialización maliciosa, remote code, tag sustituido o licencia incompatible. | Allowlist, formato seguro, digest, scan, firma, procedencia y revisión de licencia. | Revisión, hash, firma, SBOM, scanner y aprobador. |
| Código y RAG | Secretos indexados, código eliminado, retrieval cruzado y contexto excesivo. | Scan previo, ACL antes de búsqueda, índices separados, borrado y minimización. | Versión, fuentes, ACL, exclusiones y retención. |
| Editor | Telemetría, fallback cloud oculto y acceso amplio al workspace. | Build aprobado, configuración gobernada, egress, workspace restringido y updates controlados. | Versión, settings, destinos, permisos y update. |
| Herramientas | Prompt injection activa shell, Git, tickets, base o cloud. | Sandbox, adapters tipados, mínimo privilegio, dry run, aprobación y límites. | Argumentos, comando, diff, aprobador, resultado y rollback. |
| Logs y memoria | Prompts, código, secretos o datos retenidos indefinidamente. | Logs mínimos, redacción, cifrado, retención corta y borrado. | Política, accesos, borrado y versión del redactor. |
Los secretos no pueden depender de una instrucción
“No reveles secretos” no es un control. Mantén credenciales fuera de rutas indexadas y variables visibles al modelo. Usa identidades de corta duración, tokens limitados, secret brokers, scanners antes del commit y la ingesta y análisis de outputs. Rota cualquier secreto que llegue a un prompt, trace, embedding o artefacto.
El cifrado de disco protege un equipo apagado, no un editor comprometido. El uso enterprise también requiere gestión de endpoint, patching, screen lock, antimalware, separación de usuarios, backup controlado y revocación remota.
Mide calidad antes de declarar suficiente al modelo local
La privacidad falla indirectamente cuando un modelo débil genera código inseguro o empuja al equipo a un servicio no aprobado. Evalúa con repositorios y tareas reales: corrección, tests, secretos, autorización, dependencias, APIs inventadas, tools, latencia, memoria y energía.
Cuantización, contexto, hardware, template y retrieval cambian la conducta. Versiona todo y usa el mismo pipeline de evaluación de un componente productivo. Enruta al tier local solo las tareas que cumplan el nivel mínimo de calidad.
Qué construiría
Construiría un gateway de IA para workstations administradas y clusters privados. Clasificaría contexto, aplicaría política por repositorio, seleccionaría un modelo fijado, haría retrieval con ACL, abriría un worktree aislado, expondría herramientas limitadas, escanearía el diff y exigiría aprobación.
Un control plane central distribuiría manifestos, policies, extensiones, evals, revocaciones y schemas de auditoría sin recopilar código. El equipo vería qué datos quedaron locales, qué tareas sanitizadas salieron, qué artefactos se ejecutaron y qué acciones fueron aprobadas.
El principio de diseño
La inferencia local reduce la frontera de datos y elimina una dependencia. La seguridad viene de controlar todo el workflow: identidad, artefactos, red, retrieval, herramientas, storage, logs, calidad y autoridad humana. “Corre en mi máquina” es la condición inicial, no la conclusión.