AI Vendor Security Assessment: GxP Supplier Qualification for AI Vendors

The standard procurement artefact is a spreadsheet the vendor completed about itself, returned to a buyer who has no practical way to test any individual answer. That is a useful structured disclosure. It is not diligence, and the market already knows it: research cited by Vanta reports that only 34% of third-party risk management professionals believe questionnaire responses are accurate, and that a single questionnaire takes somewhere between five and fifteen hours to complete.

Two things follow from that number, and they point in the same direction. The first is that adding more questions does not add more assurance. If the instrument is distrusted, a longer instrument is distrusted at greater cost to both sides. The second is that verifiable evidence beats volume of answers by a wide margin. A vendor that names its model provider and cites the specific contractual clause governing training on customer data has told you more in one line than a two-hundred-question spreadsheet of yes and no.

The failure mode is rarely dishonesty. It is that the person completing the questionnaire is answering in good faith about a general product while you are buying a specific deployment, and the general answer and the specific answer diverge in exactly the places that matter. Data residency is the clearest example: a company can be headquartered in the EU, hosted in the EU, and still process your prompts in whatever geography its chosen deployment type routes to. The questionnaire has no field for that distinction, so it is answered "yes" and nobody has lied.

An assessment is therefore not a longer questionnaire. It is a short list of high-consequence claims, each of which is checked against a primary source: a contract clause, a configuration state the vendor can demonstrate, a scope statement on a certificate, a report section, a published sub-processor list. Everything else can be taken on disclosure. This is what makes the work finishable in days rather than becoming an open-ended audit that nobody completes before the purchase order is signed.

It also means that the output has to record what could not be verified. An assessment that presents only what was confirmed is a sales document. The useful deliverable states plainly which claims were checked against evidence, which were accepted on the vendor's word, and which the vendor declined or was unable to answer. The third category is usually the most informative part of the file.

The point of an assessment is not to collect more answers. It is to decide which few answers you are going to insist on being able to prove.

This is not a new or speculative obligation created by AI. The current Annex 11 to the EU GMP guide came into operation on 30 June 2011 and its section 3 covers suppliers and service providers directly. Chapter 7 on outsourced activities came into operation on 31 January 2013 and was revised specifically to align with ICH Q10, so that it covers outsourced GMP activities beyond contract manufacture and analysis. A software service is squarely within its scope.

Annex 11 section 3.1 requires that where third parties provide, install, configure, integrate, validate, maintain, modify or retain a computerised system, or process data, "formal agreements must exist" with "clear statements of the responsibilities of the third party" — and it adds that internal IT departments "should be considered analogous". Section 3.2 states that "the competence and reliability of a supplier are key factors when selecting a product or service provider" and that "the need for an audit should be based on a risk assessment". That sentence is the legal basis for the supplier audit request that lands, often unexpectedly, on a SaaS vendor's desk.

Section 3.4 is the clause that catches AI vendors out, and it deserves to be read slowly: "Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request." A regulator can ask to see the vendor's quality system evidence through the customer. A confidential report the customer has never been permitted to retain does not automatically satisfy that. Section 4.5 adds that the regulated user "should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system" and that "the supplier should be assessed appropriately".

Chapter 7 sharpens the test. Section 7.5 states that "prior to outsourcing activities, the Contract Giver is responsible for assessing the legality, suitability and the competence of the Contract Acceptor". Three separate tests, and a security attestation speaks to at most one of them. Section 7.4 places ultimate responsibility with the Contract Giver. Section 7.11 requires that the Contract Acceptor "should not subcontract to a third party any of the work entrusted to him under the Contract without the Contract Giver's prior evaluation and approval" — which, for an AI product whose model provider is a subcontractor, is a hard requirement rather than a courtesy notification. Section 7.13 states that outsourced activities "may be subject to inspection by the competent authorities": a software vendor selling into GMP can be inspected.

ICH Q10 is the parent text Chapter 7 was aligned to. Its section 2.7 states that "the pharmaceutical company is ultimately responsible to ensure processes are in place to assure the control of outsourced activities", and requires assessment of "the suitability and competence of the other party" before outsourcing, using audits, material evaluations and qualification. ICH Q9(R1), adopted at Step 4 on 18 January 2023, supplies the proportionality rule that keeps this sane: "the level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk", and the evaluation of risk "should be based on scientific knowledge and ultimately link to the protection of the patient".

Read together, these texts do something that a security framework never does. They locate accountability in a specific legal person — the regulated user — and then require that person to produce evidence about somebody else's organisation. That inversion is why a vendor assessment in life sciences is an obligation you own rather than a service you buy, and why the deliverable has to be something you can hold and explain, not something the vendor holds on your behalf.

On 7 July 2025 the European Commission opened a joint stakeholder consultation on three EudraLex Volume 4 documents: a revised Chapter 4 on documentation, a revised Annex 11 on computerised systems, and an entirely new Annex 22 on artificial intelligence. The consultation closed on 7 October 2025. As of 27 August 2026 no final text has been published, so everything in this section is draft language and must be read as such. It is nonetheless the clearest available statement of what regulators expect, and it is already shaping supplier questionnaires.

The draft Annex 11 grows to seventeen sections, and section 7 is retitled "Supplier and Service Management". Section 7.1 addresses reliance on a vendor's own qualification work directly: "When a regulated user is relying on a vendor's qualification of a system used in GMP activities … this does not change the requirements put forth in this document. The regulated user remains fully responsible for these activities based on the risk they constitute on product quality, patient safety and data integrity." There is no reading of that sentence in which buying a certified product transfers the obligation.

Section 7.2 sets the depth of work: the regulated user "should, according to risk and system criticality, conduct an audit or a thorough assessment to determine the adequacy of the vendor or service provider's implemented procedures, the documentation associated with the deliverables, and the potential to leverage these rather than repeating the activities." The phrase "rather than repeating the activities" is important and is often missed. The draft is not asking you to re-validate the vendor's software. It is asking you to determine, on evidence, how much of the vendor's work you are entitled to lean on.

Section 7.4 is the requirement that no attestation report satisfies on its own: documentation "is accessible and can be explained from their facility". Not held by the vendor. Not available on request under an NDA that forbids retention. Accessible, in your building, and explainable by your people to an inspector who is standing in front of them. If your only artefact is a confidential report your quality lead has not read, you do not meet this description, however good the report is.

Section 7.5 then sets a nine-point minimum for the contract itself: the activities and documentation to be provided; the company procedures and regulatory requirements to be met; regular, ad hoc and incident reporting with service levels, key performance indicators, answer and resolution times; "conditions for supplier audits"; "support during regulatory inspections, if so requested"; issue resolution; "requirements and processes for communication of quality and security related issues"; "an exit strategy by which the regulated user may retain control of system data"; and "the process for release of new system versions and on the regulated user's possibility to test these prior to release".

The last two items are the ones that collide hardest with how modern software is actually built and sold. An exit strategy that returns control of system data is not a data deletion clause; it is a data return clause with a format obligation attached. And a customer right to test new versions before release is structurally incompatible with continuous deployment and with silent model version changes. Neither is impossible — several vendors already offer pinned versions, release channels and advance notice windows — but they have to be negotiated before signature, because they are architecture decisions as much as contract terms.

Draft Annex 11 section 7.4 is the sentence to bring to a vendor call: the documentation must be "accessible and can be explained from their facility".

Put the two documents side by side and the mismatch is not a matter of rigour. A SOC 2 Type 2 report can be an excellent, demanding piece of work and still leave every GxP question open, because it was built to answer a different question for a different reader.

Start with what a SOC 2 report is. It is an attestation examination performed under AICPA attestation standards by a licensed CPA firm, resulting in a report containing a practitioner's opinion against the Trust Services Criteria — formally TSP section 100, the 2017 criteria with revised points of focus issued in 2022. The five trust services categories are Security, Availability, Processing Integrity, Confidentiality and Privacy. Only Security, the common criteria, is mandatory; the other four are elective and appear only if the service organisation chose them. So the first question about any SOC 2 report is which categories are in scope, and a report covering Security alone says nothing about availability or privacy.

Now map that onto draft Annex 11 section 7.4. The report is normally provided under a non-disclosure agreement, frequently on view-only terms, and its contents are the vendor's confidential information. Your quality unit cannot usually retain it, cannot excerpt it into a supplier file, and often cannot explain its control set from your facility. Chapter 7 section 7.11 asks something the report does not attempt: prior evaluation and approval of the subcontractors, which for an AI product means the model provider by name. Section 7.13 asks whether the vendor understands it may be inspected by a competent authority, which is a contractual commitment, not an audit finding.

The gap is not filled by choosing a stricter framework either. ISO/IEC 27001 certifies a management system within a declared scope. ISO/IEC 42001 certifies an AI management system. HITRUST verifies a prescriptive control set. All three are third-party conformity assessments of the vendor's own programme. None of them produces the artefact that your inspector will ask you for, which is your assessment, in your file, with your risk rationale, referencing evidence you can access.

This is why the practical recommendation for a small vendor selling into GMP is often counter-intuitive. If your buyer is a GMP manufacturer, spending the certification budget on a validation support package, an audit-ready quality manual and a GxP-competent contract answers the question that is actually being asked, whereas an ISO certificate scoped to corporate IT does not. That is the same analysis run from the seller's side, and it is the subject of our security questionnaire readiness work, linked below.

None of this argues for ignoring security attestations. They are the fastest available signal that a vendor has an operating security programme, and their absence in a company of any size is itself informative. The argument is narrower and it is about sequencing: read the report properly, then run the supplier assessment, and do not let the first stand in for the second.

The credible answer is a contractual clause and a named provider, not a paragraph on a marketing page. The clauses exist and are public, which makes this one of the easier claims to verify properly.

Anthropic's Commercial Terms state it flatly: "Anthropic may not train models on Customer Content from Services." OpenAI's platform documentation is equally explicit for the API: "As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)", and its enterprise privacy page states that custom models "are yours alone to use and are not shared with anyone else". Microsoft's Azure AI Foundry documentation states that prompts, completions, embeddings and training data "are NOT used by providers of Models sold by Azure to improve their models or services", and adds that the models are stateless: "no prompts or completions are stored in the model".

So the question to the vendor is not whether such commitments exist. It is which of them applies to the deployment you are being sold, whether the vendor sits on the enterprise tier or the consumer tier of its provider, and what happens if the vendor changes provider. A vendor that reserves the right to substitute model providers at will has an unresolved problem under GDPR Article 28 and, in a GMP context, under Chapter 7 section 7.11.

There is a second-order version of this question that is asked far less often and matters more: is our data used to train the vendor's own models, as distinct from the underlying provider's? A vendor can accurately state that OpenAI does not train on your data while itself fine-tuning a classifier on pooled customer content. If a vendor fine-tunes on pooled customer data, that is a materially different product and it must be disclosed. Azure documents the isolated case as the norm — "fine-tuned models are exclusively available to the customer whose data was used to create the fine-tuned model" — which gives you a reference point for what good looks like.

This is where "we do not train on your data" quietly stops being the whole answer. Not training is a statement about model weights. It is not a statement about storage, and the storage is where your obligations bite.

OpenAI documents the default plainly: "By default, abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law." Zero Data Retention and Modified Abuse Monitoring are available but, in the same documentation, "these controls are subject to prior approval by OpenAI and acceptance of additional requirements". Azure operates a parallel application path for modified abuse monitoring and publishes something unusually useful: a verifiable check, where a "ContentLogging" value in the capabilities list appears and reads false when abuse-monitoring logging is off.

The right request is therefore to see the approval and the configuration state, not to receive an assertion. This is one of very few places in AI diligence where a claim can be independently confirmed in a few minutes, and a vendor that has actually obtained modified abuse monitoring will be pleased to show you, because it was not easy to get.

The consequences reach beyond privacy hygiene. A HIPAA business associate agreement must, under 45 CFR section 164.504(e)(2)(ii)(J), require the associate at termination, if feasible, to "return or destroy all protected health information" and "retain no copies of such information". A rolling thirty-day store of prompts is a copy. Equally, the access, amendment and accounting-of-disclosures obligations at (E) to (G) collide with architectures in which content has been transformed into embeddings that cannot be individually located, corrected or enumerated. These two clauses are the first thing a knowledgeable healthcare reviewer asks about, and most AI vendors have not thought about either.

GDPR produces the mirror-image requirement. Article 28(3)(g) requires the processor to delete or return personal data at the end of the service unless retention is legally required. If the vendor's answer to deletion is "the data ages out of the log in thirty days", that is a retention schedule, not a deletion capability, and the difference will matter to your data protection officer.

The model provider is a sub-processor. That single sentence resolves a surprising amount of confusion, because it places the model provider inside a legal framework everyone already understands rather than in a special category.

Under GDPR Article 28(2), a processor may not engage a sub-processor without prior specific or general written authorisation, and under a general authorisation it must inform the controller of intended changes and give the controller the opportunity to object. Article 28(4) requires equivalent obligations to flow down and keeps the original processor fully liable for the sub-processor's performance. A vendor that will not name its model provider, or that reserves the right to swap it silently, has an unresolvable problem under those provisions before you even reach GMP. Chapter 7 section 7.11 then adds the harder requirement in a regulated context: prior evaluation and approval, with the suitability assessment information passed through.

Residency is the question most often answered wrongly, and the reason is that it is now a deployment-type question rather than a company-level one. Microsoft states the mechanics without euphemism: "For any deployment type labeled 'Global,' prompts and responses may be processed in any geography where the relevant model sold by Azure is deployed." A vendor can be an EU company on EU infrastructure and still process prompts globally, and the person filling in your questionnaire may not know it.

Break residency into four separate answers. Where is inference processed? Where does data sit at rest? Where does the abuse-monitoring and human-review store sit? And where are the humans who may read flagged content physically located? Azure answers the last of these for EEA deployments — "the authorized Microsoft employees are located in the European Economic Area" — and documents the access controls in a way that is worth using as a benchmark for other vendors: human reviewers access flagged data "via point wise queries using request IDs, Secure Access Workstations (SAWs), and Just-In-Time (JIT) request approval granted by team managers". That is the level of specificity to hold vendors to. If a vendor cannot describe its own human-review path in comparable terms, it probably has not designed one.

For transfers out of the EEA, the current standard contractual clauses are in Commission Implementing Decision 2021/914 of 4 June 2021, which replaced the three earlier sets adopted under Directive 95/46 and are modular. For United States processing, the EU-US Data Privacy Framework adequacy decision remains the simplest route, and the EU General Court dismissed the Latombe challenge to it on 3 September 2025. Treat the framework as valid but not permanently settled — the court itself stressed that the Commission "is required to monitor continuously the application of the legal framework" on which the decision is based, and an appeal was filed. A vendor relying solely on the framework should still be able to fall back to standard contractual clauses.

Isolation questions in a standard questionnaire tend to be answered at the level of the application database. For an AI product the interesting boundaries are elsewhere, and they are frequently newer, less tested and less documented than the application itself.

Ask specifically about three things: the abuse-monitoring store, the vector store, and any stateful entity such as threads or stored completions. Azure states that its abuse monitoring data store "is logically separated by customer resource", which is an honest description — logical rather than physical separation is the norm across the industry and should be stated as such rather than dressed up. A vendor claiming physical isolation should be able to explain what that means concretely, because the phrase is often used loosely.

Vector and embedding stores deserve their own line of questioning because they are where the assumptions from the relational world break down. OWASP's Top 10 for LLM Applications names "Vector and Embedding Weaknesses" as LLM08 precisely because embeddings created from one tenant's documents can leak information through a shared index, and because embeddings are difficult to delete selectively, difficult to audit, and difficult to explain to a data protection officer. The same list names "Excessive Agency" as LLM06, which is the risk that matters most as vendors add tool use and autonomous actions to their products.

Fine-tuning separation should be answered in one sentence and backed by architecture. The reference statements exist: Azure documents that fine-tuned models are exclusively available to the customer whose data created them, and OpenAI states that custom models are not shared with anyone else. If the vendor's answer is longer or more conditional than those, the condition is the finding.

Finally, ask what happens on the retrieval side of the product rather than the model side. In our first engagement at a clinical-stage biotech client, connected AI reached employee-information files in Box through existing user permissions — nothing was misconfigured at the vendor and no control failed. The permissions were simply broader than anyone had realised, and the assistant was the first tool efficient enough to notice. A vendor assessment cannot find that, which is why it belongs in a separate piece of work on your own environment.

The last two questions are the ones a security questionnaire never asks and a quality reviewer always asks. They are also the two that most often decide whether a tool can be used in a regulated process at all.

Human oversight is not a user-experience question in a GxP context; it is the compliance question. Draft Annex 22 requires that where generative models are used in non-critical applications, "personnel with adequate qualification and training should always be responsible for ensuring that the outputs from such models are suitable for the intended use, i.e. a human-in-the-loop (HITL)". That phrase is only meaningful if your organisation can say who reviews, what evidence they inspect, what qualification they hold, what they are permitted to approve, how exceptions are handled and what record is retained. A vendor can support that design or obstruct it, and the difference is visible in the product: whether outputs carry sources, whether a reviewer can see what the model was given, whether an approval is recorded.

Change control on the model is the question that separates a supplier assessment from a security review most sharply. A silent model version bump is a change to a validated system. Draft Annex 11 section 7.5 addresses it directly by requiring agreement on "the process for release of new system versions and on the regulated user's possibility to test these prior to release". In practice this means asking whether the vendor offers pinned model versions, what notice period applies to a change, whether behaviour-affecting prompt or system-message changes are treated as versioned changes, and what regression evidence the vendor produces. Most AI vendors have a deployment pipeline built for the opposite objective, which is to ship improvements continuously and invisibly.

The EMA reflection paper on artificial intelligence in the medicinal product lifecycle, adopted by CHMP on 9 September 2024, sets the expectation for third-party models where the stakes are high: "if a third-party AI model or service is to be used within the medicinal product lifecycle with high regulatory impact or high patient risk, it is expected that the manufacturer of the system has provided such details through a methodology qualification process … covering the specific context of use". It also notes, in a sentence worth quoting to any vendor that considers these requirements unusual, that the applicable requirements "may in some respects be stricter than what is considered standard practice in the field of data science".

Governance evidence is the cheap part of this and can be requested early: an ISO/IEC 42001 certificate with its scope, alignment with the NIST AI Risk Management Framework, an AI-CAIQ or STAR for AI submission, model cards, and evaluation results. None of these is conclusive and all of them are informative, mostly because of what a vendor chooses not to provide.

A silent model version change is a change to a validated system. That is the question a security questionnaire never asks and a GxP reviewer always asks.