¶ Einsatz von KI im Unternehmen
Grundsatz: KI-Anwendungen dürfen erst für einen festgelegten Zweck eingesetzt werden, wenn Anwendungsfall, Daten, Anbieter, Informationssicherheits- und Datenschutzrisiken, menschliche Kontrolle, Verantwortlichkeit und Freigabe nachvollziehbar geklärt sind.
Eingaberegel: Vertrauliche, streng vertrauliche, personenbezogene, kundenbezogene oder prototypenbezogene Informationen dürfen nicht allein deshalb in ein KI-System eingegeben werden, weil das Werkzeug technisch erreichbar ist. Maßgeblich sind Informationsklassifizierung, genehmigter Anwendungsfall, Vertrag, Konfiguration und tatsächlicher Datenfluss.
Musterstatus: Diese Seite bestätigt keine real eingesetzte KI-Anwendung, Risikoklasse, Rechtsrolle, Vertragsgestaltung, Schulung oder Wirksamkeit. Sie muss vor der betrieblichen Nutzung organisationsbezogen ergänzt, geprüft, freigegeben und nachweisbar umgesetzt werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-14 |
| Dokumentenart | Richtlinie und Verfahren für den sicheren KI-Einsatz |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Einsatz-von-KI-im-Unternehmen |
| Verantwortlich | KI-Governance-Verantwortliche/r und ISMS-Beauftragte/r |
| Fachlich geprüft durch | Geschäftsführung, IT, Informationssicherheit, Datenschutz, Recht/Compliance, Einkauf, Personal, Fachbereiche und gegebenenfalls Entwicklung |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – KI-Bestand, Rollen, Freigaben und Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 10.08.2026 |
| Gültig ab | Nach formaler Freigabe und Kommunikation |
| Nächste Prüfung | Mindestens jährlich sowie nach wesentlichen Modell-, Anbieter-, Zweck-, Daten-, Rechts- oder Risikoveränderungen |
| Schutzklasse | Intern; Registerdetails, Prompts, Datenquellen, Systemkonfigurationen, Tests und Schwachstellen gegebenenfalls Vertraulich oder Streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 6 und 8 sowie Annex A 5.7, 5.8, 5.19 bis 5.23, 5.31, 5.34, 5.36, 6.3, 8.4, 8.9, 8.25, 8.28, 8.31 und 8.32 |
| Ergänzende Orientierung | ISO/IEC 42001:2023, EU-KI-Verordnung, DSGVO, BDSG und BSI-Veröffentlichungen zu KI-Sicherheit |
| VDA-ISA-Bezug | ISA 6.0.3; mehrere Informationssicherheitsfragen zu Richtlinien, Risiken, Lieferanten, Cloud, Entwicklung, Betrieb, Daten und Awareness |
KI-Anwendungen erfassen, risikobasiert bewerten, begrenzt freigeben und fortlaufend überwachen. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Diese Regelung schafft einen einheitlichen Rahmen für Auswahl, Beschaffung, Entwicklung, Erprobung, Freigabe, Nutzung, Änderung und Beendigung von KI-Anwendungen. Sie verbindet Informationssicherheit mit Datenschutz, Recht, Qualitätsanforderungen und menschlicher Verantwortung.
Sie soll insbesondere verhindern, dass:
- unbekannte oder nicht freigegebene KI-Dienste als Schatten-KI genutzt werden,
- Geschäftsgeheimnisse, Kundeninformationen oder personenbezogene Daten unkontrolliert abfließen,
- plausible, aber falsche oder manipulierte Ausgaben ungeprüft übernommen werden,
- Anbieter Daten entgegen den Unternehmensinteressen speichern, auswerten oder zum Training verwenden,
- KI-Ergebnisse ohne kompetente menschliche Kontrolle erhebliche Entscheidungen bestimmen,
- Modelle, Wissensquellen, Systemprompts, Schnittstellen oder Berechtigungen unkontrolliert verändert werden,
- gesetzliche, vertragliche, TISAX-, Kunden- oder Prototypenschutzanforderungen übersehen werden,
- die Organisation einen KI-Einsatz nicht erklären, prüfen, beenden oder im Vorfall beherrschen kann.
Zugleich ermöglicht die Regelung einen nachvollziehbaren und angemessen schnellen Freigabeweg für geeignete KI-Anwendungen.
¶ 2. Geltungsbereich
Die Regelung gilt unabhängig vom Produktnamen für:
- generative Text-, Bild-, Audio-, Video- und Codeassistenten,
- Übersetzung, Zusammenfassung, Recherche und Dokumentenklassifikation,
- Chatbots, Copilots und in Standardsoftware integrierte KI-Funktionen,
- lokale, selbst betriebene, Cloud- und hybride Modelle,
- Dokumentensuche, Retrieval-Augmented Generation (RAG) und Wissensassistenten,
- Prognosen, Empfehlungen, Priorisierung, Erkennung und automatisierte Entscheidungen,
- KI in Personal, Vertrieb, Marketing, Einkauf, Support, Entwicklung, Produktion, Qualität und Sicherheit,
- selbst entwickelte, angepasste oder über Schnittstellen eingebundene KI-Systeme,
- Pilot-, Test-, Forschungs- und Produktivnutzung,
- KI-Systeme von Lieferanten, die Leistungen oder Entscheidungen für das Unternehmen unterstützen.
Auch eine kostenfreie Testversion, ein privates Konto, eine Browsererweiterung oder eine unauffällige KI-Funktion in einer bereits beschafften Software ist erfasst.
¶ 3. Abgrenzung und Zusammenspiel
Diese Seite regelt den sicheren betrieblichen Einsatz. Sie ersetzt keine vollständige Prüfung nach der EU-KI-Verordnung, DSGVO, BDSG, Urheber-, Arbeits-, Wettbewerbs-, Geheimnisschutz- oder Produktsicherheitsrecht.
| Thema | Führende Wiki-Seite oder Nachweis |
|---|---|
| Informationssicherheitsrisiko | Methodik Risikobewertung und Risikoregister |
| Schutzklasse der Ein- und Ausgaben | Informationsklassifizierung |
| Anbieter-, Cloud- und Vertragsprüfung | Lieferanten und Dienstleister |
| Entwicklungs- und Integrationssicherheit | Sichere Entwicklung |
| Datenschutz und automatisierte Verarbeitung | KI und automatisierte Verarbeitung |
| Beschäftigte und Qualifikation | Personal und Schulungen |
| Vorfälle | Meldeweg für Sicherheitsvorfälle |
¶ 4. Leitprinzipien
- Anwendungsfall statt Produktfreigabe: Ein Anbieter wird nicht pauschal für beliebige Zwecke und Daten freigegeben.
- Kein Einsatz ohne Owner: Jede Anwendung besitzt eine fachlich verantwortliche und entscheidungsbefugte Rolle.
- Datenminimierung: Es werden nur erforderliche, zulässige und für den Dienst freigegebene Informationen verarbeitet.
- Menschliche Verantwortung: KI-Ausgaben unterstützen Entscheidungen; Verantwortung und Freigabe verbleiben bei Menschen.
- Misstrauen gegenüber Ausgaben: Sprachliche Sicherheit ist kein Beleg für Richtigkeit, Aktualität oder zulässige Herkunft.
- Security und Privacy by Design: Schutzmaßnahmen werden vor Pilot und Produktivnutzung festgelegt.
- Nachvollziehbarkeit: Zweck, Version, Datenquellen, Tests, Einschränkungen, Änderungen und Entscheidungen bleiben dokumentiert.
- Begrenzte Freigabe: Eine Freigabe gilt nur für benannte Nutzergruppen, Zwecke, Datenklassen, Funktionen und Konfigurationen.
- Änderungskontrolle: Modell-, Anbieter-, Prompt-, Plugin-, Datenquellen- und Schnittstellenänderungen werden bewertet.
- Beherrschbarer Ausstieg: Daten, Abhängigkeiten und Geschäftsprozesse müssen auch bei Anbieterwechsel oder Abschaltung kontrolliert bleiben.
¶ 5. Rollen und Verantwortlichkeiten
| Rolle | Mindestverantwortung |
|---|---|
| Geschäftsführung | KI-Grundsätze, Ressourcen, wesentliche Restrisiken und kritische Anwendungen freigeben |
| KI-Governance | Register, Prüfmethode, Rollenklärung, Freigabekoordination und Rechtsstatus pflegen |
| Fachlicher Owner | Zweck, Nutzen, Prozess, Qualitätskriterien, Nutzergruppe und menschliche Kontrolle verantworten |
| Information Owner | Schutzklasse, zulässige Eingaben, Empfänger, Speicherung und Löschung festlegen |
| IT/Informationssicherheit | Architektur, Identitäten, Schnittstellen, Protokollierung, Bedrohungen, Tests und Betrieb bewerten |
| Datenschutz | Rollen, Rechtsgrundlage, Transparenz, Betroffenenrechte, DSFA und Drittlandtransfer prüfen |
| Recht/Compliance | EU-KI-Verordnung, Verträge, Urheberrecht, Geschäftsgeheimnisse und sonstige Pflichten prüfen |
| Einkauf/Lieferantenmanagement | Anbieterprüfung, Vertragsanforderungen, Unterauftragnehmer, Audit- und Exit-Rechte steuern |
| Personal/Betriebsparteien | Beschäftigtenbezug, Schulungsbedarf, Beteiligung und arbeitsrechtliche Aspekte behandeln |
| Entwicklung/Integration | sicheren Lebenszyklus, Daten- und Modellherkunft, Tests, Versionierung und technische Kontrollen umsetzen |
| Nutzende | nur freigegebene Zwecke und Konten verwenden, Eingaberegeln einhalten, Ausgaben prüfen und Vorfälle melden |
| Interne Revision/Audit | Stichproben, Freigaben, Register, Nutzung und Wirksamkeitsnachweise unabhängig prüfen |
¶ 6. KI-Anwendungsregister
Vor Pilot oder Beschaffung wird jeder Anwendungsfall registriert. Eine Tabellenzeile pro Produkt reicht nicht aus, wenn dasselbe Werkzeug für unterschiedliche Zwecke oder Daten verwendet wird.
| Feldgruppe | Mindestinhalt |
|---|---|
| Identifikation | KI-ID, Bezeichnung, Anbieter, Produkt, Modell und Version |
| Anwendungsfall | Zweck, Prozess, erwarteter Nutzen, Nutzergruppen und ausgeschlossene Nutzungen |
| Rolle | Anbieter, Betreiber/Deployer, Importeur, Händler oder sonstige Rolle nach tatsächlicher Tätigkeit |
| Daten | Eingaben, Ausgaben, Wissensquellen, Personenbezug, Schutzklasse und Datenstandorte |
| Technik | SaaS/lokal/hybrid, Schnittstellen, Plugins, RAG, Logging, Training und Produktverbesserung |
| Wirkung | Unterstützung, Empfehlung, Priorisierung oder Entscheidung; betroffene Personen und mögliche Folgen |
| Risiko | Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität, Fehler, Manipulation, Bias und Missbrauch |
| Recht | KI-Risikokategorie, verbotene Praxis, Transparenz, DSGVO, Vertrag, Transfer und Beteiligungsrechte |
| Kontrollen | Zugriffe, Datenfilter, Ausgabetest, menschliche Aufsicht, Monitoring, Incident- und Exit-Verfahren |
| Freigabe | Status, Auflagen, Owner, Prüfende, Freigabestelle, Datum, Review und Nachweisverweise |
Empfohlene Statusfolge: Vorgeschlagen → Erfasst → In Prüfung → Pilot unter Auflagen → Freigegeben → Ausgesetzt → Beendet.
¶ 7. Freigabeampel
| Ampel | Bedeutung | Beispiele | Entscheidung |
|---|---|---|---|
| 🔴 Rot | verboten oder nicht vertretbar | verbotene KI-Praxis; unbekannter Datenfluss; Eingabe streng vertraulicher Informationen in einen öffentlichen Dienst; unkontrollierte erhebliche Entscheidung | nicht einsetzen beziehungsweise sofort aussetzen und eskalieren |
| 🟠 Orange | kritisch oder vertieft prüfpflichtig | Beschäftigtenauswahl, biometrische Verarbeitung, sicherheitskritische Steuerung, erhebliche Kundenentscheidung, besondere Kategorien personenbezogener Daten | keine Nutzung ohne vertiefte Rechts-, Risiko-, Datenschutz-, Sicherheits- und Managementfreigabe |
| 🟡 Gelb | begrenzter Pilot möglich | internes Zusammenfassen freigegebener Inhalte, RAG, Codeassistenz oder Klassifikation mit kontrollierten Daten und menschlicher Prüfung | Pilot nur mit Auflagen, Testkriterien, begrenztem Nutzerkreis und Review |
| 🟢 Grün | niedrigeres, aber nicht risikofreies Nutzungsszenario | Formulierungshilfe mit öffentlichen oder vollständig fiktiven Informationen | registrieren, Nutzungsregeln beachten, Ergebnis prüfen und Änderungen überwachen |
Die Ampel ist eine Erststeuerung und keine abschließende Einstufung nach der EU-KI-Verordnung. Ein „grüner“ Anwendungsfall kann durch neue Daten, Plugins, automatische Aktionen oder Zweckänderung hochgestuft werden.
¶ 8. Freigabeprozess
Eine technische Demonstration oder ein erfolgreich erzeugter Beispieltext ist keine Freigabe. Vor der Freigabe müssen vorab definierte fachliche, sicherheitsbezogene, datenschutzrechtliche und betriebliche Kriterien erfüllt sein.
¶ 9. Zulässige Eingaben und Informationsklassifizierung
| Informationsart | Standardregel für externe KI-Dienste | Mögliche Ausnahme |
|---|---|---|
| Öffentlich | zulässig, wenn Zweck und Dienst freigegeben sind | Quellen-, Urheber- und Ausgabeprüfung bleibt erforderlich |
| Intern | nur in freigegebenem Unternehmenskonto und für zugelassenen Zweck | Speicherung, Training, Zugriffe und Löschung müssen geklärt sein |
| Vertraulich | standardmäßig nicht eingeben | nur nach dokumentierter Information-Owner-, Sicherheits-, Vertrags- und gegebenenfalls Datenschutzfreigabe |
| Streng vertraulich | nicht eingeben | nur in besonders geprüfter, isolierter Lösung mit ausdrücklicher Managementfreigabe |
| Personenbezogen | nur wenn erforderlich, rechtmäßig und freigegeben | Pseudonymisierung oder Abstraktion bevorzugen; DSGVO-Prüfung dokumentieren |
| Kunden-/TISAX-/Prototypendaten | keine Eingabe ohne bestätigte Kunden-, Vertrags-, Schutzbedarfs- und TISAX-Prüfung | Freigabe muss konkreten Dienst, Zweck, Daten und Empfänger umfassen |
| Passwörter, Schlüssel und Tokens | niemals in Prompts oder Wissensquellen eingeben | keine Ausnahme; Secrets gehören in geeignete Secret-Verwaltung |
Auch eine Ausgabe kann vertraulich sein. Zusammenfassungen, Inferenzen, Klassifikationen und aus mehreren scheinbar harmlosen Quellen abgeleitete Ergebnisse übernehmen mindestens den erforderlichen Schutz ihrer Inhalte.
¶ 10. Praktische Nutzungsregeln
¶ 10.1 Erlaubt – innerhalb eines freigegebenen Anwendungsfalls
- öffentliche oder vollständig fiktive Inhalte formulieren und strukturieren lassen,
- Ergebnisse als Entwurf behandeln und fachlich prüfen,
- Quellen, Rechenwege, Zitate und Tatsachen unabhängig verifizieren,
- personenbezogene oder vertrauliche Angaben soweit möglich abstrahieren,
- nur freigegebene Unternehmenskonten, Modelle, Plugins und Schnittstellen verwenden,
- Unsicherheiten, Fehlverhalten und versehentliche Eingaben unverzüglich melden,
- KI-Unterstützung kennzeichnen, wenn Recht, Vertrag, Prozess oder Empfänger dies erfordern.
¶ 10.2 Nicht erlaubt – ohne besondere Prüfung und Freigabe
- reale Kunden-, Beschäftigten-, Gesundheits-, Finanz-, Sicherheits- oder Prototypendaten in offene Dienste eingeben,
- Geheimnisse, Zugangsdaten, Quellcode oder Schwachstellendetails unkontrolliert übertragen,
- KI-Ausgaben ungeprüft als verbindliche Rechts-, Medizin-, Personal-, Sicherheits- oder Managemententscheidung verwenden,
- erfundene Quellen, Zitate, Nachweise oder Prüfergebnisse als echt darstellen,
- nicht freigegebene Browsererweiterungen, private Konten, Bots oder API-Schlüssel nutzen,
- Schutzmechanismen, Systemprompts oder Protokollierung umgehen,
- KI-generierte Software ungeprüft produktiv setzen,
- Stimmen, Bilder oder Identitäten täuschend imitieren oder unzulässige Überwachung durchführen.
¶ 11. Anbieter-, Cloud- und Vertragsprüfung
Die Anbieterprüfung umfasst mindestens:
| Prüffeld | Leitfragen |
|---|---|
| Rollen und Leistung | Welche Funktion wird vertraglich geschuldet, und wer entscheidet über Zwecke und Mittel? |
| Datenverwendung | Werden Eingaben, Ausgaben, Feedback oder Metadaten gespeichert, trainiert, geprüft oder zur Produktverbesserung genutzt? |
| Standorte und Zugriff | Wo erfolgen Verarbeitung, Support und Unterauftragsverarbeitung? Welche Transfers entstehen? |
| Sicherheit | Wie werden Mandanten, Identitäten, Administrationszugriffe, Verschlüsselung, Protokolle und Schwachstellen geschützt? |
| Modelländerungen | Wie werden neue Modelle, Funktionen, Plugins, Trainingsstände und Nutzungsbedingungen angekündigt? |
| Nachweise | Welche Prüfberichte, Zertifikate, Penetrationstests, Sicherheitsinformationen und Vorfallprozesse sind verfügbar? |
| Löschung und Exit | Wie werden Eingaben, Ausgaben, Protokolle, Embeddings, Vektordatenbanken, Backups und Konten gelöscht oder exportiert? |
| Rechte | Sind Audit-, Informations-, Weisungs-, Widerspruchs-, Sperr-, Kündigungs- und Unterstützungsrechte ausreichend? |
Werbeaussagen wie „kein Training“, „Enterprise Security“ oder „EU Hosting“ werden nicht ungeprüft übernommen. Vertrag, Einstellungen, technische Architektur und tatsächliche Datenflüsse müssen zusammenpassen.
¶ 12. Technische Sicherheitsmaßnahmen
¶ 12.1 Generative KI und RAG
- Zugriffsrechte werden bereits vor dem Abruf aus Wissensquellen durchgesetzt; ein Systemprompt ersetzt keine Berechtigungskontrolle.
- Dokumente und Webinhalte werden als potenziell manipulierbare Eingaben behandelt. Prompt Injection kann auch indirekt über Dateien, Webseiten oder E-Mails erfolgen.
- Systemprompts, Guardrails und Filter gelten nicht als alleinige Sicherheitsgrenze.
- Quellen, Dokumentversion und Berechtigungskontext werden mit der Ausgabe nachvollziehbar verknüpft.
- Vektordatenbanken, Embeddings, Caches, Gesprächsverläufe und Protokolle werden klassifiziert und geschützt.
- Automatische Werkzeugaufrufe, Schreibzugriffe, E-Mail-Versand oder Löschaktionen benötigen enge Berechtigungen und zusätzliche Freigabeschritte.
¶ 12.2 Entwicklung und Schnittstellen
- API-Schlüssel und Tokens werden zentral verwaltet, begrenzt, rotiert und nicht in Code oder Promptvorlagen gespeichert.
- Ein- und Ausgaben werden validiert; kritische Aktionen verwenden feste Geschäftsregeln statt freie Textausgaben.
- Modell-, Prompt-, Daten-, Abhängigkeits- und Konfigurationsversionen bleiben nachvollziehbar.
- Trainings- und Testdaten werden auf Herkunft, Zulässigkeit, Qualität, Manipulation und ungewollte Geheimnisse geprüft.
- Tests umfassen Fehlanweisungen, Jailbreaking, direkte und indirekte Prompt Injection, Datenabfluss, Halluzination, Bias, Ausfall und Kostenmissbrauch.
- Protokollierung wahrt Vertraulichkeit und Datenschutz; sensible Prompts werden nicht unkontrolliert in Monitoringwerkzeuge kopiert.
- Die Anwendung muss bei unsicherem Modellverhalten in einen sicheren Zustand wechseln können.
¶ 13. Ausgaben, menschliche Aufsicht und Qualitätsprüfung
Menschliche Kontrolle ist nur wirksam, wenn die prüfende Person:
- fachlich und hinsichtlich der KI-Risiken kompetent ist,
- ausreichend Zeit und relevante Ausgangsinformationen besitzt,
- Unsicherheit und Grenzen des Systems erkennen kann,
- Quellen und wesentliche Tatsachen prüfen darf,
- nicht durch Oberfläche, Ziele oder Arbeitsdruck zum Bestätigen gedrängt wird,
- das Ergebnis ändern, zurückweisen oder eskalieren kann,
- für besonders folgenreiche Fälle eine zweite Prüfung auslösen kann.
| Ausgaberisiko | Mindestkontrolle |
|---|---|
| sachlich falsche Aussage | Abgleich mit autoritativer Quelle oder freigegebenem Fachwissen |
| erfundene Quelle oder Zitat | Originalquelle öffnen und Inhalt, Autor, Datum sowie Fundstelle prüfen |
| fehlerhafter Code | Review, Sicherheitsanalyse, Tests und kontrollierter Build |
| diskriminierende Bewertung | geeignete Testfälle, Gruppenvergleich, Ursachenanalyse und Korrekturweg |
| unzulässige Offenlegung | Ausgabe stoppen, Incident prüfen, Datenquelle und Zugriffsmodell untersuchen |
| veraltete Information | Wissensstand, Abrufdatum und Gültigkeitsbereich kenntlich machen |
| erhebliche Entscheidung | qualifizierte menschliche Entscheidung mit dokumentierter Abweichungsbefugnis |
¶ 14. EU-KI-Verordnung – organisatorische Einordnung
Die Organisation dokumentiert ihre tatsächliche Rolle und den konkreten Anwendungsfall. Die Bezeichnung als „Kunde“ oder „Nutzer“ genügt nicht, wenn das Unternehmen ein System wesentlich verändert, unter eigenem Namen bereitstellt oder für andere entwickelt.
| Prüfschritt | Ergebnis im Register |
|---|---|
| Fällt die Lösung unter die Definition eines KI-Systems? | begründete Einordnung und Quelle |
| Welche Rolle nimmt die Organisation ein? | Anbieter, Betreiber/Deployer, Importeur, Händler oder mehrere Rollen |
| Liegt eine verbotene Praxis vor? | Ja/Nein mit dokumentierter Prüfung |
| Handelt es sich um ein Hochrisiko-KI-System oder eine eingebettete Hochrisikofunktion? | Kategorie, Begründung und anwendbarer Zeitpunkt |
| Gelten Transparenzpflichten oder Kennzeichnungspflichten? | erforderliche Information und Verantwortlichkeit |
| Wird ein allgemeines KI-Modell bereitgestellt oder wesentlich verändert? | gesonderte GPAI-Rollen- und Pflichtenprüfung |
| Welche KI-Kompetenz benötigen beteiligte Personen? | rollen- und risikobezogener Schulungsplan |
Rechtsstand-Hinweis: Nach den offiziellen Informationen der Europäischen Kommission gelten Verbote und Anforderungen an KI-Kompetenz seit 2. Februar 2025 sowie Governance- und GPAI-Regeln seit 2. August 2025. Weitere Regelungen sind seit August 2026 anwendbar; für Hochrisiko-KI wurden durch den AI Omnibus Übergangsfristen verändert. Vor jeder Freigabe werden deshalb die aktuelle konsolidierte Verordnung, Übergangsregelungen und Behördenhinweise erneut geprüft. Diese Seite ist keine Rechtsberatung.
¶ 15. Datenschutz und Beschäftigtenbezug
Sobald personenbezogene Daten verarbeitet oder Personen bewertet werden, wird die DSGVO-Seite zu KI und automatisierter Verarbeitung angewendet. Zu klären sind insbesondere Zweck, Rechtsgrundlage, Datenminimierung, Transparenz, Betroffenenrechte, Auftragsverarbeitung, Drittlandtransfer, Datenschutz-Folgenabschätzung und Artikel 22 DSGVO.
Im Beschäftigungskontext sind zusätzlich § 26 BDSG, mögliche besondere Kategorien, Überwachungswirkungen, Freiwilligkeit, Leistungs- und Verhaltenskontrolle sowie Beteiligungsrechte zu prüfen. Ein KI-gestütztes Ranking oder eine scheinbar unverbindliche Empfehlung kann faktisch entscheidungsbestimmend sein.
¶ 16. KI-Kompetenz, Schulung und Awareness
Die Schulung richtet sich nach Rolle, Vorwissen, System und Risiko. Eine allgemeine Präsentation für alle Beschäftigten reicht für kritische Anwendungen nicht aus.
| Zielgruppe | Mindestinhalte |
|---|---|
| alle Beschäftigten | zugelassene Werkzeuge, Eingaberegeln, Halluzinationen, Meldeweg, Social Engineering und Deepfakes |
| Fachnutzende | Grenzen des Anwendungsfalls, Ergebnisprüfung, Kennzeichnung, Datenschutz und Eskalation |
| Owner und Führungskräfte | Freigabeverantwortung, Risikoklasse, menschliche Aufsicht, Kennzahlen und Restrisiken |
| IT und Entwicklung | Prompt Injection, RAG-Rechte, APIs, Modell- und Datenrisiken, Tests, Logging und sichere Änderungen |
| Einkauf/Datenschutz/Recht | Anbieterrollen, Verträge, Transfers, EU-KI-Verordnung, DSFA und Nachweise |
| Incident- und BCM-Rollen | KI-bezogene Vorfälle, Deepfakes, Ausfall, Anbieterabhängigkeit und sichere Ersatzverfahren |
Schulungsnachweise belegen Teilnahme und Inhalt, aber nicht automatisch sichere Anwendung. Wirksamkeit wird unter anderem durch Fallübungen, Stichproben, Fehlermeldungen und korrektes Erkennen unzulässiger Eingaben bewertet.
¶ 17. Betrieb, Überwachung und Änderungen
Im Betrieb werden mindestens Verfügbarkeit, Fehlerraten, kritische Falschausgaben, Sicherheitsereignisse, unzulässige Eingaben, Kosten- und Mengenabweichungen, Modelländerungen, Zugriffsverletzungen und Beschwerden überwacht.
Eine erneute Prüfung wird unter anderem ausgelöst durch:
- neuen Zweck oder neue Nutzergruppe,
- zusätzliche Datenklasse oder Wissensquelle,
- anderes Modell, neue Version oder Fine-Tuning,
- aktiviertes Plugin, Werkzeug, Browserzugriff oder Schreibrecht,
- Änderung von Hosting, Unterauftragnehmern, Vertrag oder Trainingseinstellungen,
- Automatisierung einer bisher menschlich getroffenen Entscheidung,
- erhebliche Fehler, Vorfälle, Beschwerden oder neue Bedrohungsinformationen,
- geänderte rechtliche, Kunden-, TISAX- oder Branchenanforderungen.
¶ 18. KI-bezogene Sicherheitsvorfälle
Unverzüglich zu melden sind beispielsweise:
- versehentliche Eingabe geschützter Informationen,
- Ausgabe fremder oder unberechtigt zugänglicher Daten,
- erfolgreiche Prompt Injection oder Umgehung von Schutzregeln,
- manipulierte Wissensquelle, Trainingsdaten oder Modellartefakte,
- kritische Halluzination oder fehlerhafte Entscheidung mit möglichem Schaden,
- nicht freigegebene KI-Nutzung oder Kontoübernahme,
- Deepfake, Identitätsimitation oder KI-gestützter Betrugsversuch,
- unerwartete Anbieter-, Modell- oder Datenflussänderung.
Incident Response, Datenschutzverletzungsprüfung, Lieferanteneskalation und gegebenenfalls Meldungen nach KI-, NIS2-, Kunden- oder Vertragsanforderungen werden getrennt geprüft, aber koordiniert gesteuert.
¶ 19. Kontinuität, Exit und Beendigung
Für geschäftskritische KI-Anwendungen werden manueller Mindestbetrieb, alternative Verfahren, Datenexport, Wissensquellen, Prompt- und Konfigurationsdokumentation, Anbieterwechsel und geordnete Abschaltung geplant. Die Organisation darf nicht davon abhängig sein, dass ein einzelnes Modell jederzeit verfügbar, unverändert oder preislich tragbar bleibt.
Bei Beendigung werden Konten, Schlüssel, Schnittstellen, Plugins, Berechtigungen, Datenbestände, Embeddings, Protokolle und Verträge kontrolliert behandelt. Gesetzliche Aufbewahrung und Nachweispflichten bleiben erhalten.
¶ 20. Nachweise und geschützte Ablage
| Nachweis | Mindestinhalt | Öffentliche Wiki-Darstellung |
|---|---|---|
| KI-Anwendungsregister | reale Systeme, Zwecke, Rollen, Daten und Status | nur Struktur oder fiktives Beispiel |
| Freigabeakte | Prüfungen, Auflagen, Entscheidung und Restrisiko | Metadaten und Status |
| Anbieterakte | Vertrag, TOM, Unterauftragnehmer, Auditnachweise und Exit | nicht öffentlich |
| Risiko-/DSFA-Unterlagen | Bedrohungen, Auswirkungen, Bewertungen und Maßnahmen | Methodik und anonymisierte Beispiele |
| Testbericht | Testfälle, Versionen, Ergebnisse, Fehler und Abnahme | aggregierter Status |
| Schulungsnachweis | Zielgruppe, Inhalt, Teilnahme und Wirksamkeit | Nachweisstatus |
| Änderungsprotokoll | Modell, Prompt, Daten, Konfiguration und Freigabe | Versionsstatus |
| Incident-Akte | Eingaben, Ausgaben, Zeitlinie, Schäden und Maßnahmen | nicht öffentlich |
¶ 21. Kennzahlen und Wirksamkeitsprüfung
Sinnvolle Kennzahlen sind beispielsweise:
- Anteil registrierter gegenüber festgestellten unbekannten KI-Anwendungen,
- Anteil fristgerecht geprüfter und überprüfter Anwendungen,
- offene kritische Auflagen und überfällige Maßnahmen,
- Mitarbeitende mit erforderlicher rollenbezogener KI-Schulung,
- kritische Testfehler, Vorfälle und Wiederholungsbefunde,
- Zeit von der Bedarfsmeldung bis zur begründeten Freigabeentscheidung,
- Anwendungen ohne getesteten Exit oder manuellen Mindestbetrieb,
- dokumentierte menschliche Korrekturen und Eskalationen.
Eine hohe Nutzungsquote, Zahl erzeugter Texte oder Zeitersparnis belegt weder Sicherheit noch Qualität. Wirksamkeit setzt voraus, dass Risiken tatsächlich erkannt, Kontrollen angewendet und Fehler rechtzeitig verhindert oder begrenzt werden.
¶ 22. Schnellprüfung für neue KI-Anwendungen
Zwölf Fragen vor der ersten Nutzung anzeigen
- Welcher konkrete Geschäftszweck wird verfolgt?
- Wer ist fachlicher Owner und wer darf freigeben?
- Welche Eingaben, Ausgaben, Wissensquellen und Protokolle entstehen?
- Welche Schutzklasse und welche personenbezogenen Daten sind betroffen?
- Wohin fließen die Daten, wer kann zugreifen und werden sie zum Training verwendet?
- Welche Rolle nimmt das Unternehmen nach der EU-KI-Verordnung ein?
- Gibt es verbotene, hochriskante oder transparenzpflichtige Funktionen?
- Welche fachlichen, Sicherheits-, Bias- und Manipulationstests sind erforderlich?
- Wie prüft ein kompetenter Mensch die Ausgabe und kann er abweichen?
- Welche Anbieter-, Vertrags-, Transfer- und Exit-Risiken bestehen?
- Wie werden Änderungen, Vorfälle, Löschung und Betroffenenrechte beherrscht?
- Welche Nachweise und Reviewtermine sind vor Freigabe erforderlich?
Bleibt eine dieser Fragen für einen relevanten Risikobereich offen, ist der Anwendungsfall noch nicht produktiv freigabefähig.
¶ 23. Qualitätssicherung vor Freigabe
| Prüffrage | Status dieses Musters |
|---|---|
| Sind alle real eingesetzten und geplanten KI-Anwendungen registriert? | Nein |
| Sind Owner, Rechtsrollen, Datenflüsse und Schutzklassen bestätigt? | Nein |
| Sind verbotene und hochriskante Nutzungen geprüft? | Nein |
| Sind Anbieter, Verträge, Datenstandorte und Trainingseinstellungen geprüft? | Nein |
| Sind Tests, menschliche Aufsicht und Abbruchkriterien freigegeben? | Nein |
| Sind KI-Kompetenzmaßnahmen rollenbezogen durchgeführt und nachgewiesen? | Nein |
| Sind Monitoring, Incident- und Exit-Verfahren getestet? | Nein |
| Liegen fachliche Prüfung und formale Geschäftsführungsfreigabe vor? | Nein |
¶ 24. Offene Punkte vor Freigabe
- KI-Geltungsbereich, Governance und Freigabebefugnisse festlegen.
- vorhandene KI-Funktionen und Schatten-KI erfassen.
- Register, Prüfformular, Freigabeampel und geschützte Ablage operationalisieren.
- Informationsklassen und zulässige KI-Eingaben konkret beschließen.
- Rechtsrollen und aktuelle Anwendung der EU-KI-Verordnung prüfen.
- bestehende Anbieter, Verträge, Konten, Plugins und Datenflüsse bewerten.
- priorisierte Anwendungsfälle risikobasiert testen und begrenzt freigeben.
- rollenbezogenes KI-Kompetenzprogramm durchführen.
- technische Schutzmaßnahmen, Monitoring und Meldewege testen.
- Exit-, Notbetriebs- und Löschverfahren für kritische Anwendungen festlegen.
- Kunden-, TISAX-, Datenschutz- und Beschäftigtenanforderungen abgleichen.
- fachliche Prüfung und formale Freigabe dokumentieren.
¶ 25. Mitgeltende Dokumente
- Informationssicherheitspolitik
- Methodik Risikobewertung
- Risikoregister
- Rechts- und Vertragskataster
- Asset-Inventar
- Informationsklassifizierung
- Zulässige Nutzung von Assets
- Personal und Schulungen
- Lieferanten und Dienstleister
- Informationssicherheit im Projektmanagement
- Sichere Entwicklung
- Mobile Arbeit und Cloud
- Protokollierung und Überwachung
- Meldeweg für Sicherheitsvorfälle
- KI und automatisierte Verarbeitung
¶ 26. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 10.08.2026 | Musterregelung für Inventarisierung, Risikoeinstufung, Freigabe, sichere Nutzung, technische Kontrollen, EU-KI-Verordnung, KI-Kompetenz, Überwachung, Vorfälle und Exit erstellt | KI-Governance / ISMS | Ausstehend | – |
¶ 27. Offizielle und fachliche Quellen
- EUR-Lex – Verordnung (EU) 2024/1689 über künstliche Intelligenz
- Europäische Kommission – AI Act und aktueller Anwendungszeitplan
- Europäische Kommission – Fragen und Antworten zu KI-Kompetenz
- ISO – ISO/IEC 42001:2023 AI management systems
- ISO – ISO/IEC 27001 Informationssicherheitsmanagementsysteme
- BSI – Generative KI-Modelle: Chancen und Risiken für Industrie und Behörden
- BSI – Kriterienkatalog für den sicheren Einsatz von KI-Modellen
- Datenschutzkonferenz – Orientierungshilfe KI und Datenschutz
Maßgeblich bleiben die aktuellen konsolidierten Rechtsquellen, Normfassungen, Behördenhinweise, Verträge, Kundenanforderungen und organisationsbezogenen Freigaben. Die Regelung ersetzt keine fallbezogene Rechtsberatung, Systemprüfung oder Konformitätsbewertung.
Seite 1 von 1 · ISMS-MA-04-14 · Version 0.1