Diese Website verwendet ausschließlich technisch notwendige Cookies, die für den Betrieb der Seite erforderlich sind. Weitere Informationen


GPAI-Modelle sicher bewerten und einsetzen



Rechtlicher Status (Stand 02.08.2026)

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 2025

GPAI-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.
Quelle: EU-Kommission, Guidelines on the scope of obligations for providers of general-purpose AI models, 18. Juli 2025, Abschnitt 2.
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.

Compliance-Readiness
Rollen, Verträge, Nachweise.
Human Oversight
Verantwortung bleibt beim Menschen.
Nachweisfähigkeit
Logging Logging bei KI bezeichnet die automatisierte Protokollierung von Ereignissen, Eingaben (Prompts) und Ausgaben (Responses) eines KI-Systems, um dessen Verhalten, Leistung und Sicherheit zu überwachen. , Monitoring, Incident Flow.

Executive Takeaway

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.

Leitplanke
Ohne klare Rollenklärung (Anbieter vs. Betreiber vs. Integrator) und ohne Nachweise vom Anbieter entsteht operativ ein Compliance-Delta – inklusive Haftungs- und Reputationsrisiko.

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)

1) Rollen & Verantwortung
Betreiber (Krankenhaus), Anbieter (Modell/Tool), ggf. Systemintegrator. Entscheidungshoheit bleibt fachlich im Haus.
2) Zweckbestimmung
Administrativ (Dokumentation) vs. klinisch (Entscheidungsunterstützung). Zweck bestimmt Risikopflichten.
3) Betriebskonzept
Zugriff, Logging, Freigaben, Monitoring, Incident-Flow Incident-Flow (oft im Kontext von AI Incident Response oder KI-gestütztem Incident Management) beschreibt den automatisierten und strukturierten Prozess zur Erkennung, Analyse, Behebung und Dokumentation von Störungen, Sicherheitsvorfällen oder Leistungsabfällen in KI-Systemen. . Change-Control bei Modell-/Prompt-Änderungen.
4) Qualifizierung
AI Literacy AI Literacy (KI-Kompetenz oder KI-Alphabetisierung) bezeichnet die Fähigkeit, Künstliche Intelligenz (KI) zu verstehen, kritisch zu bewerten, sicher zu nutzen und ethisch verantwortungsvoll anzuwenden. und Schulungspflichten als Betriebsstandard (Einweisung, Grenzen, Fehlermodi, Eskalation).

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.

Mindestunterlagen vom Anbieter anfordern
  • 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.
Vertragsklauseln (operativer Standard)
  • Ä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

Tipp: intern als Projekt-Readiness-Check für IT-, QM- oder Rechtsabteilung
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
Quelle: Überblick zu GPAI-Leitlinien (EU-Kommission Entwurf, Kontext & Pflichtenlogik)
Fortschritt: 0%

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

0erfüllt
0teilweise erfüllt
0nicht erfüllt
0nicht anwendbar

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