Ilustración editorial para Evaluación de impacto en derechos fundamentales para IA: cómo decidir si corresponde y qué documentar
Imagen generada con gpt-image-2.5-sunburst para InferamaQuelle ↗
01

Geltungsbereich und Vorbehalt: eine Bewertung als Grundlage für Entscheidungen vor dem Einsatz

Die Folgenabschätzung für Grundrechte nach Artikel 27 der Verordnung über künstliche Intelligenz, dem sogenannten AI Act, ist eine vorgelagerte Analyse, die bestimmte Betreiber vor dem Einsatz bestimmter Hochrisiko-KI-Systeme durchführen müssen. In der Praxis soll sie untersuchen, wie sich die vorgesehene Nutzung im konkreten Kontext auf Personen oder Gruppen auswirken könnte, und festlegen, welche Maßnahmen, Verantwortlichen und Reaktionsmechanismen erforderlich sind, bevor der Einsatz freigegeben wird.

Sie ist weder eine Zertifizierung des Systems noch eine Garantie dafür, dass keine Schäden entstehen. Ebenso wenig ist sie eine allgemeine Bewertung sämtlicher Tätigkeiten einer Organisation. Eine Datenschutz-Folgenabschätzung (DSFA) ersetzt sie auch nicht automatisch. Dieser Leitfaden hat einen engeren Zweck: Er soll dabei helfen festzustellen, ob die Pflicht im konkreten Fall gilt, und die erforderlichen Arbeitsschritte so zu ordnen, dass die Einsatzentscheidung nachvollziehbar bleibt.

Die maßgeblichen Rechtsvorschriften können sich ändern. Die hier angegebenen offiziellen Quellen enthalten eine Änderung aus dem Jahr 2026, die unter anderem die Nutzung von Elementen einer DSFA und den von der KI-Behörde zu erstellenden Fragebogen betrifft. Prüfen Sie daher vor Anwendung dieses Leitfadens den geltenden konsolidierten Rechtsakt, die offiziellen Formulare und den für den jeweiligen Fall geltenden Zeitplan. Dieser Leitfaden strukturiert die Analyse, stellt aber keine Rechtsberatung dar.

02

Prüfung der Anwendbarkeit: Wer bewerten muss und welche Nutzung zu prüfen ist

Die Pflicht nach Artikel 27 gilt nicht unterschiedslos für jede Organisation, die KI nutzt. Grundsätzlich ist zu prüfen, ob das System unter die einschlägige Kategorie der Hochrisiko-Systeme fällt und ob der Betreiber zu einer der in der Vorschrift genannten Kategorien gehört. Artikel 27 erfasst unter anderem Einrichtungen des öffentlichen Rechts, private Einrichtungen, die öffentliche Dienstleistungen erbringen, sowie Betreiber bestimmter Hochrisiko-Systeme in den Bereichen Kredit und Lebens- oder Krankenversicherung.

Die Bewertung bezieht sich auf die tatsächliche vorgesehene Nutzung, nicht nur auf den Produktnamen oder eine allgemeine Einstufung des Anbieters. Ermitteln Sie den Zweck, die aktivierten Funktionen, den organisatorischen Prozess, in den das System eingebettet ist, und die betroffenen Personen. Hat ein Werkzeug mehrere Einsatzbereiche, sollten Sie jeden Anwendungsfall gesondert betrachten: Die Pflicht und die Risiken können sich je nach Einsatz unterscheiden.

Artikel 27 nimmt die im Anhang III Nummer 2 genannten Hochrisiko-Systeme von dieser besonderen Pflicht aus. Diese Ausnahme darf nicht auf jedes System übertragen werden, das lediglich ein begrenztes Risiko zu haben scheint. Sie klärt auch nicht automatisch andere Pflichten aus dem AI Act, dem Datenschutzrecht oder sektoralen Vorschriften. Hängt die Einstufung von einer Ausnahme, einer Änderung der Nutzung oder einer Auslegung des Zwecks ab, dokumentieren Sie die Grundlage dieser Schlussfolgerung und lassen Sie sie rechtlich prüfen.

Die Entscheidungsfrage lässt sich so zusammenfassen: Gehört die Organisation zu den erfassten Betreibern? Fallen das System und der konkrete Anwendungsfall in den maßgeblichen Anwendungsbereich? Greift eine Ausnahme? Und ist eine bereits durchgeführte Bewertung für diese Nutzung weiterhin gültig? Fehlen Informationen für eine Antwort, besteht die verantwortungsvolle Schlussfolgerung nicht darin, von einer Nichtanwendbarkeit auszugehen. Benennen Sie stattdessen die fehlende Information, die dafür zuständige Person und die Bedingung, die einer abschließenden Freigabe entgegensteht.

Erste Schritte zur Prüfung der Anwendbarkeit

  1. 01Stellen Sie fest, welche Organisation über den Einsatz des Systems entscheidet und welche Rolle sie dabei hat: Betreiber, Anbieter oder je nach Tätigkeit beides.
  2. 02Beschreiben Sie das System und den konkreten Anwendungsfall. Bestätigen Sie die Einstufung als Hochrisiko-System anhand der einschlägigen Unterlagen und des konsolidierten Rechtsakts.
  3. 03Prüfen Sie, ob die Organisation zu einer in Artikel 27 genannten Kategorie gehört. Dazu zählen öffentliche Einrichtungen, bestimmte private Anbieter öffentlicher Dienstleistungen sowie die von der Vorschrift erfassten Kredit- und Versicherungsfälle.
  4. 04Prüfen Sie, ob die Ausnahme für Anhang III Nummer 2 oder eine andere relevante rechtliche Bedingung greift, und dokumentieren Sie die Begründung.
  5. 05Wenn die Pflicht gilt, planen Sie die Bewertung vor der ersten Nutzung und vor der Freigabe des Einsatzes. Wenn sie Ihrer Einschätzung nach nicht gilt, dokumentieren Sie die Gründe und die Änderungen, bei denen die Einschätzung erneut geprüft werden muss.
03

Zeitpunkt, Verantwortlichkeiten und Kommunikation mit der Behörde

Die Bewertung muss vor dem maßgeblichen Einsatz abgeschlossen sein, nicht erst, nachdem Schäden eingetreten sind oder ein regulärer Betrieb begonnen hat. Der Kontrollpunkt sollte in der Praxis vor der Freigabe des Zugangs für Nutzerinnen und Nutzer liegen, bevor das System in einen Entscheidungsprozess integriert wird oder bevor seine Ergebnisse Entscheidungen über Personen beeinflussen können.

Die organisatorische Verantwortung muss ausdrücklich zugewiesen werden. Das Team, das den Anwendungsfall vorantreibt, beschreibt den Prozess und die Entscheidungen, die das System unterstützen soll. Die Funktionen für Compliance, Datenschutz, Grundrechte, Sicherheit und Betrieb prüfen jeweils ihren Zuständigkeitsbereich. Eine Stelle mit ausreichender Entscheidungsbefugnis bestimmt anschließend, ob der Einsatz freigegeben, geändert oder gestoppt wird. Die Zusammenarbeit darf nicht dazu führen, dass unklar bleibt, wer für die Fertigstellung und Aktualisierung der Bewertung verantwortlich ist.

Die Vorschrift sieht vor, dass die Bewertung nach ihrer Durchführung der zuständigen Marktüberwachungsbehörde übermittelt wird. Welche Behörde zuständig ist und welcher Übermittlungsweg und welches Format gelten, muss anhand der Zuständigkeit, der nationalen Behördenstruktur und der aktuellen offiziellen Anweisungen geprüft werden. Erfinden Sie weder eine Empfängerstelle noch ein Verfahren auf Grundlage einer internen Vorlage.

Legen Sie außerdem fest, wann die Bewertung aktualisiert werden muss. Eine Änderung des Zwecks, der betroffenen Bevölkerung, der Eingabedaten, der Nutzungshäufigkeit, des Automatisierungsgrads, der menschlichen Aufsicht oder der Betriebsbedingungen kann die Analyse verändern. Dokumentieren Sie, welche Änderungen eine erneute Prüfung auslösen, wer sie erkennt und wer den Einsatz bis zum Abschluss der Prüfung aussetzen kann.

Sinnvoll zuzuweisende interne Verantwortlichkeiten

FunktionErwarteter BeitragZu dokumentierende Nachweise
ProzessverantwortlicheZweck, Prozessschritte und vom System beeinflusste EntscheidungenProzessübersicht, operative Verantwortliche und Nutzungsgrenzen
Technisches Team oder Anbieter, soweit zutreffendBekannte Fähigkeiten, Grenzen, Anweisungen und NutzungsbedingungenSystemdokumentation, Version und mitgeteilte Annahmen
Datenschutz und ComplianceAnalyse der anwendbaren Pflichten und Abstimmung mit anderen BewertungenSchlussfolgerungen, Querverweise und offene Punkte
Verantwortliche für GrundrechteErmittlung betroffener Gruppen, möglicher Schäden und AbhilfemaßnahmenKontextbezogene Risiken, Maßnahmen und Restrisiken
FreigabestelleEntscheidung über Freigabe, Auflagen, Änderung oder StoppEntscheidungsprotokoll, Bedingungen und Überprüfungsdatum
04

Was zu dokumentieren ist: vom Zweck zu den betroffenen Personen

Artikel 27 legt einen Kern an Informationen fest, der das System mit seinem Nutzungskontext verknüpft. Die Bewertung muss die Prozesse beschreiben, in denen das System entsprechend seinem vorgesehenen Zweck eingesetzt wird; die Dauer und Häufigkeit der Nutzung; die Kategorien von Personen und Gruppen, die wahrscheinlich betroffen sind; die spezifischen Schadensrisiken in diesem Kontext unter Berücksichtigung relevanter Informationen des Anbieters; die Anwendung menschlicher Aufsichtsmaßnahmen; und die Maßnahmen, die im Fall der Verwirklichung von Risiken ergriffen werden, einschließlich interner Governance-Regelungen und Beschwerdemechanismen.

Damit diese Punkte eine Entscheidung unterstützen, sollten Sie vage Formulierungen wie „es kann zu Verzerrungen kommen“ oder „eine menschliche Aufsicht wird sichergestellt“ vermeiden. Erklären Sie, wer geschädigt werden könnte, durch welchen Prozessschritt dies geschehen könnte, welche konkrete Folge plausibel ist und welche Nachweise eine solche Folge erkennen lassen würden. Hängt eine Auswirkung von unbekannten Umständen ab – etwa von der Größe einer betroffenen Gruppe oder der Qualität bestimmter Daten –, halten Sie die Unsicherheit fest, statt sie in eine Tatsachenbehauptung umzuwandeln.

Die vom Anbieter bereitgestellten Informationen können helfen, die Fähigkeiten, Grenzen und bekannten Risiken des Systems zu verstehen. Sie ersetzen jedoch nicht die Analyse des Betreibers. Dasselbe System kann je nach Zulassungskriterien, Auslegung seiner Ergebnisse durch Beschäftigte, Möglichkeit zur Datenkorrektur und Zugang der betroffenen Personen zu Anfechtungswegen unterschiedliche Folgen haben. Die Bewertung muss diese konkreten Bedingungen abbilden.

Konsultationen mit betroffenen Personen, Vertretungen oder Fachleuten können Informationen liefern, die in technischen Unterlagen fehlen. Dabei muss zwischen gesetzlichen Pflichten und redaktionellen oder organisatorischen bewährten Verfahren unterschieden werden: Schreibt die Vorschrift keine bestimmte Konsultationsmethode vor, dokumentieren Sie die Konsultation als gewählte Maßnahme zur Verbesserung der Analyse und nicht als eine angeblich in Artikel 27 festgelegte Pflicht.

Arbeitsvorlage für jedes Risiko

ElementLeitfrageBeispiel für einen Nachweis
KontextWelche Entscheidung oder Prozessphase wird vom System beeinflusst?Prozessdiagramm und Beschreibung der vorgesehenen Nutzung
Betroffene PersonenWer ist direkt oder indirekt betroffen?Kategorien von Antragstellenden, Nutzenden oder exponierten Gruppen
Möglicher SchadenWelche konkrete Folge könnte eintreten?Verzögerung, Ausschluss, Ungleichbehandlung oder Schwierigkeiten bei der Anfechtung
Ursachen und BedingungenWelche Daten, Regeln oder Praktiken könnten zum Schaden beitragen?Verwendete Felder, Schwellenwerte, Anweisungen und betriebliche Praktiken
Maßnahme und VerantwortlicheWelche Handlung mindert das Risiko und wer führt sie aus?Zugewiesene Tests, Kontrollen, menschliche Prüfung oder Beschwerdekanal
RestrisikoWas könnte nach Umsetzung der Maßnahmen weiterhin eintreten?Verbleibende Einschränkungen und Kriterien für eine erneute Prüfung der Nutzung
05

Von Risiken zu Entscheidungen: Maßnahmen, Nachweise und Grenzen

Eine bloße Liste von Risiken reicht nicht aus. Jedes relevante Risiko muss mit einer überprüfbaren Maßnahme, einer verantwortlichen Person, einer Frist und einem Nachweis verknüpft werden, anhand dessen sich die Wirksamkeit der Maßnahme kontrollieren lässt. Hängt eine Maßnahme von einer anderen Stelle, einer noch nicht umgesetzten Funktion oder einer ausstehenden Validierung ab, darf sie nicht so beschrieben werden, als sei sie bereits betriebsbereit. Behandeln Sie sie als Voraussetzung für den Einsatz.

Zu den Maßnahmen können gehören: den Zweck oder den Kreis der Berechtigten einzuschränken, die Nutzungshäufigkeit zu verringern, die Datenqualität zu verbessern, Schwellenwerte für eine Überprüfung festzulegen, Ergebnisse auf relevante Unterschiede zu testen, vor nachteiligen Entscheidungen eine menschliche Prüfung vorzuschreiben, Korrekturen und Beschwerden zu ermöglichen oder das System bei Anzeichen für Schäden anzuhalten. Solche Optionen müssen im jeweiligen Kontext begründet werden. Sie bilden weder eine abschließende Liste noch gewährleisten sie für sich genommen die Einhaltung der Vorschriften.

Menschliche Aufsicht muss konkret und praktikabel sein. Legen Sie fest, wer prüft, welche Informationen diese Person erhält, welche Schulung erforderlich ist, welchen Spielraum sie hat, vom Ergebnis abzuweichen, und wie sie die Entscheidung dokumentiert. Eine Person, die Ausgaben lediglich automatisch bestätigt und weder Zeit noch Informationen oder Befugnisse zum Eingreifen hat, stellt nicht allein deshalb eine wirksame Maßnahme dar, weil sie in einem Verfahren erwähnt wird.

Eine Freigabe kann mit Bedingungen verbunden sein. So könnte ein eingeschränkter Pilotbetrieb erst nach Abschluss von Tests, Validierung des Beschwerdekanals und Bereitstellung von Ressourcen für die Überprüfung erlaubt werden. Die Entscheidung sollte Kriterien für eine Aussetzung oder Änderung enthalten, etwa Fehler oberhalb eines zuvor festgelegten Schwellenwerts, Beschwerden, die auf ein Muster hindeuten, nicht genehmigte Systemänderungen oder die Unfähigkeit, die zugesagte Aufsicht durchzuführen. Konkrete Schwellenwerte müssen sich aus der Bewertung ergeben und dürfen nicht als allgemeingültige Werte erfunden werden.

Den Entscheidungszyklus abschließen

  1. 01Formulieren Sie das Risiko als Zusammenhang zwischen Kontext, betroffenen Personen und möglichem Schaden. Kennzeichnen Sie, welche Aspekte gesicherte Tatsachen und welche Hypothesen sind.
  2. 02Wählen Sie eine verhältnismäßige Maßnahme und legen Sie Verantwortliche, Termin, Ressourcen und Wirksamkeitsnachweis fest.
  3. 03Dokumentieren Sie das Restrisiko und bestimmen Sie, ob es für die Organisation und im Hinblick auf ihre Pflichten vertretbar ist. Verbergen Sie es nicht hinter der Bezeichnung „gemindert“.
  4. 04Legen Sie ausdrückliche Bedingungen fest: freigeben, mit Einschränkungen freigeben, bis zur Erledigung offener Punkte zurückstellen oder nicht einsetzen.
  5. 05Definieren Sie die Überwachung, den Umgang mit Beschwerden und Vorfällen sowie Änderungen, die eine erneute Prüfung oder Aussetzung der Nutzung erfordern.
06

Verhältnis zur DSFA: Abstimmen, ohne gleichzusetzen

Eine DSFA, also eine Datenschutz-Folgenabschätzung, wird nach den Datenschutzvorschriften durchgeführt, wenn eine geplante Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Ihr Schwerpunkt liegt auf der Verarbeitung personenbezogener Daten und den datenschutzrechtlichen Pflichten. Die Bewertung nach Artikel 27 richtet den Blick auf die Auswirkungen der Nutzung des KI-Systems auf Grundrechte innerhalb des vom AI Act festgelegten Anwendungsbereichs. Es kann Überschneidungen geben, doch Zweck und Umfang sind nicht identisch.

Artikel 27 behandelt das Verhältnis zu Datenschutz-Folgenabschätzungen. Außerdem weisen die hier angegebenen offiziellen Quellen darauf hin, dass eine Änderung aus dem Jahr 2026 die Wiederverwendung von Elementen einer DSFA und den von der KI-Behörde zu erstellenden Fragebogen betrifft. Frühere Aussagen dazu, ob die Bewertung eine DSFA ergänzen, wiederverwenden oder auf sie verweisen muss, sollten daher nicht automatisch übernommen werden. Prüfen Sie den geltenden konsolidierten Rechtsakt und die offiziellen Anweisungen, um die aktuellen Bedingungen festzustellen.

Als Arbeitsmethode empfiehlt sich eine Zuordnungstabelle. Kennzeichnen Sie, welche Analysen der DSFA auch für betroffene Personen, Daten oder Risiken der Grundrechtsbewertung relevant sind; welche Punkte einer zusätzlichen Analyse bedürfen; und welche Fragen eine Bewertung mit dem jeweils anderen Zweck nicht abdeckt. Querverweise vermeiden Doppelarbeit, müssen aber so angelegt sein, dass eine prüfende Person die Nachweise finden und verstehen kann, weshalb sie für den betreffenden Punkt relevant sind.

Ist im konkreten Fall keine DSFA erforderlich, beweist das nicht, dass auch die Bewertung nach Artikel 27 entfällt. Und liegt eine DSFA vor, belegt ihre bloße Existenz nicht, dass Risiken außerhalb der Datenverarbeitung erfasst wurden. Die Organisation muss die für den konkreten Fall geltende Schlussfolgerung, die zugrunde gelegte aktuelle Rechtslage und noch zu klärende Lücken dokumentieren.

07

Praxisbeispiel: Prüfung von Kreditanträgen

Angenommen, eine Organisation nutzt ein Hochrisiko-System, um die Prüfung von Kreditanträgen zu unterstützen. Dieses Beispiel ist hypothetisch. Es besagt weder, dass ein bestimmtes System existiert, noch dass eine konkrete Organisation verpflichtet ist oder tatsächlich Schäden eingetreten sind. Vor einer Anwendung müsste die Organisation die Einstufung, ihre Rolle, die vorgesehene Nutzung und die rechtlichen Bedingungen des Falls bestätigen.

Zunächst wird der Prozess abgebildet: Welche Informationen erhält das System? Welches Ergebnis erzeugt es? Wer sieht dieses Ergebnis, und empfiehlt, ordnet oder bestimmt es eine Entscheidung? Außerdem werden Nutzungsdauer und -häufigkeit beschrieben. Die Aussage „das Modell bewertet Kreditwürdigkeit“ klärt nicht, ob Beschäftigte von der Empfehlung abweichen können, ob das Ergebnis eine automatische Ablehnung auslöst oder ob eine zweite Prüfung stattfindet.

Anschließend werden die betroffenen Personen ermittelt – zum Beispiel Antragstellende und Personen, deren Daten die Bewertung indirekt beeinflussen – und mögliche Schäden als von der Organisation zu prüfende Hypothesen formuliert. Untersucht werden könnte, ob nachteilige Entscheidungen mit unvollständigen Daten zusammenhängen, bestimmte Gruppen unverhältnismäßig betroffen sind, Fehler schwer korrigiert werden können oder es Hindernisse gibt, eine Entscheidung zu verstehen und anzufechten. Das sind keine Aussagen über ein reales Modell; sie müssen anhand von Daten, Tests und des konkreten Kontexts geprüft werden.

Die Maßnahmen sollten auf die Hypothesen reagieren. Die Organisation könnte Herkunft und Qualität der Daten überprüfen, Ergebnisse und relevante Unterschiede testen, sicherstellen, dass ein Score bei nachteiligen Entscheidungen nicht die alleinige Grundlage bildet, wenn die Analyse eine Prüfung erforderlich erscheinen lässt, Beschäftigte schulen, Gründe für Abweichungen von einer Empfehlung dokumentieren und einen zugänglichen Weg zur Datenkorrektur oder Beschwerde anbieten. Für jede Kontrolle ist festzulegen, wer sie durchführt und anhand welcher Ergebnisse sie als unzureichend gelten würde.

Vor der Freigabe sollte die zuständige Stelle prüfen, ob die Maßnahmen tatsächlich bestehen und die Aufsicht wirksame Eingriffsmöglichkeiten bietet. Fehlen Testergebnisse, ist kein betriebsbereiter Beschwerdekanal vorhanden oder lässt sich nicht erklären, welche Informationen eine Entscheidung stützen, kann es umsichtig sein, den Einsatz zurückzustellen, einzuschränken oder nicht freizugeben, bis diese Punkte geklärt sind. Die Organisation muss ihre Schlussfolgerung auf eigene Nachweise stützen; das Beispiel ersetzt ihre Analyse nicht.

08

Prüfliste vor der Freigabe

Eine Prüfliste ist hilfreich, wenn sie zu einer Entscheidung führt und nicht bloß zum Abhaken von Punkten wird. Jede Antwort sollte eine Quelle und eine verantwortliche Person haben sowie, falls erforderlich, eine ausstehende Maßnahme auslösen. Halten Sie die im geltenden Rechtsakt festgestellten gesetzlichen Anforderungen getrennt von internen Verfahren, die die Organisation zur Verbesserung der Analyse ergänzt.

Prüfen Sie vor dem Abschluss, ob das Dokument das System, seine Version, den Zweck, die betroffenen Prozesse sowie Dauer und Häufigkeit der Nutzung genau bezeichnet. Vergewissern Sie sich, dass betroffene Personen und Gruppen hinreichend konkret beschrieben sind, jedes Risiko mit einem möglichen Schaden im jeweiligen Kontext verknüpft ist und Einschränkungen sowie relevante Informationen des Anbieters berücksichtigt wurden.

Bestätigen Sie außerdem, dass menschliche Aufsicht in der Praxis stattfindet, Maßnahmen Verantwortlichen und Nachweisen zugeordnet sind und die Restrisiken bekannt sind. Prüfen Sie die Mechanismen zur Erkennung von Problemen, zur Entgegennahme von Beschwerden und zur Reaktion auf Vorfälle. Wenn betroffene Personen oder Fachleute konsultiert wurden, dokumentieren Sie, welchen Beitrag die Konsultation geleistet und welche Entscheidungen sie beeinflusst hat. Wurde keine Konsultation durchgeführt, halten Sie fest, ob dies die Analyse einschränkt.

Prüfen Sie zuletzt die Mitteilung an die zuständige Behörde, gegebenenfalls die Verweise auf eine DSFA, das Datum der nächsten Überprüfung und die Bedingungen, die eine erneute Bewertung auslösen. Die Freigabe sollte angeben, welche Dokumentationsversion geprüft wurde, welche Bedingungen für die Nutzung gelten und wer befugt ist, den Einsatz zu stoppen.

Abschlussprüfung

PrüfpunktVoraussetzung für den nächsten SchrittWenn der Punkt offen ist
AnwendbarkeitBetreiber, System, Nutzung und mögliche Ausnahme geprüft und dokumentiertEinstufung eskalieren und nicht einfach von einer Nichtanwendbarkeit ausgehen
NutzungskontextProzess, Zweck, Dauer und Häufigkeit beschriebenProzessübersicht gemeinsam mit dem operativen Bereich vervollständigen
Personen und RisikenBetroffene Gruppen und mögliche Schäden mit Nachweisen oder ausgewiesenen Unsicherheiten ermitteltDaten beschaffen, konsultieren und Hypothesen überprüfen
MaßnahmenVerantwortliche, Fristen, Aufsicht und Beschwerdemechanismen festgelegtRessourcen zuweisen und die Maßnahme als ausstehend behandeln
EntscheidungRestrisiko und Freigabebedingungen ausdrücklich benanntEinsatz zurückstellen, einschränken oder ablehnen, bis das Erforderliche geklärt ist
Pflege der BewertungÄnderungen, Überwachung, zuständige Behörde und Überprüfung vorgesehenKontrollen festlegen und offizielles Verfahren bestätigen
09

Was vor der Anwendung dieses Leitfadens zu prüfen ist

Die Bewertung muss sich auf die zum maßgeblichen Zeitpunkt geltende konsolidierte Fassung des AI Act stützen und nicht allein auf Zusammenfassungen, Entwürfe oder ältere Fassungen. Die angegebenen Quellen nennen eine Gesetzesänderung aus dem Jahr 2026 und eine Konsolidierung mit Stand Juli 2026. Sie weisen außerdem darauf hin, dass die Europäische Kommission ihre häufig gestellten Fragen im August 2026 aktualisiert hat. Da sich Vorschriften und Fristen ändern können, prüfen Sie, ob diese Fassungen zum Zeitpunkt und zum konkreten Anwendungsfall passen.

Prüfen Sie im offiziellen Rechtsakt den genauen Kreis der verpflichteten Betreiber, die erfassten Systemkategorien, die Ausnahme, die vorgeschriebenen Inhalte, die Übermittlung an die Behörde und die Auswirkungen der Änderungen auf die DSFA. Klären Sie außerdem, ob inzwischen endgültige offizielle Formulare veröffentlicht wurden und wie die Mitteilung im betreffenden Mitgliedstaat einzureichen ist. Eine FAQ kann der Orientierung dienen, hat aber keinen Vorrang vor dem Gesetzgebungsakt.

Den Zeitplan für die Anwendung sollten Sie gesondert prüfen: Der maßgebliche Zeitpunkt hängt von den geltenden Vorschriften und der konkreten Systemkategorie ab. Leiten Sie kein allgemeines Datum aus einer Nachricht oder einer früheren Fassung der Verordnung ab. Bestehen Zweifel am Anwendungsbereich, an der zuständigen Behörde oder am Verhältnis zu anderen Vorschriften, holen Sie vor der Freigabe rechtlichen Rat ein.

Ergänzen Sie die Analyse durch die internen Verfahren der Organisation für Sicherheit und Risikomanagement, durch den Prozess zum Vergleich von Systemen und durch die Prüfung von Alternativen vor der Auswahl einer Lösung. Diese Prüfungen unterstützen die Entscheidung, ersetzen aber keine gesetzlich vorgeschriebene Bewertung.

Offene Fragen

  • Die angegebenen Quellen verweisen auf eine Änderung aus dem Jahr 2026 und einen konsolidierten Rechtsakt vom Juli 2026. Dieser Leitfaden gibt jedoch nicht sämtliche Bestimmungen vollständig wieder oder legt sie umfassend aus. Die genauen Auswirkungen auf die Wiederverwendung von Elementen einer DSFA, den Fragebogen der KI-Behörde und die Anforderungen aus Artikel 27 sind im geltenden offiziellen Rechtsakt zu prüfen.
  • Welche nationale Behörde zuständig ist und wie die Mitteilung in einem konkreten Fall erfolgt, wird hier nicht bestimmt. Das hängt von der Zuständigkeit und den geltenden offiziellen Anweisungen ab.
  • Ein allgemeines Anwendungsdatum wird nicht festgelegt. Der Zeitplan muss anhand der jeweiligen Systemkategorie und des konkreten Falls unter Berücksichtigung der geltenden Gesetzesänderungen geprüft werden.
  • Das Kreditbeispiel enthält keine Daten zu einem realen System. Ob die genannten Risiken bestehen, wie groß sie sind und wie sie verteilt sind, muss die einsetzende Organisation selbst überprüfen.
10

Weiter entdecken

10

Verwendete Quellen

03

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.

Korrektur vorschlagen