Approach
How we deliver AI in regulated organisations
Five steps, in this order, every engagement. Most expensive failures in this field come from doing step one fourth.
- 01 Week one, always
Draw the boundary
Before any architecture, we establish the highest classification of data the system will touch in production, not in the pilot. That one table decides most of what follows. Skipping it is the most expensive mistake in the field.
Deliverable: a table mapping each use case to a permitted deployment tier, with written reasoning that survives a change of staff.
- 02 Before anything is built
Define what correct means
An evaluation set from your real material: 100 to 200 questions or cases with reviewed correct answers, including ones the system should refuse. Without it nobody can answer "how accurate is it?", 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. Working software from the first fortnight, reviewed fortnightly against the evaluation set. Platforms and centres of excellence can wait until there is something to put in them.
Deliverable: software in your repository, with tests, CI and infrastructure as code from day one.
- 04 Continuously
Produce the evidence as you go
DPIA, risk entries, data flow documentation, NCSC CAF contributing-outcome commentary, Secure by Design artefacts and the ATRS record where they apply. Written while decisions are made, by the people making them.
Deliverable: an evidence pack your assurance function, accreditor, auditor or procurement panel can rely on. Hosts and orchestration come with DISA STIG and CIS Level 2 scan output and a justified deviation list.
- 05 The final fortnight
Hand it over properly
Runbook, architecture decision records, handover sessions with your engineers, and named internal owners for the corpus, infrastructure and evaluation.
Deliverable: your team can run, change and re-evaluate the system without us. Until then, we have not finished.
What we avoid
Six ways AI projects waste money
All six are common. All six are avoidable at no extra cost, if you know them before you commission the work.
The pilot on synthetic data
It proves a demo can be built, little else. Real corpora are messier and more sensitive than any demo sample. We ask for a slice of real material under a proper agreement, even if it takes three weeks to arrange.
The strategy phase you did not need
If you can name the three processes that hurt most, you do not need £25,000 of strategy telling you AI is transformative. You need an assessment of whether AI can fix those three, at a fraction of the cost.
The human-in-the-loop that is not
A person approving two hundred outputs an hour is not a control. Human review must be resourced, given realistic time, and evidenced. Otherwise stop claiming it.
The architecture you cannot leave
A supplier’s licensed middleware sitting permanently between you and your own systems. The build price looks competitive; the five-year cost does not. We keep model access behind an interface you own, so you can change your mind.
Compliance discovered at the end
A system built on a hosted API, then blocked at information governance, usually cannot be adjusted into compliance. The data flows are wrong at the foundation. That is why the boundary comes first.
The agent that should have been a script
When the task is the same every time, a deterministic pipeline beats an agent on cost and predictability. We build agents where the task varies from run to run.
The test
Could your team run this in six months without us?
We ask it at every handover. Ask any supplier before you sign.
Talk to usNext step
Want this applied to your problem?
Tell us what you are trying to do and what is in the way. We will tell you which step you are stuck on. Usually the first.