AI Governance Framework für KMU: 6 Bausteine

Pflicht und Empfehlung: Pflicht ist in diesem Artikel, was mit Fundstelle steht. Die Gliederung in sechs Bausteine, der Zuschnitt der internen Zuständigkeiten und alle hier genannten Rhythmen — Aktualisierung und Quartals-Review des Inventars, Schulungs-Refresher, Bias-Re-Tests, jährliches Audit — sind Praxisempfehlungen dieses Artikels und als solche gekennzeichnet.

Quellenstand: Die Rechtsaussagen dieses Artikels beruhen auf einer Quellenprüfung vom 02.05.2026, nachgeführt zum Rechtsstand 17.08.2026 (Verordnung (EU) 2026/1744, KI-MIG); die Anwendungstermine der KI-VO folgen unmittelbar aus Art. 113 und Art. 111 Abs. 3.

Vertiefung: KI-Inventar in 8 Schritten — wie Sie KI-Systeme erfassen, einstufen und die Anbieter- oder Betreiberrolle zuordnen.

Fristenlogik: Welche Pflichten das Framework heute tragen muss

Zum Stand dieses Artikels sind die zentralen Anwendungstermine der KI-VO eingetreten: Art. 4 (KI-Kompetenz) und Art. 5 (verbotene Praktiken) gelten seit dem 2. Februar 2025, die Anbieterpflichten für Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025, der allgemeine Geltungsbeginn der Verordnung ist am 2. August 2026 eingetreten. Offen sind der 2. Dezember 2026 (neues Verbot Nr. 9; Übergang für Art. 50 Abs. 2 nach Art. 111 Abs. 4), der 2. August 2027 (GPAI-Bestandsmodelle, Art. 111 Abs. 3), der 2. Dezember 2027 (Anhang III) und der 2. August 2028 (Anhang I) — Art. 113 Abs. 3 KI-VO i. d. F. der Verordnung (EU) 2026/1744. Das Framework muss deshalb nicht auf einen Stichtag hinarbeiten, sondern einen laufenden Betrieb nachweisen können.

Alle Termine der folgenden Tabelle sind Anwendungstermine der KI-VO nach Art. 113 beziehungsweise der Übergangsregel des Art. 111 Abs. 3.

Der Vorbehalt zum Anhang-III-Teil der fünften Zeile ist erledigt: Mit der Verordnung (EU) 2026/1744 (Digital-Omnibus KI), in Kraft seit 27. Juli 2026, gelten die Hochrisiko-Pflichten der Kapitel III Abschnitte 1–3 für Anhang-III-Systeme ab dem 02.12.2027 und für Anhang-I-Systeme ab dem 02.08.2028 (Art. 113 Abs. 3 lit. c KI-VO n. F.); es sind feste Kalenderdaten ohne Auslösemechanismus. Von der Verschiebung nicht erfasst sind Art. 4, Art. 5, die GPAI-Pflichten und Art. 50 — der allgemeine Geltungsbeginn 02.08.2026 bleibt; die FRIA-Pflicht des Art. 27 gehört dagegen zu Kapitel III Abschnitt 3 und gilt für Anhang-III-Systeme ab dem 02.12.2027. Legen Sie Ihre Umsetzungsplanung auf diese Daten; Ausgangspunkt der Fundstellen ist der Quellenblock am Ende dieses Artikels. Für die Planung (Praxisempfehlung): Halten Sie den je System maßgeblichen Termin mit Datum in der AI-Policy oder im Kopf des Inventars fest und prüfen Sie ihn beim nächsten Quartals-Review erneut.

1. AI-Policy (Top-Level)

Die AI-Policy ist das Statement der Geschäftsführung zur KI-Nutzung: Sie legt Werte, Prinzipien, Verbote und Verantwortlichkeiten fest — wofür KI im Unternehmen eingesetzt werden darf, wofür nicht und wer die Einhaltung verantwortet.

Warum sie zuerst kommt: Der harte Kern der Verbote steht in Art. 5 Abs. 1 KI-VO und gilt seit dem 02.02.2025. Untersagt sind unter anderem Social Scoring, Emotionserkennung am Arbeitsplatz und in Bildungseinrichtungen, biometrische Kategorisierung zur Ableitung sensibler Merkmale, das Ausnutzen von Vulnerabilitäten aufgrund von Alter, Behinderung oder sozialer beziehungsweise wirtschaftlicher Lage sowie das ungezielte Auslesen von Gesichtsbildern aus dem Internet oder aus Überwachungsaufnahmen. Verstöße gegen Art. 5 liegen im obersten Bußgeldrahmen: bis zu 35 Mio. EUR oder 7 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist (Art. 99 Abs. 3). Für KMU einschließlich Start-ups gilt dabei nach Art. 99 Abs. 6 der jeweils niedrigere der beiden Werte. Eine Policy, die diese Liste nicht ausdrücklich benennt, lässt die Fachbereiche mit der Abgrenzung allein.

Zuständigkeiten (Praxisempfehlung): Eine zentrale Stelle — die Geschäftsführung selbst oder eine benannte KI-verantwortliche Person — führt Inventar und Freigaben, die Fachbereiche liefern zu. Welche interne Stelle die Anbieter- oder Betreiberrolle ausfüllt (Bestimmung in Baustein 3), entscheidet die Policy. Ihr operatives Gegenstück ist die Acceptable Use Policy für die tägliche Nutzung — sie ist zugleich Prüfpunkt im Audit (Baustein 6).

Mindestinhalt der Acceptable Use Policy (Praxisempfehlung): Sie benennt die freigegebenen Tools mit Freigabestand — was nicht auf der Liste steht, ist nicht freigegeben —, die Datenkategorien, die nicht in ein KI-Tool eingegeben werden dürfen (etwa personenbezogene Daten ohne geprüfte Rechtsgrundlage oder besondere Kategorien nach Art. 9 Abs. 1 DSGVO), die Regel für Prüfung und Kennzeichnung von KI-Output gegenüber Kunden, den Melde- und Eskalationsweg bei auffälligem Output oder Datenabfluss mit Name und Erreichbarkeit sowie die Konsequenzen bei Verstoß. Versionsstand und Freigabedatum gehören auf die erste Seite, weil das Audit die Policy auf ihr Alter prüft (Baustein 6). Passt eine geplante Anschaffung nicht in diese Policy, ist das der Konflikt, den der Bewertungs-Prozess auflöst (Baustein 3).

2. KI-Inventar mit Risiko-Klassifizierung

Das KI-Inventar dokumentiert alle eingesetzten KI-Tools mit ihrer Klassifikation (verboten/hoch/begrenzt/minimal) und ist die Datenbasis, ohne die die übrigen fünf Bausteine leerlaufen.

Die KI-VO enthält keinen ausdrücklichen Inventar-Artikel; das Inventar ist operativer Mindeststandard für mehrere Pflichten: Art. 4 in der seit 27. Juli 2026 geltenden Fassung (Verordnung (EU) 2026/1744) verlangt Maßnahmen, die die Entwicklung der KI-Kompetenz zur tatsächlich eingesetzten KI unterstützen — ohne Übersicht lässt sich nicht schulen; Art. 5 verlangt den Ausschluss verbotener Praktiken; Art. 26 die Betreiberpflichten für Hochrisiko-Systeme. Was überhaupt hineingehört, definiert Art. 3 Nr. 1: ein maschinengestütztes System, das für einen in unterschiedlichem Grade autonomen Betrieb ausgelegt ist, nach Betriebsaufnahme anpassungsfähig sein kann und aus den erhaltenen Eingaben für explizite oder implizite Ziele ableitet, wie Ausgaben — Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen — erzeugt werden, die physische oder virtuelle Umgebungen beeinflussen können.

Die Bezeichnungen der vier Klassen folgen dem Bestand dieses Artikels; die KI-VO knüpft die Pflichten an die in der letzten Spalte genannten Normen. Erwägungsgrund 26 unterscheidet dafür verbotene Praktiken, Anforderungen an Hochrisiko-KI-Systeme und Transparenzpflichten für bestimmte KI-Systeme.

Quer zu diesen Klassen liegen GPAI-Modelle (Art. 3 Nr. 63): Sie sind eine Modellkategorie mit eigenem Pflichtenkreis, keine Risikoklasse — deshalb führt das Inventar „GPAI ja/nein“ als eigene Spalte. Als Praxisempfehlung — eine gesetzliche Spaltenvorgabe gibt es nicht — schlägt dieser Artikel zwölf Spalten vor:

Aktualisierung (Praxisempfehlung): bei jeder Änderung der KI-Nutzung und mindestens jährlich, dazu ein Quartals-Review. Ein gesetzliches Intervall folgt daraus nicht. Der Quartals-Review ist dabei der Vorgang, der das Inventar unter der Sechs-Monats-Schwelle des Audits hält (Baustein 6); die jährliche Vollüberprüfung geht darüber hinaus und betrifft alle Einträge einschließlich der als „minimal“ klassifizierten. Auslöser für eine Aktualisierung sind unter anderem neue Tools, Vertragsverlängerungen und Änderungen an Anhang III — die vollständige Auslöser-Liste steht in der FAQ.

3. KI-Bewertungs-Prozess

Der Bewertungs-Prozess ist das Tor vor der Anschaffung (Praxisempfehlung): Kein KI-Tool geht in Betrieb, bevor fünf Schritte in dieser Reihenfolge dokumentiert sind — Risiko-Bewertung, Rollenbestimmung, Datenschutz-Check, Bias-Check und AUP-Compatibility —, bevor also Risikoklasse, Rolle, Datenschutz-Grundlage, Bias-Risiko und Policy-Abgleich in der Akte stehen. Diese Bewertungsakte wird je System geführt und ist das Ablageziel aller fünf Schritte; das Inventar verweist mit der Spalte „Genehmigt durch und Datum“ auf sie (Baustein 2).

Risiko-Bewertung. Prüfen Sie zuerst, ob einer der acht Bereiche des Anhangs III einschlägig ist. Die Ausnahme des Art. 6 Abs. 3 greift nur, wenn das System kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte birgt — und sie greift nicht, wenn das System ein Profiling natürlicher Personen durchführt. Sobald es Empfehlungen oder Bewertungen erzeugt, die menschliche Entscheidungen wesentlich beeinflussen können, bleibt es Hochrisiko; bei Zweifel höher klassifizieren (Praxisempfehlung).

Für KMU sind vor allem zwei Nummern einschlägig. Nr. 4 (Beschäftigung und Personalmanagement) ist der häufigste KMU-Use-Case: CV-Match-Scoring, Performance-Scoring und Workforce-Planning mit Beförderungs- oder Kündigungs-Empfehlungen sind Hochrisiko, ein HR-FAQ-Chatbot ist es nicht. Nr. 5 lit. b (Kreditwürdigkeitsbewertung) und lit. c (Lebens- und Krankenversicherungs-Scoring) betreffen Banken und Versicherer; an diese beiden Buchstaben knüpft die FRIA-Pflicht des Art. 27 an — daneben trifft sie Betreiber, die öffentliche Stellen sind oder als private Einrichtungen öffentliche Dienste erbringen (Einzelheiten in der FAQ).

Rolle. Anbieter ist nach Art. 3 Nr. 3, wer ein KI-System entwickelt oder in Verkehr bringt; Betreiber nach Art. 3 Nr. 4, wer es unter eigener Verantwortung verwendet. Nach Art. 25 wechselt ein Betreiber in die Anbieterrolle, wenn er Zweck oder Funktionalität wesentlich ändert oder das System unter eigenem Namen in Verkehr bringt. Bei GPAI entsteht der Anbieter-Status nur bei eigenem Modell-Training, bei wesentlicher Fine-Tuning-Anpassung oder bei einem Wrapper mit White-Label-Branding und eigener Vermarktung. Wo Sie Betreiber sind, fordern Sie die Nachweise beim Lieferanten ein — etwa den GPAI Code of Practice (Nachweismittel nach Art. 53 Abs. 4, keine Konformitätsvermutung — siehe Baustein 6).

Datenschutz-Check. Datenschutzseitig gehören drei Punkte in die Akte: die Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO, der Auftragsverarbeitungsvertrag mit gesetzlichem Mindestinhalt nach Art. 28 Abs. 1 und 3 DSGVO und die vorab durchzuführende Datenschutz-Folgenabschätzung nach Art. 35 Abs. 1 DSGVO, wenn die Verarbeitung — insbesondere bei Verwendung neuer Technologien — voraussichtlich ein hohes Risiko birgt, etwa bei systematischer umfassender Bewertung persönlicher Aspekte mit Rechtswirkung (Art. 35 Abs. 3 DSGVO).

Bias-Check. Der Bias-Check hängt nicht an den KI-VO-Fristen: In Deutschland verlagert § 22 AGG die Beweislast, sobald eine Partei Indizien beweist, die eine Benachteiligung wegen eines Grundes nach § 1 AGG vermuten lassen. In Österreich tritt an diese Stelle die Glaubhaftmachung nach § 12 Abs. 12 GlBG (Geschlecht) beziehungsweise § 26 Abs. 12 GlBG (übrige Gründe). Operativ (Praxisempfehlung): Halten Sie erstens fest, welche der Gründe des § 1 AGG — Rasse oder ethnische Herkunft, Geschlecht, Religion oder Weltanschauung, Behinderung, Alter, sexuelle Identität; in Österreich die Gründe des § 3 GlBG (Geschlecht) und des § 17 GlBG (ethnische Zugehörigkeit, Religion oder Weltanschauung, Alter, sexuelle Orientierung) — der Use Case überhaupt berühren kann. Fordern Sie zweitens beim Anbieter die Dokumentation zu Trainingsdaten, bekannten Verzerrungen und Modellgrenzen an und legen Sie sie ab; bei Modellen mit allgemeinem Verwendungszweck decken die Unterlagen nach Art. 53 davon Trainingsdaten und Modellgrenzen (Limitationen) ab (siehe Rollen-Absatz oben). Lassen Sie drittens eine eigene Stichprobe laufen: reale oder synthetische Fälle, die sich nur im geschützten Merkmal unterscheiden, durch das System schicken und die Ergebnisverteilung vergleichen — als Anhalt mindestens 20 Fallpaare je geprüftem Merkmal; auffällig ist jede systematische Abweichung zwischen den Gruppen, die sich nicht sachlich aus dem Use Case erklären lässt. Halten Sie viertens bei einem so festgestellten Befund fest, wer die menschliche Letztentscheidung trifft und worauf sie sich stützt. Fünftens gehören Datum, prüfende Person und Befund in die Bewertungsakte; die Anlässe für eine Wiederholung stehen in Baustein 5.

AUP-Compatibility (Praxisempfehlung). Passt der Use Case in die bestehende Acceptable Use Policy? Wenn nein, gibt es zwei Ausgänge: Policy ändern — Freigabe durch die in Baustein 1 benannte Stelle, neuer Versionsstand — oder Tool nicht freigeben; die Entscheidung gehört mit Datum in die Bewertungsakte.

4. AI-Literacy-Schulung

Art. 4 KI-VO gilt seit dem 2. Februar 2025; nach der seit 27. Juli 2026 geltenden Fassung (Verordnung (EU) 2026/1744) müssen Anbieter und Betreiber Maßnahmen ergreifen, um die Entwicklung der KI-Kompetenz ihres Personals zu unterstützen — ein bestimmtes Kompetenzniveau wird nicht geschuldet. Dieser Baustein legt dafür die Schulungsinhalte, den Nachweis und den Wiederholungs-Rhythmus fest — ohne Inventar ist die Pflicht nicht erfüllbar.

Inhalte (Praxisempfehlung): KI-Definition, Risikoklassen, verbotene Praktiken — ab 02.12.2026 einschließlich des neuen Verbots Nr. 9 (Art. 5 Abs. 1 lit. ba/bb KI-VO i. d. F. der Verordnung (EU) 2026/1744) —, Transparenzpflichten und menschliche Aufsicht, abgeschlossen mit Quiz und Nachweis als Nachweismittel dieses Bausteins; ein Zertifikat ist nach den Kommissions-FAQ (unverbindlich) nicht erforderlich, ein interner Schulungsnachweis genügt. Die Schulungspflichten sind pro Tool zu bestimmen: Aus der Spalte „Use Case“ des Inventars ergibt sich, wer mit welchem System arbeitet und welchen Zuschnitt die Schulung braucht.

Zuschnitt nach Zielgruppe (Praxisempfehlung): Ein Basisteil für das Personal und die weiteren Personen, die in Ihrem Auftrag mit dem Betrieb und der Nutzung der KI-Systeme befasst sind, deckt die fünf Inhalte oben ab — auf diesen Personenkreis stellt Art. 4 KI-VO in der seit 27. Juli 2026 geltenden Fassung ab. Ein Zusatzteil für Beschäftigte, die mit einem Hochrisiko-System arbeiten, behandelt die menschliche Aufsicht über genau dieses System und die Grenzen seines Outputs; die davon getrennte Information nach Art. 26 Abs. 7 ersetzt er nicht. Ein Zusatzteil für die freigebende Stelle behandelt Einstufung, Rollenbestimmung und Dokumentation aus Baustein 3. Den ausformulierten Lehrplan enthält der Artikel AI Literacy Curriculum.

Als Nachweis dient ein Schulungs-Logbuch mit Wissens-Quiz; das Schulungsdatum je System steht im Inventar (Baustein 2).

Refresher (Praxisempfehlung): jährlich sowie anlassbezogen bei jedem neu freigegebenen Tool. Das Datum je System gehört in die Inventar-Spalte „Datum der AI-Literacy-Schulung“, das Logbuch ist Prüfpunkt im Audit (Baustein 6).

Sanktionsseite: Verstöße gegen Art. 4 sind nicht vom Bußgeldkatalog des Art. 99 Abs. 4 erfasst — Sanktionen richten sich insoweit nach nationalem Recht (Art. 99 Abs. 1). In Deutschland gilt dafür seit 29. Juli 2026 das KI-MIG vom 22. Juli 2026 (BGBl. 2026 I Nr. 223), dessen eigene Ordnungswidrigkeiten-Tatbestände (§ 15 Abs. 1 und 2; Geldbuße bis zu fünfzigtausend Euro nach § 15 Abs. 3) an Art. 21, 27, 45 und 86 Abs. 1 KI-VO anknüpfen; in Österreich lag zum 17. August 2026 keine entsprechende Regelung vor. Das ändert den Bußgeldrahmen, nicht die Pflicht.

Nicht mit der Schulung verwechseln: Setzen Sie als Betreiber ein Hochrisiko-System am Arbeitsplatz ein, ist zusätzlich die Information der betroffenen Beschäftigten nach Art. 26 Abs. 7 KI-VO geschuldet. Sie ist eine eigene Pflicht und wird durch ein Schulungszertifikat nicht erledigt.

5. KI-Monitoring + Vorfall-Plan

Monitoring bedeutet bei Hochrisiko-Systemen drei benannte Betreiberpflichten (Art. 26 Abs. 4, Abs. 6, Abs. 7) und — als Praxisempfehlung — einen definierten Eskalationsweg. Daneben führt dieser Baustein drei Praxisempfehlungen: Output-Qualitätskontrolle, Bias-Re-Tests und Vorfall-Eskalation.

Als Betreiber prüfen Sie die Relevanz der Eingabedaten (Art. 26 Abs. 4) und bewahren die Logs mindestens sechs Monate auf (Art. 26 Abs. 6); die Information der Beschäftigten nach Abs. 7 steht in Baustein 4. Als Anbieter eines GPAI-Modells mit systemischem Risiko erfassen und dokumentieren Sie schwerwiegende Vorfälle und melden sie unverzüglich dem Büro für Künstliche Intelligenz sowie gegebenenfalls den zuständigen nationalen Behörden (Art. 55 Abs. 1). Für Hochrisiko-Systeme sieht die KI-VO daneben Post-Market-Monitoring (Art. 72) und Incident Response (Art. 73) vor; welche Rolle diese beiden Pflichten trifft und welche Melde-Adressaten und Fristen Art. 73 im Einzelnen vorgibt, führt dieser Artikel nicht aus — klären Sie beides am Verordnungstext, bevor Sie ein Hochrisiko-System in Betrieb nehmen, und halten Sie das Ergebnis im Bewertungs-Prozess fest (Baustein 3).

Output-Qualitätskontrolle (Praxisempfehlung): Ziehen Sie je freigegebenem Tool eine Stichprobe des erzeugten Outputs — bei Hochrisiko-Systemen quartalsweise, sonst halbjährlich, je Durchgang mindestens 10 Outputs aus dem laufenden Betrieb. Prüfende Stelle ist der verantwortliche Fachbereich aus der gleichnamigen Inventar-Spalte (Baustein 2). Geprüft wird auf sachliche Richtigkeit, Vollständigkeit und — wo Art. 50 einschlägig ist — auf die Kennzeichnung des Inhalts als künstlich erzeugt. Das Ergebnis wird mit Datum und prüfender Person abgelegt; bei mehr als einer Beanstandung je Durchgang geht der Fall über den Melde- und Eskalationsweg der Acceptable Use Policy an die freigebende Stelle (Baustein 1).

Bias-Re-Tests (Praxisempfehlung): Wiederholen Sie den Bias-Check aus Baustein 3 bei jedem Modell- oder Versionswechsel des Anbieters, bei Vertragsverlängerung und bei Änderung des Use Case; vermerken Sie das Ergebnis mit Datum im Inventar. Der Anlass folgt nicht aus der KI-VO, sondern aus den Beweislastregeln aus Baustein 3.

Datenschutz-Kopplung: Ein KI-Vorfall kann zugleich eine Verletzung des Schutzes personenbezogener Daten sein. Dann läuft eine zweite Uhr: Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen (Art. 33 Abs. 1 DSGVO); bei voraussichtlich hohem Risiko zusätzlich Benachrichtigung der betroffenen Personen (Art. 34 Abs. 1 DSGVO). Beide Uhren laufen nebeneinander: Die Frist des Art. 33 Abs. 1 DSGVO knüpft an das Bekanntwerden der Datenschutzverletzung an, nicht an die Bewertung des Vorfalls nach der KI-VO. Praxisempfehlung: Nehmen Sie KI-Tools ausdrücklich in das bestehende Datenpannen-Verfahren auf und hinterlegen Sie den Eskalationsweg mit Name, Vertretung und Erreichbarkeit — eine 72-Stunden-Frist lässt sich nicht mit einer Suche nach Zuständigkeiten beginnen.

Vorfall-Plan (Praxisempfehlung): Fünf Schritte in dieser Reihenfolge. Erstens Erkennung und Sofortmaßnahme: Wer den Vorfall bemerkt, meldet ihn; wer die Nutzung des betroffenen Tools aussetzen darf, ist in der AI-Policy festgelegt (Baustein 1). Zweitens Meldung an die in der Acceptable Use Policy hinterlegte interne Stelle, mit Name und Vertretung. Drittens die parallele Doppelbewertung: die KI-VO-Seite am Verordnungstext, die Datenschutz-Seite gegen die 72-Stunden-Uhr des Art. 33 Abs. 1 DSGVO, wie oben beschrieben. Viertens Dokumentation mit festen Feldern: System und Version aus dem Inventar, Zeitpunkt des Bekanntwerdens, Auswirkung, Sofortmaßnahme, Meldeentscheidung mit Begründung. Fünftens Nachbereitung: Eintrag im Inventar, Anlass für einen Bias-Re-Test und Wiedervorlage im nächsten Audit (Baustein 6).

6. KI-Audit jährlich

Das interne Audit prüft die anderen fünf Bausteine gegen Nachweise und entscheidet über die optionale ISO-42001-Zertifizierung — der jährliche Rhythmus ist eine Praxisempfehlung, die geprüften Pflichten sind es nicht.

Prüfpunkte (Praxisempfehlung): Policy-Version und Freigabe-Datum der AI-Policy; Inventar jünger als sechs Monate; Genehmigungs-Workflow je Tool nachvollziehbar; FRIA für die betroffenen Use Cases vorhanden; AI-Literacy-Schulungs-Logbuch mit Wissens-Quiz; Acceptable Use Policy jünger als zwölf Monate; Log-Aufbewahrung nach Art. 26 Abs. 6 technisch belegt; Stichproben der Output-Qualitätskontrolle mit Datum und Befund vorhanden (Baustein 5); Datenpannen-Verfahren auch für KI-Tools dokumentiert.

Verfahren (Praxisempfehlung): Prüfen sollte eine Stelle, die das Tool nicht selbst angefordert hat — im KMU genügt das Vier-Augen-Prinzip zwischen KI-verantwortlicher Person und dem jeweiligen Fachbereich. Jede Feststellung bekommt einen Verantwortlichen, eine Maßnahme und ein Wiedervorlagedatum; was zum Wiedervorlagetermin offen ist, geht an die Geschäftsführung, weil dort auch die AI-Policy verantwortet wird (Baustein 1).

Rahmenwerke: Dieser Artikel nennt dafür ISO/IEC 42001:2023 (international) und NIST AI RMF (USA). Für die Zertifizierungs-Entscheidung gilt: Welche Pflichten der KI-VO ISO/IEC 42001:2023 abdeckt, welche nicht und wie sie einzuordnen ist, steht in der FAQ. Das NIST AI RMF ist frei verfügbar und ein US-Rahmenwerk. Eine Vermutung der Konformität knüpft die KI-VO ausdrücklich an eine harmonisierte europäische Norm; als Nachweismittel der Einhaltung nennt Art. 53 Abs. 4 für Anbieter von GPAI-Modellen zusätzlich Praxisleitfäden im Sinne des Art. 56.

Zertifizierungs-Entscheidung (Praxisempfehlung): Für eine Zertifizierung sprechen drei Punkte — erstens fordern Kunden oder Ausschreibungen einen Managementsystem-Nachweis, zweitens sind Sie bei mindestens einem System Anbieter (Art. 3 Nr. 3), drittens betreiben Sie mehr als ein Hochrisiko-System nach Anhang III. Trifft keiner davon zu, genügen die Nachweise aus den Bausteinen 1 bis 5.

Rechtslage Österreich

Für die KI-VO gilt in Österreich nichts anderes: Sie ist eine unmittelbar anwendbare EU-Verordnung, alle oben genannten Artikel und Termine sind identisch, ein Umbau der Fundstellen ist nicht nötig. National geregelt sind die zuständigen Behörden und das Sanktionsregime im Rahmen von Art. 99 Abs. 1. Jeder Mitgliedstaat richtet mindestens eine notifizierende Behörde und mindestens eine Marktüberwachungsbehörde ein, benennt eine Marktüberwachungsbehörde als zentrale Anlaufstelle und macht die Kontaktinformationen öffentlich zugänglich (Art. 70 Abs. 1 und 2). In Deutschland ist Marktüberwachungsbehörde seit 29. Juli 2026 die Bundesnetzagentur (§ 2 Abs. 1 KI-MIG), soweit nicht sektorale Behörden — etwa die BaFin — zuständig sind; zentrale Anlaufstelle im Sinne des Art. 70 Abs. 2 ist nach § 6 Abs. 1 KI-MIG ebenfalls die Bundesnetzagentur. Österreich hat bis zum Stand dieses Artikels (17.08.2026) keine Marktüberwachungsbehörde nach Art. 70 KI-VO benannt; die KI-Servicestelle der RTR ist eine Informations- und Beratungsstelle ohne Aufsichtsbefugnis — prüfen Sie den Stand, bevor Sie eine Anlaufstelle oder einen Meldeweg in Ihre Policy schreiben. Praxisempfehlung: Legen Sie in der AI-Policy je Rechtsraum ein Feld „zuständige Marktüberwachungsbehörde / zentrale Anlaufstelle“ mit Abrufdatum an — solange es leer ist, bleibt die Lücke im Audit sichtbar. Für die GPAI-Modelle des Kapitels V liegt die Aufsicht ohnehin bei der Europäischen Kommission, die die Durchführung dem Büro für Künstliche Intelligenz überträgt (Art. 88 Abs. 1); die nationalen Marktüberwachungsbehörden in Deutschland und Österreich sind dafür nicht zuständig.

Zwei flankierende Unterschiede betreffen das Framework unmittelbar. Erstens der Bias-Check aus Baustein 3: Zuständig sind in Österreich die Gleichbehandlungsanwaltschaft und die Gleichbehandlungskommission, nicht die deutsche Antidiskriminierungsstelle des Bundes. Zweitens die Datenschutz-Organisation: In Deutschland ist ergänzend zu Art. 37 DSGVO ein Datenschutzbeauftragter zu benennen, wenn in der Regel mindestens 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigt sind oder Verarbeitungen einer Datenschutz-Folgenabschätzung nach Art. 35 DSGVO unterliegen (§ 38 Abs. 1 BDSG). Österreich sieht keine über Art. 37 DSGVO hinausgehende zahlenmäßige Benennungsschwelle vor (§ 5 DSG).