KI-InventarWissen, welche KI läuft.
Ohne Inventar keine Steuerung. Diese Seite zeigt, was ins KI-Inventar gehört, welche Pflichtfelder es braucht, wie man Systeme einschliesslich Schatten-KI findet und wie man sie nach AI Act und internem Risiko einstuft.
Rechtsstand: 10. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar.
Erst zählen,
dann steuern.
Fast jede KI-Pflicht hängt an einem einzelnen System: Rolle, Risikoklasse, Aufsicht, Transparenz. Wer nicht weiss, welche Systeme im Einsatz sind, kann keine dieser Pflichten zuordnen. Das NIST AI RMF sieht dafür in GOVERN 1.6 Mechanismen zur Inventarisierung von KI-Systemen vor, ausgestattet nach Risikoprioritäten.
Der AI Act kennt keine allgemeine Inventarpflicht. Er setzt aber voraus, dass Anbieter und Betreiber ihre Systeme einstufen können, etwa für die Dokumentation nach Art. 6 Abs. 4. KI-Anwendungen mit Personendaten erscheinen zudem im Verzeichnis der Bearbeitungstätigkeiten nach Art. 12 DSG (Schweiz) bzw. Art. 30 DSGVO (Deutschland), soweit ein Verzeichnis zu führen ist.
Das KI-Inventar ist keine separate Tabelle, sondern eine Erweiterung des bestehenden Asset-Inventars im ISMS-Prozess 05 Inventar. Definition eher breit wählen: Im Zweifel erfassen. Die Einstufung entscheidet anschliessend über die Prüftiefe, nicht die Aufnahme ins Inventar.
Was ins
Inventar gehört.
| Objekt | Beispiele | Warum erfassen |
|---|---|---|
| Eigene KI-Systeme | Selbst entwickelte Modelle, RAG-Anwendungen, interne Assistenten | Organisation kann Anbieter im Sinne des AI Act sein |
| Eingekaufte KI-Systeme | Fachanwendungen mit KI-Kern, Scoring, Dokumentenerkennung | Betreiberpflichten, Lieferantenrisiko |
| Eingebettete KI in SaaS | KI-Funktionen in Bürosoftware, CRM, HR-Systemen, Ticketing | Oft per Update aktiviert, ohne Beschaffungsvorgang |
| Nutzung generativer KI | Chat-Assistenten, Programmierassistenten, Browser-Erweiterungen | Datenabfluss, Schatten-KI |
| Agenten und Werkzeuge | Agenten mit Schreibrechten, angebundene Tools und MCP-Server | Eigene Identitäten und Berechtigungen, Handlungsfähigkeit |
| Modelle | Basismodelle, feinabgestimmte Modelle, Open-Weight-Modelle, Modellversionen | Herkunft, Lizenz, Austausch ohne Prüfung |
| Datensätze | Trainings- und Testdaten, Wissensbasen für RAG, Vektordatenbanken | Datenklassifizierung, Poisoning, Datenschutz |
| Systemprompts und Konfiguration | Systemanweisungen, Guardrail-Regeln, Tool-Freigaben | Verhalten des Systems hängt direkt davon ab |
| Plattformen | MLOps- und Experimentplattformen, Modell-Registries, GPU-Umgebungen | Angriffsfläche mit Zugriff auf Modelle und Daten |
Praxisbeispiel einer exponierten MLOps-Plattform: SIGNAL-Beitrag SIGNAL: kritische Schwachstelle einer MLOps-Plattform.
Minimal, aber
vollständig.
Die Felder sind an eine CMDB anschlussfähig. Was dort schon gepflegt wird (Betriebsverantwortung, Standort, Lieferant), wird verknüpft und nicht doppelt erfasst.
| Feld | Zweck | Quelle |
|---|---|---|
| ID und Name | Eindeutige Referenz in Risiko-, Change- und Vorfallprozessen | Inventar/CMDB |
| AI-Owner | Verantwortung über den Lebenszyklus | Fachbereich |
| Zweck und Einsatzkontext | Grundlage für AI-Act-Einstufung und Risiko | Antrag G0 |
| Systemtyp | Eigen, eingekauft, eingebettet, GenAI-Nutzung, Agent | Antrag, Beschaffung |
| Rolle nach AI Act | Anbieter, Betreiber, Einführer, Händler oder nicht anwendbar | Compliance |
| AI-Act-Risikoklasse | Verboten, hochriskant, Transparenzpflicht, übrige | Compliance |
| Interne Kritikalität | Steuert Prüftiefe und Gate-Entscheid | Risikobeurteilung |
| Datenarten und Klassifizierung | Ein- und Ausgabedaten, Personendaten, Geheimhaltungsstufe | Datenklassifizierung |
| Modell und Version | Nachvollziehbarkeit bei Modellwechsel | Technik, Lieferant |
| Lieferant und Vertrag | Verknüpfung zum Lieferantenregister | Einkauf |
| Hosting und Datenstandort | On-Premises, Cloud, Region, Datenweitergabe | Architektur |
| Autonomiegrad | Assistenz, Empfehlung, automatischer Entscheid, Handlung über Werkzeuge | Antrag, Architektur |
| Betroffene Personen | Kundschaft, Mitarbeitende, Dritte | Fachbereich |
| Abhängige Geschäftsprozesse | Kritikalität für den Betrieb | BIA, CMDB |
| Status und Gate | Antrag, Pilot, produktiv, stillgelegt; letzter Gate-Entscheid | Freigabeprozess |
| Nächste Rezertifizierung | Termin für die Bestätigung durch den Owner | Inventar |
Fünf Wege,
die sich ergänzen.
| Methode | Findet | Grenzen | Werkzeugklasse |
|---|---|---|---|
| Umfrage bei Fachbereichen | Zweck, Nutzen, inoffizielle Nutzung | Unvollständig, abhängig von Bewusstsein | – |
| Beschaffung und Verträge | Eingekaufte Systeme, KI-Funktionen in SaaS, Datenverarbeitungsverträge | Erfasst keine kostenlose Nutzung | GRC-Plattformen |
| CASB- und SSE-Logs | Aufrufe von KI-Diensten im Web, Uploads, Browser-Erweiterungen | Nur Verkehr über die Kontrollpunkte | SASE und SSE |
| Code- und Repository-Scan | KI-Bibliotheken, API-Aufrufe, API-Schlüssel, Modelldateien | Nur eigene Entwicklung | Secrets Scanning, SBOM und VEX |
| Cloud-Inventar | Verwaltete KI-Dienste, Modell-Endpunkte, GPU-Ressourcen, Vektordatenbanken | Nur bekannte Cloud-Konten | CAASM, CSPM |
Ergänzend: OAuth-Freigaben an KI-Apps in SaaS-Plattformen über SSPM prüfen. Agenten mit eigenen Identitäten erscheinen im IAM.
Überführen
statt nur sperren.
Schatten-KI ist KI-Nutzung ohne Freigabe. Sie entsteht meist, weil ein Bedarf besteht und kein freigegebenes Werkzeug verfügbar ist. Reines Sperren verlagert die Nutzung auf private Geräte.
Einordnung zu Hochrisiko-Fristen, Art. 6 Abs. 4 und Schatten-KI: SIGNAL-Beitrag AI Act Hochrisiko-Frist: 2. August 2026 vs. 2. Dezember 2027 erklärt.
- Freigegebene Alternative für häufige Fälle bereitstellen, bevor gesperrt wird.
- Erkannte Nutzung ohne Sanktion melden lassen und ins Inventar überführen.
- Sperren nach Kategorie dort, wo Datenabfluss nicht tragbar ist; Upload-Kontrolle für vertrauliche Daten.
- Neue KI-Funktionen in bestehender SaaS beim Release-Review prüfen.
- Regel in der KI-Nutzungsrichtlinie festhalten.
Risikoklasse
nach AI Act.
Die rechtliche Einstufung ist EU-Recht. Für Schweizer Unternehmen ist sie nötig, wenn sie KI-Systeme in der EU in Verkehr bringen oder der Output in der EU verwendet wird (Art. 2 Abs. 1 AI Act). Ohne EU-Bezug lautet der Eintrag «nicht anwendbar», mit Begründung.
| Klasse | Grundlage | Folge im Inventar |
|---|---|---|
| Verbotene Praktik | Art. 5 | Nicht freigeben, Einsatz beenden |
| Hochrisiko (Produkt) | Art. 6 Abs. 1 mit Anhang I | Volle Prüftiefe, Anbieter- oder Betreiberpflichten zuordnen |
| Hochrisiko (Einsatzbereich) | Art. 6 Abs. 2 mit Anhang III | Volle Prüftiefe; Betreiberpflichten nach Art. 26 |
| Anhang III, aber nicht hochriskant | Art. 6 Abs. 3 | Anbieter dokumentiert die Bewertung vor Inverkehrbringen (Art. 6 Abs. 4) und unterliegt der Registrierung nach Art. 49 Abs. 2 |
| Transparenzpflicht | Art. 50 | Kennzeichnung und Information sicherstellen |
| KI-Modell mit allgemeinem Verwendungszweck | Art. 51 ff. | Nur relevant, wenn die Organisation selbst ein solches Modell anbietet |
| Übrige KI-Systeme | keine besonderen Pflichten ausser Art. 4 | Interne Kritikalität entscheidet |
Anwendungsdaten der Pflichten: Fristenkalender DCH. Rechtliche Einordnung: Regulierung DCH.
Interne
Kritikalität.
Die interne Einstufung gilt für alle Systeme, auch ohne AI-Act-Bezug. Sie nutzt die bestehende Schutzbedarfsmethode des ISMS und ergänzt KI-spezifische Kriterien.
- Schutzbedarf: Vertraulichkeit, Integrität, Verfügbarkeit der verarbeiteten Daten.
- Auswirkung: Wie stark sind Kundschaft, Mitarbeitende oder Dritte vom Ergebnis betroffen?
- Autonomie: Assistenz mit Prüfung durch Menschen oder Handlung ohne Prüfung?
- Prozessbedeutung: Unterstützt das System eine kritische Funktion oder die Einhaltung von Pflichten?
- Exposition: Intern, für Kundschaft zugänglich oder mit Zugriff auf externe Inhalte (Prompt Injection)?
| Kritikalität | Prüftiefe |
|---|---|
| Niedrig | Gates G0 bis G3 zusammengefasst, Entscheid AI-Owner, Rezertifizierung alle 24 Monate |
| Mittel | Risikobeurteilung, Lieferantenprüfung, Entscheid AI-Owner mit CISO, Rezertifizierung jährlich |
| Hoch | Volle Gates, Tests vor Betrieb, Entscheid KI-Ausschuss, Rezertifizierung jährlich |
| Kritisch | Wie hoch, zusätzlich unabhängige Prüfung und laufende Überwachung |
Die Intervalle sind Vorschläge. Gates und Rollen: Governance und Programm.
Anbieter oder
Betreiber.
Die Rolle wird je System bestimmt, nicht je Organisation. Ein Unternehmen ist oft Betreiber (deployer) vieler eingekaufter Systeme und Anbieter (provider) weniger eigener.
| Situation | Rolle | Grundlage |
|---|---|---|
| System eingekauft und unter eigener Verantwortung genutzt | Betreiber | Art. 3 Nr. 4 |
| System selbst entwickelt und unter eigenem Namen eingesetzt oder angeboten | Anbieter | Art. 3 Nr. 3 |
| System aus Drittstaat erstmals in der EU in Verkehr gebracht | Einführer (importer) | Art. 3 Nr. 6 |
| System weiterverkauft | Händler (distributor) | Art. 3 Nr. 7 |
| Hochrisiko-System mit eigenem Namen versehen oder wesentlich verändert; oder Zweck eines nicht hochriskanten Systems so geändert, dass es hochriskant wird | Wird zum Anbieter | Art. 25 Abs. 1 |
Rezertifizieren
und auslösen.
- Owner bestätigt Eintrag, Einstufung und Zweck im festgelegten Intervall.
- Neue Prüfung bei Modellwechsel, neuem Zweck, neuen Datenarten, neuem Lieferanten oder höherer Autonomie; Auslöser im Prozess 17 Änderungen.
- Abgleich der Discovery-Ergebnisse mit dem Inventar mindestens quartalsweise.
- Stilllegung mit Rückbau von Zugriffen, Schlüsseln und Daten dokumentieren.
Verknüpfen
statt kopieren.
KI-Systeme, Modelle und Datensätze werden als eigene Klassen in der Service-Configuration und CMDB geführt und mit Geschäftsdienst, Lieferant und Datenklasse verknüpft. Für die technische Stückliste eignen sich offene Formate: CycloneDX ML-BOM und das AI-Profil von SPDX 3.0. Beide sind frei verfügbar und lassen sich mit der bestehenden SBOM-Praxis kombinieren.
Schweiz: Die FINMA beurteilt nach Aufsichtsmitteilung 08/2024, Kap. 2.2 (Inventar und Risikoklassifizierung), ob eine ausreichend breite Definition von KI vorliegt sowie Vorhandensein und Vollständigkeit der KI-Inventare und die Risikoklassifizierung der Anwendungen. Sie beobachtete zu eng gefasste Definitionen und uneinheitliche Kriterien zur Wesentlichkeit. Erhöhte Risiken sieht sie tendenziell, wenn KI zur Einhaltung von Aufsichtsrecht oder für kritische Funktionen eingesetzt wird oder Kundschaft oder Mitarbeitende stark betroffen sind (Fussnote 5).
EU: DORA Art. 8 Abs. 1, 4 und 6 verlangt die Identifikation, Klassifizierung und Dokumentation aller IKT-gestützten Geschäftsfunktionen und IKT-Assets und deren laufende Inventarisierung. KI-Systeme sind darin enthalten. KI-Anbieter als IKT-Drittdienstleister gehören in das Informationsregister nach Art. 28 Abs. 3.
Vertiefung: AI Act Framework für Finanzinstitute.
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt bei der Erstinventarisierung und Einstufung von KI-Systemen. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 3, 5, 6, 25, 26, 49, 50, 51, Anhang I und III (EU, 13.06.2024)
- Verordnung (EU) 2026/1744, Digital-Omnibus zur KI (EU, 08.07.2026)
- AI Act, konsolidierte Fassung vom 27.07.2026, Art. 6 Abs. 4 (EUR-Lex, ohne Rechtswirkung)
- NIST AI 100-1, AI Risk Management Framework 1.0, GOVERN 1.6, MAP 4.1 (NIST, 01/2023)
- Bundesgesetz über den Datenschutz (DSG), Art. 12 (Fedlex, SR 235.1)
- Verordnung (EU) 2016/679 (DSGVO), Art. 30 (EU)
- CycloneDX Machine Learning BOM (OWASP CycloneDX, laufend)
- SPDX 3.0.1, AI-Profil (Linux Foundation, 2024)
- FINMA-Aufsichtsmitteilung 08/2024, Kap. 2.2 Inventar und Risikoklassifizierung (FINMA, 18.12.2024)
- Verordnung (EU) 2022/2554 (DORA), Art. 8 und 28 (EU, 14.12.2022)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.