The AI platform is available. Access has been arranged. An introductory session has taken place. The business team still does not know whether it should change the way it handles customer requests.
Who owns the next step?
Enterprise AI adoption needs a named owner for the change in the work, supported by technical, people and specialist responsibilities that are equally clear. Assigning the entire challenge to IT or HR leaves decisions with people who may not control the process, resources or outcome.
That is a proposed operating approach, not a universally proven organisation chart. Titles and structures vary. The practical test is whether each important decision has someone with the authority, knowledge and support to make it.
Ownership begins with decisions, not a department label
“IT owns AI” can mean that IT provides a platform, approves access or maintains a service. It does not necessarily mean that IT can change a sales process, allocate customer-service staff or decide how managers should support new working practices.
“HR owns adoption” can mean that HR coordinates communication, learning or workforce considerations. It does not necessarily give HR authority to redesign a business team's daily work.
“Business leaders own it” is incomplete too, if those leaders cannot obtain technical support or understand the conditions attached to a proposed use.
Start by naming the decisions. Which business problem deserves attention? What change is proposed? Who can commit time to it? What must be demonstrated before normal use begins? Who will keep the arrangement workable afterwards?
The answer may involve several functions, but responsibility for a particular decision should remain findable.
What official guidance supports
The NIST AI Risk Management Framework Playbook calls for clear risk-related roles, responsibilities and lines of communication. It also places responsibility for AI risk decisions with executive leadership. This is voluntary risk-management guidance, not a legal determination that one job title must own adoption. NIST's current pages note that the framework is being revised and the Playbook will follow.
Australia's National AI Centre foundations guidance recommends an overall senior governance owner alongside a specific accountable person for each system. Its implementation guidance also addresses authority, competencies, staffing and resources. These are practical recommendations, rather than a comparative study proving one enterprise structure superior.
The useful distinction is between organisational oversight and the responsibility for a particular use. A committee considering the portfolio does not automatically provide day-to-day ownership for every process affected.
The approach below applies that distinction to an original fictional rollout. It does not assign legal liability or replace the specialist assessment appropriate to a real deployment.
Follow a rollout from “available” to “usable”
Imagine a customer-service team considering AI assistance for complaint triage. The proposed tool suggests a category and an initial priority. A trained employee would still assess the case and choose the appropriate response.
The technology team can demonstrate that the application is accessible and works under the agreed test conditions. Yet operational questions remain.
What makes a complaint urgent? Which information must the employee examine before accepting a suggestion? What happens when the category is uncertain? Does the proposed process leave enough time for the required review?
A useful demonstration cannot settle those questions without the people who understand and run the service.
This fictional example is not a reported customer case or a claim that an AI triage product meets these requirements. Its purpose is to show where operating decisions sit.
The business owner defines the service change
For this use, the customer-service leader is a plausible operating owner because they can change the process and are responsible for the service it delivers.
Their first task is to explain the problem. Perhaps complaints arrive with inconsistent initial categories. Perhaps urgent cases wait because important information is hard to identify. These are different needs and may require different interventions.
The owner should also define an acceptable outcome and the proposed scope. That includes identifying where the existing method remains preferable and what evidence would justify changing it.
This is ownership of the business proposal, not permission to bypass technical or specialist requirements. A person accountable for an outcome still needs to work within the organisation's decision-making arrangements.
IT makes the supported service concrete
Technical colleagues need a sufficiently clear use to assess and support.
For the fictional triage process, their contribution could concern the approved environment, access, integration, availability, support and the handling of changes. They can explain what the available system can reliably provide and which assumptions need investigation.
They should not be expected to infer the meaning of an urgent complaint from a broad request to “improve triage.” Equally, the business owner should not announce a rollout while leaving IT to discover how it must be supported.
An explicit service arrangement connects the two. Who reports an operational problem? Who investigates a technical fault? How will relevant changes reach the people using the process?
Those questions continue after launch. Technical availability is an ongoing contribution to adoption, not a box checked once.
HR and L&D connect the change with people's work
HR and learning colleagues can help examine role expectations, communication, learning opportunities and the experience of the transition. Their contribution becomes more useful when it addresses a specific task.
For the customer-service team, employees may need practice comparing a suggested priority with the information in a complaint, recognising uncertainty and explaining an escalation. Managers may need to learn how to coach that judgment.
A general introduction to AI may be useful preparation. It does not establish that staff can perform this particular work.
Time matters too. If the service owner expects employees to practise, who adjusts their workload? If managers need to observe and support initial use, who makes that feasible?
HR and L&D can help design the support. Operational leaders must make the necessary room for it. Neither function can solve the problem alone.
Make three handoffs explicit
A rollout often crosses boundaries between teams. Before each handoff, ask what is actually being transferred.
From proposal to preparation: The business owner provides a defined use, intended outcome and relevant operational context. Technical and specialist colleagues identify conditions that must be examined. Learning colleagues identify what people need to understand and practise.
From preparation to ordinary use: The group reviews the evidence against agreed requirements. Someone with the appropriate authority decides whether the process can begin within a specified scope. Unfinished work needs an owner rather than a vague promise to resolve it later.
From initial use to ongoing operation: Support, monitoring, employee feedback and process improvement become part of normal responsibilities. The original project team's availability should not be assumed indefinitely.
These are proposed handoff questions, not a standard certification procedure. In a complex organisation, several approvals may be necessary. In a smaller firm, one person may perform multiple roles.
The important point is to avoid treating “the tool is ready” as shorthand for every other part of readiness.
Give disagreement a route to a decision
Suppose the customer-service owner wants to start next week. IT identifies an unresolved support dependency. Employees say the proposed review step is difficult within current workloads. L&D needs more realistic cases before it can prepare useful practice.
A meeting can surface the disagreement. It does not resolve it merely because all functions attended.
The executive sponsor needs to know what choice is being requested: narrow the scope, provide additional resources, change the timetable or gather missing evidence. Some requirements may need specialist resolution rather than a simple management trade-off.
Record the decision and its implications. If the launch is delayed, what needs to become true before reconsideration? If the scope is narrowed, how will affected teams know? If extra support is committed, who supplies it?
A cross-functional group is useful when it connects expertise with decisions. It becomes less useful when it circulates the same unresolved question among functions that lack authority to answer it.
Keep an operating owner after the announcement
A launch does not finish adoption.
In the fictional triage team, staff might find that certain complaints are repeatedly assigned an unsuitable initial category. The issue could involve the tool, the information supplied, the category definitions or the way employees interpret the recommendation.
The operating owner needs a route for investigating that experience with the relevant colleagues. Not every problem is a technical fault. Not every problem is a training gap.
A change in the underlying service can also matter. If the company changes how complaints are handled, the assisted process may need review. Someone should be responsible for noticing that connection.
Ownership therefore needs continuity and succession. If the operating owner changes roles, who receives the responsibility, the reasoning behind earlier decisions and the unresolved issues?
A project can have a well-attended launch and still leave these questions unanswered.
Avoid solving the problem by adding a title
A chief AI officer, central programme office or shared centre of expertise may help coordinate enterprise priorities and support. The appropriate structure depends on the organisation.
The title alone does not establish who owns the complaint-triage process, who can change workload expectations or who supports the application. Those decisions still need to be assigned.
Central arrangements can provide reusable expertise and common requirements. Local operating owners can connect a use with its actual context. The boundary between them should be explicit enough to resolve disagreements.
For a small business, a complicated committee structure may add little. An owner-manager may need a clear working arrangement with an external technical provider and appropriate specialist support. Combining roles does not remove the need to understand their different responsibilities.
No single model in this article should be treated as the answer for every sector, scale or risk profile.
Build capability in the people who own the decisions
An accountable person needs more than a name on a document.
They should understand the proposed use well enough to ask meaningful questions, recognise the limits of the available evidence and know when another specialist is needed. They also need access to relevant people and information.
For a business owner, that may mean learning how to examine a process and judge whether the proposed change serves its purpose. For a technical owner, it may mean learning more about the operational conditions. For managers, it may mean supporting employees who raise uncertainty rather than interpreting every question as resistance.
The human learning advantage matters across these roles. Adoption is partly the organisation learning how to work differently, not simply employees learning how to operate a tool.
That learning should produce clearer decisions and better-supported work. Counting introductory sessions cannot establish that it has happened.
Use an executive event to expose missing authority
A useful leadership exercise is to give IT, HR and business leaders the same fictional rollout and ask them to describe the next decision.
Who believes the process is ready? What evidence are they using? Which part do they expect another function to handle? Who can authorise the resources still missing?
The discussion can reveal an unclear handoff before a real deployment encounters it. It is a proposed activity, not a proven intervention.
A keynote can frame the issue; a facilitated working session can help people apply it. Our guide to designing a corporate AI learning summit explains how to connect that shared perspective with practical follow-through.
The organisation remains responsible for its operating decisions. An external speaker cannot supply internal authority that has not been assigned.
The ownership question that matters
Sources were checked on 28 October 2026. This article uses selected official guidance and an original fictional scenario. It does not establish a universal reporting structure, allocate legal fault or claim that the proposed approach guarantees successful adoption.
IT, HR and business leaders all have important contributions. The useful question is what each can actually decide and deliver.
Before the next rollout, ask: Who owns the change in the work—and do they have the authority, expertise and resources to carry it through?
Bring that question to your next leadership event. Explore Learning Coach's international keynotes and request a tailored proposal.
References
NIST. AI Risk Management Framework Playbook: Govern. Roles, communication and executive responsibility; voluntary guidance, accessed 28 October 2026. Framework revision underway.
Australian National AI Centre. Guidance for AI adoption: foundations. Accountability recommendations for early and lower-risk use.
Australian National AI Centre. Guidance for AI adoption: implementation guidance. Section 1, including authority, competencies and resources; accessed 28 October 2026.
