EU AI Act
90 records. Direct records match this source; context records explain their connections.
Read the first JSON page · Data retrieval guide
Mappings may provide partial coverage. Read mapping properties, residual requirements and source notes before relying on a connection.
control · Direct
AIA-Art10 — Data and data governance (high-risk)
Data and data governance (high-risk)
control · Direct
AIA-Art11 — Technical documentation (high-risk)
Technical documentation (high-risk)
control · Direct
AIA-Art12 — Record-keeping / logging (high-risk)
Record-keeping / logging (high-risk)
control · Direct
AIA-Art13 — Transparency and provision of information to deployers (high-risk)
Transparency and provision of information to deployers (high-risk)
control · Direct
AIA-Art14 — Human oversight (high-risk)
Human oversight (high-risk)
control · Direct
AIA-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (high-risk)
control · Direct
AIA-Art16 — Obligations of providers of high-risk AI systems
Obligations of providers of high-risk AI systems
control · Direct
AIA-Art17 — Quality management system (providers of high-risk AI systems)
Quality management system (providers of high-risk AI systems)
control · Direct
AIA-Art18 — Documentation keeping — 10-year retention of technical documentation, QMS records and conformity documents (providers)
Documentation keeping — 10-year retention of technical documentation, QMS records and conformity documents (providers)
control · Direct
AIA-Art19 — Automatically generated logs — provider retention of high-risk system logs (minimum six months)
Automatically generated logs — provider retention of high-risk system logs (minimum six months)
control · Direct
AIA-Art20 — Corrective actions and duty of information for non-conforming high-risk AI systems
Corrective actions and duty of information for non-conforming high-risk AI systems
control · Direct
AIA-Art21-22 — Cooperation with competent authorities; authorised representatives of non-EU providers
Cooperation with competent authorities; authorised representatives of non-EU providers
control · Direct
AIA-Art23-25 — Obligations of importers and distributors; responsibilities along the AI value chain
Obligations of importers and distributors; responsibilities along the AI value chain
control · Direct
AIA-Art26 — Obligations of deployers of high-risk AI systems
Obligations of deployers of high-risk AI systems
control · Direct
AIA-Art27 — Fundamental rights impact assessment for high-risk AI systems (deployers)
Fundamental rights impact assessment for high-risk AI systems (deployers)
control · Direct
AIA-Art43 — Conformity assessment of high-risk AI systems
Conformity assessment of high-risk AI systems
control · Direct
AIA-Art47-49 — EU declaration of conformity, CE marking and registration in the EU database
EU declaration of conformity, CE marking and registration in the EU database
control · Direct
AIA-Art5 — Prohibited AI practices
Prohibited AI practices
control · Direct
AIA-Art50 — Transparency obligations for certain AI systems (deepfakes, chatbots, emotion recognition)
Transparency obligations for certain AI systems (deepfakes, chatbots, emotion recognition)
control · Direct
AIA-Art53 — Obligations for providers of general-purpose AI (GPAI) models
Obligations for providers of general-purpose AI (GPAI) models
control · Direct
AIA-Art55 — Obligations for GPAI models with systemic risk
Obligations for GPAI models with systemic risk
control · Direct
AIA-Art6-7 — Risk-based classification of high-risk AI systems
Risk-based classification of high-risk AI systems
control · Direct
AIA-Art72 — Post-market monitoring by providers of high-risk AI systems
Post-market monitoring by providers of high-risk AI systems
control · Direct
AIA-Art73 — Reporting of serious incidents (providers; deployers inform providers)
Reporting of serious incidents (providers; deployers inform providers)
control · Direct
AIA-Art9 — Risk management system (high-risk)
Risk management system (high-risk)
risk · Context
AI accountability gaps and organizational liability
Ambiguous responsibility across developers, deployers, and operators means no party is clearly accountable when AI causes harm; organizations face reputational damage, regulatory sanctions, and civil liability from AI failures at scale, and operational disruption when AI is unavailable.
risk · Context
Adversarial attacks, data poisoning and prompt injection
Data-poisoning corrupts training data and embeds backdoors; adversarial evasion, prompt injection, and jailbreaks fool deployed models at inference; model extraction steals proprietary weights/logic — enabling harmful or policy-violating outputs.
risk · Context
Unauthorized or unsafe autonomous agent actions and tool calls
AI agents with excessive permissions or weak action controls execute tool calls, transactions, or code outside their authorized task scope — through prompt injection, misinterpretation, or emergent behaviour — causing data loss, financial loss, or irreversible changes in connected systems.
risk · Context
Harmful AI bias and discrimination against protected groups
Models encode/amplify historical bias, producing allocative harm (biased hiring/lending/housing/benefits), representational harm (stereotyping), and evaluation bias masking disparate subgroup performance — systematically disadvantaging protected groups.
risk · Context
Misuse of AI systems for offensive cyber operations or catastrophic harm
Users obtain meaningful uplift from an AI system for offensive cyber operations (malware development, vulnerability exploitation, autonomous intrusion) or for biological, chemical, nuclear, or radiological harm, exposing the deploying organization to severe legal, regulatory, and societal consequences.
risk · Context
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · Context
GPAI transparency, systemic-risk and synthetic-content obligations
GPAI providers failing transparency/copyright/training-data obligations; systemic-risk models (>10^25 FLOPs) lacking red-teaming, incident reporting, and cybersecurity; unlabeled deepfake/synthetic content; and concentration of GPAI capability creating ecosystem single points of failure.
risk · Context
Rights harm from biometric-identification AI
Because remote biometric identification, categorization, or emotion-recognition systems (EU AI Act Annex III(1)) are deployed without conformity assessment, data governance, human oversight, accuracy/robustness controls, or a fundamental-rights impact assessment, they can misidentify, misclassify, or surveil individuals, resulting in wrongful treatment, discrimination, and rights violations.
risk · Context
Public-safety harm from AI in critical infrastructure
Because AI acting as a safety component in critical digital infrastructure, road traffic, or utilities (Annex III(2)) operates without the required risk management, robustness, and human oversight, it can fail or behave unsafely, resulting in service disruption and threats to public safety and continuity.
risk · Context
Unfair exclusion by AI in education and training
Because AI determining access, admission, assessment, or proctoring in education and vocational training (Annex III(3)) operates without bias controls, transparency, human oversight, or fundamental-rights safeguards, learners can be scored or excluded unfairly, resulting in denial of educational opportunity and discrimination.
risk · Context
Discriminatory outcomes from AI in employment
Because AI used for recruitment, selection, promotion, task allocation, or worker monitoring (Annex III(4)) operates without bias mitigation, worker transparency, human oversight, or a data-protection impact assessment, it can decide about workers on biased or opaque grounds, resulting in discriminatory or unfair employment outcomes.
risk · Context
Unlawful denial of essential services by AI
Because AI evaluating eligibility for public benefits, creditworthiness, or insurance risk and pricing (Annex III(5)) operates without fairness, explainability, human oversight, or the required conformity controls, it can wrongly deny or misprice essential services, resulting in unlawful exclusion and consumer harm.
risk · Context
Harm to due process and democratic integrity from AI
Because AI assisting judicial decisions or intended to influence elections or voter behaviour (Annex III(8)) operates without human oversight, transparency, and integrity safeguards, it can distort legal outcomes or manipulate electorates, resulting in threats to due process and democratic integrity.
risk · Context
Rights violations from AI in law enforcement
Because AI for individual risk assessment, evidence evaluation, profiling, or predictive policing (Annex III(6)) operates without strict accuracy, human oversight, logging, and fundamental-rights safeguards, it can drive wrongful enforcement action, resulting in unjust detention, profiling harm, and rights violations.
risk · Context
Wrongful denial by AI in migration and border control
Because AI for migration, asylum, or visa risk assessment and border-control screening (Annex III(7)) operates without the required accuracy, human oversight, and fundamental-rights protections, it can misjudge individuals, resulting in wrongful denial of entry or status and discrimination.
risk · Context
Inaccurate, unreliable or hallucinated AI outputs
AI outputs contain factual errors, hallucinations, or confidently wrong predictions; inappropriate proxy metrics, overfitting/underfitting, or insufficient pre-deployment testing undermine trust in decisions made on their basis.
risk · Context
Inappropriate human/AI task allocation and end-of-life risk
Tasks needing contextual judgment, ethics, or accountability are improperly delegated to AI; and decommissioning raises data-persistence in weights, loss of institutional knowledge, and service-continuity gaps.
risk · Context
Insufficient human oversight and automation complacency
Because consequential AI decisions run under full automation with reviewers who lack the authority, information, or AI literacy to intervene, meaningful human control is absent and automation complacency erodes vigilance, so erroneous or harmful automated decisions reach individuals unchecked.
risk · Context
Lack of AI explainability, documentation and disclosure
Because AI models are opaque, model cards and datasheets are missing, and AI involvement in consequential interactions is not disclosed, affected individuals cannot obtain recourse and operators cannot see failure modes, resulting in unaccountable decisions, uninformed consent, and misplaced confidence in spurious, non-causal model reasoning.
risk · Context
Model/data drift and inadequate post-deployment monitoring
Distribution shift between training and deployment data silently degrades accuracy, and without ongoing monitoring, model decay and emerging failure modes go undetected with no trigger to retrain or decommission. Uncontrolled updates alter behaviour and invalidate prior assessments.
risk · Context
Insufficient AI resilience and fallback mechanisms
AI systems lacking fallback, redundancy, or graceful degradation fail catastrophically under adversarial conditions, infrastructure outages, or out-of-distribution inputs, disrupting dependent business processes.
risk · Context
Poor-quality, unrepresentative or mislabeled training data
Training data that is too small, unrepresentative, error-contaminated, or mislabeled produces systematic failure modes; data-lifecycle risks (unlawful collection, insecure storage, failure to purge) further corrupt model quality or violate privacy.
risk · Context
AI power concentration and erosion of societal trust
Disproportionate access to data, compute, and AI talent creates winner-take-all dynamics foreclosing competition; proliferation of AI-generated synthetic media and automated influence operations degrades the shared epistemic environment and democratic institutions.
risk · Context
AI privacy leakage and re-identification
Model inversion and membership-inference attacks reconstruct training data or reveal individuals in the training set; AI inference re-identifies anonymized data and infers sensitive attributes; training on data without consent/legal basis creates regulatory liability.
risk · Context
Deployment of prohibited AI practices (EU AI Act Art.5)
Use of prohibited AI: subliminal/manipulative techniques, social scoring, untargeted facial-image scraping, real-time/post remote biometric identification for law enforcement, sensitive-attribute biometric categorization, and emotion recognition in work/education settings.
risk · Context
AI safety failures causing physical or psychological harm
AI errors in safety-critical systems (autonomous vehicles, medical devices, industrial controls) cause injury or death; safety-constraint violations by agentic AI, cascading failures across coupled systems, and AI-generated misinformation/deepfakes cause harm.
risk · Context
AI supply-chain compromise and provider concentration
Because the organization relies on third-party pretrained models, datasets, and libraries that may carry backdoors, malicious code, or bias, and concentrates on a few external AI API providers, AI-dependent workflows are exposed to both supply-chain compromise and provider outage or insolvency, resulting in compromised model behaviour or sudden loss of AI capability.
risk · Context
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · Context
Corruption or integrity loss of critical data
Intentional or accidental alteration, deletion, defacement, or injection of false-but-believable data into systems (including web defacement and data from untrustworthy sources) renders data inaccurate and erodes confidence in it.
risk · Context
Privacy harms: distortion, stigmatization, unwarranted restriction
Processing inaccurate/out-of-context data (distortion), attaching negative social labels (stigmatization), or denying services based on personal data without justification (unwarranted restriction / algorithmic gatekeeping) — causing discrimination and economic loss.
risk · Context
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · Context
Absence of privacy-by-design and default
Because systems and products are built without embedding privacy controls at the architecture level, privacy protections are bolted on after launch rather than applied by default, so personal data is over-collected and exposed and costly manual remediation is required.
risk · Context
Power imbalance and loss of self-determination over personal data
Structural informational asymmetry (take-it-or-leave-it consent, opaque algorithmic decisions) and inability to correct, delete, or restrict processing deprive individuals of meaningful control over their own data and narrative.
risk · Context
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Context
Applications running with excessive privilege / insecure design
Applications or services running under privileged accounts, opening unnecessary network connections, or lacking secure-by-design architecture mean a single compromise grants broad system access and expands attack surface.
risk · Context
Malware delivery, insertion and compromise of systems
Adversary crafts and delivers known, modified, or targeted malware (via email, web, removable media, or downloadable software) and compromises system software to take control, exfiltrate data, or degrade functions.
risk · Context
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
risk · Context
Zero-day exploitation
Adversary employs attacks that exploit as-yet-unpublicized vulnerabilities (targeted, based on reconnaissance, or nontargeted), compromising systems before any patch or signature exists.
standard · Direct
EU AI Act
EU AI Act — principal obligation areas (Chapters II, III, V and IX)
unified · Context
UC-AI-04 — Assess impacts and classify AI systems before deployment
Operate a documented AI impact assessment process performed before deployment and repeated on significant change, assessing consequences for individuals, groups of individuals, and society, including fairness, safety, and fundamental-rights effects. Classify each system against applicable regulatory risk categories, including any high-risk designation, and record the classification rationale. Retain assessment reports, approvals, and reassessment triggers as evidence.
unified · Context
UC-AI-06 — Maintain AI system technical documentation
Produce and maintain technical documentation for each AI system covering design and development decisions, architecture, model and data characteristics, performance, and limitations, including all content mandated by applicable regulation for higher-risk systems. Keep documentation up to date through changes and retain it for the regulatorily mandated period. Documentation must be sufficient for regulators and assessors to evaluate compliance.
unified · Context
UC-AI-08 — Log and monitor AI system behavior in operation
Ensure AI systems automatically record event logs that enable traceability of operation over the system's lifetime, including events relevant to identifying risk situations and substantial modification. Retain logs for at least the mandated regulatory minimum, or longer where required. Monitor deployed systems against defined performance and behavior metrics with alerting and escalation for anomalies and drift, and retain logs and monitoring reviews as evidence.
unified · Context
UC-AI-09 — Govern AI data quality, provenance, and preparation
Govern training, validation, and test data under documented data-management practices covering acquisition, selection, provenance recording, and preparation activities such as labelling, cleaning, and enrichment. Apply and record quality criteria appropriate to the intended purpose, including relevance, representativeness, and, to the best extent possible, completeness and freedom from errors, and examine datasets for biases with mitigation of those likely to affect health, safety, or fundamental rights. Retain data documentation and provenance records for each AI system.
unified · Context
UC-AI-10 — Meet transparency obligations for AI systems
Provide users, deployers, and other interested parties with documentation and instructions for each AI system describing its intended purpose, capabilities, limitations, performance characteristics, and required human-oversight measures. Disclose when people are interacting with an AI system, and mark AI-generated or manipulated content, including deepfakes, in a machine-readable and clearly perceptible way where required. Keep transparency materials current with system changes and retain distribution evidence.
unified · Context
UC-AI-11 — Operate AI concern, incident, and external reporting channels
Operate channels through which personnel and other stakeholders can report concerns about the organization's role in developing or using AI systems, with documented triage and follow-up. Define and execute procedures for communicating AI incidents to affected users and interested parties, and for making required reports to regulators and other external bodies within mandated timeframes. Retain concern reports, incident communications, and resolution records as evidence.
unified · Context
UC-AI-12 — Enforce responsible and lawful use of AI systems
Define objectives and documented processes for responsible use of AI systems, and ensure each system is used only in accordance with its intended use and accompanying documentation. Screen proposed and existing uses against legal prohibitions on unacceptable practices — such as manipulative techniques, social scoring, and untargeted facial-image scraping — and block or discontinue prohibited uses. Retain use approvals and screening records.
unified · Context
UC-AI-13 — Assign AI value-chain roles and discharge obligations
For each AI system, determine and document the organization's role in the value chain, such as provider or deployer, and allocate life-cycle responsibilities among the organization, partners, suppliers, and customers. Maintain a register of the obligations attached to each role, including provider duties for high-risk systems (quality management, conformity assessment, CE marking, registration) and deployer duties (instruction-compliant operation, oversight assignment, log retention), tracking each obligation to an owner and evidence. Review the register when systems or regulations change.
unified · Context
UC-AI-15 — Fulfill general-purpose AI model provider obligations
Where the organization provides general-purpose AI models, maintain model technical documentation and information for downstream providers, implement a policy to comply with applicable copyright law including reservation-of-rights opt-outs, and publish a sufficiently detailed summary of training content. For models designated as posing systemic risk, additionally perform state-of-the-art model evaluations including adversarial testing, assess and mitigate systemic risks, track and report serious incidents to the competent authority, and ensure adequate cybersecurity protection for the model and its infrastructure.
unified · Context
UC-AI-16 — Ensure human oversight of AI decisions
Design and operate high-risk AI systems so that natural persons can effectively oversee them during use, through human-machine interface tools and oversight measures built into the system or defined for the deployer. Assign oversight to persons who understand the system's capacities and limitations, can monitor operation, remain aware of automation bias, correctly interpret output, and can decide not to use, override, or halt the system. Evidence includes oversight procedures, oversight assignments, and intervention records.
unified · Context
UC-AI-24 — Operate an AI quality management system
Establish and maintain a documented quality management system for AI products covering quality objectives and responsibilities; documented design, development, testing, and release procedures; change management; data management procedures; issue tracking and corrective action; stakeholder and regulator communication procedures; and record keeping. Review the system periodically for effectiveness and continual improvement, and retain the quality manual, procedures, review records, and corrective-action logs as evidence.
unified · Context
UC-RISK-01 — Establish and maintain a tailored risk management framework
Senior leadership establishes, approves, and visibly sponsors an enterprise risk management framework customized to the organization's external and internal context. The framework design defines accountabilities, resources, and processes for managing risk, and the framework is implemented across the organization on a planned schedule. Where regulated technologies such as high-risk AI systems are in scope, the framework is extended with the required lifecycle-specific risk processes. Approved framework documentation and implementation plans are retained as evidence.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
AI Operations Monitoring & Incident Response
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.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
AI Governance & Risk/Impact Assessment
Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Risk & Resilience Framework Governance
Risk & Resilience Framework Governance as a decision-aware workflow. The instance runs on the "Enterprise Risk Management Framework" Process item (process_type: business_process, process_owner = the framework owner, frequency: annual) - created on the first cycle at "Design core ERM framework" and enriched every cycle thereafter, never duplicated; that Process item is the governance register entry, and each governance cycle runs as a workflow instance attached to it, so the at-least-annual cadence is provable from one item's instance history. Working from the organization's context and the ISO 31000 / COSO ERM / DORA reference models - no upstream workflow package feeds it, because this workflow establishes the governance layer - it establishes or refreshes the enterprise risk management framework, extends it for ICT operational resilience and regulated technologies, secures management-body approval and budget, drives implementation across the organization, and runs the at-least-annual review, filling the governance layer the risk-cycle workflows run inside but never establish. The named deliverable is the approved risk & resilience framework package (core ERM design + ICT operational-resilience (DORA) extension + any regulated-technology lifecycle extension), archived at close as durable governance evidence. In scope: the enterprise risk framework, its always-in-scope ICT operational-resilience (DORA) extension, and any regulated-technology (e.g. high-risk AI) extensions to be evaluated. Out of scope: executing the individual risk-cycle workflows (identify / assess / treat / monitor) that run inside this framework - this workflow governs them but does not perform them, and consumes no upstream workflow package. Downstream, the archived framework enables those risk-cycle workflows, which reference it as their governing baseline (the relationship is real but not modeled as a node).
workflow · Context
AI Governance Framework, Roles & Obligations Review
AI Governance Framework, Roles & Obligations Review as a modular, decision-aware workflow. Each quarterly instance runs on the existing "AI Governance Program" Process item (process_type operational, quarterly, process_owner = AI Governance Officer) and enriches its standing registers — it never recreates them. It keeps the AI policy current and republished, refreshes the RACI and competency records, maintains each AI system's resource and dependency inventory, and walks the value-chain obligations register so every provider and deployer duty traces to an owner and evidence. Consumes at launch: the cycle trigger (interval, folded-in annual re-approval, or a regulatory/technology change) and prior-cycle registers — the AI policy as a Policy item (framework iso-42001 + eu-ai-act, domains ai_governance), the obligations register as EU AI Act / ISO 42001 Control items (control_owner = obligation owner), plus the in-scope AI system list, the RACI and competency register, and the per-system resource inventory, which have no native item type and travel as versioned step documents. Deliverables: the republished AI policy version, the refreshed RACI and competency register, the current resource and dependency inventory, the walked obligations register, and a four-area cycle evidence package. In scope: those four governance registers for the AI systems in boundary this quarter; out of scope: the AI systems' own development, risk assessment, and control testing. Terminal — no downstream workflow consumes the output; the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
AI Service Data Policy & Quality Management Cycle
AI Service Data Policy & Quality Management Cycle as a modular, decision-aware workflow. Each annual instance — and each semiannual regulatory-compliance checkpoint — runs on the existing "AI Service Data Policy & Quality Management" Process item (process_type operational, process_owner = AI Product Owner) and enriches its standing records; it never recreates them. Run by the AI Governance Lead (second line) and owned by the AI Product Owner (first line), it refreshes the customer-facing input data policy and output data policy, collects customer acknowledgements where the changes are material, reviews the AI quality management system for effectiveness, and refreshes the regulatory compliance documentation and obligations register shared with customers. Consumes at launch: the cycle trigger and mode, the in-scope AI service list with each service's value-chain role (a step document — there is no AI System item type), both data policies and the quality manual and procedures as Policy items, and the obligations register as Control items. Deliverables: the published policy versions with their acknowledgement records, the quality management system review record, the refreshed compliance statement and obligations register, the corrective-action log, and an indexed cycle evidence pack. Out of scope: the AI services' own development, risk assessment, and control testing, and fulfilment of individual customer data requests. Terminal — the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
AI System Development, Data & Deployment Gate
Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).
workflow · Context
AI Transparency & Value-Chain Communications
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.
workflow · Context
GPAI Model Provider Compliance Cycle
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.
workflow · Context
EU AI Act Obligation Impact Analysis
EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the "impact-analysis item" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.