Should IT or the Business Own an AI Initiative?

Geoffrey Chen

After AI Enters the Workflow · Season Two: “From Personal Tool to Organisational Capability” · Article 2

An organisation wants AI to assist with customer correspondence. The business team states the requirement as “faster and more consistent replies”. IT selects a model, connects documents and customer records, and builds the interface. After deployment, business staff complain that suggestions do not reflect policy exceptions. Technical staff reply that the exceptions were never specified. Compliance discovers late that some letters involve statutory deadlines and sensitive personal information.

When the project fails, every department can identify something another department omitted. The business does not understand the model, IT does not own the service decision, and assurance arrived too late. Management asks: who should own the AI project?

If the only available answers are IT or the business, the organisation has framed the problem incorrectly. An AI use case is simultaneously a business decision, a technical system and a continuing chain of responsibility. It needs a business owner accountable for the outcome and named co-owners for technology, information, security, law and operation.

IT cannot decide the business purpose

Technical teams can judge whether an interface is reliable, permissions are minimal, logs are complete and rollback is possible. They cannot determine alone what counts as correct treatment of a customer letter.

If speed conflicts with accuracy, which prevails? What can be drafted automatically, and what requires an authorised judgement? One error may create awkward prose; another may cause a customer to miss an appeal deadline. These are questions of service purpose, legal obligation and risk tolerance.

When the business supplies only the objective “improve efficiency”, IT is forced to translate hidden values into system goals. An easily measured indicator—average handling time, for example—may displace the real purpose.

The business must therefore own the use case’s purpose, completion standard and consequences.

The business cannot own system risk by itself

Understanding the workflow does not equip business staff to assess model updates, access tokens, prompt injection, data retention, supply-chain dependencies and monitoring architecture.

A seemingly simple drafting tool may read customer records, retrieve policy, call an external model and write output into a formal case-management system. Calling it “assistance only” does not remove those technical facts.

Technology, security and data teams must own the components they can control: architecture, permissions, integration, asset inventories, updates, incident response and recovery. They must also have authority to block deployment that fails minimum conditions.

This is not a technical veto over business. It prevents a business decision from acquiring powers through infrastructure that its owner has not examined.

Why “shared responsibility” often becomes no responsibility

Many organisations respond with a cross-functional committee. A committee can gather perspectives but can also dilute obligation into attendance.

Genuine shared ownership does not mean that everyone’s name appears on a list. It means that every kind of decision has an answerable owner. Who approves the purpose? Who confirms the authoritative sources? Who accepts residual risk? Who authorises release? Who monitors failure? Who can suspend operation? Who explains and remedies harm?

The NIST AI RMF calls for roles and responsibilities in human–AI configurations and oversight to be defined and differentiated. It also states that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. NIST AI RMF Core

Australia’s Policy for the responsible use of AI in government, Version 2.0, requires covered agencies to designate accountable officials and establish use-case accountability, internal registers, training and impact assessment. It does not hand responsibility to an abstract “AI team”; governance is made specific to agencies, roles and uses. Digital Transformation Agency, “Policy for the responsible use of AI in government”

Four kinds of ownership are required

The first is outcome ownership. A business owner defines the problem, affected people, success criteria and unacceptable consequences, and decides whether the result may be adopted.

The second is system ownership. A technical owner maintains architecture, model access, permissions, versions, availability and recovery.

The third is information ownership. A data or knowledge owner confirms sources, quality, access scope, updating and retention.

The fourth is assurance ownership. Risk, legal, security or professional functions determine the independent checks required and can escalate to someone with authority to stop the project.

Different people may hold these roles, but they should be connected in one use-case record. Higher-risk systems may also require worker representatives, affected communities or independent experts to participate. Participation enriches the decision; it does not replace the institution’s final accountability.

The UK Government AI Playbook places goal definition, team design, procurement, lifecycle management, meaningful human control and assurance within one body of guidance. That structure also shows why AI cannot be a closed technical project. UK Government, “Artificial Intelligence Playbook”

The final owner needs actual control

Naming an accountable owner is necessary but insufficient. The owner must see evaluation results and incident trends, know when the supplier or model changes, possess resources to repair problems and have power to suspend the system.

If the owner can sign a release document but cannot restrict data, change metrics or stop the service, the responsibility is nominal. If IT can replace the model without notifying the business owner, business ownership is equally hollow.

ISO/IEC 42001 places leadership, planning, support, operation, performance evaluation and continual improvement inside an AI management system. It makes responsibility an organisational process, not a one-time project appointment. Standards Australia, “AS ISO/IEC 42001:2023”

Replace departmental competition with a decision-rights map

At the beginning of the project, list the material decisions and identify who proposes, advises, approves, executes and receives notice for each. The map should cover purpose, data, model and supplier, testing, release, material change, incident response and retirement.

The map must change when the use changes. An innovation team may own an experiment, but not a production customer service indefinitely. If drafting becomes automatic sending, the approval level and assurance requirements must be reconsidered.

Departments remain important, but they should not be the endpoint of responsibility. The true boundary of an AI use case is the chain from purpose to consequence.

The map also provides a test for escalation. A routine configuration change may remain with the system owner, while a change that expands the affected population, adds personal data or moves from drafting to automatic action returns to the outcome and assurance owners. Without this rule, teams can transform the risk profile through a sequence of apparently minor technical releases. Ownership must attach not only to the initial project, but also to decisions that change what the system is allowed to become.

Ownership must also survive organisational change. When a pilot lead moves, a supplier changes or a funding period ends, the use case cannot become an unclaimed legacy process. A registry should preserve the business owner, technical owner, risk-accepting authority, review date and stopping conditions, with role changes triggering renewed confirmation. That continuity prevents “shared responsibility” from becoming a situation in which every party owns only the familiar part and nobody owns the outcome when failure crosses boundaries.

Conclusion: the business owns purpose, IT owns the system, and the institution owns the consequences

An AI initiative should not simply “belong to IT”, because a technology function cannot independently decide service purposes and acceptable consequences. It should not simply “belong to the business”, because models, data, integration and security require professional control.

A more accurate arrangement is:

A business owner holds final ownership of the use-case outcome; technical, information and assurance owners hold their respective controls; and institutional leadership is accountable for the completeness of that arrangement.

When something goes wrong, the organisation should not search for whoever “touched the AI”. It should follow predefined decision rights to the owners of purpose, system, information, adoption and remedy. That is what turns cross-functional discussion into cross-functional operation.

Primary sources and further reading

Continue reading: Explore the After AI Enters the Workflow series.

Discover more from Geoffrey Chen

Subscribe to get the latest posts sent to your email.