A controller's team builds a month-end-close automation because the IT queue is four months out. Six months later, nobody can say who supports it, what data it consumes, or how it posts a journal entry. Elsewhere, an AI request waits while the process it was meant to change moves on.
Companies keep trying to settle issues like these by asking who owns the technology. That is the wrong question. A technology-enabled workflow has several owners: the person accountable for the outcome, the people who know the process, the platform team and the control functions that live with the risk. Putting all those responsibilities in one organization creates either a bottleneck or uncontrolled technology.
Centralize what you can't duplicate safely or economically. Keep workflow design, priorities and adoption with the functions that operate the process. Delivery should follow the work.
Why the old split is breaking down
The old model had a clean boundary. IT bought and ran the systems; the business wrote requirements and used them. That still works for many enterprise platforms. It doesn't fit work that spans process knowledge, data, engineering and control, such as analytics, automation, low-code, data products and AI embedded in a workflow.
The shift is accelerating. AI is moving inside business processes and can take action. Data is reused across operations, analytics and AI. Low-code and SaaS are expanding outside of IT, while cloud and AI are making spending more variable. The old requester-provider boundary is becoming less useful.
IT still must own what needs to be common and controlled: identity, security, integration, cloud and data platforms, approved model access, engineering standards and visibility into production. Business functions must own process definitions, priorities, adoption and whether the change produces value. Federation without those shared controls is just shadow IT at scale.
How the work gets done
Separate accountabilities rather than drawing a circle around "AI" or "data" and assigning it all to one group. The business owns the outcome and workflow. Technology owns the shared platforms, engineering foundations and enterprise controls. Delivery can occur in three places depending on the work.
Common architecture, security, privacy, data, vendor-risk and production standards apply across all three. They define the conditions under which work can proceed and reach production.
The enterprise group that sets platforms and patterns should enable other paths, not build every dashboard, assistant, automation and data product. Traditional service management still fits infrastructure, workplace technology, the service desk and mature enterprise applications. Standing cross-functional teams are warranted only where sustained demand and ongoing ownership justify them.
One intake, more than one path
Create one place to see the work and multiple places to perform it. Intake should be a shared record and routing point, not another approval queue. Lower-risk work can remain self-service. Sustained domain solutions can go to a domain team. Shared platforms belong with enterprise technology. Higher-assurance review applies on any path when risk warrants it.
A personal productivity automation and an agent that can execute a transaction should not follow the same process. Reviews should scale with scope, autonomy, data sensitivity, external impact and potential financial or customer harm. Decision rights should also be explicit: outcome, process, data, platform, engineering, risk, support, cost and value, so "who owns this?" has an answer beyond the org chart.
Do not start with the org chart
This is a more practical change than declaring the company product-led or moving AI wholesale into IT or the business. Start by testing four management mechanisms against a few live requests:
- Write down enterprise and domain decision rights for outcomes, workflows, data, platforms, engineering, risk, support and value.
- Open one intake with multiple paths: self-service, domain teams, or enterprise technology, with higher-assurance review when risk warrants it.
- Tier the review. A dashboard, an automation and an agent that can transfer money are not the same control case.
- Name the life cycle, support and value owners before production and show technology consumption against the business capability using it.
Once those mechanics work, change reporting lines only where demand and results justify a standing team. The goal is not to move technology from IT to the business. The goal is to place each accountability where it can be exercised well while keeping common foundations common.
