{"description":"Each monthly instance runs against the existing Control item for AI operations monitoring and incident response (framework eu-ai-act + iso-42001; domains ai_governance / logging_monitoring_detection / incident_management_response; frequency monthly; control_owner AI Operations Manager) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate. The decision-aware cycle covers event-logging and retention verification, alert resolution, human-oversight confirmation, AI-use screening against legal prohibitions, and AI concern-and-incident triage through required communications and regulator reporting, consolidating all five streams into a named cycle report and cycle dashboard while every residual gap is booked as an Issue (source: management_identified) linked to the anchor Control. In scope: every deployed production, limited-risk, and high-risk AI system under the EU AI Act, its event-log sources and monitoring dashboards, the human-oversight roster, the AI use inventory, and the AI concern-reporting channels. Out of scope: pre-deployment model development and conformity assessment, and third-party/vendor AI due diligence, which are governed by their own workflows. This cycle consumes no upstream workflow handoff; it hands off only to the next monthly run of itself, seeding it with the open carry-forward Issues (corrective actions, in-flight blocks, incident follow-ups) that the cycle-metrics-and-report step links to the anchor Control so next month can query them as its prior-cycle input.","edges":[{"id":"e-screen-ai-use-against-policy-block-and-notify-prohibited-uses","label":"Blocks required","source":"screen-ai-use-against-policy","target":"block-and-notify-prohibited-uses","whenValue":"blocks_or_discontinuations_required"},{"id":"e-screen-ai-use-against-policy-compile-cycle-metrics-and-report","label":"Cleared","source":"screen-ai-use-against-policy","target":"compile-cycle-metrics-and-report","whenValue":"all_uses_cleared"},{"id":"e-block-and-notify-prohibited-uses-compile-cycle-metrics-and-report","source":"block-and-notify-prohibited-uses","target":"compile-cycle-metrics-and-report"},{"id":"e-triage-ai-concern-and-incident-reports-execute-incident-communications-and-regulator-reporting","label":"Incident","source":"triage-ai-concern-and-incident-reports","target":"execute-incident-communications-and-regulator-reporting","whenValue":"incident_confirmed"},{"id":"e-triage-ai-concern-and-incident-reports-compile-cycle-metrics-and-report","label":"No incident","source":"triage-ai-concern-and-incident-reports","target":"compile-cycle-metrics-and-report","whenValue":"no_incident_confirmed"},{"id":"e-execute-incident-communications-and-regulator-reporting-compile-cycle-metrics-and-report","source":"execute-incident-communications-and-regulator-reporting","target":"compile-cycle-metrics-and-report"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-08","UC-AI-16","UC-AI-12","UC-AI-11"],"department":"ai-governance","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-ai-operations-monitoring-incident-response","contentDigest":"sha256:b67b3ae208b8909971dcc618da590b99838d3fe95a94a69d43f8f9e802e71adb","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b67b3ae208b8909971dcc618da590b99838d3fe95a94a69d43f8f9e802e71adb","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-ai-operations-monitoring-incident-response"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-ai-operations-monitoring-incident-response","source":"coworkcanvas-gallery","standards":["iso-42001","eu-ai-act","aiuc-1"],"teams":["ai-governance","it"]},"name":"AI Operations Monitoring & Incident Response","nodes":[{"data":{"decisionField":"use_screening_disposition","description":"Agent screens proposed and existing AI uses against intended use and legal prohibitions and retains approvals; human decides whether any use must be blocked","formData":{"fields":[{"key":"use_screening_disposition","label":"Use Screening Disposition","options":[{"label":"All uses cleared","value":"all_uses_cleared"},{"label":"Blocks or discontinuations required","value":"blocks_or_discontinuations_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether any proposed or existing AI use must be blocked or discontinued, after screening every use against its intended use, accompanying documentation, and the EU AI Act Article 5 prohibited practices. Owned by the AI Operations Manager.\n\n**Decision criteria**\n- Select `all_uses_cleared` when every screened use matches its intended-use statement and accompanying documentation and shows no prohibited-practice indicator.\n- Select `blocks_or_discontinuations_required` when at least one use mismatches its intended use or triggers a prohibited-practice indicator — manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, untargeted facial-image scraping, or any other EU AI Act Article 5 prohibition — and must therefore be blocked or discontinued.\n\n**Agent procedure** (produces the screening summary this decision reads)\n1. Query the AI use inventory and this cycle's newly proposed uses (coach-query-data), joining each use to its intended-use statement and accompanying documentation. The inventory is external (no native AI Use item type), so the joined result is retained as this step's evidence.\n2. Screen every proposed and existing use against the responsible-use Policy item (an existing Policy in the library — policy_type: policy, framework eu-ai-act, domains ai_governance — referenced here, not created) and the EU AI Act Article 5 prohibited practices, flagging any mismatch with intended use or any prohibited-practice indicator.\n3. For every use that passes screening, record its approval and screening result as a row in the screening summary — reporter/use, intended-use match, prohibited-practice check, and disposition — so the retained evidence exists regardless of the cycle's overall outcome (there is no native AI Use item to hang a per-use approval on, so this stays a document row on this step).\n4. Draft the screening summary listing every use screened, its disposition, and its evidence reference, and attach it (coach-document-upload).\n\n**Record in AssureSwarm**\n- Step form — submit `use_screening_disposition` (SELECT); record the step result with evidence references and the step's approver record (decision owner or approver).\n- Step document — the screening summary (coach-document-upload), with per-use approval and screening records captured as rows in this document (no native AI Use item type to hold per-use approval items).\n\n**Exit criteria** — The screening form is submitted with rationale and owner and the unused branch is prunable. `all_uses_cleared` proceeds straight to the cycle-metrics consolidation; `blocks_or_discontinuations_required` routes through the block-and-notify step first.","kind":"decision","label":"Screen AI use against policy","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload"]}},"id":"screen-ai-use-against-policy"},{"data":{"description":"Agent blocks or discontinues every flagged use and notifies its owner and governance; human verifies the block took effect in production","instructions":"**Objective** — Block or discontinue every flagged AI use and notify its owner and the AI governance body so a prohibited or out-of-scope practice stops without delay.\n\n**Inputs**\n- The screening summary from the AI-use screening decision, listing every flagged use with the specific prohibition or intended-use mismatch it triggered.\n- The use inventory entries and their owners.\n- The AI governance body's notification channel.\n\n**Procedure**\n1. Parse the screening summary to list every flagged use with the specific EU AI Act Article 5 prohibition or intended-use mismatch it triggered.\n2. Create an Issue for each flagged use (coach-item-create) — issue_type: exception, severity: critical, source: management_identified, description naming the specific EU AI Act Article 5 prohibition or intended-use mismatch triggered, identified_date set to the immediate block effective date — and link it to the anchor Control (coach-items-link), cross-referencing the screening summary.\n3. Notify the use owner and the AI governance body of the block, including the triggering reason and any remediation path back to an approved use.\n4. Verify the block took technical effect in production — access revoked, feature disabled, or model endpoint disabled — not merely ticketed, and record the confirmation.\n5. Attach the block-and-notification log and the retained screening records (coach-document-upload).\n\n**Record in AssureSwarm**\n- Item create — one Issue per flagged use (coach-item-create): issue_type: exception, severity: critical, source: management_identified, identified_date = block effective date, description = the Article 5 prohibition or intended-use mismatch.\n- Item relationship — each block Issue linked to the anchor Control (coach-items-link) and cross-referenced to the screening summary.\n- Step document — the block-and-notification log recording owner + governance notification and the verified production block (coach-document-upload).\n\n**Exit criteria** — Every flagged use is actually blocked or discontinued in production; the owner and governance body are notified; the block-and-notification log is attached. Feeds the cycle-metrics consolidation.","label":"Block and notify prohibited uses","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"block-and-notify-prohibited-uses"},{"data":{"decisionField":"concern_triage_disposition","description":"Agent sweeps the AI concern channels, logs and triages every report; human decides whether a genuine incident is confirmed","formData":{"fields":[{"key":"concern_triage_disposition","label":"Concern Triage Disposition","options":[{"label":"No incident confirmed","value":"no_incident_confirmed"},{"label":"AI incident confirmed","value":"incident_confirmed"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether any report to the AI concern channels is a genuine AI incident, after capturing, triaging, and documenting follow-up for every report. Owned by the AI Operations Manager.\n\n**Decision criteria**\n- Select `no_incident_confirmed` when every report this sweep was advisory, a duplicate, or resolved as a non-issue with documented follow-up, and none constitutes a genuine AI incident.\n- Select `incident_confirmed` when at least one report is a genuine AI incident — for example harm or a rights impact, a safety issue or serious malfunction, or an otherwise reportable event — requiring formal communication and possibly regulator reporting.\n\n**Agent procedure** (produces the triage log this decision reads)\n1. Sweep the AI concern-reporting channels (coach-query-data) for every new report since the last sweep, timestamp each, and deduplicate reports describing the same concern.\n2. Create an Issue for each report (coach-item-create) — issue_type: observation, source: management_identified, description capturing reporter, channel, the AI system concerned, and a preliminary severity flag — and link it to the anchor Control (coach-items-link); the concerned AI system is named in the description, since there is no native AI System item to link to.\n3. Triage each report and document the follow-up taken — advisory guidance issued, closed as a non-issue, or escalated as a genuine AI incident (an escalated intake Issue is raised to issue_type: finding at the incident step) — confirming no report is left unactioned.\n4. Draft the triage log and attach it (coach-document-upload).\n\n**Record in AssureSwarm**\n- Step form — submit `concern_triage_disposition` (SELECT); record the step result with evidence references and the step's approver record (decision owner or approver).\n- Item create — one Issue per concern report (coach-item-create): issue_type: observation, source: management_identified, description = reporter / channel / system / preliminary severity.\n- Item relationship — each intake Issue linked to the anchor Control (coach-items-link); the concerned system is named in the description (no native AI System item).\n- Step document — the triage log (coach-document-upload).\n\n**Exit criteria** — The triage form is submitted with rationale and owner and the unused branch is prunable. `no_incident_confirmed` proceeds to the cycle-metrics consolidation; `incident_confirmed` routes through incident communications and regulator reporting first.","kind":"decision","label":"Triage AI concern and incident reports","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"triage-ai-concern-and-incident-reports"},{"data":{"description":"Agent drafts and tracks required incident communications and regulator reports to their mandated deadlines; human confirms every notification and filing landed on time","instructions":"**Objective** — Execute the required incident communications to affected users and interested parties and any mandated regulator or external report within its deadline, and retain the resolution record.\n\n**Inputs**\n- The confirmed incident intake record(s) from the concern-triage decision.\n- The incident facts, the affected users and interested parties, and the applicable notification and regulator-reporting obligations with their mandated deadlines.\n- Communication templates and the correct external body / regulator addressing.\n\n**Procedure**\n1. Compile the incident facts, the affected users and interested parties, and the applicable notification and regulator-reporting obligations with their mandated deadlines (coach-query-data).\n2. Draft the incident communication to affected users and interested parties and, where a regulator report is required, draft the report package addressed to the correct external body (coach-document-upload).\n3. Track every communication and report against its mandated deadline (coach-workflow-scan), and create an Issue (coach-item-create) for any at risk of breaching its deadline — issue_type: exception, severity: high, source: management_identified, target_remediation_date = the mandated deadline — linked to the confirmed-incident Issue, and escalate it.\n4. Confirm each communication was sent and each mandated report filed; capture the timestamps. On confirmed resolution, update the confirmed-incident intake Issue (coach-item-update): raise issue_type to finding and set actual_remediation_date and verified_date.\n5. Compile the resolution record — incident facts, communications sent, reports filed, and timestamps — and attach it (coach-document-upload).\n\n**Record in AssureSwarm**\n- Item create — one Issue per at-risk communication/filing (coach-item-create): issue_type: exception, severity: high, source: management_identified, target_remediation_date = mandated deadline; deadline tracking runs via coach-workflow-scan.\n- Item relationship — each at-risk Issue linked to the confirmed-incident Issue.\n- Item field update — on the confirmed-incident intake Issue (coach-item-update): issue_type raised to finding, actual_remediation_date and verified_date set on resolution.\n- Step document — incident communication drafts, the regulator report package, and the resolution record (coach-document-upload); the actual sending/filing happens in external systems, so these are the retained evidence copies.\n\n**Exit criteria** — Every affected user and interested party is notified; every mandated regulator report is filed within its timeframe or an at-risk breach is escalated; the resolution record is complete and attached. Feeds the cycle-metrics consolidation.","label":"Execute incident communications and regulator reporting","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-item-update","coach-workflow-scan","coach-document-upload"]}},"id":"execute-incident-communications-and-regulator-reporting"},{"data":{"description":"Judge logging integrity, sustained model drift and oversight capability together, then approve the cycle result and the severity, ownership and dates of its residual gaps.","instructions":"**Objective** — Judge logging integrity, sustained model drift and oversight capability together, then approve the cycle result and the severity, ownership and dates of its residual gaps.\n\n**Inputs**\n- The anchor Control item (the AI operations monitoring & incident-response control, framework eu-ai-act + iso-42001) this monthly instance runs against — plus the governing Control items UC-AI-08/UC-AI-16/UC-AI-12/UC-AI-11 that encode the EU AI Act Article 12 logging obligation.\n- The AI system inventory / model register: every in-scope production, limited-risk, and high-risk system under the EU AI Act, with its logging pipeline and log-store identifiers — queried live from the external model registry (coach-query-data); no native item type exists for AI systems, so the query results are retained on this step as the point-in-time evidence copy.\n- Each system's configured log-retention setting, the applicable regulatory minimum (EU AI Act Article 12), and any longer internal-policy or contractual period.\n- The change register's recorded risk situations and substantial-modification events (retraining, redeployment, configuration change) for the period — sampled from the external change-management system (no native Change item type; the sampled evidence lives in the logging-integrity memo).\n- The prior-cycle logging-integrity memo and any carried-forward logging gap that arrived as an input to this cycle — the latter as an open Issue that the prior instance's cycle-metrics consolidation linked to the anchor Control at closure.\n- The monitoring platform's alert feed: every performance, anomaly, and drift alert raised since the last cycle, per system, with each system's defined metrics and thresholds.\n- Each alert's response-time target / SLA.\n- The system inventory, to attribute each alert to an accountable engineer or model owner.\n- Any prior-cycle open or aging alerts that arrived as inputs to this cycle.\n- The anchor Control item this instance runs against, and the governing Control UC-AI-12 encoding the EU AI Act Article 14 human-oversight obligation.\n- The oversight-assignment roster: the named overseer per in-scope system, plus their training and capability evidence — queried from external / HR records (no native Person or Roster item type; the roster snapshot becomes evidence inside the oversight-adequacy memo).\n- Each system's capacities-and-limitations documentation and its human-machine-interface / oversight-measure configuration.\n- Current automation-bias-awareness materials.\n- The period's intervention log: every override, halt, or decide-not-to-use event, with the alert or concern report that triggered it where one exists.\n- The logging-integrity memo (logging and retention verification).\n- The monitoring review and dashboard (alert resolution).\n- The oversight-adequacy memo (oversight staffing and interventions).\n- The use-screening summary and any block-and-notification log.\n- The concern-triage log and any incident resolution record.\n- Each metric's threshold and the prior-cycle values for trending.\n- Open corrective actions, in-flight blocks or discontinuations, and open incident follow-ups from this cycle.\n- The designated evidence repository and its retention controls, and the control execution log.\n\n**Procedure**\n_This checkpoint absorbs “Verify event logging and retention”, “Resolve monitoring alerts and drift”, “Confirm oversight staffing and interventions”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Verify event logging and retention: For each in-scope system, query its logging pipeline (coach-query-data) to confirm automatic event logs are being generated; capture the last-log timestamp and log-volume trend, and flag any silent or gapped system where the last log predates the period or volume dropped anomalously.\n2. Verify the configured retention period for every log store against the regulatory minimum — at least six months under EU AI Act Article 12, or a longer period where internal policy or contract requires it — and flag any system under-retaining.\n3. Sample recent logs against the change register's known risk situations and substantial-modification events to confirm the logs actually capture traceability of operation (inputs, decisions, overrides, model version), not merely uptime or health signals. A system that logs \"up\" but not what it did fails this check.\n4. For every gap (silent system, short retention, uptime-only logging), record the specific defect and assign a named remediation owner and target date.\n5. Draft the logging-integrity memo listing each system, its logging status, retention setting, sampled-traceability result, and any gap with its remediation owner, and attach it (coach-document-upload).\n6. Resolve monitoring alerts and drift: Query the monitoring platform (coach-query-data) to pull every performance, anomaly, and drift alert raised since the last cycle against each system's defined metrics and thresholds.\n7. Classify each alert as resolved, in progress, or unactioned. For every unactioned or aging alert, create an Issue (coach-item-create) — issue_type: exception, severity matching the alert, source: management_identified, target_remediation_date set to the alert's response-time SLA — and link it to the anchor Control (coach-items-link); the originating system and alert id are named in the Issue description, since no native AI System or alert item type exists to link to.\n8. Compile the escalation list for alerts that breached their response-time target; draft the escalation naming the accountable engineer or model owner for each.\n9. Distinguish transient alerts from sustained drift: an isolated threshold blip that self-recovered is noted and closed, whereas a sustained metric trend (accuracy or quality declining across consecutive windows, or input-distribution drift) is treated as degradation requiring an owned remediation, not a close.\n10. Build the monitoring dashboard (coach-dashboard-create) showing alert volume, closure rate, and open aging alerts by system, and attach the monitoring review (coach-document-upload).\n11. Confirm oversight staffing and interventions: Query the oversight-assignment roster (coach-query-data) for every in-scope system, capturing the named overseer and their training and capability evidence, and confirm the human-machine-interface tools and built-in oversight measures are functioning.\n12. Cross-reference each named overseer against the system's capacities-and-limitations documentation to confirm they have the material to monitor operation and correctly interpret output (EU AI Act Article 14); flag any unassigned, under-qualified, or stale-trained system.\n13. Confirm automation-bias-awareness materials are current, so overseers are equipped not to over-trust system output.\n14. Pull the period's intervention log (coach-query-data) — every override, halt, or decide-not-to-use event — and link each intervention to the monitoring alert or concern report that triggered it where one exists (coach-items-link).\n15. Draft the oversight-adequacy memo covering staffing gaps and intervention-record completeness, and attach it (coach-document-upload).\n16. Compile cycle metrics and report: Compute the cycle metrics (coach-query-data): logging and retention compliance rate; alert closure rate; oversight staffing completeness and interventions reviewed; use-screening completion and blocked-use count; concern-report acknowledgment and triage timeliness; incident-communication and regulator-reporting timeliness.\n17. Build the cycle dashboard (coach-dashboard-create) showing each metric against its threshold and the trend against prior cycles.\n18. Create a corrective-action Issue (coach-item-create) for any metric outside tolerance or any open item carried from an earlier step this cycle — issue_type: deficiency, source: management_identified, issue_owner, target_remediation_date — and link it to its source Issue and to the anchor Control (coach-items-link).\n19. Draft the cycle report summarizing logging, monitoring, oversight, screening, and concern-and-incident results, and attach it (coach-document-upload).\n20. The AI Operations Manager reviews the report and dashboard and approves the cycle result, judging whether every residual gap is owned at a defensible severity and date. That approval is the cycle's closure.\n21. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n22. Confirm every open Issue from this cycle — corrective actions, in-flight blocks or discontinuations, and open incident follow-ups — is linked to the anchor Control so it arrives as an explicit input to the next cycle; create any not-yet-tracked carry-forward Issue and link it to its source and the anchor Control. Do not re-create Issues already booked earlier this cycle.\n23. Update the control execution log with the cycle result and key metrics, and confirm the next monthly review is scheduled.\n24. Attach the closure record.\n\n**Record in AssureSwarm**\n- Step document — the logging-integrity memo (DOCX/PDF) attached to this step (coach-document-upload), each gap listed with its named remediation owner and target date inline.\n- Step evidence — the per-system logging and retention query results captured via coach-query-data, retained on this step as the memo's supporting evidence (there is no native AI System item to update, so this stays document-and-query evidence on the step).\n- Each residual logging gap is carried into the cycle-metrics consolidation, which books it as an owned corrective-action Issue (source: management_identified) linked to the anchor Control.\n- Item create — one Issue per open or aging alert (coach-item-create): issue_type: exception, severity per alert, source: management_identified, target_remediation_date = the alert's SLA.\n- Item relationship — each such Issue linked to the anchor Control (coach-items-link); the source system and alert id are named in the Issue description (no native AI System item to link to).\n- Dashboard — the monitoring dashboard: alert volume, closure rate, open aging alerts by system (coach-dashboard-create).\n- Step document — the monitoring review (coach-document-upload).\n- Item relationship — each intervention linked to its triggering alert or concern Issue (coach-items-link), where both already exist as Issue items in AssureSwarm; interventions with no such counterpart are recorded in the memo, since there is no native intervention item type.\n- Step document — the oversight-adequacy memo (coach-document-upload) covering staffing gaps, overseer capability/training, and intervention-record completeness, with the roster snapshot as embedded evidence (no native Person/Roster item to update).\n- Dashboard — the cycle dashboard: each metric against its threshold and its trend vs prior cycles.\n- Item create — one corrective-action Issue per out-of-tolerance metric or carried-open item: issue_type: deficiency, source: management_identified, issue_owner, target_remediation_date; any not-yet-tracked carry-forward created as an Issue, not a duplicate of one already booked.\n- Item relationship — every Issue from this cycle linked to its source Issue and to the anchor Control as the next cycle's prior-cycle input.\n- Step document — the cycle report across all five streams, and the closure record with the archive location and reference.\n- Workflow instance — the full operating record exported and archived under retention controls; the completed instance against the anchor Control IS the control execution record.\n\n**Exit criteria**\n- Every in-scope system shows functioning automatic logging with retention at or above the six-month minimum; every logging gap carries a named remediation owner and date; the logging-integrity memo is attached. This memo is one of the reviewed inputs the cycle-metrics consolidation joins on.\n- Every alert this period is closed or carries an owned, dated remediation in flight; every breaching alert reached its escalation owner; the dashboard and monitoring review are attached. Feeds the cycle-metrics consolidation.\n- Every in-scope system has a capable, aware, named overseer with functioning oversight tools; every intervention this period is reviewed and explained; the oversight-adequacy memo is attached. Feeds the cycle-metrics consolidation.\n- The dashboard and report reflect all five streams; every gap has a named owner and due date; the AI Operations Manager's approval of the cycle result is recorded and closes the cycle; the archived record is immutable and retrievable; nothing remains open without a tracked owner; the next monthly review is scheduled.","label":"Compile cycle metrics and report","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link","coach-dashboard-create","coach-workflow-export"]}},"id":"compile-cycle-metrics-and-report"}],"sourceTemplateId":"workflow-library:controls-ai-operations-monitoring-incident-response"}