Kurz gesagt: Der IT-Grundschutz des BSI bietet auch für KI-Anwendungen einen erprobten Rahmen. Wer KI in regulierten Umgebungen einsetzt, muss über klassische Datenschutzbetrachtungen hinausgehen. Welche Bausteine relevant sind, welche Anforderungen für Sprachmodelle und RAG-Systeme gelten, und wie ein Umsetzungspfad aussieht.

Warum BSI-Grundschutz und KI zusammengehören

KI-Anwendungen verschieben das Sicherheitsmodell. Klassische Schutzziele wie Vertraulichkeit, Integrität und Verfügbarkeit bleiben, dazu kommen aber neue Risiken: Trainingsdaten-Manipulation, Prompt Injection, Modell-Diebstahl, ungewollte Datenabflüsse durch Sprachmodelle.

Die Bundesverwaltung arbeitet verbindlich nach IT-Grundschutz. Viele Länder, Kommunen und KRITIS-Betreiber nutzen ihn als Nachweisweg für den Stand der Technik, den sie umsetzen müssen (§§ 30, 31 BSIG). Wer KI in solchen Umgebungen einsetzt, fährt deshalb gut damit, seine Architektur am IT-Grundschutz auszurichten. Der EU AI Act setzt zusätzliche Anforderungen für Hochrisiko-Systeme, BSI-Grundschutz und EU AI Act ergänzen sich.

Welche BSI-Bausteine relevant sind

Der BSI-Grundschutz arbeitet mit thematischen Bausteinen. Für KI-Systeme sind insbesondere relevant:

  • APP.bd.1 Künstliche Intelligenz Komponenten als zentraler Baustein für in Software integrierte KI-Komponenten
  • APP.6 Allgemeine Software für die Anwendung, die die KI einbindet
  • CON.10 Entwicklung von Webanwendungen für KI-APIs und Frontends
  • OPS.1.1.5 Protokollierung für die Nachvollziehbarkeit von Modell-Inferenz
  • DER.1 Detektion von sicherheitsrelevanten Ereignissen für Anomalie-Erkennung im Betrieb
  • NET.1.1 Netzarchitektur und -design für die Segmentierung von KI-Workloads
  • SYS.1.1 Allgemeiner Server für die hostende Infrastruktur

Zusätzlich hat das BSI sektorspezifische Veröffentlichungen wie den AIC4-Kriterienkatalog (AI Cloud Service Compliance Criteria Catalogue) und Hinweise zum sicheren Einsatz von Sprachmodellen herausgegeben. Wer KI auf Cloud-Plattformen betreibt, sollte beides parallel berücksichtigen.

Spezifika für Sprachmodelle und RAG-Systeme

Sprachmodelle und Retrieval-Augmented-Generation-Architekturen haben Sicherheitsanforderungen, die klassische Anwendungen nicht kennen:

Prompt Injection und Jailbreaks. Eingaben können Modell-Verhalten in unbeabsichtigter Weise verändern. Eingaben müssen daher als nicht vertrauenswürdig behandelt werden, auch wenn sie von authentifizierten Nutzern stammen. Output-Filter, Prompt-Templating mit klarer Trennung von System- und Nutzeranweisung, und Rate-Limiting gehören zum Standard.

Datenfluss in RAG-Architekturen. Wenn das Modell auf interne Wissensdokumente zugreift, muss die Berechtigungs-Architektur diese Dokumente nach Nutzerrolle filtern. Sonst gibt das Modell über die Suche Informationen preis, die der Nutzer in der ursprünglichen Quelle nicht sehen dürfte.

Trainings- und Feintuning-Daten. Bei Modellen, die auf eigenen Daten trainiert werden, müssen die Trainingsdaten klassifiziert, freigegeben und nach Schutzbedarf behandelt werden. Personenbezogene Daten erfordern eine Rechtsgrundlage nach DSGVO.

Modell-Hosting. Self-Hosting in einer kontrollierten Umgebung ist für regulierte Anwender meist die einzig haltbare Option. Externe APIs ohne klare Datenresidenz, ohne Vertragslage nach deutschem Recht und ohne Audit-Möglichkeit lassen sich bei höherem Schutzbedarf kaum mit den Anforderungen des IT-Grundschutzes vereinbaren.

Schritte zur Umsetzung

Wir empfehlen sechs Schritte für KI-Anwendungen in regulierten Umgebungen:

  1. Schutzbedarfsanalyse für die KI-Anwendung. Welche Daten verarbeitet das Modell? Welche Ausgaben treffen welche Entscheidungen? Daraus ergibt sich der Schutzbedarf (normal, hoch, sehr hoch).
  2. Relevante BSI-Bausteine identifizieren. Aus dem Anwendungstyp und der Infrastruktur. Mapping in eine Lückenanalyse.
  3. Architektur-Entscheidungen ableiten. Self-Hosting vs API, Modell-Auswahl, RAG-Komponenten, Berechtigungs-Modell. Diese Entscheidungen sind später teuer zu revidieren.
  4. Technische Maßnahmen umsetzen. Input-Validierung, Output-Filter, Logging, Detection, Backup, Verschlüsselung. Mit nachweisbarer Konfiguration.
  5. Organisatorische Maßnahmen. Rollen-Konzept, Schulungen, Notfallplan, regelmäßige Tests (auch adversariell, etwa durch Red-Team-Engagements).
  6. Dokumentation und Audit. Audit-tauglicher Nachweis der Maßnahmen, mit Bezug auf die jeweiligen BSI-Bausteine. Bei höherem Schutzbedarf zusätzliche Penetration Tests und Modell-Reviews.

Wo es typischerweise hakt

Drei Punkte, die in Projekten regelmäßig unterschätzt werden:

  • Modell-Auswahl wird IT-getrieben, nicht risikogetrieben. Teams wählen das aktuell beste Modell, ohne die regulatorische Tragfähigkeit zu prüfen. Bei hohem Schutzbedarf sind viele kommerzielle Modelle nicht einsetzbar, unabhängig von der Leistungsfähigkeit.
  • Berechtigungen werden auf Anwendungsebene gelöst, nicht im RAG-Layer. Das führt zu subtilen Datenlecks, die in normalen Tests nicht auffallen.
  • Notfallplan fehlt. Was passiert, wenn das Modell systematisch falsche Antworten gibt? Wann wird abgeschaltet, wer entscheidet, wie wird kommuniziert?

Verhältnis zum EU AI Act

Der EU AI Act und der BSI-Grundschutz adressieren verschiedene Ebenen. Der AI Act klassifiziert Anwendungen nach Risikoklassen und definiert Pflichten für Hochrisiko-Systeme. Der IT-Grundschutz hilft, einen Teil dieser Pflichten technisch und organisatorisch umzusetzen, etwa bei Cybersicherheit, Protokollierung und Notfallvorsorge. Er ersetzt die Konformitätsbewertung nach dem AI Act nicht. Beide Werke sind kompatibel und können in einem Programm bearbeitet werden.

Wie GermanAI Defense unterstützt

Wir entwerfen KI-Anwendungen mit klarer Berechtigungs-Architektur, geprüftem Datenfluss und einer Dokumentation mit Bezug auf die BSI-Bausteine. Auf Wunsch betreiben wir sie in Deutschland oder bei Ihnen vor Ort, Modelle und Daten bleiben unter Ihrer Kontrolle.

Für Bundesbehörden, KRITIS-Betreiber und regulierten Mittelstand.

→ Mehr zu unseren AI Solutions: AI Solutions ansehen