# 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 (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses) published on the Commission's Public Buyers Community in March 2025.

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

| Must | 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. | Gateways fail over between providers. Without a region rule that covers every attempt, a fallback can move a prompt to another jurisdiction without anyone noticing. | The 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. | Sales material often uses Europe and EU interchangeably. Your transfer assessment depends on the exact list. | A 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. | A request can be served by a model in the right region and still pass through a global edge network first. | Hostnames 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. | Residency answers often cover prompts only. Metadata still holds personal data such as names, email addresses and IP addresses. | A storage location per data category, including backups and transactional email. |

## 2. Retention and zero data retention

| Must | 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. | The gateway sees every prompt your organisation sends. Its own retention is the first exposure to check. | A 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. | Model providers commonly keep prompts for a period for abuse monitoring unless a zero-retention arrangement applies to the endpoint. | Retention 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. | Retention commitments usually carry exceptions for features. The list shows where those exceptions are. | A 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. | GDPR Article 28(3)(g) requires the processor contract to cover deletion or return at the end of the services. | The DPA clause with the period, the treatment of backups, and a sample deletion confirmation. |

## 3. Training and use of data

| Must | 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. | Training is the use buyers most often exclude, and it has to be in the contract to bind. | The 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. | The gateway's own promise does not bind the model providers behind it. | Provider 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. | Secondary uses sit outside the instructions a controller gives a processor unless they are agreed. | A list of secondary uses, the human review policy, and the opt-out setting. |

## 4. Sub-processors and DPA

| Must | 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. | Article 28(3) lists what the processor contract must contain. A gateway processes personal data in every prompt that mentions a person. | The 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. | For a gateway, every model provider that can serve your traffic is a sub-processor. | The 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. | Article 28(2) requires the controller to be informed of changes and given the opportunity to object. | The 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). | Transfers need a legal basis under Chapter V of the GDPR, and the buyer documents its assessment. | The 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. | The controller has 72 hours to notify the supervisory authority under Article 33, so the processor's clock has to be shorter or equal. | The DPA clause, a summary of the incident response process and the security contact. |

## 5. Identity and access

| Must | 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. | Work accounts keep access tied to employment, with the buyer's MFA and sign-in policies applied. | Supported 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. | SSO that runs alongside passwords leaves accounts outside the identity provider's control. | The 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. | Without deprovisioning, leavers keep access until someone remembers to remove it. | The 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. | Shared keys hide who sent which request and cannot be revoked for one person. | The 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. | These tools are where personal accounts and copied keys appear outside procurement. | The setup guide and the list of supported tools. |

## 6. Spend control

| Must | 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. | Agents and batch jobs can spend a month's budget in hours. A limit that only alerts is a report. | The 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. | Finance needs one number that cannot be exceeded, whatever happens below it. | The 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. | Per-token prices differ between models by orders of magnitude, so the evaluation needs the price basis and the reporting. | The price list, a sample invoice and a sample usage report. |

## 7. Model access and allow-lists

| Must | 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. | A model that is unavailable in your region is unavailable to you once the region rule is on. | A 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. | A model approval that lives only in a policy document does not stop anyone from calling another model. | The 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. | A provider the supplier adds becomes a new place your data is processed. | The 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. | A silent model change alters output quality and can invalidate the evaluation done for a use case. | The 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. | Automatic routing is valuable only if you can see where each request went. | The routing documentation and a sample per-request record. |

## 8. Audit logging and export

| Must | 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. | Reviewers ask who changed a policy and when. Without before and after values the log cannot answer what changed. | A 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. | For 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. | The 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. | Records the buyer cannot take out cannot be used in its own audit. | Formats, row or time limits, and API documentation. |

## 9. AI Act deployer duties

| Must | 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. | Article 4 has applied since 2 February 2025, and an inventory is the starting point for every other AI Act duty. | Per-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. | Annex III deployer duties apply from 2 December 2027 and depend on information only the supplier and model provider have. | The 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. | Article 53 obliges providers of general-purpose AI models to make this available, and buyers file it per model. | Links 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. | Article 50 transparency obligations apply from 2 August 2026. | Per-model marking information and guidance for disclosure. |

## 10. Exit and portability

| Must | 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. | A proprietary interface turns a supplier change into a software project. | The 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. | Where 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. | Export 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. | Long terms and termination fees decide what an exit costs. | The commercial terms and the termination clause. |

## 11. Support and SLA

| Must | No. | Requirement | Why it matters | Evidence to request |
| --- | --- | --- | --- | --- |
| [ ] | 40 | Uptime SLA. A monthly availability commitment with service credits, the measurement method and the exclusions. | AI is moving into production workflows, where downtime has a cost. | The 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. | Failover that ignores the region or the allow-list breaks the rules exactly when an incident is already under way. | The 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. | The buyer's own incident process depends on the supplier's. | The 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. | This is what the buyer's security team reviews before approval. Asking for it with the tender saves a round. | The security page, a completed questionnaire such as the open LLM gateway security questionnaire (https://standardcompute.com/security/questionnaire), and any reports. |

---

## Sources

- [Updated EU model contractual AI clauses (MCC-AI High Risk and Light), Public Buyers Community, 5 March 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Regulation (EU) 2016/679, the GDPR, Articles 28 and 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)
- [Regulation (EU) 2024/1689, the AI Act, Articles 4, 26, 50 and 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)
- [Regulation (EU) 2023/2854, the Data Act, Chapter VI on switching between data processing services, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, SCIM 2.0 protocol](https://www.rfc-editor.org/rfc/rfc7644) and [SAML 2.0 core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Free LLM gateway and AI platform RFP template from https://standardcompute.com/llm-gateway-rfp-template (version of 9 November 2026). Free to copy and edit. Not legal advice._