The cloud-runtime question for enterprise Claude is settled. AWS shops route through Amazon Bedrock. Google Cloud shops route through Vertex AI. Direct deployments now sit inside the customer's perimeter via self-hosted sandboxes and MCP tunnels that shipped this month. The question "where should Claude run" has a workable answer for every common stack, and a circulating LinkedIn post this week argued — correctly — that the debate has shifted from "should we use Claude" to "where do we wire it in."
The diagnosis is right. The prescription that usually follows — "now write the usage standards" — is the part most enterprises will get wrong, for the same reason most enterprise AI rollouts have already gotten this wrong on every prior tool.
The Word "Standards" Is Doing Work
Calling the next layer "usage standards" makes it sound like a policy artifact. A document the central AI committee drafts, approves, and circulates. A page on the wiki. A two-hour all-hands. That is what most enterprises will produce in Q3. It will not survive contact with the actual work, and the divergence between the document and the operator behavior will start within sixty days of publication.
The reason is structural and the corpus has been arguing it from a different angle for six weeks. The May 20 piece on faculty AI governance laid out the version of this argument applied to higher education. The mechanism is identical in the enterprise. Standards that hold under stress are authored by operators who have worked through the actual edge cases in their actual workflows for weeks. Standards that fail are authored by committees of policy interpreters who have used the tool in artificial training contexts and are extrapolating from surface familiarity to operational judgment.
The output of those two processes carries the same word — "standards" — and looks the same in PDF. One survives the first stress case. The other becomes the canonical example of the gap between policy and practice.
What the Edge Cases Actually Look Like
The reason a central standards document fails is that the standards that matter are discipline-specific. Marketing's prompts touch customer data and outbound brand voice; the failure modes are leakage of unpublished campaigns and tonal mismatch on cross-channel publish. Finance's prompts touch material non-public information and account-level identifiers; the failure modes are inadvertent disclosure into model context and downstream training. Legal's prompts touch privileged communications; the failure modes are waiver and the discoverability of LLM transcripts in subsequent litigation. Engineering's prompts touch production data, customer PII, and intellectual property in source form; the failure modes are everything the security team already knows plus the new class of model-egress risks.
A central usage-standards document compresses all of these into a paragraph each, written by someone whose closest experience is the third-party security review of the procurement contract. The compression itself is the failure. The marketing operator who has actually been red-teaming customer-data prompts for six weeks knows the failure mode that matters in their work. The compression in the central document does not capture it because the compression was done by someone who was never in the seat.
Where Real Standards Come From
The enterprises that will end up with standards worth defending are the ones who treat the authoring layer the way safety-critical industries treat their procedure manuals. Operators in each domain spend sustained time in the actual workflow with the tool, surface specific failures, document them, and write the discipline-specific rules. The central function's job is to aggregate, not to author. The marketing team's three pages on outbound-brand prompts is the canonical document for marketing. The finance team's two pages on MNPI handling is the canonical document for finance. The aggregated central artifact is a table of contents, not a policy.
This is the wrapper-pattern argument at the enterprise scale. Same shape as the personal version. The operator writes the rules they encode in their own hooks and lint configurations because they are the only ones who hit the edge cases the rules need to handle. The central function holds the index.
The Procurement Bite Lands at the Runtime Layer Too
The cloud-runtime decision treated as settled is partially a usage-standards decision in disguise. Bedrock has one default for training-data carve-outs and prompt-logging retention; Vertex AI has another; the new self-hosted-sandbox direct path has its own. The choice of runtime has policy buried in it. Calling that decision "settled" because every common stack has a workable answer understates how much of the standards work was already decided in the contract before any committee met.
This is the same pattern as the May 18 piece on shadow IT 2.0. The procurement door is where the actual policy gets written. The committee door is where the discussion document gets written. The enterprises that staff operators into both doors get standards that match the runtime. The enterprises that staff operators into only one door get standards that diverge from the runtime within a quarter.
Why "The Holding Pattern Is Expensive" Is Half True
The source piece is correct that delay pushes adoption outside governed environments. The implicit claim is that an enterprise standard would have kept things governed. It would not have. Central standards never govern operator behavior. They govern the policy document. What actually governs operator behavior in a sustainable way is the operator's own standards — encoded in their own tooling, their own hooks, their own lint, their own playbooks for the workflows they actually run. The holding pattern is in fact the period when operators with that posture are building standards that will be the de facto rules by the time the official document ships.
This was the prescriptive close of yesterday's piece on opening the personal stack at the individual scale. The same logic applies at the team scale. The marketing team that has spent the "holding pattern" period encoding their actual prompt guardrails into their own internal MCP server has authored their standards. The marketing team that has spent the same period waiting for the central policy document has authored nothing.
The Next Layer Is Authorship
The vendors solved distribution. The next layer is authorship — which operators, with what depth of praxis, are allowed to write the standards that will actually govern the work. The enterprise that ships a twelve-page AI Usage Policy in Q3 will discover in Q4 that the operators who built their own standards in Q2 are the ones who set the de facto rules. The policy document and the lived standard will diverge. Every prior wave of tool adoption — version control, container runtimes, IDE choice, CI pipelines — has produced the same divergence, and the resolution has always been the same: the operator-authored standard wins, the policy document catches up, and the gap between them is the cost of pretending the central function can author what only the operator can.
Match the layer to the right author. Distribution to procurement. Runtime to platform engineering. Standards to the operators in each discipline who have done the work. The vendors did their part. The hard part — and the part that has not been "solved" by anything Anthropic shipped in the last sixty days — is whether the authoring chair gets assigned correctly inside the customer.
