Template: Grundrechte-Folgenabschätzung (AISIA) nach Art. 27

Wofür

Dieses Template strukturiert die Grundrechte-Folgenabschätzung — im Toolkit als AI System Impact Assessment (AISIA), in der Verordnung als Fundamental Rights Impact Assessment (FRIA) bezeichnet. Es richtet sich an Deployer, die ein Hochrisiko-KI-System einsetzen und vor Inbetriebnahme dokumentieren müssen, welche Auswirkungen der Einsatz auf die Grundrechte betroffener Personen haben kann. Anders als das Risk Assessment nach Art. 9, das die Provider-Perspektive auf das System selbst einnimmt, betrachtet die AISIA den konkreten Einsatzkontext beim Deployer: dieselbe KI in zwei Organisationen kann sehr unterschiedliche Grundrechtsfolgen auslösen. Das Artefakt ist deshalb organisations- und prozessspezifisch und wird bei wesentlichen Änderungen am Einsatz fortgeschrieben.

Wann es Pflicht ist

Die Grundrechte-Folgenabschätzung ist nach Art. 27 EU AI Act (Verordnung (EU) 2024/1689) verpflichtend für bestimmte Deployer von Hochrisiko-KI-Systemen — namentlich Einrichtungen des öffentlichen Rechts, private Akteure, die öffentliche Dienste erbringen, sowie Deployer von Systemen nach Anhang III Nummer 5 Buchstaben b und c (Kreditwürdigkeitsprüfung sowie Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung). Die Bewertung muss vor der Inbetriebnahme erfolgen; ihr Ergebnis ist der Marktüberwachungsbehörde mitzuteilen. Art. 27 verzahnt sich mit der vom Provider bereitgestellten Information (Art. 13), den Maßnahmen zur menschlichen Aufsicht (Art. 14) und — wo eine Verarbeitung personenbezogener Daten vorliegt — mit der Datenschutz-Folgenabschätzung. Mit Enforcement-Wirksamkeit zum 02.12.2027 muss die AISIA belegbar durchgeführt sein, nicht erst vorgesehen.

Das Artefakt selbst

# Grundrechte-Folgenabschätzung (AISIA) — <System-Name> / <Einsatz>

## 0. Metadaten
- Deployer (Organisation, Rolle):
- KI-System / Version / Provider:
- Erstellt am / Letzte Revision / nächste Review:
- Verknüpfte Provider-Doku (Art. 13 Gebrauchsanweisung):
- Verknüpfte DSFA (falls vorhanden):
- Einsatz-Rechtsraum (DE / EU27-Rest / UK / CH):

## 1. Prozessbeschreibung (Art. 27 Abs. 1 lit. a)
- In welchen Deployer-Prozessen wird das System eingesetzt:
- Entscheidungstyp (unterstützend / (teil-)automatisiert):
- Anbindung an nachgelagerte Maßnahmen:

## 2. Zeitraum & Häufigkeit (lit. b)
- Geplanter Einsatzzeitraum:
- Frequenz / Fallvolumen:

## 3. Betroffene Personen & Gruppen (lit. c)
| Gruppe | Betroffenheit | Vulnerabilität | geschätzter Umfang |
|--------|---------------|----------------|--------------------|
|        |               |                |                    |

## 4. Spezifische Schadensrisiken für Grundrechte (lit. d)
| ID | Betroffenes Grundrecht | Schadensszenario | Eintritt (1-5) | Schwere (1-5) | Score |
|----|------------------------|------------------|----------------|---------------|-------|
| G-01 |                      |                  |                |               |       |

## 5. Menschliche Aufsicht (lit. e)
- Oversight-Maßnahmen (Verweis auf Art.-14-Konzept):
- Eingriffs- und Override-Möglichkeit:
- Qualifikation der aufsichtsführenden Personen:

## 6. Governance bei Risikoeintritt (lit. f)
- Interne Governance / Eskalation:
- Beschwerdemechanismus für Betroffene:
- Abhilfe- und Korrekturmaßnahmen:

## 7. Mitteilung an die Marktüberwachungsbehörde
- Ergebnis übermittelt am / Aktenzeichen:

Ausfüll-Anleitung

1. Metadaten zuerst: Verknüpfen Sie die AISIA mit der Provider-Gebrauchsanweisung (Art. 13) und der Klassifizierung — die Grundrechtsfolgen lassen sich nur im konkreten Einsatzkontext beurteilen.
2. Prozess konkret beschreiben (Abschnitt 1): Nicht das System abstrakt, sondern den tatsächlichen Geschäftsprozess. Halten Sie fest, ob die KI-Ausgabe eine Entscheidung vorbereitet oder faktisch trifft.
3. Zeitraum und Häufigkeit (Abschnitt 2): Fallvolumen und Frequenz bestimmen die Reichweite möglicher Grundrechtseingriffe — quantifizieren, wo möglich.
4. Betroffene benennen (Abschnitt 3): Auch indirekt Betroffene und besonders schutzbedürftige Gruppen aufnehmen.
5. Schäden grundrechtsbezogen formulieren (Abschnitt 4): Pro Szenario das konkret berührte Grundrecht nennen (z. B. Diskriminierungsverbot, Schutz personenbezogener Daten, Recht auf wirksamen Rechtsbehelf), nicht nur „Risiko allgemein".
6. Aufsicht referenzieren (Abschnitt 5): Auf das bestehende Human-Oversight-Konzept verweisen statt zu duplizieren.
7. Abhilfe vor Inbetriebnahme festlegen (Abschnitt 6): Beschwerdeweg und Eskalation müssen stehen, bevor das System produktiv geht.
8. Mitteilung dokumentieren (Abschnitt 7): Übermittlung des Ergebnisses an die Marktüberwachungsbehörde mit Datum und Aktenzeichen belegen.

Audit-Erwartung

Auditoren prüfen zuerst, ob die AISIA vor Inbetriebnahme erstellt wurde — ein nachträglich datiertes Dokument entwertet den Nachweis. Erwartet werden außerdem: ein erkennbarer Bezug zum konkreten Einsatzprozess (keine generische Vorlage), eine nachvollziehbare Verknüpfung der identifizierten Schäden mit den getroffenen Aufsichts- und Abhilfemaßnahmen, der Nachweis der Mitteilung an die Marktüberwachungsbehörde sowie eine Revisionshistorie, die belegt, dass die Bewertung bei Änderungen aktualisiert wurde. Wo eine Datenschutz-Folgenabschätzung existiert, achten Prüfer auf Konsistenz zwischen beiden Dokumenten.

Verwandte Artefakte

• Template: AI Risk Assessment nach Art. 9 — Provider-seitiges Pendant zur Risikoerfassung am System selbst.
• Für die Frage, ob Ihr Use-Case überhaupt hochrisiko ist und unter Anhang III fällt: die Use-Case-Bibliothek auf hochrisiko-ki.com.
• Zur Einordnung in die Risikoklassen-Systematik: ki-risikostufe.de.
• Vertiefender Kontext zu Deployer-Pflichten im Gesamtbild des EU AI Act: Leitfaden auf eu-ai-verordnung.de.
• Schweizer Anwendbarkeit (CH-Einsatz): ki-regulierung.ch.

AEGIRA AI Guardian operationalisiert diese Artefakte als laufende, evidenzbasierte Trust-Infrastructure — aegira.ai.