KI Security Framework: 4 Stufen zur sicheren AI

Sie haben KI-Tools im Einsatz – offiziell oder inoffiziell. Sie wissen, dass Risiken existieren. Aber wo anfangen? Welche Maßnahmen zuerst? Und wie stellen Sie sicher, dass nichts übersehen wird?

Dieses Framework gibt Ihnen einen klaren Fahrplan: Discover → Assess → Protect → Monitor. Vier Stufen, die aufeinander aufbauen und sich kontinuierlich wiederholen. Kein theoretisches Konzept, sondern ein praktischer Implementierungsplan – entwickelt aus den Prinzipien von NIST AI RMF und OWASP, angepasst an die Realität deutscher Unternehmen.

Warum ein strukturierter Ansatz entscheidend ist

Die meisten Unternehmen reagieren auf KI-Risiken ad-hoc: Ein neues Tool taucht auf, jemand fragt nach der Sicherheit, es wird schnell eine Lösung gebastelt. Das funktioniert bei zwei oder drei Tools. Aber bei zehn, zwanzig oder fünfzig KI-Anwendungen – offiziellen und inoffiziellen – verlieren Sie den Überblick.

Was ohne Framework passiert:

• Jedes neue Tool wird isoliert bewertet – ohne Blick auf das Gesamtbild
• Kritische Lücken bleiben unsichtbar, weil niemand systematisch sucht
• Security-Team und Fachbereiche arbeiten aneinander vorbei
• Sie können dem Vorstand nicht sagen, wie sicher Ihre KI-Landschaft wirklich ist

Was ein Framework ermöglicht:

• Sie wissen jederzeit, welche KI-Systeme existieren und wo die Risiken liegen
• Neue Tools werden nach einheitlichen Kriterien bewertet
• Verantwortlichkeiten sind klar – wer kümmert sich um was?
• Sie können Fortschritt messen und dem Management berichten

Die 4 Stufen im Überblick

Stufe 1: Discover (2-4 Wochen)

Ziel: Wissen, was Sie haben – bevor Sie es schützen können.

Sie können nicht schützen, was Sie nicht kennen. Die Discovery-Phase schafft Transparenz: Welche KI-Systeme existieren in Ihrem Unternehmen? Wer nutzt sie? Welche Daten fließen hindurch? Die Erfahrung zeigt: Die meisten Unternehmen unterschätzen die Anzahl ihrer KI-Anwendungen um Faktor 3-5.

1.1 AI-Inventar erstellen

Das AI-Inventar ist Ihre Single Source of Truth für alle KI-Anwendungen. Wichtig dabei: Es geht nicht nur um die offiziell genehmigten Tools. Gerade die inoffiziellen Anwendungen – von Mitarbeitern eigenständig genutzt – bergen oft die größten Risiken.

Diese fünf Kategorien sollten Sie erfassen:

Template für jedes AI-System:

AI-System: _______________
Typ: [ ] SaaS [ ] Self-hosted [ ] API [ ] Embedded
Verantwortlich: _______________
Daten-Input: [ ] Public [ ] Internal [ ] Confidential [ ] PII
Use Case: _______________
Nutzer: ___ Personen / Teams
Letzte Review: _______________

1.2 Data Flows dokumentieren

Das Inventar zeigt Ihnen WAS existiert. Die Data-Flow-Analyse zeigt, WELCHE DATEN wo hinfließen. Das ist entscheidend für DSGVO-Compliance und Risikobewertung: Personenbezogene Daten, die zu einem US-Anbieter fließen, sind ein völlig anderes Risiko als interne Dokumente in einem selbst gehosteten System.

Für jedes AI-System klären:

• Input: Welche Daten geben Nutzer ein? Könnten versehentlich vertrauliche Informationen dabei sein?
• Speicherung: Werden Prompts und Responses geloggt? Für Training verwendet? Wie lange aufbewahrt?
• Output: Welche Daten kommen zurück? Könnten Informationen aus dem Training durchsickern?
• Drittparteien: Werden Daten an weitere Anbieter weitergegeben (z.B. für Moderation)?

1.3 Non-Human Identities (NHIs) erfassen

Neben menschlichen Nutzern greifen auch Maschinen auf Ihre KI-Systeme zu: API-Keys, Service Accounts, OAuth Tokens. Diese "Non-Human Identities" (NHIs) sind oft das schwächste Glied – sie werden einmal erstellt und dann vergessen, rotieren nie, und haben häufig viel zu weitreichende Berechtigungen.

Warum das kritisch ist: Studien zeigen durchschnittlich 144 NHIs pro Mitarbeiter. Bei KI-Systemen oft noch mehr, weil jede Integration, jede Pipeline, jeder automatisierte Workflow eigene Credentials braucht. Ein kompromittierter API-Key kann mehr Schaden anrichten als ein gehacktes Mitarbeiter-Konto.

Diese Credentials sollten Sie inventarisieren:

• API-Keys für LLM-Provider (OpenAI, Anthropic, Azure OpenAI)
• Service Accounts für AI-Pipelines und Automatisierungen
• OAuth Tokens für Integrationen mit anderen Tools
• Machine-to-Machine Credentials für interne Systeme

Pro Credential erfassen:

Credential: _______________
Typ: [ ] API Key [ ] Service Account [ ] Token
Zugriff auf: _______________
Berechtigungen: _______________
Rotiert: [ ] Nie [ ] Jährlich [ ] Quartalsweise [ ] Monatlich
Ablaufdatum: _______________
Owner: _______________

Die wichtigste Frage: Wer ist verantwortlich? Credentials ohne klaren Owner werden nie rotiert und nie deaktiviert.

1.4 Shadow AI aufdecken

Shadow AI – KI-Tools, die Mitarbeiter ohne IT-Freigabe nutzen – ist kein Randproblem. Studien zeigen: 59% der Mitarbeiter nutzen KI ohne Genehmigung. Die Gründe sind nachvollziehbar: Die offiziellen Prozesse sind zu langsam, die genehmigten Tools zu eingeschränkt. Aber die Risiken sind real: Keine Verträge, keine Datenschutzgarantien, keine Kontrolle.

So finden Sie Shadow AI:

Der Ton macht die Musik: Discovery sollte kein Tribunal sein. Wenn Mitarbeiter Angst vor Konsequenzen haben, werden sie nicht ehrlich antworten. Kommunizieren Sie klar: Es geht um Sichtbarkeit und bessere Alternativen, nicht um Bestrafung.

Ergebnis Stufe 1: Nach 2-4 Wochen haben Sie ein vollständiges Bild: Welche KI-Systeme existieren (offiziell und inoffiziell), welche Daten fließen wohin, welche Credentials sind im Umlauf. Sie wissen jetzt, was Sie schützen müssen.

Stufe 2: Assess (2-3 Wochen)

Ziel: Risiken verstehen und priorisieren.

Sie haben jetzt ein Inventar. Aber nicht alle KI-Systeme sind gleich riskant. Der Marketing-Chatbot, der nur öffentliche Informationen verarbeitet, ist ein anderes Risiko als das HR-Tool, das Bewerberdaten analysiert. In der Assess-Phase bewerten Sie systematisch: Wo liegen die größten Risiken? Was muss zuerst angegangen werden?

2.1 Risk Matrix erstellen

Eine Risk Matrix hilft, Risiken vergleichbar zu machen. Zwei Dimensionen sind entscheidend: Wie schlimm wäre es, wenn etwas passiert (Impact)? Und wie wahrscheinlich ist es, dass etwas passiert (Likelihood)?

Impact – Was steht auf dem Spiel?

• Critical: Geschäftsunterbrechung, regulatorische Strafen (DSGVO: bis 4% Jahresumsatz), massiver Reputationsschaden
• High: Signifikanter Datenverlust, hohe Kosten für Incident Response und Recovery
• Medium: Eingeschränkte Funktionalität, behebbare Probleme, überschaubare Kosten
• Low: Minimale Auswirkung, kaum merkbar für das Geschäft

Likelihood – Wie wahrscheinlich ist ein Vorfall?

• High: System ist öffentlich zugänglich, keine oder schwache Schutzmaßnahmen
• Medium: Interner Zugriff, einige Controls vorhanden, aber Lücken erkennbar
• Low: Stark eingeschränkter Zugriff, mehrere Schutzebenen, regelmäßig getestet

So nutzen Sie die Matrix:

Ordnen Sie jedes KI-System aus Ihrem Inventar in diese Matrix ein. Systeme in der oberen rechten Ecke (High Likelihood + High/Critical Impact) brauchen sofortige Aufmerksamkeit.

2.2 AI-spezifische Risikobewertung

Die allgemeine Risk Matrix reicht für KI-Systeme nicht aus. LLMs haben spezifische Schwachstellen, die Sie gezielt bewerten sollten. Die OWASP Foundation hat die kritischsten Risiken für LLM-Anwendungen identifiziert – nutzen Sie diese als Checkliste:

Die wichtigsten LLM-Risiken erklärt:

Bewertungs-Template pro System:

System: _______________

Risikobewertung (0=nicht relevant, 5=kritisch):
[ ] Prompt Injection: Kann das System durch Nutzer-Input manipuliert werden? ___
[ ] Output-Sicherheit: Werden Ausgaben vor Weiterverarbeitung validiert?     ___
[ ] Datenschutz: Könnten vertrauliche Infos nach außen gelangen?             ___
[ ] Berechtigungen: Welche Aktionen kann das System eigenständig ausführen?  ___

Datenklassifikation des Inputs:
[ ] Öffentlich [ ] Intern [ ] Vertraulich [ ] Personenbezogen

Compliance-Relevanz:
[ ] DSGVO (personenbezogene Daten)
[ ] EU AI Act (Hochrisiko-Anwendung?)
[ ] Branchenspezifisch (z.B. Finanzaufsicht, Gesundheitswesen)

Gesamtrisiko: ___ / 20
Priorität: [ ] Sofort [ ] Dieses Quartal [ ] Dieses Jahr [ ] Beobachten

2.3 Gap Analysis

Sie wissen jetzt, welche Risiken existieren. Die Gap Analysis zeigt, wo Ihre aktuellen Maßnahmen nicht ausreichen. Vergleichen Sie Ihren Ist-Stand mit anerkannten Standards – das gibt Ihnen einen objektiven Maßstab und hilft bei der Priorisierung.

Welcher Standard für welchen Zweck?

So führen Sie die Gap Analysis durch:

Nehmen Sie die wichtigsten Anforderungen des relevanten Standards und prüfen Sie für jede: Erfüllen wir das? Teilweise? Gar nicht?

Anforderung: _______________
Standard: [ ] OWASP [ ] NIST [ ] EU AI Act [ ] ISO
Aktueller Status: [ ] Nicht erfüllt [ ] Teilweise [ ] Erfüllt
Was fehlt konkret: _______________
Aufwand zur Schließung: [ ] Gering [ ] Mittel [ ] Hoch
Deadline (bei Compliance-Pflicht): _______________

Tipp: Starten Sie mit dem EU AI Act – der wird für die meisten Unternehmen verbindlich. OWASP ergänzt die technische Perspektive.

2.4 Priorisierung

Sie haben jetzt eine Liste von Risiken und Gaps. Aber Sie können nicht alles gleichzeitig angehen. Die Kunst liegt in der richtigen Priorisierung: Maximale Risikoreduktion mit verfügbaren Ressourcen.

Das Priorisierungs-Framework:

Der größte Fehler: Zu lange in der Assess-Phase verharren. Eine 80%-Analyse mit schnellen ersten Maßnahmen ist wertvoller als eine 100%-Analyse ohne Umsetzung.

Ergebnis Stufe 2: Nach 2-3 Wochen haben Sie eine Risk Matrix für alle KI-Systeme, eine priorisierte Roadmap und eine Liste von Quick Wins für den sofortigen Start. Sie wissen jetzt nicht nur WAS die Risiken sind, sondern auch WAS ZUERST angegangen werden muss.

Stufe 3: Protect (0-6 Monate)

Ziel: Risiken reduzieren durch konkrete Maßnahmen.

Jetzt wird umgesetzt. Sie wissen, was Sie haben (Discover) und wo die Risiken liegen (Assess). Die Protect-Phase bringt konkrete Schutzmaßnahmen – gestaffelt nach Aufwand und Wirkung.

3.1 Quick Wins (Woche 1-4)

Beginnen Sie mit Maßnahmen, die wenig Aufwand erfordern, aber sofort wirken. Diese Quick Wins reduzieren Risiken, während Sie an größeren Projekten arbeiten.

Woche 1-2: Grundlegende Absicherung

Woche 3-4: Zugriffskontrollen

Monat 2-3: Governance und Awareness

3.2 Technical Controls (Monat 2-6)

Die Quick Wins sind umgesetzt. Jetzt geht es an die tiefergehenden technischen Maßnahmen. Diese erfordern mehr Entwicklungsaufwand, bieten aber auch robusteren Schutz.

Input Security: Mehrschichtige Validierung

Vertrauen Sie keinem Nutzer-Input. Jede Eingabe sollte mehrere Prüfungsebenen durchlaufen, bevor sie ans LLM geht:

1. Größenbegrenzung: Überlange Eingaben können auf Injection-Versuche hindeuten
2. Pattern-Erkennung: Bekannte Injection-Muster blockieren
3. Risiko-Klassifikation: Verdächtige Inhalte kennzeichnen
4. PII-Erkennung: Personenbezogene Daten maskieren oder warnen

def validate_ai_input(user_input: str) -> ValidationResult:
    # Layer 1: Size limits - überlange Inputs sind verdächtig
    if len(user_input) > MAX_INPUT_LENGTH:
        return ValidationResult(valid=False, reason="Input too long")

    # Layer 2: Pattern detection - bekannte Injection-Muster
    if contains_injection_patterns(user_input):
        return ValidationResult(valid=False, reason="Suspicious pattern")

    # Layer 3: Content classification - Risikobewertung des Inhalts
    risk_level = classify_content_risk(user_input)
    if risk_level > RISK_THRESHOLD:
        return ValidationResult(valid=False, reason="High-risk content")

    # Layer 4: PII detection - personenbezogene Daten erkennen
    if contains_pii(user_input):
        return ValidationResult(
            valid=True,
            warning="PII detected",
            sanitized=redact_pii(user_input)
        )

    return ValidationResult(valid=True, sanitized=user_input)

Output Security: Was rausgeht, muss geprüft werden

Auch die Antworten des LLMs brauchen Kontrolle. Das System könnte versehentlich vertrauliche Informationen preisgeben oder schädliche Inhalte generieren:

def filter_ai_output(llm_response: str) -> FilteredOutput:
    # Layer 1: PII Redaction - keine personenbezogenen Daten nach außen
    filtered = redact_pii(llm_response)

    # Layer 2: System Prompt Leakage - interne Anweisungen schützen
    if detects_system_prompt_leakage(filtered):
        return FilteredOutput(
            content="Diese Information kann ich nicht bereitstellen.",
            alert=True  # Security-Team benachrichtigen
        )

    # Layer 3: Harmful Content - schädliche Inhalte blockieren
    if is_harmful_content(filtered):
        return FilteredOutput(
            content="Antwort wegen Policy-Verstoß gefiltert.",
            alert=True
        )

    return FilteredOutput(content=filtered, alert=False)

Access Control: Wer darf was?

Nicht jeder braucht Vollzugriff. Ein Rollenmodell stellt sicher, dass Nutzer nur die Berechtigungen haben, die sie für ihre Arbeit brauchen:

3.3 Advanced Security (ab Monat 6)

Für Unternehmen mit mehreren KI-Anwendungen lohnt sich eine zentrale Steuerungsebene: ein AI Gateway. Statt jede Anwendung einzeln abzusichern, laufen alle Anfragen durch einen zentralen Punkt.

AI Gateway: Alle Anfragen unter Kontrolle

Warum ein Gateway?

• Ein Kontrollpunkt: Policies, Logging und Filtering zentral konfigurieren
• Provider-unabhängig: Heute OpenAI, morgen Anthropic – die Security-Schicht bleibt
• Einheitliches Logging: Alle Anfragen an einem Ort, ideal für Compliance und Forensik
• Kostencontrolle: Budget-Limits und Abuse-Erkennung zentral steuern

Human-in-the-Loop: Kritische Aktionen absichern

Wenn KI-Systeme eigenständig handeln können (Agenten), brauchen Sie zusätzliche Sicherheit. Bestimmte Aktionen sollten nicht ohne menschliche Freigabe möglich sein:

# Diese Aktionen erfordern menschliche Bestätigung
HIGH_RISK_ACTIONS = ['delete', 'transfer', 'modify_access', 'external_call']

async def execute_ai_action(action: str, params: dict, user: User) -> Result:
    if action in HIGH_RISK_ACTIONS:
        # Warte auf manuelle Freigabe (z.B. via Slack, E-Mail, oder Dashboard)
        approval = await request_human_approval(
            action=action,
            params=params,
            requester=user,
            timeout=3600  # 1 Stunde Zeit zur Prüfung
        )
        if not approval.granted:
            return Result(success=False, reason="Freigabe verweigert")

    return await perform_action(action, params)

Beispiele für Human-in-the-Loop:

• KI-Agent will E-Mail an Kunden senden → Freigabe durch Mitarbeiter
• System will Daten löschen → Bestätigung durch Admin
• Automatisierung will externen API-Call machen → Prüfung durch Security

Ergebnis Stufe 3: Nach 3-6 Monaten haben Sie mehrschichtige technische Controls live: Input/Output-Validation, Zugriffskontrolle, Rate Limiting, umfassendes Logging. Ihre Mitarbeiter sind geschult, Policies sind kommuniziert. Ihre KI-Systeme sind jetzt aktiv geschützt.

Stufe 4: Monitor (Ongoing)

Ziel: Sicherheit aufrechterhalten und verbessern.

Security ist kein Projekt mit Enddatum. Bedrohungen entwickeln sich weiter, neue Schwachstellen werden entdeckt, Nutzungsmuster ändern sich. Die Monitor-Phase stellt sicher, dass Sie Probleme erkennen, bevor sie zu Vorfällen werden.

4.1 Continuous Monitoring

Effektives Monitoring braucht die richtigen Metriken – nicht zu viele, nicht zu wenige. Die folgenden sechs KPIs decken Security, Performance und Kosten ab:

Beispiel-Dashboard:

Ein AI Security Dashboard sollte auf einen Blick zeigen: Läuft alles normal? Wo muss ich eingreifen? Die wichtigsten Komponenten:

• Query Volume & Trends: Wie viele Anfragen pro Zeiteinheit? Gibt es ungewöhnliche Spikes?
• Security Events: Geblockte Requests, Injection-Versuche, Policy-Violations
• Cost Tracking: Budget-Auslastung in Echtzeit, um Überraschungen zu vermeiden
• Active Alerts: Priorisierte Liste aktueller Warnungen mit Kontext
• System Health: Status aller Komponenten (Gateway, LLM-Service, Logging-Pipeline)

4.2 Anomaly Detection

Normale Metriken zeigen, ob alles im grünen Bereich ist. Anomalie-Erkennung findet das Ungewöhnliche – oft der erste Hinweis auf einen Angriff oder Missbrauch.

Worauf Sie achten sollten:

Integration in Ihre bestehende Infrastruktur:

Wenn Sie bereits ein SIEM haben, integrieren Sie die AI-Logs dort. Der Vorteil: Korrelation mit anderen Security-Events, einheitliches Alerting, bewährte Prozesse.

AI-Logs → Log Aggregator → SIEM → Alert → Response

4.3 Periodic Assessment

Kontinuierliches Monitoring ist reaktiv – es findet Probleme, wenn sie auftreten. Regelmäßige Assessments sind proaktiv: Sie suchen gezielt nach Schwachstellen, bevor Angreifer sie finden.

Tipp: Quartalsweise Red-Team-Übungen klingen aufwendig, müssen es aber nicht sein. Schon ein halber Tag gezieltes Testen durch einen erfahrenen Mitarbeiter findet oft kritische Lücken.

4.4 Feedback Loop

Security ist ein Kreislauf: Monitoring findet Probleme, die zu neuen Assessments führen, die zu neuen Schutzmaßnahmen führen – und dann wieder zu Monitoring.

Der wichtigste Aspekt: Lernen Sie aus Vorfällen. Jeder Security-Event ist eine Gelegenheit, Ihre Schutzmaßnahmen zu verbessern.

Ergebnis Stufe 4: Sie haben ein laufendes Monitoring-System, Alert-Regeln für kritische Events und einen regelmäßigen Review-Prozess. Sie reagieren nicht mehr nur auf Vorfälle – Sie erkennen und verhindern sie proaktiv.

Integration mit bestehenden Frameworks

Sie haben vermutlich bereits Security-Frameworks im Einsatz – ISO 27001, NIST, oder bereiten sich auf den EU AI Act vor. Dieses Framework ersetzt sie nicht, sondern ergänzt sie um die KI-spezifischen Aspekte. Hier sehen Sie, wie die Phasen zueinander passen:

Warum Integration wichtig ist

• Keine Doppelarbeit: Nutzen Sie bestehende Prozesse und erweitern Sie sie
• Audit-ready: Zeigen Sie Prüfern, wie Ihre KI-Security in etablierte Standards passt
• Einheitliche Sprache: Management und Compliance-Teams verstehen die Mapping-Tabellen

NIST AI RMF

Das NIST AI Risk Management Framework ist der umfassendste Standard für KI-Governance. So passt unser Framework hinein:

Offizielle Dokumentation:

• NIST AI Risk Management Framework – Übersicht – Einstiegspunkt mit allen Ressourcen
• AI RMF 1.0 (PDF) – Das vollständige Framework-Dokument
• NIST AI RMF Playbook – Praktische Umsetzungsanleitungen
• Generative AI Profile (2024) – Ergänzung für GenAI-spezifische Risiken

ISO 27001

Wenn Sie ISO 27001-zertifiziert sind, können Sie KI-Security in Ihr bestehendes ISMS integrieren:

Offizielle Dokumentation:

• ISO/IEC 27001:2022 – Offizielle Standardseite – Übersicht und Bezugsquelle
• ISO/IEC 27000 Familie – Übersicht – Alle verwandten Standards
• BSI IT-Grundschutz – Deutsche Umsetzung mit KI-Bausteinen

EU AI Act

Ab 2025 verpflichtend – unser Framework bereitet Sie darauf vor:

Offizielle Dokumentation:

• EU AI Act – Volltext (EUR-Lex) – Regulation (EU) 2024/1689, offizieller Gesetzestext
• EU AI Act – PDF-Version – Zum Download und Offline-Lesen
• EU AI Act Zusammenfassung (EUR-Lex) – Kompakte Übersicht der wichtigsten Punkte
• AI Act Explorer – Durchsuchbare Version mit Erläuterungen

Kosten & Ressourcen

"Was kostet das?" – eine berechtigte Frage. Die ehrliche Antwort: Es kommt darauf an. Aber hier sind realistische Schätzungen basierend auf typischen Implementierungen.

Personalbedarf

Der größte Kostenfaktor ist nicht Software, sondern Zeit. Diese Aufwände sollten Sie einplanen:

Realistische Einschätzung: Die ersten drei Phasen laufen parallel zum Tagesgeschäft. Rechnen Sie mit 2-3 Monaten, bis die Grundlagen stehen. Monitor ist dann Dauerbetrieb.

Tool-Kosten

Sie müssen nicht alles kaufen. Priorisieren Sie nach Ihrem größten Risiko:

Tipp: Wenn Sie bereits Microsoft 365 E5 haben, ist Defender for Cloud Apps enthalten. Nutzen Sie bestehende Lizenzen, bevor Sie neue kaufen.

Budget-Schätzung

Grobe Orientierung für ein vollständiges Programm (Personal + Tools + externe Unterstützung):

Der ROI-Gedanke: Ein einzelnes Datenleck kann Millionen kosten (DSGVO-Strafen bis 4% Jahresumsatz, Reputationsschaden, Incident Response). Die Investition in Prävention ist fast immer günstiger als die Reaktion auf einen Vorfall.

Fazit: So starten Sie

Der kritische Erfolgsfaktor ist nicht die perfekte Implementierung – es ist der Start. Ein unvollständiges Inventar ist besser als keins. Eine einfache Risk Matrix ist besser als endlose Analyse-Paralyse.

Die ersten 30 Tage entscheiden: Sponsor sichern (CISO oder CTO), Discovery starten, erste Quick Wins umsetzen. Wenn nach einem Monat kein AI-Inventar existiert, wird das Projekt scheitern.

Der häufigste Fehler: Zu lange in der Assess-Phase verharren. Perfekte Risikobewertungen sind wertlos ohne Protection. Lieber 80% Risikoverständnis mit 100% Quick Wins als umgekehrt.

Das Ziel nach 6 Monaten: Sie wissen, welche KI-Systeme Sie haben (Discover), kennen die kritischen Risiken (Assess), haben technische Controls live (Protect) und können Anomalien erkennen (Monitor). Nicht perfekt – aber systematisch geschützt.

Weiterführend

• LLM Security: Risiken und Schutzmaßnahmen – Die 7 kritischsten OWASP-Risiken
• Prompt Injection verstehen und verhindern – Deep-Dive in die kritischste Schwachstelle
• AI Security Grundlagen – Zurück zur Übersicht