Annex IV — Technische Dokumentation

Feld	Wert
Provider	[Beispiel-Unternehmen GmbH]
KI-System	HR-Screen-AI
Annex-Pfad	annexiii4employment
Klassifikation	highrisk
Engine-Version	AI-ACT-2024-1689-v5.12.0
Erstellt am	2026-05-13
Land	DE

> Rechtsgrundlage: Art. 11 EU AI Act in Verbindung mit Annex IV. Diese Dokumentation muss vollständig vorliegen, bevor das System auf den EU-Markt gebracht oder in Betrieb genommen wird, und ist auf Anfrage einer Aufsichtsbehörde innerhalb 10 Werktagen vorzulegen. > > SME-Vereinfachung: Falls Du KMU bist (< 50 Mitarbeiter, < €10M Umsatz), kannst Du nach Art. 11(1) eine vereinfachte Form verwenden — sektionsweise gekennzeichnet.

---

Sektion 1 — Allgemeine Beschreibung des KI-Systems (Annex IV §1)

1.1 Identifikation

Feld	Wert
Handelsname / Bezeichnung	HR-Screen-AI
Versionsnummer	〔z.B. v1.0.0〕
Erste Markteinführung	〔YYYY-MM-DD〕
Letzte wesentliche Änderung	〔YYYY-MM-DD〕
Provider-Name + Adresse	[Beispiel-Unternehmen GmbH], 〔Adresse〕
Authorized Representative (falls non-EU Provider)	〔Name + Adresse in EU〕

1.2 Beabsichtigte Zweckbestimmung

Das System ist für den Einsatz in HR / Recruiting vorgesehen.

Konkrete Zweckbestimmung:

〔Beschreibe konkret den Einsatzzweck. Wichtig: Jede Erweiterung der Zweckbestimmung später kann eine Substantial-Modification nach Art. 25 sein.〕

1.3 Erwartete Nutzergruppen

〔Wer setzt das System ein? Compliance-Officer / Sachbearbeiter / Endkunden / etc.〕

1.4 Hardware-Anforderungen

〔CPU / GPU / RAM / Storage / Netzwerk-Anforderungen für den Betrieb.〕

1.5 Software-Form (Standalone / Cloud / Embedded)

〔z.B. SaaS-Web-Anwendung / On-Premise-Container / Embedded-Modul in Drittprodukt〕

---

Sektion 2 — Detaillierte Design-Beschreibung (Annex IV §2)

2.1 Methodische Grundlagen

〔Beschreibe die methodische Grundlage: Klassisches ML / Deep Learning / Symbolic AI / Hybrid〕

2.2 Architektur-Übersicht

〔Architektur-Diagramm einfügen + textuelle Beschreibung der Komponenten und Datenflüsse.〕

2.3 Modell-Details

Aspekt	Wert
Modell-Typ	〔z.B. Random Forest / Transformer / CNN / LLM〕
Modell-Architektur	〔z.B. eigene Architektur〕
Anzahl Parameter	〔falls relevant〕
Trainings-Framework	〔PyTorch / TensorFlow / scikit-learn / Custom〕
Inferenz-Latenz (P50/P95)	〔Werte angeben〕
Genauigkeits-Metriken (Test-Set)	〔Accuracy / F1 / AUC / etc.〕

2.4 Datenformate

Schritt	Eingabe	Ausgabe
Inferenz	〔Format〕	〔Format + Konfidenz-Score〕
Logging	—	〔strukturiertes Log〕
Audit-Trail	—	〔gespeicherte Felder〕

---

Sektion 3 — Monitoring + Kontroll-Massnahmen (Annex IV §3)

3.1 Performance-Monitoring

Metrik	Schwellenwert	Alarm-Kanal
Inferenz-Latenz	〔z.B. P95 < 500 ms〕	〔Slack / E-Mail / PagerDuty〕
Error-Rate	〔z.B. < 0.5 %〕	〔...〕
Drift-Erkennung	〔z.B. PSI > 0.2〕	〔...〕
Confidence-Distribution	〔z.B. Mean > 0.7〕	〔...〕

3.2 Anomalie-Erkennung

〔Welche Mechanismen sind implementiert, um anomalische Vorhersagen, Drift, oder Distribution-Shifts zu erkennen?〕

3.3 Auto-Stop bei Anomalien

〔Greift bei welchen Anomalien automatisch ein Auto-Stop / Fallback-Modus? Wie wird der menschliche Operator benachrichtigt?〕

---

Sektion 4 — Risk Management System (Art. 9 + Annex IV §4)

4.1 Risk-Management-Prozess

〔Beschreibe den iterativen Risk-Management-Zyklus: Identifikation → Bewertung → Mitigation → Monitoring → Re-Evaluation.〕

4.2 Identifizierte Risiken (engine-detected)

• DEADLINEANNEXIII_2026: deadline annex iii 2026

4.3 Mitigations-Massnahmen

Risiko	Mitigation	Restrisiko	Verantwortliche/r
〔Risiko 1〕	〔Massnahme〕	〔Niedrig/Mittel/Hoch〕	〔Person/Funktion〕
〔Risiko 2〕	〔...〕	〔...〕	〔...〕

4.4 Test-Verfahren

〔Welche Tests werden vor Roll-Out und in Produktion durchgeführt: Funktional, Adversarial, Bias, Performance.〕

---

Sektion 5 — Data Governance (Art. 10 + Annex IV §5)

⚠️ Personenbezogene Daten: Art. 10(5) erlaubt die Verarbeitung von besonderen Datenkategorien zur Bias-Korrektur, aber nur unter strengen Bedingungen. DSGVO-Compliance separat dokumentieren.

5.1 Trainings-Daten

Aspekt	Beschreibung
Daten-Quellen	〔Eigene / Lizenziert / Open / Synthetisch〕
Volumen	〔Anzahl Records〕
Erhebungs-Zeitraum	〔YYYY-MM bis YYYY-MM〕
Geographische Abdeckung	〔Länder / Regionen〕
Sprachen	〔...〕
Demographische Abdeckung	〔Alters- / Geschlechts- / Ethnie-Verteilung〕
Pre-Processing	〔Anonymisierung / Normalisierung / Augmentation〕

5.2 Validierungs- + Test-Daten

〔Sind Validierungs- und Test-Daten getrennt vom Training? Anzahl Records pro Set? Stratifikation?〕

5.3 Bias-Bewertung

〔Welche Bias-Tests wurden durchgeführt? z.B. Disparate Impact, Equal Opportunity, Demographic Parity. Resultate angeben.〕

5.4 Daten-Qualitäts-Massnahmen

〔Outlier-Erkennung / Mislabeling-Audit / Duplikat-Erkennung / Konsistenz-Checks.〕

---

Sektion 6 — Logging-Fähigkeiten (Art. 12 + Annex IV §6)

6.1 Geloggte Ereignisse

Event-Typ	Felder	Aufbewahrungs-Frist
Inferenz-Anfrage	〔Timestamp, User-ID, Input-Hash, Output, Confidence〕	〔mind. 6 Monate, Art. 12(2)〕
Override-Ereignis	〔Timestamp, User-ID, Original-Output, Override-Output, Begründung〕	〔mind. 6 Monate〕
Modell-Update	〔Version, Datum, Trainings-Daten-Hash, Verantwortliche〕	〔Lebenszeit + 10 Jahre, Art. 18〕
Anomalie	〔Timestamp, Typ, Schweregrad, Massnahme〕	〔mind. 6 Monate〕

6.2 Logging-Architektur

〔Wo werden Logs gespeichert? Welche Sicherheits-Massnahmen (Verschlüsselung, Zugriff, Manipulationsschutz)?〕

6.3 Log-Bereitstellung

〔Wie kann der Deployer auf die Logs zugreifen? In welchem Format können sie an Aufsichtsbehörden übergeben werden?〕

---

Sektion 7 — Genauigkeit, Robustheit, Cybersecurity (Art. 15)

7.1 Genauigkeits-Metriken

Metrik	Test-Set	Produktion (rolling 30d)	Schwellenwert
〔z.B. Accuracy〕	〔Wert〕	〔Wert〕	〔min. Wert〕
〔z.B. F1-Score〕	〔...〕	〔...〕	〔...〕
〔z.B. AUC〕	〔...〕	〔...〕	〔...〕

7.2 Robustheit-Tests

〔Adversarial-Tests / Out-of-Distribution-Tests / Stress-Tests. Resultate angeben.〕

7.3 Cybersecurity-Massnahmen

Massnahme	Implementiert?	Verantwortliche/r
Modell-Encryption-at-Rest	〔Ja/Nein〕	〔...〕
API-Authentifizierung (OAuth2 / mTLS)	〔...〕	〔...〕
Rate-Limiting	〔...〕	〔...〕
Input-Validation gegen Adversarial-Inputs	〔...〕	〔...〕
Audit-Trail-Integrity (signed Hash)	〔...〕	〔...〕
Penetration-Testing-Frequenz	〔z.B. jährlich〕	〔...〕

7.4 Patch-Management

〔Wie schnell werden Sicherheits-Patches eingespielt? Wer entscheidet?〕

---

Sektion 8 — Human Oversight (Art. 14 + Annex IV §7)

8.1 Aufsichts-Architektur

〔Wie ist das System für menschliche Aufsicht designt? Was kann der Operator sehen, hinterfragen, überstimmen?〕

8.2 UI-Massnahmen für Operator

〔Welche Anzeigen, Tooltips, Warnungen, Konfidenz-Indikatoren werden im UI gezeigt?〕

8.3 Override-Mechanismus

〔Wie kann der Operator eine KI-Entscheidung überstimmen? Wie wird das geloggt?〕

8.4 Stop-Mechanismus

〔Wie kann das System manuell pausiert oder gestoppt werden? Welche Auswirkung hat das auf laufende Operationen?〕

8.5 Operator-Schulung

〔Welche Schulung müssen Operatoren absolvieren, bevor sie das System bedienen?〕

---

Sektion 9 — Performance + Limitations (Annex IV §8)

9.1 Bekannte Limitationen

〔Welche Edge-Cases performt das System schlechter? Welche Eingaben sollten nicht verwendet werden?〕

9.2 Vorhersagbare Fehler

〔Welche Fehler-Typen sind vorhersehbar? Wie verhält sich das System bei Fehlern?〕

9.3 Risiken bei zweckwidrigem Gebrauch

〔Falls das System zweckwidrig genutzt wird (z.B. für eine andere Zielgruppe) — welche Risiken?〕

9.4 Compliance-Erklärung

Hiermit bestätigt [Beispiel-Unternehmen GmbH] als Provider, dass das KI-System HR-Screen-AI in Übereinstimmung mit Art. 11 EU AI Act und Annex IV dokumentiert wurde.

Verantwortliche/r	Funktion	Datum	Unterschrift
〔Name〕	Technischer Leiter	〔YYYY-MM-DD〕	〔...〕
〔Name〕	Quality Assurance	〔YYYY-MM-DD〕	〔...〕
〔Name〕	Compliance-Officer	〔YYYY-MM-DD〕	〔...〕

---

> Diese Technische Dokumentation wurde am 2026-05-13 mit ai-risk-check.com (Engine AI-ACT-2024-1689-v5.12.0) für 15 Pflichten und 4 regulatorische Pfade vorbereitet. Die endgültige Validität liegt beim Provider. > > Audit-Trail-Hash: 〔Hash aus Audit-Package einfügen〕