Enterprise Controls and TrustJuly 11, 2026Flatkey

AI Gateway DPA Checklist: Data Processing Questions for Model Routing Buyers

A practical AI gateway DPA checklist for procurement, security, and platform teams reviewing model routing, logs, retention, subprocessors, and support access.

An AI gateway DPA checklist should do more than confirm that a vendor has a legal page. For model routing buyers, the real question is whether the signed data processing agreement matches the route your application will actually use: gateway logs, upstream model providers, support access, regional routing, retention controls, deletion rights, and incident notice.

Use this AI gateway DPA checklist before approving a unified model access layer, LLM gateway DPA, or AI API data processing agreement. It is not legal advice. It is a practical evidence list for platform, security, procurement, and legal teams that need the DPA to line up with technical routing behavior.

Flatkey fits this review because the current public site positions flatkey.ai around one API key, an OpenAI-compatible base URL at https://router.flatkey.ai/v1, usage and cost visibility, request logs, model routing, and provider access through one dashboard. Treat those product pages as dated screening evidence. For approval, attach your signed order form, DPA, account settings, and any support confirmation that controls your real workload.

If you are building the broader control set, pair this review with the GDPR AI API gateway checklist, the enterprise AI API gateway checklist, the AI API data retention checklist, and current Flatkey pricing.

AI Gateway DPA Checklist: Start With The Route

The first mistake is reviewing the vendor in general. The DPA has to match a specific route. A support chatbot, a batch document classifier, a coding assistant, and a multimodal media workflow can have different data classes, endpoints, provider terms, storage behavior, and support access.

Before legal review, freeze these route facts:

Route field	Question to answer	Evidence to save
Workload owner	Who owns the feature and the data sent through it?	Product owner, platform owner, security reviewer
Environment	Is this development, staging, production, or customer-specific?	Route config, project name, environment tag
Endpoint family	Is the call chat, responses, messages, image, video, embeddings, files, or a tool workflow?	Gateway endpoint and upstream provider endpoint
Data class	Will prompts, files, images, audio, customer content, credentials, or regulated data pass through?	Data classification note and sample redacted payload
Provider path	Which model providers can receive the request under normal routing and fallback?	Route policy, provider list, fallback order
Logging path	Which systems can store request metadata, prompts, outputs, errors, support tickets, or exports?	Gateway settings, provider docs, observability config
Retention path	What is retained by the gateway, upstream provider, support tooling, and backups?	DPA, privacy docs, retention settings, deletion procedure
Approval scope	What is approved, and what would require a new review?	Decision record and review expiration date

The AI gateway DPA checklist should end with a route-specific approval record, not a broad statement that "AI is approved."

The Ten Data Processing Questions Buyers Should Ask

Use these questions as the core AI vendor DPA checklist for any model routing purchase.

#	DPA question	Why it matters for model routing	Acceptable evidence
1	Who is the controller, processor, and sub-processor for each route?	A gateway may process data directly and also pass it to upstream model providers.	Signed DPA, subprocessor list, route/provider map
2	What data categories are in scope?	"API data" can include prompts, outputs, uploaded files, images, logs, metadata, billing data, and support tickets.	Data category schedule, payload examples, account settings
3	Which providers can receive the request?	Dynamic routing and fallback can change the processing chain.	Route policy, allowed provider list, fallback rules
4	Are prompts and outputs stored?	Gateway logs and provider abuse-monitoring logs can have different retention behavior.	Gateway retention config, provider data controls, ZDR/MAM proof where applicable
5	What metadata is retained?	Even if content is not stored, metadata can reveal users, workloads, costs, timing, IPs, or customer IDs.	Log schema, analytics fields, billing export sample
6	What support access is allowed?	Support investigations can expose request records, screenshots, logs, or account metadata.	Support access policy, access transparency records, ticket redaction process
7	Which subprocessors are used?	A DPA is incomplete if it does not disclose the services that process customer data.	Current subprocessor list and notice process
8	What deletion or return process exists?	Procurement needs to know how retained content, logs, files, and account records are deleted or exported.	Deletion SLA, API/dashboard steps, backup exception note
9	Where is data processed and stored?	Regional routing, provider regions, support teams, and logs may not share the same location.	Data residency terms, route region setting, provider region documentation
10	What incident notice and audit evidence will be available?	Buyers need a timeline for breach notice, incident communication, and evidence after a routing issue.	DPA notice terms, SLA, security contact, audit report, incident workflow

If the answer changes by endpoint, feature, provider, or account tier, record that exception in the AI gateway DPA checklist instead of smoothing it over.

Match DPA Language To Technical Processing

Article 28 style processor contracts focus on subject matter, duration, nature, purpose, data categories, controller rights, processor instructions, confidentiality, security, subprocessors, deletion or return, and assistance with data subject rights. Those are legal terms. A gateway buyer still has to translate them into engineering facts.

Use this mapping:

DPA term	Technical translation for an AI gateway
Subject matter	Model inference, routing, metering, logging, billing, support, and account administration
Duration	How long the contract runs, plus how long logs, files, support tickets, and backups remain
Nature and purpose	Passing requests to model providers, returning outputs, measuring usage, detecting abuse, supporting incidents
Personal data categories	Prompt content, output content, uploaded files, user identifiers, IP addresses, account metadata, billing contacts
Processor instructions	Allowed routes, blocked data classes, approved providers, no-training commitments, retention settings
Subprocessors	Upstream model providers, cloud hosting, payment, analytics, support, monitoring, email, and security vendors
Security measures	Encryption, access controls, logging, key management, segmentation, vulnerability process, audit evidence
Deletion or return	Content deletion, file deletion, log expiration, support ticket redaction, export format, backup exceptions

This is where many AI API data processing agreement reviews break down. The DPA may say a processor acts on instructions, while the product route quietly allows fallback to multiple providers. The approval record should say which providers are allowed, which are blocked, and who can change that policy.

Verify Retention By Endpoint And Feature

Provider data controls are often feature-specific. OpenAI's platform data controls describe API training restrictions, default abuse-monitoring retention, approved Zero Data Retention or Modified Abuse Monitoring controls, and endpoint-specific application state behavior. Anthropic's API data-retention documentation separates Claude API processing from cloud marketplace processing and explains ZDR eligibility by feature. Google's Gemini Developer API ZDR documentation explains paid-service training restrictions and feature-level cases where prompts, responses, files, grounding, state, or cache behavior may still matter.

That means "we have ZDR" is not enough for an LLM gateway DPA. Ask:

Is the exact endpoint eligible for the retention control?
Is the exact project, organization, or account approved?
Does fallback route to a provider or feature that is not covered?
Do files, images, audio, video, tools, web search, code execution, context caching, batch jobs, or stateful conversations change retention?
Are abuse-monitoring logs, application state, gateway logs, support records, billing records, and backups handled separately?

For a production route, save a one-row retention matrix:

System	Content stored?	Metadata stored?	Retention period	Deletion path	Evidence
Application	Yes or no	Yes or no	Internal policy	App deletion process	Internal data map
Gateway	Yes or no	Yes or no	Account setting or vendor term	Dashboard/API/support	Gateway evidence
Provider A	Yes or no	Yes or no	Provider control	Provider policy	Provider docs
Provider B fallback	Yes or no	Yes or no	Provider control	Provider policy	Provider docs
Support tool	Yes or no	Yes or no	Ticket policy	Ticket redaction/deletion	Support evidence

The AI gateway DPA checklist is complete only when each retained copy has an owner, a reason, and a deletion or expiration path.

Review Gateway Logs Separately From Provider Terms

Gateway logs are useful for reliability, cost control, debugging, and audit review. They are also a separate data-processing surface. Public gateway documentation from infrastructure providers shows why buyers should ask this explicitly: request logs may include user prompts, model responses, provider, timestamp, status, token usage, cost, duration, and client metadata, and persistent log limits can vary by plan.

Ask these logging questions before signing:

Can the gateway store full prompts or outputs, or only metadata?
Can prompt and response logging be disabled per route, environment, workspace, or customer?
Can sensitive fields be omitted, masked, hashed, or redacted before logging?
Are logs copied into analytics, data warehouses, alerting, support tickets, or exports?
Who can view logs, and is every access logged?
Can logs be deleted early, exported for audit, or excluded from support workflows?
Does the DPA cover logs as customer data, system data, or both?

This is the difference between a legal DPA review and an operational AI gateway DPA checklist. If your security policy says prompts must not be stored, the route should prove that the gateway, provider, and support paths follow the same rule.

Check Subprocessors And Provider Switching

A direct provider account usually has one main processor chain. A model router can have a larger chain because one application route may touch a gateway, an upstream provider, observability tooling, payment infrastructure, support tooling, and cloud hosting. If fallback is enabled, a request may go to a second provider when the first provider fails.

The DPA package should answer:

Subprocessor question	What to inspect
Current subprocessors	Is there a published list, and does it include hosting, model providers, support, analytics, and billing vendors?
Change notice	How will the buyer receive notice of new subprocessors?
Objection rights	Can the buyer object, terminate, disable a route, or restrict a provider?
Provider allowlist	Can procurement approve a limited set of providers for a specific workload?
Fallback behavior	Can fallback be disabled for sensitive routes?
Regional coverage	Are subprocessors and provider regions aligned with buyer data residency requirements?
Contract flowdown	Do subprocessor commitments cover confidentiality, security, deletion, and incident support?

For Flatkey buyers, combine the public route and pricing evidence with account-specific controls. If your route uses one key across multiple models, the DPA evidence must still say which upstream providers can process each approved data class.

Ask For Support, Incident, And Audit Evidence

Support access is easy to overlook because it usually happens after something breaks. For a gateway DPA review, support is part of processing.

Ask for:

The support contact and escalation path for security or privacy incidents.
Whether support staff can view prompts, outputs, logs, uploaded files, screenshots, or customer metadata.
Whether support access is time-limited, approved, and logged.
Whether access transparency records are available for eligible accounts.
How support tickets are redacted when they contain prompt or output examples.
Which incident notice timeline applies under the DPA, terms, SLA, or security addendum.
Whether the vendor will help with data subject requests, deletion, export, and regulator inquiries.

NIST's AI Risk Management Framework is useful as a governance reference here because it encourages organizations to govern, map, measure, and manage AI risks instead of approving a route once and forgetting it. For a model router, that means the DPA review should be renewable. Set a review date, assign evidence owners, and recheck provider terms before major route changes.

Build The Evidence Packet

The practical output is a small evidence packet that legal, security, procurement, and platform teams can all read.

Packet item	File or record to save
Route summary	Workload, owner, endpoint, data class, approved providers, fallback behavior
DPA	Signed data processing agreement and any security or regional addendum
Data map	Prompt/output flow from application to gateway to provider to logs/support
Retention matrix	Gateway, provider, application, support, billing, and backup retention
Subprocessor evidence	Current subprocessor list and change-notice process
Account controls	ZDR/MAM approval, data residency, logging settings, route allowlist, redaction settings
Log sample	Redacted example showing stored fields, not secrets
Deletion workflow	How content, files, logs, tickets, and account records are deleted or returned
Incident workflow	Notice timeline, contact, escalation, and evidence available after an event
Approval decision	Reviewers, exceptions, expiration date, and route-change triggers

For Flatkey, add current public evidence from the homepage, privacy policy, pricing page, terms, SLA, and the account dashboard. The public pages can help buyers screen the service, but account-specific evidence should control the final decision.

Red Flags That Should Pause Approval

Pause the route review when any of these are unresolved:

The DPA names the gateway vendor but not the upstream model-provider path.
Fallback can send sensitive data to an unapproved provider.
Prompt or output logs are enabled, but the DPA or security review does not cover them.
The vendor says "no training" but cannot answer retention, support access, deletion, or subprocessors.
ZDR is promised broadly, but the selected endpoint, feature, or account is not eligible.
Support tickets can include raw prompts without a redaction process.
Subprocessor changes have no notice path.
Regional routing is assumed but not proven by contract, account setting, or usage evidence.
Pricing, logs, and usage exports contain customer identifiers that were not included in the data map.
The approval has no owner or review date.

These red flags do not always mean the vendor is unusable. They mean the AI gateway DPA checklist is not finished.

What A Good Approval Looks Like

A strong approval record is short and testable:

Approval field	Example wording
Scope	"Production support triage route, text-only prompts, no file upload, approved providers A and B only."
Data class	"Customer support text after application-level secret and payment redaction."
Logging	"Gateway stores metadata only. Application stores redacted transcript for 30 days. Provider retention follows approved account control."
Restrictions	"No web search, file upload, image input, batch upload, or fallback outside allowlist."
Evidence	"DPA signed, subprocessor list saved, retention matrix attached, route config exported."
Renewal	"Review again before adding providers, changing endpoint families, enabling full prompt logs, or sending regulated data."

This format makes the DPA operational. Developers know what they can route. Procurement knows what was approved. Security knows what to monitor. Legal has evidence rather than scattered promises.

Final AI Gateway DPA Checklist

Before you buy or expand a model router, confirm these items:

The AI gateway DPA checklist names the exact route, endpoint, provider list, fallback policy, and data class.
The AI API data processing agreement covers prompts, outputs, files, logs, metadata, support tickets, billing records, and subprocessors where applicable.
Gateway logging and provider retention are reviewed as separate systems.
ZDR, no-training, or modified-retention claims are tied to the exact account, project, endpoint, and feature.
Provider switching has an allowlist, owner, and review trigger.
Deletion, export, support access, incident notice, and subprocessor change notice are written down.
Public vendor pages are treated as dated screening evidence, not a substitute for the signed DPA.
The approval has an owner, an expiration date, and a rule for route changes.

If your team wants one API key and one dashboard for multi-model access, start with Flatkey and keep this AI gateway DPA checklist next to the technical route review. Get a key, confirm the current account controls, and approve each route with the same discipline you use for any other production data processor.