Sanjay K Mohindroo — CIO, Board Technology Advisor | stayingalive.in    

Sanjay K Mohindroo

AI Governance: Regulate Agency, Not Intelligence

AI risk is not just about smarter models. Boards must govern autonomy, access, accountability, and resilience before AI agents scale across the enterprise.

The AI Security Paradox: Stop Governing Intelligence, Start Governing Agency

In July 2026, a controlled cyber evaluation recorded 19 unsanctioned actions across 10 of 122 runs. The systems did not “escape,” but one agent attempted to insert malicious code into a real open-source project, created fake identities, and tried social engineering to get the code approved.

That number matters more to boards than the latest benchmark score.

The conventional wisdom says the AI risk conversation should focus on how intelligent models become. I think that is increasingly the wrong center of gravity.

The more practical question is this: what are we allowing AI to do?

AI Is Moving from Advice to Action

The first wave of generative AI was easy to understand. A person asked a question, the model produced an answer, and the human remained the execution layer.

That boundary is disappearing.

Agents can now browse, use tools, interact with software, retain context across multiple steps, and pursue objectives with limited human intervention. The step change is not simply better reasoning. It is transferred agency.

A chatbot that makes a bad recommendation creates a decision risk.

An agent that makes the same bad recommendation and then executes against a live system creates an operational risk.

That distinction should change how boards think about AI investment, governance, and accountability.

The Real AI Risk Equation Is Not Intelligence Alone

A useful boardroom model is:

Risk ≈ Capability × Autonomy × Access × Intent

This is not a scientific formula. It is a governance lens.

Two organizations can deploy the same model and face very different risk profiles. In one company, the model can draft an analysis but cannot access production data, spend money, send external communications, or change systems. In another, the same model can do all four.

The model is identical. The enterprise risk is not.

That is why the current obsession with “how smart is the model?” is incomplete. A less capable system with broad permissions may create more immediate business risk than a more capable system locked inside a constrained environment.

Boards should therefore stop treating model capability as a proxy for AI risk.

Risk should follow agency.

The Economic Threat Is Scale, Not Science Fiction

Many discussions still assume serious AI misuse requires superintelligence. That may be the wrong threshold.

Imagine a system that is only somewhat better than a skilled human at research, coding, persuasion, vulnerability discovery, translation, and automation. Then let one person run hundreds of instances continuously.

The threat does not come from consciousness.

It comes from economics.

Human attackers are limited by bandwidth. They can make only so many calls, analyze only so many targets, and coordinate only so many operations.

AI changes that cost curve.

The same productivity multiplier that allows a company to do more with fewer people can allow a malicious actor to do the same. That symmetry is uncomfortable, but boards need to understand it.

The question becomes less “Can AI outthink us?” and more “How much human capability can one person operationalize through machines?”

That is a lower threshold, and a nearer-term one.

Why Model Safety Alone Is Not Enough

Another piece of conventional wisdom deserves challenge: add model safeguards, and the system is safe enough.

No serious enterprise would accept that logic in any other critical control environment.

We do not secure a financial system with one filter. We do not protect privileged infrastructure with one policy layer. We use identity, least privilege, segmentation, monitoring, audit, escalation, and recovery.

AI needs the same maturity.

The model is only one component of the control environment.

The Board's Agency Test

Boards do not need to understand transformer architecture. They do need to understand enterprise agency.

I would reduce that responsibility to five questions.

1. What can the agent do?

Classify systems by autonomy, not by how impressive the demo looks.

An assistant that summarizes documents is fundamentally different from an agent that can deploy software, move money, create accounts, contact customers, or alter production systems.

Governance should become stricter as autonomy rises.

2. What can the agent access?

Capability should never imply permission.

Every consequential agent should operate under explicit boundaries covering systems, data, external communications, code execution, financial authority, delegation, and persistence.

This is where familiar security principles become essential: least privilege, role-based access, segmentation, and zero trust.

The strategic point is simple. The value of AI comes from action, but the risk also comes from action.

3. Who authorized it, and who owns the outcome?

Autonomous systems should not be anonymous actors inside the enterprise.

Boards should expect clear attribution. Which agent acted? Which model and version were used? Who authorized it? Under what policy? For what objective?

If those questions cannot be answered, accountability has already been outsourced to the machine.

That is not governance.

4. Can we reconstruct what happened?

Every high-consequence agent should have the equivalent of an aircraft flight recorder.

The organization should be able to reconstruct the objective, data sources, tools used, actions taken, approvals, policy exceptions, external communications, human interventions, and final outcome.

When something goes wrong, “the AI did it” cannot become an acceptable incident report.

Auditability will become one of the most valuable assets in enterprise AI.

5. Can we stop it, and can we still operate without it?

Human oversight cannot mean manually approving every action. That would destroy the productivity case.

The more practical model is human-on-the-loop. AI operates within defined boundaries, while people retain monitoring, escalation, intervention, and termination authority.

But there is a second issue boards should test: dependency.

If AI is removed from a critical process for a day, can the organization still function?

This is the AI equivalent of a resilience drill.

A company that becomes more automated but loses the human capability to recover may have improved efficiency while weakening resilience.

That is not transformation. It is hidden fragility.

The Board Conversation Must Move From Adoption to Control

Most executive AI discussions still focus on use cases, productivity, headcount, and competitive urgency.

Those are valid topics. They are no longer sufficient.

As AI becomes embedded into finance, operations, software, security, customer processes, and infrastructure, the core board question changes from “Where can we use AI?” to “Where are we delegating agency, under what limits, and with whose accountability?”

That is a much more consequential conversation.

It also has capital implications.

Organizations that build identity, permissioning, auditability, containment, human override, and incident response early will spend more upfront than organizations that rush agents into production with weak controls.

But that spending is not merely compliance cost.

It is adoption infrastructure.

Trust Will Become a Competitive Asset

As AI moves from generating content to acting inside real business processes, customers, partners, regulators, and boards will ask a different question.

Not “Is the AI capable?”

“Can I trust it to act?”

Companies that can demonstrate accountability, auditability, resilience, and controllability will be able to delegate more to AI with greater confidence.

That creates an advantage.

The winners may not be the companies that automate fastest. They may be the companies that can automate the most without losing control.

The Counter-Argument: Will This Slow Innovation?

It may, in some cases.

That is not necessarily a flaw.

High-consequence industries already accept that faster deployment is not always the highest-order objective. Aviation, financial markets, critical infrastructure, and pharmaceuticals all operate with controls because trust is a precondition for scale.

AI should be treated the same way.

The choice is not innovation or governance.

The real choice is between governed scale and unmanaged fragility.

A New Operating Principle for the AI Era

The operating principle I keep coming back to is simple:

AI should absorb execution. Humans should retain responsibility.

That does not mean keeping humans in every micro-decision. It means humans define the objective, set the boundaries, approve the authority, monitor exceptions, and remain accountable for consequences.

The future risk of AI will not be determined only by what machines can think.

It will be determined by what we allow machines to do.

So here is the question I would put to every board today:

Do you know how many AI agents in your organization can act, what each one can access, and who is accountable when one of them crosses a boundary?

If not, the governance gap is already larger than the technology gap.

What would you add to the board's agency test?

Subscribe to TechnologyTrends or share your perspective in the comments.

Sanjay K Mohindroo

AI adoption is not about automating the most work. Boards must decide which tasks AI should execute and which judgments humans must retain.

After three decades in enterprise IT, I have seen organizations repeatedly make the same mistake with new technology: they measure adoption before they define what success should actually mean.

AI is creating the biggest version of that mistake yet.

Boards are being shown numbers such as AI users, copilots deployed, hours saved, processes automated, and productivity gained. All useful measures.

But they avoid the harder question:

What part of the organization’s thinking are we handing over?

That question matters far more than how many employees are using ChatGPT, Copilot, or an AI agent.

The conventional wisdom today is that the organizations using AI most aggressively will win.

I think that is incomplete.

The organizations that win will be those that automate aggressively without outsourcing the judgment that creates competitive advantage.

AI Adoption Is Not the Same as AI Maturity

Consider a simple example.

Imagine an investigation involving 7,000 pages of documents, of which perhaps 1,000 contain material evidence.

A capable AI system can read, classify and correlate those pages much faster than a senior executive, lawyer, auditor or analyst ever could.

That is exactly what it should do.

But there are two very different ways to use it.

In the first:

“Read everything and tell me what happened.”

In the second, the human first establishes what appears important, develops an initial hypothesis, identifies relevant relationships and then asks AI to search the full corpus for evidence that supports, contradicts or completely overturns that reasoning.

The computational workload is largely the same.

The cognitive architecture is completely different.

In the first model, AI increasingly defines the problem and constructs the interpretation.

In the second, AI expands the human decision-maker’s ability to investigate the problem.

That distinction is the difference between cognitive substitution and cognitive amplification.

Boards should care about it.

The Wrong AI Metric: How Much Work Did We Eliminate?

The dominant enterprise AI conversation is still centered on efficiency.

How many hours did we save?

How many people can one AI-enabled employee replace?

How much faster can reports, code, presentations, or customer responses be produced?

Those questions are legitimate. They are simply not sufficient.

The more important question is:

Which human capabilities no longer get exercised because AI is now performing them?

Humans have always outsourced cognitive work.

Calculators outsourced arithmetic.

Spreadsheets outsourced large-scale calculation.

Search engines outsourced much of information retrieval.

GPS outsourced a significant amount of navigation.

AI is different because the range of cognition that can now be delegated is dramatically broader.

Research. Summarization. Analysis. Writing. Planning. Coding. Hypothesis generation. Evaluation. Increasingly, action itself.

The danger is therefore not that employees use AI too much.

Someone can use AI eight hours a day and remain intellectually sharp.

Another person can use it for thirty minutes and outsource the most important part of the decision.

The critical issue is not how much AI you use. It is what layer of cognition you delegate.

The Five Layers Boards Should Distinguish

I would separate enterprise cognitive work into five layers.

1. Execution

Formatting, transcription, routine correspondence, data cleaning, scheduling, document conversion, and repetitive processing.

Automate aggressively.

There is little strategic value in asking expensive human talent to continue performing work that machines can perform reliably.

2. Information processing

Searching, summarizing, extracting, translating, comparing, classifying, and organizing information.

Again, AI has enormous structural advantages.

This is where AI can remove hours of low-value cognitive labor.

3. Analysis

Pattern detection, anomaly identification, modelling alternatives, correlating information, generating hypotheses and exploring scenarios.

AI should play a major role here, but human scrutiny becomes increasingly important.

The machine can widen the search space. It should not automatically own the conclusion.

4. Problem framing

What problem are we actually trying to solve?

Which variables matter?

What are we optimizing?

Which assumptions are embedded in the question?

What information are we missing?

This is where leadership begins.

An organization that becomes excellent at answering badly framed questions faster has not become smarter.

5. Judgment

What should we believe?

What should we do?

Which trade-off is acceptable?

What risk are we prepared to take?

When should we act?

Who is accountable when the decision is wrong?

This is the layer organizations should be most careful about surrendering.

AI can inform judgment.

It can challenge judgment.

It can expose blind spots in judgment.

But accountability cannot be delegated to an algorithm simply because analysis has become automated.

AI-First Execution, Human-First Judgment

This leads to a principle I believe boards should consider explicitly:

AI-first execution. Human-first judgment.

This does not mean humans should approve every decision made by an AI system.

That would destroy much of the economic value.

If an AI agent can reconcile thousands of low-risk transactions accurately, there is no reason for a manager to manually approve each one.

Instead, human control moves upstream.

Management defines:

1.   the objective,

2.   the constraints,

3.   acceptable risk,

4.   decision rights,

5.   escalation thresholds,

6.   and accountability.

AI can then operate with considerable autonomy inside those boundaries.

That is a fundamentally stronger governance model than either extreme: humans approving everything or AI deciding everything.

A Four-Step Discipline for High-Stakes AI

For consequential work, I use a simple mental model:

Think → AI → Challenge → Decide

1. Think

Before opening the AI tool, establish an independent position.

What do I currently believe?

Why?

What evidence supports it?

What assumptions am I making?

What could prove me wrong?

Even five minutes of independent thinking creates something extremely valuable: a baseline against which the AI output can be tested.

Without that baseline, the first plausible answer generated by the machine can easily become the frame through which the entire problem is subsequently viewed.

2. AI

Now exploit what machines do exceptionally well.

Search more information than you could manually inspect.

Correlate documents.

Generate scenarios.

Find anomalies.

Compare alternatives.

Explore adjacent possibilities.

The objective is not to make the AI agree with you.

It is to expand the decision space.

3. Challenge

This may be the most underused part of enterprise AI.

Ask the model:

“What is wrong with this analysis?”

“What assumptions are unsupported?”

“What evidence contradicts the conclusion?”

“Assume my hypothesis is wrong. What would we expect to find?”

“What alternative explanation best fits the evidence?”

An AI system is potentially far more valuable as an intellectual adversary than as a confirmation engine.

4. Decide

Then turn the machine off mentally.

The final question should never be:

“What did the AI recommend?”

It should be:

“Having considered the evidence, what do we believe, what will we do, and who owns the decision?”

That is management.

The AI Strategy for an Expert Should Be Different

There is another mistake I see emerging.

Organizations are trying to create a single model of “AI literacy” for everyone.

That misses an important distinction.

A novice and an expert should not use AI in the same way.

A novice does not yet possess a strong mental model. If AI supplies the explanation, reasoning, and conclusion immediately, the novice may receive an excellent answer while learning surprisingly little.

For a novice, AI should behave more like a tutor.

Learn. Attempt. Receive feedback. Correct. Practice.

For an experienced practitioner, AI can be used more aggressively for research, comparison, analysis, preparation, and scenario generation.

For an expert, the opportunity becomes much larger.

An expert already possesses a mental model.

The real value of AI is then not merely answering questions faster. It is allowing the expert to test that mental model against vastly more information than was previously possible.

That means searching thousands of documents, exploring competing hypotheses, monitoring emerging developments, finding unexpected relationships, and attacking assumptions developed over decades of experience.

The optimal model is:

Expert mental model + AI computational breadth

Not:

AI mental model + human approval

The first amplifies expertise.

The second eventually commoditizes it.

The Counter-Argument: Why Not Let AI Make Better Decisions?

There is an obvious challenge to this argument.

What if AI eventually makes certain decisions more accurately than humans?

Then we should absolutely let it.

Machines already outperform humans in many narrow activities, and the boundary will continue moving.

The objective is not to preserve human involvement for sentimental reasons.

Nobody should manually read 7,000 pages merely to prove that humans remain useful.

The objective is to distinguish between decision execution and decision accountability.

If AI reliably makes a class of operational decisions better than people, automate them.

But somebody still needs to decide what the system is optimizing, which data it can use, how much risk it can accept, when exceptions require escalation and when the system should be stopped.

AI does not eliminate governance.

It moves governance upward.

The AI-Off Test

There is one simple test I would encourage senior leaders to apply periodically.

Take an important task that you or your team now perform with AI.

Remove the AI.

Then ask:

Can we still define the problem?

Can we identify the relevant evidence?

Can we develop hypotheses?

Can we challenge an argument?

Can we explain the underlying logic?

Can we make the decision?

If the answer is yes, AI is probably amplifying capability.

If the answer becomes, “I would need to ask the AI,” you may be creating dependency.

That does not mean stopping AI adoption.

It means recognizing which capability now requires deliberate maintenance.

Boards Should Measure Capability Amplified, Not Just Work Eliminated

The AI transformation will not be won by organizations that keep humans busy doing work machines can perform better.

Nor will it be won by organizations that automate everything merely because they can.

The competitive advantage will come from understanding the boundary.

Let AI perform the work your people do not need to become exceptional at.

Use it aggressively for scale, speed, retrieval, correlation, processing and repetitive execution.

But protect the human capabilities that determine whether the organization is making the right decisions in the first place: context, problem framing, judgment, purpose, risk acceptance and accountability.

The ultimate measure of AI success should therefore not simply be:

How much human work did we eliminate?

A better question is:

How much human capability did we amplify?

Perhaps that is the question boards should now be asking their CEOs and CIOs.

Where is AI making your organization smarter, and where might it quietly be making the organization dependent?

If this resonates, subscribe to TechnologyTrends or share how your organization is drawing the line between AI execution and human judgment.

Sanjay K Mohindroo

Digital India: When Digitization Does Not Translate into Better Governance.

India's digital transformation is one of the country's most visible governance stories of the past decade. Applications have moved online. Payments can be made digitally. Certificates sit in DigiLocker. Grievances can be filed from a phone. Government services that once required repeated visits to an office can increasingly be initiated from home.

Digital India was built around precisely this ambition. Its original vision included not just digital infrastructure, but "Governance and Services on Demand", integrated services across departments, electronic application tracking and greater public accountability.

There is little doubt that India has made enormous progress in building this digital infrastructure.

But there is a more uncomfortable question that deserves attention:

Has digitizing government actually made government more accountable to the citizen?

For many citizens, the answer can depend heavily on what happens after they press "Submit."

And this is where the gap between Digital India as infrastructure and Digital India as governance reform becomes visible.

A digital application is not the same as a digital service

Imagine a fairly ordinary interaction with government.

A citizen applies online for a license, certificate, approval, pension, benefit, or registration.

The portal accepts the application.

A reference number is generated.

Payment is taken digitally.

Documents are uploaded.

Verification is completed.

The dashboard shows that the application is "under process."

Then nothing happens.

The deadline passes.

The citizen checks the portal again. The status has not changed.

A helpline redirects the citizen to a department. The department asks the citizen to visit the office. The office says the file is with another officer. Emails are sent. A grievance is filed. Another reference number is generated.

Eventually, the citizen discovers that while the application process has been digitized, the accountability process has not.

This is perhaps the biggest unresolved challenge of India's digital-governance journey.

The front end may be twenty-first century.

The back end can still operate through files, discretion, departmental silos, follow-ups and personal intervention.

We may be measuring the wrong things

Government technology programmes naturally produce impressive numbers.

Number of users.

Number of applications.

Number of transactions.

Number of services available online.

Number of grievances disposed.

Number of villages connected.

These are useful indicators. But they are predominantly output indicators.

Citizens experience government through outcomes.

Was the licence issued?

Was the pension credited?

Was the certificate corrected?

Was the grievance genuinely resolved?

Did the citizen have to visit the government office despite completing the entire process online?

Was the application completed within the promised period?

Was someone accountable when it was not?

That distinction matters enormously.

Consider grievance redressal. CPGRAMS has become a large national digital grievance system. In July 2026 alone, Central ministries and departments received more than 2.20 lakh grievances and reported redressal of about 2.17 lakh, with the average disposal time during 2026 reported at 12 days.

Those numbers demonstrate impressive administrative capacity.

But government data also reveal why "disposed" and "resolved" should not automatically be treated as synonyms.

Between January 2025 and February 2026, approximately six lakh citizens provided feedback on grievances recorded as resolved on CPGRAMS. 69.8% rated the resolution satisfactory.

That is a useful achievement, but it also means that the disposal statistic alone cannot tell us whether the citizen believed the underlying problem was solved.

A governance dashboard that says "grievance closed" therefore tells us something.

A dashboard that says "citizen's problem resolved" tells us considerably more.

Digitization can make inefficiency more visible without eliminating it

One of the great advantages of digital government is traceability.

Paper files can disappear into administrative systems.

Digital applications leave timestamps.

The system knows when the citizen applied.

It knows when documents were submitted.

It often knows when verification took place.

It knows which department is handling the application.

It knows when the promised deadline expired.

That should fundamentally change accountability.

If a government system knows that an application was supposed to be completed on Monday and remains pending on Friday, why should the citizen need to lodge another complaint telling the government something its own database already knows?

Yet this remains a common design flaw in digital governance.

The government digitizes the citizen's obligation to apply, but not always the government's obligation to act.

The citizen is expected to upload documents on time.

The citizen must respond to queries on time.

The citizen must make payment correctly.

But when the government misses its own service timeline, the consequences can be far less automatic.

This is where technology risks becoming a digital layer placed on top of an unchanged administrative culture.

The problem is not simply technology

This is also why blaming portals alone misses the point.

A well-designed website cannot compensate for an unclear chain of responsibility.

An app cannot fix an approval process involving five departments that do not communicate with one another.

A dashboard cannot create accountability if no consequence follows when a deadline is breached.

Even the Government's Digital India framework recognized this from the beginning. Its e-Governance pillar called for processes and forms to be simplified and integrated, rather than merely converted into electronic versions.

This distinction is crucial.

Putting a fifty-year-old administrative process online does not automatically constitute administrative reform.

Sometimes it simply creates a digital version of the same bureaucracy.

Infrastructure itself illustrates the problem

The same principle applies beyond individual citizen services.

The Comptroller and Auditor General's 2026 performance audit of BharatNet examined whether one of India's flagship rural broadband programmes translated infrastructure expenditure into functioning connectivity and service delivery. The very existence of such performance audits highlights why implementation must be evaluated beyond headline rollout statistics.

The relevant question for a village is not merely:

"Has fibre been laid?"

It is:

"Does the connection work reliably, and can people actually use it?"

Similarly, the relevant question for a digital government portal is not:

"Does an online service exist?"

It is:

"Can the citizen complete the service successfully from beginning to end?"

The difference between infrastructure being created and infrastructure being usable is the same difference between government being digitized and government being digitally transformed.

This is why some citizens perceive digital governance as hype

When digital systems work, citizens experience something genuinely transformative.

A payment that once required standing in a queue happens in seconds.

A document that once required visiting an office can be downloaded immediately.

A benefit reaches a bank account directly.

These are real improvements and should not be dismissed.

But perceptions change dramatically when the digital system works only until it encounters administrative discretion.

If a citizen:

• applies online but must repeatedly visit the office;
• tracks an application but cannot discover why it is delayed;
• files a grievance but receives a standard response;
• appeals but must again pursue officials manually; or
• sees a statutory deadline expire without any automatic consequence,

the citizen understandably begins to ask what exactly has been transformed.

From that perspective, a portal can start looking like a digitized reception counter rather than a reformed government service.

And when policy communication celebrates transactions, registrations and applications while the citizen continues struggling for the underlying service, Digital India can be perceived as more hype than governance reform, even where considerable technological progress has genuinely occurred.

That perception should not simply be dismissed as cynicism.

It should be treated as feedback about programme design.

India already knows what the next step looks like

Interestingly, some governments have already experimented with a stronger model.

Haryana's Auto Appeal System, integrated with its Antyodaya SARAL service platform, is designed around a simple principle: if a designated officer fails to provide a notified service within the stipulated timeframe, an appeal can be generated automatically and escalated to higher authorities. DARPG describes the intended result as either satisfactory delivery of the service or fixing responsibility for the failure.

That changes the underlying philosophy.

The conventional model says:

Government misses deadline → Citizen must complain.

An accountability-by-design model says:

Government misses deadline → System must explain and escalate.

That is a far more powerful use of technology.

From Digital by Default to Accountability by Default

The next phase of Digital India should therefore not simply be about putting more services online.

It should be about making government commitments digitally enforceable.

Every major citizen service could have five basic features:

A clearly defined service timeline.

A named authority responsible for the application at every stage.

Automatic escalation when the timeline is breached.

A recorded reason whenever the government delays or rejects a service.

Public reporting based on actual citizen outcomes, not merely file disposal.

Then government dashboards could evolve.

Instead of reporting:

98% applications disposed

they could report:

91% services delivered within statutory time

4% completed after automatic escalation

2% pending beyond timeline

2% successfully appealed

1% rejected with recorded reasons

Citizen satisfaction: 84%

That would tell citizens and policymakers far more about how government actually functions.

The real test of Digital India

Digital India has already demonstrated that India can build technology at extraordinary scale.

The harder challenge now is institutional.

Can technology change the relationship between the citizen and the state?

Can it reduce discretion?

Can it eliminate unnecessary visits?

Can it identify where a file is stuck?

Can it ensure that deadlines mean something?

Can it make responsibility visible?

And most importantly:

Can it shift the burden of accountability from the citizen chasing the government to the government explaining itself to the citizen?

That should be the next benchmark for digital governance.

Because ultimately, citizens do not experience Digital India through the number of portals launched, transactions recorded, or dashboards created.

They experience it when they need something from the government.

If that service is delivered simply, transparently and on time, digital governance becomes meaningful.

If the citizen still has to chase files, locate officials, send repeated emails and physically visit offices after completing an online process, digitization may have changed the interface without changing governance.

The success of the next decade of Digital India will therefore depend less on whether more government becomes digital and more on whether digital government becomes accountable

Sanjay K Mohindroo

When IT accepts every business request, priorities blur and value suffers. A five-gate framework for better technology investment decisions.

After nearly three decades in enterprise IT, I have learned to be wary of one sentence that sounds wonderfully collaborative:

“IT will make it happen.”

It wins applause in the meeting. Six months later, it can leave the organisation with too many priorities, too much technology, diluted accountability, and very little clarity about what actually created value.

The conventional wisdom says IT must be an enabler. The modern CIO, we are told, should remove friction, support every business initiative, move faster, and never become the dreaded “Department of No.”

I think that advice has been taken too far.

When IT says yes to everything, it is not enabling the business. It is avoiding a decision the business needs to make.

And eventually, the business pays for it.

The Real Cost of an IT “Yes”

A request arrives from sales for a new customer platform.

Operations want workflow automation.

Finance wants better analytics.

HR wants another employee system.

A business unit has found an AI tool it wants deployed immediately.

Another team wants a custom application because the enterprise platform does not work exactly the way it would prefer.

Individually, almost every request can sound reasonable.

That is precisely the problem.

The question is rarely whether an initiative has some value. Most do. The real question is whether it creates more value than the alternatives competing for the same capital, management attention, technical capacity, and organisational change bandwidth.

That question cannot be answered by IT alone.

Yet organisations routinely behave as though it can.

A business sponsor makes a request. IT estimates it. Funding is somehow found. The project enters the portfolio.

Then another one enters.

And another.

Soon, the organisation has fifty “priority” initiatives, each with an executive sponsor and a compelling presentation explaining why it cannot wait.

At that point, priority has lost its meaning.

This is not an IT capacity problem. It is a management discipline problem.

Why Saying Yes Creates IT Portfolio Risk

For years, CIOs were encouraged to become more customer-centric. That was correct.

But internal customer service has sometimes been confused with internal order-taking.

They are not the same thing.

A good technology organisation listens carefully to the business. It understands urgency. It solves problems. It makes experimentation easier.

But it also protects the enterprise from fragmented investment, duplicated capability, unmanaged risk, and projects whose business case disappears the moment somebody asks who owns the outcome.

The strongest CIOs I have worked with and observed understand something important:

Their job is not to maximise the number of business requests IT fulfils. Their job is to maximise the business value created from technology investment.

Those are very different objectives.

One rewards activity.

The other demands choices.

Every IT Yes Has an Opportunity Cost

Boards understand this instinctively when discussing acquisitions, factories, markets, and capital expenditure.

Every investment competes with another investment.

Technology should be treated no differently.

If an organisation commits people and capital to Initiative A, those resources are no longer available for Initiative B.

Yet this opportunity cost is strangely absent from many technology discussions.

The conversation becomes:

“Can IT do this?”

That is the wrong question.

Given enough money, time, vendors, and people, IT can do an extraordinary number of things.

The better question is:

“Should this be one of the things we choose to do now?”

That changes the conversation completely.

It moves technology demand away from functionality and toward enterprise value.

It also forces one uncomfortable but necessary question:

If this becomes a priority, what stops being a priority?

If the answer is “nothing,” management has probably not prioritised anything at all.

The Hidden Cost of Unlimited IT Demand

The damage from excessive yeses is not limited to the IT budget.

It appears in at least five places.

First, strategic focus gets diluted.

The enterprise starts funding many reasonable ideas instead of a few important ones.

Second, delivery slows down.

More projects mean more dependencies, more governance, more vendor coordination, and more executive attention spread across competing programmes.

Third, complexity compounds.

A new platform or application may solve one department's immediate problem while creating additional integration, data, security, licensing, and support obligations for the enterprise.

The initial business case rarely prices that complexity correctly.

Fourth, accountability becomes blurred.

IT delivers the system, but the promised productivity improvement, revenue increase, cost reduction, or customer adoption never materialises.

Who owns the shortfall?

Too often, nobody.

Finally, important work gets crowded out by urgent work.

Cyber resilience, architecture simplification, technical debt, data quality, core platform renewal, and infrastructure modernisation are easy to defer because they rarely arrive with a business executive demanding action by Friday.

Until something breaks.

Then they suddenly become board matters.

The Five Gates Before IT Says Yes

I believe every material technology initiative should pass five simple gates before it receives a meaningful commitment of enterprise resources.

Not a fifty-slide business case.

Five questions.

1. What business outcome will change?

Start with the outcome, not the technology.

Not:

“We need an AI platform.”

Not:

“We need a new CRM.”

Ask:

What measurable business result should be different if we make this investment?

Revenue?

Cost?

Cycle time?

Customer retention?

Working capital?

Regulatory exposure?

Operational resilience?

If management cannot describe the result in business terms, the initiative is not ready.

There should also be a baseline. “Improve productivity” is not enough.

Improve it from what, to what, and by when?

2. Do the economics justify the investment?

Technology projects have visible costs and invisible costs.

Licences and implementation fees are visible.

Management time, process redesign, training, integration, security, data preparation, support, and future upgrades frequently receive less attention.

Then there is opportunity cost.

What could those same resources accomplish elsewhere?

A strong business case therefore asks not merely whether an initiative generates value.

It asks whether it is one of the best available uses of scarce enterprise resources.

That is a much higher bar.

3. Who owns the business outcome?

Every major technology investment needs a named business owner.

Not merely a sponsor who appears at steering committee meetings.

An executive who is accountable for the outcome.

If a new sales platform is supposed to increase conversion, sales leadership owns conversion.

If automation is supposed to reduce processing costs, operations owns the reduction.

IT should be accountable for technology delivery, resilience, security, and agreed service outcomes.

It should not become the default owner of benefits that depend on business behaviour.

Technology can enable change.

It cannot force a business unit to adopt it.

4. What new risk are we accepting?

Every technology investment changes the organisation's risk profile.

It may reduce one risk while creating another.

A cloud platform may increase agility while changing concentration risk.

An AI deployment may increase productivity while introducing data, decision, regulatory, or reputational exposure.

A new application may solve an immediate business problem while adding another dependency the enterprise must support for years.

Boards should ask a simple question:

What risk exists after this decision that did not exist before it?

The purpose is not to stop innovation.

It is to ensure enthusiasm does not temporarily suspend judgement.

5. What are we willing to stop?

This is the gate most organisations avoid.

It is also the most important.

Every major new priority should force a portfolio conversation.

What will we stop?

What will we delay?

What funding moves?

What leadership attention changes?

Without an explicit trade-off, portfolios expand until everything moves slowly.

A serious strategy is not a list of things an organisation wants.

It is a list of choices.

#ITGovernance is therefore less about controlling technology and more about forcing clarity about those choices.

The Board Should Not Approve Technology Shopping Lists

Another mistake is taking technology portfolios to boards as collections of programmes.

ERP transformation.

Cloud migration.

AI programme.

Data platform.

Cybersecurity upgrade.

Customer experience platform.

Those labels describe technology activity.

They do not describe why shareholders should care.

Boards should instead see the technology portfolio mapped to enterprise outcomes.

Which investments protect revenue?

Which lower structural cost?

Which create growth options?

Which address material risk?

Which simplify the operating model?

Which are mandatory?

And which are experiments that deserve limited capital until they prove themselves?

This framing makes one uncomfortable category visible: projects that consume substantial resources but have weak strategic justification.

That visibility is useful.

“But Won't Saying No Slow Innovation?”

This is the obvious counter-argument.

If every idea goes through governance, don't we risk becoming bureaucratic?

Yes, if governance is badly designed.

But that is not an argument for unlimited yeses.

It is an argument for different levels of commitment.

Small, reversible experiments should be easy.

A business team wanting to test an idea with limited cost, controlled data, and bounded risk should not need a six-month approval cycle.

Experiment quickly.

Learn cheaply.

Stop unsuccessful ideas without drama.

But an experiment becoming an enterprise commitment is a different decision.

That is when the five gates matter.

The distinction is important:

Speed should increase when decisions are reversible. Scrutiny should increase when commitments become expensive, difficult to reverse, or strategically consequential.

That is not bureaucracy.

It is sensible capital discipline.

Saying No Is Sometimes the Most Business-Friendly Answer

There is a reason executives dislike hearing “no” from IT.

Historically, some technology organisations earned a reputation for protecting their own convenience rather than enabling the enterprise.

That needed to change.

But the correction should not turn CIOs into order takers.

A mature technology leader sometimes needs to say:

“Yes, but not now.”

“Yes, if we stop something else.”

“Yes, provided the business owns the outcome.”

“Yes, as a limited experiment first.”

Or simply:

“No. The enterprise already has a capability that solves this problem.”

That is not obstruction.

That is leadership.

The most useful CIO in the boardroom is not the person who promises to make every request happen.

It is the person who helps leadership understand which technology decisions are worth making.

What CEOs Should Ask Their CIOs

A CEO does not need to become a technologist to improve technology decision-making.

Ask five questions at the next portfolio review:

1.   Which three technology investments matter most to our strategy, and why?

2.   What measurable business outcome does each one have?

3.   Which executive owns each outcome?

4.   What have we deliberately stopped or delayed to fund these priorities?

5.   Which projects would we cancel today if we had to rebuild the portfolio from zero?

The fifth question is particularly revealing.

Legacy priorities have a habit of surviving because stopping them requires a decision, while continuing them requires only inertia.

IT Demand Is Ultimately a Leadership Question

Technology portfolios do not become overloaded because businesses have too many ideas.

Ideas are supposed to be abundant.

They become overloaded because organisations lack the discipline to choose among them.

That distinction matters.

The CIO can bring transparency.

Finance can expose economics.

Risk teams can challenge exposure.

The board can demand evidence.

But enterprise leadership must ultimately decide what matters most.

IT saying “yes” should therefore never end the conversation.

It should mean:

Yes, this deserves scarce enterprise capital ahead of the alternatives.

That is a much more consequential statement.

And it should be treated as one.

After three decades around enterprise technology, I remain convinced that one of the most valuable services IT can provide is not faster agreement.

It is better decision-making.

Where has your organisation drawn the line between enabling business demand and simply accepting too much of it?

Subscribe to TechnologyTrends, or add your perspective in the comments, for more on cutting through the hype to what actually matters in IT.

Sanjay K Mohindroo

The IT-business partnership model is failing. The real issue is split accountability for outcomes, capital, trade-offs, and technology value.

Why the IT-Business Partnership Cliché Keeps Failing

The phrase I distrust most in a transformation meeting is: “IT needs to partner more closely with the business.”

After nearly three decades around enterprise technology, I have learned that this sentence often reveals the real problem. The organisation has already separated technology from business accountability, and is now trying to repair the gap with better relationships.

That rarely works.

The conventional wisdom says IT must become a “trusted business partner.” CIOs are encouraged to speak the language of business, sit closer to business leaders, understand commercial priorities, and become more collaborative.

All sensible advice.

But the premise is increasingly outdated.

If IT still needs to “partner with the business,” we are implicitly saying IT is not part of the business.

And in a company where customer experience, pricing, supply chains, risk, productivity, distribution, and increasingly the product itself depend on technology, that distinction is no longer harmless.

It creates an accountability problem.

The Problem Is Not Alignment. It Is Split Accountability.

I have seen versions of the same situation repeatedly.

A business leader owns an ambitious growth target. Technology is asked to build the capabilities required to support it. Finance approves the investment. Operations must change processes. Frontline teams must adopt new ways of working.

Then the initiative starts slipping.

The business says IT is moving too slowly.

IT says requirements keep changing.

Finance asks why the benefits have not appeared.

Operations says the solution does not fit reality.

Everyone was involved.

Nobody owned the whole outcome.

That is not a partnership failure in the interpersonal sense. The executives may have excellent relationships.

It is an operating model failure.

The organisation has assigned responsibility for the business outcome to one group, responsibility for the technology to another, responsibility for the money to a third, and responsibility for adoption somewhere else.

Then it holds meetings to create “alignment.”

No number of steering committees can compensate for badly designed accountability.

Why the IT-Business Divide Is Becoming More Expensive

Twenty years ago, it was at least possible to think of many technology decisions as support decisions.

Today, technology increasingly determines how the enterprise competes.

A decision about data may affect pricing.

A decision about architecture may determine how quickly the company can launch in a new market.

A decision about automation may alter the economics of an operating model.

A decision about cybersecurity may affect the organisation's risk exposure and even its licence to operate.

A decision about artificial intelligence may change workforce requirements, customer experience, intellectual property risk, and capital allocation simultaneously.

These are not merely IT decisions.

They are business decisions expressed through technology.

Yet many organisations still govern them using a structure inherited from an era when IT primarily kept systems running.

That is why the language of partnership has become misleading.

The CEO does not normally ask finance to “partner with the business” before deciding where capital should go. Finance is part of how the business makes that decision.

Technology increasingly needs to be treated the same way.

What a Fake IT-Business Partnership Looks Like

The warning signs are surprisingly consistent.

The business writes the requirements, then IT estimates the delivery date.

The business case contains revenue or productivity benefits, but technology is measured mainly on cost and delivery.

Projects are approved individually without examining what must be delayed or stopped to create capacity.

Business sponsors disappear once funding is approved and return when implementation problems appear.

IT is expected to say yes to strategic priorities that collectively exceed available capital, talent, or organisational capacity.

And when results disappoint, each function can produce evidence showing that it completed its part.

That last point matters.

A company can have excellent functional performance and poor enterprise performance at the same time.

The technology team can deliver the system.

The business team can conduct training.

Finance can keep spending within the approved envelope.

The programme can still destroy value.

The board should care about the last outcome, not whether each department can defend its own scorecard.

The Four Tests of a Real Technology Partnership

Rather than asking whether IT and the business are “aligned,” I would ask four harder questions.

A real partnership requires shared outcomes, shared capital, shared trade-offs, and shared accountability.

If one of those is missing, collaboration may be strong, but the partnership is largely ceremonial.

1. Do We Share the Outcome?

Every major technology investment should have a business outcome that both the business executive and technology executive are accountable for.

Not “implement the platform.”

Not “migrate the applications.”

Not “complete Phase 1.”

Those are delivery milestones.

The outcome might be reducing order-to-cash time, increasing conversion, lowering cost to serve, reducing operational risk, improving forecast accuracy, or allowing a product to reach market faster.

The important point is that the metric cannot belong only to the business while IT owns a separate technical measure.

If one executive succeeds when the system launches and another succeeds only when the business benefit appears, their incentives diverge exactly when the difficult decisions begin.

The board should ask a simple question:

What number will move if this investment works, and which two executives own that number together?

If the answer is unclear, the partnership is unclear.

2. Do We Share the Capital Decision?

Technology portfolios are capital allocation portfolios, whether companies describe them that way or not.

Every rupee, dollar, pound, or euro committed to one technology initiative is capital unavailable for another priority.

Yet many companies still treat technology demand as a queue.

Business units submit requests. IT estimates effort. Projects are ranked. Budgets are negotiated.

The uncomfortable discussion is often missing: What are we choosing not to do?

That question changes behaviour.

Take the kind of situation I have seen many times in large enterprises. Five business units each present a project that is individually defensible. Each promises revenue, productivity, risk reduction, or customer improvement.

The problem appears only when you consider them together.

They depend on the same scarce people.

They require overlapping organisational changes.

They compete for management attention.

And their combined benefits assume the business can absorb several major changes simultaneously.

The portfolio may be financially funded while being operationally impossible.

A genuine technology partnership therefore requires business and technology leaders to allocate capital together.

Approval cannot mean, “The business wants it, IT must find a way.”

Approval means accepting the opportunity cost.

3. Do We Share the Trade-Offs?

This is where many supposed partnerships break down.

Everyone agrees on priorities until something has to give.

A launch date is fixed, so scope must change.

A budget is constrained, so some capability must wait.

A risk threshold cannot be compromised, so speed must be sacrificed.

A new strategic priority appears, so an existing initiative must lose resources.

Someone has to make that trade-off.

Too often IT is expected to absorb it invisibly.

The organisation says everything is critical, then asks technology leaders to reconcile contradictory expectations through heroic execution.

That is not partnership.

That is avoidance.

The most mature executive teams I have worked around make trade-offs visible. They do not ask whether every priority can be delivered. They ask which combination of priorities produces the highest enterprise value within real constraints.

This sounds obvious.

It is surprisingly rare.

The board can test this by asking:

When the next priority enters the portfolio, who decides what moves down?

If the answer is “IT will work it out,” there is no shared prioritisation.

There is only delegated pain.

4. Do We Share Accountability After Go-Live?

One of the most damaging habits in enterprise technology is treating implementation as the finish line.

A system goes live.

The programme team celebrates.

The steering committee winds down.

Attention moves to the next initiative.

But business value often begins after implementation, not before it.

Adoption must happen.

Processes must change.

Management behaviours may need to change.

Old systems or manual workarounds may need to disappear.

Benefits need to be measured.

Sometimes the original assumptions need to be challenged.

This is where shared accountability matters most.

Technology leaders should not be able to say, “We delivered what was requested.”

Business leaders should not be able to say, “The technology did not deliver the benefits.”

Both statements may be technically true and strategically useless.

If the promised business result does not appear, the executive team should investigate the outcome together.

Was the original business case wrong?

Did adoption fail?

Was the product badly designed?

Did market conditions change?

Did the organisation automate a poor process instead of changing it?

Was the investment simply a bad decision?

That is the accountability conversation boards need.

Collaboration Is Necessary, but It Is Not Enough

There is an obvious counter-argument.

Companies still need specialist functions. Technology requires expertise, governance, architecture, security, resilience, engineering discipline, and operational control.

Absolutely.

Removing the artificial divide between IT and the business does not mean removing professional accountability.

The CFO still needs financial expertise.

The CHRO still needs people expertise.

The general counsel still needs legal expertise.

But nobody argues that finance, people, or legal issues somehow sit outside the business.

Technology should be no different.

The CIO must remain accountable for technology integrity, just as the business executive remains accountable for commercial and operational judgement.

What should disappear is the gap in between, where the enterprise outcome belongs to everybody in principle and nobody in practice.

Boards Should Stop Asking Whether IT Is “Aligned”

“Are IT and the business aligned?” sounds like a sensible governance question.

It is usually too soft.

Alignment can mean meetings happened.

It can mean roadmaps were presented.

It can mean stakeholders agreed that the project was important.

None of those guarantees value.

Boards should ask harder questions:

Who owns the business outcome?

Who owns the capital at risk?

Who has authority to make trade-offs?

What will stop if this becomes more important?

What measurable benefit must appear after implementation?

And which executives remain accountable if it does not?

Those questions quickly reveal whether technology is genuinely embedded in the business or merely supplying it.

The CIO Should Not Aspire to Be a Better Supplier

This is ultimately why I think the “business partner” ambition is too modest.

A supplier needs a good relationship with its customer.

A business leader shares responsibility for the enterprise.

Those are different standards.

The modern CIO should certainly understand markets, customers, economics, operations, and strategy.

But not because doing so makes IT more responsive to the business.

Because technology leadership is now part of business leadership.

Likewise, business executives cannot outsource their understanding of technology to the CIO.

A CEO who treats technology as something the CIO owns is increasingly making the same mistake as a CEO who says the CFO owns economics.

Specialists provide expertise.

Leadership owns consequences.

Stop Partnering. Start Owning.

The phrase “IT-business partnership” has survived because the intention behind it is good.

It asks two groups to work together instead of throwing requirements, deadlines, and blame across an organisational boundary.

But that boundary is now the deeper problem.

The next step is not better partnership theatre.

It is shared ownership.

Shared outcomes.

Shared capital decisions.

Shared trade-offs.

Shared accountability when the promised value does not materialise.

That changes the conversation from:

“Is IT supporting the business?”

to:

“Are we making the right business decisions about technology?”

That is a much harder question.

It is also the one that matters.

What has worked in your organisation: stronger IT-business partnership, or removing the distinction altogether and creating shared accountability?

If this is the kind of technology conversation you want more of, subscribe to TechnologyTrends and add your perspective in the comments.