The value proposition is obvious: your documents hold answers no general model has, so indexing them for AI retrieval makes every assistant dramatically more useful. The risk is equally obvious: those documents are contracts, research, client records, personal files. Before any of them leave your disk, "private" needs a definition sharper than a marketing adjective.
What "private" must mean, concretely
1. No training on your content
The first question for any provider: is my content ever used to train or fine-tune models? The acceptable answer is an unqualified no, stated in the privacy policy, not in a FAQ that can change. Training is how private data becomes public behavior.
2. Tenant isolation with teeth
Multi-tenant services store many users' data on shared infrastructure; the question is what enforces separation. Application-level filtering ("we add a WHERE clause") fails open — one bug and queries cross tenants. Database-enforced row-level security (RLS) fails closed: the database itself refuses to return rows that don't belong to the authenticated user, no matter what the application layer does. Ask which model your provider uses.
3. Scoped, revocable access
Retrieval endpoints should be per-user and token-scoped, so possession of a URL grants access to exactly one tenant's corpus — and revoking the token kills access without a migration.
4. Deletion that deletes
Removing a source should remove its chunks and embeddings from the index, not just hide the filename. You should be able to enumerate every source the system holds for you.
5. Conversation boundaries
Subtle but important for AI knowledge bases specifically: does the provider see your conversations, or only the retrieval queries? A tool-provider architecture — where the knowledge base answers discrete tool calls and never receives the surrounding chat — structurally limits what the provider can know. Metadata-only logging (tool name, timestamp, latency) is the right posture.
The architecture spectrum
| Approach | Privacy model | Trade-off |
|---|---|---|
| Local-only (e.g. notes app + local index) | Data never leaves your machine | Per-device setup; no cross-client access; you run the pipeline |
| Self-hosted RAG stack | Your infrastructure, your rules | Real engineering and ops burden; you own every failure |
| Hosted context layer (e.g. VeelIQ Context) | Provider-enforced isolation (RLS), no-training policy, tool-call-only visibility | Trust shifts to the provider's stated and audited posture |
| Upload-to-chatbot (files into a chat app) | Varies by vendor and plan; often entangled with product improvement clauses | Knowledge locked to one vendor; least user control |
There is no universally correct row — a hospital's constraints aren't a freelancer's. The failure is not choosing consciously. The VeelIQ vs Obsidian comparison walks the local-vs-hosted trade-off in detail.
Retrieval-specific risks people miss
- Cross-context bleed. One undifferentiated corpus means client A's strategy can surface while you work for client B. Fix: separate workspaces per context, enforced at the store level — not prompt discipline.
- Over-retrieval. Retrieval injects document content into prompts. Only the top-matching chunks should travel, not whole files; chunk-level granularity is a privacy control, not just a relevance one.
- Citation leakage. Source names appear in answers (that's the point), so name files with the sensitivity they'll carry into conversations.
- Stale embeddings. Deleting a document must delete its vectors. Embeddings can reconstruct content approximately; they are the data, legally and practically.
An evaluation checklist
- Written no-training commitment covering documents, memories, and queries?
- Isolation enforced in the database (RLS) rather than only in application code?
- Per-user scoped endpoints with revocable tokens?
- Full source listing plus true deletion of chunks and vectors?
- Provider sees tool calls only — never full conversations?
- Workspace separation for contexts that must not mix?
- Open-standard access (MCP), so leaving doesn't strand your corpus inside one app?
For the record, this checklist is VeelIQ Context's design brief: RLS isolation on every table, no training on content, metadata-only logging, per-token endpoints, deletable sources, workspaces, and MCP as the only interface. Details in the privacy FAQ and privacy policy.
Key takeaways
- "Private" decomposes into training policy, isolation mechanism, access scoping, deletion semantics, and conversation boundaries — verify each, don't assume the bundle.
- Database-enforced RLS fails closed; application-level filtering fails open.
- Retrieval adds its own risks: context bleed, over-retrieval, and embeddings that outlive deleted files.
- Choose your point on the local↔hosted spectrum consciously; any conscious choice beats the default of pasting files into whatever chat window is open.
Related reading
RLS isolation, no training on your content, tool calls only. Try it with a non-sensitive document first — we'd do the same.