What Your AI Contract Doesn't Cover
The enterprise terms you signed with your AI providers protect your prompts and outputs. They say much less about what those providers can observe in everything else.
Something structural shifted in the AI market over the past eighteen months, and most enterprise risk functions haven’t caught up to what it means for their vendor relationships.
The major AI labs are no longer pure infrastructure providers. OpenAI built a computer-using agent and folded it into ChatGPT Agent, an agentic layer inside its flagship product. Google is weaving Gemini directly into Workspace. Anthropic has moved into the operating layer of the workplace itself: in June it launched Claude Tag, an always-on agent that lives inside a company’s Slack channels and, in its own description, learns ever more about the work as it follows along. Microsoft has gone further still, into the documents themselves: Copilot now sits inside Word, Excel, Teams, and Outlook, reading the work as it is written, on top of an Azure layer that hosts models for the same customers whose applications compete with Microsoft 365. The pattern is consistent. The companies that sell AI infrastructure are also building application-layer products that compete with the software vendors who use that same infrastructure, and increasingly, products that sit inside the customer’s operations and observe them.
The clearest sign of where this goes appeared in June 2026. AWS introduced a model-to-model migration capability in AWS Transform that scans a customer’s codebase, identifies its dependencies on OpenAI, Google, and Anthropic, and generates a plan to move those workloads onto Amazon Bedrock, AWS’s own model service. The engineering value is real. Structurally, it is also one infrastructure provider shipping a tool that reads how deeply you have built on its competitors and converts you off them. Visibility into your architecture and a direct competitive interest in it are not separate concerns there. They are the same product.
This is a familiar dynamic in platform economics. What’s less familiar is the specific implication for enterprise AI governance. If your model provider now competes with your software vendors and occupies the infrastructure layer beneath them, what does your contract actually say about what they can observe about your operations?
I spent time recently reviewing the standard enterprise terms for four major AI providers from primary sources. What I found is a gap that is only starting to be named, and named at a different layer than the one that matters most here.
What Providers Can Observe (Without Training on Your Content)
The conversation about AI data privacy has been dominated by one question, is my vendor training on my data? This is a reasonable question and the major providers have responded to market pressure. Anthropic’s commercial terms prohibit model training on customer content outright. OpenAI provides opt-out controls. Google Cloud’s enterprise terms restrict processing to service provision.
But training on content is not the only form of strategic visibility.
When your organization uses an AI API at scale, your provider sees a different class of data. Usage patterns. Which business domains you’re querying. At what volume, and at what cadence. What failure patterns emerge. How your usage scales over time. What price tier you’re operating at. Which capabilities you lean on most heavily.
None of this is your content. It’s metadata about your operations. And it’s potentially more strategically valuable than your content, because it maps your dependency structure. A provider watching your usage patterns over twelve months can infer which workflows you’ve automated, how operationally dependent you’ve become, and where your organization is concentrating AI investment. That’s a competitive intelligence profile, assembled from infrastructure-layer visibility, with no inference required from the content of your prompts.
And the surface is widening. As organizations connect their internal systems to models through the Model Context Protocol, the open standard Anthropic introduced and the other major providers have adopted, more than usage patterns pass through. The tools you expose, the calls your agents make, and the results those calls return all enter the model’s context. The map of which operational systems you have wired to AI becomes visible at the same layer as how often you use it.
The deepest form of this visibility is no longer remote. In June 2026, AWS committed a billion dollars to a Forward Deployed Engineering organization that places its own engineers, working alongside its agents, directly inside customer teams on short deployment cycles. It is not alone. Google Cloud is fielding forward-deployed engineers of its own, and OpenAI and Anthropic have stood up comparable units. The stated purpose is the last mile, getting AI into production. But look at the design. AWS describes implementing an enterprise-wide semantic context, an ontology of the customer’s business, in nearly every engagement. That is the provider’s people, inside your operations, building a structured model of how your organization works, on infrastructure the provider owns. At that point the observation is not a byproduct of API traffic. It is the service.
This is not a theoretical concern. It’s a structural feature of how AI is now sold and deployed, and the question of whether standard contracts address it has a clear answer.
What the Contracts Say
I reviewed the standard enterprise agreements for OpenAI, Anthropic, Google Cloud, and Microsoft. In each case, I focused on three questions: how is protected customer data defined, what restrictions apply to the provider’s use of it, and whether usage metadata appears as a named category.
OpenAI Services Agreement. Section 17 defines “Customer Content” as “the Input and the Output.” That includes your prompts and the model’s responses. Section 4.2 limits OpenAI’s obligations to Customer Content. Section 3.3(e) prohibits the customer from using outputs to develop competing AI models. No equivalent restriction runs against OpenAI, and no defined usage-metadata category appears in the terms.
Anthropic Commercial Terms of Service. Section B contains the training prohibition: “Anthropic may not train models on Customer Content from Services.” The prohibition is flat and unequivocal, which is the strongest protection in this area among the four providers I reviewed. But “Customer Content” is defined as Inputs and Outputs. The same narrow definition. Section E.1 elevates Customer Content to Confidential Information status. Section D.4 prohibits the customer from accessing the services to build a competing product. Again, no equivalent restriction on Anthropic. Usage metadata does not appear as a protected category.
Google Cloud Data Processing Addendum. The picture here is more textured, and among the strongest of the four. The CDPA defines “Customer Data” broadly, as “data provided by or on behalf of Customer or its End Users” through Google Cloud Platform, or “submitted, stored, sent or received by or on behalf of Customer” through Workspace, not a narrow inputs-and-outputs formulation. Under Section 5.2, Google is instructed to process that data only on the customer’s instructions and only “to provide, secure, and monitor the Services.” That is a purpose-bound commitment, and a good one.
Two complications. First, “monitor” is load-bearing language. Monitoring the services necessarily involves observing usage patterns. If usage metadata is classified as data Google observes in the course of monitoring rather than data the customer provides, it falls outside Customer Data entirely. Second, the CDPA is structured primarily as a GDPR compliance framework. Its protections are most robust for enterprises subject to European data protection law. For US-based enterprises operating outside GDPR scope, the contractual architecture is present but the enforcement and standing landscape differs.
Microsoft Products and Services Data Protection Addendum (updated May 22, 2026). Microsoft is the most vertically integrated of the four, and on paper the most explicit. Its protected category is broad. “Customer Data” is defined as “all data, including all text, sound, video, or image files, and software, that are provided to Microsoft by, or on behalf of, Customer through use of the Online Service,” and under Nature of Data Processing the customer “retains all right, title and interest in and to Customer Data,” while “Microsoft acquires no rights.” Microsoft further commits that it will not use that data for “user profiling,” “advertising or similar commercial purposes,” or “market research aimed at creating new functionalities, services, or products,” except on the customer’s documented instructions. That is a stronger, broader definition than the input-and-output framing above.
But Microsoft is also the only one of the four that names the observational layer directly, and having named it, reserves it. Under “business operations incident to providing the Products and Services,” the customer authorizes Microsoft “to create aggregated statistical, non-personal data from data containing pseudonymized identifiers (such as usage logs containing unique, pseudonymized identifiers)” and “to calculate statistics related to Customer Data,” in each case “without accessing or analyzing the content of Customer Data,” for a closed list of purposes that includes “internal reporting and business modeling, such as forecasting, revenue, capacity planning, and product strategy.” Read that last one again. The provider may derive statistics from how you use the service, and use them for its own product strategy, as long as it does not read your content. That is the exact layer this piece is about, and here it is written down, permitted, and fenced.
That makes Microsoft the instructive case, not the cautionary one. The other three are effectively silent on this layer. Microsoft governs it: it names the category, grants itself a narrow permission, and bounds that permission with “no content,” “non-personal,” data minimization, and a closed list of purposes. The lesson is not that Microsoft takes more. It is that a contract can actually address what a provider derives from watching you, which throws the silence in the other three into sharp relief.
The finding across the four is not uniform, and the variation is the point. Three of them, OpenAI, Anthropic, and Google, do not define “usage metadata,” “API telemetry,” or “operational data” as a named category at all. Their protection stops at content, your prompts and your outputs. Microsoft is the exception: it names the layer and treats it as a bounded permission it holds, not a protection you own. Either way, across all four, what the provider observes or derives about how you operate is not, by default, yours. Outside Microsoft’s terms, it is largely unaddressed.
What Has Been Named, and What Hasn’t
Enterprise AI governance is still a young discipline, and the conflict at the center of this is beginning to be named, though at a different layer than the one this piece is about.
Earlier this year the Vanderbilt Policy Accelerator published Net Neutrality for AI, by Asad Ramzanali and Akhil Rajan. It argues that foundation-model providers who also compete with the startups depending on them hold a structural conflict, and it proposes an AI-neutrality rule modeled on net neutrality. That work names the conflict, and names it well. But it frames the harm as discrimination: a provider throttling, deprioritizing, or cutting off a competitor’s access, as when Anthropic restricted the coding agent Windsurf’s access to Claude during OpenAI’s acquisition talks. The remedy it proposes is a rule against picking winners.
The mechanism this piece is about is different. It is not discrimination in access. It is observation. What the provider can see about your operations from its position beneath them, and what your contract says it may do with that. A neutrality rule would stop a provider from throttling you. It would do nothing about what the provider learns from watching you. Those are two different exposures, and the second one lives in the definition sections of the agreement you have already signed.
The analogy that fits the observation problem is financial services conflict of interest governance. It is well established that a broker-dealer who serves both as a market maker and an advisor to the same client is in a structurally conflicted position, regardless of whether they have done anything wrong in a specific transaction. The relationship structure itself requires disclosure, assessment, and management. The question is not whether to trust them. It is whether the relationship has been named, mapped, and governed.
AI supply chain relationships are now in a structurally similar position. Your model provider is also a product competitor to the software vendors built on their API, and occupies the infrastructure layer with visibility into your operational behavior. That is a relationship structure that deserves named governance, regardless of any specific concern about a specific provider’s conduct.
Most enterprise risk functions have not done this mapping because the category does not exist in their frameworks yet. AI sits in legal (data privacy), IT (vendor security), or finance (procurement). None of those functions owns the competitive relationship dimension.
The Provider Variation Problem
One finding worth underscoring. The gap is not uniform across providers, and this is itself a governance problem.
Anthropic’s training prohibition is absolute and well-defined. OpenAI’s is conditional and subject to opt-out. Google Cloud’s protections are the most architecturally robust but carry GDPR-jurisdictional complexity and a “monitoring” carve-out that creates definitional ambiguity. Microsoft is the only one of the four to address the observational layer at all, and it does so as a bounded permission it reserves rather than a protection the customer holds.
AWS is the instructive exception. Its service terms address competitive use of usage data more directly than the others, even as AWS is, through Transform and its Forward Deployed Engineering organization, the most aggressive of the providers at operating inside customer environments. Contract language and conduct do not always point the same direction, which is exactly why the relationship has to be governed on both.
An enterprise running workloads across multiple AI providers, which is the norm at scale, has a different risk profile with each one. A generic policy position (”we don’t allow AI vendors to use our data”) does not map to the actual contractual landscape. What is needed is a provider-by-provider assessment that accounts for these differences, and that assessment is not yet a standard enterprise practice.
Three Questions to Ask
These questions aren’t designed to generate alarm. They’re designed to reveal whether your organization has mapped the exposure. If you can answer all three, you’ve done more than most.
One. Have you identified which AI providers have infrastructure-layer visibility into your usage patterns, and which business workflows are represented in that data, including any always-on agents that observe your teams directly or provider engineers embedded in your teams? Most organizations know what APIs they’ve procured. Fewer have mapped what operational behavior is visible to those providers as a byproduct of use.
Two. Do your enterprise AI agreements define “usage data,” “operational telemetry,” or “API metadata” as a protected category, or do they stop at inputs and outputs? This is a contract review question, not a legal opinion question. You can answer it by reading the definition sections.
Three. If your primary AI provider launched an application-layer product that competes directly with a workflow you’ve automated using their API, what would your current contract actually restrict them from doing with what they’ve observed about your operations? If you don’t know the answer, the contract probably doesn’t address it.
What This Is and Isn’t
This is not an argument that AI providers are acting badly. It’s an observation that standard enterprise contracts weren’t written for a world in which your infrastructure provider is also an application-layer competitor, and that the specific exposure this creates, what the provider can observe and what the contract permits it to do with that, sits underneath the conflict others have started to name.
Unnamed risks don’t get managed. They get inherited by default.
The vertical integration of AI labs into the application layer is not slowing down. The enterprises that navigate it well won’t be the ones that assumed the standard contract covered everything. They’ll be the ones that did the mapping, asked the questions, and built governance for the relationship structure that actually exists.
The starting point is straightforward. Read the definition sections of your AI vendor agreements. Find out what “customer data” actually includes. Ask what’s missing. That’s a two-hour review, and most organizations haven’t done it.
All four providers’ terms were re-pulled from primary sources and reviewed on July 21, 2026: OpenAI’s Services Agreement, Anthropic’s Commercial Terms of Service, Google’s Cloud Data Processing Addendum, and Microsoft’s Products and Services Data Protection Addendum (updated May 22, 2026). Citations reflect the published enterprise terms as of that date.
Thomas is the founder of Fellowship Intelligence, which helps organizations design and install governance systems for their use of AI. He writes about AI governance, organizational risk, and the structural questions that enterprise AI raises for how work is controlled.
Fellowship Intelligence helps organizations govern the decisions AI is already making. The Diagnostic is the place to start. Learn more at fellowshipintelligence.com.