On this page
- Key takeaways
- 1. No number leadership would accept as proof
- 2. The data that matters lives in spreadsheets
- 3. A core system with no integration path
- 4. Nobody owns the workflow
- 5. Governance decided after the build
- 6. A pilot built on a demo rather than the operation
- The six blockers at a glance
- Frequently asked questions
- Related
Key takeaways
- The six blockers are: no agreed number, data that lives in people's spreadsheets, core systems without an integration path, no owner for the workflow, governance decided after the fact, and a pilot built on a demo rather than the operation.
- Four of the six are organisational. Two are technical. The organisational ones are found in interviews, which is why questionnaires miss them.
- Each blocker has a first fix measured in weeks, and a sprint's job is to name the owner for each.
- A company with all six open should not start a build. A company with two open can start, with the fixes in the plan.
Last updated: October 2026
AI readiness in a mid-market company is the state in which a chosen workflow can be rebuilt around AI on real data, reviewed by the people who own it, and measured against a number leadership accepts. Six things block it more often than any model or vendor choice, and they recur across sectors in the readiness sprints Twistag runs with €20M–€500M companies. None of them is exotic. Each has a first fix that takes weeks rather than quarters. The scale of the problem is well documented: Gartner's survey of 1,203 data leaders found that 63% of organisations lack suitable data management practices for AI or are unsure whether they have them.
1. No number leadership would accept as proof
What it looks like. The use case is described as "automate invoice processing" or "AI for customer service". Asked which number would show it worked, the room offers three different answers or none.
Why it stalls AI. Without a number, the pilot cannot fail, so it cannot succeed either. It runs until the budget ends and is judged on impressions. ISG's 2025 survey found only one in four AI initiatives meeting revenue expectations, and most of the rest never had a target to meet.
The first fix. One number per workflow, agreed with the sponsor before any build: exceptions per thousand invoices, hours of agency staffing per week, time to first reply. Baselined in the first two weeks. One to two weeks.
2. The data that matters lives in spreadsheets
What it looks like. The ERP holds the official record. The pricing rules, the supplier exceptions, the real shift plan and the customer notes live in files that three people maintain and nobody else trusts.
Why it stalls AI. An agent reading the system of record gets a version of the business that the people running it stopped believing years ago. Gartner predicts that organisations will abandon 60% of AI projects that lack AI-ready data through 2026, and in mid-market companies the missing data is usually sitting on someone's desktop.
The first fix. For the one workflow in scope, find every file it depends on, move the rules into a table the agent can read, and give the three maintainers a way to keep it current. Two to four weeks for one workflow; a data platform comes later, once two or three workflows have shown what it needs to hold.
3. A core system with no integration path
What it looks like. The ERP is a decade old, customised, and reachable through screens and nightly exports. The vendor's API is an upgrade away, and the upgrade is a two-year project.
Why it stalls AI. The agent can read but cannot write, so every action ends in a person retyping the result, and the time saved disappears in the handover.
The first fix. An integration layer for the one workflow: a database view, a file drop, a vendor connector, or a small service that posts into the system through whatever interface exists. Scoped to the fields the workflow needs, tested against the real system in a sandbox. Three to six weeks. Twistag's note on modernising legacy systems for agent access covers the options.
4. Nobody owns the workflow
What it looks like. Finance owns the invoices, procurement owns the orders, IT owns the ERP, and the matching between them is done by two people whose job title is something else.
Why it stalls AI. An agent needs a person who approves its exceptions and decides when it is wrong. If nobody owns the workflow, nobody owns the agent, and it is switched off the first week a mistake reaches a customer.
The first fix. Name one owner for the workflow, with the authority to change the procedure and the time to review the agent's work for the first eight weeks. One conversation, usually with the COO, and one week.
5. Governance decided after the build
What it looks like. The pilot is in week six. Legal asks which data went to which provider. Security asks who approved it. The answer is that nobody asked, because the pilot was small.
Why it stalls AI. The pilot stops while a policy is written, and the policy is written for the worst case because it is written under pressure. Companies operating in Europe also need the EU AI Act risk tier for each use case before anything reaches customers.
The first fix. A one-page rule set agreed in the first two weeks: which data may go where, who approves a new use, how decisions are logged, which regulations apply. Short enough to follow, revised when the first workflow ships. One to two weeks with legal and security in the room.
6. A pilot built on a demo rather than the operation
What it looks like. The vendor demo was impressive. The pilot reproduced it on a sample of clean documents. Daily use means every format, every supplier and every exception, and the pilot was never tested on those.
Why it stalls AI. MIT's 2025 report found 95% of corporate generative AI pilots stalling before scaled adoption. A pilot that passes on the demo set and fails on the real one is the usual shape.
The first fix. An evaluation set from real data before the build: at least ten cases per behaviour, including the ugly ones, with a threshold the owner accepts. Tested weekly. One to two weeks to assemble, then continuous.
The six blockers at a glance
| Blocker | Type | First fix | Typical time |
|---|---|---|---|
| No agreed number | Organisational | One number per workflow, baselined | 1–2 weeks |
| Data in spreadsheets | Technical | Rules into a readable table, maintainers kept | 2–4 weeks |
| No integration path | Technical | Integration layer scoped to one workflow | 3–6 weeks |
| No workflow owner | Organisational | One owner with authority and time | 1 week |
| Governance after the fact | Organisational | One-page rule set agreed up front | 1–2 weeks |
| Pilot built on a demo | Organisational | Evaluation set from real data | 1–2 weeks, then continuous |
Frequently asked questions
Should a company fix all six before starting an AI project?
No. The fixes are scoped to one workflow, so they are part of the first proof rather than a precondition for it. A company with two open blockers can start with the fixes in the 90-day plan. A company with all six open should run an assessment first, because the first workflow has not been chosen well.
Are these blockers different in large enterprises?
The technical ones are similar and the organisational ones are worse, because ownership and governance span more units. Enterprises also have transformation offices to work through them. Mid-market companies have the advantage of a short path to the COO, which is why four of the six can be fixed in a week or two.
How does an AI readiness sprint find these?
By talking to the people who run the workflow and by checking the data and systems directly, rather than by questionnaire. Twistag's AI Readiness Sprint returns each blocker with an owner and a fix in the 90-day plan.
