Are Companies Really Ready for AI? The Real Problem Is Not the Technology

Most companies are nowhere near ready for AI.

Not because they lack licences, pilot projects or employees experimenting with generative tools. Many are already using AI extensively.

The deeper problem is that they cannot clearly describe what they want AI to improve.

They ask for greater productivity, faster innovation, better decisions and lower costs. But when those ambitions are translated into operational questions, the uncertainty quickly becomes visible.

Which work should improve?

Where does it currently fail?

Who owns the process?

What information does it depend on?

What measurable outcome should change?

How will the organisation know whether the change was successful?

AI is powerful when it receives a clear problem, relevant context, appropriate boundaries and a way to verify its output. It is far less useful inside an organisation whose goals, processes and responsibilities are poorly understood or constantly shifting.

You cannot optimise what you do not understand.

And scaling the wrong activity does not make it valuable. It only makes the mistake larger, faster and harder to detect.

The real problem is organisational chaos

Discussions about AI readiness often begin with technology.

Does the company have enough data?

Has it selected the right platform?

Which AI provider should it use?

Are employees sufficiently trained?

How quickly can the organisation deploy an assistant, a copilot or an agent?

These questions matter, but they are frequently asked too early.

The more fundamental question is whether the organisation understands itself.

In conversations with businesses, I have repeatedly found that the hardest problem is not selecting an AI provider. It is establishing a sufficiently stable and shared understanding of what the organisation is trying to achieve.

Many organisations are, in practice, opaque systems held together by inherited routines, informal relationships, local workarounds and a small number of people who know where the bodies are buried.

They have found a few things that work well enough to retain customers, deliver products and remain in business. Their continued existence can create the impression that the underlying organisation is coherent.

But ask the organisation to describe itself in operational terms and the picture often becomes less convincing.

What problems does it solve for customers?

How is value actually created?

Which processes are critical?

What are the most important dependencies?

Where do delays, risks and unnecessary costs arise?

Which decisions are made, by whom and using what evidence?

How do strategic priorities translate into projects and daily work?

In many organisations, answering those questions would require weeks of meetings, document gathering and internal negotiation. By the time the resulting material had been assembled, reviewed and approved, parts of it would already be outdated.

This is not simply a documentation problem.

It is a problem of organisational self-awareness.

The organisation may have strategies, process maps, quarterly reports and polished presentations, but those artefacts do not necessarily describe how the business actually operates. They may instead describe how different departments, managers or functions wish to be perceived.

This creates a dangerous situation when AI is introduced.

AI can help people produce more reports, presentations, diagrams, plans and analyses. It can make the organisation appear more structured without making it more coherent.

It can automate the production of convincing descriptions of work that remains poorly understood.

Telling such an organisation to “scale AI” is like looking at TV static and deciding that the solution is to make the screen larger.

The result is more visible activity, but not necessarily a clearer signal.

What operations taught me about organisational clarity

My view of AI readiness does not come only from the recent development of generative AI.

It has grown out of years spent working with operational IT, infrastructure, troubleshooting, monitoring, cybersecurity, automation and direct conversations with businesses about how they work and what they are trying to accomplish.

Although much of my work was centred on IT operations, the processes involved rarely ended at the boundary of the IT department.

Technical environments supported order flows, logistics, sales processes, marketing activities, distributor integrations, customer service, finance and reporting. A failure in one system could appear elsewhere as a delayed delivery, a lost sales opportunity, an interrupted customer journey or an inability to make a business decision.

Working in operations therefore required more than an understanding of individual systems. It required an understanding of how information, responsibilities and work moved across the organisation.

It also meant involving people from different parts of the company.

Logistics could explain what happened after an order entered the system.

Sales could identify where information or handovers failed during the customer process.

Marketing could show how campaigns depended on data, platforms and timing.

Distributors and external partners could reveal dependencies that were barely visible from inside the organisation.

The technical system and the business process were not separate realities. They were different views of the same operational chain.

In operational environments, ambiguity has consequences.

A service may be fully available, degraded under load or failing intermittently, and each of those states calls for a different response.

A dependency may respond normally, respond too slowly to be useful or time out only under particular conditions.

A backup may restore completely, restore partially or fail in ways that are discovered only when the restore is actually needed.

An alert represents a meaningful condition, an incomplete rule or meaningless noise.

When something goes wrong, the organisation must be able to identify what changed, which components and business activities are affected, what actions are safe and whether the intervention solved the problem.

Operational confusion cannot remain theoretical for very long.

As a systems specialist responsible for operational delivery, one of my tasks was to document our work so clearly that another person could take over without depending entirely on the individual who had built the environment or solved the previous incident.

We used what I think of as the “Kalle Svensson test”, using an intentionally ordinary Swedish name for a competent colleague who had not built the environment. Could a suitably competent outsider operate and troubleshoot it using the documentation?

This was an ideal rather than a literal expectation. Complex environments still require competence, training and judgement.

But the principle mattered.

The knowledge could not be allowed to exist only in the mind of the person who had built the system, discovered a hidden dependency or happened to remember what had solved a similar problem several years earlier.

The Kalle Svensson test

The immediate benefit of documenting to that standard was continuity.

If a key person was absent, changed role or left the organisation, the environment still needed to be operated. Documentation therefore acted as an operational backup and as protection against excessive dependence on individual employees.

But the more important result appeared during the documentation process itself.

To explain a procedure clearly enough for another person to follow it, we had to make implicit knowledge explicit.

Instructions such as these were not sufficient.

“Restart the usual service.”

“Check the server that normally causes the problem.”

“Ask Anders, he knows how it works.”

We had to identify the actual service.

We had to explain the relevant dependencies.

We had to define which signals should be examined.

We had to describe what a successful outcome looked like.

We had to document likely failure conditions, alternative paths and escalation points.

Normal operation was only half of the problem. The documentation also had to support troubleshooting.

A basic procedure may say:

1. Perform action A.
2. Continue with action B.
3. Complete action C.

A useful operational procedure also needs to answer further questions.

What evidence shows that action A succeeded?

What should the specialist examine if action B fails?

Which other systems could have caused the failure?

Which actions are reversible?

When should the work stop and be escalated?

How can the environment be returned to a safe state?

This forced us to lift the process out of the specific incident or the memory of an individual employee.

We moved away from “This is how we solved that particular problem.”

We moved towards “This is the type of problem, these are its likely causes, these are its observable signals, these are the available actions and this is how we determine whether the result is correct.”

This taught me that documentation is not merely a record of operational knowledge. The act of producing it is one of the ways an organisation discovers whether that knowledge is coherent in the first place.

That shift is fundamental to AI readiness.

A company that cannot reliably transfer operational knowledge to another human being will struggle to delegate work reliably to an AI system.

Documentation is a model of the business

Good operational documentation is more than a collection of instructions.

It is a model of how the organisation believes its systems and processes work.

Once a process has been made explicit, it can be reviewed from perspectives beyond the immediate operational task.

A steering group can see where dependencies create risk.

Management can identify activities that require disproportionate effort.

Decision-makers can see where capacity, investment or organisational change may be needed.

Security teams can identify weak controls and unclear responsibilities.

Automation teams can evaluate whether parts of the process are sufficiently stable and well-defined to be automated.

The process has been lifted out of the specific situation and becomes a bridge between execution and governance, translating daily work into something that can be examined, questioned and improved at a strategic level.

This is why documentation should not be treated as administrative residue produced after the real work has been completed.

Creating the documentation is part of understanding the work.

The attempt to describe a process often reveals that the process is not as orderly as people assumed. It exposes hidden dependencies, contradictory expectations and areas where different employees perform the same task in incompatible ways.

That discovery is valuable.

An organisation cannot govern what it cannot see.

Documentation describes. Observability tests.

Documentation alone is not enough.

A process description tells us how the organisation believes a system should behave. Monitoring, telemetry, alerts, incidents and actual outcomes show us how it behaves in reality.

This distinction became central in my work with monitoring and alert handling.

A documented architecture may appear clean and logical. The operational signals may reveal something very different.

A service may fail repeatedly after a particular dependency slows down.

An alert may be triggered so frequently that employees stop treating it as meaningful.

A manual workaround may have become part of normal operations without ever being included in the formal process.

A system considered non-critical may turn out to affect several business-critical workflows.

A team may meet its local performance target while creating delays and additional costs elsewhere in the organisation.

Observability provides a continuing test of the organisation’s own description of itself.

The same principle applies beyond technical systems. Targets, customer outcomes, delivery times, costs, handovers and recurring exceptions all produce signals about whether a process works as management believes it does.

A company may have an approved process map showing a smooth handover between departments, while actual delivery data shows repeated delays and informal escalation.

It may report that a customer-facing process is efficient while complaints, corrections and manual interventions indicate otherwise.

It may celebrate the number of initiatives launched while being unable to demonstrate that those initiatives improved a meaningful business outcome.

This creates a feedback loop:

1. Describe the system or process.
2. Observe its actual behaviour.
3. Detect meaningful deviations.
4. Investigate the causes.
5. Apply an action.
6. Verify the outcome.
7. Improve the model and documentation.

A mature organisation does not assume that its process descriptions remain correct because they were approved six months ago. It continuously compares them with evidence from the real environment.

AI systems need the same connection to reality.

An AI-generated recommendation should not be judged by how clear, confident or well-written it sounds. It should be evaluated against observable facts, defined objectives and the result of any action taken.

Without observability, AI can produce persuasive output while the underlying process continues to fail.

Observation reveals how the process actually behaves. It does not, by itself, determine who may act, what may change or who remains accountable.

Governance assigns ownership, defines permitted actions, establishes approval and escalation paths and determines how responsibility is maintained.

Only when an organisation can both observe the process and govern its boundaries is it ready to automate it safely.

You cannot automate what you cannot explain

Automation does not eliminate ambiguity. It turns ambiguity into executable behaviour.

If the underlying process is unclear, automation does not resolve the uncertainty. It embeds it in a system that can repeat the mistake at speed and scale.

A human specialist can sometimes compensate for an unclear process by using experience, context and intuition. The specialist may recognise that a documented rule should not be followed in a particular situation.

They may know that a certain alarm is usually harmless, that a formally correct action would create a downstream problem or that a particular stakeholder must be contacted before anything is changed.

An automated system requires greater precision.

To automate a process safely, the organisation must define:

• what triggers the process
• which information is relevant
• what constitutes a normal condition
• what constitutes a meaningful deviation
• which actions are permitted
• which actions require approval
• how exceptions should be handled
• how the outcome should be verified
• when the process must be stopped or escalated
• how errors can be reversed or contained

Automation therefore becomes a test of whether the organisation truly understands the process.

It is easy to describe a workflow as simple while a skilled employee quietly resolves dozens of undocumented exceptions. Once the organisation attempts to automate the workflow, those exceptions become visible.

Sometimes the discovery is that the process can be automated.

Sometimes only a stable and repetitive portion should be automated.

Sometimes the conclusion should be that the process must first be redesigned.

This applies even more strongly to AI agents.

An agent may be able to analyse information, select tools and adapt its actions dynamically. That flexibility can be useful, but it does not remove the need for boundaries.

The organisation still needs to define the operating boundaries.

What is the agent authorised to do?

Which systems may it access?

Which decisions may it make independently?

Which actions require human approval?

What evidence must it preserve?

How will its conclusions and actions be reviewed?

What happens when its confidence is low, its information is incomplete or one of its tools fails?

Without these controls, the organisation has not created intelligent automation.

It has created uncertain delegation.

From alerts to situational awareness

My work with cybersecurity and security operations centre (SOC) automation demonstrated how individual signals can be transformed into broader operational understanding.

A single security alert rarely provides the complete picture.

Its importance depends on context.

Which asset is affected?

How critical is that asset to the business?

Has similar activity occurred elsewhere?

Is the behaviour part of a known pattern?

Which vulnerabilities are present?

What other systems depend on the affected component?

Is the signal consistent with normal activity, or does it represent a meaningful deviation?

Exploratory data analysis allowed us to move beyond predefined alerts and examine concentrations, correlations, recurring incident types and unusual behaviour that were not always visible event by event.

This supported a transition from basic alert handling towards situational awareness.

Instead of asking only “What alerts do we have?”, we could ask “Where are the most significant threats and vulnerabilities right now?”

That is a more valuable question, but it requires a richer system.

An AI agent attempting to answer it needs access to current and relevant sources, consistent concepts, information about assets and dependencies, risk criteria and evidence that can be traced back to the original data.

Agents need systems, not just models

Organisations often discuss AI as if the model itself were the complete solution.

But a useful operational agent depends on much more than model intelligence.

It may require:

• reliable and current data sources
• access controls
• asset and dependency context
• business criticality
• consistent terminology
• retrieval mechanisms
• prioritisation rules
• constrained tool access
• explicit state transitions
• audit trails
• human review points
• independent verification
• safe failure behaviour

A proprietary frontier model may offer sophisticated reasoning, but it cannot infer an organisation’s missing governance structure.

A locally operated small language model may have less general capability, but it can still be valuable for focused classification, routing, summarisation or analysis when the task and context are well-defined.

The appropriate choice depends on the problem.

In some cases, a local small language model can perform the entire task, particularly where information should remain inside a controlled environment.

In other cases, a frontier model may be justified because the task depends on stronger reasoning, broader context handling, greater adaptability or more advanced language and multimodal capabilities.

But the boundary between these categories is moving quickly.

Recent open-weight releases are narrowing the gap with proprietary frontier systems on selected tasks, including coding and reasoning. Their relative capability varies by workload, evaluation method, tooling and deployment conditions, and the ranking continues to change as new models arrive.

Some can be downloaded and operated under an organisation’s own controls, subject to their individual licence terms and infrastructure requirements.

Open weights, however, do not automatically mean easy local inference.

Highly capable models still turn self-hosting into a substantial infrastructure and operations problem. Quantisation, distributed inference and specialised serving architectures may reduce the burden, but they do not make compute and memory requirements disappear.

You may control the model.

You still need enough iron to run it.

An externally hosted frontier model may therefore remain the more practical choice when a task requires greater capability, lower operational complexity or access to compute that would be unreasonable to maintain internally.

But it may also be desirable not to build the entire solution around a particular frontier model.

Capabilities are advancing rapidly. A model that appears indispensable today may be overtaken, renamed, restricted, repriced or commercially deprioritised tomorrow, and workflows built too tightly around one model or provider inherit that fragility as lock-in.

How serious the risk becomes depends on how much responsibility sits inside the model. If it is expected to interpret ambiguous situations, plan the work, choose tools and verify its own results, replacing it changes the behaviour of the whole system. If the orchestration is explicit and deterministic, with structured inputs, constrained tool access, policy checks and independent verification, the dependency shrinks and the model becomes a capable but replaceable component rather than the workflow itself.

That is not an argument against frontier models. Some tasks genuinely depend on the strongest available reasoning and broadest context handling, and replacing that capability with rigid rules produces a system that is portable but ineffective.

The architectural question is not whether the model should be intelligent. It is how much responsibility should sit inside the model, and how much should remain explicit, testable and portable outside it.

The model should be a powerful component of the architecture, not the architecture itself.

Protecting sensitive information

Using AI with operational, security or personal data does not have to be an all-or-nothing choice between avoiding AI entirely and sending the entire dataset to an external provider.

The architecture can be adapted according to:

• the sensitivity of the information
• the purpose of the processing
• the capability required
• where processing may occur
• how consequential the output may be
• how the result will be reviewed and verified

Personally identifiable information and other sensitive fields can sometimes be removed, minimised, anonymised, pseudonymised or replaced with tokens before processing.

These methods should not be treated as identical.

True anonymisation aims to prevent individuals from being reasonably reidentified.

Tokenisation replaces sensitive values with references, while the original values may remain in a separate protected system. Tokenised or pseudonymised information may therefore remain sensitive and require appropriate controls.

Removing a name is not automatically the same as removing identity.

When the whole task can remain inside a controlled local environment, the organisation avoids exposing the material to an external model provider. That narrows the question of exposure rather than removing it, because the local environment still needs its own security, access control and governance.

In other cases, a hybrid design may use local components to filter information, classify material, remove unnecessary fields or separate identifying data before a more capable external model receives a reduced and protected context.

An organisation may choose among:

• a focused local small language model
• a larger self-hosted open-weight model
• an externally hosted frontier model
• several specialised models
• a hybrid workflow combining deterministic components and AI services

Each option creates different requirements for infrastructure, security, cost, portability and governance.

The guiding principle should remain simple.

Give the AI system the information it needs, not every piece of information the organisation possesses.

The organisation should know:

• what information is being processed
• why it is required
• where processing occurs
• which model or AI provider is involved
• which information remains local
• how identifying data is separated or protected
• who can reconnect tokens with original values
• how outputs are verified
• whether the system influences consequential decisions
• who remains accountable when the result is wrong

These are not secondary compliance questions to address after the AI initiative has been designed.

They are part of the design.

A secure and resilient AI system is not created by placing a privacy statement around an uncontrolled data flow or by attaching an organisation’s future to whichever model currently leads a benchmark.

It is created by deliberately controlling data, responsibilities, boundaries, dependencies and verification.

AI is not one discipline

The same lack of clarity often becomes visible when companies recruit people to work with AI.

AI is not one role, one profession or one type of problem.

It reaches deeply into the human and organisational dimensions of a company, including how goals are formulated, how decisions are made, how responsibilities are assigned, how employees adopt new ways of working and where human judgement must remain in control.

It is also used as a technical tool. AI may generate code, classify events, query operational data, integrate systems, support security analysis or act through tools and APIs.

These areas overlap, but they are not the same.

Someone who can use an AI coding assistant is not automatically qualified to redesign an organisation’s decision-making processes.

Someone with experience in organisational change and AI adoption is not automatically qualified to architect a secure agentic system.

The organisation must therefore understand the work before defining the role.

Too many AI job descriptions combine strategy, software engineering, data architecture, machine learning, cybersecurity, governance, product management, change leadership and commercial responsibility into a single position.

The result is less a job description than a search for an AI-shaped unicorn.

Those responsible for hiring cannot delegate this confusion to the candidates. They are accountable for deciding which capability the organisation actually needs, how it relates to existing teams and what authority the person will have.

Before asking candidates to bring artificial intelligence into the organisation, the hiring process may need to demonstrate a little organisational intelligence of its own.

Imagine if offices adopting printers during the 1970s and 1980s had insisted that the person leading the introduction must also be a mechanical engineer, electronics specialist, network architect, maintenance technician, information-governance expert, trainer and business-process designer.

Yes, that is an exaggeration, but you see the point.

Somebody needed to understand how the technology worked. Somebody needed to integrate and maintain it. Managers needed to decide how it would support the organisation. Employees needed to understand the documents, information and tasks involved.

Those were related responsibilities, but they were not one job.

The same distinction applies to AI.

An organisation may need expertise in models, data engineering, security, governance, integration, process design, change leadership and the relevant business domain. That does not mean every capability should be compressed into one supposedly complete AI professional.

Nor does every employee using an AI-enabled tool need to understand model architecture or build agentic systems. Those who design, integrate, secure and govern such systems will require deeper and more specialised capabilities.

AI competence should therefore be defined in relation to the role and the task:

• using an AI-enabled workplace tool
• redesigning a business process
• leading organisational adoption
• creating software with AI assistance
• integrating models and business systems
• developing automated or agentic workflows
• protecting data and managing security
• evaluating outputs, risks and business outcomes

Treating all of these as the same kind of “AI experience” produces both inflated job requirements and dangerously incomplete teams.

A company that does not know which kind of AI capability it needs is not yet ready to decide whom it should hire.

Which companies benefit most from AI?

The companies receiving the greatest benefit from AI often appear to be the same companies that already understand what they are doing.

They can explain:

• which problems they solve for customers and why their solution is valuable
• which limitations exist in the current approach
• what objectives they are pursuing and how those objectives are measured
• which obstacles prevent progress and which strategies address them
• which projects and daily work implement those strategies, who performs the work and what it costs
• how the results are evaluated

This does not mean their answers never change. Healthy organisations adapt strategies, systems, processes and sometimes even business models. The difference is that their changes are traceable. They can describe what changed, why it changed and what evidence motivated it.

Organisational stability should not mean rigidity. It should mean continuity of reasoning.

By contrast, organisations that are drifting often recreate their own story every quarter. Goals, priorities and measures change repeatedly, not because the environment has been carefully reassessed, but because different groups are attempting to present themselves favourably.

AI may make this behaviour more efficient.

It can help the organisation produce more polished explanations, more ambitious plans and more impressive dashboards.

But polished inconsistency remains inconsistency.

AI will widen the gap

AI reduces the cost of producing text, code, analysis, plans and recommendations.

As the cost of execution falls, the value of problem formulation, judgement, prioritisation and verification increases.

This will widen the gap between coherent and incoherent organisations.

A coherent organisation can use AI to accelerate a process that already has:

• a meaningful purpose
• defined ownership
• useful data
• operational boundaries
• observable outcomes
• feedback and correction

An incoherent organisation may use the same technology to accelerate contradictory initiatives, local optimisation, administrative theatre and poorly understood risk.

AI acts as a multiplier.

It can multiply capability, but it can also multiply confusion.

Smaller companies may gain a particular advantage because they often have shorter decision paths and lower coordination costs. A small, focused organisation can sometimes describe its customers, value creation and workflows more clearly than a large institution with multiple layers of management.

But small companies are not automatically mature. They can be highly person-dependent, reactive and poorly documented. The advantage belongs not to small companies as a category but to organisations with high clarity and low coordination friction.

A large coherent company may achieve extraordinary scale with AI.

A small coherent company may operate with the reach of a much larger organisation.

A small chaotic company may produce mistakes faster.

A large chaotic company may institutionalise them.

What boards should ask

A board should begin by challenging the assumptions behind an AI initiative.

What problem is the organisation actually trying to solve?

What evidence suggests that AI is an appropriate part of the solution?

What needs to be true for the initiative to create value?

Which risks, dependencies and changes in responsibility does it introduce?

By testing these assumptions, the board can determine whether the organisation understands the proposed initiative well enough to pursue it responsibly and productively.

This is also where the necessary AI-related understanding becomes visible. The board must be able to question the organisation’s choices, recognise when important issues have been left unresolved and ensure that accountability does not disappear behind technical language or external expertise.

Before asking how much the company should invest in AI, a board should ask eight questions.

1. What concrete business problem are we trying to solve?

Is the objective specific enough to guide action, prioritisation and evaluation, or is the organisation merely pursuing a general ambition to “use more AI”?

2. How does the relevant process actually work today?

Is the answer based on operational evidence, or on an approved presentation of how the process is supposed to work?

3. Where does the critical knowledge reside?

Is it documented, transferable and reviewable, or concentrated in the heads of a few employees?

4. Can we observe and measure the result?

Do we have meaningful signals showing whether the process works, whether an intervention created value and whether the organisation’s assumptions remain valid?

5. What may be automated, and what requires human judgement?

Have permissions, exceptions, escalation paths and human control points been explicitly defined?

6. What information will the AI system use, and how is it protected?

Does the system receive only the information required for the task? Is the organisation deliberately choosing between local processing, external providers, minimisation, anonymisation, pseudonymisation and tokenisation?

7. How will recommendations and actions be verified?

Can outputs be traced back to evidence? Can the organisation determine whether the result was correct, safe and valuable?

8. Who remains accountable when the system is wrong?

Can errors be detected, contained and reversed, and does responsibility remain clear even when an AI system performs part of the work?

These are not merely technical questions.

They are questions of governance, operational maturity and organisational design.

AI amplifies the organisation it enters

The most important question a company should ask is not “What can AI do for us?”

It is “Are we in a condition where AI can help us?”

Through consulting directly with businesses, as well as working across operations, documentation, monitoring, cybersecurity, automation and AI, I have repeatedly encountered the same principle.

What cannot be described cannot be transferred reliably.

What cannot be observed cannot be governed effectively.

What cannot be explained cannot be automated safely.

What cannot be verified should not be trusted simply because it was produced by an advanced AI system.

AI readiness begins before the provider, platform or model is selected.

It begins when an organisation develops enough self-awareness to describe what it does, enough operational discipline to observe what is actually happening, enough governance to define boundaries and enough feedback to determine whether its actions are creating value.

AI is not the foundation of that capability.

It is a multiplier of it.

The organisations that understand this will use AI to become faster, more adaptive and more capable.

Those that do not may discover that AI has simply made them more productive at producing the wrong things.