Responsible AI
Responsible AI is not a values statement. It is a set of engineering practices — measuring quality against a fixed test set, constraining what a system may do, logging what it did, and keeping a person accountable for consequential decisions. Done early it costs little. Done after an incident it costs a great deal.
Nobody can say whether it's working
Ask most teams running an AI feature how good it is and you get anecdotes. There is no test set, no baseline, and no alert — so a prompt change or a model update can degrade quality for weeks before anyone notices, and when a customer complains there is no way to reconstruct what happened.
You’ll recognise this if
- Quality is assessed by whether anyone has complained recently
- You cannot reconstruct why the system produced a particular output
- Prompt changes ship on the basis that they seemed better
- You are entering a regulated market and cannot evidence your controls
What we actually deliver
An evaluation set that reflects your real use
Real inputs with agreed correct outputs, including the awkward edge cases, run automatically on every change. This single artefact turns quality from an argument into a number.
Guardrails at the boundary
Constraints on inputs and outputs — what topics are refused, what may never be produced, what triggers a handoff. Enforced in code around the model rather than requested politely inside a prompt.
Audit logging
What was asked, what context was retrieved, what was produced, and what the system then did. Enough to answer a customer complaint, an internal review, or a regulator six months later.
Human review where the stakes justify it
A designed escalation path for consequential decisions, with the reviewer given enough context to actually judge rather than rubber-stamp.
The way we approach it
Start from consequences, not principles
We work out what the worst realistic outcome of this system being wrong actually is, and size the controls to that. A drafting assistant and a system touching someone's finances warrant very different treatment.
Test for the failures that matter to you
Generic safety benchmarks say little about your context. We build tests around your own failure modes — the confusions specific to your domain, your customers, your data.
Documentation that survives staff turnover
What the system does, what it must not do, what was decided and why. The people who answer for it in two years will not be the people who built it.
What changes
- A number for quality, tracked over time instead of debated
- Regressions caught before release rather than by a customer
- A defensible record of what the system did and why
- Evidence of controls, ready for procurement or regulatory review
Asked often enough to answer here
Isn't this overkill for a small internal tool?
The controls should be proportionate, and for a low-stakes internal tool that may mean an evaluation set and basic logging — a few days of work. What is rarely proportionate is nothing at all, because without a test set you cannot tell whether a change made things worse.
Does this cover the EU AI Act?
We build the technical foundations that obligations of that kind rest on — documented purpose, evaluation records, logging, human oversight. We are engineers rather than your legal counsel, so we work alongside your advisers rather than replacing them.
Can you assess a system we already have live?
Yes, and it is a common starting point. We review what is running, build the evaluation set that should have existed, and give you a prioritised list of gaps with the risk of each one stated plainly.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.