EU AI Act · NIST AI RMF · ISO/IEC 42001 · mapped to documented evidence a reviewer can re-run
Most AI governance is a document written after the fact, describing a system nobody can inspect. This is the opposite: the governance artifacts are engineering outputs, produced as the system runs, and each one maps to a specific control in the frameworks a regulated buyer already answers to. Evidence, not a legal opinion.
The Two-Domain Angle
The rare pairing is a person who builds the AI system AND produces the assurance evidence for it. In regulated settings such as healthcare and AML, the two jobs are usually done by different teams who never share a vocabulary. Here they are the same discipline: the engineer who ships it and the analyst who proves it are one person, so the audit trail is a byproduct of the build rather than an argument bolted on later.
Artifact → Control Mapping
ARTIFACT 01
Deterministic audit-trail documentation
Records produced as the system runs, not reconstructed after the fact.
maps to: EU AI Act Art. 12 (record-keeping / logging) · NIST AI RMF MEASURE · ISO/IEC 42001 operational records
ARTIFACT 02
Adversarial validation record
140/140 adversarial attempts caught on a synthetic corpus, mapped to the OWASP LLM Top 10, replayable.
maps to: EU AI Act Art. 15 (accuracy, robustness, cybersecurity) · NIST AI RMF MANAGE · ISO/IEC 42001 controls testing
ARTIFACT 03
Human-oversight logs
Records of where a human decision gates the system, and what the human saw at the decision point.
maps to: EU AI Act Art. 14 (human oversight) · NIST AI RMF GOVERN · ISO/IEC 42001 roles and oversight
ARTIFACT 04
Bias and quality documentation
Quality-management records and bias documentation produced as the system was built, not reconstructed after.
maps to: EU AI Act Art. 9-11 (risk management, data governance, technical documentation) · NIST AI RMF MAP
What This Is Not
This is engineering evidence, not a legal opinion and not a certification. It does not assert that a system is "compliant", that is a determination for counsel and an accredited auditor. What it asserts is narrower and stronger: the technical evidence a control requires exists, is documented, and can be independently re-run. That is the part an engineer owns, and the part most governance decks are missing.
# Governance artifact contract
for control in [eu_ai_act, nist_ai_rmf, iso_42001]:
evidence = artifact_for(control) # produced during the build
assert documented(evidence) # dated, attributable
assert reproducible(evidence) # a reviewer can re-run it
# result: the audit trail is a byproduct, not a retrofit
Why This Matters For A Governance Or Risk Team
A GRC or compliance function spends most of its time chasing engineers for evidence that was never captured. When the evidence is generated by the build and mapped to the framework at the source, the review shrinks to reading a documented record instead of reconstructing history. It also closes the gap a skeptical auditor probes immediately: whether the artifact was written to describe the system, or produced by it. Here it is produced by it.
PROOF
✓3 frameworks mapped: EU AI Act · NIST AI RMF · ISO/IEC 42001, per artifact
✓Documented evidence: Produced during the build, not reconstructed after the fact
✓140/140 adversarial record: Mapped to the OWASP LLM Top 10, caught on a synthetic corpus, replayable
✓Evidence, not opinion: No compliance or certification claimed; the technical artifact a control requires, re-runnable
