When an AI project fails at a mid-sized firm, the post-mortem almost never blames the AI. It blames the inputs. The customer list lived in three places with three spellings of the same client. The product data had free-text fields where structured ones were needed. The historical documents that were supposed to ground the assistant were scattered across personal drives, email attachments and a shared folder nobody had permission to read.
AI systems are amplifiers of data quality in both directions. Feed a document-extraction workflow clean, consistent invoices and it performs impressively. Feed it a decade of inconsistently scanned PDFs and it produces confident nonsense — which is worse than no output at all, because someone has to find the errors.
The practical test is simple, and you can run it without a consultant. Pick the process you want to improve. Ask: could a competent temp, given only the systems and documents — no tribal knowledge, no asking Sandra — do this job correctly? If not, an AI cannot either, and the gap between what is written down and what Sandra knows is your real project.
Data readiness is unglamorous: agreeing a single source of truth for each core entity, fixing the fields automation will depend on, consolidating documents into governed storage with sensible permissions. It typically costs a fraction of an AI programme and, notably, delivers value even if you never buy the AI. That makes it the rare technology investment with no losing scenario — which is exactly why it should come first.
There is a hierarchy of tools for removing manual work, and cost rises as you climb it. At the bottom: deterministic automation — if an order arrives, create the invoice; if a form is submitted, update the record. Predictable, testable, inexpensive to run. In the middle: extraction and classification, where AI reads unstructured input and turns it into structured data. At the top: generation and judgement, where a model drafts or decides — the most expensive tier to run and, crucially, to supervise.
Most mid-sized firms have years of unclaimed value sitting in the bottom tier. Rekeying between the CRM and the accounts package. Weekly reports assembled by copy-paste. Onboarding checklists executed from memory. None of this needs AI. It needs APIs, an orchestration layer, and someone to map the process honestly.
Starting at the bottom has a compounding benefit that is easy to miss: plumbing. Once your systems are connected and your workflows are explicit, adding an AI step later is an increment, not a programme. The firm that automated its invoice routing last year can add AI extraction for the awkward suppliers this year in weeks. The firm that starts with a grand AI vision must build all the plumbing anyway, under pressure, at AI-project prices.
A useful discipline for any proposal: for each step, ask whether a rule could do it. Where the answer is yes, a model is the wrong tool — slower, dearer, and probabilistic where you wanted certainty. Reserve AI for the steps that genuinely need judgement. There are fewer of those than the vendors suggest, and they are more valuable when properly isolated.
UK GDPR does not prohibit using AI on personal data. It requires you to know what you are doing with it and to be able to show your working. For a mid-sized firm evaluating an AI tool, the questions that matter fit on a page.
First, establish what personal data will actually reach the tool. Not what the use case is meant to involve — what will, in practice, be pasted, uploaded or synced. Staff copying customer emails into a free chatbot is a data transfer to a processor you have no agreement with. If a tool is useful, procure it properly on business terms; if it is not worth procuring, it is not worth feeding your data.
Second, settle the training question in writing. Does the provider use your inputs to train its models? Enterprise tiers of the major providers generally exclude this contractually; free and consumer tiers often do not. This single distinction disqualifies more tools than any other check, and it takes ten minutes to verify.
Third, do the boring documents, briefly. A Data Protection Impact Assessment where processing is likely high-risk — and screening for whether one is needed is itself quick. A data processing agreement with the provider. An entry in your record of processing. Where data leaves the UK, identify the transfer mechanism. None of this requires outside counsel for a typical automation use case; it requires an afternoon and honesty.
Fourth, keep a human in the loop where decisions have legal or similarly significant effects on people — recruitment sifting, credit terms, anything touching employment. Article 22 constrains solely automated decisions of that kind, and quite apart from the law, these are the decisions where a named accountable human is simply good management. Log what automated systems did and why, so that when someone asks — a customer, the ICO, your own board — the answer is retrieval, not reconstruction.
Firms approaching automation are usually offered two options. Buy: adopt a suite that promises to do everything, and accept its assumptions about how you work. Build: commission bespoke software that fits exactly, and accept the cost of creating and maintaining it. Both have their place. Neither is where most mid-sized firms should start.
The third option is orchestration: keep your existing systems — CRM, accounts, email, the line-of-business tools your industry runs on — and connect them through a workflow layer such as n8n or its commercial equivalents. The orchestration layer watches for events, moves data, applies rules, and calls an AI model for the steps that need one. Your systems of record stay where they are.
The economics favour this approach for a specific reason: reversibility. A workflow that took two weeks to build can be changed in an afternoon and deleted without ceremony. Compare the exit cost of a suite migration or a bespoke rebuild. When your processes are still evolving — and in a growing firm they always are — the cheap-to-change option carries an option value the alternatives cannot match.
The honest caveats: orchestration adds a component that must itself be hosted, secured and monitored, and it is bounded by your systems' APIs — a core system with no interfaces caps what any workflow can do, which argues for making API quality a hard criterion in your next procurement. Buy still wins for genuinely commodity problems where a mature product exists. Build still wins when a process is your competitive edge and worth owning outright. But as a default posture — orchestrate first, buy the commodities, build only the crown jewels — it is the strategy we would want if we were in your chair.