An AI gateway procurement evidence packet should make approval repeatable. It is not a folder of vendor claims. It is the buyer-owned proof that security, legal, platform engineering, finance, and the business owner reviewed the same gateway behavior before traffic moved through it.
That matters because an AI gateway sits between your applications and model providers. It can affect keys, routes, provider access, billing, prompt and response handling, logs, quotas, fallback behavior, and incident response. If the approval record only says "trust page reviewed," the next renewal, audit, outage, or data question starts from scratch.
Flatkey is built for teams that want one AI API gateway surface for model access, routing, billing, usage analytics, and operational controls. Before approving any gateway, including Flatkey, save dated evidence that shows what was reviewed, who accepted it, which assumptions still need account-level proof, and what should trigger renewal review.
AI gateway procurement evidence packet at a glance
Use this table as the first page of the packet. The file name should include the vendor, environment, business owner, approval date, and renewal date.
| Evidence file | Save before approval | Owner | Renewal trigger |
|---|---|---|---|
| Vendor identity | Legal entity, support contact, contract counterparty, current terms, privacy policy, refund policy, and SLA pages | Procurement and legal | Entity, terms, privacy, payment, or SLA change |
| Gateway scope | What the gateway will front: endpoint families, apps, environments, model providers, model aliases, and data classes | Platform engineering | New app, new endpoint family, new provider, regulated workload |
| Data handling | Privacy policy, DPA or data terms, retention settings, log payload policy, provider passthrough terms, and redaction controls | Security and legal | Prompt/response logging change, ZDR request, new data category |
| Access controls | Key owners, key creation process, rotation schedule, offboarding path, service accounts, and least-privilege boundaries | Security and platform | New team, shared key found, owner leaves, production key rotated |
| Audit and logs | Request ID fields, usage exports, owner attribution, billing fields, error records, and retention limits | Security and finance | Audit request, incident, missing cost owner, log field change |
| Billing and quotas | Current pricing page, prepaid or invoice terms, quota limits, recharge policy, refund process, and budget owner | Finance and operations | Price change, new model class, credit exhaustion, invoice issue |
| Reliability | Status page or incident process, SLA, maintenance language, fallback policy, route health test, and rollback owner | Platform engineering | Outage, provider route change, degraded latency, failed smoke test |
| Sign-off | Approval memo, open risks, exceptions, test transcript, accepted use cases, and review date | Business owner | Any material scope, policy, pricing, or architecture change |
The practical rule: if a reviewer would need the same artifact during a renewal, incident, security questionnaire, or finance dispute, it belongs in the AI gateway procurement evidence packet.
Start with identity, authority, and scope
Procurement should be able to answer three questions without opening a chat thread: who is the counterparty, what are we buying, and who approved the scope?
For Flatkey, save dated copies of the public pages that matter to the contract and operating record: the homepage, pricing, terms, privacy policy, service level agreement, and refund policy. The live Flatkey pricing page currently describes self-serve prepaid top-ups, enterprise procurement support, one balance across GPT, Claude, Gemini, DeepSeek, image, audio, and video models, and usage metering by model, token type, and request logs. Save the page you reviewed rather than relying on a remembered price or model list.
Then define scope in buyer language:
| Scope question | Evidence to save | Why it matters |
|---|---|---|
| Which environments will use the gateway? | Dev, staging, production, batch, and evaluation list | Prevents production traffic from inheriting an unreviewed test exception |
| Which applications are in scope? | App names, owners, and data classification | Lets security map gateway use to real systems |
| Which endpoint families are required? | Chat, Responses, Messages, images, video, or provider-specific routes | Avoids approving one route and accidentally using another |
| Which providers and models are allowed? | Provider list, model aliases, fallback candidates, and disallowed models | Keeps routing aligned with procurement and policy |
| Which data classes may pass through? | Public, internal, customer, regulated, secrets, credentials, or PHI status | Determines whether DPA, retention, and redaction evidence is enough |
Do not treat a broad gateway approval as approval for every future model, provider, or data class. The packet should name what is approved and what requires another review.
Save privacy, DPA, and retention proof as dated evidence
The highest-risk mistake in AI gateway procurement evidence is confusing public marketing language with account-specific data handling. Public docs are useful screening evidence. Final approval still needs the signed contract, DPA, account settings, and any provider-specific terms that apply to your traffic.
Save these files before approval:
| Data artifact | What to capture | Review note |
|---|---|---|
| Vendor privacy policy | Effective date, covered data categories, account data, API usage data, support data, retention language | Public policy is not a substitute for a DPA |
| DPA or data terms | Legal entity, subprocessors, transfer language, audit rights, breach process | Confirm it matches your contracting entity |
| Prompt and response retention | Whether prompts, outputs, files, embeddings, images, or logs are stored; default and configurable TTLs | Separate gateway retention from provider retention |
| Provider passthrough | Which upstream provider terms apply when the gateway routes to that provider | A gateway can simplify access without removing downstream obligations |
| Redaction and omission controls | What fields can be masked, omitted, or excluded from logs | Needed before sensitive workloads or customer payloads |
| Data residency | Region, backup, support access, and cross-border processing claims | Must match legal and customer commitments |
Provider docs show why this should be explicit. Anthropic's API data-retention documentation distinguishes Zero Data Retention from other arrangements and notes that some features or models require storage for specific periods. Google Cloud's Gemini Enterprise Agent Platform documentation likewise frames zero data retention as something customers achieve by meeting specific conditions and settings. NIST's AI Risk Management Framework is voluntary guidance, but it is clear that trustworthy AI use depends on managing risks across design, use, and evaluation, not on accepting a single vendor statement.
The buyer-owned packet should therefore include both public provider documentation and your account-specific evidence: screenshots of settings, signed addenda, support confirmations, and a short statement of what is still assumed.
Prove access control before sharing production keys
Access approval is not just "who can log in." For an AI gateway, it means who can create keys, rotate keys, view usage, change routes, approve models, recharge balance, export logs, and disable traffic.
Save a key-control page in the packet:
| Control | Evidence to keep | Failure to avoid |
|---|---|---|
| Key owner | Named human owner and backup owner for every production key | Orphaned key after team changes |
| Key scope | Environment, app, route, provider set, and model set | Shared key used across unrelated workloads |
| Rotation | Last rotation date, next rotation date, and emergency rotation runbook | Long-lived key with no owner |
| Offboarding | How access is removed when an engineer or vendor leaves | Former user retains route or dashboard access |
| Service account use | Whether automation uses shared user credentials, service account credentials, or workload identity | Untraceable automation changes |
| Secrets storage | Secret manager path, CI/CD reference, and non-secret screenshots | API keys appearing in tickets, docs, or logs |
Flatkey's public positioning around one key and one dashboard is useful for reducing provider-account sprawl. Procurement still needs proof of how your team will prevent that one gateway key from becoming a shared super-key. Pair this article with AI API access review and audit logs for AI API usage when building the internal review workflow.
Turn logging claims into audit files
An AI gateway procurement evidence packet should answer what happened, who owned it, what it cost, and what changed. Save sample exports, not just screenshots of dashboard charts.
Minimum audit fields to test:
| Audit field | Why reviewers need it |
|---|---|
| Request ID and timestamp | Supports incident reconstruction and support tickets |
| Key or owner label | Ties traffic to an accountable team or service |
| Endpoint family and route | Shows whether traffic used the approved gateway path |
| Requested model and served model | Reveals routing, fallback, and alias behavior |
| Provider or upstream account | Separates gateway evidence from downstream provider evidence |
| Usage units | Tokens, images, seconds, cache units, or other billing dimensions |
| Estimated and actual cost | Lets finance review spend and retry amplification |
| Error class and retry count | Shows whether failures drove additional spend |
| Redaction status | Confirms whether prompts/responses were logged, masked, or omitted |
Keep one positive test and one negative test. The positive test proves a normal request is visible with the expected owner, model, cost, and route fields. The negative test proves a failed key, blocked route, quota event, or invalid model is captured without exposing secrets.
For vendor-risk review, connect this evidence to AI API vendor risk assessment. For operations, connect it to quota, retry, and incident runbooks so logs are useful when something breaks.
Preserve pricing, billing, and quota evidence
Finance should not approve an AI gateway only from a pricing headline. The packet should show how the team will understand unit cost, prepaid balance, recharge records, invoice handling, refunds, and budget limits after traffic starts.
Save these finance artifacts:
| Finance artifact | What to save |
|---|---|
| Current pricing page | Dated PDF or screenshot with model classes, units, and enterprise plan language |
| Test request cost | Request ID, model, input/output units, and cost shown in the dashboard |
| Balance or invoice flow | Recharge record, invoice sample, tax handling, payment processor, or enterprise billing contact |
| Quota settings | Per-key, per-team, or account-level quota screenshots and owner |
| Refund or dispute policy | Process for duplicate charges, incorrect deductions, delivery failures, invoice errors, and support evidence |
| Renewal assumptions | Expected monthly usage, model mix, growth range, and owner for price-change review |
The key control is not whether today's rate is acceptable. It is whether finance can reproduce the cost trail later. Pricing and provider catalogs change, especially across text, image, audio, and video models. Save dated evidence and require a renewal trigger when a new model class or provider route is added.
Run the approval smoke test
Before approval, run one controlled test through the proposed gateway path. If no production key is available yet, run it in a sandbox with representative settings and label the evidence as pre-production.
Use this approval test:
- Create or select the approved test key.
- Send one low-risk request through the approved base URL and endpoint family.
- Capture the request ID, model alias, served model if available, route, provider, latency, usage units, and estimated cost.
- Confirm the request appears in the dashboard or export under the correct owner.
- Trigger one expected failure, such as invalid model, bad key, quota cap, or blocked route.
- Confirm the failure record does not reveal secrets or sensitive payloads.
- Save the rollback path: how to disable the key, route traffic away, or return to direct provider access.
Flatkey's current public site points users to the console, pricing page, models page, and sign-up flow, and positions the platform around gateway access, routing, billing, usage analytics, and operational controls. That is enough to build a procurement test plan. It is not enough to skip account-specific proof.
Sign-off should include open risks
The final page of the AI gateway procurement evidence packet should be a decision record, not a celebratory checklist.
Include:
| Decision field | Example |
|---|---|
| Approved use case | Production support assistant, internal batch summarization, model evaluation, or developer tooling |
| Approved route | Base URL, endpoint family, provider set, model aliases, and fallback policy |
| Approved data | Public-only, internal-only, customer data allowed, regulated data excluded, or PHI allowed only after BAA |
| Required controls | Key owner, quota cap, log redaction, monthly review, incident owner |
| Open risks | DPA pending, ZDR not enabled, provider passthrough not confirmed, fallback not approved |
| Review date | Next renewal, first production month, or before any new provider/model class |
| Approvers | Procurement, legal, security, platform, finance, and business owner |
This record keeps approval honest. If a risk is accepted, say who accepted it and when it expires. If a claim still needs proof, do not bury it in a chat thread.
Bottom line
Good AI gateway procurement evidence turns vendor claims into files the buyer controls: dated policy pages, contract terms, account settings, access owners, audit exports, cost tests, smoke-test transcripts, and renewal triggers.
For Flatkey, start by saving the current product, pricing, terms, privacy, SLA, and refund pages; define the exact apps, routes, models, providers, data classes, and owners in scope; then run a small gateway test before production approval. Use the enterprise AI API gateway checklist as the broader control review, then get a key and keep the approval record attached to the team that will own the traffic.
FAQ
What is AI gateway procurement evidence?
AI gateway procurement evidence is the buyer-owned proof package that supports approval of an AI API gateway. It includes dated vendor pages, signed terms, privacy and retention evidence, access-control proof, audit samples, pricing records, smoke tests, and approval sign-off.
Is a trust page enough for an AI gateway approval?
No. A trust page is screening evidence, not a complete approval record. Buyers should save the trust page, but they also need contract scope, DPA status, account settings, access ownership, logging samples, pricing evidence, and test results.
Who should own the AI gateway procurement evidence packet?
Procurement or legal can own the contract folder, but platform engineering should own technical scope and smoke-test evidence. Security should own data, access, and audit proof. Finance should own pricing, usage, quota, and invoice evidence.
How often should the evidence packet be refreshed?
Refresh it at renewal, after material policy or pricing changes, before adding a new provider or model class, before routing regulated data, and after any incident that changes the gateway's operating assumptions.
What should Flatkey buyers save before approval?
Flatkey buyers should save dated copies of the homepage, pricing page, terms, privacy policy, SLA, refund policy, model and route scope, key-owner plan, quota settings, audit/log samples, billing evidence, and the first successful gateway smoke test.
