The first sign is usually a queue. A functional leader can name an AI workflow their team needs, but can't start it, because every experiment routes through a central inbox they don't control. A company running AI in more than one function doesn't need a headquarters that picks every use case and signs off on every experiment. It needs a small hub that holds the shared guardrails and the visibility, while the people closest to the work decide what to build and own whether it pays off.

Two ways this usually breaks

Once AI is running in more than one part of the business, executive teams tend to reach for one of two structures. Both are common, and both tend to break in ways you can watch happen.

The first is a headquarters. A central AI team owns the roadmap, chooses the use cases, and approves each experiment before it starts. It feels like control, and at first it looks like order. Then the queue forms. Marketing waits behind finance, which waits behind operations, and the team that was supposed to accelerate the company becomes the reason everything routes through one inbox. The people who understand the actual work are on one side of the wall, and the people with the authority to approve it are on the other.

The second is no structure at all. Every department runs its own AI however it likes. Speed returns, and so does the mess: three teams building the same thing, an agent somewhere with far more access than its task requires, and no shared record of what's running where. Nobody decided this would happen. It happened because nobody decided anything.

Plenty of companies operate somewhere between these extremes, with capable central teams and tiered models. Both patterns still recur often enough to be worth naming, and both come from the same mistake. The work of governing AI splits into two different kinds, and the failure comes from handing both kinds to the same body.

Why a headquarters can't own the work

A central team deciding where a company's AI efficiencies should come from is deciding without the knowledge to decide well. It doesn't run the marketing funnel, close the books, or work the support queue. A detached central team is prone to putting AI where it doesn't belong and missing the places it would earn the most, not from carelessness but because it can't see what a functional leader sees every day.

There's a cleaner way to say what goes wrong. A true owner controls the decisions, the data path, and the resources needed to move an outcome. A headquarters that approves work it doesn't run holds a veto, not ownership. It can slow a workflow and it can stop one, but it can't make one succeed, because success depends on judgments only the function can make.

The incentive sits crooked too. When a central team vetoes a function's AI project, the central team doesn't miss the revenue target or the service level the function is measured on. The function does. Authority on one side of the wall and accountability on the other is the deeper failure, and process rarely fixes it while the wall stands. A central AI team should not own the agents or pick the work; that argument runs through Anchor's agent-management piece, and it points at the same boundary this article draws around structure.

What the hub owns, and what it coordinates

Strip the approve-everything power out of the central team and something smaller and more useful is left. Call it a hub. It's a label for elements the Anchor framework already names, gathered into one accountable place: shared guardrails, central visibility, explainable exceptions, and pattern-conformance.

The hub's charter is limited and specific. It owns the governance system itself: the common control framework every function operates inside, the evidence standard, the publication process, the exception routing, and the maintenance cycle that keeps all of it current. Within that framework, the substantive requirements for access, data handling, security, and acceptable use are authorized by the domain owners who already hold them, so no single guardrail is both hub-mandated and domain-owned at once. The hub owns the central logging standard, because AI work leaves a trail across chat logs, generated files, API calls, tool invocations, approvals, and system changes, and capturing that trail through approved enterprise paths is what lets authorized owners inspect activity, exceptions, control events, and relevant outcomes. It designs the exception and escalation paths, so when a function hits the edge of a guardrail there's a known way to raise it and a known person who answers. For the handful of standards that genuinely should be set once for everyone, such as an approved-model list or a vendor standard, it convenes the decision and publishes the result, because those choices sit on top of authority that procurement, security, and enterprise architecture already hold. And it conforms the patterns that prove out locally into standards other functions can adopt.

The hub needs a particular kind of capability, whether it's staffed as a team or convened from existing roles: people who can keep context sizes down, teach an agent new skills, wire logging into the systems the company already runs, and set the controls that make AI work observable inside the existing enterprise stack. Not domain experts in finance or marketing, but LLM facilitators fluent enough in the operating model to write standards a function will actually use. The domain expertise already lives in the functions. The hub exists to enable those functions, not to out-think them.

Just as important, the hub operates inside the company's existing control framework rather than replacing it. Legal still owns regulatory interpretation, security owns the security posture, procurement owns vendor contracting, enterprise architecture owns platform standards, and data owners own data-access policy. Those authorities don't dissolve because AI is decentralized. When a shared AI standard touches one of them, the hub coordinates the decision and publishes the result as a joint standard rather than overruling the authority that owns it. The hub owns the framework that standard lives in, its evidence rule, and its maintenance; the domain authority authorizes the substantive control inside it. It convenes and records the agreement; the underlying authority stays where it already sits.

Where the hub itself sits, under a CIO, a chief AI officer, or a small standards function reporting elsewhere, is a fit question rather than a universal answer. It depends on where the company already keeps its enterprise standards and where an accountable owner can credibly hold them. And its authority comes from two things: the formal decision rights it's given, and the visibility that lets it exercise them on evidence rather than opinion. Visibility alone creates influence; decision rights and executive sponsorship create authority.

The allocation, in one place

Here is the whole allocation, compressed.

  • The hub sets the shared system once, for the enterprise. The common control framework, the evidence standard, the central logging standard, the exception and escalation routing, and the maintenance cycle, which the hub owns outright. The substantive controls inside the guardrails, for access, data handling, security, and acceptable use, are authorized by the domain owners who hold them; approved-model and vendor standards it coordinates with procurement, security, and enterprise architecture, then publishes, rather than deciding alone. Accountable party: the hub lead for the governance system, jointly with the relevant authority for the controls inside it. Evidence owed: published standards and a record of exceptions granted.
  • The function decides and owns locally. Which AI work fits its mission, how the work is redesigned around the tool, how adoption is managed, and the operating outcome. Accountable party: the named functional owner. Evidence owed: the result in the business's own terms, plus the logs, control events, and recorded exceptions an authorized owner can inspect; these trace how the work ran rather than proving on their own that it complied or paid off.
  • Some decisions escalate. A requested exception to a guardrail or a material change in access goes to a named authority before the work proceeds. A detected breach goes to a named authority who can halt the work. In both cases the authority follows the domain the decision touches: security for a security exception, the data owner for a data-access change, legal for a regulatory question. Accountable party: that named owner. Evidence owed: the decision and its rationale, logged.

Ordinary work inside the guardrails needs none of this. It's pre-authorized by the guardrails themselves, so nobody asks permission for the routine case. The shared standard can still single out a limited high-consequence class, work that sends externally, alters production data, or makes a consequential call, for a preventive technical control or a prior domain review before it runs. Escalation exists for the cases that carry real consequence, and it names a person who can act, not a committee that convenes.

This is emergence under guardrails. Functions pilot their own AI under shared standards rather than executing a master plan handed down from the top. The hub doesn't need to be the big brain that plans the whole company's AI; it needs to keep many small pilots legible and reconcilable while the functions do the learning. Decision rights and cadence are different instruments: the allocation here says who holds each class of decision, while an operating cadence governs when each decision returns to a table for review.

The test that separates this from a reshuffled org chart is ownership. For any AI workflow that matters, name the single person who controls the workflow, the data path, and the resources to change it. If that person sits inside the function, the model is working. If the only name you can supply sits in the central team, the company has quietly rebuilt the headquarters and will feel the queue again.

Governing without a queue

The most common way a hub decays back into a headquarters is by turning its visibility into a gate. Watching becomes reviewing, reviewing becomes approving, and before long every experiment waits on the central team again.

The distinction is worth holding precisely. A guardrail constrains in advance: it defines what any function may do, once, so nobody has to ask permission for the ordinary case. Enforcement then runs in more than one mode. Some controls prevent a high-consequence action outright or route it for prior domain review; monitoring catches the breaches and drift the guardrails were meant to prevent, by making misuse or an agent operating outside its lane observable after it starts. Monitoring is one enforcement mode, not the whole model, and none of these requires signing off on each pilot.

But visibility on its own detects; it doesn't stop. So the model pairs monitoring with a named authority. When the hub sees a workflow breach a control, operate with overbroad access, or drift outside its guardrails, it escalates to the owner of the domain that breach touches, who can halt the work. That authority is set in advance, not improvised in the moment. The hub notices; a named decision-maker stops. A requested exception takes the other path: it reaches its named authority before the work starts, so a deliberate variance is decided up front and a detected breach is contained after the fact. That preserves the non-gating principle for ordinary work while making sure a material breach has someone who can end it before it spreads.

Central logging is the objective, not a boast. Shadow tools, embedded vendor features, and personal accounts mean coverage is never total, and the honest posture treats a coverage gap as a governance finding rather than pretending it away. The same access discipline Anchor has written about, where an agent gets only the access its task requires, is enforced this way: through guardrails and logging plus a named authority for exceptions, rather than through a person approving each routine request. The same discipline applies to the weekly standard-and-drift check Anchor has described elsewhere, which keeps a working agent honest from one week to the next.

Conforming the patterns is where the hub earns its keep

In Clark's experience, the work that pays off most is conforming: turning what one function proves into a standard the others can adopt.

This is a pattern Clark carried out of his data-warehouse years. The teams that scaled best didn't plan every table from the center. Each built its own specialized outputs while agreeing on the shared definitions that let those outputs be joined together later. Drift was expected, and it was fine, as long as it stayed reconcilable. Perfect was never the standard.

AI governance has the same shape, and the movement is concrete. Say a support team works out a reliable way to let an agent draft customer replies: a specific review step before anything sends, a logging pattern that makes each draft auditable, a prompt structure that holds up under edge cases. The customer-reply workflow itself doesn't transfer, because finance and operations don't draft support replies. What transfers is the control pattern underneath it. The hub reads the evidence, extracts the review step, the logging pattern, and the prompt discipline as a reusable standard, and hands that standard to other functions to apply to their own AI work. A named owner in the hub keeps the standard current and can revise or retire it when a better pattern emerges. That's codification after learning, not planning before it.

A pattern is proven only when four things hold: evidence from live use, an identifiable control benefit, applicability beyond the one workflow it came from, and review by the authority whose domain the standard touches. The hub identifies a pattern that clears that bar, documents it, maintains it, and retires it when something better arrives; it does not convert every local success into a binding enterprise standard on its own. A central team that only watches produces a log nobody uses, and one that only blocks produces a queue nobody clears. A hub that conforms turns proven local patterns into standards other functions can adopt, which is the one thing neither a headquarters nor unmanaged sprawl can do.

A diagnostic you can run this week

None of this needs a new tool or a new program. It needs an honest hour and a few direct questions.

  • Think of the last AI decision that actually mattered. Who made it, a function or the central team, and who should have? A mismatch there is the whole problem in miniature.
  • List what your central AI team gates. If it signs off on experiments before they run, you have a headquarters, whatever it's called on the org chart.
  • Name one guardrail every function shares, and say where the evidence of compliance is logged. If you can't name the guardrail, execution is unmanaged. If you can't find the log, you have rules without visibility.
  • When work falls outside a guardrail, who decides, by when, and on what evidence? If no one can answer, your model has visibility but no exception authority, which is the gap that turns a quiet breach into a loud one.
  • For one live workflow, name the person who controls the workflow, the data path, and the resources to change it. If no single name fits, that workflow has a coordinator, not an owner.
  • Name one pattern that proved out in a single function and has since become a standard others use. If there is none, your central team is watching or blocking, but not yet conforming, which is the part that pays.

The diagnostic exposes where the line is drawn wrong: a workflow with a coordinator instead of an owner, a guardrail no one can name, an exception with no authority behind it, a good local pattern that died because nothing conformed it.

The hard part is political rather than architectural: reallocating authority away from the team that currently holds it, toward the function that will now own the outcome. Those people have budgets, headcount, and reasons to resist, and that is where these transitions usually stall.

If your central AI team is gating work it should only be watching, or every department is running its own way with no shared guardrail, an Anchor AI Bearing Assessment can find where the hub-and-function line is misdrawn before your next org decision commits you to the wrong structure.

Sources

This is a practitioner argument. It draws on Anchor Enterprise's documented operating-model framework and Clark's own experience conforming independent work across many teams, rather than on external research. Where it ranks one part of the hub's work above another, that is Clark's stated practitioner judgment rather than measured evidence. It builds on related published Anchor Logbook work: The Real AI Problem Is Your Operating Model, AI Agents Need Workforce-Style Management, Not Tool-Style Neglect, The Access Control Gap, Your AI Agent Worked Last Week. Who Checks Whether It Still Works This Week?, and Your AI Strategy Needs an Operating Cadence, Not Another Steering Committee.