The Hidden Risk of AI: Building Transformation Programs for a Future That May Not Exist
For decades, enterprise transformation followed a familiar model: define a future state, build a multi-year roadmap, and execute with discipline. That model is now under pressure—not because transformation is no longer necessary, but because the assumptions behind it are rapidly breaking down. Large transformation programs rely on a core premise: that we can reasonably predict the future operating model. In an AI-driven environment, that premise is increasingly fragile. Capabilities are evolving faster than planning cycles, and organizations are designing multi-year programs against a moving target. McKinsey & Company has highlighted that while generative AI could create significant economic value, organizations are capturing impact fastest through incremental deployment embedded in existing workflows, not large, monolithic transformations. Value is emerging in shorter cycles, not long-duration bets. At the same time, execution risk was already high. Boston Consulting Group estimates that 70% of digital transformations fail to meet their objectives, even in more stable environments. AI does not reduce that risk—it amplifies it. But there is a more fundamental issue emerging—one that is still underappreciated. We are designing transformation programs without a clear understanding of what AI will actually be capable of in two to three years. This introduces a new form of exposure. Not just whether a program will be delivered successfully, but whether it is solving the right problem at all. Entire layers of functionality being built today—workflow orchestration, decision support, even elements of system integration—may be simplified, automated, or eliminated as AI capabilities mature. The risk is no longer just execution failure. It is design risk leading to solution irrelevance. Programs that are delivered on time, on budget, and exactly as designed—but no longer aligned with the business or technology landscape by the time they go live. This is why we are seeing leading organizations shift away from “big-bang” transformation toward more adaptive models. Composable architectures, incremental modernization, and shorter investment cycles are becoming the preferred approach—not as a compromise, but as a strategic response to uncertainty. The question is no longer, “What should our business look like in five years?” It is, “How do we remain adaptable over the next five quarters?” For CEOs, CIOs, and private equity leaders, this has direct implications for capital allocation and risk management. Transformation programs must be structured with optionality—designed to evolve as capabilities evolve, rather than locking into a fixed future state. In many cases, the right answer is not to stop transformation—but to deconstruct it. Rob Purks is a Founding Partner at Lumerai Advisors, a technology strategy advisory firm. Lumerai Advisors provides an unbiased perspective which is not influenced by vendor relationships. With over 150 years of CIO and technology experience, the founding partners bring an honest and complete perspective on technology strategies and challenges. #Telecom #DigitalTransformation #PrivateEquity #ITStrategy #CIO #EnterpriseArchitecture #OPEX #AI #Cloud Lumerai Advisors
The AI ROI Panic Is About to Create the Next Legacy System
By Rob Purks, Founding & Operating Partner, Lumerai Advisors There is a quiet panic spreading through boardrooms right now, and it has nothing to do with whether AI works. It has to do with whether anyone can prove it. The numbers behind that panic are real. Hyperscalers are on track to spend roughly $675 billion on AI infrastructure this year alone. Meanwhile, MIT’s Project NANDA found that 95% of enterprise AI pilots deliver no measurable P&L impact. S&P Global reported that 42% of companies abandoned most of their AI initiatives last year which is more than double the rate of the year before. Forrester is now predicting a market correction with enterprises deferring a quarter of their planned 2026 AI spend into 2027. Even the debt markets have weighed in: Citi identified a measurable credit spread penalty for companies classified as AI adopters without evidence of return. Spending without proof is now literally priced into the cost of capital. I am not here to argue with the data. The data is right. I am here to argue with the response. Key Takeaways The Control Reflex: Why AI Governance Backfires When boards see numbers like these, they react the way boards have always reacted: with control. AI steering committees and per-use-case business cases. ROI attestation before funding. Approval gates between pilot and production. Governance councils that meet monthly to review initiatives that move weekly. Every one of these mechanisms is individually defensible. That is exactly what makes them dangerous. I have spent my career on both sides of this dynamic, as a CIO running technology for telecom operators in Latin America, and later advising enterprises on transformation at Accenture, IBM, and Ericsson. And I can tell you what happens next, because I have watched it happen with every major technology wave: the control structure built to manage today’s uncertainty becomes tomorrow’s constraint. It outlives the problem it was created to solve. Nobody is ever promoted for dismantling a governance committee. I learned this the hard way by inheriting the aftermath of one. At a Latin American operator a major CRM transformation had been put in front of a review board and killed on grounds that were individually hard to argue with: the projected budget was steep, the internal skills weren’t fully in place, and the business wasn’t deemed ready. Every objection was reasonable. The board did exactly what it was designed to do. And while we sat on a defensible “not yet” a competitor moved, modernized its customer platform, and took ground we never fully recovered. The control worked perfectly. The company lost anyway. That is the trap: the most dangerous governance failures don’t look like failures at all, they look like prudence. We have seen this exact movie before. Cloud and agile both promised speed. In most enterprises they delivered something closer to “the same speed with more meetings.” The technology arrived, the operating model absorbed it, neutralized it, and carried on. The gains didn’t disappear, they were quietly strangled by slow decisions and diffused accountability. The ROI panic is now rebuilding that machinery, at speed, with the best of intentions. Except this time there is a difference that should worry every executive: when the constraint is a legacy system you can eventually migrate off it. When the constraint is a legacy operating structure there is no migration project. It just becomes how the company works. I call this Governance Debt: the accumulated drag of controls that outlast the uncertainty they were built to manage. Like technical debt it compounds quietly and like technical debt the interest is paid in speed. The Wrong Diagnosis: It’s Not an AI Adoption Problem Here is the tell that we are solving the wrong problem. In one of the most striking findings of this cycle 97% of executives report personally benefiting from AI yet only 29% see significant organizational ROI. Read that gap carefully. It is not an adoption problem. It is not a model-quality problem. And it is emphatically not a control problem. It is a compounding problem. Value is being created at the level of individuals and teams and the organization has no mechanism to aggregate it, redirect it, or build on it. Adding oversight to that situation does not create compounding. It adds friction to the one place value actually exists. Look at what the successful 29% actually have in common: AI tied to revenue outcomes, business teams owning the workflows, and the whole effort treated as organizational redesign rather than technology deployment.[1] Notice what is not on that list: more approval gates. The organizations seeing returns did not out-govern their peers. They out decided them. What to Build Instead: A Velocity-First AI Operating Model If the answer isn’t heavier oversight, what is it? Three structural moves none of which require a committee: Replace approval gates with kill cycles. Don’t make initiatives prove their worth before they start, make them prove it on a clock. Every AI initiative launches with pre-agreed kill criteria and a fixed time box. The discipline shifts from “may we begin?” to “did we learn enough to continue?” That is governance measured in velocity, not meetings. Measure ROI at the portfolio level, not the use case. Demanding a business case from every individual experiment guarantees you will only fund the safe, incremental, and ultimately unimportant. Venture and private equity investors figured this out decades ago: the portfolio carries the math so the individual bets can take real risk. It is the same logic that drives value creation across a portfolio of companies, you manage the aggregate, not the average. Boards should hold leadership accountable for portfolio-level return and learning rate, not for the survival of any single pilot. Put a sunset clause on every control. Any governance mechanism created to manage AI uncertainty should carry an expiration date and a renewal test: what decision did this body accelerate this quarter? If the honest answer is none, it isn’t governing, it’s accumulating. This is how you keep
The 95% AI Pilot Failure Rate Is Good News
Why the MIT number is a portfolio management finding, not a technology verdict, and the three governance mechanisms that separate an AI experiment pipeline from a capital leak.
AI Isn’t Your Competitive Advantage; Better Decisions Are
Organizations don’t compete on technology. They compete on the quality and speed of their decisions. Introducing the Enterprise Decision Stack™, a new executive framework explaining why strategy, governance, operating models, trusted data, and AI must work together to create sustainable competitive advantage.
The Missing Stage in Every Technology Investment
McKinsey estimates that approximately 70% of digital transformations fail to meet their objectives. Why? Most technology decisions don’t fail because organizations choose the wrong technology. They fail because they begin by solving the wrong problem. After more than three decades helping executives make major technology decisions, I’ve noticed something: the best executive teams don’t necessarily have better answers. They ask better questions. It often starts with a statement like: Most organizations immediately begin discussing vendors. A different conversation begins by asking, “What business problem are we actually trying to solve?” Technology requests are rarely the problem. They are hypotheses about the solution. Executive leadership begins by validating the problem before validating the technology. Exceptional leaders separate business problems from proposed solutions. That’s why I believe the quality of every technology investment is determined long before technology is ever selected. Better decisions begin with better questions. Executive Takeaways Where Most Investment Processes Break Down Imagine building a new corporate headquarters. No executive team would approve the full construction budget before understanding the business requirements, evaluating alternative designs, assessing the site, and validating the long term operating model. Yet organizations routinely approve technology investments with an equivalent level of uncertainty. Not because they’re careless. Because the investment process encourages certainty before sufficient understanding exists. Business cases are often written while assumptions still outweigh evidence. Benefits are estimated before outcomes are fully defined. Budgets are approved before organizations truly understand the problem they are trying to solve. Then implementation begins and the organization spends months learning what it could have discovered before approval. We’ve normalized learning after approval. Instead of learning before commitment. Technology Investments Should Mature Like Executive Decisions One of the lessons I’ve taken from working with executive teams is that confidence isn’t something you create. It’s something you earn. The best investors understand this instinctively. They don’t commit all of their capital on day one. They invest in reducing uncertainty. Every conversation. Every discovery session. Every customer interview. Every piece of evidence either increases confidence or challenges assumptions. Technology investments should work exactly the same way. As knowledge increases… Decision confidence should increase. As decision confidence increases… Investment commitment should increase. Instead, many organizations reverse the sequence. They commit significant capital first. Then spend months validating assumptions they could have challenged before funding was approved. The Lumerai Technology Value Realization Framework™ After seeing this pattern repeat across hundreds of technology decisions, we developed the Lumerai Technology Value Realization Framework™ to help executives improve decision quality before major investments are made. At its core is a simple principle: investment confidence should increase before capital commitment. Rather than viewing technology investments as a single approval event, the framework treats them as a progression of executive decisions. Each stage is designed to answer one critical question before additional resources, executive attention, or capital are committed. It begins with a Business Opportunity. Not a technology request. Not a vendor presentation. A business opportunity. From there, each stage progressively reduces uncertainty while increasing executive confidence. Each stage exists for one purpose: replacing assumptions with evidence before increasing commitment. Every stage earns the right to unlock the next investment decision. Warning Signs You’re Investing Too Early The Role of the Modern CIO Is Changing For decades, CIOs were measured by operational excellence. System availability. Cost management. Project delivery. Those responsibilities remain essential. But executive leadership increasingly expects something more. Boards, CEOs, CFOs, and investors increasingly expect CIOs to improve the quality of enterprise technology investment decisions, not simply the quality of technology delivery. That requires a different leadership mindset. One that values curiosity before certainty. Business outcomes before technology features. Questions before answers. The CIO of the future won’t be defined by the systems they implement. They’ll be defined by the quality of the decisions they help their organizations make. A Question Worth Asking Before approving your next major technology investment, ask one simple question. Are we solving the right problem? It sounds obvious. Yet it may be the most valuable question an executive team can ask. Technology alone doesn’t create business value. Better decisions do. Those decisions come from solving the right problems, executing with confidence, and replacing assumptions with evidence. And every one of those things begins with asking better questions. Coming Next: The Most Expensive Technology Mistake You Can Make Most technology requests arrive disguised as solutions. “We need AI.” “We need a new ERP.” “We need to move everything to the cloud.” But what if those aren’t business problems at all? In the next article, we’ll explore why organizations so often mistake technology requests for business needs, and how a disciplined discovery process can dramatically improve technology investment decisions before a single dollar is committed.
Governance Debt: The Hidden AI Liability Every Private Equity Investor Is Buying
For PE Operating Partners: the AI-era liability hiding inside every portfolio company’s tech stack, invisible to diligence until it’s already yours. By Rob Purks, Founder and Operating Partner, Lumerai Advisors The tech diligence came back clean. SOC 2 current, licenses reconciled, infrastructure spend in line with the model. On paper, the platform company was exactly what the thesis assumed – a solid operational base to build the value creation plan on top of. Four months into a hold, that gap stops being abstract. The automation initiative the plan counted on stalls – not because the AI model is bad, but because nobody can trust the data feeding it, no one owns the pipeline, and half the “adoption” the seller showed you was employees quietly using personal tools that leave the moment they do. That is Governance Debt. And by the time you see it, you already own it. The Blind Spot Standard Diligence Was Never Built to Find Governance Debt is the accumulated liability a company takes on when it deploys AI faster than it governs it: ungoverned pilots, shadow model usage, and unowned data pipelines that no one is accountable for. Like technical debt, it compounds quietly. Unlike technical debt, it does not show up in a code review or a cost audit – because it is behavioral, not architectural. That distinction is the whole problem for diligence. Standard tech due diligence is built to inspect things that are static and auditable: infrastructure, licenses, security posture, spend. You take a point-in-time snapshot and verify it. Governance Debt is neither static nor auditable that way. It is additive -accumulating every week through pilots that never got governed, models that never got owned, and AI tools employees adopted without anyone sanctioning them. A snapshot taken on diligence day captures none of it, because the debt lives in behavior and accountability gaps, not in the systems inventory. So the diligence report is not wrong. It is answering a different question than the one your return actually depends on. Why This Is an ROI Problem, Not a Risk Problem Risk language undersells it. This is not a tail risk that might cost you – it is a discount already priced into the return, whether or not it appears in your model. The mechanism is simple arithmetic against a finite clock. PitchBook and BCG put average private equity hold periods at roughly 5.8 to 7.1 years. Against that window, AI initiatives that require 12 to 18 months to reach production – if they reach it at all – consume a meaningful slice of the value creation runway before delivering a dollar. When the underlying data and governance foundation cannot support the build, that timeline does not hold. It slips, or the initiative is abandoned, and the efficiency gain your model underwrote never materializes. The base rates are sobering. MIT’s NANDA initiative, in its 2025 State of AI in Business study, found that roughly 95% of enterprise generative AI pilots deliver no measurable impact on the P&L – only about 5% achieve real revenue acceleration. That is the outcome distribution across an estimated $30 to $40 billion in enterprise AI investment. And critically, MIT traced the failures not to weak models but to enterprise conditions set before the model was ever built fragmented, ungoverned production data and no clear owner after deployment. Read that against your hold clock and the ROI logic is unavoidable. You are underwriting AI-driven gains on a foundation that, in 95% of cases, cannot deliver on the timeline your return requires. The Governance Debt is the reason the foundation cannot – and you paid for the gains at close. Four Questions Your Diligence Should Be Asking – and Usually Isn’t Governance Debt can be incorporated into diligence. It just requires questions aimed at ownership and behavior rather than inventory. Each of these maps to one of the failure conditions MIT identified – reframed as something you can ask before you close. Who owns each AI model and data pipeline after deployment? MIT found that a defining failure condition is that no one owns the model once it is live. Ask for the named accountable owner – a person, not a team – for every AI system and the data feeding it. If the answer is vague, the debt is already there. Can the data team define the top five KPIs and show they agree on each? Ask the data leaders to define the five metrics that matter most, show where each is sourced, and demonstrate that every function agrees on the definition. If that takes more than an afternoon or surfaces disagreement, the data estate is fragmented – and any AI deployed on it will amplify the fragmentation, not the value. What is the real inventory of AI tools in use – including the ones IT never sanctioned? MIT’s research documented a shadow AI economy in which employees at more than 90% of firms use personal AI tools even when official pilots fail. That usage looks like adoption in a demo and evaporates at close, because it was never owned or governed. Ask what employees are actually using, not what the company licensed. Was the workflow ever redesigned to use the AI output – or just bolted on? A pilot that produces output nobody’s process is built to act. Ask to see where an AI output changed a decision or a workflow in production. If the process still runs exactly as it did before, the pilot is not value – it is Governance Debt wearing a demo’s clothing. Reframe It as Underwriting Discipline Catching Governance Debt before close is not a compliance chore. It is an underwriting input. If the debt is real, it changes the price you should pay or the plan you should build – you can discount the entry, extend the timeline, or budget the remediation into the value creation plan from day one. Miss it, and you discover the discount after you have already paid full
Your Operating Model Is the Real Legacy System
This is an expanded version of an article originally published on CIO.com. Reprinted with permission. © Foundry, Inc., 2026. All rights reserved. [https://www.cio.com/article/4168935/your-operating-model-is-the-real-legacy-system.html] Enterprise modernization isn’t failing because technology is outdated. It’s failing because the enterprise is still operating on a legacy decision model. For the past decade, enterprise modernization has been framed as a technology problem. Legacy systems. Technical debt. Monoliths that need to be broken apart and moved to the cloud. Those investments matter. But they rarely address the actual constraint. In many organizations, technology is capable of moving faster than the enterprise itself. The operating model has become the real legacy system. That framing may be convenient, but it is also incomplete. Technology has advanced dramatically. Cloud platforms, APIs, automation, AI, and modern engineering practices have given organizations unprecedented technical capability. Yet many enterprises continue to struggle to translate those investments into faster execution, better decisions, and measurable business outcomes. The reason is increasingly clear. In most organizations, technology isn’t the constraint. The operating model is. The Real Constraint Is Decision Latency You can see it in how decisions do or don’t move. A product team identifies an opportunity. It makes its way through architecture review, risk, finance, legal, compliance, and multiple layers of approval. Each step is rational on its own. Each exists for a legitimate reason. Collectively, however, they create latency. By the time a decision is made, the opportunity has changed. It’s worth pausing on that word legitimate. Most of this friction wasn’t installed by accident. Approval layers, architecture review boards, and risk sign-offs typically exist because an earlier version of the organization got burned: a compliance failure, a botched integration, a vendor risk nobody caught in time. Governance is, in effect, institutional memory. The problem isn’t that governance exists. It’s that most organizations never revisit which decisions actually warrant that level of scrutiny and which don’t, so a $50,000 vendor renewal and a $50 million platform migration move through the same gauntlet. This is rarely identified as the primary issue. It gets labeled as “complexity,” “organizational maturity,” or simply “the cost of operating at scale.” But the pattern is remarkably consistent. The system isn’t slow because the technology can’t move. It’s slow because the organization can’t decide, or, more precisely, hasn’t decided, which decisions deserve deliberation and which deserve delegation. Most modernization programs focus on replacing systems of record. They invest in platforms, APIs, cloud infrastructure, developer tooling, and application modernization. The expectation is that once the technology is updated, the business will naturally become faster and more adaptive. But the underlying decision structure remains unchanged. Funding is still annual and project-based. Authority is still fragmented across functions. Accountability is distributed in ways that make outcomes ambiguous. Risk is still evaluated in isolation rather than in the context of business intent. The organization integrates modern technology into its traditional operating model, resulting in predictable outcomes. While teams can move quickly in isolated pockets, overall speed does not improve, and enterprise-wide decisions continue to be delayed. As a result, the organization may seem more active, but it is not necessarily more effective. MIT’s Center for Information Systems Research (MIT CISR) has documented this fragmentation directly. Its research on componentized organizations found that as the digital economy accelerates the pace of business, companies need to redesign their people, processes, and technology to facilitate speed and identified rethinking accountability, not adding new layers of oversight, as the key lever (MIT CISR, “The Digital Operating Model: Building a Componentized Organization”). Organizations routinely measure modernization through cloud adoption, deployment frequency, application retirement, or engineering velocity. Far fewer measure how long it takes the enterprise to recognize an opportunity, make a cross-functional decision, establish clear ownership, and execute with confidence. McKinsey’s research on this exact gap found that only 37 percent of executives believe their organizations make decisions that are both fast and good and that speed and quality are not actually a trade-off, since faster decisions tend to be higher-quality ones (McKinsey, “Decision making in the age of urgency”). Increasingly, that decision cycle, not the technology stack itself, is becoming the true determinant of competitive advantage. Modern Technology Cannot Fix a Legacy Operating Model In practice, the operating model defines how work gets prioritized, how decisions are made, and how tradeoffs are resolved. It determines whether the organization can convert technology capability into business results. When that model is misaligned, even well-executed technology initiatives underdeliver. You can see this most clearly in cross-functional decisions. A customer experience initiative spans multiple systems, business units, and risk domains. Each group operates with its own objectives, constraints, funding model, and measures of success. No single decision-maker owns the tradeoffs across the entire initiative. As a result, decisions are escalated, deferred, or negotiated one function at a time. Nothing breaks. But very little moves with intent. The common response is to add another steering committee, another governance checkpoint, or another approval layer. Those changes may improve oversight, but they seldom improve throughput. The organization becomes more controlled without becoming more responsive. That’s not an argument against governance; it’s an argument for designed governance, calibrated to the actual risk and reversibility of each decision, rather than governance that grows by accretion every time something goes wrong. What it looks like when this actually gets fixed Allstate’s Claims division offers a concrete example of a company redesigning the decision layer rather than the technology layer. In 2021, Claims set out to simplify operations and deliver more frictionless digital experiences to customers. Rather than starting with a new platform, the organization redesigned decision rights: operational authority was pushed down to durable, cross-functional teams built around strategic objectives, replacing a traditional project-based way of working rooted in prescriptive annual plans with a continuous, iterative process (MIT CISR, “Allstate’s Digital Operating Model: Think Big, Act Small”). The technology stack Claims used wasn’t the differentiator. The decision architecture was. Teams that had previously waited on annual planning cycles and cross-functional sign-off could now resolve customer and business problems continuously
The modern CIO is no longer a technologist – they’re an architect of enterprise decisions.
As featured on CIO.com For much of the last three decades, the CIO role has been defined by delivery: platforms implemented, systems stabilized, programs executed. Success was measured in uptime, milestones, and budget adherence. When things went wrong, the diagnosis was familiar execution struggled, teams moved too slowly, or technology didn’t perform as expected. That framing is no longer sufficient. Most large-scale enterprise modernization efforts do not fail because teams cannot execute. They fail because the strategy and structural decisions were flawed from the start, and those flaws quietly harden long before delivery ever begins. In today’s enterprises, technology outcomes are rarely constrained by tools or talent. They are constrained by how clearly leaders define outcomes, how explicitly they make tradeoffs, and how intentionally they design the decision systems that translate strategy into action. That is why the modern CIO is no longer simply accountable for technology execution. They are increasingly accountable for the decision systems that determine whether transformation efforts ever translate into durable business value. I’ve come to believe this is the real evolution of the role. The modern CIO is no longer primarily a technologist. They are the architects of enterprise decisions. Where transformations actually fail I’ve been brought into many programs described as “behind schedule” or “underperforming delivery.” On the surface, they appear to be execution problems. Teams are busy. Roadmaps exist. Progress is tracked. Yet outcomes continue to disappoint. When you examine the root causes, the issues are rarely about effort or capability. They’re systemic. The same patterns appear again and again: When these conditions are met, delivery does not encounter random issues. It degrades predictably. Velocity slows. Dependencies multiply. Decision latency increases. Risk accumulates. Costs escalate. Credibility erodes. By the time leadership starts asking why execution is failing, the failure is already baked into the structure. This is where modernization efforts most often go wrong. Leaders declare a new strategy, but they leave the underlying decision architecture intact. Old governance models are asked to support new operating realities. Legacy funding structures are expected to enable adaptive delivery. Accountability remains fragmented while outcomes demand cohesion. Execution is then asked to compensate for design failure. It never does. Research published by McKinsey has consistently shown that organizational and operating model constraints, not technology, are among the primary reasons large transformations stall or reverse course. The more profound implication is often left unstated: if the constraint is structural, accelerating delivery without redesigning decision systems reveals the weakness more quickly. The CIO’s real leverage point Modern CIOs sit at a unique intersection of strategy, execution, and governance. They see where priorities collide, where accountability blurs, and where decisions stall under the weight of ambiguity. Historically, CIO influence was exercised through control of technology assets, budgets, platforms, architecture standards, and delivery capacity. Today, the CIO’s most consequential influence is exercised upstream of delivery, in how decisions are designed and governed. This is less visible work than a cloud migration or platform rollout, but far more determinative of outcomes. In practice, the CIO becomes responsible for orchestrating intelligence and ensuring that strategy is supported by structures capable of executing it. That requires deliberate design across several dimensions. Outcome clarity.What are we trying to achieve, and how will we know? If outcomes are vague, success becomes subjective, and tradeoffs become political. Decision rights.Who decides what, and at what altitude? When decision ownership is implicit, authority defaults to whoever can delay the longest. Tradeoff discipline.When priorities conflict, and they always do, how does the organization decide? What data is required? Who arbitrates? How long does it take? Without a mechanism, alignment becomes theater. Governance that enables movement.Governance should resolve ambiguity, not preserve it. Committees that exist primarily to distribute blame will reliably slow progress. Operating model alignment.Declaring “product teams” does not create product accountability. If funding, incentives, and authority remain project-based, the operating model is performative. Sequencing and capacity management.Every organization has finite change capacity. Strategy without sequencing diverts leadership attention and creates the illusion of resistance, when the real issue is design failure. When these elements are intentionally designed, something important happens. Execution becomes less dependent on heroics. Teams stop waiting for permission to solve obvious problems. Leaders stop relitigating the same tradeoffs. Delivery begins to resemble a stable operating rhythm instead of a constant escalation. This is the CIO’s real leverage point. Not tooling. Not velocity. But decision integrity. What boards increasingly expect from CIO leadership Boards and executive teams are beginning to recognize this shift, even if they don’t always articulate it in architectural terms. They rarely ask about specific platforms or methodologies. Instead, the questions sound like: These are not technical questions. They are governance and decision-design questions. Boards understand that digital transformation is no longer a discrete program. It is an ongoing operating reality. As a result, they are increasingly looking to the CIO not just for delivery competence but also for judgment, the ability to translate strategy into repeatable, governable execution. MIT Sloan Management Review has written extensively about the importance of explicitly designing decision rights and governance structures to sustain transformation outcomes. Organizations that do this well tend to move faster with less friction because ambiguity is no longer the default operating condition. This is why the modern CIO is increasingly viewed as a peer enterprise leader rather than a functional specialist. Boards do not need another executive who can “run IT.” They need an executive who can shape how the enterprise changes without losing control. The modern CIO mandate None of this diminishes the importance of technical competence. Modern CIOs must still understand architecture, platforms, data, and security deeply. In many industries, those responsibilities are existential. But those capabilities are now table stakes. The differentiator is whether the CIO can see and redesign the invisible systems that determine how work actually gets done: decision rights, governance structures, escalation paths, incentives, and accountability. In organizations where transformation sticks, the CIO has shifted from being the steward of technology to being the steward of decision integrity. They
The Rise of Systems of Judgment: Why AI Requires a New Enterprise Architecture
Every enterprise today is racing to deploy artificial intelligence. Yet most organizations are attempting to insert intelligent systems into an architecture that was never designed for machine-assisted decision making. The result is growing uncertainty not about technology, but about authority, accountability, and governance. For decades, enterprise technology architecture has been organized around two foundational layers: systems of record and systems of engagement. Together, they have shaped enterprise technology strategy, digital transformation, and operating models for more than two decades. Artificial intelligence introduces a third architectural layer that fundamentally changes this model. I call these Systems of Judgment. They represent the emergence of Enterprise Decision Architecture, the discipline of designing how intelligence participates in enterprise decisions while preserving accountability, governance, and human oversight. Organizations that recognize this shift early will build AI into the fabric of the enterprise responsibly. Those that do not risk creating faster systems with less clarity over who ultimately owns the decisions those systems influence. The Evolution of Enterprise Architecture For decades, enterprise technology architecture has been understood through two primary lenses. Systems of Record Systems of record manage the authoritative data that underpins the enterprise financial ledgers, customer records, inventory systems, loan platforms, ERP environments, and transaction processing systems. These platforms are built for accuracy, durability, compliance, and consistency. They preserve the organization’s institutional memory and establish a single source of truth. Systems of Engagement As digital transformation accelerated, organizations introduced systems of engagement. Customer portals, mobile applications, collaboration platforms, CRM solutions, workflow engines, and employee experience platforms made it possible to interact with customers and coordinate work in ways traditional transactional systems were never designed to support. Together, systems of record and systems of engagement have defined enterprise IT strategy for more than twenty years. Artificial intelligence changes that architecture. The Rise of Systems of Judgment AI does not simply process information. It interprets information. Unlike traditional enterprise systems, AI evaluates probabilities, recognizes patterns, generates recommendations, prioritizes alternatives, and increasingly initiates actions. That is a fundamentally different responsibility. These are Systems of Judgment. Rather than storing data or facilitating interactions, they participate directly in enterprise decision-making. Examples already exist across nearly every industry. A credit risk model evaluates the probability of default before recommending whether to approve a loan. A fraud detection platform determines whether a transaction should proceed or be blocked. An AI copilot recommends operational changes in response to supply chain disruptions. A predictive maintenance engine determines when expensive equipment should be serviced before failure occurs. In each case, the software is no longer simply processing transactions. It is exercising delegated judgment. When software begins participating in judgment, enterprise architecture must evolve accordingly. From Technology Architecture to Decision Architecture Traditional enterprise systems were deterministic. Given identical inputs, they consistently produced identical outputs. Their responsibility was to execute predefined business logic: process a transaction, update a record, or trigger a workflow. AI-driven systems operate differently. They interpret uncertainty. They evaluate probabilities. They recommend actions that may vary depending on context. That means organizations are no longer designing only technology architectures. They are designing decision architectures. This distinction matters because decisions carry accountability in ways transactions never have. The Decision Stack As intelligent systems mature, enterprise architecture naturally evolves into a layered decision model. Systems of RecordAuthoritative data, transactional integrity, compliance, and institutional memory. Systems of EngagementCustomer experiences, employee interactions, collaboration, and workflow coordination. Systems of JudgmentIntelligence, prediction, reasoning, recommendations, prioritization, and decision support. Human GovernanceExecutive oversight, escalation paths, accountability, risk management, ethics, regulatory compliance, and final authority. Each layer performs a distinct role. The effectiveness of the enterprise increasingly depends on how clearly organizations define the boundaries between automated judgment and human judgment. Today, many organizations have invested heavily in AI while giving comparatively little attention to designing those boundaries. Figure 1. The Enterprise Decision Stack Enterprise AI does not replace existing technology architecture; it extends it. Systems of Judgment introduce a new architectural layer between enterprise data and executive oversight, requiring organizations to intentionally design how intelligence, automation, and human accountability work together. Governance Becomes the Critical Design Challenge As organizations adopt AI-assisted decision making, the central challenge shifts from model accuracy to decision governance. As illustrated in the Enterprise Decision Stack, Systems of Judgment occupy a unique position between enterprise operations and executive oversight. Their value comes not simply from generating recommendations, but from enabling organizations to determine when decisions should be automated, when they should be escalated, and who ultimately remains accountable. Every enterprise must answer several fundamental questions. These are not technology questions. They are enterprise governance questions. Consider a global financial institution processing millions of transactions every day. If an AI-powered fraud engine automatically declines thousands of customer transactions, the organization has delegated judgment, not merely automation. If those decisions prove incorrect, responsibility cannot belong to the algorithm. It belongs to the enterprise that designed the governance model around it. Similarly, if an AI model prioritizes customers, allocates resources, or recommends operational changes across multiple business units, leadership must define who validates those recommendations before execution and how exceptions are managed. Governance, not model sophistication, ultimately determines whether AI creates enterprise value or enterprise risk. Implications for CIO Leadership The emergence of Systems of Judgment significantly expands the role of the modern CIO. Historically, technology executives were measured primarily by platform reliability, scalability, security, availability, and cost efficiency. Those responsibilities remain essential. But AI introduces an entirely new leadership obligation. Technology leaders must now help design the flow of decisions through the enterprise. That includes establishing: Increasingly, CIOs are not simply architects of technology. They are architects of enterprise decision systems. Why This Matters for Every Enterprise Artificial intelligence will continue becoming more capable. Models will improve. Automation will expand. Agentic AI will increasingly coordinate complex work across multiple systems. But the long-term competitive advantage will not come from deploying more models. It will come from designing better systems for governing how those models participate in enterprise decisions. Organizations that intentionally build Systems of Judgment into their enterprise
The Architecture of Authority: Why AI Is Reshaping Enterprise Leadership
For decades, the enterprise power dynamic was absolute and unchallenged: systems provided the data, and humans provided the judgment. Organizations termed themselves “data-driven” if an executive glanced at a dashboard before making a call, but the dashboard was a passive participant. It never actually changed who held the steering wheel or who was accountable when things went wrong. Technology was a silent partner—a repository of record that executed instructions only after the human “go” signal was given. That boundary has not just blurred; it is being erased. We are moving from an era of “Systems of Record” to an era of “Systems of Action,” and most organizations are fundamentally unprepared for the shift in authority that follows. The challenge isn’t the technology itself; it’s that we are attempting to run 21st-century intelligence on top of 20th-century governance. The End of the Dashboard Era The newest generation of AI has moved beyond recommending a course of action to initiate it. This is the critical pivot point where “support” becomes “participation”. In many modern enterprise stacks, the machine is already making high-stakes calls in milliseconds—isolating network devices, blocking multi-million-dollar transactions, or rerouting global shipments—often before a human analyst even sees an alert. When a system functions at this speed, the traditional “human-in-the-loop” model becomes a bottleneck or, in some cases, a myth. At this point, the system is no longer informing a decision; it is determining the outcome. This creates an immediate crisis for traditional governance. Most corporate frameworks are built on a 1990s-era assumption: that humans make judgments and systems implement them. When the system itself begins to determine what happens next, the separation between decision-making and execution—the very foundation of corporate oversight—becomes impossible to maintain. The Conflict of Logic vs. Intuition The most overlooked risk in AI implementation isn’t a technical failure—it’s the moment of disagreement. What happens when a machine’s data-driven recommendation contradicts a veteran manager’s years of intuition? In a traditional hierarchy, the senior leader wins by default. But in an AI-integrated environment, that “win” might come at the cost of operational speed or accuracy. Conversely, if the machine wins, who owns the liability? In regulated industries, these aren’t just philosophical debates; they carry significant legal and operational consequences. A system that blocks a transaction or flags a customer is taking an action that has traditionally required a signature and a clear chain of custody. If we haven’t designed the “Decision Architecture” to handle these conflicts, we aren’t innovating; we are simply creating a new type of organizational chaos. Decision Architecture: The Invisible Layer As decisions begin to emerge from within the technology itself, the structure of decision-making becomes an architectural question, not just a management one. This is the concept of Decision Architecture: the intentional design of how authority flows between people and software. Historically, authority evolved through hierarchy: information flowed up, and decisions moved back down through operational silos. Core platforms, like ERP systems, were built specifically to reinforce this “step-by-step” approval logic. These designs work perfectly when systems are executing predictable transactions. But they fail when an intelligent layer begins to evaluate context and trigger responses across those same processes. The friction we are seeing today isn’t a technical glitch; it is an organizational collision. Decisions are bypassing the management chain entirely and emerging from the “intelligence layer” of the stack. Without dedicated architecture to govern this flow, the CIO is no longer managing a technical stack—they are managing a fragmented, automated bureaucracy. The Danger of Accidental Authority Perhaps the greatest risk to the modern enterprise is “Accidental Authority.” This happens when AI capabilities are developed in isolated silos—one team building a fraud model, another implementing automated customer service, and a third deploying AI-driven cybersecurity. Each of these teams is essentially handing over “micro-slices” of corporate authority to different algorithms, often without a central registry of what decisions have been automated. Without coordinated architecture, you wake up to a fragmented environment where your systems have inconsistent levels of authority, lack oversight, and offer no clear way to override them when they go off the rails. We must stop building AI as a series of features and start building it as a unified decision-making ecosystem. The Practitioner’s Mandate: Designing for Authority For the modern CIO, the challenge is no longer the deployment of AI; it is the management of authority. The most dangerous path is allowing this authority to emerge accidentally, hidden within isolated teams or embedded deep inside individual platforms. To lead this transition, technology leaders must move toward three strategic imperatives: From Tool to Participant The organizations that survive this shift will be the ones that stop viewing AI as just another tool in the shed and start viewing it as an active participant in the business. The role of the leader is no longer to “sign off” on the data, but to architect the logic that governs the machine’s behavior. Success in the AI era won’t belong to the companies with the fastest algorithms or the biggest data lakes. It will belong to the leaders who treat decision-making as something that must be intentionally designed, rather than something that happens by accident as a byproduct of new technology. Frequently Asked Questions How is AI changing corporate hierarchy? Artificial intelligence is reducing the need for organizations to rely solely on traditional management layers to coordinate work and distribute information. As AI systems become capable of analyzing data, recommending actions, and executing routine decisions, authority increasingly shifts from information control to judgment, governance, and accountability. Organizations will need to redesign leadership structures to ensure humans remain responsible for strategic direction and oversight. What is the Architecture of Authority? The Architecture of Authority is the framework that defines how decisions are made, delegated, governed, and monitored within an organization. In the age of AI, it extends beyond traditional reporting structures to include intelligent systems that participate in decision-making. A well-designed Architecture of Authority ensures AI augments human judgment without weakening accountability or governance. Will AI