Assessment, feasibility against your real data, production build and an evaluation suite that proves it still works next quarter. For companies in the US, UK, Canada, Australia and the EU that have had enough of pilots which never shipped.
By 2026 almost every mid-sized company has run an AI pilot. A large share of them never reached production, and the reason is rarely that the model was not capable enough. It is that the pilot was demonstrated on tidy inputs, no one agreed in advance what accuracy would count as success, the system was never connected to the workflow it was supposed to improve, or the running cost only became visible at real volume.
Those are engineering and scoping failures, and they are all cheaper to catch early. That is what the first two stages below are for: by the end of week six you should know whether the idea works against your own data, what it will cost to run, and whether it is worth building — before anyone has committed to a build budget.
Where the answer is no, we would rather tell you at week six than bill you until month nine.
Every stage ends in a deliverable you own outright, so you can stop after any of them and still be ahead.
We work through your workflows looking for the places where volume, repetition and judgement meet. Most organisations have between two and five candidates worth testing, and considerably more that sound promising and are not.
You get: A ranked shortlist of use cases with an estimated value, an estimated build cost and a feasibility rating for each, plus the ones we recommend you do not do.
Almost every AI project that fails, fails here — and finds out six months late. We test against the messy data you actually have, not a cleaned sample, and we set the accuracy threshold with you before we start so the result is a decision rather than an argument.
You get: A working prototype against your real data, plus an honest read on whether the accuracy is good enough to be useful.
This is where the majority of the engineering sits: retrieval, integrations, permissions, latency, cost control, error handling and the interface people will actually use. The model is rarely the hard part.
You get: The system running inside your workflow, with monitoring, an evaluation suite and a documented fallback for when the model is wrong.
Models change underneath you, your data drifts and your users find inputs you did not imagine. A system without an evaluation harness is not in production, it is on probation.
You get: A regression suite that runs on every change, live quality metrics, and a monthly review of where the system is failing.
The second column is the more useful one. Knowing which projects to decline is most of what an assessment buys you.
Four routes to the same outcome, with very different cost and control profiles. Most teams reach for the last one first and need it least.
| Approach | Choose it when | What to watch |
|---|---|---|
| Buy an existing product | Your problem is common, a mature product exists, and your data is not a differentiator. | Per-seat pricing at scale, data leaving your control, and integration work that quietly costs more than the licence. |
| Build on a hosted model API | The problem is specific to you, the volume justifies the engineering, and you need it inside your own systems. | Inference cost at production volume, provider rate limits, and model versions changing behaviour under you. |
| Retrieval over your own content | The value is in your documents, tickets or records rather than in general reasoning. This covers most internal knowledge use cases. | Retrieval quality, not model choice, is what determines whether this works. Permissions must be enforced at retrieval time, not in the prompt. |
| Fine-tune or train a model | You need consistent structure or a narrow domain style, and you have thousands of good labelled examples. | It is the option most often reached for first and needed last. Prompting plus retrieval solves the majority of what fine-tuning is proposed for, at a fraction of the cost. |
Work through these before commissioning anything. If four or more have clear answers, a feasibility stage is worth running.
Not which system in principle — which table, bucket or folder, and who can grant access to it.
Historical decisions, resolved tickets, approved documents. Without these there is nothing to measure accuracy against.
Duplicates, scans without text layers, records that stopped being maintained in 2019. This is normally larger than expected and is normally survivable.
Personal data, health records, financial identifiers, client-confidential material. This determines the architecture, so it is a first-week question, not a pre-launch one.
Contractual restrictions on client data, and consent basis where personal data is involved.
A system built on a monthly export behaves differently from one built on a live feed. Drift is a design input, not an operational surprise.
AI running cost scales with usage rather than with users, which is the part traditional software budgeting does not prepare you for.
Charged per token or per request, and it scales with usage rather than with headcount. The difference between a naive implementation and a considered one is routinely 5-10x on the same workload.
Vector storage, embedding regeneration when documents change, and the pipeline that keeps the index current.
Building the test set is a real cost, and skipping it is the reason teams cannot tell whether last week's change helped.
Where output is reviewed, the reviewing time is part of the running cost and belongs in the business case from day one.
Providers deprecate models, change defaults and adjust pricing. Budget for a maintenance cadence rather than treating launch as the end.
If your system touches EU or UK users, two regimes matter and they are not the same thing. GDPR governs the personal data going into the system: lawful basis, minimisation, retention, and the fact that a model provider processing your data on your instructions is a processor who needs a data processing agreement. The EU AI Act governs the system itself, and its obligations depend on how the system is classified.
The AI Act timeline moved materially in 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred the high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027, with AI embedded in products under Annex I moving to 2 August 2028. Three things did not move: the prohibited practices in force since February 2025, the general-purpose AI provider obligations that have applied since August 2025, and the Article 50 transparency and AI-content-labelling duties that applied from 2 August 2026.
For most business automation the practical consequence is narrower than the headlines suggest — the majority of internal document and workflow systems are not high-risk. The transparency duties, however, frequently do apply, and they are already live. We build to the technical requirements a classification implies: audit trails of what the system saw and produced, disclosure where users interact with an AI system, human review where output carries weight, and documented data handling.
This is a summary of the regulatory position as it stood in August 2026, not legal advice. Classification of your specific system is a question for your counsel; we build to whatever classification they confirm.
The build side: assistants, document workflows, retrieval systems and ML-backed decision support.
Dedicated teams and embedded engineers when the work extends past the AI component.
The pipelines and reporting that usually have to exist before an AI system is worth building.
Fintech, healthcare operations, logistics, retail and legal operations.
Three things, in order. First, work out which parts of your operation are genuinely improved by AI and which are not — that shortlist is worth more than the build, because most of the cost of a failed AI project is spent on the wrong use case. Second, test feasibility against your real data before anyone commits to a budget. Third, build and integrate the system so it runs inside your workflow with monitoring and evaluation attached. A consultant whose engagement ends at a strategy document has handed you the easiest part.
An opportunity assessment takes one to two weeks. A feasibility prototype against your own data takes a further two to four. A production system typically takes six to sixteen weeks after that, depending on how many systems it has to integrate with and how strict the accuracy requirement is. You should not have to wait longer than about six weeks to know whether the idea is viable.
Running cost is driven by inference volume, retrieval infrastructure, evaluation and any human review in the loop. Unlike traditional software, it scales with usage rather than with users, which catches teams out. We model expected running cost during feasibility, before the build is approved, and design against it — caching, routing simpler requests to cheaper models, and limiting context are architectural decisions with a direct monthly cost attached.
With an evaluation suite built from your own examples, run automatically on every change, plus live quality metrics once it is in production. This is the single biggest difference between an AI pilot and an AI system. If a vendor cannot tell you how accuracy will be measured before the build starts, they are not planning to measure it.
It is designed for, not hoped against. That means a documented confidence threshold below which output goes to a human, a visible audit trail of what the system saw and decided, and a fallback path that keeps the workflow moving when the model or the provider is unavailable. Where the output is customer-facing or carries legal weight, we default to human review before it leaves the organisation.
It applies to providers and deployers whose AI systems are used in the EU, regardless of where the company is based. The timeline changed materially in 2026: the Digital Omnibus on AI (Regulation (EU) 2026/1744) entered into force on 27 July 2026 and deferred the high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in products under Annex I to 2 August 2028. What did not move: the prohibited-practices rules that have applied since February 2025, the general-purpose AI provider obligations in force since August 2025, and the Article 50 transparency and AI-content-labelling duties that applied from 2 August 2026. In practice most business automation is not high-risk, but the transparency duties frequently do apply. We are not a law firm — we build to the technical requirements the classification implies and expect you to confirm the classification with counsel.
Not if the architecture is set up correctly. Enterprise tiers of the major providers contractually exclude API inputs from training, and we configure and document that as part of the build. Where data cannot leave a jurisdiction or a network at all, the design changes accordingly — regional endpoints, or models running in your own infrastructure. This is a first-week architecture question because retrofitting it is expensive.
Usually one of four things. The pilot was demonstrated on curated inputs and collapsed on real ones. There was no agreed accuracy threshold, so nobody could say whether it had passed. It was never integrated into the workflow, so using it meant extra work for the people it was meant to help. Or the running cost was never modelled and became visible only at production volume. All four are avoidable, and all four are cheaper to catch in a two-week feasibility stage than in a six-month build.
Frequently, and it is usually the better arrangement — your team knows the domain and the systems. We take the parts that need specific experience (retrieval design, evaluation harnesses, cost and latency work) and hand them over with documentation. Where you have no engineering team, we can also build and run the whole thing.
We stay deliberately model-agnostic and design so the model is a replaceable component, because the frontier changes every few months and nothing on this page should depend on which provider is ahead this quarter. In practice that means working across the major hosted providers and open-weight models on your own infrastructure, chosen per use case on accuracy, latency, cost and data-residency requirements.
One to two weeks, a ranked shortlist of what is worth doing, and a clear recommendation on what is not. You keep the document either way.
Book an AI assessment