An AI transformation office can solve a coordination problem. It can also become the place where the organisation sends decisions that business leaders have not resolved.
The difference is visible in the mandate. A useful office has authority to address named barriers, delivery responsibilities that connect to operating outcomes and a plan for transferring its work. An office asked to “drive AI across the enterprise” has a slogan where those decisions should be.
I would not reject a central team on principle. Shared platforms, evaluation, supplier management and scarce expertise may justify one. I would ask what needs temporary concentration, what belongs permanently in a shared service and what the business must eventually operate itself.
Begin with the coordination failure
Before approving a new structure, describe the problem it will solve. Several business units may need access to the same controlled documents. Evaluation expertise may be scarce. Supplier commitments may conflict. A process may cross functions whose leaders cannot agree on the changed decision rights.
Those are different problems. A platform team can address common access and reliability. A portfolio forum can resolve competing investments. A delivery team can redesign a process with its owner. Giving one office responsibility for all of them without distinguishing the authority required is an invitation to confusion.
Consider a hypothetical manufacturer whose plants want document assistants. Each plant has a different library, access arrangement and terminology. A central team could establish approved retrieval infrastructure and evaluation practices. It could help the plants prepare their content and test important exceptions. The plant leaders would still own whether the service helps the work and whether their teams are ready to use it.
This is a coordination task worth concentrating. The same structure would add little in a company that already has the common services, expertise and decision process in place.
Write decision rights before the organisation chart
The mandate should explain which decisions the office can make and which it coordinates. Can it prioritise common platform work? Commit an approved budget? Select suppliers within agreed terms? Require a representative evaluation before a delivery proceeds? Those rights need to be explicit and proportionate to the responsibility.
Business leaders retain responsibility for the operating outcomes assigned to them. Technology and service owners remain accountable for the systems they run. Risk, security, data and domain specialists need defined authority over the requirements within their remit. The office should bring these decisions together, rather than claim that its existence replaces them.
Disagreements will occur. A delivery team may want a larger scope than the evaluation supports. A business unit may resist a common service because its local requirements differ. Name an escalation route that can resolve the trade-off, record the reason and identify who accepts the remaining exposure.
A faster route through this process can be designed and approved. It might use pre-agreed patterns, standard evaluation requirements and a delegated budget. That is different from bypassing governance. The advantage should come from preparing decisions well and removing unnecessary handoffs, while preserving the controls that the deployment requires.
Separate delivery from the services it depends on
Some responsibilities are temporary. A team can help a business unit change a workflow, establish the evaluation and train its operators. Other responsibilities persist for as long as the service runs: access administration, incident response, supplier management, model updates and periodic review.
If both are placed inside the transformation office, distinguish them in the budget and operating plan. Otherwise, closing the office may remove the support that made the deployed system workable. Keeping it indefinitely may conceal that the receiving organisation never became ready.
A sensible transfer might move process ownership to the business, service operation to an established technology function and evaluation support to a shared capability. The exact destination follows the existing organisation and the work. There is no universal rule that every capability must be decentralised or that every unit needs its own AI team.
The central team can also remain as a permanent service if its continuing value is clear. Its mandate should then describe that service and its customers. Calling it a transformation office forever makes it harder to see the actual responsibility being funded.
Readiness is the condition for transfer
Put a review date on the mandate, with expected outcomes and the evidence required. Do not impose a day on which the office must dissolve regardless of the business's ability to operate what it receives.
Readiness includes a receiving owner, a funded support model, authorised access and people who can recognise and manage failures. The evaluation method should be usable by the receiving team. The fallback should work in the conditions where it may be needed. Benefits should have an owner and a credible plan for realisation.
Test that readiness through actual operation. Ask the receiving team to handle an exception, diagnose an incorrect output and follow the incident procedure. A handover presentation and a signed document are weaker evidence than a team demonstrating that it can run the service without informal rescue from the original developers.
Transfer can be staged. One workflow may be ready while another still depends on central expertise. Narrow the office's remaining mandate to the unresolved responsibilities. If the same barrier repeatedly prevents transfer, address it directly: capability, budget, ownership or a service design that is too difficult to operate.
Judge the office by what the organisation can now do
Counts of workshops, trained employees and prototypes describe activity. They can help manage delivery, but they do not establish that an operating capability has improved.
Use measures linked to the mandate. For a shared access service, track whether intended users can reliably retrieve authorised material and whether integration effort has fallen. For a changed process, measure the relevant outcome alongside error, review and adoption costs. For a coordination mandate, examine whether consequential decisions reach a resolution with the right evidence.
This also prevents the office from claiming every improvement made by the business as its own. Contributions can be shared. Finance and process owners should agree how the benefit will be measured and avoid counting the same released capacity in several programmes.
The NIST AI Risk Management Framework offers a voluntary, lifecycle-oriented structure for governing and evaluating AI risks. It supports attention to responsibilities and operating context; it does not prescribe a transformation-office design or a deadline for closing one.
The appointment decision
Before creating the office, ask for a mandate that names the barriers, decisions, budget, delivery partners and receiving owners. Ask which services will continue after transfer and who will pay for them. Establish a review where leaders can continue, narrow, redesign or end the mandate on the evidence.
That makes the structure accountable without treating closure as a performance stunt. A successful office may become smaller, transfer most of its work or become a clearly defined permanent capability. What matters is whether the business can sustain the improvement it was created to help deliver.
The executive AI mandate checklist can structure this discussion. Use it to resolve authority and ownership before the new team inherits an impossible promise.
Use the transformation-office mandate worksheet to prepare the decision rights and transfer review.