{"description":"EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the \"impact-analysis item\" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.","edges":[{"id":"e-lock-executable-workplan-map-ai-use-cases","source":"lock-executable-workplan","target":"map-ai-use-cases"},{"id":"e-map-ai-use-cases-rate-conformity-exposure","source":"map-ai-use-cases","target":"rate-conformity-exposure"},{"id":"e-rate-conformity-exposure-hand-high-risk-gaps-to-aims","source":"rate-conformity-exposure","target":"hand-high-risk-gaps-to-aims"},{"id":"e-hand-high-risk-gaps-to-aims-classify-disposition","source":"hand-high-risk-gaps-to-aims","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-03","UC-AUDIT-24","UC-AI-13","UC-RISK-11"],"department":"ai-governance","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-eu-ai-act-impact-analysis","contentDigest":"sha256:ebe3ad0a90ce6e3b0b4f990739127367ed0dc83b3beaa4ee49d421d7b8f9c3db","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:ebe3ad0a90ce6e3b0b4f990739127367ed0dc83b3beaa4ee49d421d7b8f9c3db","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-eu-ai-act-impact-analysis"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"reg-eu-ai-act-impact-analysis","source":"coworkcanvas-gallery","standards":["eu-ai-act","iso-42001"],"teams":["ai-governance","compliance-legal"]},"name":"EU AI Act Obligation Impact Analysis","nodes":[{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Freeze scope, owners, dates, evidence expectations, and escalation thresholds so the mapping and crosswalk phase executes against a fixed plan and any later scope change is visible as a logged amendment.\n\n**Inputs**\n- The horizon-scanning handoff package from Regulatory Horizon Scanning & Triage (regulatory text extracts with citations, triage severity, applicability dates) — uploaded (PBC/external) as a document on this step; applicability deadlines for the in-scope provisions travel inside it.\n- The full in-scope AI inventory, including any procured or citizen-developer systems swept in at intake — an inventory spreadsheet uploaded on this step (there is no native AI System item type).\n- The in-scope boundary (entities, AI systems, markets) fixed at intake — carried on the anchor compliance Audit item in `Audit.scope` and `Audit.description`; per-system role hypotheses and analyst availability are captured in the workplan document.\n- The prior obligation register (previous run's state, for reconciliation and its ID convention) — the prior register XLSX uploaded on this step (there is no native Obligation item type).\n\n**Procedure**\n1. Enumerate the work items — provisions to parse times systems to classify — and put a named analyst and business-owner contact on each.\n2. Sequence by applicability date and severity: Art 5 exposure first (applicable since 2 Feb 2025 and at the EUR 35M / 7% penalty tier), then provisions with the nearest compliance dates, then long-lead items — conformity assessment for Annex III systems needs the longest runway (quality management system under Art 17, Annex IV technical documentation, possibly a notified body under Annex VII).\n3. Set the evidence expectation per work item: which artifact proves the conclusion — classification memo, Art 6(3) filter assessment, crosswalk table with citations, gap rating with rationale.\n4. Set review gates: legal reviews all prohibited-practice calls and contested Art 6(3) filter claims; a second analyst peer-reviews ratings; state the review SLA.\n5. Pre-commit escalation thresholds now, before results exist: any plausible Art 5 practice escalates to legal the same day it is identified, without waiting for the disposition step; any system needing a notified body triggers an immediate lead-time alert to the obligation owner.\n6. Publish the plan with dates, owners, and deliverables. After lock, changes are plan amendments with reasons — not quiet edits.\n\n**Record in AssureSwarm**\n- Anchor this run to the compliance Audit item (the \"impact-analysis item\"): set `Audit.audit_type: compliance`, record the in-scope boundary in `Audit.scope`, the entity/market context in `Audit.description`, and the analysis window in `Audit.period_start`/`Audit.period_end`.\n- Attach the workplan (DOCX/PDF) as a document on this step — scope counts (provisions, systems), milestone dates, owner assignments, and escalation thresholds live in that document, as no native Audit field holds them.\n- Attach the horizon-scanning handoff package, the AI-system inventory spreadsheet, and the prior obligation register (XLSX) as documents on this step (no native AI System or Obligation type).\n\n**Exit criteria** — Plan published with dated milestones and named owners for 100% of work items; review gates and escalation thresholds recorded; baseline frozen for amendment tracking.","label":"Lock executable workplan"},"id":"lock-executable-workplan"},{"data":{"description":"Determine, for every in-scope AI use case, the organization's operator role and the system's AI Act risk tier, so obligations attach to the systems they actually bind.","instructions":"**Objective**\nDetermine, for every in-scope AI use case, the organization's operator role and the system's AI Act risk tier, so obligations attach to the systems they actually bind.\n\n**Inputs**\nThe horizon-scanning handoff package (consolidated text extracts with citations) — the document attached at the lock step, carried forward.\n- The locked workplan (document on the lock step) and the obligation register's ID convention (from the prior register XLSX).\n- Commission guidance in force for the in-scope provisions (prohibited-practices and AI-system-definition guidelines; Art 6(5) classification guidance when issued; GPAI guidance and codes of practice where relevant) — external public sources; retained copies of the versions relied on are uploaded as documents on this step.\n\nThe AI use-case inventory (existing plus expansion discoveries) with owner and function data — the inventory spreadsheet uploaded at the lock step (no native AI System item type).\n- The obligation rows from the ingest step (in the obligation register workbook); vendor contracts, intended-purpose statements, and system documentation — uploaded as documents on this step.\n- Commission guidance: AI-system-definition guidelines, prohibited-practices guidelines, Art 6(5) classification guidance when issued (external public sources).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Ingest AI Act provision”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Ingest AI Act provision: Decompose the in-scope AI Act text into atomic, testable obligation statements — one actor, one required behavior, one condition each — so mapping and crosswalking operate on discrete units instead of article-length prose.\n\n2. Parse each article and annex into atomic obligations. Art 26 alone yields distinct obligations for: use per the provider's instructions (26(1)); assign human oversight to competent, trained persons (26(2)); ensure input-data relevance and representativeness to the extent the deployer controls it (26(4)); monitor operation and inform the provider or distributor and the authority of Art 79(1)-level risks (26(5)); retain automatically generated logs at least six months (26(6)); inform workers' representatives and affected workers before workplace deployment (26(7)); inform natural persons subject to Annex III-assisted decisions (26(11)). One obligation item per behavior — bundled obligations produce untestable crosswalks.\n3. Tag every obligation with: actor role (provider, deployer, importer, distributor, GPAI provider); risk-tier precondition (prohibited, high-risk, transparency, GPAI, or all systems); trigger event (placing on market, putting into service, substantial modification, serious incident); applicability date from the phased timeline; and penalty tier (Art 99: EUR 35M or 7% of worldwide turnover for Art 5 breaches; EUR 15M or 3% for most operator obligations; EUR 7.5M or 1% for incorrect information to authorities).\n4. Flag interpretation-sensitive obligations: terms pending guidance or harmonised standards (\"substantial modification\", \"reasonably foreseeable misuse\", systemic-risk designations). These carry stated assumptions and wider uncertainty into the rating step.\n5. Cross-reference adjacent regimes so the register does not double-count: GDPR Art 22 automated decision-making, DPIA overlap (Art 27(4) lets the FRIA build on it), sectoral law (medical devices, financial-services outsourcing rules). Note where an existing regime's artifact partially satisfies the AI Act obligation — that reuse feeds the crosswalk.\n6. Assign obligation IDs per the register convention and write a one-paragraph plain-language summary per obligation. Lawyers and engineers must read the summary identically; the crosswalk works from it.\n\n7. Assessment scope for Map AI use cases: Determine, for every in-scope AI use case, the organization's operator role and the system's AI Act risk tier, so obligations attach to the systems they actually bind.\n\n8. Apply the Art 3(1) definition test: machine-based, operates with autonomy, may adapt, and infers from inputs how to generate outputs (predictions, content, recommendations, decisions). Deterministic rule-based tools exit here with the reason recorded.\n9. Assign the role per system: provider (developed or had developed, placed on market or put into service under own name), deployer (uses under own authority), importer, distributor. Apply Art 25 re-qualification: your name or trademark on the system, a substantial modification, or a change of intended purpose into high-risk territory makes you the provider — check fine-tuned vendor models and white-labelled products specifically.\n10. Screen against Art 5 prohibitions before anything else (in force since 2 Feb 2025): manipulative or subliminal techniques causing significant harm; exploitation of vulnerabilities; social scoring; predictive policing on profiling alone; untargeted facial-image scraping; emotion recognition in workplace or education (except medical/safety); biometric categorisation inferring sensitive attributes; real-time remote biometric identification in public spaces for law enforcement. Any plausible hit escalates to legal the same day, per the workplan threshold.\n11. Classify tier: (a) Annex I — safety component of a product under listed Union harmonisation legislation with third-party conformity assessment; (b) Annex III — the eight areas: biometrics, critical infrastructure, education, employment and worker management, access to essential services (including creditworthiness and life/health insurance pricing), law enforcement, migration and border, justice and democratic processes. HR screening tools and credit models are the most common corporate hits.\n12. For Annex III candidates, test the Art 6(3) filter: not high-risk if the system only performs a narrow procedural task, improves the result of a completed human activity, detects decision patterns without replacing human assessment, or does preparatory work — never if it profiles natural persons. Document the filter analysis in a memo even as deployer; a provider claiming the filter must document it before market placement and register the system under Art 49(2).\n13. Check Art 50 transparency triggers independently of tier: direct human interaction (disclosure), synthetic-content generation (machine-readable marking), emotion recognition or biometric categorisation (notification), deepfakes (disclosure). Tag GPAI exposure where the org provides general-purpose models, including the 10^25-FLOP systemic-risk presumption (Art 51).\n14. Rate classification confidence (high, medium, low) and route low-confidence or contested calls to the legal review gate.\n\n**Record in AssureSwarm**\nRecord one row per atomic obligation in the obligation register workbook (XLSX) — ID, citation, actor role, tier precondition, trigger event, applicability date, penalty tier, interpretation flag, plain-language summary. There is no native Obligation item type; the register workbook is the durable store, attached as a document on this step and carried run-to-run, and linked from the anchor Audit item.\n- Attach the parsing worksheet showing the article-to-obligation decomposition as a document on this step.\n\nRecord each use case's classification — definition-test result, operator role, tier (prohibited-suspect, high-risk Annex I, high-risk Annex III, transparency, minimal), Art 6(3) filter conclusion, transparency and GPAI flags, confidence, classifier and date — as rows in the AI use-case classification table (XLSX), with each Art 6(3) analysis as a memo (DOCX). Attach both as documents on this step and to the anchor Audit item; there is no native AI System item type, so the classification table is the store of record.\n- In the obligation register workbook, tie each obligation row to the use cases it binds given role plus tier, so the crosswalk works from discrete obligation-system pairs.\n\n**Exit criteria**\nEvery in-scope article decomposed; no obligation item spans multiple actors or behaviors; each carries a citation and applicability date; interpretation-sensitive items flagged; IDs unique against the register. 100% of in-scope use cases carry role, tier, and confidence; every Annex III call has a documented Art 6(3) analysis; Art 5 suspects escalated same-day with the escalation recorded; use-case-to-obligation links complete.","label":"Map AI use cases"},"id":"map-ai-use-cases"},{"data":{"description":"Convert crosswalk results into a defensible gap rating per obligation-system pair, sized by severity, deadline proximity, and penalty exposure, so remediation can be sequenced rationally and criticals surface immediately.","instructions":"**Objective**\nConvert crosswalk results into a defensible gap rating per obligation-system pair, sized by severity, deadline proximity, and penalty exposure, so remediation can be sequenced rationally and criticals surface immediately.\n\n**Inputs**\nThe obligation rows with their system links (obligation register workbook); the unified control library — Control items (`Control.framework` containing `eu-ai-act`/`iso-42001`, plus SDLC/logging/incident domains).\n- ISO/IEC 42001 AIMS documentation where adopted (documents referenced from those Control items); GDPR artifacts — the corresponding Control items (`framework: gdpr`, `domains: data_protection_privacy`) plus the DPIA documents uploaded on this step; SDLC, model-risk, logging, incident, and vendor-management Control items.\n- Framework Adoption & Cross-Mapping outputs if that module has produced an AI Act to ISO 42001 (or NIST AI RMF) mapping — uploaded as a document on this step.\n\nCrosswalk pairings with mapping strengths and evidence citations (crosswalk worksheet).\n- Classification records with confidence ratings (classification table); applicability dates per obligation and penalty tiers (obligation register workbook).\n- System reach data: user counts and whether outputs affect natural persons' rights (classification table / inventory).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Crosswalk AI controls”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Crosswalk AI controls: Map each binding obligation to the existing controls, policies, and artifacts that fully or partly satisfy it, so gap ratings measure real distance rather than assumed absence.\n\n2. For each obligation, identify candidate controls by subject: Art 9 risk management maps to ISO 42001 clause 6 planning and the A.5 impact-assessment controls; Art 10 data governance to data-quality and provenance controls (A.7); Art 12 and Art 26(6) logging to log-retention controls (verify the six-month deployer minimum specifically); Art 14 human oversight to human-in-the-loop and second-review controls; Art 15 accuracy, robustness, and cybersecurity to ML validation plus application-security controls; Art 26(7) to HR consultation processes; Art 50 to UX disclosure and content-marking standards; Arts 72-73 to post-market monitoring and incident management — test that incident clocks can meet 15 days (2 days for widespread infringement or serious critical-infrastructure disruption, 10 days for death).\n3. Rate mapping strength per obligation-control pair: **covers** (stated scope, frequency, and evidence fully satisfy the obligation as written), **partial** (control exists but its scope excludes AI systems, its frequency is too low, or its evidence would not survive an authority information request under Art 74), **none**. Classic false positive: a DPIA control mapped to the Art 27 fundamental-rights impact assessment — Art 27(4) lets the FRIA build on the DPIA, but the FRIA-specific elements (affected-person categories, oversight measures, complaint arrangements) make it partial at best.\n4. Verify with operating evidence, not design intent: every **covers** cites the control's most recent execution evidence. A designed-but-unoperated control rates partial.\n5. Reuse the module's mapping where it exists: reconcile rather than re-derive, and note deltas where your control instantiation differs from the framework's assumption.\n6. Capture reuse opportunities for the action plan: one control satisfying many obligations (a maintained model inventory feeds Art 49 registration, Annex IV documentation, and Art 72 monitoring), and obligations closable by extending an existing control instead of building new.\n7. Record **none** explicitly — an obligation with no candidate control is a crosswalk result, not a blank.\n\n8. Assessment scope for Rate conformity exposure: Convert crosswalk results into a defensible gap rating per obligation-system pair, sized by severity, deadline proximity, and penalty exposure, so remediation can be sequenced rationally and criticals surface immediately.\n\n9. Rate each obligation-system pair: **conforming** (covers plus operating evidence); **minor gap** (partial mapping closable within the compliance window by extending an existing control); **major gap** (no control, or a build of significance — a quality management system under Art 17, Annex IV technical documentation, a conformity assessment); **critical** (plausible Art 5 exposure; a high-risk system that would sit on the market non-conforming past its applicability date; or an already-in-force duty currently unmet).\n10. Weight by time-to-deadline: exposure is gap size times proximity. A major gap against 2 Aug 2026 (Annex III) outranks the same gap against 2 Aug 2027 (Annex I). Use realistic lead times: notified-body conformity assessment (Annex VII — required for Annex III biometrics where harmonised standards are not fully applied) takes quarters, and the immature harmonised-standards catalogue weakens the presumption-of-conformity shortcut.\n11. Weight by consequence: the Art 99 tier (7%, 3%, or 1% of worldwide turnover), market-surveillance powers under Art 74 including withdrawal and recall, and contractual exposure (customers demanding AI Act warranties or evidence).\n12. Rate interpretation-sensitive obligations with the assumption stated and an uncertainty band — do not average the uncertainty away into a middle rating.\n13. Aggregate to system level as the worst unresolved obligation, never the mean. Produce the ranked exposure list; criticals are pre-flagged to the escalation path committed at workplan lock.\n14. Peer-review: a second analyst reviews all critical and major ratings plus roughly 20% of minors; disagreements resolve to the more severe rating unless evidence supports the lower one.\n\n**Record in AssureSwarm**\nRecord each obligation-control pairing — mapping strength (covers / partial / none) and its evidence citation — as rows in the crosswalk worksheet (XLSX), attached as a document on this step. Per-pair strength cannot live on an item relationship because the obligation endpoint is not an item (no Obligation type).\n- Link the Control items that satisfy or partly satisfy an obligation to the anchor Audit item, marking which controls are in-crosswalk; capture reuse opportunities in the crosswalk worksheet for the action-plan step.\n\nRecord the gap rating, rationale, and uncertainty note per obligation-system pair as rows in the ranked conformity-exposure list (XLSX); attach it and the peer-review record (reviewer, date, changes made) as documents on this step.\n- Materialize each major or critical gap as an Issue item — `issue_type: deficiency`, `source: compliance_review`, `severity` mapped from the gap rating, `identified_date` set, `description` citing the obligation and system — and link `Issue ↔ Audit` (the anchor) and `Issue ↔ Control` (the deficient or partially-covering control).\n- Refresh the ratings dashboard over those Issue items (by `severity`, `target_remediation_date`, and business unit).\n\n**Exit criteria**\nEvery binding obligation rated covers, partial, or none; every covers cites operating evidence; near-miss mappings (DPIA-vs-FRIA and similar) explicitly rated; module mapping reconciled where present. 100% of pairs rated with rationale; criticals identified and routed per the pre-committed thresholds; peer review complete with resolutions documented; ranked list published and dashboard current.","label":"Rate conformity exposure"},"id":"rate-conformity-exposure"},{"data":{"description":"Complete Hand high-risk gaps to AIMS","instructions":"**Objective** — Package every major or critical gap on a high-risk system into the AIMS (ISO/IEC 42001 AI management system) risk-treatment channel, with recorded acceptance, so conformity build-out is owned and tracked in the management system rather than inside this analysis.\n\n**Inputs**\n- The ranked exposure list (document from the rate step); the gap Issue items (`issue_type: deficiency`) for systems classified high-risk (Annex I or Annex III).\n- The AIMS risk register — Risk items with `category: ai_governance` (owner in `Risk.risk_owner`) — and its treatment-plan structure and named AIMS owner.\n- Crosswalk reuse notes (existing Control items the treatment should extend rather than duplicate) from the crosswalk worksheet.\n\n**Procedure**\n1. Extract the handoff set: all major and critical gaps on high-risk systems, plus Art 5 suspects — the latter routed to legal simultaneously, with the AIMS treating them as stop-use candidates pending the legal call.\n2. Build one handoff package per system: the classification memo (including the Art 6(3) analysis where used), binding obligations with citations, gap ratings with rationale, per-obligation deadlines from the phased timeline, reuse opportunities, and the named business owner.\n3. Translate each gap into AIMS treatment language mapped to ISO 42001 machinery: a missing system impact assessment maps to A.5; Art 9 and Art 15 engineering gaps to lifecycle controls (A.6); Art 10 to data controls (A.7); Arts 13 and 50 to transparency and interested-party information (A.8); procured-system gaps where the provider must supply artifacts (Annex IV documentation, Art 13 instructions for use) to supplier controls (A.10).\n4. Agree acceptance item by item with the AIMS owner: accepted into the treatment plan, or declined or deferred with a reason. An unacknowledged handoff is not a handoff — chase each item to an explicit status.\n5. Keep ownership clean: the obligation register retains the compliance-status view and receives the AIMS report-back on an agreed cadence; the AIMS owns treatment execution. FRIA-type assessments (Art 27) route to the AI Governance & Risk/Impact Assessment module, not into this handoff.\n\n**Record in AssureSwarm**\n- Attach the per-system handoff packages (one document per high-risk system) on this step.\n- For each accepted gap, link the gap `Issue ↔ Risk` — the AIMS risk item (`Risk.category: ai_governance`, `treatment: mitigate`, owner in `Risk.risk_owner`) that took the treatment.\n- Record acceptance status, date, and accepting owner per item on this step (no native acceptance field); declined items return to the action-plan pool with the reason noted in the exposure list.\n\n**Exit criteria** — Every major or critical high-risk gap is either accepted into AIMS treatment with a linked item or explicitly declined and rerouted; Art 5 suspects double-routed to legal; report-back cadence agreed and recorded.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-attach` — attaches the AIMS risk-treatment workflow to each high-risk system item with the handoff package pre-linked, so per-item acceptance is tracked in AssureSwarm.","label":"Hand high-risk gaps to AIMS","performedBy":{"primitives":["coach-workflow-attach"]}},"id":"hand-high-risk-gaps-to-aims"},{"data":{"decisionField":"disposition_path","description":"Finalize and reconcile the obligation register, then classify the result of EU AI Act Obligation Impact Analysis so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Bring the obligation register to its final state — every parsed obligation showing applicability, mapping, gap, treatment route, owner, and deadline — and on that record classify the analysis outcome so closure takes exactly one path: no reportable gap, owned remediation, or escalation of a significant issue. The compliance officer owns the call, with legal concurrence where Art 5 or imminent non-conformity is in play.\n\n**Inputs**\n- Obligation rows with ratings (register workbook + ranked exposure list); classification records (classification table); AIMS acceptance statuses (recorded on the hand step / the `Issue ↔ Risk` links).\n- The register schema and ID convention; the prior register XLSX for reconciliation.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Update obligation register\" step); the human moment is the classification in item 6._\n1. Write one register row per obligation-system pair: obligation ID and citation; applicability (applies, or not-applicable with ground); role; risk tier; control mapping (covers, partial, or none, with control links); gap rating; treatment route (AIMS item link, action plan, or accepted-as-is); accountable owner; compliance deadline; evidence links; attestation status.\n2. Reconcile against the prior state: obligations superseded by text changes close with a reason — never delete; changed ratings show old to new with the driver named.\n3. Verify referential integrity: every row links to a live obligation item, a system item, and (where mapped) control items; no orphan rows; no obligation item without a row.\n4. Run coverage checks in both directions: every article in the horizon-scanning package traces to at least one row or a documented exclusion; every high-risk system traces to the full role-appropriate high-risk obligation set (Arts 8-27) — a high-risk system with three register rows is a parsing hole, not a clean system.\n5. Refresh the register dashboard — obligations by status, gaps by severity and deadline, systems by tier, treatment acceptance rate — and put the nearest-deadline criticals on a watchlist so slippage surfaces without anyone re-running queries.\n6. Classify the disposition against the criteria below, stating gap counts by severity and the nearest statutory date.\n\n**Decision criteria**\nBefore branching, verify the record supports any call at all: the item-4 coverage checks passed in both directions; all criticals peer-reviewed; AIMS acceptances recorded.\n- **No reportable gap (`clean`)** — every obligation-system pair rates conforming or carries an evidenced, concurred not-applicable ground; no Art 5 suspect is open; duties already in force (the 2 Feb 2025 and 2 Aug 2025 tranches) are all evidenced as operating. Rare on a first run — claim it from the coverage checks, not optimism.\n- **Remediation required (`remediate`)** — one or more minor or major gaps exist and are closable inside their compliance windows through owned actions (control extensions, AIMS treatments, vendor artifact procurement). State counts by severity and the nearest statutory date in the rationale.\n- **Escalate significant issue (`escalate`)** — any item needs a decision above the obligation owners' authority: a plausible Art 5 practice (stop-use call); a high-risk system that will pass its applicability date non-conforming (market-withdrawal and contract exposure); role re-qualification under Art 25 creating provider-grade duties the org cannot meet in time; or aggregate exposure at the 3% or 7% penalty tiers warranting executive risk acceptance. Escalation and remediation can coexist — when any single item requires higher authority, pick `escalate`; the escalation step also carries the risk-acceptance option, and routine actions still land in the final package.\n\n**Record in AssureSwarm**\n- Update the obligation register workbook (XLSX) — one row per obligation-system pair with the fields above — and attach the new version as a document on this step. There is no native Obligation or register item type; this workbook is the durable product, carried run-to-run and linked from the anchor Audit item.\n- Ensure every open-gap row is mirrored by its Issue item (`issue_type: deficiency`) linked to the anchor Audit and the relevant Control, and every AIMS-accepted row by its `Issue ↔ Risk` link.\n- Attach the reconciliation note (rows added, changed, closed, with drivers) on this step; refresh the register dashboard and update the watchlist entries.\n- Submit `disposition_path`; the step result states gap counts by severity and deadline and names each escalation item; the step's approver record records the decider.\n\n**Exit criteria** — Both coverage checks pass; referential integrity verified; all rows carry owner and deadline; reconciliation note attached; dashboard and watchlist current; form submitted with rationale counts reconciling to the register dashboard; escalation items (if any) individually named; unused branches prunable.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Turn every open gap into an owned, dated, verifiable action so Regulatory Obligation Implementation can execute without re-analysis.\n\n**Inputs**\n- The open-gap Issue items and their register rows with ratings; the `Issue ↔ Risk` AIMS treatment links (to avoid double-planning).\n- Crosswalk reuse notes (crosswalk worksheet); the owner roster; applicability deadlines per obligation (register workbook).\n\n**Procedure**\n1. Write each action in closure terms — the artifact or control state that closes the gap: \"log retention extended to six months for system X with quarterly evidence pulls\" (Art 26(6)); \"Annex IV technical documentation obtained from the vendor, or the exit clause triggered\" (procured high-risk system). Where the gap is systemic (e.g., no AI intake gate in procurement), target the root cause, not just the instance.\n2. Assign one accountable owner per action — a name, not a team — and a due date back-planned from the obligation's applicability date with verification buffer. Deadline-critical actions get interim milestones.\n3. Define interim mitigation for gaps that are live now: restricted use, enhanced human review, added disclosures. Record the mitigation and its owner — authorities weigh operating mitigations when assessing infringements.\n4. Define validation evidence per action: what artifact proves closure and who verifies it (someone other than the implementer).\n5. Set the reporting cadence and the slippage trigger: e.g., monthly status into the register; slippage threatening a statutory date auto-escalates to the disposition owner.\n6. De-conflict with AIMS: actions already accepted into AIMS treatment are tracked here as external dependencies with the agreed report-back cadence — never duplicated as parallel actions.\n\n**Record in AssureSwarm**\n- On each open-gap Issue, set `remediation_plan` (the closure action, interim mitigation, and validation evidence), `issue_owner`, `target_remediation_date` (back-planned from the obligation's applicability date), and `management_response`; actions already accepted into AIMS stay tracked via the `Issue ↔ Risk` link as external dependencies, not duplicated.\n- Attach the action-plan summary as a document on this step; move the affected Issue items to an in-remediation status and mirror it into the register workbook row.\n\n**Exit criteria** — Every open gap has at least one linked action with a named owner and defined validation evidence; due dates sit inside the compliance window, or the item carries an interim mitigation plus an explicit escalation flag for the approver; AIMS de-confliction complete.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to compliance officer, legal owner, obligation owner, or governance delegate or document risk acceptance","instructions":"**Objective** — Put each escalation item in front of the right authority with a decision-ready memo, and land every item on a recorded outcome: a directed intervention, a bounded risk acceptance, or a scoped remand for further analysis.\n\n**Inputs**\n- The escalation items named in the disposition rationale, with gap ratings and deadlines.\n- Exposure quantification: the Art 99 penalty tier against worldwide turnover, market-surveillance powers (Art 74) including withdrawal and recall, contractual warranty exposure.\n- Interim mitigations in force; the escalation path fixed at workplan lock (compliance officer, legal owner, obligation owner, governance delegate).\n\n**Procedure**\n1. Draft one decision memo per item: the issue in a paragraph; the legal anchor (article and applicability date); quantified exposure; options with cost and timeline (remediate by date, restrict or suspend use, exit the vendor, accept the risk); and a recommendation.\n2. Route by authority: Art 5 stop-use questions and imminent statutory non-conformity to legal plus executive governance; deadline-slippage items to the obligation owner's chain; resource conflicts to the governance delegate. Present, answer questions, and record the directed outcome per item.\n3. For risk acceptances, document: scope (which system and obligation), duration (never open-ended — tied to a re-review date or the next applicability milestone), mandatory conditions while accepted, the named accepting executive with authority for the exposure tier, and the triggers that void the acceptance (incident, authority contact, guidance change).\n4. Convert directed interventions into action items with owners and dates, feeding the action plan; convert acceptances into register status \"risk accepted\" with the memo linked.\n5. Close the loop on every item: each ends as intervene (action created), accept (memo signed), or remand (scoped question, named analyst, return date). Nothing stays undecided.\n\n**Record in AssureSwarm**\n- Attach the decision memos (one per item) on this step; record the per-item outcome (intervene, accept, or remand) with decider and date on the step (no native outcome field).\n- For risk acceptances, set `Risk.treatment: accept` and `Risk.residual_rating` on the linked `ai_governance` Risk item; the bounded scope, duration, mandatory conditions, void triggers, and re-review date live in the acceptance memo.\n- For interventions, create or update the gap Issue items (`remediation_plan`, `issue_owner`, `target_remediation_date`) feeding the action plan; mirror status into the register workbook row and put acceptance re-review dates on the watchlist.\n\n**Exit criteria** — Every escalation item carries a recorded outcome from the named authority; acceptances are bounded (scope, duration, conditions, void triggers); interventions exist as owned actions; remands carry an analyst and a return date.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Capture the accountable approval of the analysis package — by the compliance officer, legal owner, obligation owner, or governance delegate — or return it with explicit, testable conditions.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nCapture the accountable approval of the analysis package — by the compliance officer, legal owner, obligation owner, or governance delegate — or return it with explicit, testable conditions.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nEverything linked so far: the impact-analysis item, obligation register extract, classification memos, crosswalk worksheet, ranked exposure list and peer-review record, AIMS handoffs and acceptances, action plan, escalation and risk-acceptance memos, and the decision-node rationales.\n\n*Agent retrieval, preparation and filing absorb “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare final package: Assemble the complete, reviewable record of the analysis — scope, method, classifications, crosswalk, ratings, treatments, and open constraints — so the approver decides on evidence rather than assertion.\n\n2. Compile in decision order: (a) executive summary — trigger, scope, headline exposure, proposed disposition, asks; (b) scope and boundary with out-of-scope declarations; (c) methodology — parsing convention, classification approach including Art 6(3) filter use, rating scale; (d) results — register extract with ratings, ranked exposure list, system classification table; (e) treatment — action plan and AIMS acceptances; (f) open constraints — interpretation-sensitive items with their stated assumptions, and pending guidance and harmonised standards; (g) evidence appendix with links.\n3. Verify internal consistency: summary counts match the register dashboard; every critical named in the disposition rationale appears in the package; no action due date falls after its obligation's applicability date without an explicit risk note.\n4. Make it standalone: a reviewer must be able to reach the disposition from the package alone. Anything that so far lives only in an analyst's head gets written down now.\n5. Pre-empt the approver's known concerns from the workplan review gates: contested classifications carry their legal-review evidence attached, not merely referenced.\n6. Version the package and freeze it: post-assembly changes happen as tracked revisions in the resolve-conditions step, never as silent edits to an issued version.\n\n7. Assessment scope for Approve or revise package: Capture the accountable approval of the analysis package — by the compliance officer, legal owner, obligation owner, or governance delegate — or return it with explicit, testable conditions.\n\n\n\n**Approved (`approved`)** — the approver confirms: scope matches the locked workplan or amendments are logged; classifications carry documented role and Art 6(3) analysis with legal review where contested; every obligation-system pair is rated, with operating evidence cited for every \"covers\"; every open gap has an owned, dated action or a signed, bounded risk acceptance; all escalation items carry recorded outcomes; and open constraints are stated with their assumptions. The operational test: the approver would defend this register and disposition to a market-surveillance authority responding to an Art 74 information request as the organization's position.\n- **Revision required (`revise`)** — any materially deficient element: coverage holes (systems or articles unrated); rating rationales that fail spot-checks; actions without owners or dates, or dated past statutory deadlines without a risk decision; undecided escalation items; inconsistencies between the summary and the register. Enumerate each condition specifically and testably — \"tighten section 4\" is not a condition; \"credit-model FRIA is missing the Art 27(1)(f) complaint-arrangements element\" is. Approve-with-conditions is a `revise`: conditions get resolved and re-checked, not waved through.\n\n**Record in AssureSwarm**\nAttach the versioned package document(s) to this step and link them from the impact-analysis item.\n- Attach the consistency-check note; record the version identifier.\n\nSubmit `approval_path`; the step result enumerates the conditions (revise) or states the basis of confidence and what was reviewed (approved); the step's approver record is the accountable approver — not a delegate drafting on their behalf.\n\n**Exit criteria**\nPackage is standalone-complete; consistency checks passed and documented; all constituent artifacts linked; version pinned for approval. Form submitted for the named approver against the pinned package version; conditions, if any, enumerated testably; the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — renders the linked evidence, register extract, and decision rationales into the versioned approval package.","kind":"decision","label":"Approve or revise package","performedBy":{"note":"","primitives":["coach-render-package"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Close every approval condition with a tracked, evidenced change so re-approval reviews deltas rather than re-reading the whole package.\n\n**Inputs**\n- The enumerated conditions from the approval decision.\n- The version-pinned package and the underlying records (register rows, classification memos, action items).\n\n**Procedure**\n1. Log each condition as its own tracked item: condition text, owner, target date, and the package sections and AssureSwarm records it touches.\n2. Fix at the record level first, then regenerate the affected package extract: correct the register row, classification, or action item — never patch the document while leaving the underlying record wrong, or the next dashboard refresh reintroduces the error.\n3. Record per condition what changed: old to new, evidence added, and where the change lands in the package. A condition the analyst disputes goes back to the approver with rationale — neither silently ignored nor performatively \"fixed\".\n4. Re-run the package consistency checks (summary counts against the register, action dates against statutory deadlines) — condition fixes are exactly where new inconsistencies creep in.\n5. Issue the next package version with a delta note: one line per condition — resolved (how) or disputed (why). Obtain the original accountable approver’s native approval of that exact revision and disposition of every disputed condition before the approval record or handoff proceeds.\n\n**Record in AssureSwarm**\n- Maintain the condition tracker (condition, owner, target date, status, evidence links) as a document on this step.\n- Fix at source first — correct the Issue field (`remediation_plan`, `severity`, dates), the register-workbook row, or the classification-table entry — then regenerate the affected package extract; attach the new package version and the per-condition delta note on this step.\n\n**Exit criteria** — Every condition resolved with evidence or formally disputed back to the approver; a new version issued with a per-condition delta note; consistency checks re-passed and the original approver’s exact-version reapproval recorded.","label":"Resolve approval conditions"},"id":"resolve-approval-conditions"},{"data":{"description":"Hand the approved gap-and-action package to Regulatory Obligation Implementation so execution starts from this analysis's conclusions without re-deriving them, and close the run on that acknowledgment with a complete, retrievable audit trail and the hooks that re-trigger the analysis when the regulatory or system landscape changes.","instructions":"**Objective**\nHand the approved gap-and-action package to Regulatory Obligation Implementation so execution starts from this analysis's conclusions without re-deriving them, and close the run on that acknowledgment with a complete, retrievable audit trail and the hooks that re-trigger the analysis when the regulatory or system landscape changes.\n\n**Inputs**\nThe submitted approval form and the approved package version.\n- Any non-blocking conditions carried into approval; the follow-up owner roster.\n\nThe approved, version-pinned package and the approval record; the action plan items with owners and dates.\n- The register extract for affected rows; AIMS acceptance records; escalation outcomes and risk acceptances with their conditions and void triggers.\n- The register's final state; the open follow-up items and acceptance re-review dates.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Record approval decision”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Record approval decision: Make the approval durable and auditable: who approved which package version, when, under what carried conditions, and who owns each follow-up.\n\n2. Record the approval facts against the version: approver name and role (confirming they hold the authority set in the workplan's review gates), date, and the package version identifier. An approval that does not pin a version approves nothing.\n3. Convert carried, non-blocking conditions into dated follow-up items with named owners — e.g., \"re-rate obligation X when the Art 6(5) classification guidance issues\" or \"confirm the vendor delivers Annex IV documentation by the contract milestone\".\n4. Verify the approval covered the full disposition — register state, action plan, risk acceptances — not just the executive summary; the rationale should show what was actually reviewed.\n5. Update the affected register rows' attestation status and date: this is the state the periodic compliance-attestation cycle will reference.\n6. Notify the owners whose actions and acceptances are now in force, with their dates and reporting cadence.\n\n7. Assessment scope for Handoff to related workflow: Hand the approved gap-and-action package to Regulatory Obligation Implementation so execution starts from this analysis's conclusions without re-deriving them, and close the run on that acknowledgment with a complete, retrievable audit trail and the hooks that re-trigger the analysis when the regulatory or system landscape changes.\n\n8. Create or link the Regulatory Obligation Implementation run and pass the handoff package: the approved package version; action items (owners, due dates, validation-evidence definitions); the register extract; interim mitigations in force; risk acceptances with conditions and void triggers; and the deadline table by applicability date.\n9. State the no-redo boundary: applicability calls, classifications, and gap ratings are settled by the approval. Implementation executes and verifies; a discovered fact that undermines a classification comes back as a formal change request against the register — never a local re-interpretation.\n10. State the inherited assumptions: interpretation-sensitive obligations and the assumptions used, pending guidance or harmonised standards that could shift requirements mid-build, and AIMS treatment dependencies with their report-back cadence.\n11. Agree the status-flow contract: implementation reports action closure with validation evidence back to the register on the action plan's cadence; slippage against statutory dates escalates per the thresholds set at workplan lock.\n12. Obtain acknowledgment: the implementation owner confirms scope, dates, and the no-redo boundary. Chase unacknowledged handoffs — silence is not acceptance.\n13. Verify completeness before closing: approval recorded against the final version; the item 12 acknowledgment in hand; every follow-up item owned and dated; no register row left in an intermediate status — \"in analysis\" rows are concluded or explicitly carried to a named successor run.\n14. Archive the full trail — final package, decision-node rationales, classification memos, crosswalk worksheet, peer-review record, escalation memos, acceptance records — organized so an Art 74 authority information request or an ISO 42001 internal audit can be answered from the archive alone. Align retention with the Act: provider technical documentation must remain available for ten years after placing on the market (Art 18), so set the archive's retention period accordingly. Post-archive corrections are new dated addenda, never edits to archived artifacts.\n15. Set the re-trigger hooks: watchlist entries for interpretation-sensitive items awaiting guidance or harmonised standards; exclusion re-test triggers; risk-acceptance re-review dates; and the standing link to Regulatory Horizon Scanning & Triage so the next AI Act change lands as a new run referencing this one. The register dashboard remains the live view — the archive is the snapshot, the register lives on.\n16. Communicate closure to the approver, obligation owners, AIMS owner, and implementation owner: the disposition, where the archive lives, and who owns what next.\n\n**Record in AssureSwarm**\nRecord approver, role, date, and package version on this step; set `Audit.report_date` to the approval date and `Audit.rating` (satisfactory = clean / needs_improvement = remediate / unsatisfactory = escalate) on the anchor Audit item.\n- Update the attestation status in the register-workbook rows (no native attestation field — the register XLSX carries it).\n- Create each carried, non-blocking condition as an Issue item (`issue_type: observation`, `issue_owner`, `target_remediation_date`); note the notifications sent on this step.\n\nAttach the handoff package on this step and link the downstream Regulatory Obligation Implementation run to the anchor Audit item and the gap Issue items it will execute.\n- Record the acknowledgment (who, when) on this step; mark the affected register-workbook rows \"handed to implementation\" with the link.\n- Record the archive confirmation (locations, links) on this step — the workflow instance is the audit trail; create the watchlist entries.\n- Set the anchor Audit item status to COMPLETE; acceptance re-review dates live in the acceptance memos attached at the escalate-or-accept-risk step (no date field on the `ai_governance` Risk item), and remediation deadlines live in the open Issue `target_remediation_date` fields. Note the closure communication and its recipients on this step.\n\n**Exit criteria**\nApproval pinned to the package version with authority confirmed; register attestation updated; every carried condition exists as a dated, owned follow-up; owners notified. Downstream run linked with the complete package; no-redo boundary and inherited assumptions documented; acknowledgment recorded and the status-flow contract agreed; completeness verification passed; archive confirmation recorded; re-trigger hooks (watchlists, re-review dates, scanning link) in place; closure communicated; register confirmed as the continuing live view.","label":"Handoff to related workflow"},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:reg-eu-ai-act-impact-analysis"}