Approach
Boundary first, evidence throughout, handover meant
Five steps, in this order, on every engagement. The order is the method: most of the expensive failures in this field come from doing step one fourth.
- 01 Week one, always
Draw the boundary
Before any architecture discussion, we establish the highest data classification that will touch the system in production, not in the pilot. This single table decides most of what follows, and skipping it is the most expensive mistake available in this field.
Deliverable: a classification table mapping each use case to a permissible deployment tier, with the reasoning written down so it survives a change of personnel.
- 02 Before anything is built
Define what correct means
We build an evaluation set from your real material (100 to 200 questions or cases with reviewed correct answers) including the ones the system should refuse. Without this nobody can honestly answer "how accurate is it?", which is the question that decides whether it goes live.
Deliverable: an evaluation harness in your repository, runnable by your team, with a measured baseline.
- 03 Weeks two onward
Build the smallest useful thing
One system, in production, doing real work. Not a platform, not a centre of excellence, not a strategy for enterprise-wide adoption. Working software from the first fortnight, reviewed with you every two weeks against the evaluation set.
Deliverable: software in your repository, with tests, CI and infrastructure as code from the start rather than added at the end.
- 04 Continuously
Produce the evidence as you go
The DPIA, the risk entries, the data flow documentation, the NCSC CAF contributing-outcome commentary, the Secure by Design artefacts and the ATRS record where they apply, written while the decisions are being made and the people who made them are still available to explain why.
Deliverable: an evidence pack your assurance function, accreditor, auditor or procurement panel can rely on, rather than one reconstructed under deadline. Hosts and orchestration arrive with DISA STIG and CIS Level 2 scan output and a justified deviation list.
- 05 The final fortnight, and meant
Hand it over properly
Runbook, architecture decision records, handover sessions with your engineers, and named internal owners for the corpus, the infrastructure and the evaluation. We are trying to make ourselves unnecessary.
Deliverable: your team can run, change and re-evaluate the system without us. If they cannot, we have not finished.
What we avoid
Six ways AI projects waste money
Every one of these is common, and every one of them is avoidable at no extra cost. We would rather tell you about them before you commission the work than afterwards.
The pilot on synthetic data
It proves a demo can be built. It tells you almost nothing about production, because real corpora are messier, more inconsistent and more sensitive than any sample prepared for a demonstration. We insist on a slice of real material under a proper agreement, even when arranging it takes three weeks.
The strategy phase you did not need
If you can already name the three processes that hurt most, you do not need £25,000 of strategy to be told AI is transformative. You need someone to assess whether AI can address them, which costs a fraction of that.
The human-in-the-loop that is not
A person approving two hundred outputs an hour is not a control; they are a rubber stamp with a job title. If you are relying on human review it has to be resourced, time-boxed realistically and evidenced, or you should stop claiming it.
The architecture you cannot leave
Anything where a supplier’s licensed middleware sits permanently between you and your own systems. The build price looks competitive and the five-year cost is not. We keep model access behind an interface you own, so you can change your mind.
Compliance discovered at the end
A system architected around a hosted API and then blocked at information governance is usually not fixable by adjustment: the data flows are wrong at the foundation. This is why step one is step one.
The agent that should have been a script
When the task is the same every time, an agent is an expensive and less predictable way to run a workflow a deterministic pipeline would handle better. We build agents where the task genuinely varies, and say so when it does not.
The test
Could your team run this in six months without us?
We ask ourselves that at every handover, and we would encourage you to ask it of any supplier before you sign. A consultancy comfortable making itself unnecessary is worth considerably more than one that is not, and in our experience is the one you call back.
Talk to usWant this applied to your problem?
Tell us what you are trying to do and what is currently stopping it. We will tell you which step you are actually stuck on, which is very often step one, discovered late.