Design Review (DR)

Data Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/DR-Data-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Verification

Objective: Establish a two-lane design review for data AI changes with a published checklist and service level, so review is predictable enough that teams route through it.

Description: A program at this level reviews data AI designs against a published checklist, in one of two lanes, with a stated turnaround. The fast lane clears low-risk changes against a standard checklist in days; the full lane handles novel or high-risk designs with a named architect. Publishing both the checklist and the service level is what makes the practice work: a review whose criteria and duration are unknown is a review teams plan around rather than through, and the routing-around is invisible until an incident reveals it.

---

Maturity Level 1, Foundational

Objective: Establish a two-lane design review for data AI changes with a published checklist and service level, so review is predictable enough that teams route through it.

A program at this level reviews data AI designs against a published checklist, in one of two lanes, with a stated turnaround. The fast lane clears low-risk changes against a standard checklist in days; the full lane handles novel or high-risk designs with a named architect. Publishing both the checklist and the service level is what makes the practice work: a review whose criteria and duration are unknown is a review teams plan around rather than through, and the routing-around is invisible until an incident reveals it.

Dependencies

• Required: SM-Data-L1, TA-Data-L1, SR-Data-L1, SA-Data-L1
• Alignment (not blocking): Existing architecture review boards, so AI design review joins an established forum rather than creating a second queue
• Supports / unblocks: IR-Data-L1; ST-Data-L1; EH-Data-L1; IM-Data-L1; Required by: DR-Data-L2

Desired Outcomes

• Every AI design change reaches a review decision through one of two published lanes.
• The review checklist is published, so teams know what will be asked before they arrive.
• Every decision is written, with conditions stated and tracked to closure rather than assumed.
• Turnaround is predictable enough that teams route through review rather than around it.
• A design that skipped review is detectable rather than merely discouraged.

Activities

A) Establish two review lanes with published service levels

Define a fast lane and a full lane, and publish the routing rule and the service level for each. The fast lane handles designs adopting a sanctioned reference pattern without material deviation, cleared against a standard checklist within 5 business days. The full lane handles novel architectures, pattern deviations and high-risk designs, with a named architect reviewer and a decision within 15 business days. Publishing both numbers is the practice's single most important act: a review of unknown duration is a review teams plan around, and they do so quietly. Measure and report adherence per lane, and treat a persistent breach as a capacity problem to be resourced rather than a communication problem to be explained.

B) Publish the checklist and make decisions written

Publish the review checklist so teams can self-assess before submitting. In this domain the checklist covers classification recorded before ingest, lawful basis stated, lineage capture through every transformation, retention right-sized to the longest applicable obligation, erasure propagation path to embeddings and derived artifacts, per-request authorization on retrieval, and redaction at log write. Every review produces a written decision of approve, approve with conditions, or refuse, naming the reviewer and stating the rationale. Conditions carry an owner and a date and are tracked to closure, because an approval with untracked conditions is an approval, and the conditions are the part that mattered. Record the checklist items that most often fail, and feed that back to the education and architecture practices as the clearest available evidence of where design understanding is weak.

C) Define review triggers and detect what bypassed review

Define what triggers a review rather than relying on teams to request one. In this domain the triggers are a new data class entering a corpus, a new consuming model, a cross-border flow change, or a retention or sampling change, plus any new asset entering the inventory. Wire the triggers to the signals that already exist, being inventory changes, deployment events and change records, so that a review obligation is raised by the system rather than remembered by a person. Then detect bypass: reconcile assets reaching production against review decisions, and treat a production asset with no review record as a finding with an owner. Bypass detection is what converts design review from a service teams may use into a gate whose absence is visible, and without it the practice measures only the designs it happened to see.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
AI design changes receiving a written decision within the applicable lane service level (fast lane 5 business days, full lane 15)	first quarter of review telemetry	≥90% overall, reported per lane	Design review decision log with timestamps
Production AI assets with no design review record	first bypass reconciliation	0, with every case raised as a finding with an owner	Asset inventory reconciled against the review decision log
Review decisions carrying a written rationale and named reviewer	first decision audit	100%	Design review decision log
Approval conditions carrying an owner and a date, tracked to closure	first condition review	100%, with none past due	Condition tracker joined to the review log
Review triggers fired by system signal rather than by team request	first quarter after wiring	≥80% of reviews trigger-initiated	Review intake source field

Process Metrics (leading)

• Lane service levels reported weekly, with breaches treated as a capacity signal.
• Checklist reviewed quarterly against new findings and updated architecture patterns.
• Bypass reconciliation run at least monthly against production inventory.
• Most-failed checklist items reported to the education and architecture practices each quarter.

Effectiveness Metrics (business value)

• Fast-lane share rises as reference patterns are adopted, which indicates the pattern library is working.
• Time from design submission to decision falls, which is what keeps teams routing through review.
• Findings caught at design review rather than in implementation or production rise as a share of total findings.

Level of Effort (incremental over the level below)

• Stand-up: 120 hours · Ongoing: 140 hours/quarter
• Security Architect — primary, 32 days/year
• AppSec / SecEng — regular, 16 days/year
• AI/ML Engineer — low, 8 days/year
• Program Manager / Practice Lead — low, 6 days/year

Success Criteria

• Two lanes operate with published routing rules and service levels of 5 and 15 business days, with adherence at or above 90%.
• The review checklist is published and teams self-assess against it before submitting.
• Every decision is written with a named reviewer and rationale, and every condition carries an owner, a date and closure tracking.
• Review triggers fire from inventory, deployment and change signals rather than relying on team initiative.
• Bypass reconciliation runs monthly and every unreviewed production asset is raised as a finding.

---

Maturity Level 2, Comprehensive

Objective: Calibrate data design review depth and reviewer authority to asset tier, and make review decisions traceable to the threats and requirements they turned on.

At this level review depth follows tier. A Critical-tier design gets a named architect, a full-lane review and an executive-visible decision; a Low-tier design gets a checklist pass. Decisions are traceable to the specific threats and requirements they turned on, so a reviewer's judgment is reconstructable rather than personal. Deviation approvals carry compensating controls and expiry, and reviewer load is capped, because a design gate held by an overloaded reviewer approves at the rate the queue demands rather than at the rate the risk warrants.

Dependencies

• Required: DR-Data-L1, SM-Data-L2, TA-Data-L2, SR-Data-L2, SA-Data-L2
• Alignment (not blocking): Delivery governance, so review gates sit on the real release path rather than beside it
• Supports / unblocks: IR-Data-L2; ST-Data-L2; EH-Data-L2; IM-Data-L2; Required by: DR-Data-L3

Desired Outcomes

• Depth and reviewer seniority follow the asset tier rather than reviewer availability.
• Every decision traces to the threats and requirements it turned on, so judgment is reconstructable.
• Deviation approvals carry a compensating control, a named authority and an expiry.
• Reviewer load is capped, and exceeding the cap adds capacity rather than accelerating decisions.
• Critical-tier decisions are visible to the sponsor rather than closed within the practice.

Activities

A) Derive review depth and reviewer authority from tier

Publish what each tier receives: at Critical, a full-lane review with a named architect, mandatory threat-model and requirements-evidence review, and a decision recorded where the sponsor can see it; at High, full lane where a deviation exists and fast lane otherwise; at Medium, fast lane; at Low, a checklist pass with sampling. Derive the lane from the inventory tier automatically rather than from reviewer judgment at intake, because intake routing under queue pressure drifts toward the fast lane and does so without anyone deciding to lower the bar. Publish a reviewer-load ceiling per tier, and when it is breached add reviewers rather than shortening reviews, since the alternative is a gate that approves at the rate the queue demands. In this domain the designs that genuinely need architect judgment are new corpus types and cross-border flows, while an additional consumer of an already-governed store usually does not.

B) Make decisions traceable to threats and requirements

Require every full-lane decision to cite the specific threat identifiers from the TA library and requirement identifiers from the SR pack that it assessed, and to state which ones drove each condition or refusal. This converts review from personal judgment into reconstructable reasoning, which matters for three reasons: a second reviewer can reach the same conclusion, an auditor can follow it, and the practice can tell which threats and requirements are actually doing work in review. Report the threats and requirements most frequently driving conditions, since that is direct evidence of where designs are systematically weak and belongs in the architecture and education practices rather than only in the review log. Automated design criteria read the catalogue entry, declared lawful basis, retention setting and lineage plan, which covers the conformance questions and leaves provenance judgment to a person.

C) Govern deviations and make Critical decisions visible

Operate deviation approval as a distinct decision with its own record: what pattern or requirement is not met, why, what compensating control applies, who approved it at an authority proportionate to tier, and when it expires. Review the deviation register monthly and report Critical-tier deviations to the sponsor alongside the approvals, because a review practice that reports only what it approved and not what it excused presents a misleading picture of the estate. Track deviations later implicated in incidents as a distinct measure, which is the only honest feedback on whether deviation judgment is sound rather than merely procedurally correct. Forward tracing in this domain most often implicates approvals that accepted a retention period without checking the longest applicable obligation.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Reviews routed to a lane derived from asset tier rather than reviewer judgment at intake	first tier-derivation pass	≥95% tier-derived routing	Review intake routing source field
Critical-tier designs reviewed full-lane with a named architect	first tier conformance pass	100%	Review log joined to inventory tier
Full-lane decisions citing specific threat and requirement identifiers	first traceability pass	≥90%	Review decision records
Deviation approvals carrying compensating control, tier-appropriate authority and expiry	first deviation review	100%, with none past expiry	Deviation register
Reviewer load against the published per-tier ceiling	first quarter of load telemetry	no reviewer above ceiling for two consecutive weeks	Review assignment log
Per-tier service level adherence	first quarter of tiered telemetry	≥90% per tier	Review log with timestamps by tier

Process Metrics (leading)

• Lane routing re-derived automatically whenever an asset's tier changes.
• Deviation register reviewed monthly with Critical-tier items reported to the sponsor.
• Reviewer load monitored weekly against the ceiling.
• Most frequent condition-driving threats and requirements reported quarterly to architecture and education.

Effectiveness Metrics (business value)

• Reviewer effort concentrates on Critical and High tiers relative to L1.
• Deviations later implicated in incidents fall, which is the honest measure of deviation judgment quality.
• Repeat conditions on the same theme fall as architecture and education act on the reported patterns.
• Fast-lane share rises without a rise in downstream findings, indicating routing is calibrated rather than lax.

Level of Effort (incremental over the level below)

• Stand-up: 140 hours · Ongoing: 170 hours/quarter
• Security Architect — primary, 36 days/year
• AppSec / SecEng — regular, 20 days/year
• Compliance / Audit — low, 6 days/year
• Executive Sponsor — low, 2 days/year

Success Criteria

• Review lane and reviewer seniority are derived from asset tier, with at least 95% of routing tier-derived rather than judged at intake.
• Every Critical-tier design receives a full-lane review with a named architect and a sponsor-visible decision.
• At least 90% of full-lane decisions cite the specific threat and requirement identifiers that drove each condition or refusal.
• Deviation approvals carry a compensating control, tier-appropriate authority and an expiry, with none past expiry.
• A per-tier reviewer-load ceiling is published and breaching it adds capacity rather than shortening reviews.

---

Maturity Level 3, Industry-Leading

Objective: Shift data design review left into the pipeline, reserve human review for genuine novelty, and measure whether review decisions were right rather than only timely.

At this level most design conformance is established automatically, and human review is spent on what is genuinely novel. Machine-checkable review criteria run against design artifacts in the pipeline, so a conformant design clears without consuming reviewer attention and reviewers see only the designs that need judgment. The practice measures decision quality rather than throughput, tracing approvals forward to incidents and findings, which is the only way to learn whether the gate is calibrated or merely fast.

Dependencies

• Required: DR-Data-L2, SA-Data-L3, IM-Data-L2
• Alignment (not blocking): Platform engineering, since automated design checks run in their pipeline
• Supports / unblocks: Every other Data practice at L3, which inherits designs that were verified rather than reviewed

Desired Outcomes

• Machine-checkable design criteria are evaluated automatically, so reviewers see only what needs judgment.
• Decisions are traced forward to incidents and findings, so decision quality is measurable.
• Reviewer attention is concentrated on genuine novelty rather than on conformance confirmation.
• The criteria that cannot be automated are listed explicitly, so the automation's reach is known.
• Capacity scales with the estate rather than with reviewer headcount.

Activities

A) Automate the machine-checkable criteria

Convert every review criterion that can be evaluated from an artifact into an automated check running against the design representation, whether that is infrastructure-as-code, a configuration manifest, a service definition or a system card. A design meeting all automated criteria and adopting a sanctioned pattern clears without human review at Medium and Low tier, and arrives at Critical and High review pre-verified so the reviewer spends attention on what is novel rather than on confirming what is conformant. Publish the list of criteria that cannot be automated and review it quarterly for reduction, because that list is the honest boundary of the automation. Keep a human veto and sampling at every tier, since a wholly automated gate encodes yesterday's criteria permanently and nothing in the system notices. In this domain the designs that genuinely need architect judgment are new corpus types and cross-border flows, while an additional consumer of an already-governed store usually does not. Novelty in this domain means a new corpus type or an unfamiliar provenance situation, not another consumer of a governed store.

B) Measure decision quality, not throughput

Trace review decisions forward. For every approval, record whether the asset subsequently generated an incident, an implementation-review finding or a security-test failure attributable to something the review should have caught. Report false-negative rate, being approvals later implicated, and investigate false-positive pressure, being conditions imposed that evidence later showed unnecessary, since a gate that over-conditions trains teams to argue rather than comply. Throughput and service-level adherence remain as health metrics but are explicitly not the practice's outcome measure, because a review function optimising for turnaround will achieve it by approving, and the metric will look excellent throughout. Publish decision-quality measures to the sponsor alongside throughput. Automated design criteria read the catalogue entry, declared lawful basis, retention setting and lineage plan, which covers the conformance questions and leaves provenance judgment to a person.

C) Calibrate reviewers and concentrate attention on novelty

Run blind double-review on a sample of Critical-tier designs at least quarterly and report the disagreement rate, because a gate whose outcome depends on which architect drew the review is a lottery rather than a control, and disagreement is invisible without deliberately measuring it. Use the disagreement cases to refine criteria rather than to rank reviewers. Reserve human review explicitly for novelty: designs using an unestablished pattern, a new archetype, a new model capability class or an unfamiliar threat surface, and route everything else to automated verification with sampling. Track the share of reviewer hours spent on novel designs, which should rise steadily and is the clearest measure that the automation is doing its job. Forward tracing in this domain most often implicates approvals that accepted a retention period without checking the longest applicable obligation.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Machine-checkable review criteria evaluated automatically	L2 criteria set	≥75%, with the non-automatable remainder listed explicitly	Automated design check registry
Medium- and Low-tier designs clearing without human review while meeting all automated criteria	first quarter after automation	≥70%, with sampling maintained	Review pipeline telemetry
Approvals later implicated in an incident, finding or test failure the review should have caught	first quarter of forward tracing	tracked and falling year over year, reported to the sponsor	Review decisions joined to incident, IR and ST records
Reviewer disagreement rate on blind double-reviewed Critical-tier designs	first calibration round	≤15%, with disagreements used to refine criteria	Double-review calibration records
Share of reviewer hours spent on genuinely novel designs	first quarter of attention telemetry	≥60% and rising	Review time recording by design novelty classification

Process Metrics (leading)

• Automated checks monitored for false-positive rate and tuned rather than tolerated.
• Non-automatable criteria list reviewed quarterly with a reduction target.
• Blind double-review sampling run at least quarterly on Critical-tier designs.
• Sampling maintained on automatically cleared designs so the automation itself is checked.

Effectiveness Metrics (business value)

• Reviewer hours per design fall while decision quality holds, which is the level's defining outcome.
• Review capacity scales with the estate rather than with headcount.
• Approvals later implicated in incidents fall, indicating the gate is calibrated rather than merely fast.
• Teams submit earlier as automated feedback becomes available at design time rather than at review.

Level of Effort (incremental over the level below)

• Stand-up: 200 hours · Ongoing: 110 hours/quarter
• Security Architect — primary, 26 days/year
• DevOps / Platform Engineer — regular, 20 days/year
• AppSec / SecEng — regular, 16 days/year
• Compliance / Audit — low, 4 days/year
• Material new tooling: Automated design criteria evaluation in the delivery pipeline

Success Criteria

• At least 75% of machine-checkable criteria run automatically, with the non-automatable remainder listed and shrinking.
• Medium- and Low-tier conformant designs clear without human review while sampling continues, and a human veto is retained at every tier.
• Decision quality is measured by forward tracing to incidents and findings, and reported to the sponsor alongside throughput.
• Blind double-review runs quarterly on Critical-tier designs with a disagreement rate at or below 15%, used to refine criteria rather than rank reviewers.
• At least 60% of reviewer hours are spent on genuinely novel designs, and rising.

---

Key Success Indicators

Level 1:

• Two lanes operate with published routing rules and service levels of 5 and 15 business days, with adherence at or above 90%.
• The review checklist is published and teams self-assess against it before submitting.
• Every decision is written with a named reviewer and rationale, and every condition carries an owner, a date and closure tracking.
• Review triggers fire from inventory, deployment and change signals rather than relying on team initiative.
• Bypass reconciliation runs monthly and every unreviewed production asset is raised as a finding.

Level 2:

• Review lane and reviewer seniority are derived from asset tier, with at least 95% of routing tier-derived rather than judged at intake.
• Every Critical-tier design receives a full-lane review with a named architect and a sponsor-visible decision.
• At least 90% of full-lane decisions cite the specific threat and requirement identifiers that drove each condition or refusal.
• Deviation approvals carry a compensating control, tier-appropriate authority and an expiry, with none past expiry.
• A per-tier reviewer-load ceiling is published and breaching it adds capacity rather than shortening reviews.

Level 3:

• At least 75% of machine-checkable criteria run automatically, with the non-automatable remainder listed and shrinking.
• Medium- and Low-tier conformant designs clear without human review while sampling continues, and a human veto is retained at every tier.
• Decision quality is measured by forward tracing to incidents and findings, and reported to the sponsor alongside throughput.
• Blind double-review runs quarterly on Critical-tier designs with a disagreement rate at or below 15%, used to refine criteria rather than rank reviewers.
• At least 60% of reviewer hours are spent on genuinely novel designs, and rising.

---

Common Pitfalls

Level 1:

• ❌ Running review without a published service level, which teams respond to by planning around review rather than through it, invisibly.
• ❌ Approving with conditions that are never tracked, which converts a conditional approval into an unconditional one.
• ❌ Relying on teams to request review, which means the practice only ever sees the designs of teams already inclined to ask.
• ❌ Never reconciling production against review records, so the practice measures the designs it saw and not the ones it missed.
• ❌ Treating persistent service-level breaches as a communication problem rather than as evidence that review capacity is short.

Level 2:

• ❌ Routing at intake by reviewer judgment, which under queue pressure drifts toward the fast lane without anyone deciding to lower the bar.
• ❌ Recording decisions without citing what drove them, which makes review personal judgment and leaves a second reviewer unable to reproduce it.
• ❌ Reporting approvals to the sponsor without reporting deviations, which presents a systematically flattering picture of the estate.
• ❌ Responding to reviewer overload by shortening reviews rather than adding reviewers, producing a gate that approves at queue rate.
• ❌ Never tracking whether deviations were later implicated in incidents, which leaves deviation judgment unevaluated.

Level 3:

• ❌ Optimising the practice for turnaround, which a review function achieves by approving while the metric looks excellent throughout.
• ❌ Removing the human veto and sampling once automation is in place, which encodes yesterday's criteria permanently with nothing to notice.
• ❌ Never measuring reviewer disagreement, leaving a gate whose outcome depends on which architect drew the review.
• ❌ Using double-review disagreement to rank reviewers, which produces defensive convergence rather than better criteria.
• ❌ Leaving the non-automatable criteria list unpublished, so the boundary of the automation is unknown and assumed wider than it is.

---

Practice Maturity Questions

Level 1:

1. Do two published review lanes operate with stated routing rules and service levels of 5 and 15 business days, with adherence measured and reported per lane and persistent breaches treated as a capacity problem? Evidence this in the Data domain against a full-lane decision on a cross-border corpus flow.
2. Is the review checklist published so teams self-assess before submitting, covering classification recorded before ingest, lawful basis stated, lineage capture through every transformation, retention righ, and does every review produce a written decision with named reviewer, rationale and tracked conditions?
3. Do review triggers fire from inventory, deployment and change signals rather than team initiative, and does monthly bypass reconciliation raise every unreviewed production asset as a finding with an owner? In Data, ask to see a full-lane decision on a cross-border corpus flow.

Level 2:

1. Is review lane and reviewer seniority derived automatically from asset tier rather than judged at intake under queue pressure, with at least 95% tier-derived routing and a published per-tier reviewer-load ceiling? Evidence this in the Data domain against a full-lane decision on a cross-border corpus flow.
2. Do at least 90% of full-lane decisions cite the specific TA threat identifiers and SR requirement identifiers that drove each condition or refusal, making the reasoning reconstructable by a second reviewer and an auditor? For Data, the assessor should be shown a full-lane decision on a cross-border corpus flow.
3. Do deviation approvals carry a compensating control, tier-appropriate approval authority and an expiry with none past expiry, and are Critical-tier deviations reported to the sponsor alongside approvals? In Data, ask to see a full-lane decision on a cross-border corpus flow.

Level 3:

1. Are at least 75% of machine-checkable review criteria evaluated automatically with the non-automatable remainder listed explicitly, and do conformant Medium- and Low-tier designs clear without human review while sampling and a human veto are retained? Evidence this in the Data domain against a full-lane decision on a cross-border corpus flow.
2. Is decision quality measured by tracing approvals forward to incidents, implementation findings and test failures, reported to the sponsor alongside throughput and explicitly rather than throughput as the outcome measure? For Data, the assessor should be shown a full-lane decision on a cross-border corpus flow.
3. Does blind double-review run at least quarterly on Critical-tier designs with disagreement at or below 15% used to refine criteria rather than rank reviewers, and is at least 60% of reviewer time spent on genuinely novel designs? In Data, ask to see a full-lane decision on a cross-border corpus flow.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Is there a security review before an AI design gets built?
• Do teams know how long a design review will take?
• Would you notice an AI asset that reached production without review?

Level 2:

• Does a high-risk AI design get a more senior reviewer than a low-risk one?
• Could someone reconstruct why a design was approved with conditions?
• Is there a cap on how many designs one reviewer handles?

Level 3:

• Does a conformant AI design clear review without a human reading it?
• Do you know whether designs you approved later caused incidents?
• Would two of your architects reach the same decision on the same design?

---

Tracking

Level 1 — Jira Epic, labels haiamm-dr-data-l1, haiamm-verification

• Done when: Design review service level adherence at or above 90% per lane with zero production AI assets lacking a review record and no overdue approval conditions, sustained two consecutive quarters.
• Git artifacts: architecture/review-log.json, architecture/review-checklist.md, architecture/review-reconciliation.json
• Git signal: review-reconciliation.json is regenerated by the monthly bypass job against the production inventory rather than compiled by hand.
• CI check: design-review-bypass-check

Level 2 — Jira Epic, labels haiamm-dr-data-l2, haiamm-verification

• Done when: Every Critical-tier design reviewed full-lane with a named architect and decision traceability at or above 90%, with zero expired deviations, sustained two consecutive quarters.
• Git artifacts: architecture/review-decisions/, architecture/deviation-register.json, architecture/reviewer-load.json
• Git signal: Review decision records cite TA and SR identifiers as structured fields rather than prose, and deviation-register.json is checked by CI for entries past expiry.
• CI check: review-traceability-check

Level 3 — Jira Epic, labels haiamm-dr-data-l3, haiamm-verification

• Done when: Automated design criteria coverage at or above 75% with Critical-tier double-review disagreement at or below 15% and reviewer novelty share at or above 60%, sustained two quarters.
• Git artifacts: architecture/design-checks/, architecture/calibration-records.json, architecture/decision-quality.json
• Git signal: decision-quality.json is regenerated by joining the review log to incident and finding records rather than maintained by hand, and design checks emit results per pipeline run.
• CI check: design-check-automation

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	RA	AML.T0018, AML.T0020, AML.T0024, AML.T0115	LLM02, LLM04	EU AI Act Art. 9; EU AI Act Art. 15; NIST AI RMF MAP 2.3; ISO/IEC 42001 8.1; ISO/IEC 27001 A.8.27
L2	RA	AML.T0018, AML.T0020, AML.T0024, AML.T0115	LLM02, LLM04	EU AI Act Art. 9; EU AI Act Art. 15; EU AI Act Art. 26; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1
L3	RA	AML.T0018, AML.T0020, AML.T0024, AML.T0115	LLM02, LLM04	EU AI Act Art. 9; EU AI Act Art. 17; NIST AI RMF MANAGE 1.3; ISO/IEC 42001 8.1; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Design Review (DR) / Domain: Data