Skip to content

Standing Up the Function

Once you have a mandate and an accountability map, you need a shape for the function. Who is on the team, where it sits, what it decides, and how it changes as adoption grows. There is no single right structure. There is a right structure for your stage.

When to read this

Read this when you are standing up the enablement function, or when the structure you inherited is getting in the way. The signs are approvals piling up, teams waiting on a central group, or nobody clearly in charge.

The operating models

Most organizations land on one of three shapes:

  • Centralized. One team owns enablement, standards, and delivery. Microsoft describes the AI Center of Excellence as an internal team of experts. It drives AI adoption and prevents fragmented, ungoverned use (Microsoft, 2025). Centralized gives you control and consistency. It becomes a bottleneck as demand grows.
  • Federated. Each function runs its own enablement, with a light central group setting shared standards. It scales, but consistency and reuse are harder to hold.
  • Hub-and-spoke. A central hub owns standards, tooling, and shared assets. Embedded spokes drive adoption inside each function. It is the common middle: central coherence with local ownership.

The Enterprise AI Transformation program architecture covers this same taxonomy at the whole-program level. This page is the operator's-seat version: how you pick and run one model from the enablement chair.

The AI Council

Whatever the model, adoption needs a cross-functional steering group. A workable AI council pairs an executive sponsor with the functions the work depends on: IT, change or enablement, and risk. Its job is to set priorities, unblock the enablement lead, and hold the shared accountability from Who's Accountable for What. Keep it small, and keep it to a cadence.

Funding and decision rights

Two things decide whether the function works:

  • Funding. Enablement needs its own budget, held by the sponsor, not scraped from a project. Executive sponsorship exists precisely to provide the budget and authority the function cannot generate on its own.
  • Decision rights. Write down what the function decides versus what it advises. That covers tool standards, the intake and prioritization of use cases, and acceptable-use guardrails. Ambiguous decision rights are where centralized models turn into bottlenecks.

How the model evolves

The structure is not fixed. Microsoft's guidance describes a lifecycle. Start centralized to consolidate expertise and accelerate adoption. Then move to an advisory model as adoption matures, trading control and consistency for flexibility (Microsoft, 2025). Watch for the inflection point. When the central team becomes the thing teams wait on, push ownership out and shift the center to guidance.

How to choose

Match the model to your stage:

  • Early, or low maturity — centralized. Consolidate scarce expertise and set the foundations.
  • Scaling, uneven across functions — hub-and-spoke. Hold standards centrally, drive adoption locally.
  • Mature, high literacy — federated or advisory. Let teams own delivery while the center sets guardrails.

Pick the lightest structure that still holds standards. Then plan to change it as adoption grows.

Sources

  • Microsoft — Cloud Adoption Framework — Establish an AI Center of Excellence, 2025. An AI CoE consists of an internal team of experts who drive successful and valuable AI outcomes. The AI CoE prevents fragmented or ungoverned AI adoption. View source · verified 2026-07-02 · primary
  • Microsoft — Cloud Adoption Framework — Establish an AI Center of Excellence, 2025. Companies at an early stage of their AI journey benefit from a centralized CoE to consolidate expertise and foundational practices. As your AI adoption matures, you should move toward an advisory approach where the AI CoE supports AI use. A centralized model ensures control and consistency, while an advisory approach provides flexibility. View source · verified 2026-07-02 · primary