AI Governance for EU AI Act Compliance: The SMB Operating Model

AI governance is the set of policies, roles, processes, and controls an organisation puts in place to manage its AI systems responsibly and in accordance with applicable law. Under Regulation (EU) 2024/1689 — the EU AI Act — governance is not optional for organisations that build or deploy AI in high-risk contexts. It is a pre-market requirement enforced by national competent authorities, backed by fines reaching €15 million or 3% of worldwide annual turnover for most high-risk obligation failures.

This guide explains what an AI governance programme actually looks like for a small or medium-sized company in 2026: who owes what, which Articles map to which obligations, how to staff a minimal governance function, and what documents you need to have ready. Where appropriate, it signals how the rules interact with ISO/IEC 42001 and GDPR, and points to where Confir's rule-based compliance tools fit in.

---

Why the EU AI Act Makes Governance Non-Optional

Most SMBs believe the EU AI Act is an enterprise problem — something for large banks and hospital systems. The Act's scope does not work that way.

The Act applies to any provider that places an AI system on the EU market or into service, regardless of where the provider is established. It applies to any deployer that uses a covered AI system in a professional context within the EU. A 30-person German HR-tech firm shipping a CV-screening tool to Dutch and Spanish customers is a provider. A 50-person Belgian insurance broker deploying a third-party credit-risk model is a deployer. Both owe governance obligations.

The timeline is concrete. Prohibited practices under Article 5 applied from 2 February 2025. General obligations — including transparency for limited-risk systems under Article 50 — apply from 2 August 2026. For the full high-risk stack (Articles 9–15, 16–27, 43, 47–49, 72–73), the original deadline was also 2 August 2026, but the Digital Omnibus, on which Parliament and Council reached political agreement on 7 May 2026, deferred that date. Stand-alone high-risk AI systems covered by Annex III — recruitment, credit, biometrics, law enforcement, and the rest — must comply by 2 December 2027. High-risk AI embedded as safety components in products subject to EU product regulation (Annex I) must comply by 2 August 2028.

That sounds like distance. It is not. Assembling the Article 11 / Annex IV technical file for a single system, standing up an Article 9 risk management system, running an Article 43 conformity assessment, and registering in the EU database can easily take nine to twelve months of structured work. If you are building, acquiring, or deploying any system that touches Annex III categories, governance design should start now.

---

Who Must Govern: Provider vs Deployer Under the Act

The EU AI Act assigns obligations by role, not by industry. Getting your role right is the first governance decision.

Providers (Article 16) are entities that develop a high-risk AI system and place it on the EU market — or put it into service — under their own name or trademark. Providers shoulder the heaviest obligations: they must implement a full Article 9 risk management system, compile Article 11 technical documentation, embed Article 14 human oversight capabilities in the system design, maintain an Article 17 quality management system, carry out or commission an Article 43 conformity assessment, issue an Article 47 EU declaration of conformity, apply CE marking (Article 48), and register the system in the EU database (Article 49). Post-market, they must run Article 72 monitoring and report serious incidents under Article 73.

Deployers (Article 26) are organisations that use a high-risk AI system in a professional context under their own authority. Their obligations are lighter but not trivial. Deployers must follow the provider's instructions for use, ensure Article 14 human oversight is implemented in their operational workflow, keep the logs that Article 12 prescribes (for three years in most cases), inform their own workers when AI is used in monitoring them, conduct an Article 27 Fundamental Rights Impact Assessment (FRIA) if they are a public-sector body or certain regulated private operators, and report incidents upward to the provider.

The boundary shifts under Article 25. A deployer that puts its own name on a high-risk system, substantially modifies it, or changes its intended purpose becomes a provider — and inherits the full provider obligation stack. This is the single most dangerous trap for SaaS companies that integrate third-party AI models and then resell the output under their own product brand.

In practice, most SMBs divide into two groups: SaaS or tech companies that build and ship AI systems under their own brand (providers) and businesses that subscribe to and deploy third-party AI tools (deployers). The governance operating model is shaped by which group you are in — but both need a functioning programme.

---

The Governance Obligation Map: Article by Article

A well-designed AI governance programme maps each obligation to a concrete process owner, a set of controls, and a documented output. Here is the full high-risk obligation set with the correct Article references.

Article 9 — Risk Management System

The risk management system is a continuous, lifecycle-spanning process, not a one-time assessment. Article 9 requires providers to identify and analyse known and foreseeable risks associated with the high-risk system's intended purpose and reasonably foreseeable misuse; to estimate and evaluate risks when the system is deployed in accordance with its intended purpose and under conditions of reasonably foreseeable misuse; to adopt risk elimination or mitigation measures; and to test residual risk against the user population, including sub-groups that might be disproportionately affected.

Critically, Article 9 requires that residual risk — after mitigation — is judged acceptable by a responsible human before the system goes live. That judgment must be documented.

Governance outputs: a live risk register, version-controlled for each system release, linking each identified risk to its mitigation, its owner, and the residual-risk acceptance decision.

Article 10 — Data and Data Governance

Article 10 covers training, validation, and testing data. Providers must apply appropriate data governance practices: data collection and origin, data preparation (labelling, cleaning, enrichment, aggregation), an assessment of availability, quantity, and suitability, an analysis for possible biases, and measures to address those biases. The data must be relevant, sufficiently representative, and free of errors to the extent possible.

This Article is commonly mislabelled as staff training. It is not. Staff competence is a separate obligation under Article 4 (AI literacy), which has applied since 2 February 2025 and requires organisations to ensure their staff who work with AI systems have an appropriate level of AI literacy — relevant to their role and the risk involved.

Governance outputs: a data governance policy covering each training dataset; bias analysis records; a staff AI literacy register showing which roles have received what training and when.

Article 11 — Technical Documentation

Article 11 requires providers to compile technical documentation before placing a high-risk system on the market, and to keep it updated. The specification is in Annex IV. It includes: a general description of the system and its intended purpose; the design process including design choices, assumptions, and testing results; information on monitoring, operation, and control; descriptions of validation and testing; standards applied; and a copy of the EU declaration of conformity. A system that changes materially requires a documentation update.

In notified-body conformity assessment scenarios (required for some Annex III categories, such as biometrics used by law enforcement), the technical file is what the notified body reviews. Getting this wrong is not a technicality — it is grounds for refusing to issue a certificate.

Governance output: a maintained Annex IV technical file for each high-risk system, version-controlled and traceable to the assessed system version.

Article 12 — Logging and Record-Keeping

Article 12 requires that high-risk AI systems have automatic logging capability to allow for traceability of their operation throughout their lifecycle. The Act specifically requires that logs allow, to the extent proportionate to the risk, the identification of situations that may give rise to risks or trigger a need for post-market monitoring actions.

Deployers must retain logs for three years. Providers must retain their own logs in line with Article 72 post-market monitoring obligations.

Governance output: an immutable audit log for each system, with defined retention policy and access controls.

Article 13 — Transparency and Information to Deployers

Article 13 requires providers to give deployers sufficient information about the system's intended purpose, the level of accuracy and its limitations, any known or foreseeable circumstances that may lead to risks to health, safety, or fundamental rights, and the human oversight measures the system is designed to accommodate. This information must be provided in the instructions for use.

For deployers, this Article is important in a different way: it is the legal basis on which you can demand substantive information from your AI vendor. If a vendor cannot or will not supply an Article 13-compliant instruction set, that is a supply-chain red flag with legal consequences.

Governance output: a reviewed and filed instruction-for-use document for every deployed system; for providers, a compliant instructions-for-use document shipped with the product.

Article 14 — Human Oversight

Article 14 requires that high-risk AI systems be designed and deployed so that natural persons can effectively oversee them. In practice this means the system must be capable of being stopped or overridden by a human; users must be able to understand what the system does and recognise anomalies; and there must be someone designated who has the authority and competence to intervene. The old version of this article throughout the prior text was incorrectly attributed to "Article 6" — the correct Article is 14.

For deployers, Article 14 is operational: it is not enough to have an override button. You must ensure the humans operating the system actually have the context to use it meaningfully — which connects back to the Article 4 AI literacy obligation.

Governance output: human oversight procedures specific to each deployed system; a designated oversight responsible; logged records of human review, override, and escalation decisions.

Article 15 — Accuracy, Robustness, and Cybersecurity

Article 15 sets performance requirements: high-risk AI systems must achieve an appropriate level of accuracy, robustness, and cybersecurity, and they must perform consistently throughout their lifecycle. It also requires resilience against attempts by third parties to alter the system's outputs through adversarial inputs.

This is the technical engineering obligation. It is not post-market monitoring — that is Article 72. Article 15 is about building the system correctly: defining accuracy benchmarks, adversarial robustness testing protocols, and failure-mode analysis before launch.

Governance output: test records for accuracy and robustness; documented performance baselines; cybersecurity assessment.

Article 17 — Quality Management System

Providers must establish a quality management system (QMS). Article 17 specifies its minimum content: a strategy for compliance, including design verification and validation procedures; procedures for monitoring compliance of deployed systems; procedures for serious incident reporting; data management practices; cybersecurity controls; and internal audit procedures.

The QMS is the organisational backbone of the governance programme. It does not need to be ISO 9001 certified, but it must be documented, reviewed regularly, and capable of demonstrating systematic compliance rather than one-off efforts.

Governance output: a written QMS covering the Article 17 elements; records of QMS audits and reviews.

Article 43 — Conformity Assessment

Before placing a high-risk AI system on the market, providers must carry out a conformity assessment. Article 43 specifies two paths. For most Annex III categories, internal conformity assessment is permitted: the provider conducts the assessment itself, documents it in the technical file, and issues the EU declaration of conformity. For certain high-sensitivity categories — notably remote biometric identification systems deployed by law enforcement — a third-party notified body is required.

The old text attributed conformity assessment to "Article 27". That is wrong. Article 27 is the Fundamental Rights Impact Assessment — a separate obligation for certain deployers. Conformity assessment is Article 43.

Governance output: a completed conformity assessment record within the Article 11 technical file; the Article 47 EU declaration of conformity; CE marking applied to the system.

Articles 47–49 — Declaration, CE Marking, Registration

Article 47 requires providers to issue an EU declaration of conformity before market placement — a signed document declaring that the system conforms to the Act's requirements. Article 48 requires the CE marking to be affixed, which signals to the market and regulators that the system has been assessed. Article 49 requires registration in the EU AI Act database, an EU-hosted public register maintained by the Commission.

For deployers of high-risk systems deployed by public sector bodies, Article 49(2) imposes its own registration obligation.

Governance output: signed and dated EU declaration of conformity; registration record with the EU database entry reference.

Article 72 — Post-Market Monitoring

Article 72 places a continuing obligation on providers to actively collect and review data on the performance of high-risk systems after they are on the market. Providers must have a post-market monitoring plan, and where performance issues emerge, they must update risk documentation and take corrective action. The Act does not specify a minimum monitoring frequency, but the monitoring plan should be calibrated to the risk level and deployment volume.

This was incorrectly attributed to "Article 15" and "Article 26" in older content. Article 15 is about pre-launch technical requirements; Article 26 is about deployer obligations. Post-market monitoring by providers is Article 72.

Governance output: a post-market monitoring plan; periodic monitoring reports; version-controlled updates to the Article 11 technical file where issues arise.

Article 73 — Serious Incident Reporting

Article 73 requires providers to report serious incidents — defined as incidents that cause or could cause death, serious harm to health, property damage, or interruptions to critical services, or that constitute a serious breach of fundamental rights — to the relevant national authority. The reporting deadline is defined by category: immediately for life-threatening incidents, fifteen calendar days for other serious incidents, and within three months for serious-incident sequences that emerge over time.

Deployers must report serious incidents to the provider, not directly to the authority (unless the provider is outside the EU and has no authorised representative, or unless the deployer itself is a public sector body).

Governance output: an incident classification matrix; a reporting workflow; documented incident reports filed with timestamps.

---

Governance Roles and a Minimal RACI

A governance programme needs named owners, not just policies. The table below shows the minimal role structure for an SMB — all five functions can be covered by two or three people in a 40-person company, provided those people have sufficient AI literacy under Article 4.

In organisations without a dedicated compliance function, the DPO (where one exists under GDPR) is the natural anchor. The DPO role does not automatically extend to AI Act compliance, but the overlap in data governance, risk assessment, and record-keeping is substantial enough that combining the functions is usually the pragmatic starting point.

One role to watch: if you have an AI system that processes personal data and makes or materially contributes to decisions about individuals, you almost certainly need both a GDPR Article 35 Data Protection Impact Assessment and an EU AI Act risk assessment. These can be run in parallel with shared inputs, but they are legally distinct documents. If the system is high-risk and deployed by a public-sector body, Article 27 adds a third layer — the Fundamental Rights Impact Assessment.

---

The Five Governance Artifacts You Must Have

1. AI Inventory

Every AI system your organisation builds or deploys, regardless of risk level. At minimum: system name, vendor (if external), version, intended purpose, data inputs, deployment context, classification result (risk tier and role), Article 6(3) filter assessment if applicable, and the name of the accountability owner.

The inventory is the foundation everything else rests on. Without it, you cannot tell which systems are in scope, and you cannot demonstrate to an auditor that you have a systematic view of your AI footprint.

2. Risk Register

For each high-risk system, the Article 9 risk register documents: the identified risk, its probability and severity estimate, the mitigation measures adopted, the residual risk level after mitigation, the human who accepted the residual risk, and the date of acceptance. It should be updated at each material system change and reviewed at least annually.

The risk register is not the same as a GDPR risk register. The subject matter overlaps — both cover risks to individuals — but the Article 9 register must also address technical safety risks, robustness failures, and foreseeable misuse scenarios that go beyond personal data.

3. Technical File (Annex IV Pack)

The Article 11 technical file is the compliance backbone for high-risk systems. It contains everything an auditor or notified body needs to assess conformity: the system description, design decisions, data governance records (Article 10), test results (Article 15), the risk register (Article 9), human oversight procedures (Article 14), the QMS reference (Article 17), and the conformity assessment record (Article 43). The technical file must be kept for ten years after the system is placed on the market or put into service.

4. Audit Log

Article 12 requires automatic logging. The governance programme must specify what gets logged, where, for how long, and who has access. For most high-risk systems, this means logging each decision event (input, output, timestamp, user ID), each human override (with rationale), and each system configuration change. The log must be tamper-evident — not just a spreadsheet someone can edit.

5. Governance Policies

At minimum: an AI use policy that defines what AI tools staff may use and under what conditions; a data governance policy covering Article 10 training data requirements; a human oversight procedure for each high-risk system; and an incident response procedure that connects Article 73 reporting obligations to operational reality. These do not need to be long documents. They need to be specific, owned, and actually followed.

---

Worked Example: A 45-Person HR-Tech Firm Deploying a CV-Screening Tool

A 45-person HR-tech company based in Munich develops a candidate-screening product that parses CVs and ranks applicants for its clients. The clients are European employers in retail, logistics, and financial services. The company places the product on the market under its own brand.

Step 1: Determine role and classification. The company is a provider under Article 16. The product falls within Annex III, heading 4 (employment, workers management, access to self-employment — specifically recruitment screening and shortlisting). Under the Article 6(3) filter: the system makes a ranked shortlist that a human recruiter then reviews. Does it profile natural persons? Yes — it evaluates candidates individually against job criteria. That makes the Article 6(3) exemption unavailable. The system is high-risk.

Step 2: Scope the obligation set. As a provider of a high-risk system in Annex III, the company must comply with Articles 9, 10, 11, 12, 13, 14, 15, 16, 17, 43, 47, 48, 49, 72, and 73. Its clients, as deployers, owe Article 26 obligations — and the company's Article 13 instructions-for-use must equip them to do so.

Step 3: Build the technical file. The product team documents the model architecture, the training data (sourcing, preprocessing, bias analysis across gender, age, and nationality), validation test results across demographic subgroups, and the known limitations. The risk register identifies three material risks: gender bias from historical hiring patterns in the training data; age bias from tenure-length weighting; and performance degradation when the applicant pool is outside the languages represented in training data. Mitigations are documented; residual risk decisions are signed by the Head of Product.

Step 4: Design human oversight. The system surfaces a ranked shortlist. Article 14 requires that the deployer (the employer client) can meaningfully oversee this. The provider builds an explanation interface showing which factors influenced each candidate's ranking. Its Article 13 instructions-for-use specify that deployers must have a designated HR reviewer who has completed AI literacy training, and that no applicant should be rejected solely on the system's ranking. The instructions specify a minimum review threshold: every candidate in the top 30% of the ranking must be reviewed by a human before rejection.

Step 5: Conformity assessment and registration. Internal conformity assessment is available for Annex III recruitment systems (a notified body is not mandated). The company runs the assessment, documents it in the technical file, issues the Article 47 declaration of conformity, applies CE marking, and registers the system in the EU database before the 2 December 2027 deadline.

Step 6: Post-market monitoring. The company's Article 72 monitoring plan specifies quarterly reviews of system performance across the demographic groups identified in the risk register. If bias metrics deteriorate beyond the defined thresholds, a model update is triggered and the technical file is updated accordingly.

Article 4 in practice. The company's two compliance officers and its product team have completed an AI literacy programme calibrated to their roles: the compliance officers understand the obligation structure; the product team understands the technical requirements; client-facing staff can explain to deployer clients what the system does and what their Article 26 obligations are.

The deadline for all of this: 2 December 2027 for stand-alone Annex III systems. The company should not treat that as slack — a materially modified version of the product will require a fresh conformity assessment cycle.

---

Your First 90 Days: A Governance Build Plan

Governance programmes fail not because the rules are complicated but because no one starts. Here is a pragmatic 90-day sequence that a two-person compliance function at an SMB can follow.

Days 1–30: Inventory and classify

Run a cross-functional workshop — engineering, product, legal, procurement — and list every AI system the organisation builds or deploys. For each system, apply the Article 5 and Article 6 classification logic: does it fall within an Annex III category? Does the Article 6(3) filter apply? What role does the organisation have? Output: a completed AI inventory with risk tiers and roles assigned. Flag any potential Article 5 prohibited practices for immediate legal review — those obligations have been live since February 2025.

Days 31–60: Gap assessment against the obligation set

For each high-risk system, map existing documentation and processes against the Articles 9–15, 17, 43, 47–49, 72–73 obligation set. Where is there nothing? Where is there something that would not survive regulatory scrutiny? Prioritise gaps by deadline and by the severity of non-compliance exposure. Output: a gap analysis per system, with remediation priorities and owners.

Days 61–90: Close the highest-priority gaps

Stand up the risk register structure (Article 9). Initiate the technical file collection process (Article 11, Annex IV). Draft the human oversight procedure for the highest-risk system (Article 14). Define the logging architecture (Article 12). Draft the QMS outline (Article 17). Assign governance roles using the RACI in this guide. Output: draft governance artefacts for the first system, reviewed by legal.

After 90 days you should have visibility of your full AI footprint, a documented gap analysis, and draft artefacts for your most exposed system. That is not full compliance — but it is a defensible governance programme under construction, which is materially different from nothing.

---

Multi-Framework Alignment: ISO 42001, GDPR, and the Act Together

The EU AI Act is not the only framework that governs AI. For most SMBs, at least two of these three are relevant simultaneously.

ISO/IEC 42001 is the international standard for AI management systems. It defines the elements of an AI management system: organisational context, leadership, planning, support, operation, performance evaluation, and improvement — the classic Annex SL structure. ISO 42001 does not mirror the EU AI Act article-by-article, but there is substantial overlap. An ISO 42001-aligned AI management system covers risk management, data governance, human oversight, and monitoring in ways that map closely to Articles 9, 10, 14, and 72. If your organisation is already ISO 27001 certified, extending to ISO 42001 is a lower-effort path than building EU AI Act compliance in isolation.

GDPR Article 22 covers automated individual decision-making: where a decision is based solely on automated processing and produces legal or similarly significant effects, the data subject has rights including the right to human review. Article 22 is directly relevant to high-risk AI governance because many Annex III systems (recruitment, credit, benefits eligibility) produce exactly these effects. Your Article 14 human oversight design must be consistent with the Article 22 right-to-human-review obligation — if they conflict, you have a compliance gap in both regimes.

GDPR Article 35 — Data Protection Impact Assessment — is required when processing is likely to result in high risk to the rights and freedoms of natural persons. Large-scale processing of special categories of data, systematic monitoring of publicly accessible areas, and automated decision-making with significant effects all trigger Article 35. The inputs to a DPIA and an Article 9 risk assessment overlap substantially: purpose, data sources, risk to individuals, mitigation measures. Running them in parallel, with a shared risk taxonomy, is more efficient than running them sequentially.

One practical note: if you are ISO 42001 certified and GDPR-compliant with documented DPIAs for relevant systems, you will enter an EU AI Act audit with substantially more evidence than an organisation starting from scratch. The certifications are not a substitute for Article 43 conformity assessment, but they demonstrate systematic governance that regulators are instructed to take into account when calibrating proportionate enforcement.

---

How Confir Helps

Building and maintaining the governance artefacts above manually is time-consuming and error-prone. The calculations — which Annex III category, which Article 6(3) exemptions apply, which obligation set follows — are rule-bound and mechanical, and getting them wrong has material consequences.

Confir encodes the EU AI Act's classification and obligation logic in explicit, deterministic rules — the same inputs always produce the same outputs, with the reasoning visible and auditable. There is no AI inference involved; the engine is rule-based by design, which matters for a compliance product where reproducibility and explainability are properties regulators and auditors require.

In practice, Confir covers the governance workflow across four structured compliance areas: AIRC (Risk Classification and Compliance — Articles 5, 6, 43, 50), AITR (Data and Technical Robustness — Articles 10, 11, 15), AITO (Transparency and Human Oversight — Articles 13, 14, 27, 50), and AIGM (Governance and Post-Market Monitoring — Articles 9, 72, 73). For each system you register, the tool runs you through plain-English scenarios, derives your risk tier and role, and drives the structured assessment across all four areas.

The outputs are the artefacts this guide has been describing: the AI inventory and risk register, the Article 11 / Annex IV technical documentation pack (the "Conformity Package"), the Article 47 EU Declaration of Conformity, the Article 27 FRIA for qualifying deployers, the Compliance Health Score showing where gaps remain, and an immutable audit log. It cross-maps to ISO/IEC 42001, NIST AI RMF, and GDPR.

Self-serve, no consultants, EU-hosted, from €600 per year.

---

Frequently Asked Questions

What exactly is AI governance under the EU AI Act?

AI governance under Regulation (EU) 2024/1689 is the documented system of policies, roles, processes, and controls an organisation uses to manage its AI systems in compliance with the Act. For high-risk AI systems, the governance programme must cover at minimum: a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), accuracy and robustness (Article 15), and a quality management system (Article 17). Governance is a precondition for the conformity assessment (Article 43) that must be completed before a high-risk system reaches the market.

When does my organisation actually have to comply?

It depends on your AI system's category. Prohibited practices under Article 5 applied from 2 February 2025. Obligations for limited-risk systems under Article 50 apply from 2 August 2026. For stand-alone high-risk AI systems in Annex III — the list covering recruitment, credit, biometrics, law enforcement, and others — the deadline is 2 December 2027, deferred from the original 2 August 2026 date under the Digital Omnibus agreed in May 2026. High-risk AI embedded in regulated products (Annex I) must comply by 2 August 2028. Article 4 AI literacy has applied since 2 February 2025 and requires appropriate AI literacy for staff who work with AI systems.

What is the difference between a provider and a deployer for governance purposes?

A provider (Article 16) develops and places the AI system on the market. Providers owe the full obligation set: risk management, technical documentation, conformity assessment, registration, QMS, and post-market monitoring. A deployer (Article 26) uses a high-risk system in a professional context. Deployers must implement human oversight in their operations, maintain logs, and in some cases run a Fundamental Rights Impact Assessment (Article 27). If your organisation substantially modifies a third-party system or rebrands it as your own product, Article 25 converts you from deployer to provider — with all provider obligations following.

What are the penalties for failing AI governance obligations?

The fine ceiling for failing high-risk obligations — including risk management, technical documentation, human oversight, and QMS requirements — is €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99). Breaching the Article 5 prohibitions (banned practices, which have applied since February 2025) carries a higher ceiling: €35 million or 7%. Supplying incorrect information to a notified body or authority carries a ceiling of €7.5 million or 1%. SMEs and start-ups benefit from a proportionality cap under Article 99(6): their fine is limited to the lower of the percentage or the fixed amount.

Does my company need a dedicated AI governance officer?

The EU AI Act does not mandate a specific governance role title. What it does require, functionally, is that someone is accountable for maintaining the risk management system (Article 9), the QMS (Article 17), and the post-market monitoring programme (Article 72), and that someone ensures Article 4 AI literacy is in place across the workforce. For most SMBs, this is the DPO, Head of Compliance, or a senior product leader. The governance accountabilities in the RACI above can be distributed across two or three people in a company of 40–50. What you cannot afford is the governance function being informal — auditors will ask for named owners and documented procedures.

Does AI governance overlap with GDPR?

Substantially, yes. Any high-risk AI system that processes personal data to make or inform decisions about individuals triggers both regimes. GDPR Article 35 (Data Protection Impact Assessment) and EU AI Act Article 9 (risk management) share inputs and analysis. GDPR Article 22 (automated decision-making with significant effects) directly interacts with the Article 14 human oversight requirement. Running these assessments in parallel — with a shared risk taxonomy and linked documentation — reduces duplication and closes gaps in both regimes simultaneously. They are separate legal documents, but the effort to produce them converges significantly when organised properly.

Can the Article 6(3) filter exempt my system from high-risk classification?

Possibly. Article 6(3) provides that a system falling within an Annex III area is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — for example, because it performs a narrow procedural task, improves the output of a previously completed human activity, or detects decision patterns without replacing or influencing human assessment. However, any system that profiles natural persons is always high-risk regardless of the filter. And providers claiming the exemption must document the assessment and register the system — the filter does not eliminate the compliance obligation; it reclassifies it. If you are wrong about the exemption and have not documented your reasoning, you will face both a classification failure and a record-keeping failure in an audit.

---

Related guides

• compare EU AI Act compliance solutions
• AI governance software comparison