Contractual and Technical Controls That Lock Vendors Out of Your Prompts and Outputs

A contract clause that prohibits training use is necessary but not self-enforcing. Architecture is what makes the prohibition checkable. Without both layers, each one can only cover a gap the other cannot.

Why contractual promises alone cannot keep vendors out of your prompts and outputs

The structural asymmetry is the starting point. Vendors draft these terms at scale, with full knowledge of where the gaps sit. Buyers sign them without realizing that the defaults permit exactly what the headline forbids. A vendor-only clause leaves a gap in the subprocessor chain that the customer cannot see from the outside, because AI vendors routinely relay customer data to third-party model providers via API. Even a well-drafted training carve-out cannot prevent a misconfigured retrieval index or shared embedding pool from quietly commingling tenant data. That requires technical isolation, not legal language.

The converse holds with equal force. Technical controls alone do not create audit rights, ownership vesting, or regulatory accountability. For that, the contract is the only instrument. The framing that organizes the strategy follows from this reciprocity: contracts define what is forbidden, and architecture makes the forbidden impossible. What remains is to show how to build both layers and where each one covers the gap the other leaves.

How vendor contract defaults expose prompts and outputs without the customer's knowledge

Ambiguous language in standard vendor contracts functions as latent permission for training use. Phrases like "improve the Services" or "use aggregated and de-identified data for any business purpose" read as routine product language, but vendors now interpret them as sufficient authority to route customer inputs into training pipelines with no separate consent. The ambiguity is not accidental: language originally scoped to product analytics and bug fixes has been stretched to cover training use without a new signature.

The tier gap makes this worse, because the same vendor logo can sit behind two opposite data policies. Free or individual paid tiers often default users into training, with opt-out buried multiple menus deep. A narrower policy disclaims training on "customer data" while leaving prompts and outputs undefined.

The operational consequence is prompt leakage. Employees input sensitive business information into AI tools for legitimate work: analyzing contracts, drafting communications, debugging code. The exposure is not hypothetical. It follows directly from the defaults that standard contracts encode.

The five contract clauses that create a defensible vendor boundary

A complete contractual defense requires five named clauses, not a generic confidentiality provision. Each closes a specific exposure that earlier-generation AI contracts left open, and each is achievable in 2026 enterprise negotiations. The first is the training data carve-out. Fedorich's 2026 model language is the reference point: "Vendor shall not use Customer Data, including any inputs, outputs, prompts, fine-tuning data, or derived data, to train, fine-tune, retrain, or otherwise modify any model, algorithm, or system, whether owned by Vendor, its affiliates, or any third party. This restriction applies in perpetuity and survives termination of this Agreement. Vendor's modification of its privacy policy, terms of service, or data processing addendum shall not alter this restriction without Customer's written consent." The phrase "in perpetuity" is load-bearing: without it, the restriction expires when the contract does. The clause must also bar unilateral override via privacy-policy update, because that is how vendors most often expand training permissions after signing. Most major vendors will agree to this for paid enterprise tiers. Resistance is highest on consumer or low-tier agreements. The clause must appear consistently in the MSA, DPA, and order form.

The third clause extends all restrictions downstream by contract to any third-party model provider the vendor uses under the hood. The DPA should attach a named subprocessor list. A vendor who resists disclosing subprocessors is answering the question. Incident notification commitments with a named timeline should appear in the DPA, not on a marketing page.

The fourth clause governs model change notification. Fedorich's 2026 language requires no less than 90 days' written notice before any material change to underlying models or systems, including model version upgrades, training data changes, fine-tuning changes, and model deprecations, with the customer retaining the right to continue on the prior version for no less than 180 days, or terminate without penalty. The right to continue on the prior version is the more important provision: without it, the customer is forced to revalidate against the new version on the vendor's timeline, a significant burden for regulated use cases.

The fifth clause is audit rights. IP indemnification for output presents a related issue: major vendors including OpenAI, Anthropic, Microsoft, and Google introduced enterprise IP indemnification in 2023 and 2024, but the carve-out from the liability cap is the critical provision. Without it, indemnification is effectively meaningless for any claim larger than the contract's typical small cap.

Why contracts create obligations but cannot make access architecturally impossible

A vendor can comply with every clause in the previous section and still operate an environment where a misconfigured shared component quietly exposes tenant data. The contract creates liability after the fact. Only architecture prevents access in the first place. This is the hinge of the argument, and it justifies why the technical layer is not optional belt-and-suspenders but structurally necessary.

The governance gap is organizational and architectural rather than merely attitudinal. Frameworks including NIST AI RMF, ISO/IEC 42001, and the EU AI Act operate exclusively at the policy layer: they define what organizations should do but provide no runtime enforcement machinery. A September 2026 paper proposing the AGIL architecture terms this the "attestation deficit," a structural condition where governance exists on paper but cannot produce proof under regulatory scrutiny.

Three technical failure modes make the mechanism vivid. Trust is not an architecture. Each technical control that follows addresses a specific failure mode the contract cannot reach.

Tenant isolation and zero-retention modes as the first line of technical defense

Tenant isolation and zero-retention configuration are the baseline technical controls you should verify before signing any enterprise AI deployment. They close the shared-environment and logging failure modes that contracts cannot reach. Tenant isolation is either a deployment property, where customer data never shares compute with another tenant, or a runtime configuration, where isolation is enforced in software but the underlying infrastructure is shared. The distinction matters and should be requested in writing before procurement. SOC 2 Type II, current within the last 12 months with a bridge letter if the audit window is closing, is the minimum independent verification of isolation and access controls.

Zero-retention modes are the second baseline control. Deletion terms should name the timing after termination and confirm backup purge. If a vendor omits backup purge language, the retention commitment has a gap.

These controls are available without changing infrastructure. They require only that the procurement team know to ask for them and the contract team verify they are documented. That is the gap the next level of controls exists to close.

LLM gateways as a runtime control layer between your organization and the model provider

An LLM gateway sitting in front of every model call is the control that keeps sensitive content in prompts from reaching third-party model providers and long-lived log stores. A gateway intercepts prompts before they reach the provider, so PII filtering, policy enforcement, and logging happen at a point you control. Names, account numbers, health identifiers, and credentials can be stripped before the model ever sees them.

But where redaction happens determines whether the gateway itself becomes another point of exposure. This is not a ranking. Each offers a different packaging of the same core interception function.

A critical limitation applies. An air-gapped setup requires every model behind the gateway to run locally, so the gateway alone does not give you full containment. The AGIL architecture paper proposes a Policy Enforcement Gateway as one of five layers in a governance architecture specifically because inline permit, deny, or modify decisions at sub-100ms latency are the only way governance can operate at the speed AI systems generate and consume data. Privacy-preserving AI assistants built on confidential computing from the ground up, such as Confidant AI, embed this principle into their core design: the architecture itself makes data access impossible for the service operator, so no contractual gap can create an opening.

Gateways protect data in transit and at the prompt layer. They cannot protect data in use inside the inference computation itself. That requires hardware-enforced isolation.

Confidential computing and hardware-enforced inference isolation for the most sensitive workloads

Confidential computing running AI workloads inside a Trusted Execution Environment makes vendor access to prompt content architecturally impossible rather than merely contractually forbidden. H200 confidential mode is not yet listed in GA by any major hyperscaler, and AWS has no GPU confidential computing offering. Intel TDX is broadly available, and AMD SEV-SNP is broadly available across major hyperscalers.

The question for AI teams is no longer whether confidential computing is possible but whether attestation is actually enforced end-to-end. Attestation receipts become an audit artifact: they provide tamper-evident proof of which software ran on which data, closing the audit-rights gap that even a well-drafted SOC 2 clause leaves open for runtime behavior. This is the point at which architecture and contract reconnect, because the attestation receipt is evidence the audit-rights clause can require the vendor to produce.

How Confidant AI approaches the architecture-first privacy model this strategy requires

Building privacy into AI architecture from the start, rather than adding contractual patches to a surveillance-by-default system, is the only way to achieve the combination of capability and genuine data control the preceding sections describe. This is an architectural commitment, not a policy setting that can be reversed by a privacy-policy update of the kind the contract clauses earlier in this piece must explicitly guard against. The positioning bears directly on the dual-layer argument. Tools designed with privacy-preserving architecture from the start sidestep this problem entirely: since the system is built to keep data with the user regardless of tier or license, there is no dangerous default to opt out of and no buried menu to navigate. For organizations that have worked through the contractual checklist and still face the audit question of whether vendor access is truly prevented, Confidant AI's architecture-first approach is the answer the contract cannot fully provide on its own. Solutions like Confidant AI that build confidential computing into the inference layer ensure that prompts and outputs remain inaccessible to the service operator by design, making the contract's prohibitions a backstop to an already-closed technical boundary rather than the only lock.

Other providers and where they sit on the contractual and technical spectrum

The major frontier model vendors have moved toward stronger enterprise contractual protections, but the controls they offer are layered on top of architectures built for general access. Anthropic Claude API offers a DPA with no training on customer data as default. OpenAI API offers a DPA with no training on customer data as default, and ZDR for eligible API customers upon prior approval by OpenAI sales. Azure OpenAI offers a DPA with no training as default and EU data residency available. Google Vertex AI, AWS Bedrock, and GitHub Copilot Business each offer a DPA with no training as default. Free-tier or individual-paid versions of these same products, Claude.ai free and ChatGPT free and individual paid, carry no DPA and may use data for training. This is the fair point the comparison makes: even the strongest enterprise DPA from a major vendor still requires the contractual work the article has described, while the architecture-first alternative remains the more complete answer.

Putting the two layers together: a practical sequence for enterprise teams

The contractual and technical layers are not redundant. Each one covers specific gaps the other cannot reach, and the most defensible enterprise posture works through them in sequence: you use contract audit rights to verify technical controls, and technical attestation to make contract compliance checkable. In the contract, place the five clauses and check document consistency. The training carve-out with "in perpetuity" language must appear in the MSA, DPA, and order form, not just one of the three. Prompt and output ownership must be vested in the customer. Subprocessor extension and named disclosure, model change notification with the right to continue on the prior version, and audit rights requiring SOC 2 Type II, executive attestation, and cooperation with algorithmic audit complete the set.

At deployment, verify the technical layer. Deploy a self-hosted gateway with PII redaction inside the network perimeter before any prompt reaches the model provider. Configure zero-retention or ZDR if the vendor offers it, and document the configuration as part of the governance record. For the highest-sensitivity workloads, verify whether the inference environment supports TEE-based confidential computing and whether attestation receipts are available for audit. This is where the audit-rights clause and the technical layer reconnect.

Ongoing, use audit rights to verify that technical controls remain in place. For regulated industries, DORA Articles 28 through 30, binding since January 17, 2025, require the register of information and audit rights for critical or important functions. These are not optional governance steps. The organizations with the strongest posture treat the contract and the architecture as a single program: the contract defines what must be true, the architecture makes it structurally true, and the audit rights provide the evidence that both are operating as designed.