↓ Skip to main content
  1. Blog/

The AI Adoption Chasm

Phillip Büchler
Author
Phillip Büchler

Upload your CV. Now type your name, address, employment history, education and qualifications into the text boxes below.

The company already has that information, but its recruitment system can’t reliably map your document onto the structure its process requires. So the applicant becomes the integration layer. You read your own CV, reconcile terminology, reformat dates and fit your experience into categories the vendor chose. The form was digitised, not removed.

Most enterprise AI adoption stalls at the same point.

Individual use is the easy part
#

Someone I know starts his day with an AI that collects his open tasks, summarises overnight conversations and drafts his daily update. Three floors up, his company is six months into selecting an AI platform.

The individual gains are real: no blank page, faster triage of long threads, easier questioning of unfamiliar documents. They don’t add up to a more efficient organisation, though. Thousands of people writing emails faster removes no process step. The return shows up when work disappears, a hand-off is dropped or a service is delivered differently.

The employee as translation layer
#

An email becomes a ticket. A document’s contents get keyed into a business system. Decisions from meeting notes get copied to a task board. A service agent maps a customer’s description to a category, subcategory and resolution code.

Take this ticket: “My laptop has become very slow since yesterday afternoon and now Teams keeps freezing during calls.” The ITSM tool wants affected service, device identifier, impact, urgency and category. The person triaging knows the laptop is the affected device, that Teams is a symptom rather than necessarily the root cause, and that interrupted calls may justify a higher priority. That is integration work performed in someone’s head, which is why it never appears in an integration backlog.

Most current deployments improve the work before the text box. AI drafts the email, summarises the meeting, analyses the incident, extracts the CV data. The employee still moves the result into the next system. The adoption dashboard (licences assigned, usage rising, self-reported time saved) looks healthy while the workflow is unchanged.

What the models change
#

Classic automation needs structured input. A field maps to a field, and anything phrased differently needs a person to interpret it first. Language models can take over that interpretation step: extract employment periods from a CV, recognise a malfunctioning laptop in free text and pre-fill the ticket, pull decisions out of meeting notes.

The interpretation is probabilistic, and the failure modes matter more than the capability.

Extraction errors are plausible-looking. Overlapping employment, gaps, ambiguous date formats and translated job titles produce a well-formed field with a wrong value, which passes schema validation without complaint. Priority inferred from the wording of an email is a guess, and a confident one. A decision recognised in meeting notes isn’t necessarily an authorised decision; the person who said it may not have owned it.

Reading is also the cheap part. Creating or modifying a record needs a write path with a service identity behind it. In practice this is where projects stall: incomplete APIs, no interface at all, or a service account with broader rights than anyone is willing to sign off.

Human review is the usual mitigation, and it degrades. If nearly every proposal is correct, reviewers stop reading them. The review step needs to show what changed or what the model was unsure about, not just present a filled-in form.

The platform meeting
#

Meanwhile the workplace team has a productivity assistant, the central AI team has a governed platform, engineering has already built something against a model API, and a business unit has bought a specialist product it wants approved. Each position is defensible: proximity to the employee, reuse and cost control, fast test environments, a problem solved before year-end.

The debate is framed as platforms, models and governance. The decision underneath is who owns the integration path, who funds it and who is accountable when it writes a wrong value into a system of record.

Two separate tracks
#

The individual track is already running. People learn where AI helps, where it speeds up routine work and where its output can’t be trusted, and none of that depends on the enterprise platform decision. If you use it for real work, you are not behind.

The enterprise track is slower. It needs a specific process, a named owner, connected systems, a decision on which errors are tolerable, and acceptance of responsibility for automated actions. It is less visible than launching a chatbot, and it is where the business case value sits. Twenty minutes saved summarising a meeting only becomes a permanent saving if the decisions, actions and records land in the right systems without someone reconstructing them.

Where to start
#

Look for people acting as translation layers. Where is information copied between systems? Where does someone read a document and classify it? Where do meeting notes turn into tasks? Where is one workflow’s output reformatted for the next?

These use cases demo poorly and come with awkward permissions, incomplete interfaces and disputes over process ownership. They are also where individual assistance meets organisational change.

For recruitment, the first step is not an autonomous hiring agent. It is this:

  1. The applicant uploads a CV.
  2. AI extracts the relevant information.
  3. The recruitment system proposes completed fields.
  4. The applicant reviews and corrects them.
  5. The system records what was accepted and what was changed.

The applicant is the reviewer, and they are the one person who knows whether the data is right. The accept/change log doubles as evaluation data: a per-field correction rate tells you whether extraction is good enough to reduce review, and where it isn’t.

Licence activation, prompt counts and meeting-summary demos measure near-side adoption. Process-level measures are cycle time, handling effort per case and correction rate. These are blocked less by model quality than by system access and unclear ownership. The team that gets there will be the one that owns a single process end to end, not the one with the broadest platform mandate.

Related

Microsoft Endpoint Privilege Management: free in E5, but not free to run

I get this question in almost every Modern Workplace engagement, usually about twenty minutes after we agree that standing local admin rights have to go: “Don’t we already have something for that in our Microsoft licence?” For years the honest answer was “almost — it’s an add-on.” From July 2026, the answer changes, and it’s worth a blog post, because the gap between Microsoft’s Endpoint Privilege Management (EPM) and the established specialist tools is smaller than those vendors will tell you — and larger than Microsoft’s pre-sales decks suggest.