What You Are Actually Uploading
When a medical affairs team evaluates a knowledge platform, it is easy to think about the tool in functional terms: can it answer questions about our documents, can it track label changes, can it integrate with Veeva? Those are valid questions. But before any of that matters, there is a more foundational question: what happens to the documents once they are uploaded?
The documents medical affairs teams upload to a knowledge platform are not marketing brochures. They are clinical study reports containing patient-level aggregate data, investigator brochures with pre-approval pharmacokinetic data, unpublished label drafts still under FDA review, internal medical affairs Q&A libraries with analysis that has not gone through external publication, and regulatory authority correspondence. Some of these documents contain confidential business information whose exposure to a competitor would be commercially damaging. Some contain information that, in the wrong context, would constitute a regulatory problem. None of it should be treated casually.
The vendor assessment questions we walk through below are not about technical compliance boxes. They are about understanding exactly what the vendor does with your data, on what infrastructure, under what contractual terms, and with what oversight. The answers to these questions are what a pharma legal and privacy team will ask for in vendor due diligence. Medical affairs teams who bring these questions to a vendor evaluation before legal gets involved close deals faster and avoid contract renegotiations.
Where Does the Data Live, and Who Can Access It
The first question is straightforward but requires a precise answer: where, physically, is the data stored? Cloud-hosted platforms vary significantly in their deployment architectures. A vendor that stores all customer data in a shared multi-tenant environment is a different risk profile from a vendor that offers dedicated tenant isolation, either within a shared cloud region or in a dedicated cloud deployment.
For pharma companies with strict data residency requirements, the specific cloud region matters. EU clinical data may need to stay within the EU. Some organizations require data to remain in US-based infrastructure. Confirming the available deployment options before you are deep in a pilot saves negotiation time later.
Access controls matter as much as data residency. Ask specifically: which vendor employees can access customer documents? Under what circumstances? Is access logged? Is the log available to the customer on request? A vendor that can access your uploaded documents for support or troubleshooting purposes should be able to tell you exactly when that access has occurred, who performed it, and what was accessed. This is standard in enterprise software procurement for regulated industries; a vendor who cannot answer the question clearly is not mature enough for pharma data.
Does the Vendor Use Your Documents to Train Models
This is the question medical affairs teams often forget to ask, and it is the one that carries the most significant long-term risk. Several AI knowledge platform vendors use customer-uploaded documents as training data for their underlying language models, either in aggregate or with some anonymization step. If your clinical study reports and internal medical affairs analyses are being used to improve a model that the vendor will also sell to your competitors, that is a problem worth understanding before you sign anything.
The question to ask is not "do you use our data for training?" but rather: "describe every use of customer-uploaded documents beyond answering queries in our own workspace." The answer should be precise. If the vendor's response involves language like "we may use aggregated data to improve model performance," ask specifically what "aggregated" means and whether it includes document content or only usage metadata.
A vendor with a clear commitment to not using customer documents for model training should be able to state that directly in the Data Processing Agreement. If the DPA is vague on this point, it is worth negotiating explicit contract language before upload of any confidential documents. This is not a burdensome ask for a reputable vendor; it is a standard term in enterprise AI vendor contracts for regulated industries.
At Argon, our design commitment on this point is direct: your documents are not used to train our models, and this is reflected in the contractual terms we offer every customer. We say "design commitment" rather than "certified compliance" because we are being precise: we have built the platform with this principle as a hard constraint, but we are an early-stage company and will point you to our DPA terms rather than claim a certification we have not yet been audited for.
Security Architecture: What Controls Are Actually in Place
A vendor who says "we take security seriously" without specifics has told you nothing. The questions that generate meaningful answers are more granular.
Encryption: are documents encrypted at rest and in transit? What encryption standard is used (AES-256 at rest is current industry practice)? Who holds the encryption keys? Customer-managed keys, where the pharma company holds the decryption key rather than the vendor, are available on some platforms and provide an additional layer of data control.
Authentication: does the platform support single sign-on via SAML 2.0 or OIDC, allowing you to manage access through your existing identity provider? Multi-factor authentication should be required, not optional, for any platform handling clinical documents. Ask whether administrators can enforce MFA at the tenant level or whether it is left to individual users.
Audit logging: what user actions are logged? At minimum, you want document upload events, query events, and document download or export events to be logged with user identity, timestamp, and IP address. These logs need to be customer-accessible, not just retained internally by the vendor, because you may need them for internal compliance review or external regulatory audit.
Penetration testing: reputable vendors in the SaaS space conduct third-party penetration tests annually. Ask when the last test was conducted and whether they will share a summary report or attestation. A vendor who refuses to disclose any penetration testing history is not mature enough for your data.
Workspace Isolation for Multi-Brand Environments
Many medical affairs teams support multiple products, and in larger organizations, the teams supporting different products may have intentionally separate knowledge access: an MSL for an oncology product should not have access to the clinical study reports for a rare disease program still under regulatory review. This kind of brand-level isolation is not just a nice-to-have; in some organizations it is required by medical, legal, and compliance operating procedures.
Ask the vendor: does the platform support workspace-level isolation where different products or brands are separated into distinct environments with separate permission controls? Can a user have access to Workspace A but not Workspace B within the same organizational tenant? Is that separation enforced at the data layer (meaning the platform itself prevents cross-workspace query) or only at the application UI layer (meaning a technical bypass would theoretically be possible)?
For organizations with particularly sensitive separations, for example a product under clinical hold or a pre-approval program, application-level separation may not be sufficient. Data-layer isolation with separate storage and no shared retrieval index is the right requirement to specify.
Contractual Protections: What the DPA Should Actually Say
The Data Processing Agreement is the contractual instrument that governs the vendor's handling of your data. A well-drafted DPA for a pharma knowledge platform should address: the purpose and scope of data processing (narrowly defined: answering queries, providing the service), any sub-processors the vendor uses (cloud infrastructure providers, logging services), data retention and deletion commitments (including deletion on contract termination), breach notification timelines (72 hours to notify is standard), and the no-model-training commitment described above.
The DPA should also specify the mechanism for your right to access and audit. If your organization is subject to a regulatory audit that requires you to document your data handling practices for tools used in the medical affairs workflow, you need to be able to produce records. The DPA should confirm that the vendor will cooperate with such audits within a defined timeframe.
One area where pharma companies sometimes accept vague language and regret it later: the definition of what happens to data when you terminate the contract. "We will delete your data within 30 days of contract termination" is the right commitment. "We will make your data available for export for 30 days after termination, then delete it" is acceptable if the export mechanism is defined and functional. Vague language that does not specify a deletion timeline or that excludes backup copies should be tightened in negotiation.
The Vendor Due Diligence Conversation Worth Having Early
The best time to have these conversations is before a pilot agreement is signed, not during or after. A vendor who is not prepared to answer these questions before a pilot may become much harder to negotiate with once your team has adopted the tool and switching costs are real.
The questions here are not intended to be used as a filter to eliminate vendors with imperfect answers. They are intended to generate honest, specific answers that your legal and privacy team can evaluate. An early-stage vendor with strong privacy-by-design architecture but without SOC 2 Type II certification is a different conversation from an early-stage vendor that cannot clearly answer where your data lives. The former is a matter of audit timing; the latter is a matter of fundamental design commitment.
Medical affairs teams are uploading serious documents into these platforms. The due diligence investment is proportional to the sensitivity of what gets uploaded. For a team indexing only publicly available publications and label documents, the risk profile is modest. For a team planning to upload unpublished clinical study reports and investigator brochures, the contractual and technical protections described above are not optional safeguards. They are the baseline requirement.