Blog
•
14 Min. Lesezeit
Ein KI-Inventar, das allein auf Selbstauskünften beruht, erfasst zu wenig, denn die Systeme mit dem größten Risiko sind genau die, an deren Meldung niemand denkt: KI-Funktionen in bereits gekaufter Software, Modelle in Diensten von Drittanbietern und Agenten, die auf internen Plattformen entwickelt wurden. Ein brauchbares Inventar kombiniert technische Erkennung mit strukturierter Offenlegung, erfasst je System einen Mindestsatz an Feldern und gleicht beides fortlaufend ab.
Warum bleibt die Abfrage der KI-Nutzung immer unvollständig?
Der Work Trend Index 2024 von Microsoft und LinkedIn, eine Umfrage unter 31.000 Wissensarbeitenden in 31 Ländern, ergab, dass 78 Prozent der KI-Nutzenden eigene KI-Tools zur Arbeit mitbrachten und 52 Prozent derjenigen, die KI bei der Arbeit nutzen, nur ungern zugaben, sie für ihre wichtigsten Aufgaben einzusetzen. Ein Fragebogen an diese Zielgruppe liefert schon konstruktionsbedingt nur eine unvollständige Antwort.
Zurückhaltung ist nur eine Fehlerquelle. Jeder der folgenden Fälle entzieht sich einer Umfrage aus einem anderen Grund.
KI-Funktionen in SaaS, die das Unternehmen bereits nutzt, kommen mit einem Versionshinweis, nicht über einen Beschaffungsvorgang. Das CRM hat ein Lead-Scoring erhalten, und niemand bezeichnet sein CRM auf Nachfrage als KI-System.
Einzelabonnements über Firmenkreditkarten werden als Software verbucht, liegen unter jeder Beschaffungsschwelle und werden nur gemeldet, wenn der Karteninhaber eine monatliche Abbuchung von 20 US-Dollar mit Governance in Verbindung bringt.
Modelle in Diensten von Drittanbietern bleiben für den Geschäftsbereich, der den Dienst eingekauft hat, unsichtbar. Ein Outsourcing-Dienstleister für die Triage von Schadenmeldungen kann im Auftrag der Organisation KI einsetzen, und nach Artikel 3 Nummer 4 des EU AI Act ist die Stelle, die „ein KI-System in eigener Verantwortung verwendet“, der Betreiber, unabhängig davon, wer es entwickelt hat.
Agenten auf internen Automatisierungsplattformen werden von ihren Entwicklern als Workflows beschrieben. Ein Ablauf, der ein Modell aufruft und anschließend in ein führendes System schreibt, ist ein Agent, und keine Umfrage zu KI-Tools wird ihn erfassen.
Notebooks, die in die Produktion übernommen wurden, liefern Scores, die ein nachgelagerter Prozess weiterverarbeitet. Niemand hat sie in Auftrag gegeben, also ist niemand für sie verantwortlich, also meldet sie niemand.
Allen Fällen gemeinsam ist: Die Person, die ein System melden könnte, stuft es entweder nicht als KI ein, ist nicht dafür verantwortlich oder hat einen Grund, es zu verschweigen. Für alles andere braucht es ein Signal, das nicht von einer Person abhängt. Der Leitfaden von Enzai zur Erkennung und Governance von Schatten-KI erläutert, worin sich Schatten-KI von Schatten-IT unterscheidet; in diesem Beitrag geht es darum, sie zu finden.
Welche Erkennungsmethoden finden nicht freigegebene KI, und was übersieht jede davon?
Keine einzelne Methode deckt alle oben genannten Fehlerquellen ab. Die entscheidende Frage ist bei jeder Methode nicht, was sie findet, sondern was sie nicht sehen kann.
Methode | Was sie findet | Was sie übersieht |
|---|---|---|
Analyse des Netzwerk- und API-Traffics (DNS-, Proxy-, Egress-Logs) | Direkte Aufrufe aus dem Unternehmensnetz an bekannte Endpunkte von Modellanbietern und KI-SaaS; Volumen und Häufigkeit je Quelle | Möglicherweise serverseitige Aufrufe, die ein Drittanbieter in Ihrem Auftrag tätigt; Traffic auf privaten Geräten, in Heimnetzen und über mobile Daten; manche Tools übersehen zudem KI, die in eine bereits zugelassene SaaS-Domain eingebettet ist |
Prüfung von SSO- und OAuth-Berechtigungen (Logs des Identity Providers) | Mit Unternehmenskonten verbundene KI-Apps, die erteilten Berechtigungen (E-Mail, Dateien, Kalender) und wer sie erteilt hat | Nutzung über private Konten ohne Unternehmensanmeldung; interne Entwicklungen, die nie mit dem Identity Provider in Berührung kommen; das Modell hinter einer App, die sich unter anderem Namen authentifiziert hat |
Spesen- und Beschaffungsdaten | Bezahlte Einzelabonnements, Abteilungslizenzen, Vertragsverlängerungen, bei denen der Drittanbieter inzwischen KI ergänzt hat | Kostenlose Tarife; KI, die nach dem Kauf zu einem Produkt hinzukam; Drittanbieter, die ihren Dienst auf der Rechnung nicht als KI ausweisen |
Scans von Cloud-Umgebungen (Konten, ML-Plattformen, Modell-Endpunkte) | Bereitgestellte Modell-Endpunkte, Trainingsjobs, Vektordatenbanken, Servicekonten mit Schlüsseln von Modellanbietern, geplante Notebooks | Alles außerhalb der von Ihnen erfassten Cloud-Konten; in SaaS gehostete KI; abteilungseigene On-Premises-Server |
Code- und Repository-Scans | Importe von SDKs der Modellanbieter, eingebettete API-Schlüssel, Abhängigkeiten von Agenten-Frameworks, in Repositorys eingecheckte Prompt-Dateien | Low-Code- und No-Code-Automatisierungsplattformen; alles, was nicht in einem gescannten Repository liegt; Laufzeitkonfiguration, die bestimmt, ob der Code tatsächlich aktiv ist |
CASB und SaaS-Sicherheitstools | Genutzte SaaS-Anwendungen, einschließlich nicht freigegebener KI-Apps, mit Aktivität und Datenübertragungsvolumen je Nutzer | KI-Funktionen in freigegebenen Apps; interne Agenten; den Governance-Kontext (Verantwortliche, Zweck, betroffene Entscheidungen), für dessen Erfassung ein Sicherheitstool nicht ausgelegt ist |
Strukturierte Selbstauskunft | Zweck, Verantwortliche, genutzte Daten und betroffene Entscheidungen: die Felder, die kein technisches Signal liefern kann | Alles, was die befragte Person nicht als KI erkennt, nicht verantwortet oder lieber nicht nennt |
Die blinden Flecken unterscheiden sich. Ein System, das zwei Signale erfassen, ist daher ein bestätigter Eintrag, ein System, das nur ein Signal erfasst, ein Hinweis, der zu prüfen ist. Die Selbstauskunft ist dann nicht mehr das Inventar, sondern der Schritt zur Anreicherung: Technische Signale belegen, dass ein System existiert, und die verantwortliche Person ergänzt, was nur ein Mensch wissen kann. KI auf Anbieterseite, bei der das Modell in der Umgebung des Lieferanten läuft, ist die einzige Kategorie, die kein technisches Signal erreicht. Fragebögen für Drittanbieter und Vertragsprüfungen bleiben deshalb auf der Liste.
Wie erkennen Sie gezielt KI-Agenten?
Agenten hinterlassen andere Spuren als Tools. Eine Person, die einen KI-Assistenten nutzt, erscheint als Domain im Proxy-Log oder als App beim Identity Provider. Ein Agent erscheint als nicht-menschliche Identität: ein Servicekonto mit dem API-Schlüssel eines Modellanbieters, eine Tool-Registrierung in einem Agenten-Framework, ein geplanter Job, der ein Modell aufruft und danach etwas anderes.
Die Signale sind die Liste nicht-menschlicher Identitäten beim Identity Provider samt der Ressourcen, auf die sie zugreifen dürfen, das Verzeichnis der auf Modellanbieter beschränkten Secrets in Cloud-Konten, die Connector-Logs von Automatisierungsplattformen und Repository-Scans nach Agenten-Frameworks. Das verräterische Zeichen ist ein Modellaufruf, auf dessen Ausgabe eine Aktion folgt, ohne dass ein Mensch dazwischensteht.
Agenten delegieren außerdem an andere Agenten. Sobald eine Organisation mehr als eine Handvoll davon hat, entsteht ein Agenten-Mesh, in dem Agenten einander über gemeinsame Infrastruktur finden und sich Arbeit übergeben. Das Mesh zu erkennen heißt abzubilden, welche nicht-menschlichen Identitäten welche anderen aufrufen, sodass ein einziger Eintrag die vorgelagerten Aufrufer und nachgelagerten Ziele eines Agenten zeigt. Die daraus folgenden Kontrollen beschreibt der Leitfaden von Enzai zur Governance für agentische KI.
Wie sieht ein minimaler, brauchbarer Inventareintrag aus?
Die vollständige Feldvorlage mit rund vierzig Feldern finden Sie im Leitfaden zum Aufbau eines KI-Inventars. Hier geht es um die Untergrenze: den kleinsten Eintrag, der noch eine Governance-Entscheidung trägt. Neun Felder bestehen diesen Test.
Feld | Warum es zum Minimum gehört | Beispielwert |
|---|---|---|
Verantwortliche Person | Ohne eine verantwortliche Person lässt sich nichts anderes im Eintrag prüfen oder aktualisieren | Leitung Schadenbearbeitung |
Zweck | Bestimmt, welche regulatorischen Kategorien gelten und ob die Nutzung richtlinienkonform ist | Eingehende Schadenmeldungen nach voraussichtlicher Komplexität vorsortieren |
Betroffene Daten | Personenbezogene Daten, besondere Kategorien personenbezogener Daten, vertrauliche Daten und Kundendaten lösen jeweils unterschiedliche Pflichten aus | Schadenschilderungen, Kennungen von Versicherungsnehmern |
Modell und Version | Nachweise zum Verhalten gelten nur für die getestete Version; Updates des Drittanbieters machen sie ungültig | Vom Drittanbieter gehostetes Basismodell, Version fixiert im März 2026 |
Autonomiegrad | Ob eine Person auf Basis der Ausgabe handelt, sie prüft oder ganz umgangen wird, verändert die erforderlichen Kontrollen | Schlägt die Weiterleitung vor; Schadenregulierer bestätigt |
Betroffene nachgelagerte Entscheidungen | Folgenreiche Entscheidungen über Personen (Kredit, Versicherung, Beschäftigung) bringen unabhängig vom Modell gesetzliche Pflichten mit sich | Zuweisung von Schadenfällen; keine Deckungsentscheidung |
Anwendbare Frameworks | Unter welche Regelwerke und Standards das System fällt, und die Begründung der Einstufung | EU AI Act, Anhang III Nummer 5 Buchstabe c, in Prüfung; ISO/IEC 42001 im Geltungsbereich |
Risikostufe | Die organisationseigene Einstufung, die Prüftiefe und Prüfrhythmus bestimmt | Stufe 2 |
Links zu Nachweisen | Wo Bewertung, Freigabe, Testergebnisse und Dokumentation des Drittanbieters abgelegt sind | Links zum Freigabeeintrag und zum AVV des Drittanbieters |
Jeder Eintrag ist eine belegte Aussage. „Dieses System hat ein begrenztes Risiko“ ist eine Behauptung; dieselbe Aussage mit verantwortlicher Person, Zweck, Datenfeld und Link zur Bewertung ist ein Nachweis. Artikel 26 des EU AI Act zeigt, warum die Felder nicht optional sind: Absatz 2 verlangt menschliche Aufsicht durch kompetente Personen (die Felder für verantwortliche Person und Autonomiegrad), und Absatz 6 verlangt, Protokolle mindestens sechs Monate aufzubewahren (die Felder für Modellversion und Nachweise). Das KI-Inventar von Enzai beruht auf demselben Aufbau: verantwortliche Person, Zweck, Verweise auf Drittanbieter und Modell, Autonomiegrad, Risikostufe, zugeordnete Frameworks und Bewertungsnachweise je Eintrag, die Datensensibilität als Tag.
Welche Vorschriften und Standards verlangen ein KI-Inventar?
Nur wenige Regelwerke verwenden das Wort Inventar. Die meisten begründen jedoch Pflichten, die sich ohne Inventar nicht erfüllen lassen.
Regelwerk | Bestimmung | Was sie voraussetzt |
|---|---|---|
EU AI Act, Artikel 4 (KI-Kompetenz) | Gilt seit dem 2. Februar 2025 gemäß Artikel 113 Buchstabe a. In der durch die Verordnung (EU) 2026/1744 ersetzten Fassung gilt: Anbieter und Betreiber „ergreifen Maßnahmen, um die Entwicklung der KI-Kompetenz ihres Personals und anderer Personen zu unterstützen, die in ihrem Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befasst sind“ | Wissen, welche Mitarbeitenden welche KI-Systeme bedienen |
EU AI Act, Artikel 26 (Pflichten der Betreiber von Hochrisiko-KI-Systemen) | Betriebsanleitung, zugewiesene menschliche Aufsicht, Überwachung, Aufbewahrung der Protokolle für mindestens sechs Monate, Information der Arbeitnehmer. Systeme nach Anhang III ab dem 2. Dezember 2027, Systeme nach Anhang I ab dem 2. August 2028 | Ein Eintrag je Hochrisiko-KI-System mit verantwortlicher Person, Regelung der Aufsicht und Speicherort der Protokolle |
Abschnitt 4.3 (Anwendungsbereich des KI-Managementsystems), 6.1.2 (KI-Risikobewertung) und 6.1.4 (Folgenabschätzung für KI-Systeme); zu den Maßnahmen aus Anhang A, einer normativen Referenz, gehört die Dokumentation der Ressourcen, die jedes KI-System nutzt | Eine vollständige Aufstellung der KI-Systeme innerhalb der Grenzen des Managementsystems | |
NIST AI RMF 1.0, GOVERN 1.6 | „Es bestehen Mechanismen zur Inventarisierung von KI-Systemen, die entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet sind.“ Die Funktion MAP dokumentiert anschließend den beabsichtigten Zweck und Kontext jedes Systems (MAP 1.1) | Ein Inventar als Grundlage für MAP, MEASURE und MANAGE |
OMB M-25-21, 3. April 2025 | Jede Bundesbehörde, mit Ausnahme des Verteidigungsministeriums und der Nachrichtendienste, „muss ihre KI-Anwendungsfälle mindestens jährlich inventarisieren, das Inventar beim OMB einreichen und eine öffentliche Fassung auf der Website der Behörde veröffentlichen“ | Ein Inventar der Anwendungsfälle, in dem der Chief AI Officer die Einstufungen mit hoher Auswirkung nachverfolgt |
Colorado SB 26-189, unterzeichnet am 14. Mai 2026 | Hebt SB 24-205 auf und erlässt es neu. Die Pflichten gelten ab dem 1. Januar 2027: Hinweis am Interaktionspunkt mit einer erfassten Technologie zur automatisierten Entscheidungsfindung, Erläuterung und menschliche Überprüfung nach nachteiligen folgenreichen Entscheidungen, Aufbewahrung von Unterlagen für mindestens drei Jahre. Keine Inventarpflicht | Wissen, welche Systeme folgenreiche Entscheidungen über Verbraucher in Colorado treffen |
Die Nummern der Maßnahmen aus Anhang A der ISO/IEC 42001 sind auf iso.org nicht veröffentlicht und werden hier nicht zitiert. Der Glossareintrag von Enzai zu OMB M-25-21 behandelt das Memorandum der US-Bundesregierung ausführlicher.
Wie bleibt ein KI-Inventar nach der ersten Bestandsaufnahme aktuell?
Ein Inventar veraltet über drei Mechanismen, und für jeden gibt es eine eigene Gegenmaßnahme.
Der erste ist nicht abgeglichene Erkennung. Jedes Signal erzeugt Kandidaten, und wenn diese in einer Tabelle neben dem Inventar liegen, laufen beide innerhalb eines Quartals auseinander. Jeder Kandidat sollte einem bestehenden Eintrag zugeordnet, als Duplikat zusammengeführt oder als neuer Eintrag ohne Verantwortliche angelegt werden, mit einer Frist für die Zuweisung. Die Zahl der Einträge ohne Verantwortliche, die älter als dreißig Tage sind, ist die erste Kennzahl für den Zustand des Inventars.
Der zweite ist der Verlust von Zuständigkeiten. Verantwortliche wechseln die Rolle oder verlassen das Unternehmen. Ist das Feld für die verantwortliche Person ein Freitextname, ist das Inventar an dem Tag veraltet, an dem die Personalabteilung den Austritt bearbeitet. Erst wenn die verantwortliche Person an eine Verzeichnisidentität gekoppelt ist, sodass ein Austritt eine Neuzuweisung auslöst, hat das Feld Aussagekraft.
Der dritte sind Änderungen, die das Inventar nicht bemerkt. Ein Drittanbieter aktualisiert das Basismodell hinter einer eingebetteten Funktion; ein Agent erhält ein neues Tool; eine OAuth-Berechtigung erhält einen erweiterten Geltungsbereich. Der bestehende Leitfaden nennt die geschäftlichen Auslöser; die technischen Auslöser sind die Signale vom ersten Tag, fortlaufend ausgeführt und mit dem letzten Stand abgeglichen. Die zweite Kennzahl ist die Zeit vom ersten Auftreten eines Signals bis zum Bestehen eines Eintrags. Die dritte ist das Verhältnis der durch Erkennung gefundenen Systeme zu den über den Antragsprozess gemeldeten: Findet die Erkennung immer wieder, was der Antragsprozess nie gesehen hat, liegt das Problem im Antragsprozess, und der Leitfaden zum Antragsprozess ist der richtige Ausgangspunkt. Kontinuierliches KI-Monitoring dieser Art ist der Grundgedanke des Inventars von Enzai, das sich mit jeder Veränderung der Landschaft aktualisiert und für die Erkennung von Assets mit AWS, Azure, GCP, Databricks, watsonx und Snowflake synchronisiert.
Was sollten Sie mit der gefundenen KI tun?
Wenn ein nicht freigegebenes Tool zum ersten Mal gefunden wird, ist das einfach, weil es eine Spur hinterlassen hat: eine Spesenposition, eine OAuth-Berechtigung, eine Domain im Proxy-Log. Folgen darauf Entfernung oder Disziplinarmaßnahmen, weicht die zweite Welle auf private Konten, private Geräte und Heimnetze aus, die keines der oben genannten Signale erfasst. Wer zuerst auf Durchsetzung setzt, macht aus einer sichtbaren Population eine unsichtbare.
Die Alternative ist eine befristete Amnestie mit zugesagter Bearbeitungsfrist. Jedes offengelegte Tool erhält innerhalb einer festgelegten Frist einen Inventareintrag und eine Entscheidung: freigeben, unter Auflagen freigeben, durch eine freigegebene Alternative ersetzen oder außer Betrieb nehmen. Wer es offengelegt hat, erhält die Entscheidung, nicht eine Vorgangsnummer. Durchsetzung bleibt der Zeit nach der Amnestie vorbehalten sowie Verstößen gegen die Datenklassifizierung, die unabhängig davon Verstöße sind, ob KI im Spiel war. Der Leitfaden zu Schatten-KI behandelt den Paved-Road-Ansatz und die Gestaltung von Richtlinien zur zulässigen Nutzung.
Warten offengelegte Tools monatelang auf eine Entscheidung, hört die Offenlegung auf. Die Aufnahme von KI-Anwendungsfällen in Enzai ist auf genau dieses Muster ausgelegt: KI, die bereits im Einsatz ist und nie den Antragsprozess durchlaufen hat, lässt sich ohne Schuldzuweisung in die Governance überführen, Fälle mit geringem Risiko werden beschleunigt bearbeitet, und freigegebene Fälle gelangen mit dokumentierter Begründung ins Inventar. So sieht KI-Enablement im operativen Alltag aus.
Worauf sollten Sie bei einem Tool zum Aufspüren nicht freigegebener KI achten?
Acht Kriterien unterscheiden ein Erkennungstool, das eine Liste liefert, von einem, das ein Inventar liefert.
Mehr als ein Erkennungssignal, klar benannt. Fragen Sie, welche der sieben oben genannten Methoden das Tool selbst ausführt und welche Daten es nur übernimmt. Ein Tool mit nur einem Signal erbt dessen blinde Flecken.
Zusammenführung in einen Eintrag. Drei Signale zu einem System sollten einen Eintrag ergeben, nicht drei Warnmeldungen.
Abdeckung eingebetteter KI und KI von Drittanbietern, nicht nur von Domains für Consumer-KI, denn genau diese Fehlerquellen bleiben einer Domain-Sperrliste verborgen.
Nicht-menschliche Identitäten im Erfassungsbereich. Ein Tool, das Servicekonten und API-Schlüssel nicht sieht, kann keine Agenten finden.
Ausgabe als Governance-Eintrag: ein Eintrag mit verantwortlicher Person, Risikostufe und Framework-Mapping, nicht ein Sicherheitsereignis, das auf Triage wartet.
Nachweise je System, sodass Bewertung, Freigabe und Dokumentation des Drittanbieters mit dem Eintrag in ein Audit gehen.
Übergaben dorthin, wo die Arbeit stattfindet: Ticketing-Tools für die Zuweisung von Verantwortlichen, Cloud- und ML-Plattformen für die Erkennung von Assets.
Ein verhältnismäßiger Antragsprozess, damit das Auffinden eines Systems zu einer Entscheidung darüber führt.
Werkzeuge für Netzwerksicherheit verdienen eine faire Würdigung. CASB- und Secure-Service-Edge-Produkte erkennen SaaS-Nutzung sehr zuverlässig, verhindern Datenabfluss und setzen Richtlinien am Netzwerkrand durch. Ihr Ergebnis ist ein Sicherheitsereignis zu einer Domain oder einer App; der Governance-Eintrag ist ein anderes Artefakt, und die entscheidende Frage für die Auswahl lautet, welches Tool ihn erzeugt. Das Inventar von Enzai kombiniert KI-Erkennung, Plattformimporte und Anwendungsfallanfragen, ordnet jedes System automatisch dem EU AI Act, ISO 42001 und dem NIST AI RMF zu und übergibt Aufgaben an Jira, ServiceNow und Slack. Wo eine Organisation in einem Governance-Reifegradmodell steht, entscheidet, wie viele der acht Kriterien sie vom ersten Tag an braucht; die Automatisierung des Governance-Workflows hat Priorität, sobald die Landschaft einer Tabelle entwachsen ist, also an dem Punkt, an dem der Wildwuchs von KI-Anwendungen einsetzt.
Was das für den Betrieb bedeutet
Für ein Governance-Team, das mit einer Liste aus Selbstauskünften oder bei null beginnt:
Führen Sie jedes verfügbare Erkennungssignal einmal parallel aus und führen Sie die Kandidaten in einer Liste zusammen. Halten Sie fest, welches Signal jedes System gefunden hat und ob ein anderes es bestätigt hat; die Funde aus nur einem Signal zeigen Ihnen, welche Signale Sie dauerhaft betreiben sollten.
Legen Sie für jeden Kandidaten einen Eintrag mit den neun Mindestfeldern an. Lassen Sie Lücken überall zu, außer bei verantwortlicher Person und Zweck, und setzen Sie eine Frist von dreißig Tagen, um jedem Eintrag ohne Verantwortliche eine verantwortliche Person zuzuweisen.
Kündigen Sie die Amnestie mit der zugesagten Entscheidungsfrist an und leiten Sie jede Offenlegung durch den Antragsprozess, damit sie als Inventareintrag mit Entscheidungsdatum ankommt.
Legen Sie die drei Aktualitätskennzahlen (Einträge ohne Verantwortliche älter als dreißig Tage, Zeit vom Signal bis zum Eintrag, Verhältnis von erkannten zu gemeldeten Systemen) monatlich dem Gremium vor, das für KI-Risiken zuständig ist.
Ordnen Sie jeden Eintrag den für ihn geltenden Pflichten zu, beginnend mit Artikel 4 und Artikel 26 des EU AI Act, dem Geltungsbereich nach ISO/IEC 42001 und NIST GOVERN 1.6, damit das Inventar die Nachweisgrundlage für jedes Framework bildet.
Das KI-Inventar von Enzai ist auf die Schritte eins, zwei und fünf ausgelegt: Multi-Methoden-Erkennung, zusammengeführt in einem Eintrag je System, mit Framework-Mapping und angehängter Nachweiskette. Wenn Sie es an Ihrer eigenen Landschaft sehen möchten, sprechen Sie mit dem Enzai-Team.
Seit 2023 nach ISO 27001 zertifiziert, jährlich von NQA auditiert
An der DSGVO ausgerichtete Datenverarbeitung
Kundendaten auf AWS in mehreren Regionen gehostet
Eigenes KI-Modell über eine private Verbindung nutzen
Finden Sie die KI, die Ihre Teams nutzen, prüfen Sie sie vor der Einführung, bewerten Sie sie anhand der geltenden Vorschriften und kontrollieren Sie, was Agenten tun dürfen. Entwickelt für regulierte Organisationen.