Who Should Make a Company’s AI Decisions? The CAIO’s Role and Authority

TL;DR: A CAIO is a senior role that steers a company’s AI strategy, investment, and use. AI expertise alone is not enough: the person needs to understand the business, operations, and how departments affect one another. The role should help decide what is worth investing in, what needs to change, and where decision rights sit. It can face resistance both when it declines an AI request and when it proposes a process change. Its authority, executive backing, and relationships with business units therefore need to be designed together. Not every company needs a separate CAIO position.

Imagine a company where customer returns sit unresolved for days. Management wants an AI system that reads requests and recommends a decision. The first demonstration is persuasive: it summarises the customer’s message, finds the order, and says whether the return should be accepted.

But two customer-service representatives reviewing the same request reach different conclusions. One is using outdated return terms. Certain exceptions can be approved only by the sales manager. Even after a product reaches the warehouse, the request remains open because the record is updated late.

What should the executive responsible for this hypothetical AI project do? They could look for a better model. First, though, they need to understand why returns are waiting. If reading a message takes a few minutes but managerial approval takes two days, a faster summary does not remove the delay.

I find it more useful to discuss the CAIO role through decisions like these.

In my article on the differences between a CIO, CTO, and IT Director, I argued that responsibilities and decision rights matter more than job titles. In the discussion under my LinkedIn post, Matias Baglieri extended the discussion to AI: a model may work, yet people may not trust its output. Data definitions, model risk, and decision rights should also be on a CAIO’s agenda.

I agreed. I would add that the CAIO also needs to be able to say, “We do not need AI here.” Even where AI is useful, the expected benefit may not materialise unless the process changes alongside it.

Where the CAIO’s work begins

CAIO is short for Chief Artificial Intelligence Officer. Here, I use it to mean a senior role that guides a company’s AI strategy, investments, and use. Its remit can vary by organisation. One company may create a standalone position; another may combine it with data, technology, or transformation responsibilities.

For example, Mastercard’s management structure lists Greg Ulrich as Chief AI and Data Officer. The company’s description brings together the use of AI and data in the business, internal and external applications, and governance of those areas. It is one example of how responsibilities can be combined, not evidence that the same structure would work better in another company.

I would hold this role accountable for deciding where AI is worth using in the business. That means its work cannot begin by turning a list of use cases into projects. It needs to understand what the company is trying to improve and what is preventing that improvement.

The CAIO needs to understand AI, but also the company. They should be able to see how a promise sales makes to a customer is fulfilled in operations, why finance requires a particular control, and how a change in responsibilities affects HR. They do not need to be the expert in every department. They do need to see when making one team’s work easier shifts a burden onto another.

In the returns example, the immediate target might be faster handling of customer messages. If the intended outcome is that customers receive the right answer sooner, the whole flow between reading the message and issuing the refund needs attention. Finance, warehousing, and customer service are part of that decision.

AI may help here. It could classify free-form messages, retrieve relevant documents, or prepare a summary for review. The business still has to determine the rule for accepting a return under particular conditions. A model’s ability to produce an answer does not entitle it to set that rule.

A CAIO needs a clear "yes" as well as a credible "no"

The CAIO should not be cast as the executive who blocks every project. The role becomes useful when a rejected idea is followed by a workable direction for the company.

If return conditions are clear, data is orderly, and decisions rest on a few fixed rules, improving the existing software may be enough. If requests are genuinely difficult to interpret, an AI-supported first review may be worth testing. If exceptions and approval rights are unclear, the managers responsible for them need to take part in resolving that ambiguity.

Waiting until everything is fixed before trying AI is not always the answer either. While a company standardises its return conditions, it could test a summarisation tool on a limited group of requests. The scope is defined, the decision given to the customer does not change, and the team reviews the results. Process improvement and technical learning can proceed together.

If the CAIO’s mandate from management is simply to increase AI use, advocating for a simpler solution becomes harder. The company needs to make clear that a good result achieved without AI also counts as success.

When can an employee rely on an AI recommendation?

The trust issue Matias raised cannot be resolved by explaining how advanced a model is. A returns representative needs to know under which conditions they can use a recommendation.

Is the system reading the current return terms? Can it show that a document is missing? What should an employee do when the recommendation is wrong? Who receives an appealed decision? Without clear answers, caution about the output is reasonable.

Both accepting every recommendation and trusting none of them can cause problems. The aim should be to establish which tasks employees can rely on the model to perform, and within what limits.

The CAIO should assess whether the model produces sufficiently reliable results for that task. Producing an incorrect summary and rejecting a customer’s valid claim have different consequences. The same model may be helpful for the first task and fail to provide the reliability required for the second. The employee who checks it also needs enough time, information, and authority to challenge a decision.

This responsibility goes beyond generative AI. Demand forecasting, risk scoring, and recommendation systems can also rest on faulty data, unsuitable conditions of use, or inappropriate limits on the decisions they can make. Defining the CAIO merely as the person who manages the company’s chat tools leaves those applications outside the role.

Results cannot be expected without authority

Asking an executive to manage AI risk starts with allowing them to see the relevant systems and influence the decisions around them. Business units may buy tools, share data, and connect them to customer-facing work without one another’s knowledge. In that situation, the responsibility of a central executive may exist only on paper.

In its announcement of a 2026 technology-leader study conducted with Oxford Economics, IBM says that about two-thirds of participating CIOs and CTOs report being held accountable for AI systems they do not fully control. The research covers 2,000 senior technology decision-makers across 33 geographies. The study is based on participants’ own reports and comes from a provider that sells AI products and consulting services. It does not establish how common this problem is among companies in Turkey or show that appointing a CAIO would solve it.

In the returns example, the business unit sets the return conditions. The CAIO, technical team, and risk owners clarify the boundaries within which an AI recommendation can be used. It should also be clear from the start who decides to expand the trial and who can stop the system when it fails.

Those powers need a place in the job description. The company should state which decisions the CAIO can make directly and which must go to the CEO or the relevant committee. If no one is designated to resolve a disagreement with a business unit, the criteria the CAIO establishes may remain suggestions.

Making the CAIO approve every low-risk use case would create another queue. Teams can be given defined boundaries within which they make their own decisions. The CAIO’s time can then go to shared problems and decisions with serious consequences rather than approving every small use.

What do the CIO, CTO, and business units continue to own?

Appointing a CAIO does not remove other executives’ responsibilities. The CIO remains responsible for enterprise systems, information, and transformation priorities. When AI is part of a product, the CTO leads its technical direction and manages engineering capacity. IT may own access, integration, and day-to-day operations. If there is a data leader, definitions and quality of records need to be addressed with them.

Those boundaries depend on the company’s existing structure. A CAIO who sets common criteria for AI use does not need every software team to report to them. Those teams do, however, need the time and resources to apply the criteria. An executive excluded from budget decisions has limited power to set priorities.

The customer-service manager still owns the returns process. They remain accountable for the promise made to the customer, how employees work, and the process outcome. They cannot hand off that responsibility by saying, “It is an AI project now; the CAIO can deal with it.”

Security, legal, and risk assessments should not be reduced to the CAIO’s personal sign-off either. If the person tasked with expanding AI use is the only one deciding whether their project is acceptable, dissent has less force. The company also needs a way to resolve disagreements in those assessments.

Saying no and changing how work is done can both meet resistance

When a department wants AI-based automation, the CAIO may recommend another solution. The department head may see that as failing to provide the support they expected. If senior management expects a rapid AI deployment, it may also see the same executive as an obstacle. Sound technical reasoning does not guarantee that a recommendation will be accepted.

The CAIO can face resistance when recommending AI as well. The proposal may involve more than buying a new tool; it may change how work is done. An approval step may disappear, a decision may move to another team, or an employee who has performed a particular task for years may have a different role. Those affected will often consider what the change means for their own work before they consider the benefit described for the company.

In my view, one difficulty of the role is that the CAIO can be seen as interfering in everyone else’s work in either situation. The CAIO may be unpopular because they declined a request or because they want to change the existing arrangement. Understanding the business is not enough; they also need to be able to work with the people in it.

They need to explain a proposal through the department’s actual work. Which wait will be reduced? Which error will be prevented? Whose workload will increase? They should listen to the people who know the process and revise the proposal when necessary. An objection is not automatically resistance to change. It may identify a problem the design has missed.

Senior management cannot leave the responsibility for these choices entirely with the CAIO. If management asks the CAIO to question existing processes but retreats at the first disagreement, it cannot realistically expect that person to work with business units to change those processes. Management needs to own why the change was selected and how affected teams will be supported. The company does not need to assume that the CAIO is right about everything. It needs a way of working in which objections are considered and decisions are backed.

When does a company need a separate CAIO?

If a company has a few limited AI applications and its existing CIO, CTO, or data leader can manage the decisions with sufficient time and authority, adding another senior executive may not be necessary. The company can assign the responsibility explicitly, provide the needed support, and review the decisions made.

The case for a separate role becomes stronger when business units are competing for the same data, technical capacity, and budget. If applications carry greater risks, decisions in one department affect another, and existing executives lack time to address these shared issues, there is an ongoing need for coordination and decision-making.

It is still important to separate the gaps. Is there nobody to make the decision? Is the team unable to do the work? Or has the existing executive not been given authority? A new CAIO designed to address only the first problem leaves the other two in place.

A company might instead begin with a temporary transformation mandate. Once shared rules and team capability are established, some responsibilities can move to existing executives. If AI becomes a continuing part of the product and operations, a separate role may remain. The deciding factor should be the ongoing workload, not whether the title is fashionable.

Do not judge success by project count

A CAIO’s report may show how many pilots have started, how many people use a tool, or how many models are running. Those measures show activity. Different records are needed to determine whether the returns process has improved.

Are customers receiving the right decision sooner? Are fewer cases reopened because of an incorrect decision? How much time are representatives spending correcting summaries? Does the result still justify the cost when integration, monitoring, and review work are included alongside the licence fee?

A pilot that fails to show the expected benefit can also be useful. The company has learned the limits before making a larger investment. That does not mean the number of cancelled projects should become another success metric. Stopping an idea is a good decision only when the available information and alternatives justify it.

Be clear about what you expect from a CAIO

When hiring a CAIO, a company needs to discuss plainly what it expects from an executive who understands AI. Will this person simply turn incoming requests into projects, or can they question whether those requests are worth pursuing? If they are expected to change how work is done, it must also be clear how they will work with the responsible managers and who resolves disagreements.

A CAIO cannot take on every problem in the company. Business units remain accountable for their outcomes, while the CAIO assesses where AI can help and works with them to implement the necessary changes. If management assigns that responsibility without the authority and support to match, adding a new title will not solve the problem.