An executive IT dashboard can stay green for a year while the risks it is supposed to surface keep growing. Availability above target every month. Service levels met. Patch compliance climbing quarter over quarter. Every number accurate, and every one trusted by the executive team.

When trouble finally arrives, it skips amber entirely. It comes as an outage, an audit finding or a security incident, and the first question in the room is why the dashboard said everything was fine.

In my work with technology leaders and executive teams, I have learned that a dashboard can be technically accurate and still leave leadership dangerously misinformed. Usually nobody fudged anything. The numbers were built to summarize, and a summary is very good at hiding the one thing an executive most needs to see. Three metrics produce most of that false comfort at the executive level. I would not put any of them in front of a CEO or a board as a headline number.

Three green numbers I would take off the executive dashboard

Monthly availability is the classic. A 99.9 percent month still allows about 43 minutes of downtime, and the percentage says nothing about when those minutes fell. Forty minutes at 3 a.m. on a Sunday and forty minutes during month-end close produce the same number. So do one long outage and a dozen short ones that each forced the order desk to restart its work. CIO.com made a version of this case years ago, arguing that uptime means little until it is tied to business impact. Business leaders notice the gap. When the official figure does not match what their teams lived through, the dashboard loses the room, and nobody tells the CIO.

Service-level attainment is the second. A service desk can hit its resolution targets month after month while the same problems keep coming back. A recurring sync failure gets fixed in twenty minutes, closed inside the target and counted as a success. It happens again the following week and gets counted as another success. The metric rewards fast closure, so the organization gets very good at fast closure, and the underlying fault never draws enough attention to be fixed. What builds underneath is a growing list of known problems held together by workarounds. Each one is a small daily cost to the business and a much larger risk the day the person who knows the workaround leaves.

Patch compliance is the third, and the most dangerous, because it expresses security posture as a percentage of a device count. A fleet that is 96 percent patched sounds well defended. The question the percentage cannot answer is which 4 percent. The unpatched remainder is rarely random. It is the legacy system nobody is allowed to reboot, the vendor-managed appliance the team cannot touch, the server behind a process considered too important to risk. Those are often the assets an attacker would pick first. The headline number improves every quarter as the easy devices get patched, while the exposure that matters sits unchanged on an exceptions list nobody above the security team reads.

Why averages flatter the people who report them

Each of these metrics averages across a large population where the risk is concentrated in a small corner. The thousands of healthy devices, the hundreds of quiet hours and the routine tickets all pull the number toward green. The handful of things that could actually hurt the company barely move it.

Executive dashboards drift toward this kind of measure for understandable reasons. Percentages are stable, they trend nicely and they compare cleanly against a target. They also protect the team producing them, which is the part few people say out loud. A metric that is green almost every month spares everyone a hard conversation. Over a few years, without anyone deciding it, the dashboard selects for numbers that do exactly that. One question exposes it quickly: when did the executive dashboard last show a red month? If nobody can remember, or nobody can say what it would take to produce one, the dashboard has stopped measuring the organization and started reassuring it.

The cost lands when something breaks. A CIO who reported green for eleven straight months and then has to explain a major incident is answering two questions at once: what went wrong and why the reporting missed it. The second question is the one executives remember, and it colors how they read every report that follows. After that, a green month is no longer taken at face value.

I hold every executive metric to one test. If a number cannot embarrass me, it does not belong on the dashboard.

What I would put in front of executives instead

The replacements are less flattering and more useful. There are three I would choose.

1. Disruption minutes on the processes that matter. It starts with an agreement with business leaders, made in advance, on a short list of processes their teams cannot run without and the windows when those processes matter most: order entry during business hours, payroll in the days before a run, financial systems at close. Then the dashboard reports minutes of disruption to those processes during those windows, and every incident behind the number is listed by name. A quiet month looks quiet. A bad Tuesday during close shows up as exactly what it was, and the business leaders in the room recognize it because they lived it.
2. Repeat incidents. Of everything that broke this month, how much had broken before? I would trade every resolution rate on the dashboard for this one number. A low repeat rate means problems are being fixed at the root. A rising one means the organization is living on workarounds, and it shows up months before the workarounds start to fail in ways that customers notice.
3. The age of the worst exposure. For security, the measure I want to see is the oldest unremediated critical vulnerability on systems that face the internet or hold sensitive data, along with the number of standing exceptions and the name of the executive who approved each one. The age moves only when the hard cases get fixed, which is the point. An exception with an executive’s name on it is far more likely to get a decision: fix it or own the risk. An exception that belongs to nobody can sit indefinitely.

Each replacement shares three properties. Its red threshold is agreed before the reporting period begins, so nobody negotiates it after the fact. It points at a specific process or system, so a red result tells an executive where to look. And it is uncomfortable enough that the team would rather fix the underlying issue than explain the number again next month.

The old percentages still have a home. They stay on the operations team’s internal dashboards, where they help run the shop day to day and where a team lead can see a trend early. The executive view gets the measures that can turn red.

None of this requires new tooling. Most IT organizations already capture the incident history, the vulnerability data and the process calendar these measures depend on. What it requires is a decision about what the executive team is entitled to see, and the willingness to show a red month before something forces it.

The first report built this way will almost certainly show red somewhere, and that is the reason to build it. A red month is uncomfortable for a meeting or two. It also sharpens the questions, turns the conversation to the actual condition of the systems the company runs on and ends the CIO’s role as the person who said everything was fine. A dashboard that has been green for a year might be telling the truth. From the top, there is no way to know, and that is reason enough to change what goes on it.

Clients ask me this question perhaps more than any other. They’ve usually just come off a bad experience, either analytics stuck in IT’s backlog for months or analytics scattered across the business without anyone accountable for what it all means. My answer is always the same. Split it. IT owns the data engineering. The business owns the analytics. And you need one small team sitting between them to keep the whole thing from drifting apart.

That’s not a compromise position I land on to avoid picking a side. I’ve witnessed companies that went all in on one extreme or the other, and they end up in the same place. They have expensive dashboards sitting untouched and analysts who stopped trusting the numbers years ago. Give me twenty minutes with a client and I can usually tell which extreme they started from, just by looking at what’s broken.

Full centralization and full decentralization both fail the same way

When IT owns everything, security and governance are usually solid. You need people who actually understand networking and access control managing any connection to raw data coming out of your ERPs, TMS and CRM systems, not analysts who picked up security practices on the side.

But speed dies. Business analysts wait on intake forms and requirements documents that assume you can specify a dashboard’s full scope before you’ve ever seen the data move. Analytics doesn’t work that way. It’s one of those areas where you need multiple iterations to land on the right end state. You learn what you need by building something rough, using it for two weeks and rebuilding half of it. A team that has to file a ticket for every iteration will never keep pace with a business that changes its questions weekly. People who sit close to the business need the freedom to iterate as the tools mature, and that freedom disappears the moment every change has to clear an IT queue.

Flip it and hand analytics entirely to the business, and you get the opposite failure. I worked with a company this year that let every department build its own reports with no shared standards or governing body. Marketing had one set of definitions for a “customer.” Sales had another. Finance had a third, and every meeting turned into an argument about whose number was right. Total spend wasn’t being tracked either. As you can imagine, by the time they called me, their cloud analytics costs on Microsoft Fabric had already climbed past $20,000 a month, and the team couldn’t point to where it was going. They fixed it by building a small internal group, essentially a center of excellence, that owned the standards everyone else built on top of. CIO contributor Ranko Cosic’s April 2026 piece, “How analytics and AI are reshaping the boundaries of IT leadership,” draws a similar line, arguing that IT leadership builds the capability to analyze while analytics leadership builds the capability to decide. I’d add a third piece. Someone has to own the handoff between those two, or you get exactly the sprawl I saw at that client.

There are numbers behind this. In a survey of more than 2,400 CIOs, Gartner found that companies where IT and business leaders co-own delivery, what Gartner calls the “franchise” model, hit or beat their targets on 63% of digital initiatives. Companies where IT keeps sole ownership hit that mark on just 43% of initiatives. Only 12% of CIOs run a true franchise model today. That’s the whole argument in one number.

Adoption breaks when builders and users are different people

A few years ago, I got called into a large manufacturing company that had spent three years and an entire IT department building a dashboard platform meant for the whole organization. When I looked at usage, six people were opening those dashboards regularly. Six, out of thousands of employees. The tools worked fine technically. What broke was trust, and it’s a classic mistake. Trust and adoption begin when end users are part of the design process, or better yet, when they’re the ones building the tools.

That number stung, but it isn’t unusual. A BARC and Eckerson Group survey of 214 data and analytics leaders found average active adoption of BI tools sitting around 25%, a figure that had barely moved in seven years of tracking. Those companies bought good tools, but the adoption model wasn’t built to match. They skipped giving the people who’d use those reports a role in building them. Adoption climbs when the people using a report have a hand in shaping it, or better yet, built it themselves. That manufacturing client shifted from a fully centralized build to a decentralized one, with IT still owning the underlying data and business teams, together with us as consultants, owning what got built on top of it. They now have roughly 80% of employees using the tools weekly, on the same data, at the same company, with nothing changed but who owned the build.

I bring this up with every client who tells me they want “one IT team” running analytics end to end. A single team can own the pipeline. It can’t own every department’s judgment about what a useful report looks like, and trying to force that usually produces the same six-user outcome I saw at that manufacturer.

Standardization is the toll you pay for scale

There’s a fifth benefit to this structure that I didn’t lead with, but it’s the one that surprises clients most. It’s that alignment gets easier, not harder. Any organization of real size has a hundred project requests, a thousand small enhancements and a never-ending list of technical debt sitting somewhere. When all of that runs through one intake, owned by the seam team instead of scattered across five departments, prioritization stops being a fight and starts being a conversation. Time and time again, I’ve watched people set aside what’s good for their own team once they can actually see the whole list, the whole picture of what needs doing across the business. That only happens with one line of work to look at, not five competing ones.

This doesn’t come free. Splitting ownership this way comes with costs, and I tell clients about all three before they commit to the model.

First, the ramp-up is slow. If your organization has been running fully centralized or fully decentralized, the first few months of a split model will feel like you’re moving backward. You’re building shared data models from a standing start. You’re writing templates nobody has tested yet. None of it pays off immediately, and it takes longer than anyone wants to admit before the shared foundation starts paying for itself.

Second, coordination gets harder. Running one IT team that reports up a single chain is simpler than coordinating a business analytics team and an IT team that each report somewhere else and only share a dotted line into governance. You’ll spend real time in rooms aligning people who don’t share a manager.

Third, standardization itself is a hard sell early on. People resist naming conventions and data model rules when they can’t yet see why those rules matter. I’ve sat through those meetings. It usually takes a few months before teams start seeing the payoff in shared resources and consistent numbers across departments, and until then you’re asking people to trust a process they can’t yet see the benefit of.

I still think the tradeoff is worth it. The alternative is a business that’s either too slow to answer its own questions or too scattered to trust the answers it gets. Every client I’ve seen commit to the split — security in IT, agility and ownership in the business, a small governing layer holding the seam together — has come out the other side with something that actually gets used. The ones that skip the governing layer end up back in my inbox a year later, describing the exact same $20,000-a-month problem with different numbers attached.

So, when a client asks me where analytics should sit, I don’t tell them to pick a side. Instead, I tell them to build the seam. Put someone in charge who speaks both languages, IT and the business, and give that person say over the standards. If you skip that part, you end up back where you started. Get it right, and it’s the difference between six people opening a dashboard and eighty percent of the company doing it every week.

For most of computing history, performance was an engineering problem you could reason about at your desk. Profile the code, count the database calls, size the hardware. If a system was slow, the cause was usually something you could hold in your head: an unindexed query, a synchronous call that should have been async, a loop that ran one order of magnitude too many times. You could draw the system on a whiteboard, and the whiteboard would basically be correct.

That era is over. In cloud-native systems, performance has become an emergent property. It arises from the interaction of many moving parts, most of which you don’t directly control, and that shift changes how we have to engineer for it. The core argument is simple to state and hard to internalize: in a modern-day distributed system, you cannot optimize what you cannot observe.

Performance is no longer about your code

Consider what actually determines the speed of a cloud-native application today. It’s spread across dozens of loosely coupled microservices. Those services share network fabric and physical infrastructure with other tenants on a Kubernetes cluster. They’re scheduled into containers by an orchestrator making placement decisions you never see, filtering and scoring nodes behind the scenes before binding a workload to whichever one wins, and they scale up and down automatically in response to demand that arrives in unpredictable bursts.

In that environment, application behavior is driven less by algorithmic efficiency than by distributed orchestration, virtualization overhead, and workload variability. A minor shift in traffic distribution or container scheduling can introduce a bottleneck that’s genuinely difficult to diagnose after the fact, because the conditions that caused it may no longer exist by the time you go looking. Inter-service calls that look trivial in isolation — a few milliseconds here, a few there — accumulate into measurable delay across a long service chain, the same way a handful of small taxes compound into a large bill.

And in a multi-tenant cloud, a competing workload can degrade your responsiveness in ways you can’t reproduce on demand. This is well known enough in cloud architecture circles to have its own name: the noisy neighbor problem, where one tenant’s activity on shared infrastructure quietly degrades another’s performance even though nothing in your own stack changed. The performance you get is the sum of all these interactions, not just a property of any single component you wrote.

Why traditional monitoring falls short

The instinct is to throw monitoring at the problem. But there’s a meaningful difference between monitoring cloud-native systems vs. actually exposing where fault could lie. And that is exactly where that difference matters. Cindy Sridharan made a case earlier, describing traditional monitoring as failure-centric, built around a list of known ways things break, whereas observability is meant to support open-ended debugging of failures nobody predicted.

That distinction matters in practice because averages are exactly the wrong lens for distributed systems. Average latency can sit directly on top of a system that is intermittently unbearable for a meaningful slice of users, and because averages smooth over the short-term, however, it is the sharp events that hurt the most. This isn’t a new observation; in the now-classic paper on large-scale systems, Google engineers Jeff Dean and Luiz André Barroso described how tail latency at scale becomes the dominant experience for users of any sufficiently large distributed system, because a request that fans out to hundreds of components only needs one slow component to become a slow request overall. As a system grows, the odds that at least one component is having a bad moment approach certainty. Averages don’t see that. Observability, done well, means being able to ask why a specific request was slow and reconstruct the answer from execution traces, logs, and fine-grained runtime telemetry across every service that request touched. The goal isn’t a prettier dashboard. It’s the ability to follow one request through the system and see exactly where the time went.

Designing for runtime, not just design-time

The deeper lesson is about when we assess performance, not just how. For years, performance testing was a design-time activity: run a load test before release, and if the numbers look good, ship. Cloud-native systems break that assumption, because so much of what affects performance — scheduling decisions, autoscaling behavior, neighbor interference, resource contention under real traffic shapes — only exists at runtime and only under real workloads. Offline benchmarks against fixed, synthetic traffic patterns simply don’t capture it, because production traffic doesn’t arrive in the tidy, evenly distributed way a load-testing script assumes.

So, performance assurance has to move closer to production: continuous telemetry from running services, compared against known-good baselines, so that degradation is caught as it emerges rather than discovered after users feel it and complain. There is a growing body of research pushing in exactly this direction, on observability-driven and adaptive autoscaling approaches that use runtime signals rather than fixed thresholds to decide when and how to scale. The results across that research vary by system and workload, and the specific percentage improvements aren’t  quoted as a single universal number. What is consistent is the underlying finding: systems that scale and adapt based on what’s actually happening at runtime tend to outperform ones that rely on static, pre-configured rules, particularly on tail latency, which is the metric static rules are worst at protecting. The specific numbers in any one study matter less than what produced the improvement: measuring the system as it actually runs, not as it was assumed it would run when someone configured the autoscaler months earlier.

The takeaway

Cloud-native architecture gave us tremendous flexibility, and it took away our ability to reason about performance. The right response isn’t to fight that trade. It’s to accept it and instrument accordingly.

Treat observability as a design requirement, not an afterthought bolted on after an incident. Measure at the percentiles, not the averages, because the averages are hiding the exact failures that matter most to real users. And assess performance where it actually happens: at runtime, under real load, continuously, rather than only in a pre-release load test that can’t anticipate what production traffic will actually look like.

In systems this complex, visibility is the prerequisite for everything else. You can’t optimize what you can’t observe, and you can’t observe it unless you designed it, from the start, to be seen.

Taylor Paletta was glancing at two versions of the same customer-service interaction on her monitor. As director of support and digital success at the enterprise software company, Ninety, she could read the support chat in one window while watching the customer’s product session in another. The customer had already spent several minutes trying to solve the problem, including twice attempting the sequence the AI agent would eventually recommend.

The chat transcript alone looked reasonably positive and successful. The customer asked a question, the AI agent responded promptly and the case appeared to move toward resolution. Yet the session recording spun a different story altogether. The customer was being asked to retrace steps that had already failed, while the AI agent had no awareness of what they had done before opening the support widget. Both records contained accurate data; however, only the behavioral record explained the customer’s actual experience.

Paletta’s team addressed this apparent systemic issue by feeding behavioral session summaries into their customer support AI agent before the conversation begins, not after. The AI agent can now see what the customer did inside the product, where the process broke down and which steps have already failed. Moreover, when the interaction escalates, the human agent inherits the same context rather than reconstructing the story from scratch. Tickets with that behavioral context now resolve at 79%, six points higher than tickets without it.

A six-point improvement may not sound dramatic, yet it is a real gain tied to a specific change in how the work gets done, resulting in real revenue. Additionally, and perhaps more importantly, it illustrates a measurement challenge well beyond customer support. That is, many organizations know how much AI they have deployed, but they have far less visibility into whether AI changed the work or improved the outcome.

Indeed, MIT researchers examining U.S. enterprise AI deployments reported roughly $35 billion to $40 billion committed, while 95% of organizations reported no measurable return. The problem is that companies tend to measure what their systems make easy to count — licenses, logins, prompts, sessions and features activated. Then they use those measures as questionable proxies for value, not realizing or acknowledging that activity actually may be inversely related to value.

Customer service activity is not value

Customer service, as much as any business function, makes activity-versus-value distinction especially lucid. Common customer support AI applications don’t capture behavioral data and therefore can create more effort for customers and agents when issues are escalated. Applications informed by behavioral data, however, may produce fewer interactions precisely because they resolve more issues correctly the first time. Therefore, prompt volume or time in the application can be ambiguous measures. Sometimes, more customer interaction indicates more friction rather than more value.

This suggests distinguishing between different types of behavioral signals that show AI is merely available or being used versus signals that show work is actually changing:

1. Provisioning signals include seats purchased, licenses assigned and accounts activated, which tell you what the organization made available.
2. Engagement signals include logins, sessions, prompts and time in the application, which tell you that activity occurred. Both are useful operational measures; nonetheless, they offer limited evidence about whether the service improved.
3. Displacement signals go further by showing which human steps disappeared, which handoffs were eliminated and whether AI output survives into the finished work.
4. Friction signals capture rework, repeat attempts, abandonment, escalation, rage clicking and silent workarounds.

Displacement and friction-related measures are particularly aligned with economic value because they reveal what changed in the process and what the customer (or employee) had to do differently as a result.

At Ninety, for example, AI-generated session summaries now arrive inside the agent’s ticketing workflow. Previously, an agent handling a difficult case might open another application, scrub through a session replay, locate the point of failure and then reconstruct the story while the customer waited. With behavioral context already attached to the ticket, much of that work can disappear. Consequently, the organization can measure fewer applications opened, fewer handoffs, shorter resolution paths and less manual reconstruction rather than merely reporting that an AI feature was used.

Behavioral data changes the conversation, literally

Behavioral data does more than make the AI more efficient; it changes what the AI knows about the customer at the moment a decision has to be made. In service, this becomes important because a correct answer can still produce a poor experience when it arrives without context. Paletta’s team, for instance, found that some customers tired of AI conversations even when the answers were technically accurate, but the interaction felt cold, repetitive or unnecessarily difficult.

“Traditional adoption metrics have little to say about that kind of problem,” says Scott Voigt, co-founder and CEO of Fullstory. “Behavioral signals, however, can reveal repeated attempts, hesitation, abandonment, rage clicking or a pattern of moving back and forth through the same workflow.”

These types of signals can then trigger a different response, including routing the customer to a person before frustration compounds. In other words, behavioral data becomes part of the service logic rather than merely another source for retrospective reporting.

Paletta describes some of these branching experiences as a “choose your own quest” model, in which observed behavior influences the next path, and AI handles the decision until human intervention becomes appropriate. Furthermore, because the path is based on what customers actually do rather than what designers assumed they would do, the organization can refine the experience continuously as new patterns appear.

Measuring the work, not the worker

There is, however, an important governance issue. Once executives realize that conventional AI metrics reveal too little, the reflex may be to monitor individuals more closely. That approach can easily distort the very behavior the organization is trying to understand, since employees who feel personally tracked and scored may experiment less openly, conceal failed attempts or move work into channels that are harder to observe.

A more useful unit of analysis is generally not the employee but the work: the workflow, journey, handoff or decision.  Instead of asking how many prompts a particular support agent entered, ask where agents still have to reconstruct context manually, which cases require repeated escalation, where AI output routinely needs correction, and whether someone’s effort is rising or falling. Similarly, rather than judging people by an isolated session, look for aggregate patterns showing where people overall stall, repeat themselves, abandon a path or seek human help.

Moreover, this approach tends to produce better data because the purpose of the instrumentation is easier to defend. Instrumentation intended to improve a process is fundamentally different from instrumentation used to grade an employee; once people begin optimizing their behavior for the score, the measurement itself corrupts the signal. The former can reveal where the service design is failing; the latter may encourage people to change their behavior simply to “game the system.”

Starting the customer support journey before they do

One of Paletta’s more interesting measures extends the same thinking beyond Ninety’s own support environment. Customers now frequently consult public AI models before they visit a company’s support site. Consequently, an external system the company does not control may already be functioning as an informal first layer of customer service, interpreting company content and shaping the customer’s expectations before a formal support interaction begins.

So, the Ninety team compiled the company’s help center and blog content into JSON, tested how frontier models such as ChatGPT and Gemini alone answer questions about the product, and built a scoring system for answer quality. The scoring system helps the team identify where Ninety’s source material produces weak answers so they can improve the underlying content.

This expansion of what behavioral data includes not only what users do inside the sanctioned AI application, but also the observable choices they make around it, e.g., whether they abandon one channel for another, whether they repeatedly seek clarification, whether they bypass an AI agent and whether they arrive at support after already trying to solve the problem elsewhere. Indeed, those behaviors often reveal dissatisfaction or disengagement earlier than a survey, complaint or renewal discussion.

The business case for behavioral data

Return, then, to the customer who had already tried the same troubleshooting sequence twice. The support transcript could reasonably have been counted as a successful AI interaction, and a conventional customer service analysis dashboard might have added another prompt, another active user and another resolved conversation to its totals. Yet those measures would still have missed the fact that the customer was repeating failed work because the AI lacked behavioral context.

The customer who had already attempted the same troubleshooting sequence twice could easily have registered as an AI success: another active user, another prompt, another conversation apparently resolved. Yet almost every conventional measure would have missed the part that mattered — the customer was doing unnecessary work because the AI lacked the context to know better.

Behavioral data connects what the AI did to what happened around it, what the customer had already attempted, what the employee no longer had to do, where friction disappeared or compounded, and whether the process itself improved. For CIOs trying to establish the business value of AI, behavioral data answers “What happens better, faster, different or not at all because of AI?” rather than simply “How much are people using AI?”

Every IT leader knows the pattern. One team builds a report in a spreadsheet. Another spins up a workflow with slightly different logic to answer the same question. A dashboard is shared across three departments, and within a week, nobody can say for certain where the underlying numbers came from. 

Instead of freeing up capacity, self-service has quietly become another form of manual work: chasing down mystery logic, reconciling duplicated effort, and answering questions nobody wants to own. 

Self-service was never the risk 

It is tempting to read that scenario as an argument for tighter control — fewer people building, more requests routed through a central team, more approvals before anything ships. That reaction is understandable, but it solves the wrong problem. 

Self-service fails when there are no shared rules for access, quality, documentation, and ownership. Without those guardrails, speed doesn’t produce faster decisions, just more confusion distributed across spreadsheets and more shared drives. 

The real tension is that most organizations have been offered only two options. Either lock everything down, or let everyone build whatever they want and hope it holds together. Neither one scales. 

IT as the paved road, not the checkpoint 

Centralizing data was never the hard part. The real challenge is the last mile: turning that data into decisions and actions the business can actually trust. Closing that gap does not mean IT owns every rule, calculation, and exception that determines how work gets done. 

It means IT builds the paved road — trusted access, approved workflows, reusable templates, and visibility into what is being built — while the people closest to the work own and adapt the business logic that runs through it. 

That division of labor changes what “governance” means in practice. Instead of a gate every request has to pass through one at a time, governance becomes the infrastructure that keeps logic visible, understandable, repeatable, and auditable by design. When the fastest way to answer a question is also the most trusted way, analysts do not need to be talked into compliance, and IT does not need to inspect every workflow to know it will hold up. It is simply how the work gets done. 

Freedom and guardrails, together 

Governed self-service isn’t about choosing between speed and control, it’s about giving each side of the equation what it actually needs to trust the other. 

Governed self-service gives analysts: 

• Access to trusted data 

• Reusable templates and workflow patterns 

• Clear rules for sharing and automation 

• A way to document logic 

• Support when a workflow needs to scale 

And it gives IT: 

• Visibility into who is building what 

• Better governance over access and data use 

• Fewer one-off requests 

• Less mystery logic floating around the business 

• A cleaner path from individual workflow to team-wide process 

What this looks like in practice 

Papa Johns’ finance team offers a useful example of governed self-service in action. The team handles risk-sensitive, high-volume work — franchise billing, royalty calculations, aggregator commissions, and SOX-compliant period close — across a global, multi-currency franchise business. 

Historically, much of that logic lived in spreadsheets and disconnected tools, separate from the systems of record and hard to audit when workflows changed. 

Using Alteryx, Papa Johns rebuilt franchise billing and reconciliation as a governed workflow that runs directly against its Google BigQuery environment, so calculations execute where the data already lives rather than being copied out to another location. 

With Alteryx, complex calculations are visible, repeatable, and auditable. Finance users can ask natural language questions, such as comparing month-over-month figures, and receive immediate answers while also seeing how logic is applied. IT can support governance without becoming a bottleneck. 

The partnership between the business and IT was key to scaling success. Michael Wyant, VP of Enterprise Data and Corporate Solutions, and his team are responsible for governance and data pipelines. The finance team owns the business logic and can adapt it as requirements change. 

Each side owns the part of the problem it understands best. 

The result is a workflow that finance trusts, that IT can stand behind, and that scales as a template for other high-stakes processes across the business. That’s the kind of outcome that governed self-service is meant to produce. 

Fewer surprises, more trust 

None of this requires IT to slow analysts down or analysts to work around IT. When self-service is built on shared standards, analysts stop waiting on tickets, IT stops chasing down mystery logic, and the business gets answers that hold up the moment someone asks, “Where did this number come from?” 

Alteryx supports that model by giving business teams a governed way to build and adapt workflows themselves, while giving IT the visibility, controls, and security required to support it all at enterprise scale. 

The goal was never more control for control’s sake. It is fewer surprises, less rework, and more answers the business can actually trust. 

Ready to see what governed self-service could look like for your team? Explore the AI-Ready Starter Kits to get started. 

 To learn more, visit us here. 

There’s a scenario that plays out every day across the enterprise. A salesperson is about to close a major deal. They want to know what their commission will be. They type the question into ChatGPT or their favorite AI assistant. What comes back is a thoughtful, well-written explanation of how software companies typically structure sales compensation. 

The one thing it won’t tell them is what their commission will actually be if they close this specific deal. That gap between what AI can reason over and what it knows about your business is the defining challenge of enterprise AI adoption right now. 

I call it the logic layer. And without it, AI gives you impressive sounding outputs that are often disconnected from how your business runs. 

Why business logic lives with the analyst 

One of the more persistent myths in AI is that analysts are on the verge of becoming unnecessary. 

The reality is the opposite, and the logic layer is exactly why. 

In an AI-enabled enterprise, analysts become more essential because they are closest to the logic and context that governs the business. They know which definition of pipeline matters and which edge cases matter in audit, merchandising, finance, or marketing. 

I believe enterprises that succeed in the AI era will not be defined by how much AI they deploy but whether the people who understand the business own and control the intelligence that runs it. 

If that ownership defaults entirely to IT or to a vendor’s black box, companies risk scaling systems they cannot fully adapt or audit. Giving business teams the tools and mandate to own their logic is what makes the AI system trustworthy and responsive to how your business runs. 

That is why I see analysts as the architects of this next phase. 

What the logic layer looks like in practice 

Let me return to the commissions example, because it illustrates the concept precisely. Right now, when a salesperson needs to know their commission on a deal, they send a message to the commissions analyst. That analyst has their own spreadsheet — because comp plans change every quarter, with spiffs and special programs layered on top. They run the math manually and send back an answer. 

What if that same analyst built a simple, well-defined calculator that encoded their commission logic — the actual rules for your company, your plans, your programs — and connected it to the AI systems your salespeople are already using? Now when a rep asks what their commission will be on a specific deal, they get the right answer. Not a generic explanation of how commissions work. 

And here’s the compounding value: that same logic can then be used by the annual planning agent to model the operational cost implications of different comp plans. It can feed the scenario planning model that runs hundreds of simulations for financial planning. The analyst who built it enables an entire network of AI systems to act on accurate, business-specific logic. 

That’s the logic layer in practice: curated, purpose-built data assets and calculators that encapsulate how your business works, maintained by the people who understand it, deployable to every AI system that needs it. 

What the logic layer requires 

This is where I think most companies are still stuck. They’ve made the infrastructure investments. They have cloud data platforms and approved LLMs. But they’re asking those systems to do things they were never designed to do on their own. 

The logic layer requires three things: 

• Purpose-built data assets. A narrow, clean, well-defined data set that reflects how you actually measure a specific business process. 

• Encoded business logic. This is the part that lives in people’s heads right now — the policies, the edge cases, the context that makes data mean something. 

• The ability to update it. Nobody runs a business to keep it the same. The logic layer has to be something that domain experts can update when the business changes. 

A pragmatic path forward 

The good news is that you don’t have to wait for a perfect architecture before you start building a logic layer. 

Start with your highest-value, most-repeated business processes — the ones where an analyst is currently fielding the same questions week after week. These are the processes where encoding logic into a curated, AI-ready data asset delivers immediate, measurable value. 

Then, empower your analysts to own that encoding — not IT. Give them low-code tools to do the work, and the mandate to treat that encoded logic as a strategic asset they own and evolve as the business changes. 

This is also where leadership posture matters. 

I have said for a while that this should not be framed as a choice between business and IT. It is both. IT should set standards, manage infrastructure, establish security boundaries, and make approved AI capabilities available across the organization. But IT should not become the bottleneck for every piece of business logic the company needs to operationalize. 

If this feels familiar, it should. We have seen this pattern before in enterprise technology. Infrastructure and platforms matter. But the last mile, the part that turns capability into business value, always depends on the people closest to the work. 

AI is no different. 

The companies that get the most from AI will be the ones that treat it like an operating model. They will automate core workflows, curate the right data, and empower analysts and domain experts to define the logic that makes AI useful and generate answers the business can use. 

I recently had a chance to go deeper on these ideas on the Talking AI podcast. If you want to hear more of my thinking on the analyst’s evolving role, how the logic layer connects to agentic workflows, and why I think the next 18 months will be pivotal for getting this right, it’s worth a listen. 

 To learn more, visit us here. 

Every new frontier model release seems to spur a fresh round of doomsday articles. Just Google “the end of white-collar jobs,” and you’ll be bombarded with discourse on the end of modern work, the unraveling of the social contract between employees and organizations. 

What I don’t see anyone talking about, however, and what I believe is a far more productive conversation, is the opportunity for knowledge workers. 

Nobody understands critical business processes better than your line-of-business (LOB) employees. Not executives. Not IT. Not even the most advanced LLMs. These are your business analysts and RevOps professionals, your supply chain managers and finance leaders, and the employees whose expertise has been forged over decades. 

For an enterprise to become truly intelligent, these workers must be involved in how AI workflows are built and deployed. Their guiding hand is the only way AI can learn and truly understand your business. 

But what does this transition look like, and how can organizations start operationalizing AI in a meaningful way alongside knowledge workers? Let’s take a look. 

What enterprise intelligence requires 

Imagine walking your board through a set of financials and recommending specific actions. Then, in your next meeting, you walk everything back because your AI layer got the numbers wrong. 

There is no faster way to kill an AI initiative than by delivering wrong outputs. Without trust, the whole system falls apart. 

In our recent survey of 1,400 business and IT leaders, we found that while over 90% of organizations are using AI, only 28% trust it to support decision-making. As for how many organizations scaled their AI pilots into production, the number was just under 25%, suggesting a very strong correlation between trust and operationalization. 

An intelligent enterprise, then, is an organization that has trustworthy AI embedded across the business. 

At Alteryx, we say the results of any AI system must follow our VURA framework: an AI system and its outputs must be visible, understandable, repeatable, and auditable. In other words, two people need to be able to go to AI with a question and arrive at the same answer; anyone who uses AI in their workflows must be able to explain how their AI system arrived at that answer. 

Who’s responsible for operationalizing AI? 

Enterprise intelligence is about trustworthy AI deployed throughout key business processes, but who’s ultimately responsible for these AI systems and processes: IT teams or knowledge workers? 

Let’s say you want to use AI in your Sarbanes-Oxley process, e.g., your journal entries, revenue recognition, access controls, etc. Before IT can help you build a new AI workflow, IT must first understand your Sarbanes-Oxley process in great detail. Then, they have to code a tool your finance team can trust. 

It’s possible, sure. But creating this solution would take an inordinate amount of time. Then, when a new regulation comes along or you have an acquisition, the whole thing falls apart. You have to get back in line with IT to retune everything. 

Moreover, if your books don’t balance out or if you fall out of compliance, IT does not want to have that responsibility fall on them. You can see why ownership of AI systems and workflows must sit with LOB workers. They are the only ones with the expertise to ensure the veracity of AI’s outputs. They are the only ones who can successfully shape and define its logic and oversee its ongoing execution. 

Data is the fuel. Business logic is what keeps AI on course. 

Finally, there’s the question of data. We’ve all heard “bad inputs, bad outputs.” Seeing as I’m the CEO of a data analytics company, you might expect me to say that reliable data is the end-all, be-all when it comes to trustworthy AI outputs. 

And while it’s absolutely essential, it’s only the first step. 

Aggregating your enterprise data into a cloud data platform is immensely useful. All of that data becomes readily accessible. You gain a single source of truth across teams and workflows. But you can’t point your LLM at a cloud data platform and ask it to make sense of your data for a complex business process. 

Again, you need the people who understand these critical processes to guide your LLMs to interpret the right data in the right way. This is what will make your AI systems visible, understandable, repeatable, and auditable. Yes, you need clean, reliable data. But more than that, you need business logic around that data, and that can only come from your knowledge workers. 

The five pillars of enterprise intelligence 

At the highest level, enterprise intelligence rests on five core pillars: 

1. Trustworthy, transparent data 

2. Empowered business analysts 

3. Shared responsibility across the C-suite 

4. Cross-functional collaboration 

5. Leadership that evolves alongside AI 
    

Each pillar reinforces the same core idea: AI only becomes valuable when it’s grounded in reliable data, shaped by real business expertise, supported by executive ownership, and scaled across teams that can put it to work to improve their daily processes. 

Tap into the intelligence all around you 

As a business leader looking to build an intelligent enterprise, the most important questions you can ask are the ones around operationalizing AI in key business processes. What would it take for you to trust AI’s outputs? What would make AI-powered processes superior to your current ones? 

Once you have those answers, engage your LOB workers immediately. Give them ownership and autonomy. Rather than asking AI to replace them, lean into their intelligence. Let your knowledge workers use their expertise to amplify, shape, and govern AI. Their business mastery is what makes enterprise intelligence possible. 

 To learn more, visit us here. 

“You’re right,” the LLM says. “I was mistaken.” 

Have you ever read these words during an AI workflow? Nothing kills trust faster than incorrect outputs. It’s no wonder, then, that only a quarter of businesses today fully trust AI to support decision-making and forecasting. 

And yet, we know AI is business critical. Nine out of 10 businesses are using it; 64% say it’s powering innovation. 

So, how do you bridge the gap from experimentation to trustworthy deployment? How do you get verifiable, reproducible results from AI at scale? In this article, I’ll show you the framework that’s powering AI success for leading organizations. 

Why organizations still don’t trust AI 

We asked 1,400 IT and business leaders what their biggest barriers to success with AI workflows were. One in two (49%) said inaccurate or biased outputs; 38% said it was a reluctance to allow AI to make decisions without human oversight. 

Then, there was the data issue. Data readiness is an integral part of successful AI workflows. However, half of all organizations said they still faced poor quality or fragmented data. While you don’t need perfect data to start using LLMs, you absolutely need trustworthy data. 

VURA: The framework for trustworthy AI 

Closing this trust gap requires two things. First, organizations need a logic layer that connects AI systems to the people who understand the data and business best. Line-of-business teams and analysts cannot sit on the sidelines. They need to help build and validate AI workflows so the logic behind AI’s outputs reflects how the business actually operates. 

Second, AI workflows and processes should be visible, understandable, repeatable, and auditable. Together, these principles form VURA, a framework we developed to help organizations build and scale trustworthy AI systems. These guidelines will help build trust in your data and your AI’s outputs. You’ll need both if you want your business to build enterprise intelligence. What follows are the four pillars of VURA.  

• Visible 

Visibility is transparency. Your AI workflows shouldn’t be a black box regarding the data used and the logic applied. Every employee using AI tools should be able to answer two questions: “Where did this answer come from?” and “How did we draw that conclusion?” Otherwise, employees may be working from incorrect information. They could give your customers faulty intel or make important decisions with serious downstream effects. 

If those answers are still unclear, you may need to tighten your governance or reconsider whether your current AI and data solutions are working. Visibility becomes especially important when AI is used across teams. 

• Understandable 

It can almost feel like science fiction when tools like ChatGPT or Gemini take the most complicated or vague of prompts, parse through them, and give you an intelligent, thoughtful answer. 

However, this low threshold for asking and answering virtually any question in natural language isn’t an excuse for glossing over business fundamentals. Your AI systems must be able to explain the logic behind their outputs to even non-technical business users, and your business experts must be able to validate those outputs. 

• Repeatable 

Repeatable means that with the same AI tools, data, prompts, and business logic, AI will give you the same answer every time. Two people should be able to go to AI with the same question and arrive at the same answer. If an AI system or workflow gives you an excellent answer followed by one that’s clearly wrong, it’s not ready for operationalization. You can’t trust it. 

Repeatability also requires documentation. When teams identify prompts or processes that help produce reliable outcomes, those should be recorded and shared. 

• Auditable 

An auditable AI process means you can see what happened. There’s a trail. If there’s an answer or report that seems off, you should be able to identify who owns the workflow, what data and prompts were used, what logic the system followed, and where human judgment and oversight were involved. Auditability is a check and balance for both your AI systems and the human engineers working behind the scenes. 

Start building trustworthy AI systems today 

AI can only deliver scalable business value when it’s grounded in trustworthy data and business logic. To operationalize these systems, you’ll have to ensure your AI workflows are visible, understandable, repeatable, and auditable. 

Alteryx is the transformation and business logic layer that helps you move AI from experimental pilots to trustworthy production. It connects to data wherever it lives, helps business users apply their expertise to AI-powered workflows, and instills the guardrails needed for both your data and your AI systems. 

With Alteryx, the people closest to the business can shape how data is prepared and applied, while IT gains the governance and auditability required for enterprise use. That’s how AI outcomes become trustworthy. That’s how enterprise intelligence is built. 

 To learn more, visit us here. 

If you’re a senior analyst, you’ve probably faced a dataset that used to open in seconds but now takes minutes. Or maybe you’re up against a formula that worked fine last quarter, but now shows an error because someone renamed a tab in a file three layers upstream. Ever spent an afternoon figuring out whose numbers are right when colleagues send back a few different “final” versions of the same report? None of that is a personal failure, but it is a sign that the volume and complexity of your work has outgrown what a spreadsheet was built to handle. 

The cost is more than just your time and inconvenience. When reporting slows down, multiple versions of a number circulate before anyone catches it, or one person’s spreadsheet logic is the only process your team has for something that matters, that’s a risk to the business. 

Plenty of solid analysis still belongs in a spreadsheet, but as your data and stakeholders grow, the balance between preparing data and analyzing it changes. If prep now takes more of your week than analysis does, the tool has become the bottleneck — not you. 

Watch for concrete signs you’ve hit that ceiling, what a platform “built for scale” needs to do differently, and how to decide whether it’s time to move. 

When spreadsheets stop being enough for your data analysis 

Every spreadsheet has a hard ceiling, and it’s lower than people might expect. Microsoft’s own published specifications cap every worksheet at 1,048,576 rows by 16,384 columns, regardless of your computer’s memory or Excel version. Once a dataset crosses that line, rows don’t get flagged — they simply don’t load, and it’s easy to miss. 

The bigger risk is accuracy. A 2024 literature review published in Frontiers of Computer Science, covering more than 30 years of spreadsheet research, found that 94% of spreadsheets used in business decision-making contain errors that create real risk of financial losses and operational mistakes. Most analysts already understand that the more a spreadsheet grows past its original design, the harder it gets to trust every formula in it. 

Alteryx’s own research backs this up from the analyst’s side of the desk. The 2025 State of Data Analysts in the Age of AI report, a global survey of 1,400 data analysts, found that 76% still rely on spreadsheets for data preparation, even as AI tools reshape the rest of their workflow. Manual prep work isn’t a habit analysts choose, but it’s still the default because nothing else is in place yet. 

Spreadsheets are ultimately designed for individual calculation, not for shared, repeatable, large-scale analysis. Asking them to do that job is where the cracks start to form, and when you need to start thinking of an alternative. 

What “built for scale” means 

“Scale” gets used loosely in analytics marketing, so it’s worth being specific about what a platform needs to do differently than a spreadsheet. It comes down to four tasks: 

• Connect to data where it already lives 

A spreadsheet only knows what you paste into it, which means every report starts with an export, a download, or a copy-paste job that’s already slightly out of date by the time it’s finished. Platforms that support scale should be designed to connect, transform, and prepare AI-ready data by connecting natively to a broad range of enterprise applications, databases, and cloud platforms. This way data can be pulled in and refreshed rather than manually re-exported every reporting cycle. For an analyst, that means less time reconciling which export is current and more time on the analysis itself. 

• Prepare and blend without rebuilding from scratch 

Scalable platforms should also give analysts a drag-and-drop canvas for cleansing, blending, and reshaping data from multiple sources, with code-friendly options like Python and SQL available for analysts who want them. It should allow for logic to be built once and held to a standard we call VURA: visible, understandable, repeatable, and auditable. Analysts shouldn’t have to deal with a chain of formulas that only one person fully understands, and that visibility matters as much as the automation. When you build a workflow as a series of documented steps, colleagues can review, troubleshoot, or take over in a way a dense formula chain rarely allows. 

• Automate the workflow, not just the calculation 

The real definition of scale for an analyst is a process that runs without being rebuilt by hand. An essential component of that is workflow automation and orchestration so analysts can schedule and reuse any workflow they build. 

• Report without abandoning familiar formats 

Leaving spreadsheets behind for analysis doesn’t mean stakeholders lose the outputs they’re used to. Reporting tools can generate tables, charts, and formatted outputs in PDF, HTML, or Excel, closing the loop between analysis and the people who need to read the result. 

Spreadsheets vs. a scale-ready analytics platform 

The differences between spreadsheets and analytics platforms are less about features and more about the needs that develop as your data and your team grow. 

Matching the platform to where your team is right now 

“Scale” doesn’t mean the same thing for a 5-person team tracking budgets as it does for an enterprise running hundreds of scheduled workflows. It’s important to consider your team’s specific size and overall org structure before you shortlist any options. 

If your team is still primarily working out of Excel or CSV files and wants to reduce manual, repetitive spreadsheet work, there are several platforms built just for these types of applications. Alteryx One Starter Edition, as an example, is built specifically for that transition — code-free data prep accessible from a browser, aimed at teams getting started rather than running complex automation. 

You don’t need to know your exact tier or platform before you start a conversation with your team, but the conversation can go faster when you can describe your situation in terms of how many people touch the data, how often it needs to run, and who needs to see the output (rather than starting from a feature list). 

Governance doesn’t disappear with spreadsheets 

It’s tempting to think that moving off spreadsheets automatically solves governance, but that just changes what governance looks like. TechTarget’s coverage of data and analytics governance requirements notes that organizations should look for scalable, modular platforms that can adapt as needs change, rather than assuming governance is solved by the platform switch alone. 

It’s important to investigate whether or not a platform supports this with governance and administration capabilities such as role-based access controls, audit logs, and version history. They’re built to give IT the oversight it needs while giving analysts the flexibility to build and run their own workflows. 

A quick readiness check 

Before you bring a platform comparison to your team or your leadership, it helps to be specific about what’s driving the need. What follows are a few questions worth answering honestly: 

• Are you regularly working with datasets that approach or exceed Excel’s row limit, or that make Excel noticeably slow to open and calculate? Slow-loading files and truncated imports are usually the first visible sign, not the first real cause. 

• How much of your week goes to gathering and cleaning data by hand, instead of analyzing it? If prep consistently outweighs analysis, that ratio is the problem — not a single unwieldy file. 

• If you left tomorrow, could someone else pick up your spreadsheet-based process without you walking them through it? A process that exists only in one person’s head is a significant business continuity risk. 

• Do stakeholders currently receive conflicting versions of the same report because multiple people are editing copies independently? That’s a flag that the workflow needs a single source of truth. 

• Does your organization need an audit trail for how a number was calculated, not just what the number is? Regulated or audited environments tend to outgrow spreadsheet-based tracking quickly. 

If you answered yes to two or more of these, this is a reasonable signal that it’s worth having a conversation about moving beyond spreadsheets. 

For a deeper dive on how to build the internal case, check out this guide from Alteryx on evaluating workflow automation tools for analytics teams and another breakdown of evaluating business intelligence tools that scale without increasing complexity. 

See it on your own data 

The fastest way to know whether a platform fits your workflow is to run your own data through it rather than a demo dataset. You can start a free trial of Alteryx One to test connectivity, data prep, and workflow automation against the kind of analysis you do every week. 

[CTA]   

 To learn more, visit us here. 

The old way of creating reports is almost cliché, but only because it remains so pervasive. 

It’s a familiar scene: A teammate pings you at 4:57 pm asking for a last-minute report. The data and business logic you need live across 10 spreadsheets, in five Microsoft Teams threads, and in an email from two months ago that you can’t seem to find. 

But that was the old way. What happens when you use AI for the same situation? 

Let’s find out. 

What working with AI often looks like 

Your stakeholder pings you, asking for a report based on a massive tax reconciliation spreadsheet. 

This spreadsheet is a beast, chock-full of tabs, formulas, and data that’s been copied and pasted from several enterprise data sources. 

“Sorry for the last-minute ask,” they say, “but can you just throw AI at this?” 

You go to your LLM prompt library, select a robust prompt, and input it into Claude, along with the spreadsheet. 

Four seconds later, you get over 1,700 lines of Python code. Somewhere inside, there appear to be all the data transformations, calculations, and visualizations you need to build your report. 

But there’s a hiccup. 

Your stakeholder remembers that your tax jurisdictions change four times a year and wants to ensure that you can make any necessary changes. 

Sure, you think, that shouldn’t be a problem. I can probably find that line of code somewhere … 

Also, there are three subsidiaries. Someone else handles those taxes, so you’ll need to filter those out. 

Finally, your stakeholder remembers that your CFO will want to sign off on this and that your auditor is coming tomorrow. They’ll both want to see the logic behind your report. 

Suddenly, parsing through and validating hundreds of lines of AI-generated code seems far more difficult and time-consuming than you’d hoped. 

VURA: The missing piece 

While AI can bring incredible levels of automation and speed, those are only force multipliers when directed strategically. 

“I can get an infinite number of PowerPoints out of the AI systems if I want that,” Ethan Mollick recently told me during our executive exchange. “It may even be good content, but if it doesn’t serve the purpose you need it to, the productivity gains become a trap.” 

Ethan’s point is that more isn’t always better; bringing four hundred PowerPoints to a sales call won’t help you close a deal. Likewise, instantly generating hundreds of lines of Python is unlikely to help your CFO feel confident in your AI’s vibe-coded report. 

For an AI workflow to be trusted, it has to be Visible, Understandable, Repeatable, and Auditable, or VURA. You need to know what’s happening at every step of the process: where the inputs came from, how business logic was applied, and whether the outputs were correct. 

So, how can you accomplish this? 

The transformation and business logic layer 

Let’s try a different AI-powered workflow. Same situation and model. Only this time, we’re going to add a visual transformation and business logic layer. 

First, we go into Claude and type up a prompt, but instead of Python, we ask for an Alteryx workflow. 

We open our workflow in Alteryx, and instead of hundreds of lines of AI-generated code, we see a visual canvas showing the entire tax reconciliation process. 

It’s still an AI-generated workflow, but now, anyone in the organization can inspect it. They can see what data was used. Your analysts and domain experts can validate the logic. And you can add governance and repeat the process. 

Suddenly, AI-generated workflows become far more trustworthy and scalable, giving you a foundation for enterprise intelligence. 

The future of enterprise AI workflows 

AI tools that can’t adapt when the business changes have short shelf lives, and rebuilding from scratch constantly drains tokens, time, and energy. Endless iterations create endless chances for inconsistencies and errors. 

With a visual business logic layer, the people who know your business best — your business analysts, sales professionals, finance team, and more — can apply their expertise to your AI workflows and validate its outputs. They can see what’s happening at every step of your AI workflows so that every process is Visible, Understandable, Repeatable, and Auditable. 

Speed and reliability are no longer mutually exclusive. Now, you can bring AI’s power and your business experts together to create something fast and reliable, the intelligent solution you need to create scalable business value. 

Learn more: See how Alteryx One can help you build AI workflows your business can trust. Or, watch a live workflow demo to see Alteryx in Action. 

 To learn more, visit us here. 

There’s a version of this story you’ve probably lived. The close is approaching, someone pulls a number from a file that hasn’t been updated, and an hour later you’re untangling a discrepancy that shouldn’t exist. The fix takes 20 minutes. Finding the source took two days. 

This is the part where most articles would tell you to ‘ditch the spreadsheet.’ But that’s not the real problem, and honestly, it’s a little insulting to the work you’ve actually done. 

Your spreadsheet isn’t the issue. The process built around it is. 

The logic is real. The medium is the limitation. 

Think about what lives in the workbooks your team maintains. How revenue maps to each entity. What counts as a valid reconciling item. The variance threshold that triggers a review. The intercompany elimination logic that took a year to get right. None of that is just data — it’s institutional knowledge. It’s business logic, and it belongs to finance. 

The problem is that spreadsheets were never designed to share that logic, version it, or let anything else use it reliably. When a process lives in a file on someone’s desktop, it’s invisible to every system downstream. You can’t hand it off cleanly. You can’t audit it without opening every tab. And when the person who built it leaves, a piece of your operations leaves with them. 

Why this matters more now than it did two years ago 

A lot of finance teams are under pressure to adopt AI — for close acceleration, anomaly detection, forecast assistance, narrative reporting. The pitch is compelling. The results, so far, have been uneven. 

Here’s why, and this part is specific to finance: AI can process data at scale and surface patterns quickly, but it cannot enforce your cost allocation methodology, validate your intercompany eliminations, or know what your organization has decided counts as an exception. 

For a tax team, that means it can’t apply your jurisdiction mappings reliably. For an audit team, it can’t reproduce your evidence logic. For FP&A, it can’t honor the constraint assumptions built into your planning model. That requires logic that’s documented, governed, and repeatable — and if that logic is locked in spreadsheets AI can’t see, AI can’t apply it. So it guesses. In finance, a confident guess on a tax provision or a consolidation rule isn’t a minor error. It’s a liability. 

The teams getting real value from AI are the ones who built the foundation first and then let AI work on top of it. 

The question most teams haven’t answered yet 

The shift that helps isn’t about which tool you use but where your process logic lives and who can access it. When your reconciliation rules, transformation logic, and validation criteria exist in governed workflows rather than locked files, the close gets more consistent, errors surface earlier, and handoffs get simpler. 

But getting from here to there raises a real question most teams are still working through: what does that transition look like for a tax team, an audit function, or an FP&A group that has years of logic built up in Excel? What moves first, what stays, and what does a week of progress realistically look like? 

That’s where the specifics matter — and that’s what we’ll get into next. 

 To learn more, visit us here. 

Most finance leaders at large organizations have made the right investments. A modern ERP, cloud data platforms, planning tools, and more. And now, increasingly, AI — for forecasting support, anomaly detection, close acceleration, and reporting at scale. 

The technology stack looks right. But when the board starts asking about results, the returns are harder to point to than the investments were. 

What your ERP was built to do — and what it wasn’t 

Your ERP is excellent at what it was designed for: capturing transactions, enforcing accounting standards, managing the chart of accounts. It is the system of record, and it performs that job well. 

But it doesn’t encode how your organization has decided to handle intercompany eliminations across a complex entity structure. It doesn’t carry your FP&A team’s cost allocation methodology, refined over three budget cycles. It doesn’t know what variance threshold triggers a controller review versus a VP escalation, or how your tax team has mapped jurisdictions for Pillar Two. That logic — specific, documented, organization-defined — isn’t in your ERP. It’s not in your data warehouse either. 

For most finance organizations, it lives in spreadsheets. Sometimes in the heads of the people who built them. 

Where AI runs into trouble in finance 

There’s a finding that gets cited a lot in finance AI conversations: research from MIT found that 95% of organizations are seeing no measurable return on their gen AI investments. Bain & Company looked at the same picture and reached a different conclusion for finance specifically. The fastest payback from AI in finance comes from embedding it in workflows — not from running pilots. The distinction matters because it explains why so many finance AI efforts stall after the proof of concept. 

AI can process data at speed and surface patterns across large datasets. What it cannot do is infer your business logic from raw inputs. Without that context, AI outputs in finance look confident but aren’t defensible — and in a function where auditability is a baseline requirement, that gap is not a minor limitation. It validates that trustworthy AI is critical for scaling workflows and AI pilots. 

Our own survey of 1,400 IT and business leaders asked what their biggest barriers to success with AI workflows were. One in two (49%) said inaccurate or biased outputs. Further, 38% said it was a reluctance to allow AI to make decisions without human oversight. While you don’t need perfect data to start using LLMs, you absolutely need trustworthy data. 

The layer that’s actually missing 

The gap between your ERP and your AI ambitions isn’t a data gap. It’s a business logic gap — the layer where your organization’s specific rules, methodologies, and decision criteria live, and where AI needs to operate to produce outputs you can stand behind. 

When that layer is built correctly — logic documented, workflows repeatable, outputs traceable — AI has validated, structured inputs rather than raw data it has to interpret. Outputs can be explained to auditors and to the board. And the sequencing question resolves itself: getting the process right is how you adopt AI. 

What it takes to build that layer 

Closing the gap takes more than a mandate to “use AI responsibly.” It takes three specific things, built and owned inside finance rather than handed off to IT. 

• A purpose-built data asset for each process. Not another warehouse but a narrow, well-defined data set scoped to one process that reflects how your team measures it, not just what your ERP happens to store. 

• Encoded logic, not tribal knowledge. The allocation methodology or the variance threshold that triggers escalation — built into a repeatable workflow instead of a senior analyst’s spreadsheet. The shift is building it once; in a form AI can use. 

• A way to update it when the business changes. Comp plans get revised, tax jurisdictions shift, and the chart of accounts gets restructured after an acquisition. Logic that can only be changed by submitting a ticket to IT will be stale before it’s deployed — the people who own the process need to be the ones who can adjust the rule. 

None of this requires waiting for a perfect architecture. The highest-value starting point is whatever process has your analysts fielding the same question, the same way, every single cycle. Encode that one workflow first, connect it to the AI tools your team is already using, and the logic compounds from there: the same governed calculation that answers one controller’s question can feed the scenario model that runs your next planning cycle. 

 To learn more, visit us here. 

Every CFO I talk to right now is under some version of the same pressure: the board wants AI, the business wants faster answers, and the finance team is often still reconciling spreadsheets. The promise of AI in finance is real. But so is the gap between that promise and what most organizations are able to deliver. 

I believe finance leaders need to be asking not simply, “How do we use AI?” but “What would make our data trustworthy enough for AI?” 

That distinction matters. AI-ready finance data is intentionally shaped for a specific business outcome, so we can trust what AI produces from it. In finance terms, it’s the difference between having transactions and being able to defend the numbers. 

Finance data is uniquely messy, and important 

Finance data is messy for rational reasons. We pull from multiple systems — ERP, CRM, payroll, procurement, planning tools, banks, data warehouses, and yes, still spreadsheets. 

We live through reorgs, acquisitions, new products, and chart of accounts changes. And when the business cannot wait, we create manual workarounds to keep moving. 

That complexity is the context in which we’re now being asked to use AI. It’s no wonder that so many initiatives stall. 

The non-negotiables of AI-ready finance data 

When Alteryx talks about AI-ready data, I translate it into a few non-negotiables. For finance leaders, this is where the concept becomes practical. 

• Purpose-built, not “all the data” – AI-ready data should be scoped to the decision or workflow at hand. If I am building a cash forecast, I do not need every field from every ledger table. 

• Clean and standardized – AI does not politely ignore bad inputs; it often amplifies them. That means your data needs to be deduplicated, standardized across dates, currencies, and units, and mapped to consistent hierarchies. 

• Combined across sources, with business context – Finance work is inherently cross-source. AI-ready data is joined and enriched so the dataset reflects business reality, not just system silos. 

• Traceable and transparent – This is where finance leaders should push harder than anyone else. AI-ready data has lineage. It is auditable and explainable, not just at the output layer, but in the data shaping behind it. 

• Governed and controlled – AI readiness is about data risk management as much as data quality. AI-ready data should live inside a governed process, not a series of hero spreadsheets and copy-paste steps. 

• Maintainable as the business changes – This is one of the hidden killers of AI initiatives. A one-time cleaned dataset is not AI-ready if it breaks the minute a new subsidiary is added, a cost center structure changes, or a revenue stream appears. AI-ready data has to be built through workflows that can be updated and re-run reliably, not through one-off cleanups. 

Where AI-ready data creates value in finance 

This is where the concept becomes real. AI-ready data is the difference between value and noise in some of finance’s most important workflows, including: 

• Close acceleration: When trial balance data, mappings, intercompany logic, and exception rules are standardized, finance can generate more dependable variance flags and automate more of the financial close and reconciliation process. 

• Cash forecasting: Better-connected bank data, AR/AP, billing schedules, and seasonality drivers make forecasts less likely to be derailed by missing or misclassified transactions. 

• Anomaly and fraud detection: Clean, aligned vendor master data, payment runs, approval chains, and PO matching help teams reduce false positives and investigate issues faster. 

• Revenue quality and leakage: When contracts, invoices, usage, CRM data, and credit logic are brought together in a way that reflects the actual economics of the business, AI can help surface patterns that matter. 

• Narrative reporting: Grounding LLMs in curated, reconciled variance drivers and approved definitions allows teams to draft commentary responsibly within clear guardrails. 

Filling the AI data readiness gap 

I’ve found that in most organizations, there’s a constant friction point between data engineering and finance. Engineering understands the architecture, pipelines, and platforms. Finance understands the business context and logic — how revenue is recognized, how allocations work, where the exceptions hide. 

The handoff between those groups is often slow and messy. Analysts build fragile workarounds. Engineering teams inherit backlogs of finance requests that are actually business critical. 

What resonates with me about Alteryx is that it sits in that gap. It enables finance and business analysts to build repeatable data workflows for extracting, cleaning, joining, enriching, and shaping data for specific finance use cases. 

It emphasizes transparency and traceability, and it supports a model where IT can govern, and finance can execute. Just as importantly, it helps organizations turn their existing ERP, warehouse, and cloud investments into outputs that are actually usable for analytics, automation, and AI. 

How to get started 

If you want to make progress without boiling the ocean, my practical advice is simple: start small and start right. 

• Pick one workflow that is high pain and highly repeatable (recs, allocations, forecasting inputs, reporting packs). 

• Define what “trusted” means: the reconciliation rules, thresholds, approvals, and audit trail you need. 

• Build the AI-ready dataset first cleaned, joined, governed, and repeatable. 

• Then add AI where it makes sense (classification, summarization, exception explanation) inside the workflow, not as a free-floating tool. 

My bottom line is this: AI-ready data is an operating standard. It is how we scale AI without scaling risk. And for CFOs, that should be the real objective, not chasing the latest tool, but building the trusted data foundation that makes smarter automation, better decisions, and more resilient finance performance possible. 

To learn more, visit us here.  

Say your reconciliation tool flags a break between two ledgers, and now there’s a number that needs an explanation. The AI-generated summary says the mismatch is a timing difference, transaction posted late on one side. Reasonable. You move on. 

Then your controller asks which transaction, on which date, and why it posted late instead of on time. And now you’re not looking at an explanation anymore. You’re looking at a sentence that sounded like one. 

The four part test behind every AI answer 

That gap is the same thing the last piece here named: can you explain where the answer came from, and would the explanation survive someone pulling on it? Most practitioners have been running that check for years, on spreadsheets, on junior staff’s work, on their own numbers before a review meeting. AI just hands you answers that sound complete far more often now, and faster than the checking can keep pace with. 

The test itself breaks into a few plain questions, and it’s worth naming them because most people run all four without thinking about them separately: 

• Visible: Can you see where the number came from? 

• Understandable: Do you actually understand the logic that produced it, or just the sentence describing it? 

• Repeatable: Would the same input produce the same answer next time, or is this a one-off? 

• Auditable: Could someone other than you retrace it if they had to? 

Four different failure modes, and an AI-generated explanation can fail any one of them while still reading like a good answer. 

Why the gap is widening faster than the checking 

The reconciliation example holds up because it’s ordinary. Nobody’s arguing AI shouldn’t touch reconciliation work. Matching balances, drafting a first-pass explanation for a variance, flagging what needs a human look — that’s real time back. The problem isn’t the AI doing that work. It’s that the logic behind “this is a timing difference” has to already be defined somewhere the AI can point to. If it isn’t, the model is pattern-matching its way to something plausible, and plausible is not the same as traceable. 

Deloitte’s Finance Trends 2026 survey of over 1,300 finance leaders found 63% have fully deployed AI in their departments, with only 21% reporting clear, measurable ROI. That’s a broader adoption figure than an explanation-quality study, but the gap it points to lines up with the reconciliation example: plenty of AI running, not much of it yet standing up to scrutiny. 

Where the logic has to live 

Closing that gap starts with what the AI is drawing from in the first place, before it ever produces an answer. Every explanation an AI generates borrows its logic from somewhere: a threshold for what counts as material, a rule for what makes something a timing difference, an assumption about which system wins when two ledgers disagree. When that logic lives only as a pattern the model has inferred from past examples, the explanation is a guess dressed in confident language. When it’s defined, owned, and applied the same way every time, the AI has something real to summarize. 

Finance has kept this kind of logic for as long as the job has existed, often in a spreadsheet somebody built years ago that everybody trusts without fully remembering why it works. That logic hasn’t changed. Who can now touch it, and how fast, has, and that means the definitions underneath it need to hold up to more traffic than they ever have before. 

Get that part right, and the reconciliation example flips. The AI’s explanation becomes a summary of logic that was already defined, applied consistently, and traceable back to where it came from — the version that survives the follow-up question. 

See trusted AI workflows in action 

If you want to see what that looks like in a live workflow rather than in the abstract, Alteryx’s AI-Ready Starter Kits are pre-built Alteryx workflows and synthetic datasets designed to demonstrate how Alteryx can be applied to specific business use cases. They prepare and structure data to produce analysis-ready outputs, which can be extended using external AI tools. 

The Reconciliation Exception Resolution AI-Ready Starter Kit shows the pattern from this piece in practice: exceptions routed to an owner, prioritized by materiality, and documented consistently enough that the resolution holds up when someone asks how you got there. 

To learn more, visit us here.

There’s a specific moment every finance leader knows. A number is about to leave the building — headed for the board deck, the earnings call, or the audit committee — and right before it goes, you pause. You want to know where it came from, and you want to know it will still make sense if someone asks how you got it. That pause happens no matter what produced the number. 

That instinct shows up in the data too. In a Gartner survey of more than 200 CFOs, confidence across finance leaders’ top 2026 priorities averaged around 63%, while confidence in driving enterprise AI impact came in at just 36%. 

Leaders aren’t lacking confidence broadly. They’re confident about cost discipline and growth investment. The drop is specific to AI. It’s a broader measure than any single number leaving the building, but it points in the same direction: AI is the one place finance leaders can’t yet count on the confidence that usually comes easily. 

The four things every number has to pass 

That pause is a fast version of a test. Before you’d trust a number, you check four things: 

• Where it came from 

• Whether you could explain it simply 

• Whether it would come out the same way twice 

• Whether you could trace it back through the data if someone asked 

Most finance leaders have never written that test down. They’ve never had much reason to, because until now, the systems producing their numbers usually held up well enough that the check rarely turned into a real problem. 

AI doesn’t automatically pass that test. It can produce a plausible answer to almost anything, including things it has no real basis for knowing, and the answer looks the same whether the logic underneath is solid or made up. That’s the real source of the confidence gap. 

Leaders don’t doubt that AI can help. They doubt whether they could explain the answer if someone pushed back on it. The four things finance leaders already check for come down to four words: visible, understandable, repeatable, and auditable, or VURA. Those words succinctly describe what leaders were already checking for instinctually. 

Who owns the logic underneath 

Naming the test doesn’t resolve where it gets applied, though. That takes a harder answer about where the logic itself lives. Deterministic logic is defined by finance, not inferred by AI. A model can draft a variance commentary, summarize a forecast, or flag an anomaly worth a second look. 

It should never be the one deciding what counts as an exception, how revenue gets recognized, or which threshold triggers an escalation. Those are calls finance makes, and AI’s job is to work within them, explain them, and apply them consistently, not to invent them when it doesn’t have enough to go on. 

That distinction is where most AI disappointment in finance actually starts. The model usually isn’t failing at what it’s good at. The failure happens earlier: nobody defined the logic it needed, so it guessed, and it delivered that guess with exactly the same confidence it would use for a right answer. Looking at the output alone, you can’t tell the difference. 

That’s exactly what the four-question test catches. Ask where the number came from, whether you can explain it, whether it repeats, and whether you can trace it back to the data, and you’ll find out fast whether the AI applied logic finance defined or made something up that looks close enough. 

Building the standard into the workflow 

This is an architecture decision as much as a governance one. The four questions get easy answers when there’s a layer between raw enterprise data and the AI consuming it, one that prepares the data, holds the logic finance owns, and keeps every output traceable back to both. 

That’s the role Alteryx plays. It doesn’t compete with the model doing the reasoning, and it doesn’t replace the ERP or EPM system the data lives in. It’s the business logic layer that makes sure what reaches the model is something finance already stands behind, so the model’s output can be too. 

Build that in, and the pause before the number goes out changes what it’s doing. Instead of hoping the number will hold up, you can check that it does, every time, because the answers to those four questions are already built into how the workflow works, not something you have to reconstruct from memory. 

If you’re looking for a concrete way to see what that looks like on a real workflow, take a look at our AI-Ready Starter Kits: pre-built Alteryx workflows and synthetic datasets designed to demonstrate how Alteryx can be applied to specific business use cases. They prepare and structure data to produce analysis-ready outputs, which you can then extend using external AI tools such as large language models. 

Understanding why finance leaders hesitate to trust AI is only the first step. The next is building the governed foundation that gives AI reliable business logic to work from. 

Learn more in Building Finance AI You Can Trust, where you’ll explore the principles and practical steps behind AI-ready finance workflows. 

 To learn more, visit us here. 

If you work in finance, you’ve probably been handed an AI tool in the last year or so. Maybe a copilot in your spreadsheet, maybe something bolted onto the close, maybe a chatbot that promised to answer any question about the numbers. And maybe, if you’re being honest, it hasn’t changed your Tuesday very much. 

You’re not doing it wrong. The tool isn’t broken. What’s missing is the part nobody put on the slide: AI is only as good as the work it’s standing on, and most of the time, the work underneath it is a mess. 

Confident AI answers you can’t trust 

Here’s a familiar scene. Someone asks the AI assistant a reasonable question — “why did margin move in the East region last month?” — and it produces an answer that sounds great. Confident. Well-organized. Possibly even formatted with little bullet points. The only problem is that you have no idea whether it’s right, because you don’t know which data it pulled, whether it used the current cost allocation method, or whether it quietly grabbed last fiscal year’s calendar. 

So you do what any sensible finance person does. You check it by hand. Which means the AI didn’t save you the work. It added a step. 

This is the quiet truth about why so much finance AI stalls. It’s not that the models can’t reason. It’s that they’re reasoning over data that was never cleaned, rules that were never written down, and logic that lives in one analyst’s head and three tabs of a workbook nobody else can open. AI didn’t create that gap. It just made it impossible to ignore, because now something is making decisions on top of it. 

McKinsey looked at how finance teams are actually using gen AI and found a useful counterexample. Across the handful of finance functions where they saw AI adopted in earnest, professionals were spending 20 to 30% less time crunching data — and putting that time back into the analysis their job is supposed to be about. In one case, a global consumer goods company pointed a gen AI assistant at budget-variance work and saw roughly 30% of that manual effort disappear. That’s a real result. But notice what made it real: it was pointed at a specific, repeatable task, working from data the team had already organized around a shared definition of what “variance” even means. The AI didn’t figure that out on its own. The team handed it a problem that was ready to be automated. 

What separates the workflows that pay off 

The finance work where AI delivers tends to share a few traits. It’s bounded — a clear start and end, not “answer anything about the business.” It’s repeatable, the same shape every month. And it’s tied to something that matters: cash, margin, risk, a number someone downstream is going to act on. 

That’s the easy part to say. The harder part is what has to be true underneath. For AI to work on one of those tasks, the data feeding it has to be prepared and validated before the model ever sees it. The rules — what counts, what gets excluded, how things roll up — have to be defined by your team and applied consistently, not guessed at by a model that’s never read your policy manual. And when the output lands, you have to be able to trace it back: which numbers, which logic, who signed off. In finance, that traceability isn’t a nice-to-have. It’s the difference between an answer you can put in front of an auditor and one you can only put in front of people who won’t ask hard questions. 

Think about the difference between two versions of the same workflow. In one, the AI reaches into raw data, applies whatever it infers the rules to be, and gives you a number. In the other, the data gets cleaned and structured first, your team’s actual business logic gets applied to it, and only then does AI work on top of a foundation it can stand on. The first one feels faster right up until something’s wrong and you can’t tell why. The second one is the one you can defend in a meeting. 

That’s really the test worth applying to any AI effort on your desk: can you explain where the answer came from, and would the explanation survive someone pulling on it? If yes, you’ve got something worth scaling. If no, more AI won’t fix it — it’ll just produce wrong answers more quickly. 

Where this leaves you on Monday 

None of this means starting over. The business logic your team has built — the spreadsheets, the rules, the institutional memory of how things actually work here — is the valuable part. The goal isn’t to throw it out for an AI that doesn’t know any of it. It’s to get that logic into a form that’s governed and repeatable, so AI can finally do something useful with it. 

The most practical move is also the least dramatic. Pick one workflow. Not the whole close, not “AI across finance.” One bounded, repeatable, annoying task you’d happily never do by hand again — invoice matching, a recurring variance pull, a report you rebuild every month. Get the data right for that one thing, write the rules down, and put AI to work on top of it. When it works, you’ll have something real: a workflow you can trust, and a clear sense of what the second one should be. 

Two traps worth naming, because they’re the ones McKinsey watched teams fall into. One is waiting for perfect data before you do anything — you’ll be waiting forever, and the team next door will have shipped three workflows by the time your data is pristine. The other is the opposite mistake: automating a process that’s still a tangle of exceptions and one-offs. Drop AI on top of a fragmented workflow and it doesn’t simplify it, it just adds a confident-sounding layer to the mess. The move is in between: standardize the one thing first, then automate it. 

If you want a low-stakes way to see what that looks like before you commit, our AI-Ready Starter Kits are built for exactly this. AI-Ready Starter Kits are pre-built Alteryx workflows and synthetic datasets designed to demonstrate how Alteryx can be applied to specific business use cases. They prepare and structure data to produce analysis-ready outputs, which can be extended using external AI tools such as large language models (LLMs). They won’t run your finance function — that’s not what they’re for. But they make the shape of a workflow that actually pays off tangible enough to copy. 

The AI on your desk isn’t the problem. The work underneath it is. Fix that for one thing, and you’ll stop wondering why AI hasn’t paid off — because it finally will. 

Search our full AI-Ready Starter Kit library to find finance use cases fit for you and your team. 

To learn more, visit us here.

A few months ago, during a break at an industry conference, I ended up in one of those side conversations that I kept thinking about long after the conference ended. I was talking with several sales leaders about how AI was beginning to reshape the way they worked — from the CRM and business intelligence tools they relied on every day to the broader enterprise applications that supported their sales process. None of them asked for another dashboard. They didn’t want another tab open in the CRM. They wanted to know, in plain language, which accounts needed attention before the next call. I had spent years leading initiatives that built the reporting infrastructure to answer exactly that question — just spread across three or four different screens. That was the moment I realized the question had changed. Sales teams no longer wanted another place to look. They wanted an answer.

The question no dashboard could answer

For most of my career in enterprise business intelligence, my role has gone well beyond translation. I have led initiatives that brought together data from across the business, helped design the enterprise data architecture underneath executive reporting and worked with sales, finance and operations leaders to turn a business question into a report, a KPI or a dashboard living inside one enterprise application or another. The unspoken assumption behind almost every dashboard I helped build was that the user would go find it, open it, read it correctly and act on it, in the middle of an already full day.

During planning sessions over the past couple of years, I started noticing something I had never heard five years earlier. It was not that the dashboards were wrong. Clicking through three separate systems to prepare for one client call had become a tax nobody had time to pay, and the teams I supported started raising it in one-on-ones and quarterly reviews. At first, I read that feedback as an adoption problem, something a better onboarding session or a cleaner interface could fix. I no longer believe that.

I remember sitting with one of our sales leaders while we walked through his workflow before an important client meeting. We opened the CRM, then a separate reporting application, then a pricing tool, then a forecasting dashboard. Halfway through, he looked at me and asked, “Why can’t one system just tell me what I need to know?” I did not have a good answer for him that day. I have been building toward one ever since, and that single question has reframed how I think about every enterprise application my team touches.

From navigating systems to asking questions

I have spent most of my career supporting sales and partner operations, so I saw this shift first inside sales teams. One request I started hearing repeatedly surprised me. Representatives no longer wanted a better report. They wanted a single conversational entry point that could pull opportunity data, check it against pricing or forecasting numbers, pull in something from an HR system if the deal touched staffing and hand back a recommendation instead of a raw export.

Months later, when Gartner published its prediction that 40% of enterprise applications would carry task-specific AI agents by the end of 2026, up from under 5% a year earlier, it did not surprise me. I had already started seeing exactly that inside the sales organizations I support, well before I saw the number attached to it.

What matters here, and what I have watched happen firsthand, is that the underlying systems of record are not disappearing. The CRM still holds the opportunity data. The HCM platform still owns workforce records. What is changing is the layer sitting on top of the business systems people use every day. CIO’s Bill Doerrfeld’s own reporting on agentic AI backs this up, noting that agents are already updating CRM fields automatically from client interactions, with agent-enriched deals moving through pipeline stages meaningfully faster than the rest. I have watched a version of that same pattern play out with the teams I support. The value is not a flashier report. It is closing the gap between having a question and getting an answer people actually trust.

That word, trust, is where my earlier work on data foundations and this shift toward conversational interfaces meet. A layer that sits across a sales technology stack is only as good as the data underneath it, and a system that can now act on a recommendation, not just display one, raises the stakes on getting that foundation right. I have written before about how AI models fail when the data feeding them was never properly governed. A conversational layer spanning multiple business systems does not reduce that risk. It multiplies it, because the system is no longer just reporting a number back to a human who can apply judgment. Increasingly, it is taking the next step itself.

What this shift asks of BI leaders

I do not think the job of enterprise BI leadership disappears in this shift. I think it moves. For years, a meaningful share of my time went into dashboard design and enterprise data architecture, choosing which metric goes where, how a chart should read and which filters a user needs. Some of that work still matters, but a growing share of my attention now goes into questions that used to sit further down my list. Which systems should an AI layer be allowed to query? What happens when two systems disagree about the same customer? Who is accountable when an agent takes an action instead of simply surfacing a report?

I have started telling my own team something I did not fully believe five years ago. The organizations getting real value from this shift are the ones that treated integration and governance as part of the rollout from day one, not something bolted on once adoption took off. That matches what I have seen leading enterprise analytics for a national network of sales and partner relationships. Connecting a CRM, an HCM platform and a forecasting tool through one conversational layer is a real technical challenge, but it is usually solvable. The harder problem is deciding in advance what that layer is allowed to do once it has access to all of it.

I would tell any BI leader watching this shift the same thing I have started telling my own team. Stop measuring success by how many dashboards get built or how many people log into a portal. Start asking whether the people you support are getting trustworthy answers faster than they were a year ago, inside the tools and language they already use. It has changed how I evaluate success. I no longer ask whether we can build another dashboard. I ask whether we’re helping someone make a better decision faster. If the honest answer is no, the fix is probably not a better dashboard. It is rethinking what sits between your people and the applications they have been navigating on their own for too long.

I still believe in the discipline that built my career. Clean data. Clear ownership. Dashboards that earn a leader’s trust before they earn a login. What has changed is where that discipline gets applied.

It used to live inside the report. Increasingly, it lives inside the conversation. Business intelligence stops being something you check periodically and becomes something that responds to you in real time. The organizations that succeed won’t be the ones that build the most dashboards. They’ll be the ones whose people stop asking where to look because the answer already knows.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

Every enterprise AI strategy these days has mostly the same core cast: Software engineers who log online events data, data engineers who move data from online to offline data warehouses, data scientists who build machine learning models, AI/ML engineers who deploy these models to production systems and data analysts who consume these data outputs and help create dashboards and self-serve agents for product and business leadership for informed decision making. Despite this systematic setup, the same mode of failure still keeps recurring across industries: AI outputs contradict the dashboard, executives eventually stop trusting the numbers and there seems to be no clear owner of the gap between them.

The missing role is not a brand-new role. It is a discipline that has existed for less than a decade, is still not clearly understood at the leadership level, and has no standardized hiring rubric at most organizations. It is the analytics engineer, and the absence of this role is why most enterprise AI deployments seem to stall before they scale.

What is analytics engineering ?

Analytics engineering sits right at the intersection between data engineering, data science and business intelligence — it is the discipline responsible for transforming raw data into a trusted, governed, reusable semantic layer with metrics and dimensions that both humans and AI systems can rely on. The role emerged from the dbt ecosystem as well as early data infrastructure work at Netflix around 2016-2018, but remains unclearly defined at the leadership level — most CIOs either conflate it with data engineering or product data science or business intelligence analysts, or don’t have a job family for it at all.

The role is growing but poorly understood at the top: dbt Labs’ 2024 survey found only 14% of data professionals strongly agree their organization sets clear goals for their data team which is a number that holds steady across individual contributors and managers alike. The core function includes being able to speak both the language of core data engineering and product analytics while having a solid understanding of the business events to track for downstream end-user reporting.

The analytics engineer plays a vital role in designing as well as reviewing data models to be used for reporting in conjunction with data engineers who are building these, often in SQL and Spark. This is not reporting work — it is infrastructure work and therefore analytics in production environments must be engineered as infrastructure, not assembled as reporting.

From these defined business events and key objectives for tracking the health of the product, the analytics engineers need to be able to derive key metrics and dimensional slicing, validating the logic while ensuring those definitions are consistent across all central teams and geographies, and embedding the validation checks that make outputs trustworthy. The practitioner in this role can answer the question no one else can: “Why is the AI giving a different number than the dashboard, and who owns fixing it?”

Why AI exposed the gap

The metric governance problem has existed even before AI, with different teams using different definitions, regional inconsistencies, manual reconciliation cycles — but it was still controllable when humans were entirely responsible for all final reconciliation and data interpretation, and often any data inconsistencies were caught at the analysis stage. Now, with AI in the picture, it removes the human interpreter stage altogether. When an AI system consumes an ungoverned metric, it inherits the ambiguity at the data layer and amplifies it at the output layer. Executives receive different answers to the same question depending on which system they ask.

Confidence in AI erodes independently of model quality — and the numbers bear this out: Foundry’s 2026 State of the CIO study found that fewer than half of  enterprise IT leaders have established formal AI success metrics, and only 19% say AI initiatives have met or exceeded ROI goals. McKinsey’s 2025 State of AI survey found that nearly two-thirds of organizations have not yet begun scaling AI across the enterprise — and explicitly named the absence of platforms and guardrails, not model capability, as the reason.

Popular semantic layer tools like dbt Metrics and LookML describe how metrics should be calculated but do not enforce correctness, which means there is no structural guarantee that the calculation is consistent across regions and can be traced to an authoritative source that is version-controlled on git or maintained by anyone accountable for its accuracy. With conversation and agentic AI systems embedded into the analytics workflow, the data inconsistency problem is further amplified where agents make sequential decisions, each one building on the previous output. A metric that drifts in a traditional pipeline generally produces one wrong number. The same drift in an agentic workflow can produce a chain of downstream decisions built on that wrong number, with no architectural checkpoint to catch it. This is not a model problem. It is a governance architecture problem — and it requires a specific type of data practitioner to detect and solve it.

Ownership and enforcement

The analytics engineer owns the semantic data layer: The governed, versioned, validated definitions of every metric that matters to the business. This includes standardizing metric definitions across teams and geographies, embedding validation logic directly into data pipelines, assigning ownership accountability for each metric, and ensuring AI systems consume only validated outputs. The technical signature of this role dives into the reconciliation controls that proactively detect and stall the data pipeline on failure rather than alerting after incomplete or incorrect data lands; This also includes financial reconciliation from upstream to downstream for all the data models trying all data values to financial statements and accounting ledgers, as well as jurisdiction-aware validation logic that treats regional regulatory differences as first-class properties supported by version-controlled metric definitions that create an audit trail.

While data engineers are responsible for moving and transforming data from online to offline data warehouses, analytics engineers govern what that data means and ensure the meaning is consistent everywhere it is consumed. Data scientists, on the other hand, build machine learning models to detect anomalies, fraud or product marketing opportunities, while analytics engineers build the trusted data foundation those models depend on, making sure whether that data is accessed via manual querying, imported via dashboard tableau extracts or consumed via large language model (LLM), the end user receives consistent answers based on trusted and governed metrics. Data analysts are responsible for surfacing these metrics and building actionable dashboards and reports for leadership, while analytics engineers make sure that the data surfaced is of the utmost quality. Therefore, in the absence of this role,  oftentimes the data engineer, the data scientist and the data analyst are working around a gap that none of them owns.  

What happens when the role is absent

In the absence of this dedicated analytics engineer role, enterprises most often encounter the issue of the “which number is right” question where finance has one revenue figure, product intelligence has another and the LLM model has a third value, and none of these seem to reconcile.

One of the common issues seen in AI projects that work in pilot and often break in production is that the pilot references clean, curated datasets and production data containing millions or even billions of records still reference the ungoverned data layer. The third and significant issue seen across enterprises is the analytics team burnout, where data engineers, scientists and analysts spend 60-70% of their time on reconciliation and firefighting rather than new pipeline creation and insight generation, because there is no governed layer to prevent these fires. The fourth issue is the hidden cost of delayed decisions, eroded executive trust and AI investments that deliver less than projected because the data foundation was never built. Most organizations recognize that they need this role only after something breaks in front of an executive, by which time the damage is already done.

How to identify and hire talent for this role

Analytics engineer, data governance engineer and metrics engineer are all applicable titles for this role. But what really matters technically is the experience with data modeling, semantic layer tooling (dbt, LookML, etc.), validation pipeline design, reconciliation architecture, data lineage and data governance. An ideal candidate is someone who thinks about data correctness as a structural constraint, not a quality preference,  where the first instinct is to stop the pipeline rather than alert and continue with bad data to land and affect stakeholder dashboards.

While interviewing, it’s critical to ask candidates to describe a time they caught a metric inconsistency before it reached a stakeholder. The answer will reveal whether they think in governance terms or reporting terms. This role belongs in the data platform engineering or analytics infrastructure team, not in BI or reporting — it is mostly infrastructure work, not data visualization work. If the role doesn’t exist in your org chart, it exists somehow informally, usually as the senior data engineer whom everyone asks when the numbers don’t reconcile.

Key takeaways

The enterprises that are scaling faster and winning with AI in 2026 are not the ones with the best models, best-in-class AI infrastructure or large budgets. They are the ones who invested the time and effort in successfully building the governed data foundation before deploying the LLMs, and they built it because someone in the organization understood that metric governance is the fundamental data foundation that defines the nervous system of data and insights. It is an architectural property, not a configuration setting in the model, and the data practitioner who helps embed this thinking as a design strategy is the analytics engineer.

The role is the need of the hour, the discipline is established, and the gap it fills is not going away as AI systems become more autonomous. The question for every CIO is not whether this role is needed, as the AI deployment failures already answer that. The question is whether you should hire for it before the next deployment hiccup.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?