Trust
Compliance
Frameworks we work to, and the delivery artefacts that evidence each obligation. We claim no certification we do not hold.
ISO/IEC 42001
Certifiable management system standard
Specifies an AI management system: governance, roles, risk treatment, lifecycle controls and continual improvement. It is the framework an organisation can be audited and certified against.
How we use it · We work to it as the management system that holds everything else, and we produce delivery artefacts that map to its controls. Certification status is listed under our own certifications.
NIST AI Risk Management Framework
Voluntary risk framework (United States)
A structured method for identifying, measuring and managing AI risk across govern, map, measure and manage functions. Not law, and not certifiable.
How we use it · We use it as the risk method inside the management system, particularly its measurement emphasis, which maps closely to how we build evaluation.
EU AI Act
Binding law with penalties
Risk-tiered obligations covering risk management, data governance, technical documentation, human oversight, accuracy, robustness, cybersecurity, logging, transparency, post-market monitoring and incident reporting.
How we use it · We assess whether and where a client’s system is in scope, and we build the documentation and oversight evidence during delivery rather than retrofitting it.
ISO/IEC 27001 · SOC 2
Information security
Information security management and service-organisation controls. Neither is AI-specific, and both are usually already in place at the organisations we work with.
How we use it · We work within a client’s existing control environment rather than introducing a parallel one.
GDPR / UK GDPR
Data protection law
Lawful basis, minimisation, purpose limitation, data subject rights, and requirements around automated decision-making.
How we use it · Data protection impact considerations are part of Frame, not a document produced at the end.
Obligation to artefact
What we produce during delivery, and what it evidences. Producing these during Prove and Build costs days; assembling them afterwards costs a quarter.
| Obligation area | Artefact we produce | What it evidences |
|---|---|---|
| Risk management system | Risk register from Frame, maintained through delivery | Dated register with treatment decisions and owners |
| Data governance and provenance | Dataset documentation, lineage records, exclusion rationale | Provenance from source to index, with what was excluded and why |
| Technical documentation | Architecture decision records, system description | Decisions with rejected options and revisit triggers |
| Human oversight | Approval gate design, reviewer interface, escalation edges | Oversight as a mechanism in the graph, tested in the evaluation suite |
| Accuracy and robustness | Evaluation suite, agreement study, regression gate | Results with uncertainty, plus the CI gate that blocks regressions |
| Logging and traceability | Framework-independent trace format and store | Append-only records with replay fidelity measured |
| Cybersecurity | Threat model, adversarial test suite, supply-chain controls | Signed artefacts, SBOM, injection cases in the regression gate |
| Post-market monitoring | Production sampling, drift monitoring, override tracking | Standing review process with defined triggers |
Nothing on this page is legal advice. It describes how we work and what we produce. Whether a specific obligation applies to your system is a question for your own advisers, and we will happily give them the technical detail they need. See also evaluation & assurance.
Bring your risk function to the first meeting.
The conversations that go well are the ones where second line is in the room early. We would rather hear the objection now.