The AI Operating Model Is Not an AI Department

Creating an AI function is an understandable response to a difficult management problem. Expertise is scarce, technology choices are consequential, and separate experiments can leave an organization with incompatible systems and inconsistent controls. A center of excellence, a Chief AI Officer, or a dedicated transformation team gives that problem a visible home.

The difficulty begins when a home for specialist capability becomes a substitute for deciding how the rest of the organization must operate. An AI team can develop a solution. It cannot, merely by existing, settle which business priorities deserve investment, change responsibilities across departments, or ensure that managers use the resulting capability effectively. Those decisions require authority elsewhere in the organization.

Our earlier Perspectives examined the workflow as the unit of transformation, the organizational implications of changing work, and the growing importance of judgment and accountability. The question now is how to distribute responsibility for making those changes happen.

Normatic's position is that AI transformation is an operating-model question. A specialist department can be an important part of the answer. Its effectiveness depends on the responsibilities, resources, and authority assigned to the functions around it.

The organization chart leaves the hardest decisions open

An organization chart shows reporting relationships. An operating model explains how an organization selects work, commits resources, makes decisions, delivers outcomes, and sustains performance. It connects accountability and authority with funding, capabilities, architecture, governance, and management routines.

Two organizations can therefore have identical AI reporting structures and operate very differently. In one, business leaders sponsor workflows, commit people to redesign them, and remain accountable for results. The central team supplies engineering and common services. In another, business units submit requests to an AI team and wait for it to deliver benefits. The chart may look the same; the distribution of responsibility does not.

The distinction matters particularly when work crosses departmental boundaries. Existing budgets and performance measures may reward each function for optimizing its own activity. An AI initiative can expose a conflict among those measures without giving anyone authority to resolve it. Naming an AI owner leaves that conflict intact unless the role has a mandate to bring the relevant decisions together.

The OECD's 2025 work on AI in government offers a useful parallel. Its framework treats governance, data, infrastructure, skills, investment, procurement, and partnerships as interdependent enablers. Although the institutional context is public administration, the breadth of the framework illustrates why establishing a specialist team addresses only part of the organizational problem. Governing with Artificial Intelligence

Business outcomes and technical services need distinct owners

Consider an illustrative order-fulfillment workflow. AI might help interpret an order, identify missing information, assess availability, and propose a delivery commitment. The business result depends on sales, inventory, operations, and customer service. Faster interpretation has limited value if nobody can resolve a disagreement about what the company should promise.

A process owner needs responsibility for the overall result and a mandate to coordinate those functions. That includes defining success, agreeing changes to the workflow, determining where human judgment is required, accepting the solution, and reviewing performance after deployment. Where existing authority is insufficient, an executive sponsor must resolve the gap. Accountability without a route to influence the work is an assignment in name only.

Technical ownership is equally concrete. A service owner must be responsible for the deployed system's reliability, monitoring, support, and controlled changes. Product leadership translates business priorities into a development backlog; domain experts establish what acceptable performance means; engineering and data teams make the solution work within the enterprise environment. These responsibilities may sit in different teams, but their boundaries must be explicit.

The distinction also improves diagnosis. If a reliable system produces recommendations that managers cannot act on, the problem may lie in authority or workflow design. If an agreed workflow repeatedly fails because an integration is unstable, technical ownership must address it. A single label such as “AI owner” conceals these different obligations.

Shared work therefore needs differentiated accountability. Business ownership does not excuse engineering failures, and engineering ownership does not transfer responsibility for business decisions to the technical team.

Centralize capabilities selectively

The choice between centralization and distribution is more useful when applied to particular capabilities than to AI as a whole.

Shared infrastructure, security requirements, enterprise vendor management, evaluation methods, and scarce engineering expertise may benefit from central provision. Business priorities, domain judgment, workflow acceptance, and adoption usually require close involvement from the functions doing the work. Neither allocation is automatic. A specialist business may need dedicated engineering, while a common process used across divisions may warrant enterprise ownership.

JPMorganChase describes its data and AI organization as combining centralized platforms with federated teams embedded in businesses. That is a concrete example of the two arrangements coexisting. It is the company's description of its organization, not comparative evidence that federation produces better results in every setting. Data & AI at JPMorganChase

The management challenge is the relationship between shared capability and local demand. A common platform needs an accountable owner, a funded roadmap, and a way for its users to influence priorities. Otherwise, the central function can become a queue that business teams work around. Local teams, in turn, need obligations to meet enterprise requirements and contribute improvements that others can reuse. Autonomy cannot mean that every team independently recreates identity controls, monitoring, or vendor arrangements.

Architecture should make those obligations usable. Approved components and clear interfaces can let teams experiment within established boundaries. Exceptions still need a timely decision route: a common platform that cannot support a legitimate requirement should trigger a design decision, rather than an indefinite wait or an unrecorded workaround.

A strongly centralized model may suit scarce capability and tightly coupled operations. A federated model can combine enterprise services with business ownership, but requires sustained coordination. Greater distribution can suit relatively independent businesses with capable teams, while increasing the burden of managing duplication and consistency. These are contingent choices, not mandatory stages of maturity. Organizations may centralize one capability while distributing another, and revisit both as needs change.

Decision rights must identify the decision being made

“AI approval” is too broad to allocate meaningful authority. Selecting an initiative, approving a model, granting access to data, authorizing an automated action, and accepting a system for operational use are different decisions.

An approved model does not carry blanket permission to use every dataset or execute every transaction. Likewise, a business sponsor's enthusiasm for a use case cannot substitute for authorization from the people responsible for data access, security, or operational controls. Those responsibilities need to meet during design, when changing the proposed workflow is still practical.

The operating model must specify the boundary of each authority. Enterprise technology leaders may define the acceptable platform environment; product teams may select among approved options based on evaluated task performance. Data owners govern permitted use. Process owners define the business actions the system may take, subject to applicable controls. Release decisions bring technical readiness, business acceptance, and required risk review together.

This allocation should make routine decisions easier. Teams need room to act within agreed limits, with escalation reserved for decisions that exceed them. Exceptions require a named decision-maker, recorded conditions, and a point for reconsideration. A committee is useful where competing responsibilities need resolution; it becomes a bottleneck when every ordinary choice waits for its meeting.

Authority also continues after release. Someone must be able to suspend an unsafe action, authorize recovery, or require reevaluation after a material change. Human judgment remains essential here: people need the information, competence, and authority to intervene. A nominal reviewer without time or access to relevant evidence does not provide meaningful oversight.

Funding makes the operating model real

Responsibilities become credible when budgets support them. Asking a business unit to own adoption while funding only technical development creates a predictable gap between the delivery plan and what managers can actually change.

Central funding can support exploration and capabilities whose benefits extend across business units. It can also weaken demand discipline if sponsors obtain experiments without committing people, operating resources, or responsibility for results. The relevant test is whether an experiment has a plausible business owner and a route to a further investment decision, not whether every early idea can promise a return.

Local funding brings the investment decision closer to the expected benefit. But a unit paying the entire cost of a reusable capability has little incentive to accommodate other users, and may choose a narrow solution that is cheaper for itself. Other units may wait for someone else to make the first investment. Both responses can be rational locally and costly collectively.

Joint funding can address that mismatch when the contributions are explicit. Enterprise investment might cover a shared foundation, while participating businesses fund their workflow changes, integration, and adoption. It can fail when each participant assumes another will pay for maintenance or resolve a disputed priority. The owner of the common capability needs authority over its roadmap as well as a mechanism for reconciling users' demands.

Funding decisions should therefore include continuing operation, evaluation, support, and improvement. Performance reviews need to connect expenditure to observed outcomes and inform whether to expand, revise, or retire a solution. Counting delivered pilots or platform users alone cannot answer those investment questions.

Governance and adoption continue through operational use

Governance becomes part of the operating model when it changes how work is designed and run. A policy statement and a final approval gate are insufficient if delivery teams have no access to the expertise needed to interpret requirements earlier.

Microsoft's 2026 Responsible AI Transparency Report describes a standard that separates developer and deployer responsibilities, tailors requirements across models, platform services, and applications, and includes monitoring and corrective action after deployment. This is a self-reported governance approach, not proof of a universally superior structure. It provides a useful example of assigning responsibilities across the lifecycle rather than treating approval as the end of governance. Responsible AI Transparency Report 2026

For an enterprise adopting AI, that distinction is practical. A vendor can document its product and maintain its service. The adopting organization still has to determine appropriate use, manage permissions, redesign the surrounding work, and respond when actual performance differs from expectations. Outsourcing a technical component does not remove those responsibilities.

Adoption follows the same logic. A central team can provide training and support, but business managers determine how jobs, responsibilities, and performance expectations change. If a new system reduces one activity, managers must decide what happens to the released capacity. If it introduces exception handling, they must ensure that people can perform it. Those decisions belong in the transformation mandate from the beginning.

Management routines keep these responsibilities connected. Portfolio reviews resolve investment and dependency conflicts. Delivery reviews bring business acceptance and technical evidence together. Operational reviews examine results, incidents, and changing conditions. Each needs a clear purpose and decision authority; adding meetings without those features merely creates another coordination burden.

The Chief AI Officer should establish the operating model

A Chief AI Officer can be valuable where enterprise direction is fragmented, significant trade-offs lack an owner, or a sustained transformation agenda requires dedicated leadership. The role can coordinate priorities, develop common capability, and make unresolved organizational decisions visible to the executive team.

Its remit matters more than its title. Responsibility for an enterprise portfolio needs corresponding authority over resources, standards, or escalation. A role charged with transformation but limited to advising business units may be unable to resolve the very conflicts it was created to address.

The opposite problem arises when the appointment permits other executives to withdraw. A Chief AI Officer cannot permanently substitute for business leaders' responsibility for outcomes, technology leaders' responsibility for dependable systems, or operating managers' responsibility for how work is performed. Establishing the connections among those obligations is central to the role.

Not every organization needs a new executive position. Existing leadership may have the capacity and mandate to perform that work. A temporary or fractional transformation office can also help establish direction and coordinate delivery while internal capability develops. In Normatic's Fractional AI Transformation Office model, client leaders retain business authority and approvals, while the office takes responsibility for its agreed transformation and delivery scope. The arrangement must strengthen the client's ability to make and sustain decisions.

Success does not necessarily mean that the central function disappears. Shared platforms, specialist expertise, and enterprise governance may remain valuable permanent capabilities. What should change is the assumption that responsibility for AI can be delegated wholesale to that function.

Executive leadership's task is to establish an organization in which business ownership, technical capability, decision authority, and investment reinforce one another. The test is whether those arrangements can carry an important workflow from an agreed purpose into dependable use, and continue to improve it when conditions change. Creating an AI department may help. Deciding how the organization will operate is the work that makes it effective.

Sources

• OECD, Governing with Artificial Intelligence: Enablers, guardrails and engagement (2025). Public-sector framework informing the discussion of interdependent organizational capabilities; not a comparison of corporate operating models.
• JPMorganChase, Data & AI career opportunities. Primary organizational description of centralized platforms and federated business teams; accessed September 2026.
• Microsoft, Responsible AI Transparency Report 2026. Primary account of developer and deployer responsibilities and governance through operational use.

The allocation of ownership, authority, and funding argued for in this Perspective is Normatic's interpretation. The order-fulfillment example is illustrative and does not represent a client engagement.