{"description":"Each quarterly instance runs against the existing \"AI Transparency & Value-Chain Communications\" Process item (process_type: business_process, frequency: quarterly), enriching it rather than recreating it, and links to the existing Control items UC-AI-10 and UC-AI-14 (framework: iso-42001 + eu-ai-act, domains: ai_governance) that the cycle executes. A recurring operate cycle that keeps AI system documentation, interaction disclosures, and content marking current with system changes, retains distribution evidence, evaluates AI suppliers (Vendor items) against responsible-AI requirements, and reviews customer needs and communications; the transparency policy and content-marking standard it enforces are Policy items. It consumes no upstream handoff package (a self-originating quarterly cadence) and terminates in no downstream workflow — systemic findings and carry-forwards land as Issue items in the AI governance backlog. In scope: every AI system in production or customer-facing use and every AI supplier providing an AI system, model component, training data, or inference service; out of scope: risk-classification and conformity assessment itself — purpose or risk-class drift is routed to the EU AI Act Impact Analysis workflow (as an observation Issue referencing it) rather than resolved in this cycle.","edges":[{"id":"e-update-user-and-deployer-documentation-decide-publication-readiness","source":"update-user-and-deployer-documentation","target":"decide-publication-readiness"},{"id":"e-decide-publication-readiness-review-customer-needs-and-communications","label":"Publish","source":"decide-publication-readiness","target":"review-customer-needs-and-communications","whenValue":"publish"},{"id":"e-decide-publication-readiness-remediate-disclosure-and-marking-gaps","label":"Hold for remediation","source":"decide-publication-readiness","target":"remediate-disclosure-and-marking-gaps","whenValue":"hold_for_remediation"},{"id":"e-remediate-disclosure-and-marking-gaps-review-customer-needs-and-communications","source":"remediate-disclosure-and-marking-gaps","target":"review-customer-needs-and-communications"},{"id":"e-evaluate-ai-suppliers-for-responsible-ai-alignment-issue-supplier-corrective-action-or-disengagement","label":"Action required","source":"evaluate-ai-suppliers-for-responsible-ai-alignment","target":"issue-supplier-corrective-action-or-disengagement","whenValue":"action_required"},{"id":"e-evaluate-ai-suppliers-for-responsible-ai-alignment-review-customer-needs-and-communications","label":"Approved","source":"evaluate-ai-suppliers-for-responsible-ai-alignment","target":"review-customer-needs-and-communications","whenValue":"approved"},{"id":"e-issue-supplier-corrective-action-or-disengagement-review-customer-needs-and-communications","source":"issue-supplier-corrective-action-or-disengagement","target":"review-customer-needs-and-communications"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-10","UC-AI-14"],"department":"ai-governance","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-ai-transparency-value-chain-communications","contentDigest":"sha256:60cc1c01c83f6e87a9af1c1e666feb0df4473bd01115003eb5d049b0381808b9","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:60cc1c01c83f6e87a9af1c1e666feb0df4473bd01115003eb5d049b0381808b9","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-ai-transparency-value-chain-communications"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-ai-transparency-value-chain-communications","source":"coworkcanvas-gallery","standards":["iso-42001","eu-ai-act","aiuc-1"],"teams":["ai-governance","compliance-legal"]},"name":"AI Transparency & Value-Chain Communications","nodes":[{"data":{"description":"Bring each flagged system's user and deployer documentation back into line with actual system behavior — targeted edits, version-stamped, technically verified, and staged for the publication-readiness decision, where the disclosure and marking audit runs. Nothing publishes from this step.","instructions":"**Objective**\nBring each flagged system's user and deployer documentation back into line with actual system behavior — targeted edits, version-stamped, technically verified, and staged for the publication-readiness decision, where the disclosure and marking audit runs. Nothing publishes from this step.\n\n**Inputs**\nThe in-scope AI systems from the AI system inventory (every AI system, feature, or embedded model in production or customer-facing use, with its intended purpose, deployment context, and risk class).\n- Per-system current-state sources: release notes, the model/version registry, evaluation results, and the quarter's product changelog.\n- The last-published user and deployer documentation per system (the baseline loaded at cycle open).\n- The content-marking standard (a Policy item, policy_type: standard, framework: eu-ai-act) and its list of markable content types.\n\nThe approved change register with the specific drifted facts per system.\n- The last-published documentation set per flagged system.\n- The documentation content requirements: the transparency policy per system class (a Policy item, policy_type: policy, framework: iso-42001 + eu-ai-act); for high-risk systems the EU AI Act Art. 13 instructions-for-use elements; ISO/IEC 42001 A.8.2 for user information generally (requirement detail in the UC-AI-10 / UC-AI-14 Control descriptions).\n- The engineering or product owner per system, for the technical-accuracy verification.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Detect system and content changes”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Detect system and content changes: Produce the cycle's change register: every system whose published documentation no longer matches how it actually behaves, the specific facts that drifted, and every AI-generated-content surface without a proven marking mechanism — the approved work list for the documentation update and for the disclosure and marking audit run at the publication-readiness decision.\n\n2. For each in-scope system, diff the current state against what the last-published documentation asserts, fact by fact: model or version, training or fine-tuning data changes, capabilities, known limitations, measured performance (the metrics and the evaluation conditions behind them), deployment context, and required human-oversight measures. The comparison is documentation claims versus system reality — not one document version against another.\n3. Classify each flagged system's drift — purpose, capability, limitation, performance, or oversight-measure — and record the specific fact that changed (e.g., \"supported languages expanded 12 → 31; the documented evaluation covers 12\") so the update step can target it instead of blanket-rewriting. Purpose drift is the most consequential: under EU AI Act Art. 25, a modified intended purpose can shift regulatory role or risk class — route such cases to the EU AI Act Impact Analysis workflow in parallel; this cycle only corrects the documentation.\n4. Apply a materiality test: a change is material when it would alter a deployer's or user's decision about whether or how to use the system — a new failure mode, degraded performance for a subgroup, a changed oversight expectation. Purely cosmetic changes (UI copy, latency) do not drive documentation updates.\n5. Separately inventory every surface presenting AI-generated or manipulated content to a person this quarter — generated images, video, audio or synthetic voice, and long-form synthetic text where policy requires marking — including content types and distribution channels added since last cycle. A new export path or API surface that bypasses the marking pipeline is the classic regression. Flag every surface without a known, tested marking mechanism.\n6. Compile the change register: systems with stale documentation plus their drifted facts, and content surfaces unmarked or newly introduced.\n7. Reviewer check before approval: verify the register against the quarter's release notes and changelog, and sample the systems NOT flagged to confirm absence of change — completeness of the register is what is being approved, not just accuracy of its entries.\n\n8. Assessment scope for Update user and deployer documentation: Bring each flagged system's user and deployer documentation back into line with actual system behavior — targeted edits, version-stamped, technically verified, and staged for the publication-readiness decision, where the disclosure and marking audit runs. Nothing publishes from this step.\n\n9. Update only the sections the register flags — intended purpose, capabilities, limitations, performance characteristics, human-oversight measures — leaving unaffected sections untouched so reviewers can focus on what changed.\n10. While in a high-risk system's deployer documentation, verify Art. 13 completeness rather than only fixing the drifted fact: provider identity and contact; characteristics, capabilities, and limitations of performance, including intended purpose, the tested accuracy, robustness, and cybersecurity levels with the metrics used, known foreseeable circumstances leading to risk or misuse, and performance on the specific persons or groups the system is intended for; input-data specifications; human-oversight measures, including technical measures that help deployers interpret outputs; expected lifetime and maintenance; and log-collection mechanisms.\n11. Write the human-oversight section operationally: the required review steps, the override or shutoff mechanism, and the escalation path — matching the actual operating design. The test: could a new deployer stand up compliant oversight from this section alone, without asking anyone?\n12. State limitations concretely, tied to conditions — \"accuracy degrades on scanned inputs below 200 DPI\" or \"evaluation covers English and Spanish only\" — never generic \"results may vary\" language, which fails the deployer and the regulator alike.\n13. Version-stamp each updated document set with its effective date and a change summary referencing the specific drifted facts corrected, and link the new version to its AI system item so the documentation history stays traceable.\n14. Stage every updated set without publishing, and compile the staged-documentation package: each system, what changed, and the verifier needed.\n15. Technical-accuracy verification: the system's engineering or product owner confirms each staged document against actual system behavior — accurate, not merely internally consistent — and approves the package into the publication-readiness decision, where it is audited for disclosure and marking alongside the staged content surfaces.\n\n**Record in AssureSwarm**\nThere is no AI System item type, so the change register is itself the record: attach it as a step document (XLSX) to this step, one row per flagged system and content surface with its drift classification and the specific drifted fact — do not fabricate per-system items to link to.\n- For each case of purpose or risk-class drift, create an Issue (issue_type: observation, source: compliance_review, issue_owner) that references the EU AI Act Impact Analysis workflow and link it to the anchor Process item — this carries the parallel routing since the template has no handoff terminal node.\n- Attach the diff evidence to this step (document upload).\n\nUpload each staged documentation version to this step and link it to the anchor Process item and the workflow instance (the cycle record) — with no AI System item to relate, the Process item is the link target.\n- Record the version stamp and change summary per system on this step.\n- Attach the staged-documentation package to this step (document upload).\n\n**Exit criteria**\nEvery in-scope system has a recorded diff outcome (drifted with classified facts, or confirmed unchanged); every content surface has a marking-mechanism status; the register is verified against release records including a sample of unflagged systems, and approved as the downstream work list. Every register-flagged system has a staged documentation version with an effective date and change summary; oversight sections state operational measures; a named technical verifier signed off per system; nothing has been published.","label":"Update user and deployer documentation","performedBy":{"note":"","primitives":["coach-document-upload","coach-query-data","coach-item-create","coach-items-link"]}},"id":"update-user-and-deployer-documentation"},{"data":{"decisionField":"publication_readiness","description":"Agent scans every user-facing AI touchpoint and content surface for the required disclosure and marking, compiles the severity-rated gap register, and summarizes it with the staged documentation into a publication-readiness recommendation; human decides whether to publish now or hold for remediation","formData":{"fields":[{"key":"publication_readiness","label":"Publication readiness","options":[{"label":"Publish — no material disclosure or marking gap remains","value":"publish"},{"label":"Hold for remediation — a material gap must be fixed first","value":"hold_for_remediation"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Test every user-facing AI touchpoint and content surface for the required disclosure and marking, then decide whether this quarter's staged documentation, disclosures, and marking changes release now or whether material gaps hold part of the batch back. The cycle owner (AI Product Governance Manager) decides on the combined readiness summary.\n\n**Inputs**\n- The touchpoint list for in-scope systems: product UI, chat and assistant interfaces, generated reports and emails, voice and IVR surfaces.\n- The content-surface inventory from the change register, including newly added channels.\n- The content-marking standard (the content-marking Policy item — machine-readable and perceptible requirements, deepfake treatment) and the transparency obligations that attach to each in-scope system — deployer instructions for use (EU AI Act Art. 13 for high-risk systems; ISO/IEC 42001 A.8.2 generally), AI-interaction disclosure (Art. 50(1)), synthetic-content marking (Art. 50(2)), and deepfake disclosure (Art. 50(4)).\n- The staged documentation package with its technical-accuracy sign-offs.\n\n**Procedure**\n\n_Items 1–8 are agent-run except the sample re-performance at item 7 (folded from the former \"Audit AI-interaction disclosures and content marking\" step); the human moment is the publish/hold call below._\n\n1. Interaction-disclosure test per touchpoint (the EU AI Act Art. 50(1) pattern): the disclosure exists; it appears before or at the point of first interaction — Art. 50(5) requires clear and distinguishable information at the latest at first interaction or exposure — and it is worded plainly (\"you are chatting with an AI assistant\"), not buried in terms of service or a settings page. The exemption for systems obvious to a reasonably well-informed, observant, and circumspect person is claimed explicitly with a written justification, never assumed — a branded assistant with a human-sounding name is not obvious.\n2. Machine-readable marking test per content surface (the Art. 50(2) pattern): provenance metadata or content credentials (a C2PA-style manifest, IPTC digital-source-type) are embedded at generation. Then test robustness the way content actually travels: download and re-upload, resize or re-encode, share through a major platform — XMP/EXIF metadata is routinely stripped in transit, so metadata-only marking usually fails while watermark-backed marking survives. Record which transformations each surface's marking survived.\n3. Perceptible marking test: a person consuming the content would actually notice — a visible label or caption on synthetic images and video, an audible or visible cue on synthetic voice delivered where consumption happens (at call start, not only in an app screen nobody opens).\n4. Deepfake-risk content — realistic synthetic media resembling real people, places, entities, or events that would falsely appear authentic (Art. 3(60)) — gets heightened scrutiny: the disclosure must be prominent on the content itself, and a failure here is material by default.\n5. Compile the gap register: each touchpoint or surface, the specific requirement failed (missing disclosure, missing machine-readable marking, insufficiently perceptible marking, inadequate deepfake handling), and a severity rating — material when a person is misled about interacting with AI or about content authenticity; cosmetic when it is wording or placement polish, or documentation-only.\n6. Attach the coverage summary: touchpoints and surfaces tested, pass and fail counts, and anything unreachable with the reason — an unreached surface is an open item, never a pass.\n7. Re-perform a sample of flagged items to weed out false positives and settle each severity rating before the readiness call.\n8. Assemble the readiness summary — the staged-documentation package with its technical sign-offs plus the gap register — sorted by system and touchpoint, and verify three things: documentation verification is complete for every staged system; every gap carries a confirmed severity; and the coverage summary accounts for every surface, because an untested surface counts as a material gap until tested — only what was verified releases.\n\n**Decision criteria**\n\n- **Publish (`publish`)** — no gap rated material remains open: every touchpoint discloses the AI interaction at or before first interaction, every content surface carries machine-readable plus perceptible marking that survived the distribution test, deepfake-risk content is prominently disclosed, and every staged document has its technical-accuracy sign-off. Cosmetic gaps may ride along with logged follow-up items; material gaps may not.\n- **Hold for remediation (`hold_for_remediation`)** — at least one material gap stands: a person would be unaware they are dealing with an AI system, or unable to recognize AI-generated content, or a deepfake-risk surface lacks prominent disclosure, or a staged document failed accuracy verification. Scope the hold precisely: list exactly which systems and surfaces are excluded until fixed, so unrelated items are not delayed — the hold is item-scoped, not batch-wide, unless gaps are pervasive across the batch.\n\n**Record in AssureSwarm**\n- Create an Issue per finding — issue_type: finding, source: compliance_review, severity (material → high/critical, cosmetic → low), identified_date, issue_owner — capturing the surface and the specific requirement failed; link each Issue to Control UC-AI-10 and the anchor Process item (there is no AI System item to link to).\n- Attach the full gap register plus the test evidence — screenshots, recordings, metadata-extraction output — the coverage summary, and the readiness summary to this step (document upload).\n- Submit the decision form: `publication_readiness` (the branch), the step result citing the specific gap-register entries relied on — or the zero-material-gap state — plus the documentation sign-off references, and the step's approver record.\n\n**Exit criteria** — Every touchpoint and content surface has a recorded pass or fail with evidence; unreachable surfaces are logged as open items; severity ratings settled on a re-performed sample; gap register, coverage summary, and readiness summary attached; the form is submitted with a rationale traceable to register entries and sign-offs; on a hold, the excluded-item list is explicit; the unused branch is prunable because the taken branch fully describes the remaining work.","kind":"decision","label":"Decide publication readiness","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"decide-publication-readiness"},{"data":{"description":"Agent implements the fixes for every material gap the readiness decision held back and re-tests until none remain; human confirms the hold is cleared before release","instructions":"**Objective** — Remediate the disclosure and marking gaps the readiness decision held back and prove each fix by re-test — held items rejoin the release batch only on a genuine pass.\n\n**Inputs**\n- The hold list from the readiness decision: excluded systems and surfaces plus the gap-register entries driving each.\n- The approved standard disclosure wording and placement patterns from the transparency Policy item.\n- The content-marking standard (Policy item): required provenance mechanics, perceptible-label specifications, deepfake treatment.\n\n**Procedure**\n1. For each missing or inadequate AI-interaction disclosure, implement the approved standard wording at the point of interaction — before or at first interaction, plain language, on the surface itself. Do not invent per-surface wording; any deviation from the standard pattern needs the policy owner's sign-off, or the next audit flags it again.\n2. For each missing or deficient marking, wire the machine-readable provenance the standard requires — content credentials and, where mandated, watermarking robust to re-encoding — into the generation pipeline itself, not as a post-hoc batch job new content can bypass; and add the clearly perceptible visible or audible marking at the consumption surface. Apply the heightened deepfake treatment to realistic synthetic media of real people, places, or events: prominent disclosure on the content itself.\n3. Fix at the mechanism level: when one export path shipped unmarked content, test the sibling paths sharing its pipeline before declaring the gap closed — patching gap-by-gap leaves the defect class alive for next quarter.\n4. Re-run the exact disclosure and marking tests the readiness decision ran against every remediated item — same method, fresh evidence, including the distribution-robustness pass for markings. An item that still fails stays held; never re-flag it as resolved on the promise of a fix.\n5. Update the gap register per item with the remediation applied, the re-test result, and the evidence reference; roll cleared items back into the release batch.\n6. Human confirmation: every item rejoining the batch shows a re-test pass, nothing above the material threshold is riding along, and the remediated batch is cleared to rejoin publication.\n\n**Record in AssureSwarm**\n- Update each gap Issue: remediation_plan (the fix applied), and on a genuine re-test pass actual_remediation_date and verified_date plus status; items still failing keep their target_remediation_date and issue_owner and stay open.\n- Attach the re-test evidence and record the cleared-items list on this step (document upload).\n\n**Exit criteria** — Every held item shows a re-test pass with fresh evidence, or remains held with a named owner and target date; the register reflects current status; human clearance recorded; no still-failing item sits in the release batch.","label":"Remediate disclosure and marking gaps","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-update"]}},"id":"remediate-disclosure-and-marking-gaps"},{"data":{"decisionField":"supplier_disposition","description":"Agent scores each AI supplier against the organization's responsible-AI requirements from their submitted evidence and drafts a per-supplier recommendation; human decides each supplier's disposition","formData":{"fields":[{"key":"supplier_disposition","label":"Supplier disposition","options":[{"label":"Approved — supplier meets responsible-AI requirements","value":"approved"},{"label":"Action required — corrective action or disengagement needed","value":"action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Disposition the AI-supplier roster against the organization's responsible-AI requirements on the strength of submitted evidence (ISO/IEC 42001 A.10.3: supplier services align with the organization's responsible-AI approach). The cycle owner decides, consulting procurement or vendor management; the branch reflects whether any supplier requires action.\n\n**Decision criteria**\n\nFor each supplier on the roster — the AI suppliers in the Vendor register (Vendor items; anyone providing an AI system, model component including GPAI/foundation models, training data, or inference service) — retrieve the responsible-AI evidence package: model or system documentation (for GPAI suppliers, the downstream-provider documentation the EU AI Act Art. 53 regime obliges them to supply); bias, robustness, and safety testing results; data-provenance and licensing terms; certifications held (ISO/IEC 42001, SOC 2); and incident and complaint history since last cycle. Score against the supplier requirements checklist on four axes: documentation completeness — can the organization meet its own deployer-transparency obligations from what the supplier provided (their documentation gap becomes our Art. 13 gap); testing coverage — evaluations relevant to our deployment context, not just generic benchmarks; data-provenance clarity — training-data sources and license position stated, not waved at; incident responsiveness — disclosed within the contractual SLA with root cause and fix. Score what is evidenced, not what is promised: an expired certificate, an \"under NDA, trust us\" answer, or evidence predating the supplier's last major model release is an unmet requirement.\n\n- **Approved (`approved`)** — every roster supplier's evidence satisfies every checklist requirement, and prior-cycle corrective actions are verified closed. All suppliers carry forward unchanged; record per-supplier scores and evidence pointers.\n- **Action required (`action_required`)** — at least one supplier fails at least one requirement. Classify each failing supplier's remedy in the rationale: a remediable gap (missing document, stale test evidence, unclear licensing the supplier can cure) points to corrective action; an unremediable or trust-breaking gap (refusal to evidence data provenance for a system deployed in a regulated use, a concealed incident, repeat gaps persisting across cycles) points to disengagement. Name the suppliers, the checklist items, and the remedy class — the notice step drafts directly from this.\n\n**Record in AssureSwarm**\n- Submit the decision form: `supplier_disposition` (the branch), the step result (per failing supplier: checklist items unmet, evidence pointers, remedy class — or the clean-pass confirmation), and the step's approver record.\n- Update each evaluated Vendor item: `last_assessment_date` (this cycle), `next_reassessment_date`, and `monitoring_status` (enrolled while under active governance).\n- Attach the supplier evaluation register with per-supplier scores and evidence pointers to this step (document upload); link the evaluated Vendor items to the workflow instance (the cycle record) and the anchor Process item.\n\n**Exit criteria** — Every roster supplier has a scored evaluation with evidence pointers; form submitted; where any supplier fails, the rationale names supplier, checklist item, and remedy class; the unused branch is prunable.","kind":"decision","label":"Evaluate AI suppliers for responsible-AI alignment","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-items-link","coach-item-update"]}},"id":"evaluate-ai-suppliers-for-responsible-ai-alignment"},{"data":{"description":"Agent drafts and dispatches the corrective action notice or the disengagement and transition notice for each non-approved supplier and logs the outcome; human confirms before dispatch","instructions":"**Objective** — Convert each non-approved supplier's evaluation into a dispatched notice — corrective action with a deadline, or disengagement with a transition plan — and a tracked follow-up, so next cycle's evaluation starts from current status rather than from scratch.\n\n**Inputs**\n- The supplier evaluation register: the failing Vendor items, their unmet checklist items, and the remedy class per supplier.\n- Each supplier's contract: audit and remedy clauses, termination and notice provisions, exit-assistance and data-return obligations.\n- The affected-system map: which in-scope AI systems consume each supplier's components — kept as a register document on the anchor Process item, since there is no AI System item type to relate.\n\n**Procedure**\n1. For each remediable gap, draft the corrective action notice: the specific checklist gaps found with the evidence reviewed, the remediation required stated verifiably (\"provide a bias evaluation of model X covering the demographic axes in our deployment context\" — not \"improve documentation\"), and a response deadline scaled to exposure — 30 days is a workable default, shorter when the gap blocks the organization's own deployer obligations. Flag the supplier's components for follow-up verification next cycle.\n2. For each unremediable or trust-breaking gap, draft the disengagement notice and transition plan: the affected AI systems and components, the alternative supplier or in-house substitute where one exists, the target date to stop relying on the supplier, and interim risk measures while the transition runs (constrain the affected feature, add human review). Check the contract's notice period and data-return or deletion obligations before committing dates.\n3. Realism check: a disengagement with no viable substitute is a risk acceptance in disguise — if no alternative exists, say so and route the residual-risk acceptance to its proper owner instead of publishing an unachievable plan.\n4. Log against each supplier's record: the evaluation outcome, the notice issued, and the deadline or target date.\n5. Compile the outstanding-supplier-action list — every corrective action and disengagement in flight with its deadline and owner — for cycle tracking and the close step.\n6. Human confirmation before dispatch: each notice accurately reflects the decision and its deadline, and each transition plan is realistic. Dispatch through the contractual notice channel and keep the send evidence.\n\n**Record in AssureSwarm**\n- Create an Issue per notice — issue_type: finding, source: compliance_review, description (the unmet checklist items), remediation_plan (the required remedy or the transition plan), target_remediation_date (the notice deadline), issue_owner — linked to the failing Vendor item and to Control UC-AI-14 and the anchor Process item.\n- Update each failing Vendor item's `monitoring_status` (exited on disengagement) and record the evaluation outcome and current status on it.\n- Where a disengagement has no viable substitute, record the residual-risk acceptance as a policy_exception Issue (issue_type: policy_exception, exception_approver, exception_expiry_date) linked to the backing ai_governance Risk item, and set `treatment: accept` on that Risk — never publish an unachievable transition plan.\n- Attach the dispatched notices and send evidence to this step (document upload).\n\n**Exit criteria** — Every action-required supplier has a dispatched notice with a deadline; every disengagement has a transition plan with interim measures; the outstanding-action list is compiled with owners and deadlines; supplier records reflect current status.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` dispatches the corrective-action and disengagement notices through the recorded channel and keeps the logged send trail.","label":"Issue supplier corrective action or disengagement","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-item-update","coach-items-link","coach-notify"]}},"id":"issue-supplier-corrective-action-or-disengagement"},{"data":{"description":"Verify the quarter's published materials actually answer what customers are asking about the organization's AI systems, and close every gap with a targeted responsible-use communication (ISO/IEC 42001 A.10.4: ensure customers can use the systems responsibly).","instructions":"**Objective**\nVerify the quarter's published materials actually answer what customers are asking about the organization's AI systems, and close every gap with a targeted responsible-use communication (ISO/IEC 42001 A.10.4: ensure customers can use the systems responsibly).\n\n**Inputs**\nThe release batch: items arriving straight from a publish decision plus items cleared through remediation.\n- The staged documentation versions with their sign-offs.\n- The deployer-of-record contact and channel list for deployer-facing materials.\n- The evidence conventions for transparency evidence (what counts as proof of distribution).\n\nThe quarter's AI-related customer signals: support tickets, account-team escalations, security and RFP questionnaire responses, complaints.\n- The quarter's published documentation and disclosures from the publication step.\n- The prior cycle's customer correspondence log and any unresolved themes.\n\nThe cycle outputs: change register; staged and published documentation set; disclosure and marking gap register with remediation evidence; distribution evidence package; supplier evaluation register with notices; outstanding-supplier-action list; customer correspondence log.\n- The records-retention schedule for AI-transparency and supplier-governance evidence — align with EU AI Act Art. 18, which keeps high-risk technical documentation at the authorities' disposal for ten years after placing on the market, and with the documented-information rules of the ISO/IEC 42001 management system.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Publish updates and capture distribution evidence”, “Close and archive”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Publish updates and capture distribution evidence: Release the cleared documentation, disclosures, and content-marking configuration to production and capture per-item proof of distribution, so the quarter's transparency posture is demonstrable rather than asserted.\n\n2. Release the batch: publish the documentation versions and enable the disclosure and marking configuration in production for every system and surface, whichever path it arrived by. Verify the released artifact is the reviewed artifact — version identifier or checksum match against what was signed off, not a later edit.\n3. Capture publication evidence per item: the published document with version stamp and effective date; a screenshot or build artifact showing the disclosure or marking live in production (staging screenshots prove nothing); and the publication timestamp.\n4. For deployer-facing materials, push through the distribution channel of record — a notification, a portal posting, or a direct send — and capture the delivery confirmation the channel provides (send log, portal access record). Art. 13-style instructions for use must actually reach the deployer of record; posting to a location nobody was told about is not distribution. Where a channel offers no read receipt, record what it does provide and note the limitation rather than overstating.\n5. Assemble the distribution evidence package indexed by system and surface — per entry: what changed, the version, when it published, where the live proof sits, and the delivery confirmation for deployer materials — and link it to the cycle record.\n6. Human confirmation: spot-open a sample of the live surfaces and published documents rather than trusting the index; confirm the package proves distribution, not merely drafting, for every batch item; approve it as the quarter's transparency evidence of record.\n\n7. Assessment scope for Review customer needs and communications: Verify the quarter's published materials actually answer what customers are asking about the organization's AI systems, and close every gap with a targeted responsible-use communication (ISO/IEC 42001 A.10.4: ensure customers can use the systems responsibly).\n\n8. Compile the quarter's AI-related inquiries, expectations, and concerns from every channel and group them by AI system and by theme — data use and training, accuracy limits, the human oversight expected of the customer, marking of generated outputs, regulatory posture. Include RFP and security-questionnaire items: they show what buyers will demand next quarter.\n9. Cross-check each theme against the published documentation and disclosures: does the published material answer the question a customer actually asked, findable where a customer would look? A correct answer in an unfindable place is still a gap. Test each theme against the materials — never assume the standard documentation suffices.\n10. For each gap, draft the targeted responsible-use communication in the right vehicle: an FAQ update for recurring cross-customer themes, direct correspondence for account-specific concerns, a briefing note where the customer's own oversight duties are engaged — stating plainly what human-oversight measures the customer is expected to exercise on their side, which they cannot infer from marketing material.\n11. Recurrence check: a theme recurring across two or more cycles is a documentation defect, not a correspondence matter — feed it into next cycle's change register so the core documentation absorbs the answer.\n12. Log every inbound inquiry and outbound communication against the customer and the AI system it concerns, so the correspondence record is complete rather than scattered across channels.\n13. Human confirmation: the drafted communications genuinely address the needs raised, no recurring theme is left unanswered, and dispatch is approved along with the correspondence log as the quarter's customer-facing evidence.\n\n14. Assessment scope for Close and archive: Close the cycle with a complete, self-contained record archived under retention, metrics computed, and systemic findings routed to the AI governance backlog — no system, supplier, or customer theme left without a recorded outcome.\n\n15. Confirm the cycle is actually closable: every in-scope system reached publication or sits on a recorded hold with an owner; every supplier has a disposition and, where required, a dispatched notice; every customer theme has a disposition. Open threads escalate or become explicit carry-forwards — a cycle never closes around silent orphans.\n16. Assemble the cycle record from the outputs above, indexed so a regulator or customer auditor can navigate it unaided. The completeness test: the record alone shows what was in scope, what changed, what was found, what was fixed, what shipped and to whom, and who decided — no oral explanation needed.\n17. Compute the cycle metrics: systems with documentation updated; disclosure and marking gaps found versus closed before release; suppliers approved versus on corrective action versus disengaged; customer inquiries answered by a new or updated communication. Trend against prior cycles — the trend is what surfaces systemic decay.\n18. Archive the cycle record to the retention location under the applicable retention period and verify retrievability by reopening the archived copy, not by trusting the upload confirmation. Archive confirmation is recorded on the cycle record; post-archive corrections are new dated addenda, never edits to the archived set.\n19. Route systemic findings into the AI governance backlog with proposed owners: a system whose documentation drifts every cycle (a documentation-process failure, not a content fix), a content pipeline repeatedly failing marking checks, a supplier accumulating corrective actions across cycles (escalate the remedy class), a customer theme that keeps returning unanswered.\n20. Update the control execution log for UC-AI-10 and UC-AI-14 with the period, completion date, result, and key metrics; refresh the transparency metrics dashboard; confirm next quarter's cycle is on the calendar.\n21. Record cycle completion automatically after the approved customer communications and recorded supplier dispositions; retain all holds and open actions with their owners.\n\n**Record in AssureSwarm**\nUpload the distribution evidence package (indexed PDF/ZIP) and the per-item proofs to this step.\n- Link the package to the workflow instance (the cycle record) and to the anchor Process item — with no AI System item, the Process item stands in for per-system links.\n- Record publication dates and version identifiers per system on this step.\n\nAttach the approved communications and the correspondence log to this step (document upload) — there is no Customer or AI System item type, so the log stays a step document rather than linking to per-customer or per-system items.\n- For each theme recurring across two or more cycles, create an Issue (issue_type: observation, source: compliance_review, issue_owner) linked to the anchor Process item so it feeds the next cycle's change register.\n- Record per-system theme dispositions (answered by published material, answered by new communication, escalated to the change register) on this step.\n\nExport the final workflow record (the workflow instance is the audit trail) and attach the assembled cycle record with its archive reference to this step (document upload).\n- Create or refresh the transparency-metrics dashboard with the cycle and trend metrics (gap Issues by severity/status, supplier-action Issues open vs closed).\n- Create carry-forward Issues — supplier actions in flight, held systems, recurring customer themes — each with issue_owner and target_remediation_date, linked to the anchor Process item and the relevant Control (UC-AI-10 / UC-AI-14).\n- The Control items carry no execution-log field, so the UC-AI-10 / UC-AI-14 period, result, and key metrics are recorded in the assembled cycle-record document (honest fallback), not on the Control item.\n\n**Exit criteria**\nEvery batch item is live in production with captured proof; deployer materials carry delivery confirmation, or a recorded channel limitation with compensating evidence; the evidence package is linked to the cycle record and approved. Every theme has a recorded disposition with a reference; approved communications dispatched with send evidence; the correspondence log is complete and linked; recurring themes are queued for the next change register. Archived record verified retrievable with its reference recorded; every system, supplier, and theme shows a recorded outcome; metrics on the dashboard; systemic findings sit in the AI governance backlog with proposed owners; next cycle scheduled; completion recorded after the authorized communications and supplier dispositions.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the indexed distribution-evidence package from the cycle's linked documents; `/coach-notify` sends the deployer notifications and logs the delivery trail.","label":"Review customer needs and communications","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-items-link","coach-item-create","coach-render-package","coach-notify","coach-dashboard-create","coach-workflow-export"]}},"id":"review-customer-needs-and-communications"}],"sourceTemplateId":"workflow-library:reg-ai-transparency-value-chain-communications"}