LF-KI-Sicherheit

Aus ISMS-Ratgeber WiKi
Version vom 2. April 2026, 14:34 Uhr von Dirk (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springenZur Suche springen

Dieses Leitfaden beschreibt technische Maßnahmen zur Absicherung von KI-Systemen im ISMS-Kontext. Es adressiert Lücken in der Umsetzung von EU AI Act (Art. 15, 13), BSI Grundschutz und ISO 27001 A.8.25ff. Die Maßnahmen gewährleisten Robustheit gegen Angriffe, Modellschutz und prüfbare Nachverfolgbarkeit. Sie sind für Hochrisiko-KI-Systeme zwingend erforderlich, um Haftungsrisiken zu minimieren und Audits zu bestehen.

Einleitung

Künstliche Intelligenz (KI) birgt erhebliche Sicherheitsrisiken, die durch den EU AI Act und nationale Standards wie BSI Grundschutz adressiert werden müssen. Dieser Leitfaden beschreibt die technischen Maßnahmen zu KI-Härtung, Modellsicherheit und Nachvollziehbarkeit, die für den sicheren Einsatz von KI-Systemen im Unternehmen zwingend erforderlich sind.

Zielgruppe: IT-Sicherheitsverantwortliche, Data Scientists und ISMS-Beauftragte.

Sinn und Zweck: Bereitstellung implementierbarer und prüfbarer Maßnahmen zur Erfüllung von EU AI Act Art. 12-15, Konformität mit ISO 27001 und Vermeidung von Haftungsrisiken. Die Maßnahmen ermöglichen Audits, schützen vor Angriffen und gewährleisten die Nachverfolgbarkeit kritischer Entscheidungen.

Die nachfolgenden Kapitel leiten direkt aus den gesetzlichen Pflichten ab und enthalten konkrete Umsetzungsschritte mit Prüfkriterien.

Rechtliche Grundlagen und Pflichten

Die Maßnahmen basieren auf zwingenden Anforderungen des EU AI Act und nationaler Standards:

  • EU AI Act Art. 15 (Hochrisiko-KI): Robustheit gegen Angriffe, Cybersicherheit, Härte-Maßnahmen.
  • EU AI Act Art. 13: Transparenzpflichten inklusive technischer Dokumentation und Nachvollziehbarkeit.
  • EU AI Act Art. 12: Qualitätsmanagement mit Risikobewertung und Auditfähigkeit (10-Jahre-Dokumentation).

Ziel: Haftungsminimierung, Audits bestand, Konformität mit NIS2 und DSGVO.

KI-Härtung (Robustheit gegen Angriffe)

KI-Härtung schützt KI-Systeme vor manipulierenden Angriffen durch Erhöhung der Robustheit. Sie verhindert, dass Angreifer Modelle durch gezielte Eingaben (Prompt Injection, Adversarial Examples) umgehen oder gefährliche Ausgaben provozieren.

Input-Sanitization

Input-Sanitization filtert bösartige Eingaben vor der Modellverarbeitung. Sie blockiert Jailbreak-Versuche, SQL-Injection und Prompt Injections, die Modelle zu unzulässigen Antworten zwingen. Erforderlich durch EU AI Act Art. 15 (Robustheit).

Best-Practice-Umsetzung:

  • Bibliothek llm-guard oder neural-classifier für Input-Vorfilterung.
  • Regex-Regeln für bekannte Angriffsmuster (ignore previous instructions, sudo, Base64-Payloads).
  • Whitelisting erlaubter Zeichenmengen (alphanumerisch + begrenzte Sonderzeichen).
  • Implementierung als Middleware (FastAPI/Flask): request.input = sanitize(request.input).

Rate Limiting

Begrenzt API-Aufrufe pro Benutzer/IP, um Denial-of-Service (DoS) und Brute-Force-Angriffe zu verhindern. Schützt Rechenressourcen und ermöglicht Anomalie-Erkennung.

Best-Practice-Umsetzung:

  • Redis-basiertes Sliding-Window-Limiting: 100 Requests/Stunde pro User-ID/IP.
  • Framework-Integration: FastAPI-Limiter (slowapi), Django-RateLimit.
  • Headers setzen: X-RateLimit-Remaining, Retry-After.
  • Monitoring: Prometheus-Metriken für Rate-Limit-Hits.

Output-Moderation

Prüft Modell-Ausgaben auf Toxizität, Hate Speech oder sensible Datenlecks vor Auslieferung. Verhindert rechtliche Haftung durch schädliche Inhalte.

Best-Practice-Umsetzung:

  • OpenAI Moderation API oder HuggingFace unitary/toxic-bert.
  • Kategorien: Hate, Violence, Self-Harm, PII (Personendaten).
  • Block-Regel: Score > 0.7 → Antwort verweigern mit "Inhalt nicht zulässig".
  • Fallback: Statische Regex für Kreditkarten/SVNr.

Adversarial Training

Trainiert Modelle mit feindlichen Beispielen, sodass sie Angriffe erkennen und abwehren. Erhöht Robustheit gegen OWASP LLM Top 10-Attacken.

Best-Practice-Umsetzung:

  • Dataset: OWASP LLM Top 10 + Anthropic Red-Team-Dataset.
  • Fine-Tuning: LoRA-Adapter auf bestehendem Modell (1-2% zusätzlicher VRAM).
  • Metriken: Attack Success Rate (ASR) nach Training (kontinuierliche Reduktion).
  • Tools: trl (Transformers Reinforcement Learning), adversarial-robustness-toolbox.

Container-Härtung

Sichert den KI-Deploy-Container gegen Privilege Escalation und Side-Channel-Angriffe. Entspricht CIS Docker Benchmarks.

Best-Practice-Umsetzung:

  • Non-root User (USER 1000:1000 im Dockerfile).
  • AppArmor/SELinux-Profil für KI-Prozess.
  • Read-only Root-Filesystem (--read-only bei docker run).
  • Seccomp-Filter: Nur read/write/socket erlauben.
  • Image-Scan: Trivy vor Deploy.

Prüfkriterien und Prüfungsmodalitäten für KI-Härtung

Übergeordnetes Kriterium: Sicherheits-Test durch externe Experten mit weniger als 5% Angriffserfolg über alle Maßnahmen.

Input-Sanitization – Prüfkriterium und Umsetzung

Kriterium: 95% der bekannten gefährlichen Eingaben werden erkannt und blockiert.

Prüfungsmodalitäten: 

1. Test-Suite: 500+ Angriffsvektoren (DAN-Jailbreaks, Base64-Payloads, Unicode-Exploits)
2. Tool: llm-attacks oder garak (automatisierte Tests)
3. Erfolg: Blockquote ≥95%, False-Positive-Rate <1%
4. Dokumentation: Test-Report mit Pass/Fail pro Vektor

Umsetzung: Wöchentlicher Test mit bekannten Angriffsmustern → Bericht per E-Mail.

Rate Limiting – Prüfkriterium und Umsetzung

Kriterium: Kein Benutzer kann mehr als 100 Anfragen pro Stunde stellen.

Prüfungsmodalitäten: 

1. Load-Test: Apache Bench (ab -n 200 -c 10)
2. Überprüfung: Redis-Keys `ratelimit:ip:X` TTL ≤3600s
3. Response: HTTP 429 mit Retry-After Header bei Überschreitung
4. Metriken: Prometheus `ratelimit_hits_total > 0`

Umsetzung: Monatliche Lasttests mit Tools wie Apache Bench.

Output-Moderation – Prüfkriterium und Umsetzung

Kriterium: 98% der gefährlichen Antworten werden erkannt.

Prüfungsmodalitäten: 

1. Dataset: HuggingFace "unitary/toxic-bert" Testset (10.000 Samples)
2. Threshold: F1-Score soll stabil bleiben oder sich verbessern bei Hate/Violence/Self-Harm
3. Audit: 100% manuelle Stichprobe kritischer Outputs
4. Log: Moderation-Ergebnisse 90 Tage auffindbar

Umsetzung: Vierteljährliche Tests mit öffentlichen Test-Datensätzen.

Adversarial Training – Prüfkriterium und Umsetzung

Kriterium: Angriffe gelingen in weniger als 5% der Fälle nach Training.

Prüfungsmodalitäten: 

1. Benchmark: OWASP LLM Top 10 + Anthropic Red-Team (1.000 Angriffe)
2. Metrik: ASR = erfolgreiche Angriffe / Gesamtangriffe
3. Baseline-Vergleich: Vorher/Nachher ASR-Differenz ≥80%
4. Periodisch: Quartalsweise Re-Test nach Modell-Updates

Umsetzung: Automatisierte Tests nach jedem Modell-Update.

Container-Härtung – Prüfkriterium und Umsetzung

Kriterium: Container erfüllt 30+ Sicherheitsregeln (Docker-Standard).

Prüfungsmodalitäten: 

1. Scan: Trivy `trivy image ki-app:latest` → 0 Criticals
2. Runtime: `docker-bench-security` → ≥95% Compliance
3. Prozess: `ps aux | grep ki-app` → non-root User
4. Netzwerk: `docker inspect` → No privileged ports (<1024)

Umsetzung: Wöchentliche automatische Scans aller Container.

Übergeordnete Sicherheitsprüfung

Empfehlenswert ist ein regelmäßiger Prüf- und Auditzyklus z.B.: interne monatliche oder quartalsmäßige Prüfung und jährliche externe Prüfung

Alle jährlichen Auditergebnisse 10 Jahre aufbewahren (gesetzliche Pflicht EU AI Act).

Modellsicherheit (Integritätsschutz)

Modellsicherheit schützt das trainierte KI-Modell vor Diebstahl, Manipulation und unbefugter Nutzung während des gesamten Lebenszyklus.

Model Cards

Model Cards sind standardisierte Dokumente, die Architektur, Trainingsdaten, Leistung und Risiken des Modells beschreiben. Sie ermöglichen Transparenz und sind für Audits erforderlich (EU AI Act Art. 13).

Best-Practice-Umsetzung:

  • Vorlage nach HuggingFace-Standard verwenden
  • Inhalte: Modelltyp, Parameteranzahl, Trainingsdatenmenge, Bias-Metriken
  • Automatische Generierung mit Tools wie model-card-toolkit
  • Im Versionskontrollsystem (Git) als Markdown-Datei speichern

Integritätsprüfung

Überprüft vor jeder Nutzung, ob das Modell manipuliert wurde. Verhindert Einsatz beschädigter oder vergifteter Modelle.

Best-Practice-Umsetzung:

  • SHA-256-Hash des Originalmodells berechnen und signieren
  • Vor Inference: Hash vergleichen → bei Abweichung Notfall-Stopp
  • Digitale Signatur mit GPG oder Hardware Security Module (HSM)
  • Automatisierte Prüfung als Docker-Entry-Point-Script

Output-Watermarking

Fügt unsichtbare Markierungen in KI-Ausgaben ein, um deren Herkunft nachzuweisen. Schützt vor Missbrauch und Plagiat.

Optional - sinnvoll für bestimmte Szenarien.

Best-Practice-Umsetzung:

  • Token-basierte Watermarks (OpenAI-Methode): Spezielle Token-Wahrscheinlichkeiten
  • Text-Watermarking: Synonyme-Ersetzung nach festem Muster
  • Bild-Watermarking: LSB-Steganographie (Least Significant Bit)
  • Detektions-Tool parallel bereitstellen

Differential Privacy

Verhindert, dass einzelne Trainingsdaten aus Modell-Ausgaben rekonstruiert werden können. Schützt personenbezogene Daten (DSGVO).

Best-Practice-Umsetzung:

  • Training mit DP-SGD (Differential Privacy Stochastic Gradient Descent)
  • Privacy Budget ε=1.0 (empfohlener Richtwert)
  • Bibliothek: Opacus (PyTorch) oder TensorFlow Privacy
  • Privacy-Audit: Membership Inference Attack Tests

SBOM (Software Bill of Materials)

Vollständige Liste aller Komponenten des KI-Systems für Supply-Chain-Sicherheit. Ermöglicht Schwachstellen-Management.

Best-Practice-Umsetzung:

  • CycloneDX-Format für Python/ML-Umgebungen
  • Automatische Generierung: cyclonedx-py oder GitHub Dependency Graph
  • Dependency-Scan: Snyk/Trivy vor Deploy
  • Versionspflicht: Jede Komponente mit exakter Versionsnummer

Prüfkriterien und Prüfungsmodalitäten für Modellsicherheit

Übergeordnetes Kriterium: 100% der Modelle sind vollständig dokumentiert und integritätsgesichert.

Model Cards – Prüfkriterium und Umsetzung

Kriterium: Jede Modellversion hat vollständige Model Card (10+ Kategorien).

Prüfungsmodalitäten: 

1. Vollständigkeits-Check: Checkliste mit Pflichtfeldern
2. Aktualität: Model Card ≤ 3 Monate alt
3. Qualität: Techniker können Modell aus Card reproduzieren
4. Audit: Jährliche Stichprobe 20% aller Model Cards

Umsetzung: Git-Hook blockiert Commits ohne Model Card.

Integritätsprüfung – Prüfkriterium und Umsetzung

Kriterium: 100% Integritätsprüfung vor jeder Modellnutzung.

Prüfungsmodalitäten: 

1. Log-Analyse: Alle Inference-Starts mit Hash-Check
2. Fehlerrate: nahe 0 (Integritätsfehler werden innerhalb von 24 Stunden erkannt und behoben.)
3. Recovery-Test: Manipuliertes Modell wird erkannt
4. Signatur-Validierung: GPG-Key korrekt

Umsetzung: Monatliche Log-Auswertung und Alarm bei Fehlern.

Output-Watermarking – Prüfkriterium und Umsetzung

Kriterium: 95% Detektionsrate bei Watermark-Prüfung (optional).

Prüfungsmodalitäten: 

1. Test-Suite: 1.000 Ausgaben mit/ohne Watermark
2. False-Positive-Rate: <1%
3. Robustheit: Watermark übersteht Copy-Paste/OCR
4. Dokumentation: Detektions-Tool verfügbar

Umsetzung: Wöchentliche Batch-Tests mit Testausgaben.

Differential Privacy – Prüfkriterium und Umsetzung

Kriterium: Privacy Budget ε ≤ 1.0 nach Training.

Prüfungsmodalitäten: 

1. Privacy-Audit: Membership Inference Attack <5% Erfolg
2. ε-Berechnung: Auditor bestätigt korrekte Berechnung
3. Dokumentation: Training-Logs mit Privacy-Metriken
4. Zertifikat: Privacy-Bericht verfügbar

Umsetzung: Audit nach jedem Training.

SBOM – Prüfkriterium und Umsetzung

Kriterium: Vollständiger, aktueller SBOM für jedes KI-System.

Prüfungsmodalitäten: 

1. Vollständigkeit: 100% aller Dependencies erfasst
2. Aktualität: SBOM ≤ 30 Tage alt
3. Schwachstellen: Keine Critical Vulnerabilities
4. Validierung: CycloneDX-Schema-Check

Umsetzung: CI/CD-Pipeline generiert SBOM automatisch.

Nachvollziehbarkeit (Traceability)

Nachvollziehbarkeit ermöglicht die Rekonstruktion jeder KI-Entscheidung für Audits und Vorfälle (EU AI Act Art. 12-13, 10-Jahre-Pflicht).

Vollständiges Inference-Logging

Protokolliert alle KI-Anfragen und Antworten vollständig. Ermöglicht Nachverfolgung von Fehlentscheidungen oder Missbrauch.

Best-Practice-Umsetzung:

  • Log-Einträge: User-ID, Timestamp, Input, Output, Modell-Version, Rechenzeit
  • JSON-Format mit strukturierten Feldern
  • Speicherung in Elasticsearch oder PostgreSQL (append-only)
  • Enpfehlung: min. 1 Jahr aufbewahren (zur Verfügbarkeit für Audits)

End-to-End-Audit-Trails

Verknüpft alle Schritte einer KI-Entscheidung von der Eingabe bis zur finalen Ausgabe. Notwendig für Haftungsfragen.

Best-Practice-Umsetzung:

  • MLflow oder Weights&Biases für Experiment-Tracking
  • Jeder Inference-Request erhält eindeutige Request-ID
  • Rationale Logging (Begründungsfragmente ohne vollständige Chain‑of‑Thought)
  • API: /audit/{request_id} für Nachverfolgung

Explainability für kritische Entscheidungen

Zeigt auf, warum das Modell eine bestimmte Entscheidung getroffen hat. Erforderlich bei Hochrisiko-Anwendungen.

Best-Practice-Umsetzung:

  • SHAP/LIME für Feature Importance (wichtigste Einflussfaktoren)
  • Bei Bild-KI: Grad-CAM Heatmaps
  • Erklärung als Text + Grafik im Log speichern
  • Nur für kritische Entscheidungen (Schwellenwert-basiert)

Versionskontrolle Modelle/Daten

Jede Entscheidung ist exakt einer Modell-/Daten-Version zuzuordnen. Verhindert "Wer hat welches Modell verwendet?"-Probleme.

Best-Practice-Umsetzung:

  • DVC (Data Version Control) für Datasets und Modelle
  • Git-Tags für Modell-Releases (v1.2.3)
  • Jeder Log-Eintrag enthält model_hash und data_version
  • Container-Images mit Digest (SHA-256)

SIEM-Integration und Anomalie-Erkennung

Erkennt ungewöhnliches KI-Verhalten automatisch und leitet Alarme ein. Erfüllt ISO 27001 Überwachungspflichten.

Best-Practice-Umsetzung:

  • Logs in Splunk/ELK-Stack einspielen
  • Anomalie-Detektoren: Zu viele Token, ungewöhnliche Anfragen, Spitzenzeiten
  • Alerting: Slack/PagerDuty bei >10x normalem Verbrauch
  • Dashboard mit KI-spezifischen Metriken

Prüfkriterien und Prüfungsmodalitäten für Nachvollziehbarkeit

Übergeordnetes Kriterium: Jede KI-Entscheidung vollständig nachvollziehbar innerhalb 24 Stunden.

Inference-Logging – Prüfkriterium und Umsetzung

Kriterium: vollständig protokolliert (keine Lücken, Abweichungen dokumentiert und begründet).

Prüfungsmodalitäten: 

1. Log-Vollständigkeit: Request-Count vs. Log-Count = 100%
2. Format-Check: JSON-Schema-Validierung
3. Retention-Test: Daten aus Vorjahr abrufbar
4. Performance: Logging <50ms Overhead pro Request

Umsetzung: Täglicher Log-Completeness-Check per Cron-Job.

Audit-Trails – Prüfkriterium und Umsetzung

Kriterium: Request-ID Nachverfolgung von Input zu Output in <5 Sekunden.

Prüfungsmodalitäten: 

1. End-to-End-Test: 100 zufällige Request-IDs prüfen
2. Rationale Logging Zwischenschritte vollständig
3. Suchzeit: Elasticsearch Query <2s für 1 Jahr Daten
4. API-Test: /audit/{id} liefert vollständige Spur

Umsetzung: Monatliche Stichproben mit Zufalls-Request-IDs.

Explainability – Prüfkriterium und Umsetzung

Kriterium: 95% der kritischen Entscheidungen mit Erklärung versehen.

Prüfungsmodalitäten: 

1. Abdeckung: Kritische Entscheidungen = Erklärungen
2. Qualität: Erklärung verständlich für Nicht-Experten
3. Performance: SHAP-Berechnung <2s pro Anfrage
4. Speicherung: Erklärungen 10 Jahre haltbar

Umsetzung: Wöchentliche Prüfung kritischer Logs.

Versionskontrolle – Prüfkriterium und Umsetzung

Kriterium: 100% der Logs enthalten korrekte Modell-/Daten-Version.

Prüfungsmodalitäten: 

1. Hash-Validierung: model_hash existiert in Registry
2. Reproduzierbarkeit: Gleiches Modell = gleiche Ausgabe
3. Versions-Historie: 12 Monate rückverfolgbar
4. Daten-Integrität: DVC-Status clean

Umsetzung: Tägliche Validierung neuer Logs.

SIEM-Integration – Prüfkriterium und Umsetzung

Kriterium: Anomalien innerhalb 15 Minuten erkannt und eskaliert.

Prüfungsmodalitäten: 

1. Alert-Test: Simulierte Anomalie → Alarm in <15min
2. False-Positive-Rate: <5 pro Woche
3. Dashboard: Alle KI-Metriken real-time sichtbar
4. Incident-Response: 95% Alarme innerhalb SLA bearbeitet

Umsetzung: Wöchentliche Anomalie-Simulationstests.

Verantwortlichkeiten

Die Maßnahmen erfordern eine klare Rollenverteilung über IT-Sicherheit, Entwicklung und Nutzung hinaus.

Auch Mitarbeitende tragen Mitverantwortung durch korrekte Bedienung und Meldung von Anomalien.

Rolle Aufgaben KPIs
CISO ISMS-Integration, Audit-Planung 100% Konformität
Data Scientists Model Cards, Training-Sicherheit 100% Modelle dokumentiert
IT-Admin Logging, Container-Härtung 99,9% Logging-Verfügbarkeit
Datenschutzbeauftragte DSGVO-Privacy (ε=1.0) Privacy-Audits bestanden
Mitarbeitende Nur erlaubte Nutzung, richtige Bedienung, Anomalien melden 95% korrekte Nutzung, 100% Incident-Meldung

Nächste Schritte: Integration in ISMS-Prozesse, erste Red-Team-Tests.

Umsetzung

Die Umsetzung erfolgt in vier Phasen mit klarer Priorisierung. Jede Phase baut auf der vorherigen auf und kann parallel mit begrenzten Ressourcen begonnen werden.

Phase 1: Sofortmaßnahmen (Grundschutz)

Diese Maßnahmen schützen innerhalb von Tagen vor den häufigsten Angriffen:

  1. Input/Output-Filter aktivieren (llm-guard, Moderation API)
  2. Logging-Infrastruktur aufsetzen (ELK/PostgreSQL, JSON-Format)
  3. Rate Limiting implementieren (Redis, 100 Requests/Stunde)
  4. Wartungsmodus für Tests definieren

Phase 2: Dokumentationspflicht

Erstellt die Audit-Grundlage für EU AI Act Konformität:

  1. Model Cards für alle produktiven Modelle erstellen
  2. SBOMs für KI-Systeme generieren (cyclonedx-py)
  3. Versionskontrolle einrichten (DVC/Git für Modelle/Daten)
  4. Integritätsprüfungen automatisieren (SHA-256 vor Inference)

Phase 3: Erweiterte Härte-Maßnahmen

Erhöht die Robustheit gegen komplexe Angriffe:

  1. Adversarial Training für kritische Modelle (LoRA, OWASP Dataset)
  2. Container-Härtung (non-root, AppArmor, Trivy Scans)
  3. Differential Privacy bei neuen Trainings (Differential Privacy mit Richtwert ε=1.0)
  4. Watermarking für Text/Bild-Outputs implementieren

Phase 4: Laufende Prüfung und Optimierung

Stellt dauerhafte Konformität sicher:

  1. Automatisierte Tests einrichten (garak, docker-bench-security)
  2. SIEM-Integration mit Anomalie-Erkennung (ELK + Alerts)
  3. Erste interne Prüfung aller Maßnahmen durchführen
  4. Externe Red-Team-Prüfung beauftragen (jährlich)

Monitoring:

  • Wöchentliche Automatiktests mit Berichten
  • Monatliche Stichproben der Logs
  • Jährliche externe Validierung
  • Alle jährlichen Vaidierungen 10 Jahre archivieren (EU AI Act)

Fazit

Die beschriebenen Maßnahmen zu KI-Härtung, Modellsicherheit und Nachvollziehbarkeit bilden die technische Grundlage für konforme KI-Nutzung in Behörden oder Unternehmen. Sie erfüllen die zwingenden Anforderungen des EU AI Act (Art. 12-15) und des BSI Grundschutz, minimieren Haftungsrisiken und gewährleisten Auditfähigkeit.

Sofortige Umsetzung priorisieren:

  1. Logging-Infrastruktur – schnellste Wirkung, geringer Aufwand
  2. Input/Output-Filter – sofortiger Angriffsschutz
  3. Model Cards für bestehende Modelle – Audit-Vorbereitung

Langfristig: Jährliche Red-Team-Tests und kontinuierliche Weiterentwicklung der Maßnahmen entsprechend neuer Bedrohungen (OWASP LLM Top 10 Updates).

Die Integration in bestehende ISMS-Prozesse schafft Wettbewerbsvorteile durch vertrauenswürdige KI und erfüllt regulatorische Pflichten gleichzeitig. Beginne mit dem Umsetzungsplan – die rechtlichen Fristen laufen.

Glossar – KI‑Sicherheit

Dieses Glossar erläutert zentrale Fachbegriffe aus dem Bereich der KI‑Sicherheit, die im Leitfaden verwendet werden und für ein einheitliches Verständnis wichtig sind.

Begriff Erklärung
Adversarial Attack / Adversarial Examples Manipulierte Eingaben, die ein KI‑Modell zu falschen Ausgaben verleiten sollen.
Adversarial Success Rate (ASR) Anteil erfolgreicher adversarialer Angriffe auf ein Modell.
API‑Gateway Zentrale Schnittstelle zur Kontrolle, Authentifizierung und Überwachung von KI‑Anfragen.
Audit‑Trail Lückenlose Protokollkette aller relevanten Aktionen, Modellversionen und Änderungen.
Chain‑of‑Thought (CoT) Interne Zwischenschritte eines Modells; oft sensibel und nicht deterministisch.
Container‑Härtung Sicherheitsmaßnahmen zur Absicherung von Containern (z. B. Docker).
Data Poisoning Manipulation von Trainingsdaten, um ein Modell zu sabotieren oder zu beeinflussen.
Differential Privacy (DP) Technik, die verhindert, dass einzelne Trainingsdaten aus dem Modell rekonstruiert werden können.
DP‑SGD Trainingsverfahren, das Differential Privacy direkt in den Lernprozess integriert.
DVC (Data Version Control) Tool zur Versionierung von Trainingsdaten, Modellen und ML‑Experimenten.
Explainability / Erklärbarkeit Methoden zur Nachvollziehbarkeit von Modellentscheidungen (z. B. SHAP, LIME).
F1‑Score Kennzahl zur Bewertung der Klassifikationsqualität (Harmonic Mean aus Precision & Recall).
Halluzination (KI) Falsche oder erfundene Aussagen eines Modells ohne reale Grundlage.
Inference Ausführung eines Modells zur Beantwortung einer Anfrage (Prompt → Antwort).
Inference‑Logging Protokollierung aller Modellaufrufe, Eingaben, Ausgaben und Metadaten.
LSB‑Steganographie Verstecken von Informationen in den unauffälligen Bits von Dateien oder Bildern.
Model Card Dokumentation eines Modells mit Angaben zu Training, Risiken, Einsatzgrenzen und Performance.
Model Drift Leistungsabfall eines Modells über die Zeit durch veränderte Daten oder Umgebungen.
Model Integrity Check Prüfung, ob ein Modell unverändert, vollständig und authentisch ist (z. B. Hash‑Vergleich).
Prompt Injection Angriff, bei dem manipulierte Eingaben das Modell zu unerwünschten Aktionen bringen sollen.
Rate Limiting Begrenzung der Anzahl von Anfragen pro Nutzer oder Zeitfenster zur Missbrauchsvermeidung.
Red‑Teaming (KI) Gezielte Tests durch Teams, die Schwachstellen der KI aktiv ausnutzen sollen.
SBOM (Software Bill of Materials) Liste aller Software‑Komponenten und Abhängigkeiten eines Systems.
Shadow‑KI Nicht genehmigte oder nicht dokumentierte Nutzung von KI‑Tools durch Mitarbeitende.
SHAP / LIME Explainability‑Methoden zur Analyse der Bedeutung einzelner Merkmale.
Supply‑Chain‑Risiken (KI) Risiken durch externe Modelle, Trainingsdaten, Bibliotheken oder Cloud‑Dienste.
Watermarking (KI‑Output) Unsichtbare Markierung KI‑generierter Inhalte; noch nicht standardisiert.

Weiterführende Quellen

Abgerufen von „https://wiki.isms-ratgeber.info/index.php?title=LF-KI-Sicherheit&oldid=2025“