{"description":"Recurring operate cycle that fulfills Article 53 general-purpose AI model provider duties every release and quarterly refresh, and layers in Article 55 systemic-risk duties for models designated as posing systemic risk. The cycle runs as one Workflow instance on the existing Process item \"GPAI model governance / provider compliance\" (process_type: business_process, process_owner: Head of Model Governance) — enriched each cycle, never recreated — and links to the Control item implementing UC-AI-15. It consumes the prior cycle's archived instance on the same Process anchor (the per-model scope/exemption register and the prior version-of-record documentation carry forward), and produces the archived, authority-producible provider-obligation cycle record as its named deliverable. Note: the Studio catalog has no AI-Model item type, so per-model artifacts — scope, open-source-exemption determination, documentation and pack versions, publication records — live as version-stamped step documents and on the Workflow instance rather than on a model item, with the per-model scope register carried as a document on the anchor Process item. In scope: every general-purpose AI model this provider places on the EU market, scoped per model to Article 53 alone or Article 53 plus Article 55, with per-model provider-status and Article 53(2) open-source-exemption determinations carried on that scope register. Out of scope: the downstream integrator's own AI-system risk-class obligations, which each deployer operates separately; there is no named downstream workflow this cycle hands off to.","edges":[{"id":"e-prepare-downstream-provider-information-pack-publish-training-content-summary","source":"prepare-downstream-provider-information-pack","target":"publish-training-content-summary"},{"id":"e-operate-copyright-compliance-policy-publish-training-content-summary","source":"operate-copyright-compliance-policy","target":"publish-training-content-summary"},{"id":"e-determine-systemic-risk-designation-evaluate-systemic-risk-mitigation","label":"Systemic risk designated","source":"determine-systemic-risk-designation","target":"evaluate-systemic-risk-mitigation","whenValue":"designated"},{"id":"e-determine-systemic-risk-designation-publish-training-content-summary","label":"Not designated","source":"determine-systemic-risk-designation","target":"publish-training-content-summary","whenValue":"not_designated"},{"id":"e-evaluate-systemic-risk-mitigation-track-and-report-serious-incidents","label":"Acceptable","source":"evaluate-systemic-risk-mitigation","target":"track-and-report-serious-incidents","whenValue":"acceptable"},{"id":"e-track-and-report-serious-incidents-verify-cybersecurity-protection","source":"track-and-report-serious-incidents","target":"verify-cybersecurity-protection"},{"id":"e-evaluate-systemic-risk-mitigation-strengthen-risk-mitigations","label":"Escalate","source":"evaluate-systemic-risk-mitigation","target":"strengthen-risk-mitigations","whenValue":"escalate"},{"id":"e-strengthen-risk-mitigations-track-and-report-serious-incidents","source":"strengthen-risk-mitigations","target":"track-and-report-serious-incidents"},{"id":"e-strengthen-risk-mitigations-verify-cybersecurity-protection","source":"strengthen-risk-mitigations","target":"verify-cybersecurity-protection"},{"id":"e-track-and-report-serious-incidents-publish-training-content-summary","source":"track-and-report-serious-incidents","target":"publish-training-content-summary"},{"id":"e-verify-cybersecurity-protection-publish-training-content-summary","source":"verify-cybersecurity-protection","target":"publish-training-content-summary"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-15"],"department":"ai-governance","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-gpai-model-provider-compliance-cycle","contentDigest":"sha256:7e427a460ababb62b9c8cfd5ce27abc223cd59cabef347babf2696300e458859","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:7e427a460ababb62b9c8cfd5ce27abc223cd59cabef347babf2696300e458859","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-gpai-model-provider-compliance-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-gpai-model-provider-compliance-cycle","source":"coworkcanvas-gallery","standards":["eu-ai-act"],"teams":["ai-governance","compliance-legal"]},"name":"GPAI Model Provider Compliance Cycle","nodes":[{"data":{"description":"Put current Article 53(1)(b)/Annex XII information in the hands of every downstream provider integrating the model — or record the verified open-source exemption where that duty is lifted — consistent with the technical documentation and no broader than required on trade secrets.","instructions":"**Objective**\nPut current Article 53(1)(b)/Annex XII information in the hands of every downstream provider integrating the model — or record the verified open-source exemption where that duty is lifted — consistent with the technical documentation and no broader than required on trade secrets.\n\n**Inputs**\nThe in-scope model set for this cycle with its per-model Article 53/55 scope and Article 53(2) open-source-exemption determinations — the pre-existing subject, carried forward as the scope-register document attached to the anchor Process item from the prior instance's publish-training-content-summary package (no AI-Model item type exists to hold it).\n- The model-development record: architecture and parameter count, training and testing methodology, key design choices with rationale, optimization objectives, dataset provenance and curation notes, compute (FLOP) and training-time figures, and energy-consumption data or the basis for estimating it — from the ML engineering stack, arriving as a PBC/external upload at this step.\n- The latest evaluation results — capability benchmarks, limitations analysis, and, for systemic-risk models, adversarial-testing reports.\n- The prior cycle's documentation version of record with its change log — the document on the prior archived Workflow instance's prepare-downstream-provider-information-pack step (a prior instance on the same Process anchor).\n- The Model Documentation Form from the Code of Practice Transparency chapter, where the provider uses it.\n\nThe approved technical documentation version of record from the preceding procedure.\n- Annex XII as the content checklist; the Model Documentation Form's downstream-visible fields where the Code of Practice form is used.\n- The distribution and licensing records identifying every current downstream integrator and the channel each received the prior pack through.\n- The acceptable-use policy, the copyright-compliance record, and the training-content summary draft, for consistency triangulation.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Maintain model technical documentation”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Maintain model technical documentation: Produce and version the Article 53(1)(a) technical documentation for each in-scope model so the file handed to the AI Office or a national competent authority on request is current, complete against Annex XI, and unambiguous about which version is live.\n\n2. Assemble against Annex XI Section 1 line by line — general description (intended tasks and integration targets, acceptable-use policies, release date and distribution methods, architecture and number of parameters, input/output modalities, licence) plus the detailed elements: technical means for integration; design specifications and training process, including methodologies, key design choices with rationale and assumptions, and what the model optimizes for; data (type, provenance, curation methodology, number of data points, scope and main characteristics, selection method, and the measures used to detect unsuitable sources and identifiable biases); computational resources and training time; and energy consumption, estimated from compute where not directly known.\n3. For models designated as posing systemic risk, add Annex XI Section 2: evaluation strategies with results and the methodology for identifying limitations, adversarial-testing measures such as red-teaming, model adaptations including alignment and fine-tuning, and the system architecture showing how components integrate.\n4. Prefer the Model Documentation Form as the single container where adopted: it covers the Annex XI and Annex XII fields in one artifact with per-audience disclosure flags, keeping the AI Office and downstream views consistent by construction.\n5. Diff against the prior version of record and record every material change — a retraining run, an architecture revision, a distribution-channel change, a new evaluation result — as a dated change-log entry. \"Kept up to date\" is demonstrated by the change log, not asserted.\n6. Version and stage the file as the pending version of record under a single canonical identifier per model version, so an Article 91 information request can be answered with the current file in days rather than an assembly project. Log any content gap where source evidence was unavailable this cycle — do not paper over it.\n7. Human review: confirm the documentation matches the model actually shipped this cycle, that no material change was missed, and that gaps are acceptable or assigned, then approve it as the version of record retained for ten years after the model's placing on the market.\n\n8. Assessment scope for Prepare downstream-provider information pack: Put current Article 53(1)(b)/Annex XII information in the hands of every downstream provider integrating the model — or record the verified open-source exemption where that duty is lifted — consistent with the technical documentation and no broader than required on trade secrets.\n\n9. Build the pack against Annex XII: the general description (intended tasks and integration targets, acceptable-use policies, release date and distribution methods, interaction with external hardware or software, relevant software versions, architecture and parameter count, input/output modalities, licence) plus the integration elements — the technical means required for integration (instructions for use, infrastructure, tooling), input/output modality and maximum size such as context-window length, and information on training, testing, and validation data where applicable.\n10. Write the capability-and-limitation sections to be decision-useful for an integrator's own compliance work: supported and unsupported or discouraged use cases, known failure modes and biases, performance characteristics with the conditions they were measured under, required infrastructure and inputs, and what the integrator must add — human oversight, logging, content marking — to deploy lawfully in its own risk class.\n11. Triangulate before release: the pack, the Annex XI documentation, the copyright record, and the training summary must make consistent representations. A capability claimed here but absent from the evaluation results, or a data statement contradicting the training summary, is a defect both authorities and integrators will find.\n12. Apply the trade-secret filter deliberately: redact or generalize only what Annex XII does not require disclosed, and keep a redaction log of what was generalized and why — confidentiality protection is legitimate, but under-disclosure that leaves an integrator unable to meet its own obligations fails Article 53(1)(b). Where a model qualifies for the Article 53(2) open-source exemption (the licence permits access, use, modification, and redistribution; the weights, architecture, and usage information are public; the release is not monetized; and the model carries no systemic-risk designation), record the exemption as the reason no pack issues rather than leaving the obligation blank.\n13. Distribute the version-stamped pack to every current integrator on the distribution list and record who received which version and when. A pack update that reaches only new customers leaves the installed base non-compliant on stale information.\n\n**Record in AssureSwarm**\nAttach the documentation set and its dated change log as version-stamped documents on this step (document upload) — there is no AI-Model item type, so the step document plus the Workflow instance is the version-of-record home, not a model item.\n- Carry the documentation-version and last-reviewed stamps in the document's version header and on the Workflow instance; the scope-register document on the anchor Process item records which version is live per model (no native model-item field exists to update).\n- Create a follow-up Issue item per content gap — issue_type: observation, source: compliance_review, issue_owner, identified_date, target_remediation_date.\n\nAttach the version-stamped pack and the distribution log (who received which version and when) as documents on this step (document upload). The distribution list stays a document rather than Vendor items: the Studio Vendor type exists but models the provider's own suppliers (its upstream third parties), whereas a downstream integrator that licenses this model is the provider's customer, not a vendor to it — the semantics do not fit, and no AI-Model item type exists to hold the pack either.\n- Attach the redaction log with the Annex XII basis for each withholding.\n- Carry the pack-version stamp in the document header and on the Workflow instance; where a model qualifies for the Article 53(2) open-source exemption, record the exemption determination in the same distribution-log document in place of a pack (no native model-item field to update).\n\n**Exit criteria**\nVersion of record approved and attached with a dated change log; systemic-risk models carry Section 2 content; every content gap is an owned follow-up item; the file is retrievable by version identifier without ambiguity about which version is live. Pack complete against every applicable Annex XII element; consistency triangulation performed with discrepancies resolved; redaction log attached; every current integrator recorded as receiving the current version, or the exemption recorded in its place; human approval to distribute captured.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the Annex XII pack from the linked documentation set; `/coach-redact` applies the recorded trade-secret generalizations before the integrator copy is issued.","label":"Prepare downstream-provider information pack","performedBy":{"note":"","primitives":["coach-document-upload","coach-items-link","coach-render-package","coach-redact","coach-item-update","coach-query-data","coach-item-create"]}},"id":"prepare-downstream-provider-information-pack"},{"data":{"description":"Agent runs the reservation-of-rights opt-out check against the training pipeline and documents how the copyright policy was applied; human confirms the opt-out mechanism actually ran","formData":{"fields":[{"helperText":"Last date on which content in this delivery was collected or crawled.","key":"collection_period_end","label":"End of the collection period covered","required":true,"type":"date"},{"key":"reservations_honored","label":"Were machine-readable rights reservations honored at collection?","options":[{"label":"Yes, for all sources","value":"yes_all"},{"label":"Partially - exceptions listed below","value":"partial"},{"label":"No","value":"no"},{"label":"Unknown / not tracked","value":"unknown"}],"required":true,"type":"select"},{"helperText":"Mechanisms applied at collection: robots.txt handling, TDM Reservation Protocol, metadata opt-outs, rightsholder opt-out lists.","key":"detection_method","label":"How reservations were detected and honored","required":true,"type":"textarea"},{"key":"licence_covers_training","label":"Does the licence granted to us cover text-and-data-mining and model training?","options":[{"label":"Yes, expressly","value":"yes"},{"label":"Not express, but permitted use is broad enough","value":"implied"},{"label":"No","value":"no"},{"label":"Unclear - legal review needed","value":"unclear"}],"required":true,"type":"select"},{"key":"lawful_access_confirmed","label":"Confirms lawful access: no paywall or technical-protection circumvention, no piracy-oriented sources","required":true,"type":"checkbox"},{"helperText":"Leave blank only if none. Name the sources and the basis (for example a direct licence overriding the reservation).","key":"reserved_or_unverifiable_content","label":"Reserved or unverifiable content included, with the legal basis for retaining it","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Demonstrate that the Article 53(1)(c) copyright policy actually operated on this model version's training pipeline — rights reservations identified and honored, lawful access respected — and produce the evidence record, not just the policy document.\n\n**Inputs**\n- The training-data sourcing record for the current model version: corpora ingested, crawlers used with their configurations and crawl windows, licensed datasets with their agreements, and user and synthetic data sources — from the training pipeline, arriving as a PBC/external upload at this step.\n- The current written copyright-compliance policy with its version history — the policy document attached to the operating Control item (framework: eu-ai-act, domains: ai_governance, control_owner set) that implements this Article 53(1)(c) duty.\n- The reservation signals the pipeline claims to honor: robots.txt (Robot Exclusion Protocol) handling per crawler, TDM Reservation Protocol and metadata-based opt-outs, and any internally maintained rightsholder opt-out lists.\n- The rightsholder point-of-contact mailbox and complaints log since the last cycle — the complaints log kept as a document on the same Control item.\n- One completed supplier representation (this step's form) per third-party dataset in the training mix.\n\n**Procedure**\n1. Verify identification-and-compliance mechanically, not by assertion: pull crawler configurations and logs and confirm each crawler read and honored robots.txt disallows and machine-readable reservations expressed under Article 4(3) of Directive (EU) 2019/790 during the actual crawl window. The duty follows the market, not the data center — a model trained outside the EU must still have honored EU reservations to be placed on the EU market.\n2. Sample-test the exclusions: select opted-out domains and known reserving rightsholders and verify their content is absent from the ingested corpus (URL and hash lookups against the corpus index). A policy with no negative-evidence test is the finding an examiner writes first.\n3. Verify lawful access: no paywall or technical-protection circumvention in the crawl configurations, and piracy-oriented sources excluded — screen against the EU Counterfeit and Piracy Watch List and internal blocklists, per the Code of Practice Copyright chapter.\n4. Extend diligence to third-party data: send this step's form to each supplier's compliance contact and read the answers as evidence, not courtesy. For licensed corpora, confirm the licence covers text-and-data-mining or training use; for acquired datasets, the supplier's representation that reservations were honored at collection is the record. Chase unanswered or `unknown` responses; provenance gaps go on the exception list, not into silence.\n5. Compile the exception list — any reserved or unverifiable content retained, each with its legal basis (for example a direct licence overriding the reservation) or its remediation plan (removal from future training runs, filtering).\n6. Check the output side per the Code of Practice: memorization safeguards tested on this version (verbatim-reproduction probes against known copyrighted works) and copyright-infringing uses prohibited in the acceptable-use policy.\n7. Disposition every rightsholder inquiry in the complaints log; update the written policy if the pipeline, detection method, or exception handling changed; and record the policy version this training run operated under. This duty applies to every GPAI model — the open-source exemption never lifts it.\n\n**Record in AssureSwarm**\n- The form on this step, answered by the third-party training-data supplier's compliance contact, captures per-dataset the collection period covered, whether machine-readable reservations were honored and by what detection method, whether the licence granted covers text-and-data-mining and training, the lawful-access confirmation, any reserved or unverifiable content retained with its legal basis, — one submission per supplied dataset bound to its known name/version; attach the supplier’s supporting evidence as documents, filed as the third-party leg of the diligence record.\n- Attach the copyright-compliance evidence record — sources checked, crawler-configuration evidence, sample-test results, supplier representations, exception list with justifications, output-safeguard results, and the operative policy version — as a document on this step (document upload), and link it to the copyright Control item it evidences (Item relationship: Control ↔ anchor Process).\n- Create a remediation Issue item per unresolved exception — issue_type: exception, source: compliance_review, remediation_plan (removal from a future training run / filtering), issue_owner, target_remediation_date (the target training run).\n\n**Exit criteria** — Opt-out honoring evidenced from crawler configurations and sample tests, not policy text alone; a supplier representation on file (or an exception raised) for every third-party dataset; exception list complete with a legal basis or remediation per entry; complaints dispositioned; policy version recorded; human approval of the copyright-compliance record captured.\n\n**Form recipient** — this step's form is answered by the third-party training-data supplier's compliance contact, not by the step owner. Send it with a form assignment; the owner's own work goes in the step result.","label":"Operate copyright-compliance policy","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"operate-copyright-compliance-policy"},{"data":{"description":"Publish the Article 53(1)(d) training-content summary for this model version on the AI Office template — detailed enough for rightsholders and the public to understand what content classes trained the model, current against the actual training mix, and free of sourcing detail the template does not require.","instructions":"**Objective**\nPublish the Article 53(1)(d) training-content summary for this model version on the AI Office template — detailed enough for rightsholders and the public to understand what content classes trained the model, current against the actual training mix, and free of sourcing detail the template does not require.\n\n**Inputs**\nThe training-content inventory for the current version: sources by category, approximate scale per modality, provenance and licensing types, and the crawl records from the copyright step.\n- The AI Office training-content summary template, and the prior published summary with its publication record.\n- The approved copyright-compliance record, which feeds the data-processing section.\n\nThe cycle outputs: the confirmed per-model scope and obligation set with any open-source-exemption determinations; the technical-documentation version of record and change log; the downstream pack with its distribution log; the copyright-compliance record; the published training-content summary with its publication record; the designation memo and any Commission notifications; and, for designated models, the evaluation and adversarial-testing report, the risk-and-mitigation register with final residual ratings, the incident log with AI Office notifications or the negative confirmation, and the cybersecurity verification record.\n- The retention schedule for AI Act provider-obligation evidence — anchor on ten years after the model's placing on the market for the documentation set, and keep systemic-risk evidence at least as long as the model remains on the market plus the retention tail.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Close and archive”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Publish training-content summary: Publish the Article 53(1)(d) training-content summary for this model version on the AI Office template — detailed enough for rightsholders and the public to understand what content classes trained the model, current against the actual training mix, and free of sourcing detail the template does not require.\n\n2. Draft to the template's three parts. General information: provider identity, model identifiers and versions covered, modalities, and overall training-data size per modality in the template's broad bands. Data sources by template category: large public datasets identified by name; licensed third-party data described at the general level confidentiality allows; provider-crawled data with the crawlers used, the collection period, and the most relevant domains per the template's banding (the top 10% of all domains by scraped content volume; reduced to 5% or 1,000 domains for SMEs); user data by originating service; synthetic data with the generating models or services; and other sources. Data processing: the measures taken to respect Article 4(3) reservations and to remove illegal content, drawn directly from the copyright-compliance record.\n3. Apply the \"sufficiently detailed\" test from the rightsholder's chair: a publisher, image library, or collecting society should be able to tell whether content like theirs was plausibly in the training mix. Category-level disclosure passes; \"publicly available data\" as the whole answer does not. Withhold what the template does not require — exact dataset compositions, mixture ratios, acquisition terms.\n4. Diff against the prior published summary and carry every material composition change — a new crawl, a dropped corpus, a new synthetic-data source — so the published version describes this release, not the last one. This duty, like the copyright policy, applies to open-source-exempt models too.\n5. Cross-check the summary against the downstream pack and the technical documentation one final time: the three artifacts must tell the same data story at different resolutions.\n6. Stage publication on the provider's public channel — freely accessible without registration, stable URL, version-and-date stamped, prior versions retained — and record the publication URL and date against the model once released.\n\n7. Assessment scope for Close and archive: Close the cycle with a complete, authority-producible provider-obligation record archived under retention, cycle metrics computed, the next trigger scheduled, and every open item routed with an owner — no model in scope left without a recorded outcome for each obligation that applied to it.\n\n8. Confirm closability model by model: each in-scope model shows a recorded outcome for every obligation that applied — documentation versioned, pack distributed or exemption recorded, copyright record approved, summary published, designation decided, and for designated models the full Article 55 chain. An open thread either escalates now or becomes an explicit carry-forward; a cycle never closes around silent orphans.\n9. Assemble the cycle record from the outputs above, indexed so the AI Office or a national competent authority could navigate it unaided. The completeness test: the record alone shows what was in scope, what changed, what was found, what was mitigated, what was reported, and who decided — no oral explanation needed.\n10. Compute the cycle metrics: models covered; documentation sets and packs updated; copyright exceptions found versus remediated; summaries published; models designated; findings mitigated versus escalated; incidents reported inside versus outside the internal clock; cybersecurity gaps closed versus open. Trend against prior cycles — a rising exception rate or a late-report pattern is the systemic signal this step exists to catch.\n11. Archive the cycle record to the retention location and verify retrievability by reopening the archived copy, not by trusting the upload confirmation. Record the archive confirmation on the cycle record; post-archive corrections are new dated addenda, never edits to the archived set.\n12. Schedule the next trigger: the next planned model release, the quarterly refresh date for models remaining on the market, and any dated re-checks — exemption re-verification, compute-projection review, designation-reassessment eligibility.\n13. Route open items into the model-governance backlog with proposed owners: unresolved cybersecurity gaps, unacknowledged incident notifications, pending Commission correspondence, and copyright remediations targeting future training runs.\n14. After the disclosure approver authorizes the public summary against the completed applicable cycle record, record closure automatically.\n\n**Record in AssureSwarm**\nAttach the summary as drafted on the AI Office template, with the diff against the prior published version, as a document on this step (document upload).\n- Record the publication URL, date, and version in the document's publication-record header and on the Workflow instance, and export the publication record for the cycle file — there is no AI-Model item field to hold it; the actual publication lives on the provider's public channel and the AssureSwarm document is the evidence copy.\n\nExport the final workflow record and attach the assembled, indexed cycle record with its archive reference as a document on this step (workflow export, document upload); the archived Workflow instance on the anchor Process item is the durable audit trail.\n- Create or refresh the \"GPAI provider obligations\" dashboard with the cycle and trend metrics (dashboard).\n- Create a carry-forward Issue item per open thread — issue_owner, target_remediation_date — for open cyber gaps, pending Commission correspondence, and future-run copyright remediations; note the next trigger (next release / quarterly refresh / re-check dates) on this step, since the next run is a new Workflow instance on the same Process anchor.\n\n**Exit criteria**\nSummary complete against every template field; the sufficiency test and the trade-secret filter both documented; material changes since the prior version reflected; human approval of the disclosure-versus-protection balance captured; publication staged with the record linking this version to the model. Archived record verified retrievable with its confirmation recorded; every in-scope model shows an outcome per applicable obligation; metrics on the dashboard with trend; carry-forwards owned and dated; the next trigger scheduled; closure recorded under the disclosure approval.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the complete cycle file — documentation, packs, copyright and summary records, systemic-risk evidence — into a single indexed archive package.","label":"Publish training-content summary","performedBy":{"note":"","primitives":["coach-document-upload","coach-export-package","coach-item-update","coach-dashboard-create","coach-workflow-export","coach-render-package","coach-item-create"]}},"id":"publish-training-content-summary"},{"data":{"decisionField":"systemic_risk_status","description":"Agent checks the model against the systemic-risk criteria and drafts the designation memo; human confirms whether the model is designated as posing systemic risk for this cycle","formData":{"fields":[{"key":"systemic_risk_status","label":"Systemic-risk designation","options":[{"label":"Designated — model poses systemic risk","value":"designated"},{"label":"Not designated — systemic-risk duties do not apply","value":"not_designated"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether each in-scope model is a general-purpose AI model with systemic risk for this cycle — the determination that switches the Article 55 obligations (evaluations, risk mitigation, incident reporting, cybersecurity) on or off. The accountable owner (Head of Model Governance) decides on the designation memo.\n\n**Decision criteria**\n\nAssemble the memo before branching: the cumulative training-compute figure with its calculation basis, the Annex XIII indicator readings, any Commission or scientific-panel signals, and — if designated — which Article 55 obligations become newly in scope this cycle.\n\n- **Designated — model poses systemic risk (`designated`)** — select when any of: (1) cumulative training compute exceeds 10^25 FLOP, triggering the Article 51(2) presumption of high-impact capabilities — count compute across all capability-contributing runs (pre-training, fine-tuning, reinforcement learning, large-scale synthetic-data generation) per the Commission guidelines, and treat a credible forward projection of crossing as crossing; (2) the Commission has designated the model under Article 52, ex officio or following a scientific-panel qualified alert, regardless of compute; (3) the provider's own Annex XIII assessment finds high-impact capabilities — parameter count, dataset size, compute, modalities, benchmark performance matching the most advanced models, or reach (presumed high at 10,000 or more registered EU business users); or (4) a threshold rebuttal has been filed but not accepted — the model is treated as designated while the argument is pending, never the reverse. This branch routes into evaluations, risk assessment, incident tracking, and cybersecurity verification, and voids any open-source narrowing of the documentation duties.\n- **Not designated — systemic-risk duties do not apply (`not_designated`)** — select only when compute sits below the threshold with margin under a documented calculation, no Commission designation or qualified alert exists, and the Annex XIII indicators do not otherwise evidence high-impact capabilities. The negative determination is a recorded conclusion with evidence, not a default: keep the compute tracker live with a forward projection so a mid-cycle crossing re-triggers this decision, and note the next re-check date. The cycle proceeds to publish-training-content-summary for this model.\n\nWhichever branch is taken, check the notification duty: meeting the threshold — or learning the training plan will meet it — starts the Article 52(1) clock to notify the Commission without delay and in any event within two weeks, optionally with arguments that the model nonetheless does not present systemic risk. File or stage the notification as an owned follow-up action; a designation can be reassessed at the provider's request no earlier than six months after the decision.\n\n**Record in AssureSwarm**\n- Submit the decision form: `systemic_risk_status` (the branch), the step result citing the compute figure and calculation basis, the Annex XIII readings, or the designation instrument relied on, and the step's approver record.\n- Attach the designation memo and any Commission notification or correspondence (document upload).\n\n**Exit criteria** — Form submitted with an evidence-traceable rationale; any triggered two-week notification filed or staged with an owner and due date; the unused branch is prunable — designated models proceed to evaluations, non-designated models to close.","kind":"decision","label":"Determine systemic-risk designation","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"determine-systemic-risk-designation"},{"data":{"decisionField":"risk_mitigation_status","description":"Turn the evaluation findings into the Article 55(1)(b) systemic-risk assessment and decide whether residual risk after the proposed mitigations sits within the pre-committed acceptance criteria — continue the cycle — or must be strengthened first. The accountable owner decides on the risk-and-mitigation register.","formData":{"fields":[{"key":"risk_mitigation_status","label":"Systemic-risk mitigation disposition","options":[{"label":"Acceptable — residual risk within tolerance","value":"acceptable"},{"label":"Escalate — strengthen mitigations before proceeding","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nTurn the evaluation findings into the Article 55(1)(b) systemic-risk assessment and decide whether residual risk after the proposed mitigations sits within the pre-committed acceptance criteria — continue the cycle — or must be strengthened first. The accountable owner decides on the risk-and-mitigation register.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe designation memo and the systemic-risk taxonomy in force from the provider's safety and security framework: at minimum CBRN enablement, offensive-cyber capability, controllability and loss-of-control indicators, and harmful manipulation at scale, mapped to the Act's categories — public health and safety, fundamental rights, society and democratic processes, critical infrastructure.\n- The prior cycle's evaluation report and capability baselines, for jump detection.\n- The versioned evaluation harness: benchmark suites, elicitation tooling, red-team protocols, and access to the exact model checkpoint and deployment configuration being released.\n\n*Agent retrieval, preparation and filing absorb “Run model evaluations and adversarial testing”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Run model evaluations and adversarial testing: Execute Article 55(1)(a): state-of-the-art model evaluations of the designated model, including conducted and documented adversarial testing, producing findings strong enough to carry the systemic-risk assessment that follows.\n\n2. Select protocols per risk domain reflecting the current state of the art and record why each was chosen: dangerous-capability benchmarks for CBRN uplift, offensive-cyber suites (vulnerability discovery and exploitation tasks), autonomy and self-proliferation task batteries, persuasion and manipulation measures, and safeguard-robustness (jailbreak-resistance) tests. Freeze the harness version, model checkpoint, and decoding parameters so every result is reproducible.\n3. Evaluate at the capability ceiling, not the shipped surface: apply strong elicitation — fine-tuning where feasible, tool and scaffold access, best-of-n sampling — because the obligation concerns what the model can do; a safety-trained refusal is a mitigation, not an absent capability.\n4. Conduct structured adversarial testing: red-team campaigns per risk domain designed to elicit harmful, deceptive, or otherwise unsafe behavior, with documented protocols, the prompts and attack strategies used, domain-expert testers for CBRN content, and both mitigated and less-mitigated configurations where policy allows. Record every finding regardless of severity, including nulls — negative results are evidence too.\n5. Rate each finding's severity and novelty. Flag any capability the prior cycle's testing did not surface, and any benchmark score that jumps past the prior baseline by more than the harness's known run-to-run variance — capability jumps are the primary signal the risk assessment needs.\n6. Compile the report: methodology, a coverage matrix of risk domain against protocol with gaps stated as gaps, findings with severity and elicitation level, and reproducibility parameters. Map each material finding to the systemic-risk categories it touches so the following procedure builds directly on this evidence.\n7. Human review: judge methodology adequacy against the state of the art, confirm coverage skipped no material capability (an untested in-taxonomy domain is a finding, not an omission), and approve the findings as the risk-assessment basis. For models materially beyond the current frontier, record whether independent external evaluation was obtained or why not, per the Code of Practice Safety and Security chapter.\n\n8. Assessment scope for Assess and decide systemic-risk mitigation: Turn the evaluation findings into the Article 55(1)(b) systemic-risk assessment and decide whether residual risk after the proposed mitigations sits within the pre-committed acceptance criteria — continue the cycle — or must be strengthened first. The accountable owner decides on the risk-and-mitigation register.\n\n\n\nBuild the register before deciding: each material finding traced to its source — model capability, training data, deployment context, or reasonably foreseeable misuse — and assessed at Union level across the public-health-and-safety, fundamental-rights, societal-and-democratic-process, and critical-infrastructure categories; a proposed mitigation per risk (safety training, classifier filters and refusals, capability or access restrictions, deployment conditions, use restrictions, monitoring commitments); and a residual-risk rating per entry with an implementation owner. Rate residuals against the acceptance criteria the safety and security framework fixed before results existed — moving the acceptance bar after seeing findings is outcome-shopping and invalidates the assessment. The register's summary carries the drafted recommendation for the decision-maker.\n\n- **Acceptable — residual risk within tolerance (`acceptable`)** — every register entry's residual rating sits within the pre-committed criteria; no highest-severity finding lacks an implemented or scheduled mitigation with an owner and date; safeguard-robustness results support the effectiveness assumed of each mitigation (a jailbreak that defeats the refusal layer means that mitigation contributes nothing to residual risk); and no material capability jump remains unexplained. The cycle proceeds directly to serious-incident tracking with the register as the monitoring baseline.\n- **Escalate — strengthen mitigations before proceeding (`escalate`)** — any residual rating exceeds the acceptance criteria; a finding evidences a novel capability with no established mitigation; a mitigation's effectiveness is asserted but untested; or the evidence is too weak to support acceptance — under uncertainty about a severe risk, escalation is the default, not the exception. Scope the escalation precisely: list exactly which register entries route to strengthening so that step treats and re-tests those, not everything. The cycle rejoins at incident tracking once strengthening clears.\n\n**Record in AssureSwarm**\nAttach the evaluation and adversarial-testing report with the coverage matrix, harness version, checkpoint identifier, and elicitation levels as a document on this step (document upload).\n- Link each material finding to the systemic-risk register Risk item (category: ai_governance, taxonomies: ai_governance) it evidences (Item relationship: finding ↔ Risk).\n\nSubmit the decision form: `risk_mitigation_status` (the branch), the step result citing the specific register entries and evaluation findings relied on, and the step's approver record.\n- Create the risk-and-mitigation register as Risk items — one per finding, with category: ai_governance, taxonomies: ai_governance, likelihood, impact, inherent_rating, residual_rating, treatment: mitigate, risk_owner — linked to the evaluation-report findings they treat (Item relationship: Risk ↔ finding).\n\n**Exit criteria**\nReport attached with a complete coverage matrix; every finding severity-rated and category-mapped; capability jumps versus the prior baseline explicitly assessed; methodology approved as state-of-the-art; reproducibility parameters recorded. Form submitted with a rationale traceable to register entries; register complete — every material finding has a mitigation, an owner, and a residual rating; on escalation the routed-entry list is explicit; the unused branch is prunable.","kind":"decision","label":"Assess and decide systemic-risk mitigation","performedBy":{"note":"","primitives":["coach-query-data","coach-items-link","coach-item-create","coach-document-upload"]}},"id":"evaluate-systemic-risk-mitigation"},{"data":{"description":"Agent implements the additional mitigations the risk assessment called for and re-tests until residual risk is acceptable; human confirms the model is cleared to rejoin the mainline cycle","instructions":"**Objective** — Bring every escalated register entry's residual risk within the pre-committed acceptance criteria through additional mitigation and verified re-testing — or escalate what cannot reach tolerance to a release decision — while no elevated-risk configuration ships in the interim.\n\n**Inputs**\n- The escalated register entries with the reviewer's reasons: which criterion each failed and what strengthening was called for.\n- The evaluation harness and methodology from the evaluations step, unchanged, so re-test results are comparable.\n- The model's current deployment configuration and access-control settings.\n\n**Procedure**\n1. Freeze the interim state first: hold the model's systemic-risk-relevant deployment settings at their most restrictive viable configuration — tightened rate limits, narrowed access tiers, disabled high-risk tool integrations — and record the hold, so no elevated-risk configuration is placed on the market while strengthening runs.\n2. Implement the called-for treatment per entry: additional safety training or targeted fine-tuning against the failing behavior, stronger input and output classifiers, capability or context restrictions, narrowed access, tightened deployment conditions or acceptable-use enforcement, staged-rollout gates, or enhanced monitoring with defined tripwires. Where the gap is exfiltration- or access-control-related, route it to the cybersecurity step's remediation owner rather than duplicating treatment here.\n3. Re-test each strengthened entry under the same methodology, harness version, and elicitation strength as the original assessment — a re-test under weaker elicitation proves nothing. Include a targeted red-team round against the specific failing finding, not just the benchmark re-run.\n4. Re-rate residual risk per entry against the unchanged acceptance criteria. An entry that still fails iterates — further treatment, further re-test — or escalates to a release decision above this workflow (delay, restrict, or do not ship the configuration); it never closes by re-scoring alone.\n5. Update the register per entry with the treatment applied, the re-test evidence, the new residual rating, and the verification date, keeping the original failed rating visible in the history.\n6. Human checkpoint: confirm every escalated entry now sits within tolerance with re-test evidence or carries an explicit release-decision escalation, verify from the deployment-configuration change log that the interim hold held for the full window, and clear the model to rejoin the cycle at incident tracking.\n\n**Record in AssureSwarm**\n- Update each escalated register Risk item's residual_rating and treatment (Risk.residual_rating, Risk.treatment) with the strengthening applied; record the re-test result and verification date in the attached re-test evidence (no native Risk field holds them).\n- Attach the re-test evidence and the interim-hold record as documents on this step (document upload).\n- Create an escalation Issue item for any entry that cannot reach tolerance — issue_type: exception, severity, issue_owner, target_remediation_date — routed to the release-decision owner.\n\n**Exit criteria** — Every escalated entry shows re-test evidence under the original methodology and a residual rating within the acceptance criteria, or an explicit owned release-decision escalation; the interim hold is evidenced for the full strengthening window; clearance to rejoin at incident tracking recorded.","label":"Strengthen risk mitigations","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-item-update"]}},"id":"strengthen-risk-mitigations"},{"data":{"description":"Agent compiles the serious-incident log for the period and drafts the AI Office notification for any reportable incident; human confirms completeness before dispatch or records a documented no-incidents result","instructions":"**Objective** — Close the Article 55(1)(c) loop for the period: a complete serious-incident log for the designated model, an AI Office notification with corrective measures for every reportable incident, and an explicit negative confirmation when there were none.\n\n**Inputs**\n- The incident intake channels for the period: deployer and downstream-provider reports, trust-and-safety escalations, abuse-monitoring alerts, security-operations tickets, researcher and media reports, and the external point-of-contact mailbox.\n- The Act's serious-incident definition as the log's inclusion test.\n- The risk-and-mitigation register, for linking incidents to the risks they manifest.\n- Prior notifications and any open AI Office correspondence awaiting follow-up.\n\n**Procedure**\n1. Sweep every intake channel for the covered period and screen candidates against the definition: an incident or malfunctioning that directly or indirectly led to the death of a person or serious harm to a person's health, a serious and irreversible disruption of the management or operation of critical infrastructure, an infringement of Union-law obligations protecting fundamental rights, or serious harm to property or the environment. \"Indirectly led to\" pulls in downstream-system incidents where the model's behavior was a contributing cause — do not screen those out because a deployer sat in between; record the causal chain instead.\n2. For each in-scope incident, compile the notification: what happened and when it was detected, the affected deployments and systems, the suspected causal mechanism in the model, interim containment, and corrective measures taken or planned. The statutory clock is \"without undue delay\"; absent a GPAI-specific deadline, run the internal clock to the Act's Article 73 tiers as the outer bound — on the order of two days for a critical-infrastructure disruption, ten days for a death, fifteen days otherwise — and never hold a report for root-cause completeness: file the initial report and follow up.\n3. Determine recipients: the AI Office always; national competent authorities as appropriate, including the member states where the harm occurred.\n4. Where the sweep returns nothing, draft the explicit negative confirmation naming the channels swept and the period covered, so the record shows the check operated rather than was skipped.\n5. Feed the register: link each incident to the systemic risk it manifests, and flag any incident showing a risk rated acceptable this cycle behaving worse than assessed — that flag reopens the risk assessment next cycle, or immediately if severe.\n6. Human checkpoint: confirm log completeness against all channels, review each notification for accuracy and clock compliance before it is dispatched to the AI Office, and confirm the no-incidents record where applicable.\n\n**Record in AssureSwarm**\n- Create an Issue item per serious incident — issue_type: exception, severity, identified_date (detection date), description carrying the causal chain and classification, target_remediation_date for the reporting clock — the honest fallback: the catalog has no Incident item type and Issue.source has no incident option, so the exception issue_type is approximate and the incident classification lives in the description.\n- Attach each AI Office notification as dispatched, or the explicit no-incidents negative confirmation, as documents on this step (document upload) — dispatch itself happens on the AI Office channel and the attached copy is the evidence.\n- Link each incident Issue to the register Risk item(s) it manifests and to its corrective-measure Issue items (Item relationship: Issue ↔ Risk, Issue ↔ Issue).\n\n**Exit criteria** — Every intake channel evidenced as swept; every logged incident either notified within the internal clock with corrective measures or documented as below the seriousness threshold with reasons; the negative confirmation on file when none occurred; register links in place.","label":"Track and report serious incidents","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-items-link"]}},"id":"track-and-report-serious-incidents"},{"data":{"description":"Agent reviews the cybersecurity assessment of the model and its infrastructure and confirms protections remain adequate; human clears the model or flags gaps for remediation","instructions":"**Objective** — Verify Article 55(1)(d): the designated model and its physical infrastructure carry cybersecurity protection adequate to the state of the art — with unreleased model weights as the crown jewel — and either clear the model or route every open gap to owned remediation before the cycle closes.\n\n**Inputs**\n- The current cybersecurity assessment of the model and its physical and digital infrastructure, with its date and scope.\n- This cycle's adversarial-testing findings — any weakness the red team exploited that implies an infrastructure or access-control gap.\n- Compute- and hosting-provider attestations: SOC 2 or ISO/IEC 27001 reports, data-center physical-security assessments, and supply-chain controls.\n- The access-control state for model weights: who and what can read, copy, or export them.\n\n**Procedure**\n1. Test the weights-protection core: unreleased weights held in access-controlled environments with need-to-know allowlists and multi-factor authentication; no standing bulk-export path; egress monitoring tuned to weight-scale transfers; and every copy inventoried — training, serving, backup, researcher snapshots — because an unaccounted copy is a finding regardless of the controls on the accounted ones. Benchmark the posture against a recognized scale such as the RAND securing-model-weights security levels and record the level claimed versus the level evidenced.\n2. Verify insider-threat and interface hardening: separation of duties on weight access, privileged sessions logged and alerting, and serving-interface resistance to model-extraction and distillation attacks and to adversarial inputs — rate limits and logit-exposure limits proportionate to the model's capability.\n3. Check training- and serving-time integrity: data supply-chain controls against poisoning (dataset hashes, provenance verification, curation-pipeline access control) and deployment-pipeline integrity from checkpoint to serving (signed builds, change control).\n4. Reconcile against this cycle's red-team findings: every adversarial finding with a security dimension — an extraction success, a jailbreak that exposed a monitoring blind spot — must map to an existing safeguard or become a new gap; unmapped findings are gaps by definition.\n5. Confirm physical-infrastructure coverage: a current attestation for every data center that trains or serves the model, plus hardware-security and supply-chain controls for compute providers. An expired or absent attestation is a gap in your record, not the provider's.\n6. Compile the verification record — assessment date and scope, posture versus the state of the art, findings, and a remediation owner and date per open gap — and have the human clear the model or route each gap to tracked remediation before the cycle closes.\n\n**Record in AssureSwarm**\n- Attach the cybersecurity verification record and the provider attestations as documents on this step (document upload).\n- Create a remediation Issue item per open gap — issue_type: observation, source: self_assessment, severity, issue_owner, target_remediation_date.\n- Link the verification record to the risk-and-mitigation register Risk items it supports (Item relationship: document ↔ Risk).\n\n**Exit criteria** — Verification record attached covering weights protection, insider threat, interfaces, training- and serving-time integrity, and physical infrastructure; every red-team security finding mapped; every open gap an owned remediation item with a date; the human clearance or gap-routing decision recorded.","label":"Verify cybersecurity protection","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"verify-cybersecurity-protection"}],"sourceTemplateId":"workflow-library:reg-gpai-model-provider-compliance-cycle"}