Design a central AI team around the services several departments need, then give each workflow a local owner who can decide what acceptable work looks like and arrange its continuing use. Keep approved access, shared technical controls and specialist support clearly assigned. Delegate delivery only where a team has the skills and time to build, check and maintain it.
The useful boundary is visible in an ordinary request. If a repair visit summary misses a part still needed, who fixes the information? If the approved drafting service stops working, who restores it? A shared operating model should let staff answer both questions without searching the organization chart.
Divide the work before choosing the model's name
A central team may provide approved tools, identity and access arrangements, reusable technical components, monitoring and help from scarce specialists. A department still needs to define the task, maintain the relevant business information and judge whether the finished work is useful.
In Microsoft's July 2026 guidance on operating models, local agent delivery depends on teams being able to run, monitor and improve what they build. Its central responsibilities include the platform, identity and security baseline. This is vendor guidance for agent adoption, rather than evidence that one arrangement produces better results in every company.
For a particular workflow, distinguish three decisions:
- Provision. Who supplies the approved service and its technical support?
- Acceptance. Who checks that the task's output meets the business requirements?
- Change. Which adjustments can that owner make, and which need another authority?
A centre can build a solution while a departmental manager owns its business acceptance. A local technical team can build within shared controls while depending on the centre for platform support. Those arrangements can coexist. Calling both of them “hub and spoke” does not explain their different obligations.
The enterprise adoption strategy connects local opportunities to central help. Here, the next decision is the interface between them: the service each side promises, the limits of that promise and the route when it fails.
Give the centre authority and practical contact
In a May 2026 analytics centre discussion, a proposal for a single point of contact prompted participants to compare their experiences of centres.
we had no authority and it just turned into a team that suggested best practices.
An anonymous participant describes an analytics centre, not a verified generative-AI rollout.
In a contrasting reply, another Reddit user who described leading a centre said direct reporting to the chief financial officer and chief marketing officer came with a mandate over two departments. They also described a subsequent reorganization that changed the arrangement. The employers and results are unverified, but the contrast exposes a practical question: which decisions can the centre actually make?
Authority also needs contact with the work. In Marcel Broschk's operating-model article and discussion, founder Sepehr S. argues for central experts working alongside business teams instead of reviewing from a distance. That commercially involved practitioner's view challenges remote gatekeeping; it does not establish that necessary controls should disappear.
Give a central specialist time to see a representative task and its awkward cases. Keep that involvement bounded so every routine edit does not wait for the same expert. The leader's charter should back the centre's responsibilities with delegated authority and committed capacity.
Assign the interface for one repair workflow
Suppose a regional appliance-repair company wants an approved AI service to draft internal visit summaries. A summary helps the next technician see what was completed and which parts remain outstanding before a return appointment. Staff check it against the original visit record. The tool does not diagnose faults, order parts, dispatch technicians or send customer messages.
Claire Bennett, the service manager, owns the summary's use and accuracy. Sam Taylor, a central platform specialist, provides the approved record connection and supports the drafting service. The company's relevant owners have agreed which record fields may be used.
Agree the boundary using the actual task:
| Responsibility | Central provision | Local ownership |
|---|---|---|
Permitted use | Maintain approved access and technical controls with the required reviewers | Keep summaries inside the agreed task and input limits |
Source information | Maintain the connection and report retrieval failures | Keep visit records current and resolve missing repair or parts details |
Output quality | Supply service testing and investigate technical defects | Check each summary and decide whether it is usable for the next appointment |
Continuing support | Name the service support route, coverage and change process | Arrange staff checking, a deputy and the existing manual fallback |
Changes | Assess changes to the model, connection or shared controls | Adapt wording within approved limits and bring new uses for review |
Claire can adjust the summary headings to fit the service desk's work. She cannot authorize a new customer-data feed or automatic sending merely because she owns the workflow. Sam can repair a failed connection. He cannot infer that a missing part has been ordered when the visit record contains no confirmation.
Ownership includes the ability to stop using an unusable output. Claire needs an agreed route to pause drafting and continue from the original records while the relevant owner investigates. Sam needs enough context to diagnose the service issue, with access limited to what his role permits.
Keep this record with the workflow's current instructions. Assign named people and deputies internally, and agree response expectations that fit their actual working hours. A promised support route is incomplete if nobody has accepted the work.
Rehearse a failure on both sides of the boundary
Take one visit record whose parts status is missing. Claire should be able to reject the incomplete summary, obtain the answer through the service process and arrange the next appointment from confirmed information. Escalating every missing business field to Sam would give the centre work it cannot resolve.
Then test a service failure, such as the drafting tool being unavailable. Use a controlled rehearsal that does not disrupt customer work:
Test the service support route
Continue the task manually
Use the existing visit record and checking process while AI drafting is unavailable.
Send an answerable report
Report the service symptom through the agreed route, with permitted diagnostic detail and the task affected.
Confirm the receiving owner
Check who accepts the issue, how Claire receives an update and who authorizes a return to use.
Repair the gap before expansion
If the route has no receiving owner or workable coverage, reduce the commitment or provide support before adding another branch.
Record what happened, including unanswered requests and work that waited. If Sam's team supports only office hours but repair staff need help on Saturdays, agree the manual arrangements or fund different coverage. A local owner's name cannot close that service gap.
For a new shared commitment, bring the actual capacity choice to the AI steering committee. Keep incident response in the established urgent route rather than waiting for the next portfolio meeting.
Move delivery only when the receiving team can carry it
AWS's January 2025 operating-model guidance warns that a central delivery team needs sufficient people and automation to meet demand. Its federated architecture separates business-unit workloads from reusable central components. These are vendor design patterns, not comparative evidence for a universal central-to-local staffing ratio.
Choose a delivery arrangement for each workflow, then revisit it when support capability changes:
- Keep delivery central when the relevant technical skills or controls cannot yet be supplied locally. Retain a local business owner who can check the work and arrange its use.
- Share delivery when central specialists and departmental staff can work together, with each change and support duty assigned explicitly.
- Delegate delivery when the local team can maintain the implementation, monitor problems and respond within the shared boundaries. Confirm those duties with the receiving team before transfer.
Inspect the central queue before treating decentralization as the answer. Separate requests waiting for information, decisions waiting for authority, and accepted work waiting for people. Missing source records require a different response from an overloaded platform specialist. Repeated identical requests may justify a reusable service; a truly local exception may need closer collaboration.
Also examine the local burden. If Claire gains responsibility for checking every summary without time in the service schedule, the centre has transferred work without arranging capacity. Measure the whole task, including checking and rework, rather than counting deployments as proof of an effective operating model.
Before adding another workflow, complete the responsibility record for one current task and rehearse its support route. Use the unresolved gap to decide the next investment. That gives the centre and local owners a concrete agreement to improve.
Questions about central and local AI ownership
Must the central AI team build every workflow?
No. A central AI team can supply shared access, technical controls and support while capable departmental teams build within those boundaries. Keep delivery central where local teams lack the necessary skills or operating capacity. In either arrangement, assign a local business owner who can define acceptable work and arrange its use. Compare the delivery choices for the specific workflow before changing reporting lines.
What can a local workflow owner change without another approval?
A local AI workflow owner can change only what the organization has delegated within the approved task, data and service limits. For example, the appliance-service manager can adapt summary headings under the assumed agreement; adding customer data or automated sending needs a separate decision. Write down the allowed adjustments and escalation triggers in the responsibility record, then check that affected owners accept them.
Can a department own an AI workflow without technical staff?
Yes, a department can own the business task and its acceptance while a central team maintains the technical implementation. The department still needs time and expertise to check outputs, maintain source information and arrange a fallback. It should not inherit technical support duties it cannot perform. Test the failure and support route with both owners before treating the arrangement as operational.
How can you tell whether the central team is a bottleneck?
Inspect what accepted work is waiting, why it is waiting and who can release it. Distinguish insufficient specialist capacity from missing evidence or unclear authority. Also check whether the local team could carry the proposed delivery and maintenance duties. A growing queue warrants a decision about scope, support or delegation; it does not by itself prove that controls should be removed. Use the queue and readiness checks to choose a specific change.
