Compliance

Compliance, framework by framework

Ten frameworks touch AI traffic in some way. Each page here says what yours asks of you, which controls run in the product, and exactly what stays with you.

What these pages are, and what they are not

They map published obligations to product capabilities, with the control statuses, rule settings and evidence each framework expects. What they are not is legal advice, certification, or a substitute for your own work. Several of these frameworks require policies, risk assessments, contracts and training that no product can perform, so every page ends with the list of things that stay with you.

How the compliance surface works

Four steps, the same for every framework, so the answer to an auditor does not depend on which page they open.

01

Put the framework in scope

Turn on the frameworks that apply to you. Each one brings the controls it expects, mapped to what the product can actually enforce.

02

Assess, and work the gaps in order

An assessment reports each control with a status. Missing rules come first, then rules that exist but are switched off, then rules aimed the wrong way. You resolve them in that order rather than alphabetically.

03

Evidence what cannot be automated

Risk assessments, training and contracts are recorded as attestations: a named person, a timestamp, and an expiry that comes back to you when it lapses.

04

Export the pack, per period

Each period produces a pack covering control status, live rule state, settings, retention and inventory, with no prompt or response content in it. That is what makes it safe to hand over.

The finding that matters most, in the whole of this section: a control that exists but is switched off is reported as a gap, not a pass. It is the most common real-world failure, and the one an auditor finds on the day you least want them to.

Common questions

No, and any vendor who answers yes to that question should be treated with suspicion. Every framework here contains organisational work that no product can perform: classification, contracts, risk assessment, training, and in most cases an audit. What AI-FW does is run the technical controls on the AI path and keep the evidence an auditor asks to see.

Because the boundary is the useful information. If you know that a product handles the runtime controls and not the management system, you can plan the rest of the work instead of discovering the gap during an audit. Each page lists what stays with you, in the same place, on every framework.

Start with whichever one has a deadline or a customer behind it: an EU AI Act duty that is already live, a security questionnaire, a SOC 2 window opening, or a payment scope question. The controls overlap heavily, so the first framework you build is usually the expensive one and the rest are cheap.

No. These pages map product capabilities to published expectations so that a technical and a compliance reader can have the same conversation. Applicability, materiality and sufficiency are judgements for your counsel, and where relevant your auditor, assessor or certification body.

Bring your framework to the table

Tell us which obligations you are answering and which auditor you are answering to. We will walk the controls that apply, show what the assessment reports on the day, and be explicit about what the product does not do.

These pages map product capabilities to published expectations. They are not legal, audit or certification advice, and they create no compliance representation. Confirm applicability with qualified counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed, and instruments change: re-check the primary sources linked on each page, and the page itself, before relying on a date.