Rules for accountable and traceable AI: system design, requirements management, signal validation and provenance authentication
-
Most AI governance documents AI processes and outputs after the fact. Controls exist as written attestations rather than as things that can be tested, and evidence is assembled retrospectively, separately, for each regime an organisation answers to. A firm subject to the EU AI Act, ISO/IEC 42001 and a sector regulator will typically produce three overlapping evidence packs by hand, none of which is reusable, and all of which describe the system as designed rather than as operated.
-
A statistical system can produce a correct output and be unable to account for it. In functions where a decision has to be defended — to a regulator, a court, a counterparty, an insurer — that gap stops deployment, or permits it while leaving the liability unpriced. Many organisations are now carrying both costs at once: AI stalled at pilot in the functions where it would be most valuable, and AI in production in functions where nobody has established what happens if the output is challenged.
-
-
1. Which compliance obligations can be satisfied by records generated during operation, and which require separate attestation?
-
2. Where do W3C PROV, the NIST AI Risk Management Framework, ISO/IEC 42001 and the EU AI Act overlap sufficiently that one record can serve several obligations?
-
3. What does an auditor or regulator accept as evidence that a control was operating, as distinct from evidence that it existed?
-
4. Can a requirement be expressed so that conformance is demonstrated rather than asserted, and at what cost in engineering effort?
