Why we never certify our own work
We build AI and we test AI. The two share skills but never share a verdict. Here is why that rule exists, and what it means for clients.
Frontier 7 does two things: we build AI products for organisations, and we independently test the security of AI systems. One rule keeps the two apart. We never issue an independent security verdict on a system we built.
The conflict of interest
A builder that marks its own work has a conflict of interest, however skilled and well-intentioned it is. It knows what it meant to build, which makes it worse at seeing what it actually built. It also has a commercial interest in the result.
Independent assurance is valuable precisely because the party giving the verdict had no hand in the design and gains nothing from a clean result. Remove that independence and the report becomes a self-assessment with better formatting.
What we do instead on our own builds
We do not skip testing on our builds. Quite the opposite: a security test is a gate before every handover, threat-modelled from the start and run by people trained to attack AI systems.
The difference is the label. That report is our own quality check, so it is called internal QA, every time. It is never presented as independent assurance, and we do not let it be used as such.
If a client needs independent sign-off on something we built, for a regulator, a board or their own customers, that sign-off comes from another firm. We help them arrange it and give the testers the access and documentation they need. The verdict is theirs.
Why we hold the line, even when it costs us work
It would sometimes be easier, and more profitable, to offer a client “build and certify” as one package. We do not, for three reasons:
- It protects the client. A verdict that cannot be questioned on independence is worth more to the people who rely on it.
- It protects our testing. Our assurance work is only credible if it is never mixed with our own builds.
- It is how mature disciplines work. Financial audit separated preparing the accounts from auditing them for the same reason.
What this means in practice
When a request arrives, we ask the same questions in the same order: can we do it well, is there already a system, did we build any part of it, and has every party signed the authorisation? If the answer to the third question is yes, independent testing by us is off the table, and we say so on the first call.
It is a simple rule. We think it is one of the most useful things we can offer.