AI Implementation
Building and integrating AI systems end to end, with the evaluation set, guardrails and rollback path treated as part of the build rather than as a later phase.
Building an AI feature is the short part. Making it dependable enough that you can leave it running is the work, and it is where most implementations stop short.
We build the whole thing: the feature, the evaluation set that proves it still works next month, the guardrails that decide what it refuses, and the rollback path that has actually been tested.
What "end to end" means here#
| Included from day one | Why it is not a later phase |
|---|---|
| The held-out evaluation set | Without it, "it seems better" is the only available verdict, and quality drifts unnoticed |
| Guardrails as testable rules | Written as code, not as intentions in a prompt |
| Retrieval grounded in your data | With your permissions preserved, not flattened |
| Cost per successful outcome | A feature that delights and loses money at scale is a failure discovered late |
| The autonomy boundary | Exactly what it may do without a person, written down per feature |
| A rehearsed rollback | Timed, not described. The number decides how boldly anyone can move afterwards |
| Disclosure and marking | Required in the EU since 2 August 2026 where a person interacts directly with AI |
How the build runs#
A person decides the architecture. Agents write the change and its tests in the same pass. Every gate after that is real and allowed to stop the change: code review, the test suite, the security scan, then CI/CD.
The order is deliberate. Review runs before the tests, because a review after a green suite only reviews what the tests failed to notice. The security scan runs before deployment, because a finding in production is an incident and the same finding ten minutes earlier is a task.
What you own at the end#
Everything. The code, the evaluation set, the model cards, the guardrail specifications and the runbook. No component of the delivery depends on us continuing to be involved, and we will say plainly which parts your team can maintain and which will need a skill you do not currently have.
What we will not do#
- Ship without an evaluation set. It is the most valuable asset in an AI product and the one most often treated as an afterthought.
- Widen what a system does unsupervised because a model improved. That is a decision a person records, not a consequence of an upgrade.
- Promise a capability we have not built before without saying so. If something is new to us, you will hear that during the proposal rather than during the project.
How we work, in public#
The engineering model and the AI product discipline we use are published, including the KPIs, the release procedures and the templates for model cards and autonomy boundaries.
We also run our own AI products, which means these practices exist because the alternative was found out on live systems rather than because they read well.
Getting started#
The useful first conversation is about one specific process and what a wrong answer would cost. Get in touch.