Skip to content
SimpleAct Logo

Guide · AI governance

As of 3 October 2026 · after the Digital Omnibus

AI Governance Framework: Roles, RACI and Approval

Who decides whether an AI tool may be used? Who assesses the risk, who trains staff, who reports incidents? An AI governance framework answers these questions once and properly – with six building blocks, a RACI matrix, an approval workflow and a plan for the first 90 days. Everything on this page is free to use.

Check your maturityGo to the RACI matrix
  • 6 building blocks with outputs
  • RACI matrix for 12 tasks
  • Mapping AI Act ↔ GDPR ↔ ISO 42001
  • Roll-out in 90 days
app.simpleact.de

AI governance

Demo Organisation Ltd · Overview

A

Building blocks

  • AI policy
  • Roles & committee
  • AI register
  • Approval workflow
  • Operations & incidents
  • Literacy & evidence

Approval: applicant screening tool

  1. Request
  2. Pre-check
  3. Classify
  4. Privacy
  5. Measures
  6. Approve

Example data · next review in 42 days

In short

AI governance is the set of rules a company uses to steer which AI it uses and for what: an AI policy, clear roles, an AI register, an approval process, rules for operations and incidents, and training and evidence. The AI Act does not prescribe a framework by that name – but without one its obligations are hard to meet in a way you can prove.

Basics

What AI governance is – and what the AI Act actually requires

AI governance describes how an organisation makes and follows up on decisions about artificial intelligence: Who may request a new AI tool? Against which criteria is it assessed? Who approves it, who monitors its operation, and what happens when something goes wrong? An AI governance framework brings the answers together in a fixed structure – policy, roles, processes and evidence.

To be clear from the start: the AI Act (Regulation (EU) 2024/1689) has no article requiring every company to have an "AI governance framework". It assigns concrete obligations to roles and systems. Deployers – organisations using AI under their own authority (Art. 3(4)) – must, for example, take measures to support the AI literacy of their staff (Art. 4), avoid prohibited practices (Art. 5), observe transparency obligations (Art. 50) and, for high-risk AI, meet the deployer obligations in Art. 26 – such as human oversight by competent people, monitoring of operation and keeping logs for at least six months.

Providers of high-risk AI go further: they need a risk management system (Art. 9) and a documented quality management system (Art. 17) that explicitly includes an "accountability framework" setting out the responsibilities of management and staff. Anyone who puts their name on someone else's high-risk system, substantially modifies it or changes its intended purpose so that it becomes high-risk can become a provider themselves (Art. 25).

On top of that comes the GDPR, which applies to almost every AI use: accountability (Art. 5(2)), the controller's responsibility including reviewing and updating measures (Art. 24), data protection by design (Art. 25), records of processing (Art. 30), data protection impact assessments (Art. 35) and processing agreements (Art. 28). An AI governance framework bundles all of this so that departments do not invent their own rules and, in the end, nobody knows which AI is running in the company.

Governance is more than compliance. Compliance asks: do we meet the rules? Governance asks: who decides, on what criteria, and how do we make sure the decision is still right tomorrow? That pays off even without the threat of fines – less shadow AI, faster approvals and solid answers when customers, works councils or auditors ask.

building blocks every framework needs
6
building blocks every framework needs
tasks in the RACI matrix
12
tasks in the RACI matrix
days to a workable foundation (recommendation)
90
days to a workable foundation (recommendation)

Structure

The 6 building blocks of an AI governance framework

These six building blocks have proven themselves in practice. They are our recommendation, not a structure laid down in law. Each one produces a tangible output – exactly what you show when someone asks how you keep AI under control.

01

AI policy

The policy sets out what AI may be used for in the company, which data is off-limits, which tools are approved and how new tools are requested. Two to five pages are enough – what matters is that it is understandable and actually applies. In Germany, where AI could be used to monitor behaviour or performance, works council co-determination may apply (e.g. Section 87(1) no. 6 BetrVG); check your national rules.

  • Adopted AI policy
  • List of approved and prohibited tools
  • Rules for confidential and personal data

Art. 4, 5 AI Act · Art. 24 GDPR

02

Roles and committee

Name one person responsible for AI governance and clarify who the system owners in the business units are. Larger organisations also set up a small AI committee with IT, data protection, legal, the business and, where relevant, employee representatives. The RACI matrix further down records who decides what.

  • Named AI governance lead
  • System owner per AI system
  • RACI matrix confirmed by management

Art. 26(2) AI Act · Art. 38 GDPR

03

AI register and risk classification

The AI register lists every AI system with its purpose, role (deployer or provider), risk class and owner. Without this list you cannot assign any of the other obligations. Classification follows a fixed order: prohibited practice? High-risk under Annex III or Annex I? Transparency obligation? Otherwise minimal – each with a short rationale.

  • Complete AI register
  • Risk class with rationale per system
  • Link to records of processing and DPIA where needed

Art. 5, 6, 50 AI Act · Art. 30 GDPR

04

Approval workflow

No new AI tool and no new purpose without approval. A fixed path from request to go-live prevents tools from being introduced "just to try" and surfacing months later. Uncritical tools can take a lean route; high-risk and borderline cases go through every step.

  • Request form for new AI use cases
  • Documented go/no-go decision
  • Conditions and review date per approval

Art. 6(3) and (4), Art. 26 AI Act · Art. 35 GDPR

05

Operations, changes and incidents

After go-live the real work begins: spot-checking outputs, keeping logs, assessing vendor changes, reporting incidents. For high-risk AI, Art. 26(5) requires monitoring on the basis of the instructions for use and informing the provider without undue delay of serious incidents.

  • Monitoring and logging concept
  • Change and re-assessment rule
  • Incident process including the GDPR notification route

Art. 26(5) and (6), Art. 73 AI Act · Art. 33 GDPR

06

Literacy and evidence

Since the Digital Omnibus, Art. 4 requires providers and deployers to take measures to support the AI literacy of their staff – no particular level has to be guaranteed. Record who received which training or briefing and keep the evidence for every building block in one place.

  • Training plan per user group
  • Attendance records
  • Annual governance report to management

Art. 4 AI Act (amended) · Art. 5(2) GDPR

RACI matrix

Who does what? The AI governance RACI matrix

A RACI matrix assigns to each task who carries it out (R), who is ultimately accountable and decides (A), who is consulted (C) and who is informed (I). Each task should have exactly one A. The matrix below is a proposal for a mid-sized company – adapt the roles and assignments to your organisation.

Scroll the table sideways →

Who does what? The AI governance RACI matrix
TaskManagementAI governance leadBusiness unit / system ownerIT & information securityData protection officerWorks council / HR
Draft and adopt the AI policyArt. 4, 5 AI ActARCCCC
Maintain the AI registerBasis for all obligationsIARCC–
Request a new AI use caseInternal process–IA/RCI–
Classify the risk under the AI Act and document whyArt. 5, 6, 50 AI ActIA/RCCC–
Privacy review, DPIA where neededArt. 35, Art. 39(1)(c) GDPRACRCC–
Make the approval decision (go/no-go)Internal processARCCCI
Assign human oversight (high-risk)Art. 26(2) AI ActICA/RC–I
Inform workers (high-risk AI at the workplace)Art. 26(7) AI ActARC–IC
AI literacy: plan and record trainingArt. 4 AI ActARCCCC
Monitor operation, keep logsArt. 26(5) and (6) AI Act–IARI–
Assess and report incidentsArt. 26(5), Art. 73 AI Act · Art. 33 GDPRARRRCI
Annual review and report to managementArt. 24(1) GDPR (by analogy)ARCCCI
  • RResponsible – carries out the task
  • AAccountable – owns and decides
  • CConsulted – asked for input beforehand
  • IInformed – told about the result
  • Data protection officers advise and monitor (Art. 39 GDPR). They should therefore not decide on approvals themselves – other tasks must not result in a conflict of interests (Art. 38(6) GDPR). That is why their column only shows C or I.
  • Works council: whether co-determination rights apply depends on the case, for example in Germany where an AI system is designed to monitor behaviour or performance (Section 87(1) no. 6 BetrVG). The "C" here means early involvement, not a legal assessment.
  • For uncritical tools, management can delegate the approval (A) to the AI governance lead. High-risk and borderline cases should stay with management.

Approval workflow

From use case to go-live in 7 steps

This is how a new AI use case runs through your framework. Steps marked "Gate" are decision points: you only move on once the result is documented. For uncritical standard tools you can merge steps – for high-risk AI you cannot.

  1. 1

    Submit the request

    The business unit describes the tool, vendor, purpose, user group, affected people and data. A form with ten mandatory fields is enough. The purpose matters most, because the risk class depends on it.

    Who
    Business unit
    Output
    Complete request
    Basis
    Internal process
  2. 2

    Pre-check

    Gate

    The AI governance lead checks whether it is an AI system at all, whether a prohibited practice under Art. 5 could be involved and which role you take: deployer or – for example with in-house development or resale under your own name – provider.

    Who
    AI governance lead
    Output
    Role and prohibited practices ruled out
    Basis
    Art. 3(1), (3), (4); Art. 5; Art. 25 AI Act
  3. 3

    Risk classification

    Does the purpose fall under Annex III, or is the system a safety component of a product under Annex I? If the provider relies on the Art. 6(3) exception, it must document its assessment (Art. 6(4)) – as a deployer, ask to see it. Are there transparency obligations under Art. 50? The result goes into the AI register with a rationale.

    Who
    AI governance lead, business unit
    Output
    Risk class with rationale
    Basis
    Art. 6, 50, Annex III AI Act
  4. 4

    Privacy and contracts

    If personal data is processed: create an entry in the records of processing, clarify the legal basis, review the processing agreement with the vendor, assess third-country transfers and carry out a DPIA where a high risk is likely. The data protection officer advises.

    Who
    Business unit, data protection, purchasing
    Output
    Records of processing, DPA, DPIA where needed
    Basis
    Art. 28, 30, 35 GDPR
  5. 5

    Define measures

    Classification and privacy review lead to measures: a notice for a chatbot, training for the user group, rules for input data, an oversight concept and log retention for high-risk AI, informing workers before use at the workplace.

    Who
    System owner, IT
    Output
    Action list with owners
    Basis
    Art. 4, 26, 50 AI Act
  6. 6

    Approval decision

    Gate

    The responsible body decides: approved, approved with conditions or rejected. The decision is recorded with date, rationale and review date. No production use without documented approval.

    Who
    Management or delegated body
    Output
    Go/no-go with conditions and review date
    Basis
    Internal process
  7. 7

    Go-live and review

    After launch, the system owner monitors operation. Changes to the model, data sources or purpose trigger a re-assessment; incidents trigger the incident process. By the review date at the latest, the approval is confirmed or adjusted.

    Who
    System owner, IT
    Output
    Ongoing monitoring, review date
    Basis
    Art. 26(5) and (6) AI Act

The process and roles are a recommendation. The AI Act does not prescribe an internal approval process, but it does require the results such a process produces.

Mapping

AI Act, GDPR and ISO/IEC 42001 at a glance

Many requirements appear in all three frameworks – under different names. The table shows where they overlap so you can produce evidence once and use it several times. ISO/IEC 42001 is voluntary; the column only describes general elements of an AI management system, not the text of the standard.

Scroll the table sideways →

AI Act, GDPR and ISO/IEC 42001 at a glance
TopicAI ActGDPRISO/IEC 42001 (general)Evidence in practice
Responsibility and accountabilityNo general governance obligation; for providers of high-risk AI an accountability framework in the QMS (Art. 17(1)(m))Accountability (Art. 5(2)), responsibility of the controller (Art. 24)AI policy, roles, responsibilities and authoritiesAI policy, RACI matrix
InventoryIndirect: obligations attach to the individual system and its purposeRecords of processing activities (Art. 30)Scope and context of the management systemAI register linked to records of processing
Risk assessmentClassification (Art. 5, 6, Annex III); risk management system for providers of high-risk AI (Art. 9)Data protection impact assessment (Art. 35)Assessment and treatment of AI risksClassification rationale, DPIA
Fundamental rightsFundamental rights impact assessment for certain deployers (Art. 27), may refer to the DPIA (para. 4)DPIA (Art. 35)Consideration of impacts on individuals and societyFRIA or extended DPIA
Design and lifecycleRequirements for high-risk AI (Art. 9–15), mainly providersData protection by design (Art. 25)Control of the AI lifecycleRequirements catalogue, approval workflow
Human oversightOversight by competent people (Art. 14 providers, Art. 26(2) deployers)No solely automated decisions with significant effects, with exceptions (Art. 22)Roles, competence, operational controlOversight concept per system
LiteracyMeasures for AI literacy (Art. 4, amended)Awareness-raising and training, monitored by the DPO (Art. 39(1)(b))Competence and awarenessTraining plan, attendance records
Logs and documentationRecord-keeping (Art. 12); deployers keep logs for at least 6 months (Art. 26(6))Storage limitation (Art. 5(1)(e)), security (Art. 32)Documented informationLogging and deletion concept
IncidentsReporting of serious incidents by providers (Art. 73), information by deployers (Art. 26(5))Notification of personal data breaches, where feasible within 72 hours (Art. 33)Nonconformities and corrective actionIncident process with both reporting routes
Suppliers and third partiesResponsibilities along the AI value chain (Art. 25)Processors (Art. 28)Third-party and supplier relationshipsSupplier review, DPA
TransparencyTransparency obligations (Art. 50), informing people affected by Annex III decisions (Art. 26(11))Information obligations (Art. 13, 14)Communication and information for interested partiesNotices, privacy information
Monitoring and improvementMonitoring by deployers (Art. 26(5)); post-market monitoring by providers (Art. 72)Review and update measures (Art. 24(1))Performance evaluation, internal audits, management review, continual improvementReview calendar, governance report

Simplified overview for orientation. Each article only applies to the roles and systems named there. After the Digital Omnibus, high-risk obligations for Annex III systems apply from 2 December 2027.

Roll-out

Introducing AI governance in 90 days

A framework does not have to start perfect – it has to run. This plan takes a mid-sized company to a workable foundation in three phases. The timings are based on experience and are a recommendation – with many high-risk cases or in-house development it takes longer.

Days 1–30

Overview and ownership

  • Management names an AI governance lead and gives a mandate and time budget
  • Collect existing AI tools: licence lists, SSO, a survey in each department
  • Create the AI register with core fields and classify entries provisionally
  • Communicate an immediate rule: no new AI tools without a request

First version of the AI register, named owners

Days 31–60

Rules and processes

  • Draft the AI policy and align it with data protection, IT and employee representatives
  • Adapt the RACI matrix and have management confirm it
  • Set up the approval workflow with a request form, run existing tools through it
  • Examine unclear and potentially high-risk cases in depth

Adopted policy, running approval process

Days 61–90

Literacy, operations, evidence

  • Run and record training per user group (Art. 4)
  • Define monitoring, log retention and the incident process for critical systems
  • Set review dates for every register entry
  • First governance report to management, measure maturity again

Documented training, review calendar, first report

After that: event-driven reviews for new tools, changes and incidents, plus a full review at least once a year (recommendation).

Interactive

Governance maturity: where does your company stand?

Twelve statements, two per building block. Answer honestly for what is practised today – not what is planned. On the right you see your maturity per building block and the three most important next steps. No data is stored or transmitted.

  1. 01PolicyThere is a written AI policy that all staff know about.
  2. 02PolicyThe policy states which data must not be entered into AI tools.
  3. 03RolesOne person is explicitly responsible for AI governance and has time for it.
  4. 04RolesEvery AI system has a named system owner in the business.
  5. 05RegisterWe have a complete AI register with purpose, role and owner.
  6. 06RegisterEvery system is classified under the AI Act – with a written rationale.
  7. 07ApprovalNew AI tools are only introduced after a defined request.
  8. 08ApprovalApprovals are documented with date, rationale and review date.
  9. 09OperationsChanges to the model, data or purpose trigger a new assessment.
  10. 10OperationsThere is an incident process covering AI failures and data breaches.
  11. 11LiteracyAll user groups have received suitable training or a briefing.
  12. 12LiteracyTraining, approvals and reviews are recorded in one central place.
app.simpleact.de

Maturity

0 of 12 answered

A

No answers yet

–

Answer the statements – your result appears here.

  • Policy0%
  • Roles0%
  • Register0%
  • Approval0%
  • Operations0%
  • Literacy0%

Your next steps

Answer the statements on the left – your most important gaps will appear here.

Self-assessment for orientation only – not legal advice and not an assessment of compliance with legal obligations.

Timeline

Which obligations apply when

Governance does not wait for the last deadline. These dates from the AI Act and the Digital Omnibus determine what your framework should cover by when.

  1. 2 Feb 2025

    Prohibited practices (Art. 5) and AI literacy (Art. 4) apply.

  2. 2 Aug 2025

    Obligations for general-purpose AI models, governance structures and penalties apply.

  3. 2 Aug 2026

    General application, including the transparency obligations under Art. 50.

  4. 2 Dec 2026

    End of the transition period for marking under Art. 50(2) for systems placed on the market before 2 Aug 2026.

  5. 2 Dec 2027

    High-risk obligations for Annex III systems, including the deployer obligations in Art. 26.

  6. 2 Aug 2028

    High-risk obligations for Annex I systems (regulated products).

As amended by the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. All AI Act deadlines →

AI governance for SMEs

Start lean: governance for small and mid-sized companies

A company with 50 employees does not need an AI committee with rules of procedure. It needs clear responsibilities and a list. This is a minimal version that still holds up (recommendation):

One responsible person

Often the head of IT or whoever coordinates data protection. What matters is a clear mandate from management, not the title.

A two-page policy

Approved tools, prohibited data, how to request, who to ask. Better short and read than long and ignored.

A register in Excel

For 5 to 20 tools a spreadsheet is enough. Our free template has all core fields and dropdowns for the risk class.

A form instead of a committee

New tools via a short request; the responsible person decides uncritical cases, borderline cases go to management.

One training round a year

A short briefing per user group plus an attendance list – that is your evidence for the measures under Art. 4.

One date in the calendar

Once a year, review the register, policy and approvals and briefly record the outcome.

The Digital Omnibus eases mainly provider obligations for SMEs and small mid-caps (simplified technical documentation, a proportionate quality management system). Deployer obligations such as Art. 4, 5 and 50 apply regardless of company size.

Free AI register template (Excel)

Common mistakes

Where AI governance fails in practice

Policy without process

A nice policy on the intranet changes nothing if purchasing and IT still enable new tools without review. Tie orders and licences to the request.

Classifying the product, not the purpose

"ChatGPT is minimal risk" is only true for a specific use. If someone uses the same tool to select applicants, an Annex III case can arise. One row per purpose.

DPO as decision-maker

DPOs should advise and monitor. If they approve tools, they end up monitoring their own decisions – a conflict of interests under Art. 38(6) GDPR looms.

Check once, never again

Vendors change models and features all the time. Without a re-assessment rule and review dates, every approval is outdated within months.

Works council too late

Involving employee representatives only at go-live stalls projects. For high-risk AI at the workplace, informing them beforehand is mandatory anyway (Art. 26(7)).

Scattered evidence

Training lists in an HR folder, approvals in emails, the DPIA with data protection: when someone asks, the search begins. Keep evidence per AI system.

With SimpleAct

The framework as software instead of a binder

SimpleAct brings the building blocks together in one place: an AI inventory with risk classification and owners, approvals with reviewer and approver, deadlines and reminders, evidence and audit history, and export. The RACI logic on this page maps directly onto roles in the system.

  • AI inventory with risk classification
  • Approvals with reviewer and approver
  • Reminders for review dates
  • Audit history and export

PDF: AI governance checklist

Practical checkpoints for roles, approvals and evidence, ready to print.

Open-Source Framework

simpleact-ai-governance-framework

Open-source AI governance framework for the EU AI Act: roles, responsibilities, control structures, and operational governance paths.

View on GitHub

FAQ

Frequently asked questions about AI governance

With three things in the first weeks: management names a responsible person and gives them a mandate. That person collects every AI tool already in use, including unreported ones (shadow AI), and records them in a simple register. And from now on: no new AI tools without a short request. Everything else is in the 90-day plan above. Smaller companies can use the minimal version under “Start lean”.
An AI governance framework is the fixed structure a company uses to steer its use of AI: an AI policy, clear roles (often as a RACI matrix), an AI register with risk classification, an approval process for new use cases, rules for operations, changes and incidents, and training and evidence.
Not under that name. The AI Act sets concrete obligations per role and system, such as measures for AI literacy (Art. 4), avoiding prohibited practices (Art. 5), transparency obligations (Art. 50) and deployer obligations for high-risk AI (Art. 26). Providers of high-risk AI need a quality management system with an accountability framework (Art. 17). A governance framework is the practical way to meet these obligations in a way you can prove.
As with other compliance topics, overall responsibility lies with management. Operationally, a named person – for example from IT, compliance or data protection coordination – usually runs the framework, while system owners in the business units are responsible for their AI systems. The RACI matrix on this page shows one possible split.
A table that sets out, for every governance task, who carries it out (Responsible), who decides and is accountable (Accountable), who is consulted (Consulted) and who is informed (Informed). Each task should have exactly one accountable party (A) so that decisions do not get stuck between departments.
We advise against it. Data protection officers advise and monitor (Art. 39 GDPR); other tasks must not result in a conflict of interests (Art. 38(6) GDPR). Anyone who grants approvals would later have to monitor their own decision. Better: the DPO is consulted early (C) and management or a delegated body decides.
Yes, but in a lean form. The deployer obligations under Art. 4, 5 and 50 apply regardless of company size. For an SME, one responsible person, a short policy, a register in Excel, a request form for new tools, an annual training round and a fixed review date are usually enough.
ISO/IEC 42001 (published 2023) is an international standard for AI management systems. It describes how organisations establish, operate and continually improve policies, objectives and processes for the responsible use of AI. An AI governance framework covers many of these elements. Certification is voluntary and does not replace the individual obligations of the AI Act.
That depends on the case and on national law. In Germany, for example, a co-determination right can exist where an AI system is designed to monitor employees' behaviour or performance (Section 87(1) no. 6 BetrVG). For high-risk AI at the workplace, Art. 26(7) AI Act also requires informing workers' representatives and affected workers before putting the system into service. Early involvement saves time in practice.
For a mid-sized company with a manageable number of AI tools, a workable foundation in around 90 days is realistic: 30 days for overview and ownership, 30 days for the policy and approval process, 30 days for training, operations and evidence. This is based on experience, not a requirement.
The AI Act does not set a fixed rhythm. What works: event-driven reviews for new tools, significant changes and incidents, plus a full review at least once a year with a short report to management. Review high-risk and unclear systems more often.

More questions? We're happy to help. Send email · Get started

Sources and status

Last checked on · SimpleAct editorial team

This page is for orientation only and does not constitute legal advice. The text published in the Official Journal of the EU is authoritative. The RACI matrix, workflow, timeline and maturity check are recommendations, not legal requirements.

Changes to this page

  • 10 October 2026 – FAQ “Where do I start with AI governance?” added.
  • 3 October 2026 – Rebuilt as an AI governance framework: 6 building blocks, RACI matrix, approval workflow, mapping AI Act ↔ GDPR ↔ ISO/IEC 42001, 90-day plan, maturity check, updated after the Digital Omnibus.
  • 30 July 2026 – First version as an overview of the AI governance system.

Further reading

AI governance that works day to day

SimpleAct connects the AI inventory, risk classification, approvals, deadlines and evidence – so your framework does not fall apart into spreadsheets and emails.

Book a demoTry 7 days free