AI Governance Framework for SMEs: 6 Building Blocks

Obligation and recommendation: In this article, what is mandatory is what comes with a source reference. The division into six building blocks, the allocation of internal responsibilities and all intervals mentioned here — updating and quarterly review of the inventory, training refreshers, bias re-tests, annual audit — are practice recommendations made by this article and are identified as such.

Status of sources: The legal statements in this article are based on a review of sources as at 2 May 2026, updated to the legal status of 17 August 2026 (Regulation (EU) 2026/1744, KI-MIG); the dates of application of the AI Act follow directly from Art. 113 and Art. 111(3).

Further reading: AI inventory in 8 steps — how to record and classify AI systems and assign the provider or deployer role.

Deadline logic: which obligations the framework has to carry today

As at the date of this article, the central dates of application of the AI Act have arrived: Art. 4 (AI literacy) and Art. 5 (prohibited practices) have applied since 2 February 2025, the provider obligations for general-purpose AI models since 2 August 2025, and the general start of application of the Regulation fell on 2 August 2026. Still open are 2 December 2026 (new prohibition no. 9; transition for Art. 50(2) under Art. 111(4)), 2 August 2027 (GPAI legacy models, Art. 111(3)), 2 December 2027 (Annex III) and 2 August 2028 (Annex I) — Art. 113(3) AI Act as amended by Regulation (EU) 2026/1744. The framework therefore does not have to work towards a single cut-off date, but must be able to demonstrate ongoing operation.

All the dates in the following table are dates of application of the AI Act under Art. 113 or under the transitional rule in Art. 111(3).

The caveat regarding the Annex III part of the fifth row has been resolved: with Regulation (EU) 2026/1744 (Digital Omnibus AI), in force since 27 July 2026, the high-risk obligations of Chapter III Sections 1–3 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028 (Art. 113(3)(c) AI Act, new version); these are fixed calendar dates without any triggering mechanism. Not covered by the postponement are Art. 4, Art. 5, the GPAI obligations and Art. 50 — the general start of application on 2 August 2026 stands; the FRIA obligation in Art. 27, by contrast, belongs to Chapter III Section 3 and applies to Annex III systems from 2 December 2027. Base your implementation planning on these dates; the starting point for the source references is the sources block at the end of this article. For planning purposes (practice recommendation): record the date that applies to each system in the AI policy or in the header of the inventory, and check it again at the next quarterly review.

1. AI policy (top level)

The AI policy is management's statement on the use of AI: it sets out values, principles, prohibitions and responsibilities — what AI may be used for in the company, what it may not be used for, and who is accountable for compliance.

Why it comes first: The hard core of the prohibitions is set out in Art. 5(1) AI Act and has applied since 2 February 2025. Prohibited are, among other things, social scoring, emotion recognition in the workplace and in education institutions, biometric categorisation to infer sensitive attributes, the exploitation of vulnerabilities due to age, disability or a social or economic situation, and the untargeted scraping of facial images from the internet or from CCTV footage. Breaches of Art. 5 fall within the highest range of fines: up to EUR 35 million or 7 % of the total worldwide annual turnover for the preceding financial year, whichever is higher (Art. 99(3)). For SMEs, including start-ups, the lower of the two figures applies under Art. 99(6). A policy that does not expressly name this list leaves the business units on their own when drawing the line.

Responsibilities (practice recommendation): A central function — management itself or a designated AI officer — maintains the inventory and the approvals, and the business units feed into it. The policy decides which internal function fills the provider or deployer role (determined in building block 3). Its operational counterpart is the acceptable use policy for day-to-day use — which is at the same time a check point in the audit (building block 6).

Minimum content of the acceptable use policy (practice recommendation): It names the approved tools with their approval status — anything not on the list is not approved — the categories of data that must not be entered into an AI tool (for example personal data without a verified legal basis, or special categories under Art. 9(1) GDPR), the rule for checking and labelling AI output towards customers, the reporting and escalation channel for conspicuous output or data leakage, with a name and contact details, and the consequences of a breach. The version status and approval date belong on the first page, because the audit checks the policy for its age (building block 6). If a planned procurement does not fit this policy, that is the conflict resolved by the assessment process (building block 3).

2. AI inventory with risk classification

The AI inventory documents all AI tools in use together with their classification (prohibited/high/limited/minimal) and is the data basis without which the other five building blocks run empty.

The AI Act contains no express article on inventories; the inventory is an operational minimum standard for several obligations: Art. 4 in the version applicable since 27 July 2026 (Regulation (EU) 2026/1744) requires measures that support the development of AI literacy in relation to the AI actually used — without an overview, you cannot train; Art. 5 requires the exclusion of prohibited practices; Art. 26 sets out the deployer obligations for high-risk systems. What belongs in it at all is defined by Art. 3 no. 1: a machine-based system that is designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment and that, from the input it receives, infers how to generate outputs — predictions, content, recommendations or decisions — for explicit or implicit objectives, which can influence physical or virtual environments.

The names of the four classes follow this article's own usage; the AI Act ties the obligations to the provisions named in the last column. Recital 26 distinguishes for this purpose between prohibited practices, requirements for high-risk AI systems and transparency obligations for certain AI systems.

Cutting across these classes are GPAI models (Art. 3 no. 63): they are a category of model with their own set of obligations, not a risk class — which is why the inventory carries "GPAI yes/no" as a separate column. As a practice recommendation — there is no statutory column requirement — this article proposes twelve columns:

Updating (practice recommendation): with every change in AI use and at least annually, plus a quarterly review. No statutory interval follows from this. The quarterly review is the step that keeps the inventory below the six-month threshold used in the audit (building block 6); the annual full review goes beyond that and covers all entries, including those classified as "minimal". Triggers for an update include new tools, contract renewals and changes to Annex III — the full list of triggers is in the FAQ.

3. AI assessment process

The assessment process is the gate before procurement (practice recommendation): no AI tool goes into operation before five steps have been documented in this order — risk assessment, determination of role, data protection check, bias check and AUP compatibility — that is, before the risk class, the role, the data protection basis, the bias risk and the policy comparison are in the file. This assessment file is kept for each system and is the filing destination for all five steps; the inventory refers to it via the column "Approved by and date" (building block 2).

Risk assessment. First check whether one of the eight areas of Annex III applies. The exception in Art. 6(3) applies only where the system does not pose a significant risk to health, safety or fundamental rights — and it does not apply where the system performs profiling of natural persons. As soon as it produces recommendations or assessments capable of materially influencing human decisions, it remains high-risk; in case of doubt, classify it higher (practice recommendation).

For SMEs, two numbers are particularly relevant. No. 4 (employment and workers management) is the most common SME use case: CV match scoring, performance scoring and workforce planning with promotion or dismissal recommendations are high-risk; an HR FAQ chatbot is not. No. 5(b) (creditworthiness assessment) and (c) (life and health insurance scoring) concern banks and insurers; the FRIA obligation in Art. 27 attaches to these two points — in addition, it applies to deployers that are public bodies or private entities providing public services (details in the FAQ).

Role. Under Art. 3 no. 3, a provider is a party that develops an AI system or places it on the market; under Art. 3 no. 4, a deployer is a party that uses it under its own authority. Under Art. 25, a deployer moves into the provider role if it substantially modifies the purpose or functionality, or places the system on the market under its own name. With GPAI, provider status arises only where you train the model yourself, make a substantial fine-tuning modification, or operate a wrapper with white-label branding and your own marketing. Where you are a deployer, request the evidence from your supplier — for example the GPAI Code of Practice (a means of demonstrating compliance under Art. 53(4), not a presumption of conformity — see building block 6).

Data protection check. On the data protection side, three points belong in the file: the legal basis under Art. 6(1) GDPR, the data processing agreement with the statutory minimum content under Art. 28(1) and (3) GDPR, and the data protection impact assessment to be carried out in advance under Art. 35(1) GDPR where the processing — in particular using new technologies — is likely to result in a high risk, for example in the case of a systematic and extensive evaluation of personal aspects producing legal effects (Art. 35(3) GDPR).

Bias check. The bias check does not depend on the AI Act deadlines: in Germany, § 22 of the German General Equal Treatment Act (AGG) shifts the burden of proof as soon as a party proves indicia giving rise to a presumption of disadvantage on a ground listed in § 1 AGG. In Austria, this is replaced by the prima facie showing under § 12(12) of the Austrian Equal Treatment Act (GlBG) (gender) or § 26(12) GlBG (other grounds). In operational terms (practice recommendation): First, record which of the grounds listed in § 1 AGG — race or ethnic origin, gender, religion or belief, disability, age, sexual identity; in Austria, the grounds in § 3 GlBG (gender) and § 17 GlBG (ethnic affiliation, religion or belief, age, sexual orientation) — the use case is capable of touching at all. Second, request from the provider the documentation on training data, known biases and model limitations, and file it; for general-purpose AI models, the documentation under Art. 53 covers training data and model limitations (see the role paragraph above). Third, run your own sample: send real or synthetic cases through the system that differ only in the protected attribute, and compare the distribution of results — as a rule of thumb, at least 20 pairs of cases per attribute tested; anything conspicuous is any systematic deviation between the groups that cannot be explained on objective grounds from the use case. Fourth, where such a finding is made, record who takes the final human decision and on what basis. Fifth, the date, the person carrying out the check and the finding belong in the assessment file; the occasions for a repeat are set out in building block 5.

AUP compatibility (practice recommendation). Does the use case fit the existing acceptable use policy? If not, there are two outcomes: change the policy — approval by the function named in building block 1, new version status — or do not approve the tool; the decision belongs in the assessment file with a date.

4. AI literacy training

Art. 4 AI Act has applied since 2 February 2025; under the version applicable since 27 July 2026 (Regulation (EU) 2026/1744), providers and deployers must take measures to support the development of AI literacy among their staff — no particular level of competence is owed. This building block sets out the training content, the evidence and the repetition interval for that purpose — without an inventory, the obligation cannot be met.

Content (practice recommendation): definition of AI, risk classes, prohibited practices — from 2 December 2026 including the new prohibition no. 9 (Art. 5(1)(ba)/(bb) AI Act as amended by Regulation (EU) 2026/1744) — transparency obligations and human oversight, concluded with a quiz and a record as the means of evidence for this building block; a certificate is not required according to the Commission FAQ (non-binding), an internal training record is sufficient. Training obligations must be determined per tool: the "Use case" column of the inventory shows who works with which system and how the training needs to be tailored.

Tailoring by target group (practice recommendation): A basic module for staff and the other persons dealing with the operation and use of the AI systems on your behalf covers the five items of content above — this is the group of persons addressed by Art. 4 AI Act in the version applicable since 27 July 2026. An additional module for employees working with a high-risk system deals with human oversight of precisely that system and the limits of its output; it does not replace the separate information obligation under Art. 26(7). An additional module for the approving function deals with classification, determination of role and documentation from building block 3. The fully drafted curriculum is set out in the article AI Literacy Curriculum.

A training log with a knowledge quiz serves as evidence; the training date for each system is recorded in the inventory (building block 2).

Refresher (practice recommendation): annually, and on an ad hoc basis for every newly approved tool. The date for each system belongs in the inventory column "Date of the AI literacy training"; the log is a check point in the audit (building block 6).

Sanctions side: Breaches of Art. 4 are not covered by the catalogue of fines in Art. 99(4) — sanctions in that respect follow national law (Art. 99(1)). In Germany, the German AI Market Surveillance and Innovation Promotion Act (KI-MIG) of 22 July 2026 (BGBl. 2026 I no. 223) has applied for that purpose since 29 July 2026; its own administrative offence provisions (§ 15(1) and (2); a fine of up to fifty thousand euros under § 15(3)) attach to Art. 21, 27, 45 and 86(1) AI Act; in Austria, no corresponding rules were in place as at 17 August 2026. That changes the range of fines, not the obligation.

Not to be confused with the training: If, as a deployer, you use a high-risk system in the workplace, you additionally owe information to the employees concerned under Art. 26(7) AI Act. This is a separate obligation and is not discharged by a training certificate.

5. AI monitoring + incident plan

For high-risk systems, monitoring means three named deployer obligations (Art. 26(4), (6), (7)) and — as a practice recommendation — a defined escalation channel. In addition, this building block carries three practice recommendations: output quality control, bias re-tests and incident escalation.

As a deployer you check the relevance of the input data (Art. 26(4)) and keep the logs for at least six months (Art. 26(6)); the information to employees under paragraph 7 is covered in building block 4. As the provider of a GPAI model with systemic risk you record and document serious incidents and report them without undue delay to the AI Office and, where applicable, to the competent national authorities (Art. 55(1)). For high-risk systems, the AI Act additionally provides for post-market monitoring (Art. 72) and incident response (Art. 73); which role these two obligations fall on, and which reporting addressees and deadlines Art. 73 prescribes in detail, is not set out in this article — clarify both against the text of the Regulation before you put a high-risk system into operation, and record the result in the assessment process (building block 3).

Output quality control (practice recommendation): Take a sample of the output generated by each approved tool — quarterly for high-risk systems, otherwise every six months, with at least 10 outputs from live operation per round. The checking function is the responsible department from the inventory column of the same name (building block 2). The check covers factual accuracy, completeness and — where Art. 50 applies — the labelling of the content as artificially generated. The result is filed with the date and the person carrying out the check; where there is more than one objection per round, the case goes to the approving function via the reporting and escalation channel of the acceptable use policy (building block 1).

Bias re-tests (practice recommendation): Repeat the bias check from building block 3 whenever the provider changes the model or version, upon contract renewal and upon a change of use case; record the result with a date in the inventory. The occasion does not follow from the AI Act, but from the burden-of-proof rules set out in building block 3.

Data protection link: An AI incident may at the same time be a personal data breach. In that case a second clock starts running: notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33(1) GDPR); where a high risk is likely, the data subjects must additionally be notified (Art. 34(1) GDPR). Both clocks run in parallel: the deadline in Art. 33(1) GDPR attaches to becoming aware of the data breach, not to the assessment of the incident under the AI Act. Practice recommendation: expressly include AI tools in your existing data breach procedure and record the escalation channel with a name, a deputy and contact details — a 72-hour deadline cannot be started with a search for who is responsible.

Incident plan (practice recommendation): Five steps in this order. First, detection and immediate measure: whoever notices the incident reports it; who may suspend use of the tool concerned is laid down in the AI policy (building block 1). Second, report to the internal function recorded in the acceptable use policy, with a name and a deputy. Third, the parallel dual assessment: the AI Act side against the text of the Regulation, the data protection side against the 72-hour clock in Art. 33(1) GDPR, as described above. Fourth, documentation with fixed fields: system and version from the inventory, the time of becoming aware, impact, immediate measure, notification decision with reasons. Fifth, follow-up: entry in the inventory, trigger for a bias re-test and follow-up in the next audit (building block 6).

6. Annual AI audit

The internal audit checks the other five building blocks against evidence and decides on the optional ISO 42001 certification — the annual interval is a practice recommendation, the obligations checked are not.

Check points (practice recommendation): policy version and approval date of the AI policy; inventory less than six months old; approval workflow traceable for each tool; FRIA available for the use cases concerned; AI literacy training log with knowledge quiz; acceptable use policy less than twelve months old; log retention under Art. 26(6) demonstrated technically; samples from the output quality control with date and finding available (building block 5); data breach procedure documented for AI tools as well.

Procedure (practice recommendation): The check should be carried out by a function that did not itself request the tool — in an SME, the four-eyes principle between the AI officer and the relevant business unit is sufficient. Every finding is assigned an owner, a measure and a follow-up date; anything still open at the follow-up date goes to management, because that is also where accountability for the AI policy lies (building block 1).

Frameworks: For this purpose, this article names ISO/IEC 42001:2023 (international) and the NIST AI RMF (USA). For the certification decision: which AI Act obligations ISO/IEC 42001:2023 covers, which it does not, and how it is to be classified, is set out in the FAQ. The NIST AI RMF is freely available and is a US framework. The AI Act expressly ties a presumption of conformity to a harmonised European standard; as a means of demonstrating compliance, Art. 53(4) additionally names codes of practice within the meaning of Art. 56 for providers of GPAI models.

Certification decision (practice recommendation): Three points speak in favour of certification — first, customers or tenders require evidence of a management system; second, you are a provider for at least one system (Art. 3 no. 3); third, you operate more than one high-risk system under Annex III. If none of these applies, the evidence from building blocks 1 to 5 is sufficient.

Legal position in Austria

Nothing different applies to the AI Act in Austria: it is a directly applicable EU regulation, all the articles and dates mentioned above are identical, and there is no need to rework the source references. What is regulated nationally are the competent authorities and the sanctions regime within the framework of Art. 99(1). Each Member State establishes at least one notifying authority and at least one market surveillance authority, designates one market surveillance authority as a single point of contact and makes the contact information publicly available (Art. 70(1) and (2)). In Germany, the market surveillance authority has been the Federal Network Agency (Bundesnetzagentur) since 29 July 2026 (§ 2(1) KI-MIG), insofar as sectoral authorities — such as BaFin — are not competent; the single point of contact within the meaning of Art. 70(2) is likewise the Federal Network Agency (Bundesnetzagentur) under § 6(1) KI-MIG. As at the date of this article (17 August 2026), Austria had not designated a market surveillance authority under Art. 70 AI Act; the AI service point (KI-Servicestelle) at RTR is an information and advisory body without supervisory powers — check the current position before you write a point of contact or a reporting channel into your policy. Practice recommendation: create a field in the AI policy for each legal area headed "competent market surveillance authority / single point of contact" with a retrieval date — for as long as it is empty, the gap remains visible in the audit. For the GPAI models covered by Chapter V, supervision lies with the European Commission in any event, which delegates implementation to the AI Office (Art. 88(1)); the national market surveillance authorities in Germany and Austria are not competent for this.

Two accompanying differences directly affect the framework. First, the bias check from building block 3: in Austria, the competent bodies are the Ombud for Equal Treatment (GAW) and the Equal Treatment Commission (Gleichbehandlungskommission), not the German Federal Anti-Discrimination Agency (Antidiskriminierungsstelle des Bundes). Second, the data protection organisation: in Germany, in addition to Art. 37 GDPR, a data protection officer must be designated where, as a rule, at least 20 persons are constantly engaged in the automated processing of personal data, or where processing operations are subject to a data protection impact assessment under Art. 35 GDPR (§ 38(1) of the German Federal Data Protection Act (BDSG)). Austria does not provide for any numerical designation threshold going beyond Art. 37 GDPR (§ 5 of the Austrian Data Protection Act (DSG)).