How AI Is Reshaping the Enterprise AI Operating Model

An effective AI operating model requires more than deploying tools that automate existing tasks. As AI begins to influence business decisions, customer interactions, and resource allocation, organizations must rethink how teams work, where accountability lies, and how performance is measured.

For CTOs, the challenge is integrating AI into enterprise operations without compromising decision quality, data reliability, or human oversight. The shift also raises a bigger question: how much of an organization’s structure needs to change to make AI work at scale?

In this interview with CTO Magazine, Derek Slager, co-founder and co-CEO of Amperity, discusses how AI is reshaping enterprise decision-making, why trusted customer data matters, and what technology leaders need to rethink as they move beyond automation.

AI is changing more than workflows. It’s reshaping how decisions move through the business

AI often enters an organization as a way to accelerate an existing task. But once its recommendations begin to influence customer interactions and business priorities, it starts changing how decisions flow among people, teams, and systems.

This is where AI adoption becomes an operating-model challenge rather than simply another technology implementation.

We often talk about AI as a way to make existing work faster. At what point does it stop being a productivity tool and start changing how the organization itself operates?

Derek Slager: “AI adoption often begins with making an existing task faster. The bigger change comes when it influences which work gets prioritized, what a team recommends, and how a customer is treated. At that point, leaders are designing a new decision-making process, with different handoffs and responsibilities.

“Consider a service representative helping a customer with an unresolved issue. A useful recommendation depends on connecting that issue to the right person, their history and the latest interaction. It also depends on what the representative is permitted to do. That context has to travel with the decision as it moves between teams and systems.

“The overlooked change is that errors can scale with the workflow. A mistaken identity or an outdated signal can affect multiple recommendations before anyone notices. Leaders need a way to detect those problems, stop affected actions and correct the underlying context.

“That is an operating-model question. Who owns the quality of the customer context? Or, who defines the system’s authority? Who can intervene, and who is accountable for the outcome? A redesigned workflow is useful only if those responsibilities are clear.”

Saving time is not the same as creating business value

AI productivity is increasingly measured through adoption figures and estimates of hours saved. But those numbers can miss what happens after the output is generated.

If employees spend significant time checking recommendations, correcting mistakes or moving information between disconnected systems, the productivity calculation can look very different.

Everyone is talking about AI productivity right now. But if a tool saves employees time while creating more checking and rework elsewhere, can we really call that productivity? What should leaders actually be measuring?

Derek: “I would start with the business decision an investment is supposed to improve. Licenses and prompt counts tell you about adoption. Hours saved can indicate efficiency. The stronger test is whether that efficiency improves an outcome, such as retention or cost to serve, without reducing quality.

“Measure the whole workflow. A faster analysis has limited value if employees then spend hours reconciling customer records, checking unsupported conclusions or moving the result into another system. Include that review and rework in the productivity calculation.

The scorecard should connect operating measures to a business result:

How long does it take to move from a customer question to a reviewed decision and completed action?

What amount of employee effort goes into checking, correcting, and completing the work?

Also, how often do incorrect identities, stale data or missing context cause a recommendation to fail? Does the workflow improve the chosen outcome compared with a baseline or a suitable comparison group?

Choose a specific use case, establish the baseline before deployment, and account for the full cost of operating it. That gives executives a more credible investment case than adding up estimated hours saved.”

AI is only as useful as the customer context behind it

AI can produce a convincing recommendation from incomplete information. That is what makes fragmented customer data more than a technical inconvenience.

If an organization cannot reliably link customer identities and interactions across systems, employees may spend more time reconciling information, while AI makes decisions based on an incomplete picture.

Let’s talk about the data underneath these decisions. What happens when an organization introduces AI before it has a reliable picture of who its customers actually are?

Derek: “Trusted customer context gives AI a more reliable basis for analysis and gives people a common basis for acting on it. Identity resolution is the starting point: connecting records that belong to the same person. The decision also needs relevant history, current signals, permissions, and business rules. A unified profile alone does not supply all of that.

“For example, one person might shop with an email address, a loyalty number, and a guest checkout. If those records remain disconnected, a system can interpret them as different customers. That can produce duplicate outreach, an incomplete service history, or a misleading picture of retention.

“Employees then absorb the reconciliation work. Service representatives check suggestions against other systems, marketers rebuild audiences, and analysts explain why reports disagree. The organization has automated part of the process while leaving the hardest trust questions unresolved. The same problem affects operational decisions. A customer who moves from online shopping to a store can appear to have stopped buying if the business cannot connect activity across channels. A retention recommendation based on that incomplete history may target the wrong customer or diagnose the wrong problem.”

“With a dependable foundation, data teams can focus on maintaining and testing the context, while business teams spend more time evaluating recommendations and acting within agreed boundaries. That does not eliminate review. It makes review more focused on the evidence, the decision, and its consequences.”

The biggest transformation problem often starts after the demo

A successful demonstration can show what a technology is capable of. It cannot show whether employees have the authority, evidence and recovery processes needed to use it reliably every day.That gap between a compelling demo and the reality of adoption is where many technology projects encounter resistance.

We’ve all seen technology demos that look impressive, but everyday adoption is a different story. Where does the gap usually appear between what a technology team builds and what the organization is actually ready to use?

Derek: “Technology leaders should design the change in how people work alongside the system itself. A successful launch tells you the software is available. It does not tell you that the organization can use it reliably.

“Before building, map a real decision from beginning to end. Who makes it today? What information do they need? Which steps could AI support? Who reviews the recommendation, and what happens when it is wrong? Work through those questions with the people doing the job.

“The disconnect often appears between a convincing demonstration and everyday use. A team may like the output but still lack the evidence, permissions, or recovery process to rely on it. If the new workflow cannot handle exceptions, people will keep the old process running alongside it.

“CTOs should work with business and people leaders on incentives, training, approval boundaries and role expectations from the beginning. If a workflow prioritizes retention while a team is rewarded only for new sales, the technology and the operating model are pulling in different directions.

“Start with a bounded use case, observe how people use it and improve the workflow before expanding. Share a scorecard that measures business results, employee effort, and reliability. Adoption should be part of delivery, with an owner and a feedback loop.”

As AI does more of the analysis, human judgment becomes more important

The more answers and recommendations AI produces, the more important it becomes for employees to recognize when an answer should be questioned.

A response can sound convincing while relying on incomplete data, an outdated signal or the wrong customer identity. Knowing how to challenge that output may become as important as knowing how to generate it.

If AI is going to give people more answers and recommendations, what do employees need to get better at? Is the real skill becoming knowing when to question the answer rather than simply knowing how to use the tool?

Derek: “Judgment becomes more valuable as AI produces more analyses and recommendations. People need to assess whether an answer fits the evidence, recognize what is missing, and know when to escalate. A fluent answer can still rest on the wrong customer identity or an outdated assumption.

“Domain expertise matters here. Someone who understands the customer and the business can spot a recommendation that is technically plausible but operationally wrong. Organizations need to make that expertise part of the feedback loop.

“Employees also need to frame problems clearly and question the data behind an answer. Where did it come from? How current is it? Does it cover the relevant customer activity? Is this use permitted? Those are practical skills for anyone working with AI, not just data specialists.

“Reskilling should use real work. Take a familiar customer problem and have employees frame the question, inspect the supporting evidence, challenge a recommendation and practice approving or escalating the next step. Assess whether they can make a sound decision, rather than whether they can operate an interface.

“Managers need to make it safe to identify mistakes and stop a workflow. That feedback helps improve both the system and the process. Training should continue as the work changes, with time and support for employees to develop those skills.”

Someone still has to own the decision

AI can support a decision, but it cannot remove responsibility for its consequences. The challenge is deciding where accountability sits when business leaders, technology teams, and data teams all contribute to the system.

Clear boundaries can also help organizations move faster by clarifying where experimentation is appropriate and where greater oversight is required.

When an AI-supported decision goes wrong, who actually owns it? And how do organizations create that accountability without turning every AI experiment into a months-long approval process?

Derek: “Accountability should stay with the people who have authority over the decision. The business leader responsible for a customer outcome needs to own how AI is used to pursue it. That accountability has to come with the ability to set limits, inspect results, and stop the workflow.

“Responsibilities need to be explicit across functions. Data teams maintain and test the customer context. Technology teams own system reliability, access controls, and traceability. Business leaders define decision criteria and review outcomes. Executive leadership sets the risk boundaries, with privacy, security, and other specialists involved where relevant.

“Clear boundaries can make experimentation faster. Define the permitted data, actions, and approval steps for a bounded use case before the team starts. Record the evidence and actions needed to review it, and provide a way to intervene and recover. Testing a recommendation without changing a customer experience should have a different approval path from issuing a refund or launching outreach.”

Customer data is becoming infrastructure, not just a marketing asset

Customer data has traditionally been viewed through the lens of marketing and analytics. But as more teams and systems depend on customer information to make decisions, trusted context becomes something closer to shared infrastructure.

That has implications for how organizations structure teams, allocate technology investment and measure the value of their data.

Customer data used to sit largely in the marketing and analytics conversation. What changes when an organization starts treating trusted customer context as shared infrastructure for the entire business?

Derek: “Customer context becomes shared infrastructure for decisions across the business. It connects who a customer is with relevant history, recent interactions, and the rules governing how that information can be used. Managing it strategically means investing in its reliability and assigning responsibility for supporting business outcomes.

“I would expect that to change three things:

How teams are organized. Data and technology teams maintain a governed customer foundation, while business teams define the context their decisions require. Shared definitions reduce the need for each department to reconcile its own version of the customer.

Where investment goes. Reusable identity, data access, and governance capabilities can reduce duplicated integration work. Keeping that foundation distinct from a particular AI interface can also make it easier to evaluate new models, although switching still requires integration work and testing.

How success is measured. Pair measures of data quality and freshness with the results of a specific workflow, such as retention or cost to serve. Test whether better context improves the decision and outcome. Cleaner data is valuable, but it is not by itself proof of revenue growth.”

The CTO’s job is getting bigger than the technology

Once software begins influencing decisions, approval boundaries, and the responsibilities of employees, technology architecture becomes closely connected to organizational design.

That does not mean the CTO should own every aspect of workforce strategy. But technology leaders increasingly need to understand how systems change the way people work and where those changes create new risks or opportunities.

Do you think the CTO role is changing as a result? Are technology leaders now being pulled further into questions of organizational design and workforce strategy, whether they planned for that or not?

Derek: “I expect technology leadership to become more closely involved in organizational design. When software influences decisions, choices about access, approval, and system behavior also shape people’s responsibilities. CTOs need to understand those consequences as part of the architecture.

“The capabilities I would encourage technology leaders to build are:

● Connect architecture to economics. Explain how an investment changes employee effort, operating cost and the business result.

● Design for accountable decisions. Define authority and approval boundaries with business leaders, and make intervention and recovery practical.

● Translate in both directions. Turn a business goal into system requirements and explain technical limits in terms people can act on.

● Build for change. Keep customer context and governance reusable, and evaluate new models against real workflows before expanding their use.

“For customer-facing AI, the model is one part of the system. A durable advantage comes from accurately understanding customers, bringing that context into the decision, and using it responsibly. Technology leaders have to make those pieces work together.”