← All posts

AI governance framework: a practical playbook for EU leaders

An AI governance framework is the system of policies, roles, controls, monitoring practices, and documented evidence that an organisation uses to develop, deploy, and oversee AI responsibly. For EU organisations, the immediate first action is to build an AI system inventory and classify each system against the EU AI Act’s four risk categories: unacceptable (prohibited), high risk, transparency risk, and minimal risk. That classification determines every subsequent obligation. The five pillars that structure a practical framework are:

  • Governance and roles: executive accountability, committee structures, and RACI

  • Risk and regulatory compliance: risk assessment, classification, and legal mapping

  • Ethics, transparency, and stakeholder engagement: fairness, explainability, and communication

  • Data, MLOps, and infrastructure: data quality, model lifecycle, and pipeline controls

  • Security and incident response: threat management, logging, and breach protocols

Map those pillars to ISO/IEC 42001 for your management system, the EU AI Act for compliance triggers, the NIST AI Risk Management Framework for lifecycle processes, and the OECD AI Principles for due diligence. Start with the inventory. Everything else follows from it.

Table of Contents

Why AI governance matters for EU organisations right now

AI governance is the organisational system that keeps AI development and deployment legal, ethical, and operationally sound. It covers the policies that define acceptable use, the roles that own decisions, the controls that prevent harm, the monitoring that detects problems, and the evidence that satisfies regulators.

The urgency is regulatory and commercial. The EU AI Act is now in force, with prohibitions on unacceptable-risk systems already applicable and obligations for high-risk systems phasing in progressively. The Act’s risk-based classification means that the compliance burden scales with the potential harm a system can cause. A high-risk AI system used in recruitment, credit scoring, or critical infrastructure carries documentation, testing, human oversight, and post-market monitoring requirements that a minimal-risk chatbot does not.

Beyond legal exposure, poor governance creates reputational and operational risk. An AI system that produces biased outputs, fails silently, or operates without a documented owner is a liability regardless of whether a regulator has noticed it yet. Governance reduces that exposure by making accountability explicit and controls auditable.

The practical case for governance is equally strong. Organisations that build governance early can scale AI adoption with confidence, because they have the controls and evidence to demonstrate trustworthiness to customers, partners, and regulators alike.

The role of the Board in AI governance | Blog | Mario Thomas

Infographic showing five pillars of AI governance framework

What are the five pillars of a practical AI governance framework?

Pillar 1: Governance and roles

Team discussion on AI governance framework in meeting room

Every AI system needs a named owner. This pillar covers the committee structures, role definitions, and decision-escalation paths that make accountability real rather than rhetorical. Critical artefacts include a governance charter, a terms of reference for any AI oversight committee, and a RACI matrix covering inventory, risk tiering, approval, monitoring, and incident response. The executive sponsor holds ultimate accountability; the AI programme lead coordinates day-to-day governance; model owners are accountable for individual systems.

Pillar 2: Risk and regulatory compliance

This pillar translates the EU AI Act’s risk categories into internal risk tiers and maps each tier to a set of required controls. Artefacts include a risk register, impact assessments for high-risk systems, and a compliance mapping document that shows which regulatory obligations apply to each system. The Data Protection Officer (DPO) is typically accountable for GDPR intersections; the compliance lead owns the regulatory mapping.

Pillar 3: Ethics, transparency, and stakeholder engagement

Fairness assessments, explainability requirements, and disclosure obligations all live here. For high-risk systems, the EU AI Act requires that users are informed they are interacting with AI and that decisions can be explained. Artefacts include an ethics policy, fairness testing reports, and a stakeholder communication plan. Singapore’s Model AI Governance Framework provides practical matrices for determining the appropriate level of human oversight, which is a useful reference when calibrating this pillar.

Pillar 4: Data, MLOps, and infrastructure

Governance must cover the whole AI ecosystem: data pipelines, prompt libraries, application logic, and human decision workflows, not only the model itself. Many operational risks emerge from interactions across these components. Artefacts include data sheets, model cards, training and validation reports, and a model registry. ML engineers and data owners are accountable; the model card is the minimum documentation standard for any system in production.

Pillar 5: Security and incident response

AI systems introduce specific attack surfaces: adversarial inputs, data poisoning, model extraction, and prompt injection. This pillar covers threat modelling, access controls, logging requirements, and a documented incident response playbook for AI-specific failures. Artefacts include a security risk assessment, an incident log, and a post-incident review template.

Pro Tip: Design reusable governance patterns rather than bespoke controls for each system. The Responsible AI Pattern Catalogue groups patterns across governance, process, and product levels — adopting a pattern library means your team applies consistent controls without reinventing them for every new deployment.

How do leading standards compare for EU organisations?

The table below maps the five most relevant frameworks on the dimensions that matter for an EU organisation deciding how to structure its governance programme.

Framework Scope Risk coverage Maturity target Operational requirements Jurisdictional force
EU AI Act AI systems placed on or used in the EU market High-risk focus with prohibited-use ceiling All sizes; obligations scale with risk tier Documentation, testing, human oversight, post-market monitoring, registration Binding EU law
ISO/IEC 42001 Organisations developing or using AI General principles with management system controls Enterprise and SME; certifiable Leadership commitment, planning, support, operation, performance evaluation Voluntary; certifiable
NIST AI RMF AI systems across the lifecycle Broad risk coverage: GOVERN, MAP, MEASURE, MANAGE Enterprise-oriented; adaptable Lifecycle documentation, risk profiles, playbooks Voluntary (US origin; globally adopted)
OECD AI Principles Organisations and governments Principles-based; due diligence focus All sizes Embed, identify, assess, cease/mitigate, track, communicate, remediate Advisory; referenced in EU Act preamble
ICO AI guidance Organisations processing personal data using AI Data protection risk focus All sizes Data protection impact assessments, transparency notices, fairness testing Binding where GDPR applies

How to combine them in practice:

  • Use ISO/IEC 42001 as your management system backbone. It gives you a certifiable structure covering leadership, planning, and performance evaluation that maps directly to your existing ISO 27001 or ISO 9001 disciplines.

  • Use the EU AI Act as your compliance trigger. Its risk categories determine which obligations are mandatory and by when.

  • Use the NIST AI RMF for lifecycle process design. Its GOVERN, MAP, MEASURE, and MANAGE functions provide a practical operating model for AI teams.

  • Use the OECD due diligence guidance for supply chain and third-party AI risk, where its stepwise roadmap (embed, identify, assess, mitigate, track, communicate, remediate) maps directly to vendor management processes.

  • Use ICO guidance whenever your AI system processes personal data, which in practice means almost every customer-facing or HR-related system.

For an SME, the pragmatic starting point is the EU AI Act for compliance obligations and ISO/IEC 42001 for management system structure. The NIST RMF adds depth when your team has the capacity to adopt its lifecycle playbooks.

How do you implement an AI governance framework step by step?

Phase 1: Prepare (weeks 1–4)

  1. Appoint an executive sponsor with budget authority and board visibility.

  2. Build an AI system inventory: name, purpose, data inputs, outputs, decision authority, and business owner for every system in use or in development.

  3. Identify applicable regulatory obligations using the EU AI Act risk categories and ICO guidance.

  4. Establish a cross-functional governance team: legal, compliance, data science, security, and business leads.

Phase 2: Classify (weeks 5–8)

  1. Apply the EU AI Act’s risk classification to each inventoried system: prohibited, high risk, transparency risk, or minimal risk.

  2. Assign an internal risk tier (critical, elevated, standard) that maps to your control requirements.

  3. Prioritise high-risk and critical-tier systems for immediate remediation.

Phase 3: Design controls (weeks 9–16)

  1. Draft or update policies: acceptable use, data governance, model development standards, and incident response.

  2. Produce model cards and data sheets for all systems in scope.

  3. Conduct impact assessments for high-risk systems.

  4. Define monitoring requirements: logging, drift detection, fairness metrics, and human override protocols.

Phase 4: Test and validate (weeks 17–20)

  1. Run pre-deployment testing: performance, fairness, adversarial robustness, and explainability checks.

  2. Conduct a tabletop incident response exercise.

  3. Collect and organise evidence for each control.

Phase 5: Deploy with monitoring (weeks 21–28)

  1. Deploy systems with active monitoring dashboards in place.

  2. Establish review cadences: monthly metrics review, quarterly risk register update, annual full audit.

Phase 6: Continuous improvement (ongoing)

  1. Feed audit findings and incident reports back into the risk register and control library.

  2. Re-classify systems when their use, exposure, or decision authority changes.

The OECD AI Governance Playbook recommends embedding governance directives across strategy, risk, compliance, and workforce readiness rather than treating it as a standalone project. That integration is what makes governance sustainable.

Phase SME milestone Enterprise milestone
Prepare Inventory complete, sponsor named Governance charter approved, steering committee formed
Classify All systems risk-tiered Risk register baselined, critical systems identified
Design controls Core policies drafted, model cards produced Full control library mapped to EU AI Act obligations
Test and validate Pre-deployment checklist completed Independent review of high-risk systems
Deploy with monitoring Monitoring dashboard live Automated alerting and escalation paths operational
Continuous improvement Quarterly review cadence established Annual third-party audit scheduled

Who owns AI governance? Roles, committees, and RACI

Governance without named owners is decoration. The table below sets out the core roles and a RACI for the activities that matter most.

Activity Executive sponsor AI programme lead Model owner DPO ML engineer Security lead Compliance lead
AI system inventory A R C C C C I
Risk classification A R C C I C C
Policy approval A C I C I I R
Impact assessment I C R A C C C
Pre-deployment approval A R C C I C C
Monitoring and alerting I C R I A C I
Incident response A R C C C A C
Audit preparation I R C C I C A

R = Responsible, A = Accountable, C = Consulted, I = Informed

Questions to ask when assigning roles:

  • Does this person have the authority to stop a deployment? If not, they cannot be accountable.

  • Is there a clear escalation path from model owner to executive sponsor for high-risk decisions?

  • Does the DPO have visibility of all AI systems that process personal data, not just those flagged as high risk?

  • Are federated domain owners (e.g., a business unit AI lead) connected to the central governance function, or operating independently?

For SMEs without a dedicated AI team, the AI programme lead role often sits with the Head of Technology or CTO, and the model owner role is shared across product managers. That is workable, provided the RACI is explicit and the escalation path to the executive sponsor is documented.

Central policy with federated delivery is the most effective operating model at scale: a central team sets standards and owns the control library, while domain teams execute controls for their own systems. This reduces shadow AI and keeps governance proportionate for smaller teams.

How do you assess and classify AI risk under the EU AI Act?

The EU AI Act’s risk classification is the starting point for any practical risk assessment. The four categories carry materially different obligations.

Risk tier EU AI Act category Trigger criteria Minimum controls required
Prohibited Unacceptable risk Social scoring by public authorities; real-time biometric surveillance in public spaces (with narrow exceptions); subliminal manipulation Cease use immediately; document decision
Critical High risk Systems in Annex III domains: biometric ID, critical infrastructure, education, employment, essential services, law enforcement, migration, justice Full documentation, conformity assessment, human oversight, post-market monitoring, EU database registration
Elevated Transparency risk Chatbots, deepfakes, emotion recognition Disclosure to users; content labelling
Standard Minimal/no risk Most business productivity tools, recommendation engines with no significant rights impact Voluntary codes of practice; internal monitoring

Practical risk assessment questions for each system:

  • What decisions does this system influence, and can a human override them?

  • Which individuals or groups are affected, and what is the potential harm if the system fails or produces biased outputs?

  • Does the system fall within any of the Annex III high-risk domains?

  • What data does it process, and does that data include special-category personal data under GDPR?

  • Has the system’s use, scope, or decision authority changed since it was last assessed?

That last question matters more than most teams realise. A system originally deployed as a low-risk analytics tool can become high risk if its outputs are later used to make employment or credit decisions. Re-classification should be triggered by any material change in use, exposure, or decision authority, not only at scheduled review intervals.

Treatment patterns follow the tier: prohibited systems must be ceased; high-risk systems require technical and organisational mitigation; transparency-risk systems require disclosure; minimal-risk systems can be accepted with light monitoring. Transfer (e.g., contractual liability shift to a vendor) is available but does not remove the deployer’s obligations under the EU Act.

What KPIs and monitoring practices keep governance effective?

Monitoring is where governance either holds or collapses. A policy document that is not backed by active measurement is not governance; it is paperwork.

KPI categories to track:

  • Safety: rate of human override activations; number of safety incidents per system per quarter

  • Fairness: demographic parity metrics; false positive/negative rate differentials across protected groups

  • Performance: model accuracy, precision, recall, and F1 score against baseline; drift indicators

  • Reliability: system uptime; latency; failure rate under load

  • Compliance coverage: percentage of inventoried systems with current model cards; percentage with completed impact assessments; open remediation items by age

  • Incident metrics: mean time to detect (MTTD); mean time to respond (MTTR); number of incidents escalated to the executive sponsor

Monitoring practices:

  • Automated logging of all model inputs, outputs, and decisions for high-risk systems, with retention periods aligned to regulatory requirements

  • Drift detection: statistical process control charts or population stability index (PSI) scores to flag when input data distributions shift materially from training data

  • Synthetic test sets run on a scheduled basis to detect performance degradation without waiting for live failures

  • Human override protocols for high-risk decisions: every system in the critical tier should have a documented process for a human to review and reverse an AI-generated decision

  • Quarterly fairness audits using disaggregated performance data across relevant demographic groups

Audit readiness checklist:

  • Current model card for every production system

  • Completed impact assessment for every high-risk system

  • Evidence of pre-deployment testing (test reports, fairness assessments)

  • Monitoring dashboard screenshots or exports covering the review period

  • Incident log with resolution notes

  • Training records for staff with AI governance responsibilities

  • Vendor contracts with AI-specific clauses (see the third-party section below)

What does AI governance cost, and how long does it take?

Cost and timeline vary significantly by organisation size, the number of AI systems in scope, and the risk profile of those systems. The table below gives realistic ranges for an SME (fewer than 250 employees, up to 10 AI systems) and a larger enterprise.

Cost/time driver SME estimate Enterprise estimate
Initial inventory and risk classification 2–4 weeks; internal effort only 6–12 weeks; may require external facilitation
Policy and control design 4–8 weeks; 1–2 FTE equivalent 8–16 weeks; dedicated programme team
Impact assessments (per high-risk system) 2–4 weeks each 4–8 weeks each with legal review
Tooling (GRC platform, monitoring) Subscription-based; lower entry cost Enterprise licensing; integration effort
Training (governance and compliance staff) 1–2 days per cohort Ongoing programme; role-specific curricula
External assurance (audit or certification) Optional at SME scale initially Annual third-party audit; ISO/IEC 42001 certification
Total time to baseline governance 3–6 months 6–18 months

The biggest cost driver for most organisations is not tooling; it is the internal effort required to produce documentation and conduct assessments. A GRC platform that automates evidence collection, generates policy templates, and tracks remediation items can reduce that effort materially. For SMEs, the practical choice is between building governance manually (lower upfront cost, higher ongoing effort) or using a platform to automate the repeatable elements.

Resourcing model: a central programme team of one to two people sets standards and owns the control library. Federated domain owners in each business unit execute controls for their systems and report into the central function. External consultants or a virtual CISO can fill gaps during the initial build phase without the cost of a permanent hire.

Common mistakes that undermine AI governance programmes

Most governance failures are not dramatic. They are quiet: a system deployed without a model card, a risk assessment that was never updated after a scope change, a monitoring dashboard that nobody checks.

Anti-patterns to avoid:

  • Shadow AI: employees using AI tools that have not been inventoried or assessed. The fix is a mandatory disclosure process and an acceptable use policy with teeth.

  • One-off ethics checks: a single pre-deployment review that is never repeated. Ethics and fairness assessments must be scheduled, not one-time events.

  • Model-only governance: focusing controls only on the model algorithm while ignoring data pipelines, prompts, and downstream human workflows. Operational risk often lives in those components.

  • Governance by committee with no owners: a steering group that meets quarterly but no individual is accountable for specific systems. Every system needs a named model owner.

  • Documentation as theatre: producing model cards and impact assessments to satisfy a checklist, then filing them and never updating them. Regulators and auditors look for evidence of active use, not just existence.

Red flags in vendor engagements:

  • A vendor cannot provide a model card or technical documentation for their AI system.

  • No contractual clause covering what happens when the vendor’s model changes materially.

  • No clarity on where training data originates or whether it includes personal data.

  • The vendor cannot explain how their system produces outputs or what human oversight is in place.

When you spot these red flags, the corrective action is straightforward: require documentation as a condition of contract, include change notification clauses, and conduct a proportionate risk assessment before deployment.

How ShieldIQ helps you build and evidence AI governance

ShieldIQ’s GRC platform maps directly to the playbook above. The table below shows how specific platform capabilities align to the artefacts and activities each phase requires.

Governance activity Required artefact ShieldIQ capability
AI system inventory Asset register with system metadata Risk and asset register with custom AI system fields
Risk classification Risk register with EU AI Act tier mapping Automated risk assessments mapped to EU AI Act categories
Policy and control design Acceptable use policy, model development standards AI-driven policy creation with gap analysis
Impact assessments High-risk system impact assessment Assessment templates aligned to EU AI Act Annex III
Evidence collection Test reports, monitoring logs, audit packs Evidence management and audit-ready reporting
Vendor management Third-party AI risk assessments, contract clauses Vendor management module with risk scoring
Monitoring and incident response Monitoring dashboard, incident log Incident workflows and compliance dashboards
Audit preparation Evidence pack, remediation tracker Gap analysis reports and remediation tracking

ShieldIQ’s EU AI Act compliance support is built specifically for SMEs that need to meet regulatory obligations without a full-time compliance team. The platform automates the repeatable elements of governance — assessments, controls, evidence collection — so your team can focus on the decisions that require human judgement.

For organisations that also need to align AI governance with ISO 27001 or NIS2 obligations, ShieldIQ’s cross-framework controls mean you build once and evidence across multiple standards simultaneously.

How does AI governance fit into your existing risk management?

AI governance is not a separate discipline. It is an extension of enterprise risk management (ERM) applied to algorithmic systems. The most effective approach, as Singapore’s Model AI Governance Framework recommends, is to adapt existing ERM frameworks to include algorithmic risk assessments, human oversight requirements, and AI-specific documentation artefacts.

In practice, this means adding AI system risk to your existing risk register categories, extending your third-party risk management process to cover AI vendors, and including AI-related incidents in your existing incident management workflow. Your existing three-lines-of-defence model maps cleanly: the AI system owner is the first line, the governance and compliance function is the second, and internal or external audit is the third.

Board-level oversight is the piece most organisations underinvest in. AI risk should appear on the board risk agenda with the same regularity as cyber risk and financial risk. That requires the executive sponsor to translate technical AI risk into business impact terms — which is precisely why the RACI in the roles section assigns accountability for escalation to the executive sponsor rather than the AI programme lead.

What EU organisations are doing in practice

EU organisations across sectors are moving from policy commitments to operational governance. Financial services firms subject to DORA are extending their ICT risk frameworks to cover AI systems used in credit decisioning and fraud detection, treating model risk as a subset of operational risk. Healthcare organisations deploying AI-assisted diagnostics are conducting conformity assessments aligned to the EU AI Act’s Annex III high-risk categories, producing technical documentation and registering systems in the EU database.

For SMEs, the practical pattern is lighter but structurally similar: a named AI lead (often the CTO or Head of Technology), a model inventory maintained in a GRC platform, and a risk classification exercise conducted before any new AI tool is deployed in a customer-facing or decision-making context. The key discipline is not waiting until a system is in production to ask whether it is high risk. That question belongs at the procurement or development stage.

Organisations that have integrated AI governance with their ISO 27001 management systems report the fastest time to audit readiness, because the documentation disciplines and internal audit cadences are already established. Adding AI-specific controls to an existing management system is significantly less effort than building a standalone governance programme from scratch.

How do you engage stakeholders and build a governance culture?

Governance programmes that live only in the compliance team fail. The controls are there on paper, but the AI teams building and deploying systems do not follow them because they were not involved in designing them.

Effective stakeholder engagement starts at the design stage. Bring AI developers, product managers, and business owners into the risk classification process. When they understand why a system is classified as high risk and what that means for their deployment timeline, they are far more likely to produce the required documentation than if it arrives as a compliance mandate after the fact.

Communication plan essentials:

  • A plain-language summary of the organisation’s AI governance policy, written for non-specialists

  • Role-specific training: developers need to understand model card requirements and testing standards; business owners need to understand risk classification and escalation paths; executives need to understand board-level reporting obligations

  • A regular governance update (quarterly is sufficient for most SMEs) that reports on the state of the AI system inventory, open remediation items, and any incidents

Training for compliance staff should cover the EU AI Act’s risk categories and the internal risk classification criteria in enough depth that they can conduct a first-pass assessment without specialist support. AI teams need training on documentation standards: what a model card must contain, what a data sheet must record, and what evidence is required for pre-deployment approval.

The cultural shift that matters most is normalising the question “has this been assessed?” before any AI system goes into production. That question should be as automatic as asking whether a new software tool has been through security review.

Managing third-party AI vendors and supply chain risk

Most EU organisations are not building AI from scratch. They are deploying AI systems built by vendors, integrating AI APIs into existing products, or using AI-enabled SaaS tools. Each of those relationships creates governance obligations that do not disappear because the system was built externally.

Under the EU AI Act, the deployer of a high-risk AI system carries obligations regardless of whether they built it. That means your vendor management process must include AI-specific due diligence.

Third-party AI due diligence checklist:

  • Request the vendor’s technical documentation and model card before contracting

  • Confirm whether the system is classified as high risk under the EU AI Act, and if so, whether the vendor has completed a conformity assessment

  • Include contractual clauses covering: notification of material model changes, data processing terms aligned to GDPR, incident notification timelines, and audit rights

  • Assess the vendor’s own governance programme: do they have a named AI owner, documented testing procedures, and a monitoring process?

  • Conduct a proportionate risk assessment for each vendor AI system, applying your internal risk classification criteria

The OECD due diligence guidance is particularly useful here. Its stepwise approach (embed, identify, assess, mitigate, track, communicate, remediate) maps directly to a vendor risk management lifecycle. Apply it to your AI supply chain the same way you would apply it to any other third-party risk.

For AI APIs and foundation model providers, the key question is what the provider’s terms of service permit in terms of data use, and whether those terms are compatible with your GDPR obligations. Many foundation model providers process inputs for model improvement by default. That is a data governance issue as much as an AI governance one, and it belongs in your impact assessment for any system that uses those APIs with personal data.

Key takeaways

An effective AI governance framework requires a named inventory, EU AI Act risk classification, five operational pillars, and active monitoring — not just a policy document.

Point Details
Start with the inventory Build a complete AI system register before designing any controls; classification determines every subsequent obligation.
EU AI Act risk tiers drive obligations High-risk systems require documentation, conformity assessment, human oversight, and post-market monitoring under binding EU law.
Five pillars structure the framework Governance and roles, risk and compliance, ethics and transparency, data and MLOps, and security each require named owners and documented artefacts.
Central policy with federated delivery scales governance A central team sets standards; domain owners execute controls, reducing shadow AI without creating bottlenecks.
ShieldIQ automates the repeatable elements ShieldIQ’s GRC platform covers inventory, risk assessments, policy creation, evidence management, and audit-ready reporting for EU AI Act and ISO/IEC 42001 alignment.

The governance gap most organisations are not talking about

The debate around AI governance tends to focus on the EU AI Act’s prohibited and high-risk categories, which is understandable. Those are the categories with legal teeth. But the more common failure mode is not deploying a prohibited system. It is deploying dozens of minimal-risk and transparency-risk systems with no inventory, no owner, and no monitoring, and then discovering that several of them have quietly drifted into high-risk territory because their use cases evolved.

The inventory is not a bureaucratic exercise. It is the only way to know what you are governing. Organisations that skip it and jump straight to policy drafting are building governance on a foundation they cannot see. The policy looks complete; the actual risk exposure is invisible.

The second thing that gets underestimated is the human oversight requirement. The EU AI Act mandates meaningful human oversight for high-risk systems, not nominal oversight. A human who rubber-stamps every AI recommendation without the information, time, or authority to override it does not satisfy the requirement. Designing genuine override capability into high-risk systems is an engineering and process challenge, not just a compliance checkbox.

The third gap is vendor governance. Most EU organisations have accepted AI into their supply chains faster than their procurement processes have adapted. A vendor’s AI system that processes your customers’ personal data and influences material decisions about them is your governance problem, not just theirs. The contractual and due diligence disciplines described in this guide are not optional extras for large enterprises; they are the minimum standard for any organisation that takes its EU AI Act obligations seriously.

ShieldIQ: AI governance support built for EU SMEs

Building an AI governance programme from scratch takes time your team probably does not have spare. ShieldIQ’s GRC platform gives EU SMEs a faster path: automated risk assessments aligned to the EU AI Act, a cross-framework controls library that covers ISO/IEC 42001 and GDPR simultaneously, AI-driven policy creation, and audit-ready evidence packs that satisfy regulators without months of manual documentation work.

ShieldIQ

The platform’s vendor management module handles third-party AI due diligence, and its incident workflows keep your response process documented and auditable. For organisations that need hands-on support, ShieldIQ’s consulting services include virtual CISO engagements, gap analysis, and audit preparation. Whether you need a platform subscription to automate governance or a consulting engagement to build your programme, the next step is a conversation. Book a demo or assessment at shieldiqcyber.com to see how quickly your organisation can move from inventory to audit-ready.

Useful sources

  • EU AI Act — Regulation (EU) 2024/1689: The primary binding legislation. Normative for all EU organisations. Essential reading for understanding risk categories, Annex III high-risk domains, and compliance obligations. Most relevant for all sizes.

  • European Commission — Regulatory framework for AI: Official Commission summary of the AI Act’s risk-based approach and classification criteria. Advisory companion to the Act itself. Good starting point for SMEs.

  • NIST AI Risk Management Framework (AI RMF): Voluntary US framework covering GOVERN, MAP, MEASURE, and MANAGE functions across the AI lifecycle. Globally adopted; most useful for enterprise organisations building lifecycle governance processes.

  • OECD Due Diligence Guidance for Responsible AI: Advisory guidance covering a stepwise due diligence roadmap. Referenced in the EU AI Act preamble. Particularly useful for supply chain and third-party AI risk management. Relevant for all sizes.

  • OECD AI Governance Playbook: Practical playbook recommending integrated governance across strategy, risk, compliance, and workforce. Advisory. Useful for enterprise programme design.

  • Model AI Governance Framework — IMDA (Second Edition): Singapore’s practical governance framework with human oversight matrices and industry examples. Advisory; not EU-binding, but operationally useful for all sizes.

  • Responsible AI Pattern Catalogue — ACM Computing Surveys: Academic catalogue of reusable governance, process, and product patterns for responsible AI. Advisory; most useful for enterprise and technical teams building pattern libraries.

  • EU AI Act Annex III — AI Act Service Desk: Official list of high-risk AI system categories under Annex III. Normative. Essential for risk classification. Relevant for all sizes.

  • ShieldIQ — EU AI Act compliance for SMEs: Practical guidance on EU AI Act obligations for SMEs, including scope, timelines, and remediation steps.

Recommended