AI vendor compliance RFP: a 24-question framework in 4 categories

Reading time: about 10 minutes. Cluster: vendor-eval. Author: Fryderyk.

Answer first

A good RFP for an AI vendor in regulated manufacturing is not a feature wish list. It is a decision tool. It does one job: forcing the vendor to commit on paper to things they will not say on a sales call, and giving you comparable answers across several suppliers. Below is a ready framework: 24 questions across four categories, security, regulatory, architecture and exit, six in each. Every question states its purpose and how to read the answer. Paste it into your request for proposal as is, or trim it to your context.

Contents

1. Why a separate RFP instead of an email thread
2. How to read and score answers
3. Category 1: Security
4. Category 2: Regulatory and compliance
5. Category 3: Architecture and integration
6. Category 4: Exit and continuity
7. How to weight the result and spot red flags
8. What this does not cover
9. Disclosure and biases
10. Related notes

Why a separate RFP instead of an email thread

Three reasons to formalize the request rather than trade emails.

First, comparability. When every vendor answers the same question in the same order, the differences are obvious. Loose correspondence gives you three non-comparable sales narratives.

Second, the audit trail. Under NIS2 the board is accountable for supply chain risk analysis. A dated RFP with questions and vendor answers is a document you produce once and later show an auditor as evidence of due diligence in supplier selection.

Third, binding weight. An answer inside an RFP is easier to carry over into the MSA and DPA as a supplier representation. A verbal assurance from a meeting does not have that weight.

An RFP does not replace technical due diligence or a proof of concept. It narrows the field to the two or three vendors worth taking further.

How to read and score answers

Before the questions, set the scale. A simple scheme that works: score each question 0, 1 or 2.

Two points is a concrete answer with a number, a named standard or a clause you can move into the contract. One point is a directionally sound but non-committal answer. Zero is an evasion, a "that depends" with no follow-through, or silence.

The key rule: weight the categories, do not blindly sum. For an entity under NIS2, the regulatory and exit categories matter more than a feature list. A high security score paired with a zero on exit is not a safe choice. It is dependence on a single supplier with a nice certificate.

Category 1: Security

Six questions about what happens to your data and model, and who can reach them.

1. Where is our data physically processed, and where do prompts and responses go? Purpose: establish whether anything leaves your infrastructure. "In our secure cloud" scores one. "Only in your data center, no prompt ever leaves it" scores two, if the architecture confirms it.

2. How is isolation enforced between tenants, or, for on-prem, between environments? Purpose: check whether your data can bleed into another client or another business unit. Look for a concrete isolation model, not the word "single-tenant."

3. What access does vendor staff have to our data and model, and how is it logged? Purpose: reduce insider risk on the vendor side. A good answer describes break-glass access, full logging and no standing access to production data.

4. How is data encrypted at rest and in transit, and who manages the keys? Purpose: establish whether keys sit on your side. Customer-managed keys are a strong signal.

5. What is your security incident process, and how fast will you notify us? Purpose: align with the NIS2 reporting duty. You need a concrete time window, not "without undue delay."

6. How do you test your own controls, and do you share test reports or certificates? Purpose: separate a claim from evidence. A third-party pentest, a SOC 2 report or an equivalent scores two.

Category 2: Regulatory and compliance

Six questions that connect the vendor to your duties under NIS2, the AI Act and GDPR.

7. Which certifications and standards do you actually hold, not just "we are compliant"? Purpose: separate a held certificate from a claim. Ask for the number, scope and expiry of ISO 27001 or an equivalent.

8. How does your solution support our Article 21 NIS2 duties, in particular risk analysis and supply chain security? Purpose: check whether the vendor understands it is part of your supply chain. "That is your responsibility" is a red flag.

9. Will you sign a DPA, and which processing clauses are non-negotiable for you? Purpose: catch contract friction early. Refusing a DPA where personal data is processed is disqualifying.

10. How do you classify the system against the AI Act, and do you support high-risk obligations? Purpose: establish whether the vendor tracks the AI Act and knows when a manufacturing use case falls into high-risk. Look for Annex III awareness, not generalities.

11. Where is the responsibility boundary between you and us on compliance? Purpose: avoid a gap where "everyone assumed the other side had it." A good answer is a clear responsibility matrix.

12. How do you communicate regulatory changes and updates that affect us? Purpose: check whether compliance is a process, not a one-off statement at signing. The Digital Omnibus and shifting AI Act deadlines show this keeps moving.

Category 3: Architecture and integration

Six questions about how the solution fits your infrastructure and who maintains it.

13. What is the deployment model: on-prem, private environment or cloud, and what exactly runs on our side? Purpose: break marketing "on-prem" into specifics. Establish which components sit with you and which with the vendor.

14. What are the minimum and recommended hardware requirements, including GPU? Purpose: cost the deployment realistically. Concrete sizing numbers score two and feed your TCO model.

15. How does the solution integrate with our systems, and through which interfaces? Purpose: check that you are not buying an island. Standard APIs and documentation are the floor.

16. What does maintenance and model updating look like, and who performs it? Purpose: establish whether you need your own ML ops team or the vendor carries it. This is one of the largest hidden cost lines.

17. How do you log and expose the system's audit trail? Purpose: tie observability to the NIS2 audit requirement. You need an auditable log of who asked what, when, and what came back.

18. How does the solution scale as users and queries grow? Purpose: avoid a pilot that works while production chokes. Look for concrete throughput, not "scales elastically."

Category 4: Exit and continuity

Six questions that usually drop out of RFPs and decide whether in three years you are a hostage to the vendor. This category most often exposes the vendor's real intent.

19. What is the exit process, and in what format do you return our data? Purpose: confirm the data is portable. A standard open format and a clear process score two.

20. What happens to the model, fine-tuning and embeddings built on our data after the contract ends? Purpose: establish whether you take the value you built with you or it stays with the vendor. A common lock-in trap.

21. What dependencies on closed or proprietary components make migration harder? Purpose: map the lock-in layers. An honest vendor names them unprompted.

22. What is the notice period, and are there exit or migration fees? Purpose: catch contract penalties that discourage leaving. A long time lock plus a migration fee is a red flag.

23. What happens if you cease operations or get acquired? Purpose: protect continuity. Ask about code escrow, the right to continued use and a contingency plan.

24. What transition support do you provide if we migrate to another solution? Purpose: check whether exit is supported or sabotaged. A written commitment to cooperate on migration says a lot about the vendor.

How to weight the result and spot red flags

Once the answers are in, score per category, not as one sum. The maximum is 12 points in each of the four categories.

Three signals that outweigh a high overall score. First: a zero in exit. A vendor who cannot describe how you leave is designing dependence. Second: pushing all compliance responsibility onto you in questions 8 and 11. That means they do not understand their supply chain role, or they downplay it on purpose. Third: claims without evidence in security and regulatory, that is, "we are compliant" with no certificate, number or date.

The inverse, positive signal: a vendor who names their own limits and lock-in layers is usually more trustworthy than one who answers everything with a smooth "yes."

Treat the RFP as a filter, not a verdict. Its job is to narrow the field to two or three vendors worth a proof of concept and technical due diligence.

What this does not cover

This framework covers the request-for-proposal stage, not the whole procurement. It does not discuss price negotiation or licensing model, which depend on scale and budget. It does not go into the technical assessment of model quality, retrieval evaluation or benchmarks, which come at the proof-of-concept stage after the RFP. It does not cover your internal procurement workflow, budget approval path or procurement law, which vary between organizations. It also skips specific vendors, because this request is meant to be a tool, not a ranking.

// disclosure & biasesDisclosure and biases

I write from an on-prem and architecture perspective for entities under NIS2, so questions about data location, isolation and exit carry more weight here than in a typical SaaS RFP. That is a deliberate choice, not neutrality. If your regulatory context is lighter, you can soften parts of the exit and security categories. This framework is not legal advice. You set the scope of your NIS2, AI Act and GDPR duties with your own legal and compliance teams, because it depends on entity classification and system use.

Related notes

• Vendor security review for AI: 12 questions before signing an MSA
• On-prem AI vs cloud TCO: how to calculate over three years
• AI vendor lock-in: three layers and two contractual traps
• AI Vendor DPA: 8 clauses whose absence breaks your audit
• NIS2 audit readiness for AI: the 7 documents an auditor asks for