Why Contractual Data Clauses Fail Where Private Inference Infrastructure Succeeds

A zero-trust AI architecture for enterprise protects sensitive prompts and data with technical constraints as well as the vendor’s promise to follow the rules. Private inference can prevent vendor access when the infrastructure makes that access impossible, while a contract can only prohibit it. That difference matters most when data exposure cannot be undone, though protection built into the system still depends on a clearly stated trust chain.

Why the AI vendor contract became the primary instrument for data protection — and why that is a structural problem

The general counsel negotiates data-use clauses while the legal operations team reviews data-processing addenda. Across industries, organizations procure AI capability from third-party vendors rather than build it internally, so the vendor agreement becomes the place where confidentiality requirements are translated into commitments. Procurement asks who may see the data, whether it may be kept, and whether it may be used for training. These are necessary questions for any vendor relationship. Yet the answers describe the service’s obligations as distinct from its technical boundaries.

That distinction creates a mismatch between the instrument and the task. Sensitive information flows into infrastructure that the contract does not technically govern, even when the agreement tightly restricts what the operator may do. The operator’s capabilities and its permissions remain separate. A prohibition on access does not remove access. If the enterprise needs the vendor to be unable to inspect a query, negotiating that the vendor must not inspect it addresses a different requirement.

Privacy policies sit further from that technical requirement because they are unilateral statements. They describe intended behavior but provide no enforcement mechanism of their own. Bespoke enterprise agreements offer a stronger contractual position, but they do not necessarily change the data path. The KPMG / Anthropic deployment takes this approach by adding protections that were negotiated with the vendor.

How vendor-drafted defaults and post-signing drift erode the protections enterprises believe they have negotiated

AI vendor agreements begin with the vendor’s business model. Retention clauses can be unclear, while training opt-outs can be found on settings pages. A setting that expresses a preference and an agreement that establishes an obligation are not interchangeable protections.

Even an agreement that begins on acceptable terms can drift. Vendor contracts commonly permit changes to privacy policies or terms of service on short notice, so a training-data carve-out negotiated today can disappear at the next renewal cycle without renegotiation. The enterprise is then relying on a protection whose durability depends on the surrounding amendment terms. Signing does not freeze the whole relationship.

Which document takes precedence can leave a gap even before any terms change. When a services agreement and a data-processing addendum conflict on training permissions, the DPA typically governs data-processing issues only where the order-of-precedence clause gives it priority. That priority is not universal across vendor agreements. A restrictive MSA can therefore be displaced by a permissive exhibit, despite the attention spent negotiating the restriction. The operative commitment emerges from the documents together, rather than from the strongest sentence in any one of them.

The subprocessor layer makes the same problem harder to see. AI vendors use model providers, embedding providers, and vector database vendors that enterprise DPAs may not name because disclosure templates predate agentic architectures. Who gets the data besides the vendor that signed the contract? An internal policy cannot answer that question once proprietary work product goes into a commercial software pipeline. These weaknesses stem from how contracts are written and kept up to date, even when the people negotiating them take confidentiality seriously.

Why the irreversibility of data exposure makes contractual remedies structurally inadequate, regardless of clause quality

Better drafting could fix those weaknesses, but data exposure would still be hard to undo. A contract governs future behavior, while some consequences of disclosure become irreversible as soon as data is exposed. A newly negotiated carve-out cannot undo training that has already happened, clear an existing cache on its own, or make a human reviewer forget what they have seen. These are different kinds of loss of control. A no-training promise describes permitted conduct.

CB Financial Services provides a concrete example of the gap between policy and outcome. Its subsidiary, Community Bank in Pennsylvania, had a data policy when an employee used an unauthorized artificial intelligence-based software application to handle non-public customer information in May 2026. The information that was exposed included names, Social Security numbers, and dates of birth. CB Financial Services reported what happened in an SEC Form 8-K under Item 1.05. Because the application was unauthorized, the example also exposes a boundary of procurement itself. A well-managed vendor contract governs the approved surface.

United States v. Heppner, decided in S.D.N.Y. in February 2026, denied attorney-client privilege for documents made with an AI tool. The court reasoned both that Claude is not an attorney and that its privacy policy permitted third-party disclosure, defeating a reasonable expectation of confidentiality. The disclosed policy was itself part of the problem. No breach of that policy was needed for the privilege claim to fail.

In May 2025, a federal court ordered all ChatGPT logs to be kept, including logs users had already deleted. Separate subsequent orders required OpenAI to produce a de-identified sample at a figure it had proposed against the plaintiffs’ larger demand, with the production order affirmed on January 5, 2026. A litigation hold overrides contractual deletion commitments. Together, these decisions dissolve the assumption that favorable language necessarily preserves confidentiality or control.

What courts and enterprise buyers are now requiring, and how those requirements expose the limits of the promissory model

Morgan v. V2X, in D. Colo. in March 2026, made the conditions for AI use on confidential litigation material explicit. A magistrate judge amended a protective order to require no storing or training on inputs, restricted third-party disclosure, and deletion on request. Disclosure was permitted only where essential to delivering the service, and recipients had to be bound by obligations no less protective than the order required. Standard consumer and low-cost tools did not do what the order required.

Legal teams are rejecting deals at final review when subprocessor disclosure is absent, because the agreement does not identify the model provider that actually processes customer data. A disclosure clause that works names each subprocessor by its legal entity and states what data goes to each. It also provides advance notice of model swaps and audit rights. Without those provisions, a change of model can change who sees the data without giving the customer a meaningful opportunity to assess that change.

When a regulator asks an enterprise to show that the vendor’s stated policies are being followed, the enterprise usually has no way under the contract to get the evidence it needs. SOC 2 reports were designed for systems other than AI and, on their own, offer insufficient assurance. The question shifts from what the vendor has agreed to do to how the enterprise can establish what happens.

The KPMG deployment represents the strong version of the contractual approach. Bespoke protections can express an enterprise’s requirements more carefully than default terms. What enforces those requirements while the data is being processed? A promise, however well resourced its negotiation, is not the mechanism that prevents prohibited access.

How can an enterprise prevent its AI vendor from seeing internal prompts and data through private inference?

Private inference changes how the rules are enforced by keeping processing inside infrastructure that the customer controls. Data residency, access logging, and isolation can then become properties of the system rather than claims the vendor makes about its conduct. The data path becomes the relevant boundary. Instead of asking only whether access is forbidden, the enterprise can ask whether access is technically possible within the design.

Confidential computing brings this approach to the cloud by using hardware to enforce the rules. Protection can extend beyond dependence on the AI vendor honoring its privacy policy. This distinction separates assertion from a verifiable constraint. A vendor-no-access claim is architectural only to the extent that the system’s design prevents the access being ruled out. The phrase “private inference” alone is not a substitute for establishing that boundary.

The restrictions in Morgan call for controls that can be built into private inference infrastructure. Isolation can limit disclosure, while controls over retention and use can support no-training and deletion requirements. Access logging provides evidence about system behavior. The court expressed its requirements contractually because no architectural standard existed in the proceeding. It did not make contractual language equivalent to the controls needed to fulfill those requirements.

Confidant illustrates the architectural model by treating privacy as a property of the system’s design. The system makes some kinds of data exposure impossible as well as forbidden. The basis for evaluating the claim is which party is prevented from seeing which data and what part of the system imposes that restriction.

Why the architectural approach does not eliminate all trust assumptions, and what the residual trust chain looks like

Architecture does not make trust disappear from the system. Confidential computing relocates trust toward the hardware manufacturer and, in managed cloud deployments, the cloud provider. That is the strongest qualification of the architectural argument. A technical restriction must be evaluated with its dependencies, rather than treated as an unconditional guarantee merely because it operates below the application.

Apple’s Private Cloud Compute makes this trust chain explicit and auditable. Its binaries are publicly available for inspection, and its Security Bounty program extends to Google Cloud-hosted infrastructure. The privacy promise is presented as verifiable rather than merely asserted. This gives scrutiny a defined object to examine. It does not remove the need to assess the parties and components on which enforcement rests.

On-premises private inference takes the cloud provider out of that chain but adds costs to buy equipment and demands to run it that most mid-sized enterprises cannot meet right away. Confidential cloud computing is the practical alternative for those organizations, though it has overhead costs. The comparison is between dependence on promised behavior and dependence on technical enforcement with identifiable assumptions. Architecture is stronger on enforceability when its constraints hold, even when it is not cheaper or simpler.

What the gap between contractual and architectural protection means for how organizations should evaluate AI procurement

The procurement implication is a tiering question rather than a blanket rejection of contracts. Which exposures would have legal, operational, or reputational consequences severe enough that promised behavior is insufficient? For other uses, it may make sense to keep relying on well-drafted clauses.

For banking, healthcare, and law, the court record gives that distinction practical weight. Morgan specifies protections that standard consumer and low-cost tools do not meet, while Heppner shows that disclosed policy terms can defeat a claim of confidentiality without any breach. Permission to process data is not the whole inquiry. The terms that allow processing and the way it is done can affect whether the intended legal protection holds.

For enterprise procurement more broadly, subprocessor disclosure is the first practical test. An enterprise cannot tell who gets its information unless the vendor can name every model provider that touches customer data, explain what data goes to each, and promise advance notice of model swaps. Strong language elsewhere cannot fill that gap. Where the recipients are known, the next question is whether the enterprise can obtain evidence of compliance or must accept an assertion.

The architectural option therefore warrants evaluation as an enforcement choice. For irreversible exposures or legally required confidentiality, technical constraints provide prevention while contract language remains a supplement. Confidant’s framing of “AI without surveillance” expresses the underlying procurement question without settling it for any particular deployment. The decisive distinction is whether the organization’s required protection rests on what a vendor promises not to do or on what the system prevents it from doing.