AI Will Not Transform a Company That Cannot Decide
Models can compress analysis in seconds while approval, execution, and learning still consume weeks. Faster output does not make a faster company.
A company can shrink the time it takes to produce an analysis from two days to two minutes and still take three weeks to decide what to do with it.
The neglected operating unit of AI transformation is the recurring decision, the point at which information becomes commitment.
McKinsey’s November 2025 survey found that 88 percent of respondents reported regular AI use, yet only 39 percent attributed any enterprise-level EBIT impact to it, and most of that group put the contribution below 5 percent.
Deloitte’s separate 2026 survey found a similar divide between ambition and reported results: 74 percent hoped AI would drive revenue growth, while 20 percent said it already did.
These are self-reported estimates, and they cannot cleanly separate AI from the workflow, staffing, and management changes surrounding it. They point to a substantial gap between deployment and claimed organization-wide financial impact.
In a separate March 2025 analysis focused on generative AI, McKinsey reported that workflow redesign had the strongest association with reported EBIT impact among 25 organizational practices tested.
The result was associative rather than causal, but it reinforces an older organizational finding. In McKinsey’s 2019 research on organizational decision-making, respondents who described decisions as fast were about twice as likely to describe them as high quality. Only 37 percent said their organizations achieved both.
The findings were perceptual and correlational, but they challenge the assumption that rigor must require delay.
Workflows determine how information moves. Recurring decisions determine whether that information produces commitment, execution, and learning.
That makes the recurring decision a particularly useful unit for measuring whether redesign changes performance.
The Recurring Decision Is the Missing Unit
A recurring decision is a class of choices made repeatedly under comparable conditions.
Pricing exceptions, credit approvals, retention offers, and decisions to continue or stop product experiments are common examples. Cases belong in the same class only when they share broadly similar triggers, evidence requirements, authority, risk, and outcome measures.
High-frequency classes can be calibrated quickly. Low-frequency decisions require longer review periods or external comparisons.
Workflows map activities and handoffs. They can remove steps and automate movement without establishing who has authority to commit resources, what standard of evidence must be met, or when further analysis stops adding value.
Decision design supplies those missing rules and defines the outcome against which the decision will later be evaluated.
The Decision Velocity Cycle
The framework proposed here divides decision velocity into three connected intervals, each with its own quality test.
Resolution velocity
Resolution velocity is measured from a predefined, observable trigger to a committed decision.
A decision is committed only when the chosen action, owner, resources, guardrails, and effective date are clear enough for execution to begin.
Track intake completeness separately from deliberation. Intake time measures how long the organization takes to assemble the defined case. Resolution time measures how long the owner takes to reach commitment once that evidence is present.
Quality test: Did the organization use the evidence and challenge reasonably available at the time?
Execution velocity
From commitment to completed implementation.
Each decision class should define its implementation endpoint in advance. Completion might mean a signed contract, a budget transfer, a production release, or another observable operating state.
Execution and learning may overlap during staged rollouts. Track implementation through completion while starting the learning clock when the decision first produces measurable exposure or consequences.
Quality test: Was the decision carried out as intended?
Learning velocity
From the point at which the decision begins producing observable consequences to evidence strong enough to confirm, revise, or reject a material assumption.
Before execution, the owner should identify the assumption being tested, the primary outcome, the review date, the minimum evidentiary threshold, and what result would cause the organization to preserve, revise, or reverse its current rule.
Learning is organizational only when the evidence changes a rule, threshold, forecast, process, or future decision.
Quality test: Did the organization test the result against its original forecast?
An interval has not improved when its cycle time falls but its quality measure deteriorates.
In that case, the organization has transferred costs from delay to error, rework, or poor outcomes. When speed improves but quality falls, pause expansion and determine whether the loss comes from weaker evidence, compressed challenge, execution shortcuts, or premature outcome judgment.
When Waiting Adds Value
Some delay is useful.
New information can genuinely improve the call. Safety, legal, or regulatory requirements sometimes demand it. Strategic optionality is worth preserving when uncertainty is high.
A useful delay may also reflect the time needed to hear from stakeholders who bear consequences the internal decision owner cannot fully observe.
Much of the delay leaders encounter comes not from useful analysis but from unclear ownership, serial review, and scheduling friction.
Leaders should not optimize decisions involving fundamental rights, irreversible safety exposure, or contested public legitimacy primarily for speed.
The goal is not to remove all waiting. It is to remove the waiting that buys no improvement in quality.
How to make faster decisions
The Economics of Avoidable Delay
Use this as a directional prioritization tool.
A pricing move forecast to create $40,000 in monthly incremental contribution, with a 50 percent probability of success, carries $20,000 in probability-adjusted monthly value.
A six-week avoidable delay would therefore defer approximately $30,000 under those assumptions.
Whether that value is lost or merely postponed depends on customer behavior, competition, capacity, and implementation timing.
Over time, the ledger should compare assigned probabilities with actual outcomes so the organization can see whether its forecasts are calibrated or systematically optimistic.
How This Plays Out in Practice
Consider a simplified hypothetical software company handling dozens of pricing exceptions each month.
Before redesign, the company knew how long exceptions took but had no reliable baseline for whether larger discounts improved win rates or damaged renewal economics.
Resolution often took two to four weeks because requests passed serially through sales, finance, and legal without a single owner.
Execution required several more days because billing and contract updates were uncoordinated.
Learning was nearly absent because outcomes were rarely tested against the original assumptions about price sensitivity.
An early AI tool helped draft justifications and surface comparable past deals.
The drafting step got faster.
The overall decision did not.
The tool shortened evidence preparation, but preparation was still not the binding constraint. Authority remained distributed, reviews remained serial, and implementation still had no owner.
The redesign focused on the decision itself.
The expedited class included commercial discounts and standard payment-term exceptions within predetermined contract language. Requests involving liability, exclusivity, data rights, or unusual implementation obligations entered separate decision classes.
One pricing lead was given clear authority to approve or deny within preset financial and risk limits.
Input from finance and legal was time-boxed, while requests crossing predefined legal thresholds remained blocked until the required review was complete.
A target resolution time was set, with automatic escalation if it slipped. Lower-risk exceptions moved with lighter review.
Higher-risk requests received one time-boxed review from a named challenger empowered to identify a specific material risk or assumption and state whether it changed the recommendation.
A decision ledger recorded the trigger, evidence used, assumptions, decision, expected outcome, and the date on which enough evidence should exist to evaluate the result.
AI was then applied to the actual constraint: pulling relevant historical cases and flagging when a request crossed a risk threshold.
The working hypothesis would be that tighter exception discipline can improve contribution margin without materially reducing win rates.
Before the test, the company would define its primary outcome, contribution margin per exception deal, along with acceptable tradeoffs, the review horizon, and segment-level guardrails.
The company would also track withdrawn and unsubmitted opportunities where tighter controls may have discouraged potentially valuable exceptions before they entered the ledger.
5 Steps to Fix Any Problem at Work | Anne Morriss
The Decision Operating Architecture
The cycle identifies where the constraint sits.
The architecture identifies what management can change.
Six operating components
Ownership: Who makes the decision and who is responsible for implementation?
Evidence: What must be known?
Clock: When must it close?
Risk: What raises review or escalation?
Feedback: When are the process and outcome reviewed?
Memory: What is preserved for the next cycle?
Two system safeguards
Dissent: Contributors should have a time-bound opportunity to challenge a material assumption or risk. The challenge should be recorded, but it should not create an indefinite veto unless the contributor holds explicit legal, safety, or financial authority.
Portfolio coordination: A design leader should regularly review aggregate exposure, exception volume, bottleneck migration, and capacity effects, adjusting the frequency ranging from weekly for high-volume exceptions to monthly or quarterly for slower decision classes.
Committees can add expertise and legitimacy, but they can also diffuse accountability when no rule defines how consultation ends and commitment begins.
The form of ownership may vary by culture and institution, but the organization still needs an explicit rule for how consultation gives way to commitment.
The ledger should capture approvals, denials, withdrawals, escalations, and requests that expire without resolution.
It should be used primarily for calibration and process learning. If it becomes a retrospective blame file, participants will protect themselves with assumptions too vague to test.
Decision records should use role-based access, retention limits, and data minimization appropriate to the commercial, employee, or customer information they contain.
Ownership, evidence, clock, and risk primarily determine resolution.
The execution owner, resources, and cross-functional dependencies determine implementation.
Feedback and memory determine whether completed action becomes learning.
What AI Can and Cannot Do
Once those rights, thresholds, feedback loops, and safeguards are explicit, the organization can decide where AI belongs and how much authority it should receive.
AI may inform by organizing evidence, advise by generating options or recommendations, execute within predefined limits, or escalate cases requiring human judgment.
Each step requires a higher evidentiary and governance standard.
Automatic action should require defined monetary or exposure limits, reliable inputs, rapid and dependable error detection, fast rollback, logged reasoning, and ongoing monitoring.
Technical reversibility is not enough. The organization must also consider the customer, legal, and reputational consequences of an error at scale.
AI should not make final autonomous determinations in decisions that materially affect employment, safety, regulated eligibility, or individual rights.
It may support evidence collection or monitoring under appropriate legal, risk, and human-review controls.
Standardization can concentrate failure.
When the same model or data source informs many decisions, one hidden error can affect dozens or hundreds of calls at once.
For material decisions, the record should preserve the model, material data sources, applicable rule or threshold version, and material configuration needed to reconstruct the recommendation.
If a defect is found, a named model or data owner should trigger a portfolio review of affected decisions and determine which require correction, reversal, or human reassessment.
Freeze material model and rule configurations during a pilot where practical. If they change, record the change and treat subsequent decisions as a separate measurement cohort.
Where the underlying data is fragmented or inconsistently defined, the first intervention may need to be data standardization, integration, or new data capture rather than model deployment.
Fundamentals of Decision Quality | Strategic Decisions Group
A Focused 30-Day Pilot
Start with a decision that is frequent, economically meaningful, measurable, and reversible enough to test safely.
Name one leader accountable for the pilot, its measurements, and the decision to expand, revise, or stop it.
Week 1: Define the trigger and reconstruct recent historical cases. Establish the baseline.
Week 2: Assign rights, evidence standards, time expectations, and escalation.
Week 3: Install the ledger, the immediate process-review rhythm, and the later outcome-review date appropriate to the decision.
Week 4: Apply AI to the measured constraint and compare early process indicators with the baseline.
A successful first month should produce a defined decision class and baseline, one documented reduction in avoidable delay without early quality loss, and a functioning record that supports a later outcome review.
At day 30, the pilot owner should decide whether to expand the redesign, revise the decision class or measurements, continue collecting evidence, or stop the intervention.
Abandon or redefine the pilot if the trigger cannot be observed consistently, cases are not comparable, outcomes cannot be measured, or the cost of delay proves immaterial.
Early operating measures can show whether the process changed.
They should not be treated as proof of financial impact until enough comparable decisions have accumulated.
The Real Test
The durable advantage is the ability to commit sooner, execute as intended, and know more when the same class of decisions recurs.
The next time an AI initiative is proposed, ask three questions:
Will the organization commit sooner?
Will it execute more reliably?
Will it know more when that decision class recurs?
A faster model is widely available.
A company that repeatedly converts consequential choices into better data, sharper judgment, and stronger operating memory is much harder to copy.













Too many people think AI is the strategy. It isn’t. AI is simply another tool, just like spreadsheets, the internet, or automation before it. If your company lacks vision, leadership, accountability, and execution, AI will only help you fail faster.
For more than 30 years I’ve developed products and built businesses. Not once did success come from the latest technology. It came from disciplined execution. Knowing your customer. Understanding your numbers. Building systems that people actually want to use. Then working every single day to make them better.
That’s exactly how I’m building Infortum. We use AI every day, but AI didn’t create the vision. It didn’t define the mission. It didn’t sit through years of product development, investor meetings, regulatory planning, and partnership building. It helps us move faster because we already know where we’re going.
Technology has always rewarded preparation. AI is no different. It doesn’t replace leadership. It amplifies it. And if your foundation is weak, it amplifies those cracks too.
Design. Develop. Deliver that is what I do and AI simply helps you do those three things better. It never replaces the responsibility to do them well in the first place.