The Enterprise AI Adoption Model: How Culture, Leadership and Departmental Context Determine Whether AI Sticks

A chief executive announces that artificial intelligence will become part of how the organisation works. Enterprise licences are purchased. An AI policy is issued. Training reaches most office-based employees. Usage dashboards begin to rise.

Six months later, the organisation appears to have adopted AI.

The reality is less coherent.

Marketing teams use generative tools daily for drafts, research and campaign variation. IT teams are building internal assistants and experimenting with agents. Finance has approved a small number of controlled use cases but still relies on manual reconciliation and established review procedures. HR uses AI in service delivery and learning content while legal teams remain cautious about recruitment and performance decisions. Procurement users conduct supplier research through a mixture of approved and personal tools. Operations teams have limited access because the available systems do not fit frontline work.

One organisation now contains several different AI cultures.

An enterprise adoption percentage conceals that difference. So does a programme built around licences, training attendance or executive enthusiasm.

KOR’s central argument is:

Enterprise AI adoption occurs when useful, approved and appropriately challenged AI becomes part of sustained work across materially different functions. It cannot be inferred from access, usage or leadership intent alone.

The Enterprise AI Adoption Model assesses nine common organisational capabilities and then applies nine context lenses that explain why adoption appears differently across departments, roles, regions and operating conditions.

It is designed to answer a practical leadership question:

Has AI become part of controlled organisational behaviour—or has the enterprise merely accumulated tools, training and isolated pockets of use?

Framework boundary: This is a KOR proposed synthesis. It is not a universal industry standard, employee personality assessment or claim that every department should adopt AI at the same speed.

Enterprise AI adoption is the sustained use of approved AI within organisational workflows, supported by role clarity, practical capability, calibrated trust, managerial reinforcement, appropriate controls and measurable outcomes. It is broader than access or usage because it asks whether behaviour, process and decision quality have changed under normal operating conditions.

KOR developed this model as a synthesis of current UK business-adoption research, workforce studies, responsible AI frameworks and operating-model evidence. It deliberately separates access, activity, readiness, adoption and realised value, and treats observed workflow change and verified outcomes as stronger evidence than self-report alone.

AI adoption is often reported through one of four measures:

• the percentage of employees with access;
• training completion;
• active users or prompts;
• positive employee sentiment.

Each measure can be useful. None establishes that AI has changed how the organisation operates.

The UK Government’s 2026 AI Adoption Research illustrates the gap. Sixteen per cent of surveyed UK businesses used at least one AI technology. Among adopters, an average of 30% of staff used AI. Marketing and administration were the most commonly identified business areas using or planning to use AI, followed by IT. Three quarters of adopters reported productivity improvement, yet 77% reported no revenue change, and the impact measures were self-reported.

The evidence does not suggest that adoption is unimportant. It shows that access, use, readiness and realised value are different findings.

An organisation can have:

• widespread informal use but weak governance;
• high activity in one department and almost none in another;
• strong executive support but inconsistent line-management behaviour;
• high trust without sufficient checking;
• strong technical controls around a workflow users avoid;
• task-level time savings without end-to-end process change;
• employee anxiety that is rational given unclear job and accountability implications;
• mandatory usage that produces hidden workarounds rather than genuine adoption.

The objective is not maximum use. It is appropriate and sustained use in the right work, under the right conditions.

The model has two layers.

Layer one: nine adoption capabilities

1. Role clarity — people understand what AI may do, what remains human and who is accountable.
2. Practical capability — users can operate, evaluate and challenge AI in their actual role.
3. Approved use — the accessible and useful route is also the governed route.
4. Calibrated trust — users neither accept outputs automatically nor reject the technology reflexively.
5. Managerial reinforcement — line managers allocate time, model behaviour and resolve barriers.
6. Psychological safety and challenge — employees can disclose use, mistakes, concerns and disagreement.
7. Incentives and performance measures — the organisation rewards the new workflow rather than preserving the old one.
8. Workflow and role redesign — AI changes the process, not merely the speed of one task.
9. Sustained behaviour — the practice survives beyond launch communications, champions and implementation support.

Layer two: nine context lenses

1. Department and professional subculture
2. Executive and local leadership
3. Industry and regulatory exposure
4. Organisation size and structural complexity
5. Workforce and role mix
6. Geography and regional operating conditions
7. Business model and stakeholder exposure
8. Rollout design
9. Time and durability

The first layer asks whether the organisational capability exists. The second asks what is shaping it.

Employees cannot adopt AI responsibly when the organisation has not defined what adoption means in their role.

A policy may permit generative AI but leave unanswered questions:

• May a salesperson use it to draft client proposals?
• May HR use it to rank applicants?
• May finance use it to explain a variance?
• May procurement use it to recommend a supplier?
• May legal rely on it for a contractual position?
• Who checks the output?
• What evidence must be retained?
• Who owns the decision?

Role clarity should distinguish:

• expected uses;
• permitted but optional uses;
• controlled experimental uses;
• restricted or prohibited uses;
• mandatory human review;
• escalation and stop conditions.

The organisation should not communicate that people remain accountable while leaving them unable to understand, inspect or override the system contributing to the outcome.

Generic AI awareness creates vocabulary. It does not create role capability.

Practical capability includes:

• framing and decomposing the task;
• selecting the approved tool;
• protecting confidential and personal information;
• recognising uncertainty and fabricated content;
• checking sources and calculations;
• documenting significant use;
• knowing when not to use AI;
• escalating material errors;
• understanding the relevant professional standard.

The same employee may be advanced in one use case and unprepared in another. A marketer skilled in creative iteration is not automatically prepared to use AI for employee profiling. A finance professional who can automate spreadsheet logic may still need support interpreting probabilistic forecasts.

Assessment should therefore be based on role-specific demonstrations and observed work, not training completion alone.

Shadow AI is often treated as a discipline problem. It can also be evidence that the authorised proposition is defective.

Employees will route around a system that is slower, harder to access, poorly integrated or less useful than the consumer tool they already know. A policy cannot make an inferior workflow attractive.

The organisation should examine:

• whether approved tools are available to the relevant roles;
• whether access and authentication are proportionate;
• whether the tool sits inside the workflow;
• whether data and knowledge sources are usable;
• whether approved functionality solves a problem employees recognise;
• whether the review burden is proportionate to the risk;
• whether rejected requests receive a credible alternative.

Low approved usage may indicate poor communication. It may also indicate poor product, process or control design.

Trust should match evidence and consequence.

Under-trust produces duplication. Employees recreate the task manually, keep parallel spreadsheets or ignore useful recommendations. Over-trust produces uncritical acceptance, weak verification and misplaced confidence in polished outputs.

Calibrated trust requires people to know:

• what the system performs well;
• where it is unreliable;
• how current and complete its data is;
• what evidence supports the output;
• which decisions require independent review;
• how performance is monitored;
• how corrections improve the process.

The 2025 University of Melbourne and KPMG global study of trust and AI found widespread use alongside concerns about inappropriate or complacent behaviour and inconsistent evaluation of outputs. That is an adoption issue, not merely a technical one.

Executive sponsorship creates permission and priority. Line management determines whether the permission becomes work.

The adoption cascade is:

Executive intent → functional translation → managerial reinforcement → workflow expectation → observed behaviour → sustained norm

A break at any point weakens the change.

Managers influence adoption when they:

• use the approved capability themselves where relevant;
• allocate time for learning and redesign;
• make expectations specific;
• remove obstacles;
• respond constructively to reported errors;
• recognise good judgement rather than prompt volume;
• challenge unsafe or low-value use;
• update performance measures and workload assumptions.

A chief executive can endorse AI while a local manager preserves the old process, refuses learning time and penalises disclosed mistakes. Employees will follow the operating consequence, not the corporate message.

Responsible adoption requires more than confidence to experiment. It requires confidence to stop, question and disclose.

Employees should be able to say:

• the output appears wrong;
• the tool is unsuitable for this case;
• the mandated process is creating duplicate work;
• they used an unapproved tool and need help containing the issue;
• the system may affect a group unfairly;
• a manager is pressuring them to bypass review;
• the promised benefit is not appearing.

A culture that celebrates success but punishes honest disclosure will produce cleaner dashboards and weaker control.

AI adoption stalls when the organisation introduces a new tool but continues to reward the old operating model.

Examples include:

• asking employees to verify AI outputs without changing workload targets;
• expecting collaboration while measuring individual throughput only;
• encouraging experimentation but treating every failed test as poor performance;
• automating administration without redesigning roles or development paths;
• measuring log-ins rather than outcomes and judgement quality.

Incentives should support:

• appropriate use;
• evidence and verification;
• knowledge sharing;
• escalation of uncertainty;
• process improvement;
• measurable outcomes;
• stopping low-value uses.

The largest gap in many adoption programmes is the absence of process change.

An employee receives an AI-generated output but must copy it between systems, repeat the work manually, obtain the same approvals and remain accountable for checking everything without additional time. The task may be faster in isolation while the workflow becomes more complex.

Workflow redesign asks:

• Which step disappears?
• Which step changes?
• What new review is required?
• Where is evidence retained?
• Who handles exceptions?
• How does work move between teams?
• What capability becomes more important?
• What should stop being measured?
• How is released capacity used?

AI adoption should produce a better operating design, not an additional layer around the old one.

There is no defensible universal rule that organisational culture takes a fixed number of years to change.

Visible behaviour may shift quickly. Durable culture requires the behaviour to persist when:

• launch communications stop;
• implementation support is withdrawn;
• workloads rise;
• managers and champions change;
• new employees join;
• systems, suppliers or models change;
• difficult cases occur;
• the novelty disappears.

The 2026 ILO review of emerging evidence on GenAI, productivity and work organisation finds that productivity effects are real but uneven, while worker-reported time savings have not consistently translated into measured organisational outcomes. Sustained adoption must therefore be tested through behaviour and outcomes over time.

An enterprise does not contain one professional culture.

Functions differ in their accountability, customer exposure, data, professional standards, process structure and tolerance for uncertainty.

IT and technology

IT often has earlier exposure, stronger technical confidence and greater influence over approved tooling. Its adoption risks include tool proliferation, technical overconfidence, weak translation into business workflows and becoming the default owner of problems that belong to the function.

Marketing and sales

These teams often see rapid task-level gains in drafting, research, personalisation and content variation. Cultural risks include uncontrolled tool use, brand inconsistency, intellectual-property exposure and pressure to prioritise speed over verification.

Human resources

HR combines internal adoption with stewardship of the workforce transition. It may use AI in recruitment, learning, service delivery, workforce planning, scheduling and performance processes. Trust depends heavily on fairness, transparency, employee voice, privacy and meaningful human oversight.

Finance

Finance adoption is shaped by auditability, data quality, reconciliation, control ownership and a low tolerance for unexplained error. Use may grow quickly while production deployment remains controlled. The function needs to distinguish exploratory assistance from evidence used in reporting, forecasting and decisions.

Procurement

Procurement combines sourcing, supplier research, contract analysis and stakeholder work with responsibility for acquiring third-party AI. Adoption depends on source verification, confidentiality, category variation, supplier transparency and whether AI is integrated into sourcing and contract workflows.

Legal, risk and compliance

These functions may appear cautious because the consequences of unsupported output are high. Adoption is more likely where use cases preserve professional judgement, evidence, privilege, explainability and review.

Operations and customer service

Frontline adoption depends heavily on usability, access, integration and escalation rights. A model that works in a demonstration may fail when it increases handling time, produces unreliable advice or does not reflect local conditions.

The correct leadership question is not: Which department is resistant?

It is: What does appropriate adoption require in this department, and what evidence shows that it is occurring?

Industry influences adoption through digital intensity, data availability, skills, regulation, consequence of error, competitive pressure and credible use cases.

DSIT found higher adoption in information and communication, finance and real estate, and business services and administration than across UK businesses overall. That does not mean every technology company is culturally ready or every regulated organisation is slow. Regulation can increase caution in some decisions while accelerating investment in governance and controlled use.

The UK Business Data Survey 2026 found that reported AI use and formal written AI policies were substantially more common in large businesses. Large organisations also tend to have more legacy systems, approval layers, regional variation and distance between executive policy and local behaviour.

Smaller organisations may diffuse new behaviour quickly but rely more heavily on informal practice and individual judgement. Scale changes the rollout architecture; it does not determine readiness by itself.

Age can affect exposure, but generational labels are weak substitutes for diagnosis.

Assess:

• role and task;
• career stage;
• professional experience;
• digital and data literacy;
• confidence;
• perceived threat and opportunity;
• accessibility;
• access to approved tools;
• management support;
• source-verification behaviour.

A younger employee may know consumer AI but not the organisation’s evidence and confidentiality requirements. A highly experienced employee may combine deep domain judgement with sophisticated AI use.

Country and regional differences should be examined through local conditions rather than stereotypes.

A multinational rollout should consider:

• decision centralisation and regional autonomy;
• language and knowledge support;
• labour relations and consultation;
• regulation;
• process standardisation;
• management style;
• data residency and access;
• local system maturity;
• whether the global tool is better than the local workaround.

A global policy may be necessary. A global assumption about behaviour is not.

Voluntary discovery

Useful for low-risk exploration and identifying credible use cases. It may produce a self-selecting evidence base and fragmented practice.

Bounded pilots

Useful where the organisation needs evidence on performance, risk, behaviour and workflow. Pilots should define users, data, review, baseline, success criteria and stop conditions.

Phased rollout

Appropriate where departments, roles, regions or data conditions differ materially. It allows learning across different operating environments.

Mandatory use

Appropriate only when the process, support, controls and value are sufficiently established. Mandating an inferior workflow creates visible compliance and invisible workarounds.

KOR’s recommended sequence is:

1. voluntary discovery for low-risk exploration;
2. bounded role-based pilots;
3. phased deployment across materially different conditions;
4. mandatory workflow use where the proposition is proven;
5. continuing authority to stop or redesign when evidence deteriorates.

Step 1: map actual use

Create an inventory of approved tools, embedded AI, local experiments and known shadow use. Map use by function, role, location and workflow.

Step 2: identify materially different adoption populations

Do not average together employees whose tasks, risk and access differ. Separate functions, managers, regions and roles where the adoption conditions are meaningfully different.

Step 3: assess the nine capabilities

Use interviews and surveys for orientation, then examine policies, role guidance, workflow design, tool access, training, usage, exceptions, corrections, manager behaviour and outcomes.

Step 4: apply the context lenses

Determine whether weak adoption is driven by capability, proposition, management, regulation, infrastructure or local operating conditions.

Step 5: distinguish activity from adoption

Report separately:

• enablement;
• approved use;
• sustained behaviour;
• process change;
• control performance;
• realised outcomes.

Step 6: create function-specific interventions

The enterprise may need common policy and technology standards, but departments require different examples, review rules, training, incentives and evidence.

Step 7: measure durability

Reassess after launch support reduces and after materially difficult cases. Adoption that depends on one champion is not yet cultural capability.

Provisional

• employee sentiment;
• leadership statements;
• training attendance;
• reported use;
• pilot anecdotes.

Substantiated

• role guidance;
• approved workflows;
• manager expectations;
• tool access and configuration;
• use-case approvals;
• training aligned to tasks;
• issue and escalation records.

Verified

• sustained approved usage;
• observed workflow change;
• appropriate checking and escalation;
• reduced shadow use;
• operational outcomes against baseline;
• behaviour persisting after implementation support;
• finance-validated value where relevant.

A high adoption score supported only by self-report should not justify enterprise-scale decisions.

Treating culture as communication

Communication creates awareness. Culture changes when expectations, tools, workflows, management and consequences change together.

Treating resistance as irrational

Avoidance may reflect poor usability, unclear accountability, weak evidence or a credible concern about harm.

Using one rollout for every department

Common controls do not require identical implementation.

Measuring prompts instead of work

Prompt volume can rise while process quality and value remain unchanged.

Mandating use before proving the proposition

This encourages compliance theatre and shadow work.

Treating early adopters as representative

Enthusiasts can establish possibility. They do not establish enterprise usability.

Ignoring role redesign

If AI removes tasks but the organisation does not redesign work, incentives or development paths, anxiety and duplicate effort will persist.

The purpose of an adoption assessment is not to classify employees as enthusiastic or resistant.

It is to determine:

• where useful and controlled behaviour exists;
• where adoption is only apparent;
• which departments require different interventions;
• whether leadership reinforcement is reaching daily work;
• whether the workflow is better than the workaround;
• whether trust is calibrated;
• whether the behaviour is durable;
• whether outcomes justify further scale.

The most important question is not:

How many people are using AI?

It is:

Where has AI become useful, controlled and sustained organisational work—and what must change before that can happen elsewhere?

What is enterprise AI adoption?

Enterprise AI adoption is the sustained use of approved AI within organisational workflows, supported by role clarity, capability, calibrated trust, management, controls and measurable outcomes.

Why does AI adoption differ by department?

Departments have different tasks, professional standards, data, accountability, risk, workflows and management practices. The same tool and rollout can therefore produce very different behaviour.

Is training enough to drive AI adoption?

No. Training can build awareness and skill, but adoption also requires useful tools, workflow integration, management reinforcement, appropriate incentives and continuing evidence.

Should AI use be mandatory?

Only where the use case, workflow, support, controls and benefit are sufficiently established. Premature mandates often create duplicate work and hidden avoidance.

How should leaders measure AI culture?

Measure observable behaviour: approved use, review quality, issue reporting, workflow change, management reinforcement, sustained use and outcomes—not sentiment or log-ins alone.

How long does AI culture change take?

There is no universal duration. Early behaviour can change quickly, while durable culture requires repeated reinforcement and evidence that the behaviour survives normal operating pressure.