RAINavigator

Art. 72 monitoring plan plus Art. 73 serious-incident reports (15 days; 2 days for widespread infringement) — reconciled in one runbook with GDPR Art. 33 (72h), NIS2 (24h/72h) and DORA timelines.

• article · Art. 72/73 — Post-Market Monitoring & Incidents
• control · Art. 72/73 — Post-Market Monitoring & Incidents → CO: Performance Monitoring & Drift Management
• regulation · DORA
• regulation · NIS2 Directive
• useCase · Clinical Imaging Triage & Patient Follow-Up
• useCase · Cross-Border Statutory Tax & Wealth Filing
• useCase · Procurement Variance & Vendor KPI Monitoring
• useCase · Trade Lifecycle & Settlement Reconciliation

Machine-readable composition manifest per AI application: base-model metadata (identifier, version, parameters, supplier tag), dataset provenance (fine-tune/RAG sources, scrubbing logs, consent records), vector-namespace bindings and access rules, active runtime-policy ruleset versions and thresholds, performance & safety verification history (bias scores, accuracy benchmarks, red-team reports). Complements the SBOM (software dependencies) with the AI-specific supply chain; auto-published into the register on every change. Feeds the Art. 11 technical file, vendor due diligence (contractually demanded from providers) and Colorado/LL144-class disclosure duties. Factsheets are its human-readable projection for auditors.

• article · Art. 11 — Technical Documentation
• control · Art. 26 — Deployer Obligations → CO: Embedded-AI Vendor Governance
• useCase · Continuous Technical Documentation Generation

Model lineage, architecture, pre-training data sources, context limits, evaluation benchmarks and known failure modes.

• article · Art. 11 — Technical Documentation
• control · Art. 13 — Transparency to Deployers → CO: System Traceability & Decision Transparency
• useCase · Algorithmic Portfolio Execution & Advisory
• useCase · Automated Financial Forecasting & Audit Trails
• useCase · Continuous Technical Documentation Generation
• useCase · Enterprise SDLC Code Automation & QA
• useCase · Legal Contract & Regulatory Clause Extraction

Art. 10 evidence: provenance and lineage of training/validation/test data, representativeness analysis, bias metrics and mitigation reports per ISO/IEC 5259 and BSI QUAIDAL data-quality metrics; baseline assumptions documented (Art. 10(2)(d)).

• article · Art. 10 — Data Governance
• control · Art. 10 — Data Governance → CO: Data Quality & Origin Management
• useCase · Digital Shelf Analytics & Competitive Intelligence
• useCase · Generative Asset Production & Virtual Try-On
• useCase · Supplier Master Data & ESG Risk Screening

Art. 47 written declaration that the high-risk system meets the AI Act requirements; renewed on substantial modification.

• article · Art. 43 — Conformity Assessment
• article · Art. 47/48 — CE Marking & Declaration of Conformity
• useCase · Continuous Technical Documentation Generation
• useCase · Enterprise Marketing Disclosure Compliance
• useCase · Regulatory Change Management & Policy Updating

Art. 13 deployer-facing documentation: intended purpose, capabilities, limitations, expected accuracy, oversight measures — plus Art. 50 user-facing disclosures.

• article · Art. 13 — Transparency to Deployers
• article · Art. 50 — Transparency Duties
• useCase · Generative Asset Production & Virtual Try-On
• useCase · Omnichannel Virtual Support & Voice Bots

Text-derived from Art. 43(4) read with Annex IV point 2(f): the documented description of the changes the provider pre-determined at the initial conformity assessment — the performance and data corridors within which automated retraining and redeployment may proceed, the methods used to make the change, and the limits beyond which the modification becomes substantial and a new conformity assessment is owed.

• article · Art. 43 — Conformity Assessment
• control · Art. 43 — Conformity Assessment → CO: Model Registry Gate & Drift Interlock

CRA evidence: software bill of materials incl. model weights and datasets, vulnerability handling and patch history — reused for NIS2 supply-chain security and DORA third-party registers.

Why practice-derived: The CRA requires a software bill of materials, but no CRA article node carries it in this graph yet — upgrade to text-derived once one does.

• regulation · Cyber Resilience Act
• regulation · NIS2 Directive
• useCase · Enterprise SDLC Code Automation & QA

The Art. 11 technical file: system description, architecture, capabilities/limitations, risk measures, development process. Built incrementally during development — retro-reconstruction is an audit red flag. Reviewed by a notified body where the Annex VII route applies.

• article · Art. 11 — Technical Documentation
• article · Art. 43 — Conformity Assessment
• useCase · Clinical Imaging Triage & Patient Follow-Up
• useCase · Continuous Technical Documentation Generation

Art. 48 visible/indelible marking; digital CE via UI or machine-readable code for digitally provided systems; notified-body number displayed where involved.

• article · Art. 47/48 — CE Marking & Declaration of Conformity

Documented quality management system: design controls, development testing, validation, supplier management, post-market processes — the documentation set that EN 18286:2026 is expected to address once the standard is cited in the OJEU.

• article · Art. 17 — Quality Management System

Fundamental-rights impact assessment (Art. 27, deployer-side) generalized to the AI Impact Assessment: societal, legal and operational risk evaluation per ISO/IEC 42005 and ISO 42001 Clause 8.2, defining HITL intervention parameters and acceptable-use bounds. Cadence: pre-deployment, refreshed annually and on major model updates — a stale AIIA is a finding, not a document.

• article · Art. 26 — Deployer Obligations
• article · Art. 27 — Fundamental Rights Impact Assessment
• regulation · EU AI Act
• useCase · Clinical Imaging Triage & Patient Follow-Up

Societal, legal and operational risk evaluation per workflow, including the defined HITL intervention parameters and residual-risk acceptance.

• article · Art. 9 — Risk Management
• control · Art. 9 — Risk Management → CO: Pre-Deployment AI Risk & Impact Assessment
• useCase · Clinical Imaging Triage & Patient Follow-Up
• useCase · KYC & Client Onboarding Automation (Managed Service)

GDPR Art. 35 assessment for high-risk processing; supervisory-authority consultation where residual risk stays high. ISO/IEC 42005 provides the AI-specific method.

• article · GDPR Art. 35 — DPIA

Accredited third-party certificate of the AI management system (audited per ISO/IEC 42006). Strong organisational assurance signal for procurement and insurers — but no presumption of conformity under the AI Act.

Why practice-derived: A management-system certificate is voluntary assurance, not a statutory artifact.

• standard · ISO/IEC 42001:2023 (AIMS)

Binding vendor terms on zero data retention, non-training use, sub-processor list and security boundary, with technical verification records.

• article · Art. 25 — Value Chain / Role Flip
• useCase · Generative Asset Production & Virtual Try-On

Art. 15 evidence: declared accuracy metrics, adversarial and corruption robustness results (DIN SPEC 92001-2, ISO 24029), penetration and jailbreak-resistance testing, groundedness evaluation scores.

Why practice-derived: Art. 15 sets accuracy, robustness and cybersecurity duties; the test and red-teaming report format is professional practice.

• article · Art. 15 — Accuracy, Robustness, Cybersecurity
• control · Art. 15 — Accuracy, Robustness, Cybersecurity → CO: Adversarial Robustness Verified
• useCase · Enterprise SDLC Code Automation & QA
• threat · LLM01 Prompt Injection

Quantitative demographic-parity, disparate-impact and false-positive distribution analysis against a fixed test baseline.

• article · Art. 10 — Data Governance
• useCase · KYC & Client Onboarding Automation (Managed Service)

Practice-derived artifact: the measured result of probing the retrieval path with low-privilege principals, the ACL reconciliation between source repositories and the index, and the outcome of the response-grounding rights re-check. Records which corpora were probed, which principals were used and every segment that was returned without an entitlement.

Why practice-derived: No provision names this report; it is the standard way the vector-ACL control objective is shown to hold.

• control · GDPR Art. 32 — Security of Processing → CO: Vector & Chunk-Level Access Control

The single highest-leverage artifact: hash-chained, WORM-stored logs with structured decision traces. Required capability fields per FprEN ISO/IEC 24970: input/output traces, execution timestamps, acting user/agent identity, referenced sources, human overrides. Audit-packet spec per event: model version, system-prompt/context hash, hyper-parameters (temperature, top-p), output payload, confidence score, active policy-ruleset versions, human override record. Simultaneously serves AI Act Art. 12, GDPR accountability, DORA incident reporting, NIS2 logging, PLD disclosure duties and its rebuttable defect presumption; financial-sector regimes push retention to 7 years (SEC 17a-4-class WORM rules). Credibility bar: anchor hash-chain heads externally (qualified timestamp / eIDAS ledger) so integrity survives an insider with admin rights.

• article · Art. 12 — Record-Keeping / Logging
• article · CRA Art. 14 — Vulnerability & Severe-Incident Reporting
• article · DORA Art. 19 — Major ICT-Incident Reporting
• article · GDPR Art. 33/34 — Personal-Data Breach Notification
• article · HIPAA Breach Notification Rule
• article · NIS2 Art. 23 — Significant-Incident Reporting
• article · SEC Form 8-K Item 1.05 — Material Cybersecurity Incident
• control · Art. 12 — Record-Keeping / Logging → CO: Log Completeness & Coverage
• control · Art. 12 — Record-Keeping / Logging → CO: Log Integrity & Non-Repudiation
• control · Art. 15 — Accuracy, Robustness, Cybersecurity → CO: Non-Human Identity Governance
• regulation · AI Liability Directive (withdrawn)
• regulation · DORA
• standard · FprEN ISO/IEC 24970 (AI Logging)
• regulation · GDPR
• regulation · HIPAA (US Health Privacy)
• regulation · NIS2 Directive
• regulation · Revised Product Liability Directive
• useCase · Algorithmic Portfolio Execution & Advisory
• useCase · Automated Financial Forecasting & Audit Trails
• useCase · Clinical Imaging Triage & Patient Follow-Up
• useCase · Continuous Technical Documentation Generation
• useCase · Cross-Border Statutory Tax & Wealth Filing
• useCase · Digital Shelf Analytics & Competitive Intelligence
• useCase · Dynamic Deal Desk & Quoting Engine
• useCase · Enterprise Marketing Disclosure Compliance
• useCase · Procurement Variance & Vendor KPI Monitoring
• useCase · Regulatory Change Management & Policy Updating

Control-level evidence for the OWASP mappings: guardrail trigger records, blocked-prompt statistics (LLM01), runtime output-sanitization logs (LLM05), groundedness-check outcomes — the empirical proof that declared controls actually execute.

• article · Art. 15 — Accuracy, Robustness, Cybersecurity
• control · Art. 50 — Transparency Duties → CO: AI Interaction & Content Disclosure
• control · Art. 15 — Accuracy, Robustness, Cybersecurity → CO: Runtime Injection Defense
• useCase · Dynamic Deal Desk & Quoting Engine
• useCase · Enterprise Marketing Disclosure Compliance
• threat · LLM01 Prompt Injection
• threat · LLM05 Improper Output Handling
• threat · LLM09 Misinformation
• useCase · Omnichannel Virtual Support & Voice Bots

Per-execution audit packet: timestamp, model version, system prompt, input-context hash, hyper-parameters, output payload, confidence score and human override record.

• article · Art. 12 — Record-Keeping / Logging
• control · Art. 12 — Record-Keeping / Logging → CO: Log Integrity & Non-Repudiation
• standard · IFRS / US GAAP Reporting Assurance
• useCase · Algorithmic Portfolio Execution & Advisory
• useCase · Automated Financial Forecasting & Audit Trails
• useCase · Cross-Border Statutory Tax & Wealth Filing
• useCase · KYC & Client Onboarding Automation (Managed Service)
• useCase · Legal Contract & Regulatory Clause Extraction
• useCase · Trade Lifecycle & Settlement Reconciliation

Practice-derived artifact: one record per deployment attempt — candidate version, measured drift statistics against the PCCP corridors, gate verdict, and where a rollout was blocked, the re-assessment it was routed to. This is what shows the corridor was honoured rather than merely documented.

Why practice-derived: Art. 43(4) requires the change to stay inside the documented corridor; it does not name a gate log. Recording the gate decision is practice.

• control · Art. 43 — Conformity Assessment → CO: Model Registry Gate & Drift Interlock

Art. 14 evidence: documented oversight design (gates, thresholds, veto powers), reviewer qualification, and the record of actual approvals, overrides and escalations — also the GDPR Art. 22 meaningful-human-involvement proof.

Why practice-derived: Art. 14 requires oversight measures; a written SOP with intervention records is the customary way to show them, not a literal statutory artifact.

• article · Art. 14 — Human Oversight
• article · GDPR Art. 22 — Automated Decisions
• control · Art. 12 — Record-Keeping / Logging → CO: Log Access & Retention Governance
• control · Art. 14 — Human Oversight → CO: Oversight Competence & Authority
• useCase · Clinical Imaging Triage & Patient Follow-Up

DORA Art. 30 / AI Act deployer evidence: scored vendor assessments (jurisdiction, ZDR, BYOK, C5/AIC4/42001 evidence, tenant isolation), contract register, exit strategies for critical third parties.

Why practice-derived: Art. 26 and DORA require control over third parties; the due-diligence file is the customary record of it.

• article · Art. 26 — Deployer Obligations
• control · Art. 26 — Deployer Obligations → CO: Embedded-AI Vendor Governance
• regulation · DORA
• regulation · HIPAA (US Health Privacy)
• useCase · Procurement Variance & Vendor KPI Monitoring

Art. 4 evidence: role-based training curricula and completion records for staff dealing with AI systems — the one obligation that applies at every risk level.

Why practice-derived: Art. 4 requires literacy measures; training records are the customary proof.

• article · Art. 4 — AI Literacy
• control · Art. 14 — Human Oversight → CO: Oversight Competence & Authority

Practice-derived artifact: the issued adverse-decision explanations together with the attribution run, model version and counterfactual scenario that each letter rested on, so an authority or a court can check that the stated reasons are the reasons the system actually used.

Why practice-derived: Art. 86 names the explanation owed to the person, not this record class; retaining the attribution behind each letter is practice.

• article · Art. 86 — Right to explanation of individual decision-making
• article · GDPR Art. 22 — Automated Decisions

The GDPR Art. 33(5) record of every personal-data breach: facts, effects, remedial action, plus the notification sent to the supervisory authority and, where required, the data subjects.

• article · GDPR Art. 33/34 — Personal-Data Breach Notification
• article · HIPAA Breach Notification Rule

Binding procedure defining supervisor roles, competence, review-queue handling, override authority and escalation thresholds θ per workflow.

• control · Art. 14 — Human Oversight → CO: Oversight Competence & Authority
• useCase · KYC & Client Onboarding Automation (Managed Service)
• useCase · Legal Contract & Regulatory Clause Extraction
• useCase · Omnichannel Virtual Support & Voice Bots
• useCase · Regulatory Change Management & Policy Updating

Art. 9 continuous risk-management record: identified risks, quantified values (FAIR-AIR/NIST Map-Measure), mitigations, residual-risk acceptance, testing incl. misuse scenarios.

• article · Art. 9 — Risk Management
• useCase · Algorithmic Portfolio Execution & Advisory
• useCase · Supplier Master Data & ESG Risk Screening

One register carrying every reportable incident with its detection time, classification and the clocks it started, so overlapping AI Act, NIS2, DORA, CRA and sectoral reports run from the same recorded facts.

Why practice-derived: The cited articles mandate reporting, not a register; a single register per system is how practitioners keep several reporting clocks answerable at once.

• article · Art. 72/73 — Post-Market Monitoring & Incidents
• article · CRA Art. 14 — Vulnerability & Severe-Incident Reporting
• article · DORA Art. 19 — Major ICT-Incident Reporting
• article · NIS2 Art. 23 — Significant-Incident Reporting
• article · SEC Form 8-K Item 1.05 — Material Cybersecurity Incident

The organizational register of AI systems in use — role (provider or deployer), classification, owner, vendor and lifecycle state — from which per-system obligations are assigned.

Why practice-derived: No cited article names an internal inventory; it is the precondition practitioners need before any per-system duty can be assigned an owner.

• article · Art. 17 — Quality Management System
• article · Art. 26 — Deployer Obligations
• control · Art. 26 — Deployer Obligations → CO: Embedded-AI Vendor Governance