GPAI-Modelle sicher bewerten und einsetzen

Das KI-MIG ist seit 29.07.2026 in Kraft (BGBl. 2026 I Nr. 223). Für GPAI-Modelle selbst bleibt das europäische KI-Büro zuständig; für den Einsatz GPAI-basierter Anwendungen in Deutschland (z. B. in Krankenhäusern) ist die Bundesnetzagentur die zentrale Marktüberwachungsbehörde. GPAI-Pflichten selbst sind vom Digital-Omnibus-Paket nicht betroffen – verschoben wurden nur die Anhang-III- (2.12.2027) und Anhang-I-Fristen (2.8.2028) für Hochrisiko-KI-Anwendungen, nicht die seit 2.8.2025 geltenden GPAI-Anbieterpflichten.
Prüfschema
Stand: Januar 2026 – Aktualisiert nach EU AI Act GPAI-Leitlinien vom 18. Juli 2025GPAI-Modelle GPAI-Modelle (General Purpose Artificial Intelligence – KI-Modelle mit allgemeinem Verwendungszweck) sind KI-Systeme, die darauf ausgelegt sind, eine breite Palette von unterschiedlichen Aufgaben kompetent auszuführen. im Gesundheitswesen
Ein KI-Modell gilt als GPAI-Modell, wenn:
- Das Training mehr als 10²³ FLOPS (Floating Point Operations) umfasst.
- Das Modell in der Lage ist, Sprache (Text/Audio), Text-zu-Bild oder Text-zu-Video zu generieren.
- Es signifikante Allgemeingültigkeit zeigt und kompetent eine breite Palette unterschiedlicher Aufgaben erfüllen kann.
Wichtig: Modelle, die die 10²³ FLOPS-Schwelle überschreiten, aber auf spezielle Aufgaben begrenzt sind (z.B. Transkription, Bildverbesserung, Wettervorhersage), gelten NICHT als GPAI-Modelle, wenn ihnen die allgemeine Vielseitigkeit fehlt.
In der Krankenhauspraxis ist GPAI selten „nur ein Modell" – es wird fast immer Teil eines KI-Systems (Downstream AI SystemEin Downstream AI System (nachgelagertes KI-System) ist eine Anwendung, die auf einem bestehenden, grundlegenden KI-Modell (dem „Upstream"-Modell, z. B. einem Large Language Model wie GPT-4) aufbaut, um spezifische Aufgaben zu erfüllen. Beispiel: Ein Kundenservice-Chatbot, der auf GPT-4 basiert und spezifisch auf die Produktdatenbank eines Unternehmens trainiert wurde, ist ein Downstream-System.).
Damit entscheidet die Zweckbestimmung, ob zusätzliche Pflichten (z.B. Hochrisiko nach Art. 6 AI Act) greifen.
Was bedeutet die 10²³ FLOPS-Schwelle?
FLOPS = Floating Point Operations Per Second (Gleitkomma-Operationen pro Sekunde)
10²³ = 100.000.000.000.000.000.000.000 (eine 1 mit 23 Nullen)
Praktisch bedeutet das:
Ab diesem Rechenaufwand beim Training gilt ein KI-Modell als GPAI-Modell und unterliegt speziellen EU-Pflichten (Dokumentation, Transparenz, Copyright-Policy).
Beispiele von Modellen ÜBER dieser Schwelle:
- GPT-4 (OpenAI)
- Claude 3 & 4 (Anthropic)
- Gemini (Google)
- Llama 3 (Meta)
Zum Vergleich: Die 10²⁵ FLOPS-Schwelle (100× höher) kennzeichnet Modelle mit systemischem Risiko und noch strengeren Anforderungen.
Quelle: EU-Kommissions-Leitlinien für GPAI-Modelle, 18. Juli 2025
Governance-Setup (Krankenhaus)
Vertrags- & Due-Diligence-Check (Beschaffung)
Ziel ist ein prüffähiges Lieferanten-Setup: Das Krankenhaus kauft nicht „KI“, sondern Nachweisfähigkeit und Betriebsstabilität.
Kern ist die Abfrage der GPAI-relevanten Anbieterinformationen (Dokumentation, Trainingsdaten-Zusammenfassung, Copyright-Policy) und die
Absicherung der betrieblichen Anschlussprozesse.
- Modell-/Systemdokumentation (Version, Zweck, Grenzen, Evaluierung)
- Zusammenfassung der Trainingsdaten (gemäß EU-Vorlage, sobald verfügbar)
- Copyright-, TDM-Policy Eine TDM-Policy (Text and Data Mining Policy) ist eine Richtlinie oder Nutzungsbedingung, die festlegt, ob und wie automatisierte Verfahren zum Analysieren von Texten und Daten (TDM) auf urheberrechtlich geschützte Inhalte angewendet werden dürfen. und Umgang mit Rechtevorbehalten
- Sicherheits-/Cyber-Konzept, Red-Teaming Evaluierungen Red-Teaming-Evaluierungen (auch Red Team Assessments genannt) sind strukturierte Sicherheitprüfungen, bei denen ein internes oder externes Team von Experten (das "Red Team") einen realistischen, gegnerischen Angriff auf ein System, eine Infrastruktur oder ein KI-Modell simuliert. (falls vorhanden)
- Incident- und Vulnerability-Disclosure-Prozess Ein Vulnerability-Disclosure-Process (auf Deutsch: Prozess zur Offenlegung von Sicherheitslücken) ist ein strukturierter, vertraulicher Ablauf, bei dem externe Sicherheitsfachleute entdeckte Schwachstellen in Software, Hardware oder IT-Systemen direkt an den betroffenen Hersteller melden.
- Änderungsmanagement: Versionierung, Vorabinfo, Rückfalloption
- Audit-/Auskunftsrechte (mind. in regulatorisch relevanten Fällen)
- Subprozessoren/Hosting: Transparenz, EU-Standort/Schutzniveau
- Support-SLA & Security-Patch-Fristen Eine Service Level Agreement (SLA) für Sicherheitspatches legt verbindliche Fristen für die Behebung von Sicherheitslücken fest, wobei sich die Branche häufig auf 14 Tage für kritische Korrekturen einigt, um vor Cyberangriffen zu schützen. Diese Vereinbarungen, die oft als Security Level Agreements (SecLA) bezeichnet werden, regeln detailliert die Prozesse des Patch-Managements, die Reaktionszeiten und die Sanktionen bei Nichteinhaltung – allesamt entscheidende Faktoren für die Einhaltung der Vorschriften.
- Haftung/Verantwortungsabgrenzung: „Assistenz“ vs. „Entscheidung“
Checkliste: GPAI-Einsatz im Krankenhaus
| OK | Prüfpunkt | Owner | Nachweis |
|---|---|---|---|
| A) Rollenklärung & Scope | |||
| Zweckbestimmung ist schriftlich fixiert (administrativ vs. klinisch; keine automatische Entscheidung). | Projektleitung / Medizin | Use-Case One-Pager | |
| Rollen sind sauber zugeordnet: Modellanbieter / Toolanbieter / Krankenhaus als Betreiber; Integrator-Rolle geprüft. | IT / Compliance | RACI Mit RACI wird eine Technik zur Analyse und Darstellung von Verantwortlichkeiten bezeichnet. Der Name leitet sich aus den Anfangsbuchstaben der englischen Begriffe Responsible, Accountable, Consulted, Informed ab. / Rollenmatrix | |
| B) Anbieter-Nachweise (GPAI-relevant) | |||
| Dokumentation vom Anbieter liegt vor und ist versioniert (Capabilities, Grenzen, Evaluierung). | Einkauf / IT | Vendor Dossier | |
| Trainingsdaten-Zusammenfassung (oder verbindlicher Plan zur Bereitstellung) ist vertraglich gesichert. | Einkauf / Legal | Vertrag / Annex | |
| Copyright-/TDM-Policy liegt vor (inkl. Umgang mit Rechtevorbehalt) und ist intern bewertet. | Legal / QM | Policy Review | |
| Systemisches Risiko geprüft (falls relevant): zusätzliche Nachweise (Risk Mgmt, Cyber, Incidents). | IT-Security | Security Pack | |
| C) Datenschutz & IT-Governance | |||
| DSGVO-Setup: AVV, Subprozessoren, Datenflüsse, Löschkonzept; Minimalprinzip umgesetzt. | DSB / IT | Datenflussdiagramm | |
| Keine Schatten-IT: Zugriff nur über freigegebene Kanäle, Rollen-/Rechtekonzept aktiv. | IT | RBAC / IAM IAM (Identity and Access Management) ist ein Rahmenwerk zur Verwaltung von digitalen Identitäten und deren Zugriffsberechtigungen, während RBAC (Role-Based Access Control) eine spezifische Methode innerhalb von IAM ist, um Zugriffe über vordefinierte Rollen statt individuell zu steuern. | |
| Logging/Protokollierung ist definiert (Prompt/Output, Nutzer, Zeitpunkt, Version) – revisionsfest. | IT / QM | Log-Konzept | |
| D) Betrieb, Qualität, Patientensicherheit | |||
| Human Oversight: Freigabeprozess definiert (KI liefert Entwurf; Fachkraft finalisiert). | Fachbereich | SOP / Arbeitsanweisung | |
| Qualitätskontrollen: Stichproben, Fehlertypen, Korrekturprozess (inkl. „Stop-Use“-Kriterium). | QM | QA-Plan | |
| Incident-Flow steht: Meldeweg bei gravierenden Fehlern / Datenschutz / Security; Anbieter ist eingebunden. | IT-Sec / DSB | IR-Runbook Ein IR-Runbook (Incident Response Runbook) ist eine detaillierte, schrittweise Anleitung, die IT- und Sicherheitsteams nutzen, um auf spezifische Sicherheitsvorfälle (Incidents) zu reagieren. | |
| Change-Control: Modell-/Prompt-/Workflow-Änderungen werden bewertet, dokumentiert, freigegeben. | IT / QM | Change-Prozess | |
| E) Menschen, Schulung, Mitbestimmung | |||
| AI Literacy-Schulung: Grenzen, Bias, Halluzinationen, sichere Nutzung, Eskalation. | HR / QM | Schulungsnachweis | |
| Betriebsrat/Personalvertretung ist frühzeitig eingebunden (Prozess-/Arbeitsplatzwirkung). | HR | Protokoll / BV | |
BSI-Checkliste: Planung, Beschaffung, Anpassung
Kriterienkatalog des BSI zur Integration von extern bereitgestellten generativen KI-Modellen in eigene Anwendungen (Juni 2025)
Anleitung
Diese Checkliste bildet die drei frühen Lebenszyklusphasen des BSI-Kriterienkatalogs ab: anwendungsfallbezogene Planung, Beschaffung und Anpassung (u. a. System-Prompts) – jeweils vor Integration eines extern bereitgestellten generativen KI-Modells in eine eigene Anwendung. Die farbigen Marken zeigen das Modalverb des Originaltexts (MUSS, SOLLTE, DARF NICHT). Bewerten Sie jeden Punkt und exportieren Sie das Ergebnis als PDF.
Hinweis: Der Kriterienkatalog ist derzeit unverbindlich und richtet sich an die Bundesverwaltung; er dient hier als Orientierungsrahmen guter Praxis auch außerhalb der Bundesverwaltung. Quelle: BSI Kriterienkatalog
Management Summary
Statusübersicht
-
Offene Prüfpunkte
Erstellt am:
Häufige Fragen zum BSI-Kriterienkatalog
Einordnung der interaktiven Checkliste für extern bereitgestellte generative KI-Modelle.
Ist der BSI-Kriterienkatalog verbindlich?
Nein. Version 1.0 vom 6. Juni 2025 ist ein unverbindlicher Kriterienkatalog, der frühzeitig Orientierung geben und perspektivisch in einen Mindeststandard münden soll. Gesetzliche Pflichten, insbesondere aus der EU-KI-Verordnung, bleiben zusätzlich zu beachten.
Für welche KI-Anwendungen gilt der Kriterienkatalog?
Er adressiert den regulären Betrieb eigener Anwendungen, in die extern bereitgestellte generative KI-Modelle per Schnittstelle oder lokal integriert werden. Reine Dienstenutzung, vollständig selbst entwickelte Modelle, eigenes Fine-Tuning sowie Forschung, Proof of Concept und Laborbetrieb liegen außerhalb seines Geltungsbereichs.
Welche Lebenszyklusphasen deckt die Checkliste ab?
Der BSI-Katalog betrachtet globale KI-Governance, Planung, Beschaffung, Anpassung, Integration, Einsatz und Beendigung. Die interaktive Checkliste dieser Seite konzentriert sich auf Planung, Beschaffung und Anpassung; Status, Notizen und offene Punkte können als PDF dokumentiert werden.
Quelle: Bundesamt für Sicherheit in der Informationstechnik, Kriterienkatalog zur Integration extern bereitgestellter generativer KI-Modelle, Version 1.0, 6. Juni 2025.
|
Überblick über die Leitlinien für GPAI-Modelle
Die Leitlinien enthalten Auslegungshilfen zur Definition und zum Anwendungsbereich von GPAI-Modellen, zu den damit verbundenen Lebenszyklusverpflichtungen, den Kriterien für das Systemrisiko und den Meldepflichten für Anbieter. Institut für die Zukunft des Leben, 2026. Direktlink zur Webseite |
GPAI-Modelle in der Praxis nutzen?
Ich zeige Ihnen, wie Sie alle Anforderungen für GPAI-Modelle prüfen – konkret, regulatorisch sicher und umsetzbar. |
BSI A5 · Audit & Assurance
GPAI und nachgelagerte Systeme getrennt nachweisen
A5 DEI.5.2/5.3 unterstützt die Trennung von Foundation Model und downstream eingesetztem KI-System.
Systemgrenzen, Drittkomponenten, Datenflüsse und die jeweiligen Verantwortlichkeiten sind separat zu dokumentieren und anschließend in der Gesamtsystembeschreibung zu verbinden.
BSI A5: Status, Module und interaktives Readiness-Assessment