The trust problem
Every clinician I speak to about AI tools for medical literature has the same initial reaction: interest, followed immediately by caution. The interest is genuine — they see the potential of querying their guidelines and textbooks conversationally, of getting cited answers in seconds rather than searching for minutes. The caution is equally genuine — they are not comfortable uploading their medical documents to an AI platform they do not fully understand.
This caution is not irrational. It is informed by experience. Clinicians have watched technology companies promise privacy, then quietly change their terms of service. They have seen data breaches at organisations with far larger security budgets than any AI startup. They have read the stories about AI companies using customer data to train their models — sometimes explicitly, sometimes through vague contractual language that most users never read.
The documents that clinicians would upload to a medical AI tool are not casual files. They include clinical guidelines licensed from professional societies, textbook chapters under publisher copyright, journal articles obtained through institutional subscriptions, and occasionally documents that are patient-adjacent — departmental protocols, clinical pathways, audit reports. The sensitivity ranges from "merely copyrighted" to "potentially identifiable." None of it should be treated casually.
So the question is not whether AI tools for medical documents are useful. They are. The question is whether they can be trusted with the documents that make them useful.
Policy privacy versus architectural privacy
This is the distinction that matters most, and it is the one that most AI companies blur — sometimes deliberately, sometimes out of genuine confusion about their own systems.
Policy privacy means a company tells you, through their terms of service and privacy policy, that they will not misuse your data. They promise not to read your documents, not to share them with third parties, not to use them for model training. This is a contractual assurance. It is enforceable, to varying degrees, through legal mechanisms. And it is entirely dependent on the company keeping its promise.
Architectural privacy means the system is designed so that misuse is not possible — regardless of anyone's intentions. Your data is isolated at the infrastructure level. No other user's query can reach your documents. No staff member has a pathway to access your content. The system does not have a "look at user X's documents" function, because no such function exists in the codebase. Deletion removes all derived data — embeddings, chunks, metadata — not just the original file.
Policy privacy says "we promise not to look." Architectural privacy says "the system makes it impossible to look." One depends on trust. The other depends on engineering.
The difference matters because policies change. Companies get acquired. Terms of service are updated. Business models shift. A company that promises not to use your data for training today may decide, after a funding round or a strategic pivot, that training on user data is essential to their competitiveness. They update the terms, send you an email you do not read, and your documents are now training data.
Architecture is harder to change. If the system is built with tenant isolation from the ground up — if every database query is scoped to the requesting user, if every storage request is authenticated and authorised, if there is no administrative backdoor — then changing this requires re-engineering the system, not just editing a policy document.
What happens when you upload to general AI tools
Understanding what happens to your documents when you upload them to general-purpose AI platforms is important context. The details vary by provider and plan tier, but the patterns are consistent.
When you upload a document to ChatGPT (free or Plus tier), OpenAI's terms of service historically allowed the use of your inputs and outputs for model improvement. They have introduced opt-out mechanisms — you can disable training on your conversations in settings, or use the API with a business agreement that excludes training. But the default, for consumer tiers, has varied over time. The burden is on you to read the terms, find the toggle, and ensure it is set correctly.
Google's Gemini has similar patterns. Consumer-tier usage may be reviewed for product improvement. Workspace tiers have different terms. The specifics change with each product update and each region's regulatory requirements.
The common thread is complexity. The privacy posture depends on which plan you are on, which settings you have configured, which jurisdiction you are in, and which version of the terms of service was in effect when you uploaded. Most clinicians — quite reasonably — do not have time to parse this. They either trust the platform and upload, or they do not trust it and avoid it. There is no middle ground that rewards careful reading.
The complexity itself is the problem. When understanding your privacy posture requires a legal analysis, most users default to either blind trust or complete avoidance. Neither is a good outcome.
How Medevidex implements tenant isolation
I want to be specific about how Medevidex handles document privacy, because vague assurances are exactly the problem I am describing. Here is what the architecture actually does.
Every user's documents are stored in an isolated storage namespace. When you upload a PDF, it is stored in a path that includes your user identifier. No other user's queries, sessions, or API calls can access that path. This is not enforced by a policy check that could be bypassed — it is enforced by the database query structure itself. Every query that touches document content includes the authenticated user's identifier as a filter condition. There is no query path that returns another user's data.
When your document is ingested — processed into text chunks, embeddings, and metadata — all derived data is tagged with your user identifier and stored with the same isolation. Your embeddings (the mathematical representations used for search) cannot be accessed by other users' searches. Your metadata cannot appear in other users' results. The isolation is end-to-end: from the original PDF, through every processing stage, to the final search index.
Staff access to user content does not exist. There is no admin panel that displays user documents. There is no database view that aggregates content across users. The system logs operational metadata — upload timestamps, file sizes, processing status — but not document content. If I, as the operator of Medevidex, wanted to read your documents, I would have to write new code to do it, deploy it, and authenticate as you. The system was not built with that capability.
No training on your documents — and what that means technically
"We do not train on your data" has become a marketing phrase that every AI company uses, often without explaining what it means in practice. Let me be precise.
Medevidex does not fine-tune, retrain, or otherwise modify any AI model based on your documents. When you upload a guideline and ask a question about it, the process is as follows: your document is chunked and embedded (converted into mathematical vectors for search). When you ask a question, the system finds the most relevant chunks from your documents and passes them, along with your question, to a large language model as context. The model generates an answer based on that context. Then the interaction ends.
The language model does not "learn" from your document. It does not retain your content between sessions. It does not become better at answering questions because you uploaded a guideline. Your document is used at inference time — the moment of answering — and nowhere else. This is the fundamental difference between retrieval-augmented generation (which is what Medevidex does) and model training (which is what the large AI companies do with consumer-tier data).
Your embeddings — the mathematical representations of your document chunks — are stored for search purposes. But embeddings are not reversible into the original text. They are numerical vectors that capture semantic similarity. They are useful for finding relevant passages when you ask a question, but they cannot be "read" like a document.
Your documents are used to answer your questions, at the moment you ask them. They are not used to improve AI models, train algorithms, or serve any purpose other than your private retrieval.
Deletion means deletion
When you delete a document from Medevidex, the system removes the original PDF from storage, all text chunks derived from it, all embeddings generated from those chunks, and all metadata extracted during processing. Deletion is not "soft" — the data is not archived, flagged as inactive, or retained for a grace period. It is removed from the database and the storage layer.
This matters because many platforms use the word "delete" to mean different things. Some remove the file from your view but retain it in backups for 30, 60, or 90 days. Some delete the original but retain derived data (embeddings, summaries, extracted text) indefinitely because it is "anonymised" or "aggregated." Some retain data for legal compliance purposes that are not clearly communicated.
Medevidex's deletion is comprehensive. When you remove a document, every trace of it is removed from every storage layer. There is no backup retention window for user content. If you delete your account, all your documents, all derived data, and all usage history are permanently removed. This is a design choice, not an oversight — we chose not to build retention mechanisms for user content because the only purpose they serve is the platform's convenience, not the user's interest.
The copyright concern
Beyond privacy, many clinicians have a related but distinct concern: copyright. Medical textbooks and journal articles are copyrighted material. Clinical guidelines, even when freely available, often carry licensing terms. Is it legal to upload these to an AI platform?
The short answer is that uploading a document to Medevidex for your own private retrieval is analogous to saving a PDF to your personal hard drive or cloud storage and using your operating system's search to find content within it. Medevidex does not redistribute your documents. It does not display them to other users. It does not publish them. It indexes them for your private search and retrieval — the same function that your desktop search, your email client's search, or your cloud storage provider's search performs.
The distinction is between distribution and personal use. If Medevidex took your uploaded textbook chapter and showed it to other users, that would be redistribution — a clear copyright violation. What Medevidex does is index your copy for your private use. You already own (or are licensed to access) the document. Medevidex helps you search it more effectively. The document never leaves your private namespace.
Medevidex is more like a private search engine for your own files than a document sharing platform. Your documents stay yours, are accessible only to you, and are never redistributed.
What to look for in any AI document tool
Whether you use Medevidex or any other tool, here are the questions you should ask before uploading sensitive or copyrighted medical documents. These are the questions I asked myself when deciding how to build Medevidex, and they are the questions I would want answered as a user.
First: is privacy enforced by policy or by architecture? If the answer is "our terms of service prohibit access to your data," that is policy. If the answer is "the system is designed so that no query path can access another user's data," that is architecture. Prefer architecture.
Second: what happens to your data during processing? Some tools send your documents to third-party APIs for processing — OCR, summarisation, embedding. Each hop is a potential exposure point. Understand the full data flow, not just the storage layer.
Third: is your data used for model training? If so, under what conditions? Can you opt out? Is the opt-out default or opt-in? Does it apply retroactively to data already uploaded?
Fourth: what does "delete" mean? Does it remove the original file only, or all derived data? Is there a retention period? Are backups excluded from deletion requests?
Fifth: who can access your data internally? Is there an admin panel that shows user content? Can support staff view your documents when troubleshooting? Are access logs maintained and auditable?
These questions are not paranoid — they are basic due diligence for any tool that handles sensitive professional documents. If a vendor cannot answer them clearly, that tells you something about how seriously they take the issue.
The bottom line
Clinicians deserve AI tools they can trust with their professional documents. Trust is not built by marketing language or privacy badges — it is built by transparent architecture, clear answers to direct questions, and a system that makes misuse structurally impossible rather than merely contractually prohibited.
Medevidex was built by a clinician who had the same concerns you have. I would not upload my own guidelines and textbooks to a system that did not meet the standard I have described in this article. The privacy architecture is not a feature we added after launch — it is the foundation the system was built on.
If you have been hesitant to use AI tools for your medical documents because of privacy concerns, I understand. I hope this article has been specific enough to help you make an informed decision — whether that decision is to try Medevidex or to ask better questions of whatever tool you choose.
Read more
Medevidex vs ChatGPT, Consensus, and OpenEvidence · Why I Built Medevidex · Chat With Your Medical PDFs