The AI problem is no longer adoption. It is decision quality.

A few years ago, building a useful AI solution was difficult enough that technical feasibility acted as a natural filter.

You needed specialist skills, significant infrastructure, access to data, model expertise and usually a substantial budget.

That filter is disappearing.

Today, a team can connect an LLM to company data, build a retrieval-augmented generation system, automate a workflow or create an AI agent surprisingly quickly.

In many cases, the answer to the question:

“Can we use AI here?”

is now simply:

Yes.

But that is increasingly the wrong question.

The more important questions are:

• Should we use AI here?
• Is the workflow ready?
• Is the underlying data reliable?
• Would deterministic software be cheaper and more dependable?
• What happens when the AI is wrong?
• Who owns that outcome?
• What will the system cost when usage increases tenfold?
• What measurable business outcome are we actually improving?

As AI becomes easier to deploy, disciplined AI decision-making becomes more important.

The challenge is shifting from AI capability to AI judgement.

The barrier to building AI is falling

Generative AI has dramatically lowered the technical barrier to experimentation.

Developers can call sophisticated models through an API.

Business users can build workflows with low-code platforms.

Enterprise platforms increasingly include AI assistants, copilots and agents as standard functionality.

Retrieval systems can connect models to corporate information.

Agent frameworks make it possible for models to call tools, query systems and execute multi-step tasks.

This is an important development and it creates a new problem.

Organizations can now create AI solutions faster than they can determine whether those solutions make economic, operational or architectural sense.

A prototype can be impressive while the production system behind it is fundamentally flawed.

The demonstration may work.

The architecture may not.

The business case may not.

The operating model may not.

And the organization may discover those problems only after significant investment.

AI strategy is becoming a decision discipline

A good AI strategy should therefore not begin by asking which model, platform or agent framework an organization should adopt.

It should begin with the business decision.

Before approving an AI initiative, organizations should be able to answer eight fundamental questions.

1. Business outcome

What measurable problem are we trying to solve?

AI initiatives should be connected to an identifiable business outcome.

For example:

• reducing claims processing time,
• increasing sales conversion,
• improving customer response times,
• reducing administrative workload,
• identifying operational risk,
• improving forecast accuracy,
• or reducing cost per transaction.

“Deploying AI” is not an outcome.

Neither is “introducing an AI agent.”

Technology should be a means of achieving a result, not the result itself.

If the expected business outcome cannot be defined, it becomes difficult to justify the investment, evaluate performance or determine whether the system should continue operating.

2. Workflow readiness

AI cannot compensate indefinitely for a poorly understood process.

Before automating a workflow, organizations should understand:

• how the process currently operates,
• where decisions are made,
• what exceptions occur,
• which steps create value,
• and where bottlenecks exist.

Automating a broken process often produces a faster broken process.

Sometimes the correct first step is not AI.

It is process redesign.

AI becomes valuable after the organization understands where intelligence, judgement, classification or interpretation genuinely improves the workflow.

3. Data readiness

Most useful enterprise AI systems depend on organizational data.

That creates another fundamental question:

Can the system trust the information it receives?

Poor-quality data creates poor-quality decisions regardless of how capable the model is.

Organizations therefore need to understand:

• where the relevant data resides,
• who owns it,
• how frequently it changes,
• whether it is complete,
• whether it contains conflicting information,
• and whether the AI system is permitted to access it.

This is particularly important for systems using retrieval-augmented generation.

RAG can make AI responses more grounded.

It cannot make incorrect source information correct.

If the knowledge base is unreliable, the AI system will simply retrieve unreliable information more efficiently.

4. Architecture choice

This may be one of the most important questions in AI engineering:

Does this problem actually require AI?

The ability to connect an LLM to a database, build RAG or deploy an agent does not mean those components should automatically be used.

The architecture should use the simplest component capable of solving the problem reliably.

A useful hierarchy is:

CODE → RETRIEVAL → LLM → AGENT

Each step introduces additional capability.

It also introduces additional complexity.

Code

Use deterministic software where the rules are known.

Examples include:

• calculations,
• database validation,
• permission checks,
• workflow routing,
• reconciliation,
• business rules,
• and structured transformations.

If the correct answer can reliably be calculated, an LLM is usually unnecessary.

Retrieval

Sometimes the problem is simply finding the correct information.

Search, databases, APIs and retrieval systems may solve the problem more reliably than asking a language model to reason about it.

LLM

LLMs become valuable where the task involves ambiguity, interpretation or unstructured information.

Examples include:

• summarisation,
• classification,
• extracting meaning from text,
• analysing qualitative information,
• drafting responses,
• and synthesising multiple sources.

Agent

Agents become useful when the system needs to decide what actions to take and coordinate multiple tools or systems.

This can be powerful.

But agents also introduce additional operational risk because the system is no longer merely generating information.

It is taking actions.

The design principle should therefore be simple:

Move up the stack only when the simpler component cannot reliably produce the required outcome.

The most sophisticated architecture may contain less AI

Consider a company processing 20,000 supplier invoices each month.

An AI-first architecture might propose an autonomous agent that:

1. reads the invoice,
2. identifies the supplier,
3. calculates tax,
4. validates the purchase order,
5. determines the approval path,
6. posts the transaction,
7. and handles exceptions.

That sounds sophisticated.

But it may be unnecessarily complicated.

A better architecture could look like this:

Invoice capture

Use OCR or document extraction.

Supplier identification

Use a supplier database lookup.

Tax and amount validation

Use deterministic business rules.

Purchase order matching

Use SQL queries or ERP validation.

Approval workflow

Use an existing workflow engine.

Exceptions and ambiguous cases

Use an LLM to interpret unusual descriptions, missing information or unstructured correspondence.

In this design, AI is used selectively.

Most of the workflow remains deterministic.

That often produces a system that is:

• cheaper,
• easier to test,
• easier to audit,
• more predictable,
• and easier to operate.

The sophisticated architecture is therefore not necessarily the architecture containing the most AI.

It is the architecture that uses AI only where probabilistic reasoning creates value.

5. Economics

AI prototypes can hide their true cost.

A small pilot may involve a few users generating a few thousand model calls.

Production may involve thousands of users, automated agents and millions of interactions.

Organizations therefore need to model the economics early.

That includes more than model API pricing.

The total cost may include:

• inference,
• embeddings,
• vector storage,
• integration,
• orchestration,
• monitoring,
• security,
• infrastructure,
• human review,
• evaluation,
• model updates,
• and operational support.

Agentic systems can make this especially important.

A single user request may trigger multiple model calls, searches and external tool interactions.

The correct metric may therefore not be:

Cost per model call.

It may be:

Cost per completed business outcome.

That could mean:

• cost per claim processed,
• cost per sales enquiry resolved,
• cost per invoice handled,
• or cost per customer interaction.

AI economics should ultimately be connected to business economics.

6. Risk

Every AI system should also be designed around a simple question:

What happens when it is wrong?

The answer determines the level of control required.

An AI system drafting internal meeting notes presents a very different risk profile from a system:

• recommending medical treatment,
• approving financial transactions,
• making hiring decisions,
• controlling infrastructure,
• or communicating regulated advice.

Organizations should therefore consider both the probability and impact of error.

Higher-impact systems require stronger controls.

Those controls may include:

• human review,
• constrained outputs,
• approved data sources,
• permission boundaries,
• audit logging,
• model evaluation,
• validation rules,
• fallback processes,
• and escalation procedures.

AI governance should not exist simply to slow AI adoption.

Its purpose is to define where autonomy is acceptable and where controls are necessary.

7. Accountability

One of the most difficult questions in AI governance is remarkably simple:

Who owns the decision?

When a traditional software system produces an incorrect calculation, ownership is usually relatively clear.

AI systems can make accountability less obvious.

The vendor provides the model.

Technology operates the platform.

A business function supplies the data.

Another team designs the prompt.

An employee accepts the recommendation.

Who owns the outcome?

Organizations need explicit accountability for:

• the business process,
• the AI system,
• the data,
• the controls,
• the risk,
• and the resulting decisions.

Without that accountability, AI governance becomes everybody's responsibility and therefore nobody's responsibility.

8. Operating model

The final question is often overlooked during experimentation:

Who will operate this system after launch?

AI systems require ongoing management.

Models change.

Business processes change.

Data changes.

Costs change.

Regulations change.

User behaviour changes.

A system that worked well during a three-month pilot may gradually become less reliable.

Organizations therefore need an operating model for:

• monitoring,
• evaluation,
• cost management,
• incident response,
• data maintenance,
• model changes,
• access control,
• and continuous improvement.

AI is not simply something an organization builds.

Increasingly, it is something an organization must operate.

Why good models still produce bad AI investments

Many AI initiatives will fail over the next few years.

Not necessarily because the models are weak.

The models will probably continue becoming more capable.

Projects will fail because the surrounding decisions were poor.

The problem did not warrant AI.

The underlying process was broken.

The data was unreliable.

The architecture was unnecessarily complex.

The economics were misunderstood.

The risks were underestimated.

Ownership was unclear.

Controls were missing.

Or nobody planned how the system would operate after the pilot.

These are not primarily model problems.

They are architecture, governance and management problems.

From AI experimentation to AI portfolio management

As organizations deploy more AI, the challenge will also move beyond evaluating individual use cases.

Executives will need to manage an AI portfolio.

That means asking:

• Which initiatives deserve investment?
• Which should remain experiments?
• Which should be scaled?
• Which should be redesigned?
• Which should be stopped?
• Where should the organization accept AI risk?
• Where should deterministic systems remain in control?
• What capabilities should be built internally?
• What should be purchased?
• And where is AI genuinely producing measurable value?

This is where AI strategy becomes closely connected with enterprise architecture, operating model design, investment governance and financial management.

The organizations that perform well will not necessarily be those deploying the greatest number of AI tools.

They will be those making the highest-quality decisions about where AI belongs.

The next competitive advantage may be judgement

AI capability is becoming widely accessible.

Models are becoming commoditised.

Development tools are improving.

Enterprise software vendors are embedding AI everywhere.

That means simply having access to AI will increasingly provide little competitive differentiation.

The differentiator will be organizational judgement.

Knowing:

where AI should be used,

where it should not be used,

how much autonomy it should receive,

how the economics work,

what risks are acceptable,

and what business outcome justifies the investment.

The question is no longer whether organizations can build AI systems.

Increasingly, they can.

The question is whether they can make good decisions about them.

AI strategy should not start with tools.

It should start with disciplined decisions.