Contractual vs Technical Controls for Third-Party AI: A Decision Matrix for What to Enforce and Verify

A contract with an AI provider can promise that your prompts will not be used for training, but it cannot stop an employee pasting a customer database into a prompt, an over-privileged API key being stolen, or a retention setting being left at its default. Procurement handles third-party AI risk through clauses and engineering through gateways and keys, and the two rarely meet, leaving promises nobody checks and gaps nobody owns. This guide is a decision matrix for security architects, third-party risk managers and AI platform owners: which risks a contract can actually enforce, which need a technical control such as an AI gateway, redaction or key scoping, and how to verify each one. For the clause wording itself, see the AI Contract Clauses Guide.

Key takeaways

• Contracts govern the provider; technical controls govern your use. A clause binds what the provider does with data it receives; only a technical control limits what reaches the provider in the first place and what a stolen credential can do.
• A contract promise is only as good as the matching setting. Zero retention, regional processing and abuse monitoring opt-outs are usually activated by an account-level or project-level setting, so the contract and the configuration must both be checked.
• Some risks only a contract can cover. Training use, sub-processor changes, breach notification, audit rights, liability and exit are provider-side behaviours you cannot engineer around.
• Some risks only a technical control can cover. Oversharing by users, key theft, runaway spend, prompt injection and unapproved model use happen on your side of the line, whatever the contract says.
• Verification is the deciding column. For each risk, choose the control whose evidence you can actually collect: an attestation, a configuration export, a log or a test result.

The short answer

Use contracts for what the provider does after data arrives: training, retention, human review, sub-processors, location, notification, audit and exit. Use technical controls for what leaves your environment and who can send it: an AI gateway for routing and logging, redaction for sensitive fields, scoped keys and spend caps for credentials, and provider-side settings to activate the retention terms you negotiated. Where a risk is high and the contract term cannot be verified directly, add a technical control that reduces exposure even if the provider fails. For the overall programme, see the Third-Party AI Risk Guide.

What each control type is, in architectural terms

Contractual controls

Architecture in words: a master agreement, data processing agreement (DPA) and AI-specific schedule define obligations on the provider: no training on customer content, maximum retention, sub-processor lists and notice periods, processing regions, security baseline, incident notification, audit or information rights and termination assistance. Under GDPR Article 28(3)(h) a processor must make available the information needed to demonstrate compliance and allow for audits. Enforcement is legal: remedies, termination and liability, after the fact.

Threat model: contracts address provider misbehaviour, provider policy changes and provider incidents. OWASP's Top 10 for LLM Applications 2025 lists unclear terms and data privacy policies as a supply chain risk (LLM03:2025), with a scenario in which an operator changes its terms to require an explicit opt-out from training on application data. A fixed contract term is the control for that scenario. Contracts do not address anything your own users, code or credentials do.

Technical controls

Architecture in words: traffic to AI providers passes through controls you operate: an AI gateway that authenticates callers, routes to approved models, applies policies and logs requests; redaction or tokenisation that removes sensitive fields before a prompt leaves; scoped, per-application API keys held in a secrets manager with spend and rate limits; and provider-side configuration (retention, caching, logging and regional settings) set and monitored as code. Enforcement is preventive or detective, in real time.

Threat model: technical controls address oversharing, credential theft, abuse of keys, unapproved providers and the gap between what was negotiated and what is configured. They cannot prevent a provider from mishandling data it legitimately receives.

Side-by-side comparison

What contracts can and cannot enforce

• Can enforce: training and improvement use. Whether inputs, outputs and files are used to train models offered to others. Provider documentation for the major APIs already states a no-training default for business API data; the contract fixes it so a policy update cannot reduce it.
• Can enforce: retention and human review. Maximum retention per data type, including abuse monitoring copies, and conditions for human access.
• Can enforce: sub-processors and location. The list of sub-processors, including upstream model providers when you buy through an intermediary, notice of changes and the right to object.
• Can enforce: notification and cooperation. Timelines for security incidents and for material model changes, and the information you need to revoke credentials. NIST SP 800-53 SR-8 Notification Agreements is the matching control.
• Can enforce: audit, liability and exit. Information rights, indemnities, deletion at termination and portability of prompts, fine-tuned models and logs.
• Cannot enforce: what your users paste. No clause stops a user sending regulated data to an approved provider; that is an acceptable use and data protection problem.
• Cannot enforce: credential hygiene. A provider cannot prevent your API key being committed to a public repository or stolen from a hosting platform.
• Cannot enforce: prompt injection or model behaviour. Warranties on output quality exist, but they do not stop an injected instruction from triggering a tool call in your environment.
• Cannot enforce: shadow AI. A contract with an approved provider has no effect on staff using an unapproved one.

Technical compensations: gateway, redaction and key scoping

AI gateway

A gateway is the enforcement point that makes contract terms practical: route only to providers and models with a signed agreement, attach the right project or deployment (and therefore the right retention and region settings), log requests for audit, and block traffic to everything else. It also gives you the evidence that only approved providers are being used. See the AI Gateway and LLM Gateway Guide and Securing the AI gateway itself, since the gateway now holds every provider key.

Redaction and tokenisation

Redaction removes or replaces sensitive values before the prompt leaves, so a retention or training failure at the provider exposes less. It is a compensating control, not a guarantee: the Presidio project, a widely used open source detection and anonymisation toolkit, states that because detection is automated there is no guarantee it will find all sensitive information, and recommends additional protections. Use deterministic patterns for structured identifiers (card numbers, national identifiers, account numbers) and treat named-entity detection as best effort. Reversible tokenisation keeps responses useful when the application must restore the original value.

Key scoping and spend caps

A provider API key is a non-human identity with a direct cost and data exposure. Issue one key per application and environment, scope it to a project or workspace, restrict its endpoint permissions where the provider supports it, and cap spend and rate. For example, Anthropic's documentation describes workspace-scoped keys with per-workspace spend and rate limits, and OpenAI's documentation describes key permissions of All, Restricted (None, Read or Write per endpoint) and Read Only. Equivalent controls on cloud platforms are set through the platform's identity and access management. Provider-specific steps are in the Anthropic API keys security guide, Azure OpenAI and Azure AI Foundry security guide, Google Vertex AI security guide and OpenAI API Keys Security Guide.

Turning retention terms into verified settings

Retention commitments are where contract and configuration most often diverge, because the provider-side behaviour depends on account settings, endpoint choice and feature use. The table summarises what each provider's documentation describes as the customer-side setting and the evidence to collect. Providers are listed alphabetically; the order is not a ranking. Checked against vendor documentation in November 2026; confirm against current pages, and see Zero Data Retention for AI for detail.

The pattern is the same for every provider: the contract term is real only for the accounts, projects and features where the matching setting is active, and the gateway is how you keep sensitive workloads on those accounts.

Decision matrix: which control for which risk

Model change risk is covered in more depth in AI Model Change Management vs Traditional Change Management, and shadow AI routing in AI Gateway vs CASB/SSE for Controlling Shadow AI.

Verification: proving each control works

• Contract terms: map every negotiated term to an owner and an evidence type in the vendor record. Request independent reports annually, and the sub-processor list on change. Use the AI Vendor Security Questionnaire Template to collect the initial answers.
• Settings that activate terms: export provider configuration on a schedule and compare it with the contract schedule; a retention or logging setting that has changed is a contract compliance finding.
• Gateway coverage: compare provider billing and usage records with gateway logs. Usage that does not appear in the gateway means a bypass route.
• Redaction effectiveness: seed test prompts with synthetic identifiers and measure how many reach the provider unredacted.
• Key controls: reconcile provider key lists with your secrets inventory, and time a full rotation drill for one provider.
• Notification terms: run a tabletop where the provider reports an incident and confirm the contact path and the revocation steps work. See AI Vendor Breach Response.

Worked scenario: an AI note-taking service

A professional services firm wants to adopt a meeting summarisation service that calls a foundation model provider behind the scenes. Meetings include client confidential information and some personal data.

1. Contract: the DPA names the upstream model provider as a sub-processor, sets no training on customer content, limits retention of transcripts to 30 days with deletion on request, requires 72 hour incident notice, and gives 60 days notice of a change of model provider.
2. Technical: the service integrates with the firm's calendar and storage through OAuth, so the firm limits scopes to the meeting calendars in scope, reviews the grant quarterly and records the service's identities in its inventory.
3. Gap identified: the contract cannot stop staff recording client meetings that the client has not agreed to. The firm adds a meeting policy and a default-off setting for externally hosted meetings.
4. Verification: the firm requests the sub-processor list, checks the retention setting in the admin console, and tests deletion on a sample meeting.
5. Incident test: in the tabletop, the team finds it cannot revoke the OAuth grant quickly because the admin account belongs to one person. It assigns two administrators and documents the revocation steps.

A different pattern applies when the third party holds your AI keys rather than your data. In the Northflank breach, customers of a hosting platform were told to assume their environment variables had been decrypted, and several reported misuse of AI API keys stored there. No contract term would have stopped that use; scoped keys with spend caps and a practised rotation would have limited it.

Choosing the mix by risk tier and organisation size

• Low risk (public data, internal productivity): standard provider business terms plus gateway routing and per-app keys. Do not spend negotiation time on bespoke clauses.
• Moderate risk (internal confidential data): negotiated retention and sub-processor terms, settings verified, redaction of structured identifiers, spend caps.
• High risk (personal, regulated or client data, or agents with write access): full contract schedule with audit and notification rights, zero retention where available and verified, gateway as the only egress, redaction, tool approval gates and an exit plan.
• Small organisations: limited negotiating leverage means relying on published business terms; compensate with technical controls you fully own, such as key scoping, spend limits and a single approved provider list.
• Large organisations: leverage supports bespoke terms, but scale creates more bypass routes, so gateway coverage and configuration monitoring matter more, not less.

Implementing the matrix

1. Inventory providers and paths: list each AI provider, intermediary and SaaS product with embedded AI, and how traffic reaches it.
2. Tier each use case: by data sensitivity and autonomy, using the risk tiers above.
3. Fill the matrix: for each provider and tier, mark which risks the contract covers, which need a technical control, and the evidence for each.
4. Close contract gaps at renewal: prioritise retention, sub-processors and notification for high-risk tiers.
5. Deploy technical controls in order: per-app keys and spend caps first, then gateway routing in monitor mode, then enforcement and redaction for high-risk workloads. Keep a documented bypass for outages, approved and logged.
6. Automate verification: scheduled configuration exports, billing-to-gateway reconciliation and redaction tests, with findings routed to the vendor owner.

Detection and measurement

Monitor provider usage outside the gateway, key creation and permission changes at providers, spend anomalies per key, retention and logging setting changes, and redaction misses in sampled traffic.

• Verified term coverage: share of negotiated contract terms with a current piece of evidence.
• Gateway coverage: share of provider spend that appears in gateway logs (target close to 100% for high-risk tiers).
• Key hygiene: share of provider keys that are per-application, scoped and spend-capped.
• Redaction miss rate: seeded identifiers reaching the provider unredacted.
• Rotation time: minutes to revoke and replace all keys for one provider in a drill.

Common failure patterns

• Negotiated but not activated: zero retention is agreed, but the workload runs in a project where the setting was never applied, or uses a stateful feature outside its scope.
• Contract as the only control for user behaviour: the firm relies on a no-training clause while staff paste regulated data that the firm's own policy forbids sharing at all.
• One shared key for everything: a single organisation-wide key with full permissions and no spend cap means any leak exposes every project and budget.
• Intermediaries ignored: the contract is with a SaaS vendor, but the upstream model provider, its retention and its region are not named anywhere.
• Gateway with side doors: new SDKs, notebooks or agent frameworks call providers directly, so gateway logs show a fraction of real use.
• Annual questionnaire, no monitoring: answers are collected once and never compared with configuration or usage. See the Continuous Vendor Monitoring Guide.

Framework mapping

Practitioner checklist

• Every AI provider and intermediary is inventoried with its traffic path and risk tier.
• For each tier, a decision matrix records whether contract, technical control or both covers each risk.
• Every negotiated retention, region and logging term is matched to a provider-side setting that is exported and checked.
• Upstream model providers are named as sub-processors where you buy through an intermediary.
• Provider keys are per application, scoped, held in a secrets manager and spend-capped.
• A gateway is the default route to providers, and billing is reconciled against gateway logs.
• Redaction covers structured identifiers for high-risk workloads and is tested with seeded data.
• A provider incident tabletop has tested notification contacts and key rotation.

Standards and references

• NIST: AI Risk Management Framework Core
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Top 10 for LLM Applications 2025
• Anthropic: API and data retention
• Google Cloud: Zero data retention
• Microsoft Learn: Data, privacy and security for Azure OpenAI
• OpenAI: Your data
• Presidio: Data protection and de-identification toolkit

Related NHI Mgmt Group resources: Third-Party AI Risk Guide · AI Contract Clauses Guide · AI Vendor Security Questionnaire Template · LLMjacking Guide · Zero Data Retention for AI