Ein KI-Tool ist nicht abstrakt betrachtet sicher oder unsicher. Das Risiko hängt vom konkreten Anwendungsfall, Kontotyp, Tarif, den eingegebenen Daten, dem Modellpfad, Integrationen, Berechtigungen, Standort, der Aufbewahrung, dem Vertrag und den aus der Ausgabe abgeleiteten Entscheidungen ab. Dasselbe Produkt kann für öffentliche Marketingentwürfe vertretbar und für Patientenakten, unveröffentlichte Finanzergebnisse, Zugangsdaten für Produktionssysteme oder Personalentscheidungen inakzeptabel sein.
Dieser Leitfaden bietet ein praktisches Verfahren zur Anbieterprüfung für Teams, die Assistenten, Generatoren, Coding-Tools, Meeting-Aufzeichnungstools, Agenten, Rechercheprodukte und Datenanalyseplattformen einführen. Er ist keine Rechtsberatung und ersetzt keine qualifizierte Prüfung in den Bereichen Datenschutz, Sicherheit, Beschaffung, Arbeitsrecht, Medizin, Finanzen oder Regulierung. Die geltenden Pflichten unterscheiden sich je nach Rechtsordnung, Branche, Daten und Einsatz.
Das Ziel besteht nicht darin, möglichst viele Sicherheitsabzeichen zu sammeln. Es geht um eine evidenzgestützte Entscheidung: Was darf von wem, mit welchen Daten, unter welchen Kontrollen und wie lange genutzt werden, und was muss geschehen, wenn sich das Tool ändert oder ein Vorfall eintritt?
Mit dem Anwendungsfall beginnen, nicht mit dem Anbieterfragebogen
Erstellen Sie eine einseitige Dokumentation des Anwendungsfalls, bevor Sie Marketingaussagen lesen. Benennen Sie die geschäftlich verantwortliche Person, Nutzende, betroffene Personen, die vorgesehene Aufgabe, Eingabedaten, verbundene Systeme, erzeugte Ausgabe, die für die menschliche Prüfung verantwortliche Person, nachgelagerte Entscheidungen, das erwartete Volumen und die Folgen eines Fehlers.
Klassifizieren Sie die Daten mit dem höchsten Risiko, die in den Workflow gelangen könnten, und nicht nur das in einer Demo gezeigte Beispiel. Berücksichtigen Sie personenbezogene Daten, Gesundheits- und biometrische Informationen, Daten von Kindern, Finanzunterlagen, rechtliches Material, vertrauliche Kundeninformationen, Kommunikation von Beschäftigten, Quellcode, Secrets, unveröffentlichte Strategien, lizenzierte Inhalte, Forschungsdaten sowie Daten mit Anforderungen an die Datenresidenz oder vertraglichen Beschränkungen.
Definieren Sie anschließend die Freigabegrenze. Ein Produkt kann für Recherche anhand öffentlicher Quellen zugelassen, für unveröffentlichte Kundenarbeit aber verboten sein. Ein Coding-Assistent kann für ein isoliertes Repository erlaubt, für eine Zahlungsumgebung jedoch gesperrt sein. Ein Meeting-Assistent kann nach einem Hinweis für interne Projektgespräche zulässig, für klinische, HR-, rechtliche oder Vorstandssitzungen aber ausgeschlossen sein.
Das AI Risk Management Framework des NIST ordnet die laufende Arbeit nach Govern, Map, Measure und Manage. Dieser Ansatz ist nützlicher als eine einmalige Checkliste mit Ja-oder-Nein-Ergebnis, weil sich das Risiko während Einführung und Nutzung verändert.
Den tatsächlichen Datenfluss erfassen
Zeichnen Sie jedes System auf, das Informationen empfangen oder daraus ableiten kann:
- Browser, Desktop, Mobilgerät, Erweiterung, Add-in, Bot, API, CLI, MCP-Server oder Slack-Client;
- Kontoprofil, Prompts, hochgeladene Dateien, Quell-Repositories, Meetingaudio, Bilder, Datenbankschemata und Zugangsdaten;
- Abrufindex, Embeddings, temporäre Verarbeitung, Produktspeicher, Caches, Protokolle, Analytics, Feedback, Missbrauchsüberwachung und Supportsysteme;
- eigene Modelle, externe Modellanbieter, OCR- oder Transkriptionsanbieter, Suchdienste, Cloud-Infrastruktur und weitere Unterauftragsverarbeiter;
- erzeugte Ausgaben, Exporte, geteilte Links, öffentliche Seiten, Webhooks, verbundene Anwendungen, geplante Berichte, Backups und Speicher für gelöschte Elemente.
Bleiben Sie nicht bei der Aussage „Der Anbieter verwendet Verschlüsselung“ stehen. Fragen Sie, welcher Dienst jede Datenklasse zu welchem Zweck, unter welchem Konto und Vertrag erhält und wie lange jede Kopie bestehen bleibt. Eine Zusage, Daten nicht zum Training zu verwenden, beantwortet eine Frage zum Verarbeitungszweck; sie beantwortet nicht die Fragen nach Speicherung, Protokollierung, menschlicher Prüfung, rechtlicher Offenlegung, Analytics, Backups oder Löschung.
Testen Sie alle Oberflächen getrennt. Ein Webkonto für Verbraucher, ein Enterprise-Workspace, eine API, ein Custom GPT, eine Browsererweiterung, eine mobile App und eine verbundene Drittanbieterintegration können unterschiedliche Anbieter, Einstellungen, Aufbewahrungsfristen und Bedingungen haben, obwohl sie dieselbe Marke tragen.
Das maßgebliche Konto, den Tarif und die Vereinbarung prüfen
Ermitteln Sie, wem das Konto gehört und welche juristische Person den Dienst bereitstellt. Dokumentieren Sie Tarifname, Abrechnungsweg, Region, Tenant, Administrierende, akzeptierte Bedingungen, Bestellformular, Auftragsverarbeitungszusatz, Sicherheitsanlage, Service Level Agreement, gegebenenfalls Business Associate Agreement sowie jede ausgehandelte Änderung.
Tarifspezifische Aussagen sind entscheidend. „Enterprise-Daten werden standardmäßig nicht zum Training verwendet“ belegt nicht dieselbe Behandlung für ein kostenloses Konto. Eine allgemeine Sicherheitsseite kann einem Hilfeartikel für das Produkt oder einer älteren Datenschutzerklärung widersprechen. Fordern Sie den Anbieter auf, wesentliche Widersprüche schriftlich zu klären, und fügen Sie die Antwort der Entscheidungsdokumentation bei.
Verlassen Sie sich nicht auf die Nachricht einer Person im Vertrieb, wenn der Vertrag etwas anderes festlegt. Legen Sie eine Evidenzhierarchie fest: unterzeichnete Vereinbarung und Bestellformular, aktuelle tarifspezifische Bedingungen, aktuelle offizielle Sicherheits- und Datenschutzdokumentation, offizielle Hilfematerialien und zuletzt Marketingseiten. Bewertungen Dritter und Suchausschnitte sind Hinweise, aber keine maßgeblichen Belege.
Prüfen Sie das Verhalten bei Verlängerung und Herabstufung. Enterprise-Kontrollen für Datenschutz, Aufbewahrung, SSO, Audit oder Region können verschwinden, wenn ein Testzeitraum endet oder ein Workspace den Tarif wechselt.
Datenschutzfragen nach Verarbeitungszweck stellen
Verwenden Sie eine Tabelle, die Fragen trennt, die Anbieter häufig zusammenfassen:
| Frage | Anzufordernder Nachweis | Häufiger Fehler | | --- | --- | --- | | Welche Daten werden erhoben? | Feld- und Ereignisinventar zu Prompts, Dateien, Ausgaben, Metadaten, Analytics, Feedback und Integrationen | Nur hochgeladene Inhalte prüfen | | Warum wird jeder Datentyp verarbeitet? | Zweckübersicht für Diensterbringung, Sicherheit, Analytics, Verbesserung, Training, Support und Erfüllung rechtlicher Pflichten | „Dienste verbessern“ als präzisen Zweck behandeln | | Werden Daten zum Training von Modellen verwendet? | Tarifspezifische Bedingungen für Training durch eigene und externe Anbieter, Standardeinstellungen, Opt-out-Verhalten und Wirksamkeitsdatum | Annehmen, kein Training bedeute keine Speicherung | | Welche Anbieter erhalten Inhalte? | Aktuelle Liste der Unterauftragsverarbeiter und Modellanbieter mit Dienst, Standort und Benachrichtigungsverfahren | Nur den Vertragspartner prüfen | | Wie lange wird jede Kopie aufbewahrt? | Zeitplan für Prompts, Dateien, Ausgaben, Protokolle, Feedback, Support, Embeddings, Backups und Anbieterdaten | Eine Aufbewahrungsfrist für jeden Speicher akzeptieren | | Wie werden Daten gelöscht? | Löschverfahren für Nutzende, Administration, API, Konto, Backups, Anbieter und Vertragsende | Annehmen, das Löschen eines Chats entferne alle abgeleiteten Daten | | Wo werden Daten verarbeitet? | Speicher- und Verarbeitungsregionen, Übermittlungsmechanismus, Remote-Support und Standorte der Anbieter | Eine Speicherregion mit der gesamten Verarbeitung verwechseln | | Welche Rechte können Nutzende ausüben? | Gegebenenfalls Verfahren für Auskunft, Berichtigung, Löschung, Widerspruch, Einschränkung, Datenübertragbarkeit und Kontaktaufnahme | Annehmen, der Anbieter bearbeite die Hinweise des Kunden automatisch |
Das Privacy Framework des NIST unterscheidet Datenschutzrisiken von Cybersicherheitsrisiken und verwendet die Ergebnisse Identify, Govern, Control, Communicate und Protect. Ein System kann gut gegen Eindringen abgesichert sein und dennoch durch übermäßige Erhebung, unerwartete Nutzung, fehlerhafte Schlussfolgerungen oder undurchsichtige Entscheidungsfindung Datenschutzschäden verursachen.
Training, Inferenz, Protokollierung und Feedback trennen
„Wir trainieren nicht mit Ihren Daten“ kann mehrere Dinge bedeuten. Ermitteln Sie, ob die Aussage die Basismodelle des Anbieters, produktspezifische Modelle, externe Anbieter, Fine-Tuning, Evaluierung, menschliche Prüfung, Missbrauchsüberwachung, Abrufindizes und Analytics umfasst. Prüfen Sie, ob der Schutz eine Standardeinstellung, eine Option, ein Opt-out oder lediglich eine Bedingung eines Enterprise-Vertrags ist.
Auch für Inferenz müssen Inhalte ein Modell oder einen Verarbeitungsdienst erreichen. Ein Anbieter kann mit Zero Retention arbeiten, Daten vorübergehend zur Missbrauchsüberwachung aufbewahren oder sie unter einer anderen API-Vereinbarung speichern. Ein von der Administration aktiviertes Premium-Modell kann einen anderen Pfad verwenden als das Standardmodell.
Feedback verändert häufig die Regel. Das Senden eines negativen Feedbacks, eines Supporttickets, einer geteilten Unterhaltung oder eines Diagnoseprotokolls kann die Erhebung von Prompt, Datei, Ausgabe und umgebendem Kontext zur Prüfung erlauben. Dokumentieren Sie dies für Nutzende und deaktivieren Sie das optionale Teilen von Feedback, wenn das Risiko dies erfordert.
Formulieren Sie „nicht zum Training verwendet“ niemals zu „nicht gespeichert“, „privat“, „nicht eingesehen“ oder „nicht an Dritte gesendet“ um. Jede Aussage benötigt einen eigenen Nachweis.
Zugriffs-, Identitäts- und Tenant-Kontrollen prüfen
Testen Sie beim Teameinsatz die Identität, statt eine Funktionsliste zu akzeptieren. Prüfen Sie SSO-Protokoll, Mehrfaktorauthentifizierung, Domain Capture, Just-in-time-Bereitstellung, SCIM, Rollendesign, Gastbeschränkungen, Sitzungsdauer, Geräte- oder Netzwerkrichtlinien, Dienstkonten, API-Schlüssel, OAuth-Berechtigungsumfänge und den Notfallzugriff für Administrierende.
Wenden Sie das Prinzip der geringsten Rechte an. Ein Recherche-Agent benötigt keinen Schreibzugriff auf eine Produktionsdatenbank. Ein Coding-Assistent sollte keine Cloud-Secrets erhalten, nur weil er ein Repository lesen kann. Ein Meeting-Bot benötigt nicht jeden Kalendereintrag. Eine Aufgabe zur Tabellenanreicherung sollte nicht den Zugriff auf alle verbundenen Kundendatensätze erben.
Prüfen Sie Tenant-Grenzen und Freigabestandards. Testen Sie die Erstellung öffentlicher Links, Suchindexierung, Workspace-weite Auffindbarkeit, Exporte, Duplizierung, externe Gäste, Eigentumsübertragung, Widerruf, zwischengespeicherte Kopien und das Offboarding von Beschäftigten. Bestätigen Sie, ob Administrierende Unterhaltungen von Nutzenden prüfen, exportieren, aufbewahren und löschen können.
Auditprotokolle müssen nützliche Ereignisse enthalten: Anmeldung, Änderungen durch Administrierende, Autorisierung von Integrationen, Datenexport, öffentliche Freigabe, Aktionen mit API-Schlüsseln, Rollenänderungen, Löschung, Ausführung von Agenten und sensible Konnektoraktivitäten. Prüfen Sie Aufbewahrung, Exportformat, Warnmeldungen und wer das Protokoll manipulieren kann.
Agenten und verbundene Tools als privilegierte Software behandeln
Ein Assistent, der nur Text entwirft, hat eine kleinere Aktionsfläche als ein Agent, der E-Mails liest, ein Data Warehouse abfragt, Code bearbeitet, Konten erstellt, eine Website veröffentlicht, Nachrichten sendet oder Geld bewegt. Erfassen Sie jedes Tool, jede Zugangsinformation, jedes Schema, jede Aktion, jeden Freigabeschritt, jedes Netzwerkziel und jeden Ausgabekanal.
Die Top 10 für LLM- und generative KI-Anwendungen von OWASP behandeln Prompt Injection, die Offenlegung sensibler Informationen, Lieferkettenrisiken, unsachgemäße Ausgabeverarbeitung, übermäßige Handlungsautonomie und weitere Fehler auf Anwendungsebene. Eine bösartige Anweisung kann über eine Webseite, E-Mail, PDF-Datei, einen Codekommentar, eine Datenbankzeile, einen Kalendereintrag oder ein abgerufenes Dokument eintreffen – nicht nur über den Prompt der nutzenden Person.
Verwenden Sie erlaubte Aktionslisten, schreibgeschützte Zugangsdaten, eingeschränkte Schemata, isolierten Code, URL- und Dateiprüfung, Ausgabekodierung, Limits für Aufrufraten und Kosten sowie menschliche Freigaben für irreversible oder externe Aktionen. Halten Sie Secrets aus Prompts und generiertem Code heraus. Lassen Sie eine Modellausgabe nicht ohne eine den Folgen angemessene Validierung zu einem SQL-Statement, Shell-Befehl, HTML-Fragment, einer Berechtigungsänderung oder ausgehenden Nachricht werden.
Testen Sie indirekte Prompt Injection mit einer kontrollierten Datei oder Seite, die den Agenten anweist, seine Aufgabe zu ignorieren, einen Canary-Wert offenzulegen, auf eine andere Quelle zuzugreifen oder Daten an einen anderen Ort zu senden. Das erwartete Ergebnis ist Eindämmung und nicht nur eine höfliche Ablehnung im Chatfenster.
Verstehen, was Zertifizierungen belegen und was nicht
SOC-2-Berichte, ISO-Zertifikate, Penetrationstests, Trust Center, Aussagen zur Verschlüsselung, Bug-Bounty-Programme und Compliance-Bestätigungen können nützliche Nachweise liefern. Sie belegen nicht, dass jede Produktoberfläche, jeder Tarif, Unterauftragsverarbeiter, jedes KI-Modell, jede Integration oder Kundenkonfiguration abgedeckt ist.
Fragen Sie nach Umfang, Zeitraum, juristischer Person, Dienstgrenzen, Ausnahmen, ergänzenden Kontrollen der Nutzerorganisation, Prüfstelle und Stand der Fehlerbehebung. Ein SOC 2 Type II-Bericht beschreibt Kontrollen innerhalb seines Umfangs über einen Zeitraum; das Logo allein zeigt nicht den Inhalt des Berichts. Ein Penetrationstest ist eine zeitlich begrenzte Stichprobe und kein Beleg für die dauerhafte Abwesenheit von Schwachstellen.
Verschlüsselung im Ruhezustand und bei der Übertragung ist ein grundlegender Nachweis und keine vollständige Architekturprüfung. Fragen Sie nach Eigentum und Rotation von Schlüsseln, Verschlüsselung von Backups, Tenant-Isolation, Secrets Management, Trennung von Umgebungen, sicherer Entwicklung, Prüfung von Abhängigkeiten, Reaktion auf Schwachstellen, Notfallwiederherstellung und administrativem Zugriff.
Prüfen Sie, ob kundenseitig verwaltete Schlüssel oder BYOK gespeicherte Produktdaten, die Modellinferenz oder nur eine Ebene abdecken. BYOK kann Modellkosten und die Sichtbarkeit für Anbieter verändern, ohne die Protokolle, abgerufenen Daten oder Anwendungsspeicher des Anbieters zu beseitigen.
Aufbewahrung und Löschung durchgängig testen
Erstellen Sie für jeden Datenspeicher eine Lebenszyklustabelle: erstellt, aktiv, archiviert, exportiert, geteilt, gelöscht, Konto geschlossen, Vertrag beendet, Backup abgelaufen und Legal Hold. Benennen Sie die handelnde Person, die jede Phase auslösen kann, und den zurückgegebenen Nachweis.
Führen Sie mit synthetischen Canary-Daten einen Löschtest durch. Laden Sie eine eindeutig benannte Datei hoch, erstellen Sie eine Unterhaltung und ein abgeleitetes Artefakt, teilen und exportieren Sie es, löschen Sie die Quelle, entfernen Sie die nutzende Person und schließen Sie anschließend den Workspace, sofern der Pilotversuch dies erlaubt. Prüfen Sie Benutzeroberfläche, API, geteilten Link, Suche, Integrationen, Administrationsansicht, Supportweg und vertragliche Löschbestätigung.
Der sofortige Verlust des Zugriffs für Nutzende ist nicht dasselbe wie eine physische Löschung. Ein Dienst kann Wiederherstellungskopien, Sicherheitsprotokolle, Abrechnungsunterlagen oder Anbieterdaten für festgelegte Zeiträume aufbewahren. Das kann rechtmäßig sein, doch Zeitplan, Zweck, Zugriff und endgültige Löschung müssen dokumentiert werden.
Testen Sie auch die Portabilität. Exportieren Sie Prompts, Quellenkennungen, Dateien, Code, Workflows, Entscheidungen, Protokolle und Konfiguration in nutzbaren Formaten, bevor Sie eine betriebliche Abhängigkeit genehmigen. Eine Datenschutzprüfung sollte kein vermeidbares Lock-in-Problem schaffen.
Transparenz, rechtmäßige Nutzung und betroffene Personen berücksichtigen
Wenn personenbezogene Daten betroffen sind, ermitteln Sie die Rolle der Organisation, den Zweck, die gegebenenfalls erforderliche Rechtsgrundlage, Datenkategorien, betroffene Personen, Hinweise, das Verfahren für Betroffenenrechte, Aufbewahrung, Empfänger, Übermittlungen und ob eine Datenschutz-Folgenabschätzung erforderlich ist. Die Datenschutzpflichten der Europäischen Kommission und die Transparenzleitlinien für KI des ICO bieten offizielle Ausgangspunkte; die Anwendbarkeit muss jedoch durch lokale Rechtsberatung geklärt werden.
Die Einwilligung zur Aufzeichnung eines Meetings ist keine Einwilligung in jede spätere Verwendung des Transkripts. Die Berechtigung zum Zugriff auf ein Dokument ist keine Erlaubnis, ein Modell damit zu trainieren, eine erzeugte Zusammenfassung zu veröffentlichen oder sie mit einem anderen Anbieter zu teilen. Eine öffentliche Webseite ist nicht automatisch frei von urheberrechtlichen, vertraglichen oder datenschutzrechtlichen Beschränkungen.
Ein Einsatz mit hoher Tragweite erfordert zusätzliche Prüfung. Entscheidungen über Beschäftigung, Kredit, Wohnraum, Bildung, Gesundheitsversorgung, Recht, Versicherungen, Biometrie, Sicherheit und Zugang können besondere Anforderungen und erhebliche Schäden nach sich ziehen. Verwenden Sie die Ausgabe einer universellen KI nicht als alleinige Entscheidungsgrundlage. Definieren Sie menschliche Entscheidungsbefugnis, Einspruch, Korrektur, Tests, Dokumentation und Abbruchbedingungen.
Der EU AI Act verwendet einen risikobasierten Rahmen mit Anforderungen, die vom System und von der Rolle abhängen. Bezeichnen Sie einen Workflow nicht aufgrund eines Anbieterabzeichens als „AI-Act-konform“. Klassifizieren Sie den Einsatz, ermitteln Sie gegebenenfalls, ob die Organisation Anbieter, Betreiber, Einführer oder Händler ist, und prüfen Sie den aktuellen Zeitplan sowie die geltenden Pflichten.
Anbieteraussagen und Ausgaberisiken bewerten
Die FTC rät Unternehmen, Datenschutzzusagen einzuhalten und eine den gespeicherten Daten angemessene Sicherheit zu gewährleisten. Ihr Leitfaden Start with Security betont, zu wissen, welche Daten gespeichert werden, nur erforderliche Daten aufzubewahren, den Zugriff zu kontrollieren, Anbieter abzusichern, Schutzmaßnahmen aufrechtzuerhalten und Vorfälle zu planen.
Fordern Sie Nachweise für Aussagen wie „anonym“, „Zero Retention“, „HIPAA-konform“, „DSGVO-konform“, „Enterprise-sicher“, „trainiert niemals“ oder „Genauigkeit auf menschlichem Niveau“. Fragen Sie, welches Konto, welche Funktion, welche Daten, welcher Zeitraum und welcher Vertrag von der Aussage erfasst werden. Machen Sie aus einer Produktaussage keine weiter gefasste redaktionelle Aussage.
Die Sicherheitsprüfung muss die Ausgabe einschließen. Generierter Code kann Schwachstellen einführen, eine Rechercheantwort eine Quellenangabe erfinden, ein Bild privates Quellenmaterial offenlegen, eine Zusammenfassung eine vertrauliche Tatsache preisgeben und eine Automatisierung den falschen Datensatz senden. Definieren Sie Validierung, Moderation, Provenienz, Freigabe, Monitoring und Rollback für das tatsächliche Ziel der Ausgabe.
Einen kontrollierten Pilotversuch mit Canary-Daten durchführen
Verwenden Sie öffentliche, synthetische oder bewusst konstruierte Daten, bis die Prüfung bestanden ist. Erstellen Sie Canary-Werte, die niemals außerhalb des zugewiesenen Dokuments, Tenants, der Rolle oder Aufgabe erscheinen dürfen. Verwenden Sie keine echten Secrets oder personenbezogenen Daten als Testmarker.
Testen Sie mindestens diese Szenarien:
- Eine normale Aufgabe mit bekannter korrekter Ausgabe und einer dokumentierten prüfenden Person.
- Eine nicht berechtigte Person versucht, eingeschränkte Inhalte zu finden, zu exportieren oder zu teilen.
- Eine abgerufene Datei enthält eine indirekte Prompt Injection und die Aufforderung, einen Canary-Wert offenzulegen.
- Eine erzeugte Aktion versucht, den schreibgeschützten Umfang, erlaubte Domains, Kosten- oder Empfängerlimits zu überschreiten.
- Die nutzende Person löscht Quelldaten, abgeleitete Inhalte, geteilte Links und das Konto.
- Eine administrierende Person entfernt Nutzende, rotiert Zugangsdaten, widerruft eine Integration und prüft Protokolle.
- Ein Anbieter, ein Modell, eine Datenschutzbedingung, ein Unterauftragsverarbeiter oder eine Tarifeinstellung ändert sich.
Dokumentieren Sie Nachweise und nicht nur „bestanden“. Speichern Sie, soweit zulässig, Screenshots oder Exporte, Ereigniszeitstempel, Protokolleinträge, Anfrage-IDs, Löschbestätigungen, Richtlinienversionen, die prüfende Person, ungelöste Lücken, kompensierende Kontrollen und das Ablaufdatum der Freigabe.
Eine klar abgegrenzte Freigabeentscheidung erstellen
Eine sinnvolle Entscheidung hat eines von vier Ergebnissen:
- freigegeben für benannte Nutzende, Tarife, Datenklassen, Integrationen und Zwecke;
- mit Kontrollen freigegeben, etwa ohne sensible Daten, mit schreibgeschütztem Zugriff, verpflichtender menschlicher Prüfung oder deaktivierter Freigabe;
- nur für einen Pilotversuch freigegeben, bis bestimmte Nachweise oder Vertragsbedingungen vorliegen;
- für den vorgeschlagenen Einsatz mit Begründung und Auslöser für eine Neubewertung abgelehnt.
Führen Sie verbotene Verwendungen ausdrücklich auf. Benennen Sie die geschäftlich und technisch verantwortlichen Personen, Kontaktstellen für Datenschutz oder Recht und für Sicherheit, Prüfdatum, Vorfallkanal und Offboarding-Verfahren. Nutzende benötigen eine kurze Betriebsrichtlinie und nicht die gesamte Anbieterakte.
Die Freigabe läuft ab, wenn sich eine wesentliche Tatsache ändert: Eigentum, Bedingungen, Datenschutzerklärung, Modellanbieter, Training-Standardeinstellung, Unterauftragsverarbeiter, Region, Sicherheitsvorfall, Integrationsumfang, Produktarchitektur, Anwendungsfall oder Sensibilität der Daten. Prüfen Sie Tools mit hohem Risiko häufiger als Werkzeuge für öffentliche Inhalte.
Eine kompakte Checkliste für die Beschaffung
Bestätigen Sie vor dem Produktivbetrieb, dass das Team alle folgenden Fragen anhand aktueller Nachweise beantworten kann:
- Welcher konkrete Einsatz und welche Daten sind freigegeben, und was ist verboten?
- Welches Konto, welcher Tarif, welcher Tenant, welche juristische Person, welche Region und welche Vereinbarungen sind maßgeblich?
- Wohin gelangen Prompts, Dateien, Metadaten, Ausgaben, Protokolle, Feedback und Backups?
- Welche Anbieter und Modellanbieter erhalten sie, zu welchen Zwecken und wie lange?
- Welche standardmäßigen und optionalen Einstellungen für Training, Aufbewahrung, menschliche Prüfung und Feedback gelten?
- Können Administrierende Kontrollen für Identität, das Prinzip der geringsten Rechte, Freigaben, Konnektoren, Agenten, Kosten und Audits durchsetzen?
- Kann das Team Quellen und abgeleitete Daten exportieren, Zugriffe widerrufen, Daten löschen und den Lebenszyklus belegen?
- Wie werden Prompt Injection, unsichere Ausgaben, übermäßige Handlungsautonomie, Secrets und Inhalte Dritter getestet?
- Welche Personen sind betroffen, welche Hinweise und Rechte gelten, und wer trägt die endgültige Entscheidung?
- Welche Nachweise, welches Monitoring, welcher Vorfallplan, welche Auslöser für Neubewertungen und welches Ablaufdatum der Freigabe sind dokumentiert?
Wenn mehrere Antworten lauten „Darum kümmert sich der Anbieter wahrscheinlich“, ist die Prüfung nicht abgeschlossen.
Den Rahmen auf verschiedene KI-Tool-Kategorien anwenden
Prüfen Sie bei Assistenten wie ChatGPT die Bedingungen für Verbraucher und Unternehmen, Konnektoren, Memory, geteilte Links und Modellpfade. Untersuchen Sie bei Schreib- und Marketingtools wie Jasper Markenwissen, Kundeninhalte, Veröffentlichungsintegrationen und die sachliche Freigabe. Prüfen Sie bei Bild- und Videoprodukten hochgeladene Assets, Rechte an Gesichtern und Stimmen, Generierungsanbieter, öffentliche Galerien, Trainingsnutzung und kommerzielle Bedingungen anhand der Leitfäden zu KI-Tools für Bild und Design und KI-Videotools.
Behandeln Sie bei Coding-Tools wie Cursor Repository-Zugriff, Terminalbefehle, Hintergrund-Agenten, Remote-Ausführung, Secrets und erzeugte Abhängigkeiten als privilegiert. Prüfen Sie bei Meetingtools wie Otter AI Hinweise an Teilnehmende, Einwilligung, Kalenderzugriff, Aufzeichnungsbots, Transkriptfreigabe, Training, Aufbewahrung und Löschung. Konzentrieren Sie sich bei Automatisierungsplattformen wie n8n auf Zugangsdaten, menschliche Freigabe, deterministische Grenzen, Ausführungsprotokolle, Pflichten beim Self-Hosting und Lizenzierung.
Prüfen Sie bei Präsentationstools wie Gamma vertrauliche Quellenpakete, Linksichtbarkeit, Besucheranalysen, Exporte und das Offboarding von Konten. Trennen Sie bei Recherchetools wie Elicit öffentliche Literatur von unveröffentlichter Forschung und prüfen Sie tarifspezifische Bedingungen für Anbieter, Training, Aufbewahrung und Export. Durchsuchen Sie alle KI-Tool-Kategorien, um dieselben Fragen zu Anwendungsfall und Datenfluss auf den tatsächlichen Workflow anzuwenden.
Unsere Datenschutzerklärung erläutert die Datenpraktiken dieser Website. Die Testmethodik und die Redaktionsrichtlinie erklären, wie Evidenz, Tests, Unsicherheit, Sponsoring und Aktualisierungen in Analysen dargestellt werden sollten.
Verwandte Leitfäden
Lesen Sie anschließend den Leitfaden zu den besten KI-Tools für kleine Unternehmen und den Leitfaden zu den besten KI-Automatisierungstools, um diese Entscheidung mit angrenzenden Workflows und einem konsistenten Bewertungsprozess zu verbinden.
