Before you upload a single privileged file to any AI research tool, you want a straight answer to one question: who actually sees the text, and what happens to it after. Marketing pages promise security in the abstract. A compliance reviewer does not accept the abstract — they want the real data flow, vendor by vendor, step by step. Vorticel is a private, multi-tenant AI research assistant for law firms: firms upload their own documents and get grounded, cited answers pulled only from those files, never from outside knowledge. This article walks through what happens to a document from the moment you upload it to the moment an answer comes back, and names every vendor that touches any part of it along the way.
What Happens to a Document the Moment You Upload It?
The file is tagged with your firm's account before anything else touches it, then encrypted with a per-firm key before it is written to disk. From that point, the original file stays encrypted in storage and is decrypted only for your own firm's use — no later step in the pipeline touches the original file again.
- Upload — the file moves over an encrypted connection and is tagged with your firm's account.
- Encryption at rest — the document is encrypted with a per-firm libsodium key before it touches disk.
- Text extraction and embedding — extracted text, not the original file, is sent to Voyage AI to be converted into numeric embeddings for search.
- Retrieval — when someone asks a question, the system finds the closest-matching passages by comparing embeddings, scoped to your firm's tenant boundary.
- Drafting — only the retrieved passages, not the whole document, are sent to Anthropic's Claude to draft a cited answer.
Document text reaches the embedding vendor exactly once, at ingest — it is not re-sent on every question a user asks afterward. This narrow scope is deliberate: extracted text, not the file object itself, is what the search step needs to leave storage, so that is the only thing that does. When you later ask a question, the system does not fall back on anything the underlying language model already knows about your topic generally — the answer is built only from the passages retrieved for that question, and if nothing in your uploaded documents answers it, the system says so instead of guessing. That refusal behavior matters for confidentiality too: the model is never asked to fill a gap with outside knowledge that could blend into what looks like your firm's own material.
Which Outside Vendors Actually See Your Document Text?
Two: Voyage AI and Anthropic, and each receives a different, minimal slice of your data. Voyage AI, a MongoDB company, receives extracted document text to generate search embeddings; Anthropic receives only the passages retrieved for a specific question, never a whole document, to draft the answer.
| Vendor | What it receives | When | What it does not receive |
|---|---|---|---|
| Voyage AI | Extracted document text (not the original file) | Once, at ingest | The original PDF or DOCX file, or any data outside the document's text |
| Anthropic | Only the passages retrieved for one question | At query time, per question | The rest of the document, or any other firm's data |
Anthropic receives only the passages retrieved for a single question, never the full document that question was asked about. Neither vendor trains any model on your data — the full sub-processor list and what each one receives is published on the security page, so a reviewer can check it directly rather than waiting on a sales call.
What Does Per-Firm Encryption Actually Protect Against?
Per-firm encryption means each firm's stored documents use a distinct key, so a compromised key or a misdirected query cannot decrypt another firm's files. Combined with tenant isolation at the database layer — every document, passage, and answer tagged to a firm_id — this closes off the most common cross-tenant leak path in multi-tenant software.
That leak path is worth naming plainly: the most common way one customer's data reaches another customer in multi-tenant software is not a broken encryption algorithm, it's an unscoped database query that returns the wrong account's rows. Encryption at rest protects data if a disk or a backup is stolen. It does nothing to stop a buggy query from handing another firm's decrypted rows to the wrong logged-in user. Tenant isolation at the query layer is the control that actually stops that. The two solve different problems, and a compliance review should ask about both separately instead of letting an encryption claim stand in for a tenant-isolation claim.
When you ask a vendor's security team about this, ask for both proofs, not one: a description of the encryption method and key scope, and a description of how tenant scoping is enforced in the code path that serves a query — for example, whether every database fetch requires an account identifier as a mandatory parameter. The second question is harder to answer with a checklist, and it is the one that actually predicts whether a bug could leak data across firms.
Verifying all of this yourself, one vendor and one control at a time, is exactly the kind of diligence work that eats a reviewer's week. Vorticel's documentation lays out the same data flow, the citation format an answer must include, and the retrieval settings in one place, so you can check the mechanism instead of taking a claim on faith.
Is It Safe to Upload Privileged Material at All?
A sub-processor, in privacy and vendor-diligence language, is any third party a vendor uses to process your data on its behalf — the term shows up in data processing agreements for exactly this reason. When you review an AI tool's terms, look for a named, dated sub-processor list, not a clause that reserves the right to add processors later without notice. A vendor that will not commit to naming its sub-processors in writing is asking you to trust a claim it will not put in a contract.
It depends on whether the tool's sub-processor list is public, minimal, and matches what the product actually does — not on a security page's tone. Two named vendors touching narrowly scoped data, with no training on your data and encryption applied before anything is written to disk, is a materially smaller exposure than what most firms already accept by emailing an attachment to opposing counsel or storing it in a general-purpose cloud drive with no per-tenant key at all.
If a vendor cannot tell you which company sees what text and when, treat that as a red flag on its own. A tool that names its sub-processors specifically, and states plainly that none of them trains on your data, is easier to write into an engagement letter's confidentiality language than a black box. Our earlier piece on questions to ask an AI vendor before uploading client documents covers the rest of that conversation, and the compliance review checklist turns this data-flow knowledge into a sign-off list.
How Do You Check This Before You Upload a Real File?
Start with a document that carries no privilege at all — a template, a public filing, a form contract — and trace one question through the system end to end. Upload it, ask a question you already know the answer to, and read the citation the answer returns: it should point to the specific document and page the text came from, not a vague reference.
That single test tells you whether the retrieval and citation behavior match what this page describes before you risk anything privileged. Create a free account and run it — the trial is 14 days, no card required, and nothing you upload during it trains any model.
Start a free trial and upload one non-privileged document to see the citation behavior for yourself.