What your cloud provider can see about your AI adoption

There is a version of this conversation that gets conspiratorial fast, and it is not the useful one. The useful one is duller and more alarming: the visibility your provider has into your AI programme is documented, published, and in most cases something your organisation agreed to in writing. Nobody hid it. Nobody in the programme read it.

Everything below is drawn from public product documentation and standard contractual terms that any customer can pull up today. None of it comes from privileged access, and the point is that none of it needs to.

The four layers

Provider visibility is not one thing. It arrives in layers, and they have genuinely different privacy properties, which is why treating them as a single question produces bad decisions in both directions.

Billing and usage telemetry

The most complete layer, and the least discussed. Consumption records exist for every metered service, because metering is how the commercial relationship works. Token counts, request volumes, which model, which region, which project, at what hour. This data has to exist for you to be invoiced correctly.

Usage metadata is a strong signal even with no content attached. A provider can see which of your projects grew tenfold last quarter, which went quiet, and roughly what shape of workload each one is. Anyone who has read a consumption dashboard knows how much of a strategy that implies.

Service and audit logs

Every major cloud publishes documentation for its administrative audit logging: who called what API, when, from which identity. The important detail, and the one most often misread, is that some categories of administrative logging are on by default and cannot be turned off, because they exist for the provider's own security and compliance obligations. Data-access logging, which is more granular, is usually opt-in and usually off.

Read your own console. The distinction between the logs you control and the logs you do not is documented per service, and it is not consistent across services within a single provider, let alone across providers.

Content: prompts and outputs

This is where enterprise terms diverge most sharply from consumer terms, and where the public documentation is genuinely reassuring if you have the right agreement. Major providers' enterprise offerings contractually commit not to train foundation models on customer content, and publish those commitments.

Two caveats that survive the commitment. First, abuse-monitoring retention is frequently a separate clause: content may be retained for a stated window for safety review even where training is excluded, and some providers offer zero-retention on request rather than by default. Second, the commitment attaches to the agreement you signed, and staff using a consumer account for work are not covered by it. The second caveat is where nearly all real exposure lives.

Support and human review

Raising a support ticket with an attached example is a disclosure, and a voluntary one, and it does not usually occur to the engineer doing it at eleven at night. Debugging paths that involve sharing a failing payload can move content outside the boundary the contract otherwise draws.

What to actually do

The instinct after reading this is to escalate it as a risk. That produces a memo. The more useful response is four checks, each of which a competent person can complete in a day from documents you already have.

• Pull the current agreement and find the training-exclusion clause, the retention window, and whether zero-retention is default or on request. Cite the section number in your own note. If you cannot find the clause, that is the finding.
• List which log categories are enabled, which are enabled by default and cannot be disabled, and which you turned on yourself. Do this per service, not per provider.
• Measure consumer-account usage for work. This is the largest real exposure and the one no contract covers. Entry 003 in the canon covers how to measure it without turning it into surveillance.
• Write the support-path rule down. Something as simple as requiring redaction before attaching a payload to a ticket closes most of it.

The asymmetry worth naming

Your provider can see the shape of your programme with more resolution and less effort than your own executive team can, because their view is instrumented by default and yours had to be built. That is not a scandal. It is a description of how metered infrastructure works, and it has been true of every utility relationship any large organisation has ever had.

It becomes a problem in one specific case: when the provider also competes with you, or sells to your competitors an offering shaped by aggregate patterns across customers. That is a commercial question rather than a privacy one, it belongs in the concentration answer you prepare for the board, and it is the version of this concern worth taking seriously.

The exposure that will actually hurt you is not the provider reading your prompts. It is four hundred employees pasting client material into a consumer account that no agreement of yours governs.

Sourcing

Every claim here is checkable against provider documentation and standard enterprise terms, which change. Where this essay describes a general pattern across providers, verify the specific position of yours before acting on it, and tell us if we have it wrong. Corrections are logged publicly.