Externe KI darf nicht per Tool-Wunsch freigeschaltet werden. Erst wenn Zweck, Datenzugriff, DSGVO-Fragen, Kontrollen und Widerruf belastbar geprüft sind, ist eine Freigabe vertretbar.
Takeaway: Eine tragfähige Freigabe entsteht aus überprüfbaren Kontrollen, nicht aus Produktversprechen. Wer das Verfahren standardisiert, reduziert Ad-hoc-Entscheidungen und spätere Risiken im Betrieb.
Das eigentliche Problem beginnt meist nicht bei der Technik, sondern bei der Abkürzung: Ein Team will „nur schnell“ einen KI-Assistenten mit internen Daten verbinden. Genau dort kippt ein nützlicher Test in ein Risiko für Datenschutz, Zugriffssteuerung und Betrieb. Externe KI sollte erst Zugriff auf Unternehmenssysteme erhalten, wenn feststeht, wann eine Prüfung zwingend ist, wer sie trägt, welche Unterlagen vorliegen und wie Rechte, Protokolle und Widerruf praktisch funktionieren.
Gerade Plattformen wie Bitrix24 erleichtern es, Daten und Prozesse über verschiedene Bereiche hinweg zu vernetzen. Dennoch hängt der Erfolg solcher Integrationen nicht allein von der Technik ab, sondern vor allem von klaren Regeln für Datennutzung, Berechtigungen und Verantwortlichkeiten. Werden diese Rahmenbedingungen erst nach der Anbindung definiert, entstehen häufig zusätzliche Abstimmungsaufwände oder inoffizielle Nebenprozesse. KI-Projekte sollten daher nicht mit der Frage beginnen, was technisch möglich ist, sondern welche Datenzugriffe fachlich zulässig, nachvollziehbar und langfristig beherrschbar sind.
„Externe KI“ meint nicht nur einen Chatbot im Browser. Darunter fallen auch SaaS-Assistenzen, APIs zu Foundation Models, Copilots in Drittsystemen und Integrationen, die auf Unternehmensdaten zugreifen oder mit ihnen angereichert werden. Sobald ein externer Dienst Inhalte aus internen Quellen lesen, verarbeiten, zusammenfassen, klassifizieren oder in andere Systeme zurückschreiben kann, muss der Einsatz geprüft werden.
Diese Abgrenzung muss intern dokumentiert sein und das kann relativ knapp durchgeführt werden.
Verpflichtend wird das Verfahren immer dann, wenn mindestens einer dieser Auslöser vorliegt:
Zweck des Verfahrens ist nicht die Bewertung des Tool-Nutzens. Entscheidend ist, ob der Einsatz mit prüfbarem Risiko, begrenztem Datenumfang und widerrufbarer Zugriffskette betrieben werden kann. Wenn diese Punkte nicht belegt werden können, gibt es keine Freigabe.
[BANNER type="lead_banner_1" title="Prüfliste zur Risikobewertung vor KI-Freigabe" description="Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/9ae/k41d7qkdaxmxfxm8cj7ymjswnjw5hadq.pdf"]Ohne feste Rollen wird die Prüfung schnell politisch: Der Fachbereich verweist auf IT, IT wartet auf Datenschutz, Einkauf fragt nach Verträgen, und am Ende fehlt trotzdem die Entscheidung. Besser ist ein kleiner Freigabeweg mit benannten Verantwortlichen.
Typische Rollen in diesem Verfahren sind:
Freigabeschwellen verhindern, dass jeder Fall denselben Aufwand auslöst. Für öffentliche Daten in einer isolierten Testumgebung kann der Weg kurz sein. Sobald personenbezogene Daten betroffen sind, müssen Datenschutz und Security verbindlich eingebunden sein. Bei produktiven Kernsystemen, Schreibrechten oder sensiblen Daten braucht es eine höhere Autorisierung.
Die Prüfung startet nur mit vollständigen Unterlagen. Sonst bewertet man Annahmen statt Tatsachen.
|
Artefakt |
Wofür es gebraucht wird |
|
Anbieterunterlagen und TOMs (Technische und organisatorische Maßnahmen) |
Verständnis von Betrieb, Funktionen, Sicherheitsmodell und Maßnahmen |
|
DPA (Data Processing Agreement) / AVV (Auftragsverarbeitungsvertrag) |
Vertragliche Grundlage der Verarbeitung |
|
Liste der Subunternehmer |
Sicht auf weitere Dienstleister und Verarbeitungsorte |
|
Datenflussbeschreibung |
Nachvollzug, welche Daten wohin gelangen |
|
Berechtigungskonzept |
Prüfung des tatsächlichen Zugriffsumfangs |
|
Logging- und Löschinformationen |
Beurteilung von Nachweisbarkeit und Datenlebenszyklus |
Fehlt eines dieser Dokumente, ist die Prüfung nicht belastbar.
Vor Verträgen oder Schnittstellen muss der Anwendungsfall konkret beschrieben sein. Welche Arbeit soll die KI übernehmen? Auf welche Systeme greift sie zu? Reicht lesender Zugriff oder soll sie schreiben? Welche Aktionen würden automatisiert ausgelöst? Eine brauchbare Beschreibung enthält ein auslösendes Ereignis, betroffene Systeme, genutzte Datenobjekte, erwartete Ausgabe und mögliche Folgeaktionen. „Eingehende Support-Tickets kategorisieren und einen Antwortentwurf erzeugen“ ist prüfbar. „KI für Service einsetzen“ nicht.
Danach wird der minimale Datenumfang festgelegt: Datentypen, Tabellen und Felder, Dateibereiche, Zeiträume, Nutzergruppen und Umgebungen. Wer nur aktuelle offene Tickets klassifizieren will, braucht keinen Zugriff auf geschlossene Fälle aus mehreren Jahren. Wer Entwürfe erstellt, braucht oft keine vollständigen Anhänge.
Für erste Tests sind synthetische oder anonymisierte Daten meist die bessere Wahl. Das trennt früh, ob ein Vorhaben wirklich produktive Daten braucht oder ob das Team vorsorglich „alles“ anschließen wollte.
In Gesundheitsorganisationen muss diese Eingrenzung schärfer ausfallen. Schon Kontaktverläufe, Termindaten oder Freitextnotizen können sensible Gesundheitsdaten enthalten, selbst wenn sie nicht als klassische Patientenakte geführt werden. Deshalb braucht jeder externe Zugriff auf CRM- oder patientennahe Informationen eine zusätzliche Prüfung statt einer pauschalen Tool-Freigabe. Umgebungen wie ein CRM für das Gesundheitswesen zeigen, warum eine strikte Datenabgrenzung, Zweckbindung und rollenbasierte Rechte hier nicht optional sind. Die Nutzung einer Software ersetzt aber keine eigene Prüfung der konkreten Verarbeitung, Zugriffe und Verträge.
[BANNER type="lead_banner_2" blockquote="\"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/1f0/5znenimejlwyevt3s1tfd1gxgx08i7ew.png.webp?1742972973130' user-name="Geschäftsführer, Alexander Dortmann" user-description="DortmannKids" button-message="KOSTENFREI STARTEN"]Die rechtliche Bewertung muss mit der technischen Planung zusammenlaufen. Die zentrale Frage ist, auf welcher Grundlage die Daten verarbeitet werden, schließlich nennen 77 % der Unternehmen Datenschutz als ein Hindernis für die Arbeit mit KI.
Hierfür ist insbesondere die einschlägige Rechtsgrundlage nach Art. 6 DSGVO zu bestimmen. Sind besondere Kategorien personenbezogener Daten betroffen, sind zusätzlich die Voraussetzungen des Art. 9 DSGVO zu prüfen. Gerade bei sensiblen Inhalten reicht es nicht, dass die Anbindung technisch möglich ist.
Außerdem ist zu klären, ob eine DSFA (Datenschutz-Folgenabschätzung) erforderlich ist. Sobald Umfang, Art, Zwecke oder der Einsatzkontext der Verarbeitung ein höheres Risiko für die Rechte und Freiheiten betroffener Personen nahelegen, kann eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO erforderlich werden. Parallel ist zu prüfen, ob Datenschutzhinweise, interne Verzeichnisse oder Betroffeneninformationen angepasst werden müssen.
Besonders heikel sind die Retention- und Trainingsbedingungen des Anbieters. Intern sollte schriftlich festgehalten werden:
Wenn ein Anbieter hier unpräzise bleibt, ist das selbst ein Prüfbefund. Wer nicht belastbar erklären kann, was mit Eingabeaufforderungen, Antworten und verbundenen Daten geschieht, ist für sensible Einsätze kaum tragfähig.
Danach folgen Subprozessoren und mögliche Drittlandtransfers. Benötigt werden die vollständige Liste beteiligter Dienstleister, Speicher- und Verarbeitungsorte, Transfermechanismen, Regeln zur Benachrichtigung bei Änderungen und die vertraglichen Zusagen im AVV oder DPA. Nur dann lässt sich später nachvollziehen, ob der tatsächliche Betrieb noch dem freigegebenen Stand entspricht.
Viele Freigaben bleiben bei Kontrollen zu theoretisch. Rollenbeschreibungen des Anbieters sind ein Startpunkt, aber kein Nachweis. Vor dem Go-live muss praktisch geprüft werden, welche Rechte der Dienst wirklich erhält. Der Ablauf sollte wie folgt aussehen:
Erstens braucht es eine Berechtigungsprüfung. Der Test muss zeigen, ob der KI-Dienst nur lesen kann oder auch schreiben darf, wer Connectoren freischalten kann, ob Servicekonten getrennt von Benutzerkonten laufen und ob das Minimalrechteprinzip technisch erzwungen wird. Gerade bei Integrationen entstehen sonst zusätzliche Rechte, weil ein Systemkonto „vorübergehend“ weit gefasst wurde.
Zweitens braucht es belastbare Aktivitätsnachweise. Geprüft werden sollten Logs für Zugriffe, Eingabeaufforderungen, Aktionen, Admin-Änderungen und Datenexporte. Ebenso relevant ist, wie lange diese Informationen zur Verfügung stehen, in welchem Detailgrad und ob sie in SIEM-, Audit- oder Incident-Prozesse übernommen werden können.
Enterprise-Umgebungen sollten anhand verifizierbarer Kontrollen bewertet werden, nicht anhand von Marketingaussagen. Das betrifft Rechtemodelle, Nachvollziehbarkeit und zentrale Steuerungsmöglichkeiten ebenso wie Plattformen, die diese Anforderungen unterstützen. Enterprise-Lösungen wie Bitrix24 stellen dafür umfangreiche Funktionen bereit. Entscheidend bleibt jedoch, wie diese im konkreten Setup konfiguriert, genutzt und kontrolliert werden.
Drittens muss der Widerruf durchgespielt werden.
Ein brauchbarer Test umfasst:
Wenn niemand sicher sagen kann, wie der Zugriff vollständig gestoppt wird, ist die Anbindung nicht reif für Produktion.
Nach der Prüfung braucht es eine standardisierte Entscheidungsakte, nicht nur eine PDF-Ablage. Darin sollten Aspekte festgehalten werden, wie Zweck, angebundene Systeme, betroffene Datenkategorien, Restrisiken, genehmigter Datenumfang, verbotene Nutzungen, technische Auflagen, Verantwortliche und Termin für die erneute Prüfung.
Diese Dokumentation verhindert, dass sich der ursprüngliche Anwendungsfall unbemerkt ausweitet. Anfangs wird möglicherweise nur lesend auf Daten zugegriffen, später kommen Schreibrechte hinzu. Aus Testdaten werden Produktivdaten, aus einem einzelnen Team mehrere beteiligte Bereiche. Ohne einen klar definierten und dokumentierten Freigabeumfang bleiben solche Änderungen oft lange unbemerkt und werden erst erkannt, wenn bereits neue Risiken entstanden sind.
Produktive Nutzung beginnt erst, wenn Verträge abgeschlossen, Konfigurationen bestätigt, Berechtigungs- und Log-Tests dokumentiert und das Widerrufsverfahren nachgewiesen sind. Wenn eines davon offen ist, bleibt die Nutzung im Pilot oder wird zurückgestellt.
Für höhere Risiken empfiehlt sich eine abgestufte Einführung:
So wird die Freigabe nicht zum einmaligen Ja, sondern zu einem kontrollierten Start unter Auflagen.
Mit Bitrix24 regeln Sie Rollen, Rechte und Prozesse zentral, protokollieren Zugriffe und behalten Integrationen auch im Betrieb unter Kontrolle.
Jetzt kostenlos testenEin Verfahren ist erst nützlich, wenn es wiederholbar ist. Ziel ist eine kompakte Prüflogik mit festen Artefakten, die von Fall zu Fall neu befüllt, aber nicht jedes Mal neu erfunden wird.
Zu den wiederverwendbaren Unterlagen gehören:
Nachgeprüft werden sollte mindestens bei neuen Funktionen, neuen Subprozessoren, geänderten Trainingsbedingungen, zusätzlichen Datenquellen, Sicherheitsvorfällen oder wenn aus Leserechten Schreibrechte werden.
Vollständig ist die Prüfung erst, wenn die Freigabe dokumentiert, die Kontrollen verifiziert, die Auflagen umgesetzt und die Verantwortlichkeiten für Betrieb, Monitoring und erneute Bewertung zugewiesen sind. Vorher ist der Vorgang nicht abgeschlossen, auch wenn die Schnittstelle technisch schon funktioniert.
Genau diese strukturierte Vorgehensweise unterscheidet eine spontane Freigabe einzelner Tools von einem belastbaren Governance-Prozess. Unternehmen benötigen einen solchen Prozess spätestens dann, wenn das interne KI-System in Bitrix24 nicht mehr nur Inhalte erzeugt, sondern auf Unternehmensdaten zugreift, Prozesse auslöst oder Änderungen in produktiven Systemen vornehmen kann.