Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence

They answer different questions. The NIST AI RMF tells you what good AI risk management looks like, in four functions: GOVERN (policies, roles and accountability), MAP (context, intended use and impacts), MEASURE (testing, evaluation and tracking) and MANAGE (prioritizing, responding and monitoring). Nobody certifies you against it, but customers and procurement teams use it as a checklist. ISO/IEC 42001 is the management system an auditor certifies: it checks that you run AI risk management as a repeatable process with records. The EU AI Act is law for providers and deployers of AI systems placed on the EU market or whose output is used in the EU (Article 2(1)), wherever they are established.

Most teams need the AI Act analysis first, because it decides what is mandatory and when, then ISO/IEC 42001 if customers ask for a certificate, and the NIST RMF as the working vocabulary for risk reviews. The same engineering records serve all three.

Start each AI system’s record with two facts: your role and its risk class. A provider develops an AI system, or has one developed, and places it on the market under its own name; a deployer uses one under its own authority. A SaaS company that ships an AI feature is usually its provider, and its business customers are deployers. Building on a hosted general-purpose model does not make you that model’s provider: the model vendor owes you documentation on its capabilities and limits (Article 53(1)(b)), and you are the provider of the system you build with it. The Commission’s guidelines treat a downstream modifier as the provider of the modified general-purpose model when the modification uses more than a third of the original model’s training compute.

Classes stack. A high-risk system that talks to people also carries the transparency duties, and every provider and deployer has the AI literacy duty. Article 6(3) lets a provider conclude that an Annex III system is not high-risk when it does not materially influence decisions, for example because it performs a narrow procedural task; that conclusion must be documented and the system still registered.

Articles 9 to 15 and 17 read like a secure development life cycle for models. Each maps to work you can schedule and evidence you can keep with the release. Article 15(5) is worth reading in full: it asks for measures to prevent, detect, respond to, resolve and control attacks that manipulate training data (data poisoning) or pre-trained components (model poisoning), inputs designed to make the model err (adversarial examples or model evasion), confidentiality attacks and model flaws. Since 27 July 2026, a high-risk system that meets the Cyber Resilience Act’s essential requirements is deemed to meet Article 15’s cybersecurity requirements (Article 42(3)).

A high-risk system placed on the market before 2 December 2027 (or 2 August 2028 for Annex I) is covered only once it has a significant design change after that date (Article 111(2)), so record design changes deliberately. Post-market monitoring (Article 72) and serious-incident reporting (Article 73: within 15 days, 2 days for a widespread infringement or critical infrastructure, 10 days where a person has died) sit outside the deferred sections; confirm their timing for your systems with counsel.

Article 50 has applied since 2 August 2026, and it reaches far more products than the high-risk rules. If people interact directly with your AI system, the provider must design it so they are told, unless it is obvious from context. If your system generates synthetic audio, image, video or text, the provider must mark the output in a machine-readable format so it is detectable as artificially generated, with solutions that are effective, interoperable, robust and reliable as far as technically feasible; assistive editing that does not substantially alter the input is exempt. Deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest unless a person reviewed it and holds editorial responsibility.

For engineering this means a disclosure in the conversation UI, provenance metadata and watermarking on generated media and text where feasible, tests that the marking survives your own export paths, and a decision record for anything you treat as exempt. The Commission published a Code of Practice on marking and labelling AI-generated content on 10 June 2026 and guidelines on the Article 50 obligations on 20 July 2026; use them to choose techniques. For systems already on the market before 2 August 2026, the marking duty applies from 2 December 2026.

Use the AI RMF’s subcategories as the questions in your AI risk review and record the answer and its evidence for each system. The ones engineering owns most directly are GOVERN 1.6 (an inventory of AI systems), MAP 1.1 (intended purposes and context documented), MAP 3.5 (human oversight processes defined), MEASURE 2.5 (validity and reliability demonstrated, limits of generalization documented), MEASURE 2.7 (security and resilience evaluated and documented), MANAGE 2.4 (mechanisms to supersede, disengage or deactivate a system behaving outside its intended use) and MANAGE 4.3 (incidents and errors tracked, responded to and communicated).

AI 600-1 adds 12 risks that generative AI creates or makes worse: CBRN information or capabilities; confabulation; dangerous, violent or hateful content; data privacy; environmental impacts; harmful bias or homogenization; human-AI configuration; information integrity; information security; intellectual property; obscene, degrading or abusive content; and value chain and component integration. Each suggested action has an ID tied to an AI RMF subcategory, such as GV-1.6-001 (add generative AI systems to the inventory) or MS-2.7-007 (red-team for prompt injection, adversarial examples, data poisoning and membership inference). Several map straight to guides here: confabulation to /domains/ai-emerging/llm-security/llm-misinformation/, information security to /domains/ai-emerging/llm-security/prompt-injection-boundaries/ and value chain to /domains/ai-emerging/ml-security/model-artifact-security/.

NIST says AI RMF 1.0 is being revised under the July 2025 AI Action Plan, which asked it to remove references to misinformation, diversity, equity and inclusion, and climate change. Until a revision is published, cite 1.0 and AI 600-1 by name and date, and expect subcategory references to need a review when it lands.

ISO/IEC 42001 follows the same harmonized structure as ISO/IEC 27001, so it fits beside an existing information security management system (see /frameworks/iso-27001-secure-development/). Clause 4 asks you to determine your role for each AI system, such as provider, producer, customer or partner. Clause 6 adds three AI-specific steps: AI risk assessment (6.1.2), AI risk treatment (6.1.3), which selects controls and records them in a statement of applicability with the reason for including or excluding each, and AI system impact assessment (6.1.4) on individuals, groups and society. Clause 8 runs those assessments at planned intervals and when things change, and clause 9 checks the system works through monitoring, internal audit and management review.

Annex A lists reference control objectives for AI policy, internal organization, resources, impact assessment, the AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships; Annex B gives implementation guidance. An auditor samples records: a life cycle with verification and validation before release, event logs, data provenance, the impact assessments themselves and evidence that findings were acted on. ISO/IEC 42005:2025 gives guidance on the impact assessment, and certification bodies follow ISO/IEC 42006:2025.

A certificate is useful assurance for customers, but it is not a presumption of conformity with the AI Act. Presumption comes from harmonised standards whose references the Commission publishes in the Official Journal. CEN and CENELEC published EN 18286, the quality management standard written for Article 17, in July 2026; risk management (prEN 18228), cybersecurity (prEN 18282) and logging (prEN 18229-1) drafts went through public enquiry in the summer of 2026.

Each row is a practice you would do anyway for a well-run AI feature. Keep its evidence once and cite it from each framework’s assessment.

Keep an AI system register in the repository, one entry per system, and review it like code. Each entry records the purpose, your role, the risk class with its rationale and who reviewed it, the model and version, evaluations run against that version, how people are told they are dealing with AI, how output is marked, log retention, the oversight design and an incident contact. The register below has two systems: a support assistant with transparency duties and a CV ranker that the legal review classified as high-risk under Annex III point 4(a).

{
  "as_of": "2026-10-10",
  "systems": [
    {
      "id": "support-assistant",
      "purpose": "Answer customer questions from the help centre",
      "our_role": "provider",
      "risk_class": "transparency",
      "classification": {
        "rationale": "Chat assistant; no Annex III use",
        "reviewed_by": "legal",
        "reviewed_on": "2026-09-30"
      },
      "model": {
        "name": "hosted-model",
        "version": "2026-08"
      },
      "evaluations": [
        {
          "suite": "safety-and-security",
          "model_version": "2026-08",
          "run_on": "2026-09-28",
          "passed": true
        }
      ],
      "interacts_with_people": true,
      "ai_disclosure": "Banner and first message say the assistant is AI",
      "incident_contact": "ai-incidents@example.com"
    },
    {
      "id": "cv-ranker",
      "purpose": "Rank job applications for HR customers",
      "our_role": "provider",
      "risk_class": "high-risk-annex-iii",
      "classification": {
        "rationale": "Annex III point 4(a): filtering job applications",
        "reviewed_by": "legal",
        "reviewed_on": "2026-09-30"
      },
      "model": {
        "name": "ranker",
        "version": "3.2"
      },
      "evaluations": [
        {
          "suite": "accuracy-and-bias",
          "model_version": "3.1",
          "run_on": "2026-09-01",
          "passed": true
        }
      ],
      "risk_register": "docs/ai/cv-ranker/risks.md",
      "technical_documentation": "docs/ai/cv-ranker/annex-iv.md",
      "log_retention_days": 30,
      "incident_contact": "ai-incidents@example.com"
    }
  ]
}

The checker needs only the Python standard library. It fails when a classification lacks a rationale or a named reviewer or is over a year old, when there is no passing evaluation of the current model version from the last 90 days, when a system people talk to has no AI disclosure or a generator has no output marking, and when a high-risk system lacks a risk register, technical documentation, a human-oversight design or six months of log retention. It also prints how many days remain before the high-risk dates. On the register above it reports that the CV ranker’s evaluation is for version 3.1 while 3.2 is deployed, that it has no oversight design and that its logs are kept for 30 days. Run it in CI on every change to the register and on a schedule, so evaluations do not quietly expire.

"""Check an AI system register for evidence gaps (Python 3.11+, standard library)."""
import json
import sys
from datetime import date

ROLES = {"provider", "deployer", "importer", "distributor"}
CLASSES = {
    "prohibited", "high-risk-annex-iii", "high-risk-annex-i", "transparency", "minimal",
}
# EU AI Act, Article 113 as amended by Regulation (EU) 2026/1744.
HIGH_RISK_FROM = {
    "high-risk-annex-iii": date(2027, 12, 2),
    "high-risk-annex-i": date(2028, 8, 2),
}
MAX_EVAL_AGE_DAYS = 90
MAX_REVIEW_AGE_DAYS = 365
MIN_LOG_DAYS = 183  # Articles 19(1) and 26(6): at least six months


def problems(system, today):
    found, sid = [], system.get("id", "?")
    if system.get("our_role") not in ROLES:
        found.append(f"{sid}: role must be one of {sorted(ROLES)}")
    risk = system.get("risk_class")
    if risk not in CLASSES:
        found.append(f"{sid}: risk_class must be one of {sorted(CLASSES)}")
    if risk == "prohibited":
        found.append(f"{sid}: classified as a prohibited practice; it must not ship")
    review = system.get("classification") or {}
    if not (review.get("rationale") and review.get("reviewed_by")):
        found.append(f"{sid}: classification needs a rationale and a named reviewer")
    elif (today - date.fromisoformat(review["reviewed_on"])).days > MAX_REVIEW_AGE_DAYS:
        found.append(f"{sid}: classification review is over a year old")
    version = system.get("model", {}).get("version")
    current = [
        e for e in system.get("evaluations", [])
        if e.get("model_version") == version and e.get("passed")
        and (today - date.fromisoformat(e["run_on"])).days <= MAX_EVAL_AGE_DAYS
    ]
    if not current:
        found.append(f"{sid}: no passing evaluation of model {version} in 90 days")
    if system.get("interacts_with_people") and not system.get("ai_disclosure"):
        found.append(f"{sid}: users are not told they are talking to AI (Art. 50(1))")
    if system.get("generates_content") and not system.get("output_marking"):
        found.append(f"{sid}: generated content is not machine-marked (Art. 50(2))")
    if not system.get("incident_contact"):
        found.append(f"{sid}: no incident contact")
    if risk in HIGH_RISK_FROM:
        for field in ("risk_register", "technical_documentation", "human_oversight"):
            if not system.get(field):
                found.append(f"{sid}: high-risk system without {field}")
        if system.get("log_retention_days", 0) < MIN_LOG_DAYS:
            found.append(f"{sid}: logs kept under six months")
        days = (HIGH_RISK_FROM[risk] - today).days
        found.append(f"{sid}: note: high-risk obligations apply in {days} days")
    return found


if __name__ == "__main__":
    register = json.load(open(sys.argv[1], encoding="utf-8"))
    today = date.fromisoformat(register.get("as_of") or date.today().isoformat())
    report = [p for system in register["systems"] for p in problems(system, today)]
    print("\n".join(report) or "register OK")
    sys.exit(1 if any(": note:" not in p for p in report) else 0)

The Commission proposed the Digital Omnibus on AI, COM(2025) 836, on 19 November 2025. Parliament and Council reached a provisional agreement on 7 May 2026; Parliament adopted it on 16 June and the Council on 29 June. It was signed on 8 July, published in the Official Journal on 24 July and entered into force on 27 July 2026 as Regulation (EU) 2026/1744. The proposal would have tied the high-risk dates to a Commission decision that standards and support tools were ready; the adopted text fixed them instead. It also softened the AI literacy duty, extended SME simplifications to small mid-caps, allowed processing of special categories of personal data for bias detection under safeguards (Article 4a), spelled out what an initial provider must give a new provider under Article 25(2): technical documentation, known limitations and failure modes, and targeted technical access, and added two prohibitions that apply from 2 December 2026: AI systems that generate non-consensual intimate imagery of identifiable people or child sexual abuse material. They cover a generator whose design makes such output a reasonably foreseeable and reproducible outcome without reasonable and adequate safeguards to prevent it, not only one built for it (Article 5(1a)), so image, video and audio generators need tested safety filters by that date.

Guidance keeps arriving: guidelines on prohibited practices (4 February 2025) and on the AI system definition (6 February 2025), the General-Purpose AI Code of Practice (10 July 2025), guidelines on general-purpose model obligations (18 July 2025), the Code of Practice on marking and labelling AI-generated content (10 June 2026) and the Article 50 guidelines (20 July 2026). The guidelines on classifying high-risk systems were still a draft (19 May 2026) on 10 October 2026, with the final version expected by the end of 2026. On the NIST side, the SP 800-53 control overlays for securing AI systems (COSAiS) were still at concept and outline stage, and the Cyber AI Profile (NIST IR 8596) was a preliminary draft.

It does not tell you whether a system is an AI system under Article 3(1), whether an Annex III use qualifies for the Article 6(3) exception, which role you hold in a given contract, or how national authorities will enforce. Sector law (medical devices, financial services, employment) and data protection law add their own duties. Record each of those decisions with the facts it rests on, who made it and when, and revisit it when the system, its use or the guidance changes. For product security duties that overlap, see /frameworks/product-security-obligations/.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal text. 13 June 2024 (OJ L, 12 July 2024).
2. Regulation (EU) 2026/1744 amending the AI Act (Digital Omnibus on AI). 8 July 2026 (OJ L, 24 July 2026).
3. European Commission: AI Omnibus enters into force. 27 July 2026.
4. AI Act Service Desk: timeline for the implementation of the EU AI Act
5. European Parliament Legislative Observatory: procedure 2025/0359(COD), Digital Omnibus on AI
6. European Commission: guidelines on transparency obligations for providers and deployers of certain AI systems. 20 July 2026.
7. European Commission: Code of Practice on marking and labelling AI-generated content. 10 June 2026.
8. European Commission: draft guidelines on the classification of high-risk AI systems. Draft, 19 May 2026.
9. European Commission: guidelines on the scope of obligations for providers of general-purpose AI models. 18 July 2025.
10. European Commission: standardisation of the AI Act
11. CEN-CENELEC: EN 18286 in the spotlight, supporting compliance with the AI Act
12. NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0). Version 1.0 (January 2023).
13. NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. July 2024.
14. NIST: AI Risk Management Framework (revision status)
15. ISO/IEC 42001:2023: Information technology, Artificial intelligence, Management system. Edition 1 (December 2023).

Reference information

Tags

AI evaluation and governanceCompliance and assurance evidenceRegulation

SDLC phase

PlanningTestingSecurity program

Role

DevelopersAppSec engineersPlatform engineers and SREsSecurity leaders

Download this guide as Markdown

Continue exploring