What should an RFP for an LLM gateway or AI platform include?

Where data is processed, what is retained, who may train on it, the sub-processors and the DPA, identity and access (SSO, SCIM, keys), spend control, which models and providers are allowed, audit logs and export, AI Act deployer support, exit terms and the SLA. This template covers each area with 43 requirements and the evidence to request.

Can public buyers use this template in a tender?

Yes. It is free to copy and edit. Public buyers typically use it as the technical requirements annex and attach the voluntary EU model contractual AI clauses (MCC-AI) to the contract. Check the requirements against your procurement rules and mark which are mandatory before publishing.

What are the EU model contractual AI clauses?

Template clauses for buying AI systems, published by the Community of Practice on Public Procurement of AI on the Commission's Public Buyers Community. The March 2025 update has a full version for high-risk AI and a light version for other AI. They are voluntary and are meant to be annexed to a contract, which still has to cover data protection, liability and intellectual property.

Is a model provider a sub-processor of an AI gateway?

Usually yes. When a gateway forwards prompts that contain personal data to a model provider, that provider processes the data on the gateway's behalf. That is why rows 13 and 14 ask for a sub-processor list that includes inference providers and for notice before new ones are added.

How long should an AI platform keep request logs?

For high-risk uses, AI Act Article 26(6) asks deployers to keep the logs under their control for at least six months, unless other law provides otherwise. Many buyers ask for 12 months of metadata-only request records and no stored content.

RFP and tender requirements for an LLM gateway or AI platform

Updated 9 November 2026. Free to copy, edit and use in your own tender documents.

A company or public body that buys access to large language models for its staff and applications usually buys a gateway: one account and one API in front of several model providers. This template lists 43 requirements for that purchase, grouped the way a security and procurement review works through them. Each one says why it matters and which evidence to ask the supplier for.

It is vendor-neutral and works as a requirements annex for a request for proposal, a public tender or a supplier security review. For AI-specific contract terms, pair it with the voluntary EU model contractual AI clauses published on the Commission's Public Buyers Community in March 2025.

Download the template (.md)Spreadsheet (.csv)

The CSV opens in Excel, Google Sheets or Numbers, with empty columns for weight, the supplier's answer and the evidence received.

The requirements

Each requirement is written so a supplier can answer it in one paragraph and attach the evidence. Mark the ones that are mandatory for you, weight the rest, and delete what does not apply.

1. Data location

No.	Requirement	Why it matters	Evidence to request
1	Processing region. The supplier can restrict inference to a region the buyer names, such as the EU/EEA or Europe, for the whole organisation, a team or a single API key, including retries and fallbacks.	Why it mattersGateways fail over between providers. Without a region rule that covers every attempt, a fallback can move a prompt to another jurisdiction without anyone noticing.	Evidence to requestThe routing policy for restricted traffic, the endpoints allowed per region with their locations, and what happens when no endpoint in the region can serve a request.
2	Region definition. The supplier states which countries each region covers, for example EU/EEA only, or also the UK, Switzerland or other countries.	Why it mattersSales material often uses Europe and EU interchangeably. Your transfer assessment depends on the exact list.	Evidence to requestA written definition per region and the processing location of every sub-processor in it.
3	Ingress and gateway location. The supplier states where TLS terminates, where the gateway runs and which hostname to use for regional processing.	Why it mattersA request can be served by a model in the right region and still pass through a global edge network first.	Evidence to requestHostnames per region, the hosting provider and region of the load balancer and the gateway, and a data flow diagram.
4	Metadata and log location. The supplier states where account data, usage records, operational logs, backups and email are stored and processed.	Why it mattersResidency answers often cover prompts only. Metadata still holds personal data such as names, email addresses and IP addresses.	Evidence to requestA storage location per data category, including backups and transactional email.

2. Retention and zero data retention

No.	Requirement	Why it matters	Evidence to request
5	No storage of content by the supplier. The supplier processes prompts and outputs only to serve the request, or states exactly what content it stores, where and for how long.	Why it mattersThe gateway sees every prompt your organisation sends. Its own retention is the first exposure to check.	Evidence to requestA data flow description, the log schema showing which fields are written, and the matching DPA clause.
6	Zero data retention at model providers. The buyer can require that requests go only to model endpoints that commit to keeping no copy of the content, at organisation, team or key level, and lower levels cannot switch it off.	Why it mattersModel providers commonly keep prompts for a period for abuse monitoring unless a zero-retention arrangement applies to the endpoint.	Evidence to requestRetention terms per provider, how the setting is enforced on each request, and which features are disabled while it is on.
7	Features that store content. The supplier lists every feature that stores content (prompt caching, stored responses, conversation state, files, batch jobs) with its retention and the setting that turns it off.	Why it mattersRetention commitments usually carry exceptions for features. The list shows where those exceptions are.	Evidence to requestA feature list with retention per feature and the control that disables it.
8	Deletion at the end of the contract. The supplier deletes or returns the buyer's data within a stated period after the service ends and confirms it in writing.	Why it mattersGDPR Article 28(3)(g) requires the processor contract to cover deletion or return at the end of the services.	Evidence to requestThe DPA clause with the period, the treatment of backups, and a sample deletion confirmation.

3. Training and use of data

No.	Requirement	Why it matters	Evidence to request
9	No training by the supplier. The supplier does not use prompts, outputs or metadata to train or improve models.	Why it mattersTraining is the use buyers most often exclude, and it has to be in the contract to bind.	Evidence to requestThe contract or DPA clause and the matching section of the privacy notice.
10	No training by model providers. The supplier routes the buyer's traffic only to providers that commit not to train on it, and explains how this is enforced per request.	Why it mattersThe gateway's own promise does not bind the model providers behind it.	Evidence to requestProvider terms per endpoint, the enforcement mechanism, and which traffic it covers.
11	Other secondary use. The supplier states whether content or metadata is used for analytics, benchmarking, product improvement or human review, and how to opt out.	Why it mattersSecondary uses sit outside the instructions a controller gives a processor unless they are agreed.	Evidence to requestA list of secondary uses, the human review policy, and the opt-out setting.

4. Sub-processors and DPA

No.	Requirement	Why it matters	Evidence to request
12	Data processing agreement. A GDPR Article 28 DPA is available before signature and covers subject matter, duration, instructions, confidentiality, security, assistance, deletion and audits.	Why it mattersArticle 28(3) lists what the processor contract must contain. A gateway processes personal data in every prompt that mentions a person.	Evidence to requestThe DPA text, its governing law, and how it is signed.
13	Sub-processor list. The supplier publishes every sub-processor with its purpose, the data it handles and its location, including model and inference providers.	Why it mattersFor a gateway, every model provider that can serve your traffic is a sub-processor.	Evidence to requestThe URL of the list and the date of its last change.
14	Notice of new sub-processors. The supplier gives a stated period of advance notice before adding or replacing a sub-processor, with a right to object.	Why it mattersArticle 28(2) requires the controller to be informed of changes and given the opportunity to object.	Evidence to requestThe DPA clause with the notice period and the channel used for notices.
15	International transfers. For any processing outside the EEA, the supplier names the transfer mechanism (adequacy decision, Standard Contractual Clauses, UK IDTA).	Why it mattersTransfers need a legal basis under Chapter V of the GDPR, and the buyer documents its assessment.	Evidence to requestThe SCC annexes and a summary of the supplier's transfer impact assessment.
16	Breach notification. The supplier notifies personal data breaches without undue delay and within a stated number of hours.	Why it mattersThe controller has 72 hours to notify the supervisory authority under Article 33, so the processor's clock has to be shorter or equal.	Evidence to requestThe DPA clause, a summary of the incident response process and the security contact.

5. Identity and access

No.	Requirement	Why it matters	Evidence to request
17	Single sign-on. SAML 2.0 or OpenID Connect sign-in with the buyer's identity provider, such as Microsoft Entra ID, Okta or Google Workspace, for the admin console and for users.	Why it mattersWork accounts keep access tied to employment, with the buyer's MFA and sign-in policies applied.	Evidence to requestSupported protocols and identity providers, the setup guide, and a test connection.
18	SSO enforcement. The buyer can require SSO for every user and turn off password and other sign-in methods.	Why it mattersSSO that runs alongside passwords leaves accounts outside the identity provider's control.	Evidence to requestThe setting, and how it treats existing sessions and API keys.
19	User provisioning. SCIM 2.0 provisioning and deprovisioning from the identity provider, with group mapping to roles or teams.	Why it mattersWithout deprovisioning, leavers keep access until someone remembers to remove it.	Evidence to requestThe SCIM resources supported (users, groups), and how quickly deprovisioning revokes sessions and keys.
20	Roles and API keys. Role-based access, a key per person and per application, scoped keys, and immediate revocation.	Why it mattersShared keys hide who sent which request and cannot be revoked for one person.	Evidence to requestThe role matrix and the key lifecycle: creation, scoping, rotation and revocation.
21	Desktop apps and coding agents. The supplier states how employees authenticate in desktop AI apps and coding agents (for example Claude Desktop, Claude Code and IDE extensions): work-account sign-in or distributed keys.	Why it mattersThese tools are where personal accounts and copied keys appear outside procurement.	Evidence to requestThe setup guide and the list of supported tools.

6. Spend control

No.	Requirement	Why it matters	Evidence to request
22	Budgets at the levels you manage. Hard monthly limits per user, per application and per team or department, which stop spending at the limit.	Why it mattersAgents and batch jobs can spend a month's budget in hours. A limit that only alerts is a report.	Evidence to requestThe levels supported, and what happens at the limit: block, alert or overage.
23	Organisation cap and alerts. A cap for the whole organisation and alerts before any limit is reached.	Why it mattersFinance needs one number that cannot be exceeded, whatever happens below it.	Evidence to requestThe settings and the alert channels.
24	Prices and invoicing. Price per model or per plan, the billing currency, invoices with the buyer's company details and VAT number, and cost reporting per user and application for chargeback.	Why it mattersPer-token prices differ between models by orders of magnitude, so the evaluation needs the price basis and the reporting.	Evidence to requestThe price list, a sample invoice and a sample usage report.

7. Model access and allow-lists

No.	Requirement	Why it matters	Evidence to request
25	Model catalogue. The frontier and open-weight models offered, and which of them are available under each region rule.	Why it mattersA model that is unavailable in your region is unavailable to you once the region rule is on.	Evidence to requestA model list per region and the policy for adding models.
26	Model allow-lists. Administrators choose which models each team, application or key may use. Requests for other models are refused.	Why it mattersA model approval that lives only in a policy document does not stop anyone from calling another model.	Evidence to requestThe setting and the error returned for a model that is not allowed.
27	Provider allow-lists. Administrators choose which inference providers may serve traffic. Fallbacks respect the list, and new providers are never added without approval.	Why it mattersA provider the supplier adds becomes a new place your data is processed.	Evidence to requestThe setting, how fallbacks apply it, and what happens when the supplier adds a provider.
28	Model changes. The supplier gives advance notice of model deprecations and version changes, and the buyer can pin a version.	Why it mattersA silent model change alters output quality and can invalidate the evaluation done for a use case.	Evidence to requestThe deprecation policy and the notice channel.
29	Routing transparency. If the supplier routes between models or providers automatically, for cost or availability, it documents the rules and records which model and provider served each request.	Why it mattersAutomatic routing is valuable only if you can see where each request went.	Evidence to requestThe routing documentation and a sample per-request record.

8. Audit logging and export

No.	Requirement	Why it matters	Evidence to request
30	Admin audit log. Every change to users, keys, budgets and policies, with actor, time, and before and after values.	Why it mattersReviewers ask who changed a policy and when. Without before and after values the log cannot answer what changed.	Evidence to requestA sample log entry and the retention period.
31	Request log. For each request: time, user or key, model, serving provider, region rule, status, tokens and cost, without content unless the buyer opts in, with a stated retention period.	Why it mattersFor high-risk uses, AI Act Article 26(6) asks deployers to keep logs under their control for at least six months. The request log is also the AI inventory's evidence.	Evidence to requestThe field list, the retention period and a sample export.
32	Export. Logs export as CSV or through an API, and can be sent to the buyer's SIEM.	Why it mattersRecords the buyer cannot take out cannot be used in its own audit.	Evidence to requestFormats, row or time limits, and API documentation.

9. AI Act deployer duties

No.	Requirement	Why it matters	Evidence to request
33	Inventory and literacy support. The supplier provides the information the buyer needs for its AI inventory and its Article 4 AI literacy measures: models in use per application, their providers and their documented limitations.	Why it mattersArticle 4 has applied since 2 February 2025, and an inventory is the starting point for every other AI Act duty.	Evidence to requestPer-application model and provider records, and links to model documentation.
34	High-risk uses. If the buyer will use the service for a purpose listed in Annex III, the supplier states its role under the AI Act and agrees the relevant clauses of the EU model contractual AI clauses.	Why it mattersAnnex III deployer duties apply from 2 December 2027 and depend on information only the supplier and model provider have.	Evidence to requestThe supplier's role statement and a completed MCC-AI High Risk or Light annex.
35	General-purpose model documentation. For each general-purpose AI model offered, the supplier links the documentation its provider makes available to downstream providers and the public summary of training content.	Why it mattersArticle 53 obliges providers of general-purpose AI models to make this available, and buyers file it per model.	Evidence to requestLinks per model and the date retrieved.
36	Transparency. The supplier states whether outputs carry machine-readable marking and how it supports the buyer's disclosure duties.	Why it mattersArticle 50 transparency obligations apply from 2 August 2026.	Evidence to requestPer-model marking information and guidance for disclosure.

10. Exit and portability

No.	Requirement	Why it matters	Evidence to request
37	Standard interface. The API follows a widely used interface, such as the OpenAI-compatible chat completions format, so applications can move without rewrites.	Why it mattersA proprietary interface turns a supplier change into a software project.	Evidence to requestThe API reference and the SDKs and tools known to work with it.
38	Data export on exit. The buyer can export configuration, users, key metadata, usage and logs in a machine-readable format before and after termination.	Why it mattersWhere the service is a data processing service under the EU Data Act, Chapter VI gives the customer switching rights, and from 12 January 2027 no switching charges may be imposed.	Evidence to requestExport formats, the transition assistance offered, and the period data stays available after notice.
39	Term and notice. Contract term, notice period, any fees on termination, and the transition period.	Why it mattersLong terms and termination fees decide what an exit costs.	Evidence to requestThe commercial terms and the termination clause.

11. Support and SLA

No.	Requirement	Why it matters	Evidence to request
40	Uptime SLA. A monthly availability commitment with service credits, the measurement method and the exclusions.	Why it mattersAI is moving into production workflows, where downtime has a cost.	Evidence to requestThe SLA document, the public status page and the last 12 months of availability.
41	Provider failover. When a model provider is unavailable, requests fail over to another approved provider of the same model within the region and allow-list rules.	Why it mattersFailover that ignores the region or the allow-list breaks the rules exactly when an incident is already under way.	Evidence to requestThe failover design and the number of providers per model under each region rule.
42	Support and incident communication. Support channels, response times by severity, languages, and how incidents are communicated.	Why it mattersThe buyer's own incident process depends on the supplier's.	Evidence to requestThe support policy, the status page URL and recent incident reports.
43	Security documentation. A security overview, a completed security questionnaire, and the assurance reports or certifications the supplier and its hosting providers hold.	Why it mattersThis is what the buyer's security team reviews before approval. Asking for it with the tender saves a round.	Evidence to requestThe security page, a completed questionnaire such as the open LLM gateway security questionnaire, and any reports.

Download the template (.md)Spreadsheet (.csv)

How Standard Compute answers

Standard Compute is a European AI gateway: one company account and one API for Claude, GPT, Gemini and open models, run by Standard Compute AS in Oslo. These are our answers to the requirements above, in the wording we use on our security page and in our DPA. Numbers refer to the rows of the template.

No.	Status	Our answer
No. 1	Live, opt-in	Set a Europe rule for your company, a team or a single key, and every request, including retries and fallbacks, is served only by approved European inference endpoints. If no European endpoint can serve it, the request is refused before your prompt is sent.
No. 2	Live	A Europe rule admits only the approved European inference endpoints named on our sub-processor list, each with its processing location.
No. 3	Live	Our EU gateway at eu.stdcmpt.com terminates TLS and runs in Finland, and your account data is stored in Frankfurt.
No. 4	Live	Your account and usage records are stored in Frankfurt, Germany. Request records hold metadata only (model, provider, tokens, cost and status), never your prompts or outputs. Every platform sub-processor is listed with its location.
No. 5	Live	We process your prompts in memory to serve each request and never write them to storage or logs.
No. 6	Live, opt-in	Turn on zero data retention for your company, a team or a key, and every request is routed only to inference endpoints that commit to keeping no copy of your data. Teams and keys inherit the requirement and can never switch it off underneath you.
No. 8	Live	The DPA sets deletion or return of all other customer personal data within 30 days of termination (section 10).
No. 9, 10	Live	Standard Compute never trains on your prompts or outputs. With a region rule or zero retention turned on, every request goes only to providers that commit not to train on it.
No. 12, 16	Live	Sign our Data Processing Agreement in the dashboard in minutes. It commits us to no training on your data, no retention of your content, and breach notification within 72 hours. The DPA is governed by Norwegian law.
No. 13, 14	Live	We publish every sub-processor with its purpose, data and location, and give you 14 days' notice before adding a new one.
No. 15	Live	Transfers outside the EEA or the UK to a country without an adequacy decision are governed by the EU Standard Contractual Clauses and, for UK data, the UK IDTA (DPA section 6).
No. 17	Live	Connect Microsoft Entra ID or any SAML identity provider so your people sign in to Standard Compute with their work accounts. Anyone on your verified domain joins your company automatically.
No. 18	Partly	SAML sign-in is live for every company with SSO. Password sign-in stays available alongside it, so SSO is not the only way in.
No. 19, 21	Live	Employees sign in to Claude Desktop and Claude Code with their Microsoft work account, through our EU gateway, so there are no API keys to hand out. Access follows your Microsoft Entra groups through SCIM provisioning.
No. 20	Live	Organize your company into teams, invite colleagues by email, and give every person and every app its own key, all under one company account. Roles are admin and member.
No. 22, 23	Partly	Every person and app gets a fixed monthly budget that never overruns, and you can set spending caps per key and for the whole company. There is no separate budget per team: teams are covered through the budgets of their people and apps.
No. 24	Live	Flat monthly plans per person or app, with no per-token surprises, and Stripe invoices with your company name and VAT number. Prices are in US dollars.
No. 25	Live	Run leading open models, including GLM, DeepSeek, MiniMax and Kimi, alongside Claude, GPT and Gemini through one API. GLM, DeepSeek and MiniMax are also served by European providers for Europe-restricted workspaces.
No. 26	Live	Decide which models each key can use, so every app and every team member gets exactly the models you approve.
No. 27	Live	Choose exactly which inference providers may handle your data, for the whole company, a team or a single key. Lower levels can only narrow the rules, new providers are never added without an admin's approval, and fallbacks can never route around your list.
No. 29	Live	Each step goes to the cheapest model that can do it and the cheapest provider fast enough to serve it, and the request record shows the model and the provider that served it.
No. 30, 31, 32	Live	Every admin change is recorded with before and after values, and you can export a record of every request showing the model, the provider that served it and the region rule in force, kept for 12 months. Exports are CSV.
No. 33	Live	A key per person and per app, the models each key may use, and the model and serving provider of every request: the records our AI Act deployer checklist asks for.
No. 37	Live	One OpenAI-compatible API (chat completions format) for every model, documented in the API reference.
No. 40, 41	Live	If a provider goes down, your request fails over to another approved provider of the same model automatically, without leaving your region or provider rules. Enterprise includes a 99.9% monthly uptime SLA with service credits. Live status is public at /status.
No. 43	Live	Our security page, our completed security questionnaire, the sub-processor list and the DPA are public.

Rows not listed are ones to answer in your tender response with your account team. The template above stays vendor-neutral: use it with any supplier.

Create a company account

Questions

What should an RFP for an LLM gateway or AI platform include?: Where data is processed, what is retained, who may train on it, the sub-processors and the DPA, identity and access (SSO, SCIM, keys), spend control, which models and providers are allowed, audit logs and export, AI Act deployer support, exit terms and the SLA. This template covers each area with 43 requirements and the evidence to request.
Can public buyers use this template in a tender?: Yes. It is free to copy and edit. Public buyers typically use it as the technical requirements annex and attach the voluntary EU model contractual AI clauses (MCC-AI) to the contract. Check the requirements against your procurement rules and mark which are mandatory before publishing.
What are the EU model contractual AI clauses?: Template clauses for buying AI systems, published by the Community of Practice on Public Procurement of AI on the Commission's Public Buyers Community. The March 2025 update has a full version for high-risk AI and a light version for other AI. They are voluntary and are meant to be annexed to a contract, which still has to cover data protection, liability and intellectual property.
Is a model provider a sub-processor of an AI gateway?: Usually yes. When a gateway forwards prompts that contain personal data to a model provider, that provider processes the data on the gateway's behalf. That is why rows 13 and 14 ask for a sub-processor list that includes inference providers and for notice before new ones are added.
How long should an AI platform keep request logs?: For high-risk uses, AI Act Article 26(6) asks deployers to keep the logs under their control for at least six months, unless other law provides otherwise. Many buyers ask for 12 months of metadata-only request records and no stored content.

Sources

Answer the whole template with one supplier: a European gateway to frontier and open models, with the controls on one company account.