Warum 'ChatGPT Enterprise reicht' der teuerste Satz im Audit ist

Was passiert, wenn "ChatGPT Enterprise reicht" auf Datenschutz trifft

Vor zwei Wochen saß ich mit dem CTO eines mittelständischen Beratungshauses zusammen, achtzig Mitarbeiter, gute Kundenliste, gerade mitten im KI-Rollout. Er sagte in einem Nebensatz, "Wir haben jetzt ChatGPT Enterprise, das ist dann ja auch datenschutzrechtlich abgedeckt." Ich habe meinen Kaffee abgestellt und gefragt, was er damit meint.

Er meinte, alle Mitarbeitenden dürfen ab sofort alles damit machen. Mandantendaten. Strategiepapiere. Entwürfe für Vertragsverhandlungen. ChatGPT Enterprise sei doch DSGVO-konform.

Das ist der teuerste Satz, den ich 2026 in Beratungsgesprächen höre. Nicht weil ChatGPT Enterprise schlecht wäre, das Produkt ist solide. Sondern weil "DSGVO-konform" und "wir dürfen damit machen, was wir wollen" zwei völlig unterschiedliche Dinge sind. Und weil die Lücke dazwischen einen Namen hat: Datenklassifizierung. Eine Disziplin, die in den meisten Unternehmen, mit denen ich arbeite, schlicht nicht existiert.

Dieser Artikel ist mein Versuch, die Lücke zu schließen. Konkret, mit Beispielen aus echten Projekten, ohne ISO-Geschwurbel.

Was Datenklassifizierung wirklich bedeutet

Datenklassifizierung ist nicht das, was viele denken. Sie ist nicht das Excel-Dokument, das einmal in der ISO-27001-Zertifizierung erstellt und dann nie wieder angefasst wird. Sie ist auch nicht das Slide, auf dem "öffentlich, intern, vertraulich, geheim" steht und das die Geschäftsführung im Onboarding einmal sieht.

Datenklassifizierung ist die operative Antwort auf eine sehr praktische Frage: welche unserer Daten dürfen in welches Tool, und welche nicht?

Erst wenn diese Frage präzise beantwortet ist, lassen sich KI-Tools sinnvoll auswählen, ausrollen und überwachen. Vorher ist jeder Rollout Glücksspiel mit der Datenschutzbehörde, mit den eigenen Mandanten oder mit dem Werksspionage-Risiko, je nach Branche.

Was Datenklassifizierung in der Praxis leistet, ist dreierlei. Sie macht aus einem diffusen "wir haben sensible Daten" eine zählbare Liste mit Kategorien, Beispielen und konkreten Datenträgern. Sie definiert Regeln, was wo verarbeitet werden darf, ohne dass jeder einzelne Use Case neu bewertet werden muss. Und sie schafft die Grundlage für das, was die Datenschutzbehörden inzwischen bei KI-Audits ziemlich explizit erwarten: einen dokumentierten Prozess, wie mit unterschiedlich schützenswerten Daten umgegangen wird.

Was sie nicht ist, ist eine einmalige Aufgabe. Sondern ein lebender Prozess, der mit jedem neuen Tool, jeder neuen Datenkategorie und jeder neuen Subprocessor-Kette nachgezogen werden muss.

Genau hier liegt der Unterschied zwischen Unternehmen, die ich gerne auditiere, und solchen, die ich verzweifelt auditiere.

Die vier Datenklassen, die ich in Projekten verwende

Es gibt unzählige Klassifizierungsmodelle. BSI-Grundschutz, ISO 27001, NIST, branchenspezifische Frameworks. In den meisten Projekten arbeite ich mit einer reduzierten Variante: vier Klassen. Modelle mit fünf oder mehr Klassen werden in der Praxis nicht eingehalten. Mitarbeitende können sich vier Stufen merken, fünf nicht mehr zuverlässig.

Klasse 1: Public, was wirklich öffentlich ist

Das, was Sie auf Ihrer Website veröffentlichen, in Pressemitteilungen schreiben oder bei einem Branchenevent vortragen. Marketing-Texte, öffentliche Produktbeschreibungen, allgemeine Unternehmensinformationen.

Worauf Sie achten sollten: viele Unternehmen behandeln ihre internen Mitarbeiter-Newsletter als "öffentlich genug, kann doch nichts passieren". Das ist falsch. Was nicht aktiv für die Öffentlichkeit bestimmt ist, gehört nicht in Klasse 1, auch wenn es technisch gesehen nicht geheim ist.

Solche Daten dürfen in jedes KI-Tool, das die DSGVO-Mindestanforderungen erfüllt, also auch in kostenlose Versionen, sofern keine personenbezogenen Daten enthalten sind.

Klasse 2: Intern, der tägliche Geschäftsbetrieb

E-Mails ohne sensible Inhalte. Meetingprotokolle ohne Strategieentscheidungen. Allgemeine Projektdokumentation. Routine-Korrespondenz mit Lieferanten. Daten, deren Kompromittierung peinlich wäre, aber kein Drama auslöst.

In dieser Klasse landet erfahrungsgemäß achtzig Prozent dessen, was im Alltag durch ein Unternehmen fließt. Auch der größte Teil der Inhalte, die Mitarbeitende in ChatGPT, Claude oder Copilot kippen.

Solche Daten gehören in KI-Tools mit dokumentierter DSGVO-Konformität, also Enterprise-Tarife mit Auftragsverarbeitungsvertrag, in denen die Trainings-Nutzung der Daten vertraglich ausgeschlossen ist. Bei US-Anbietern nur mit ergänzenden Maßnahmen wie Standardvertragsklauseln und Transfer Impact Assessment.

Klasse 3: Vertraulich, nicht für die Öffentlichkeit

Personenbezogene Daten von Kunden, Mitarbeitenden, Bewerbern. Strategische Dokumente. Interne Finanzdaten, die nicht in der GuV stehen. Konstruktionspläne mit moderatem Schutzbedarf. Verhandlungsstrategien. Kalkulationsgrundlagen.

Hier wird es interessant, weil viele Unternehmen Klasse 2 und Klasse 3 nicht trennen. Sie sagen, "Sensibel ist sensibel." Das stimmt nicht. Eine Bewerbungsmail ist vertraulich. Ein Kalkulationsmodell für eine Großausschreibung auch. Aber die beiden gehören in unterschiedliche Tools, weil das eine unter Artikel 9 DSGVO fallen kann und das andere wettbewerbsrelevant ist.

Solche Daten dürfen nur in KI-Tools, die explizit für die jeweilige Datenkategorie zertifiziert sind, idealerweise mit EU-Datenresidenz und nachweislichem Subprocessor-Management. Bei besonderen Kategorien personenbezogener Daten erst nach DSFA, also Datenschutz-Folgenabschätzung.

Klasse 4: Streng vertraulich, Existenzfragen

Patente, die noch nicht angemeldet sind. Steuerlich brisante Sachverhalte mit möglicher strafrechtlicher Relevanz. Kreditverhandlungen mit Banken. M&A-Transaktionen vor Closing. Konstruktionsdaten, die das Kerngeschäft definieren. Mandanten- und Patientendaten in regulierten Berufen.

In dieser Klasse landet weniger als fünf Prozent dessen, was durch ein Unternehmen fließt. Aber wenn etwas davon in das falsche Tool gelangt, wird es teuer, manchmal existenzbedrohend.

Solche Daten gehören nicht in Cloud-KI, Punkt. Wer hier KI einsetzen will, baut on-premises oder in einer dedizierten europäischen Cloud-Instanz mit Zero-Knowledge-Architektur. Das ist teuer, das ist aufwendig, das ist genau richtig.

Die vier Klassen sind nicht beliebig. Jede hat eine konkrete operative Konsequenz. Wer das nicht durchhält, hat keine Klassifizierung, sondern ein Etikett.

Welche Daten in welches Tool dürfen, eine pragmatische Matrix

Die folgende Matrix verwende ich als Ausgangspunkt in Workshops. Sie ist nicht heilig, aber sie spart in den ersten zwei Stunden enorm viel Diskussion.

"Bedingt" heißt: nicht automatisch, sondern nach Einzelfallprüfung. Bei Klasse 3 in Microsoft Copilot zum Beispiel braucht es korrekte Sensitivity Labels, korrekte SharePoint-Berechtigungen, ein funktionierendes DLP-Setup, dokumentierte Schulung der Nutzenden. Wer das nicht hat, hat de facto Klasse 2.

Die Matrix ist absichtlich konservativ. In Audits taucht regelmäßig auf, dass Unternehmen die Spalte "Klasse 3" zu großzügig interpretieren. Lieber eine Stufe konservativer eingestuft als ein DSGVO-Verstoß, der drei Aufsichtsbehörden auf einmal beschäftigt.

Was die Matrix bewusst nicht macht

Sie unterscheidet nicht zwischen Anbietern desselben Reifegrads. Wer ChatGPT Enterprise und Claude for Work vergleicht, wird minimale Unterschiede in den AVVs finden, aber für die Klassifizierungslogik sind sie austauschbar. Differenzierung gehört in die Tool-Auswahl, nicht in die Klassifizierung.

Sie sagt auch nichts darüber, was sinnvoll ist, sondern nur darüber, was zulässig ist. Ob ein Mitarbeiter in der Buchhaltung wirklich Claude for Work braucht oder mit dem Copilot in Office besser bedient ist, ist eine Wirtschaftlichkeitsfrage, keine Datenschutzfrage.

Warum "ChatGPT Enterprise reicht" der teuerste Satz ist

Zurück zum Eingangsbeispiel. Der CTO mit ChatGPT Enterprise, achtzig Mitarbeiter, alle dürfen alles. Was läuft da schief?

ChatGPT Enterprise hat einen ordentlichen AVV. Die Trainings-Nutzung der Daten ist vertraglich ausgeschlossen. Es gibt SOC-2-Zertifizierung, SAML-SSO, Audit-Logs. Auf Tool-Ebene ist das ein gutes Produkt.

Das Problem liegt nicht im Tool. Es liegt in vier Annahmen, die der CTO unbewusst getroffen hat.

Erste Annahme: "DSGVO-konform" heißt "alles erlaubt". Falsch. DSGVO-konform heißt: das Tool ist als Verarbeiter geeignet. Was Sie in das Tool kippen, müssen Sie immer noch rechtfertigen. Eine Bewerberakte gehört auch in einen DSGVO-konformen Cloud-Speicher nicht ohne Rechtsgrundlage und Aufbewahrungsfrist.

Zweite Annahme: "Wir sind in der EU, alles ist gut." Falsch. ChatGPT Enterprise verarbeitet auch bei aktivierter EU-Datenresidenz Daten in Drittstaaten, mindestens für Logging, Support und Modell-Updates. Der US Cloud Act gilt weiterhin. Ein Transfer Impact Assessment ist Pflicht, nicht Kür.

Dritte Annahme: "Mitarbeiter wissen schon, was sensibel ist." Falsch. In jedem Audit, das ich mache, finde ich Mitarbeitende, die ChatGPT-Verläufe mit kompletten Mandantenverträgen, Lebensläufen samt Kontonummern oder Steuerakten haben. Nicht aus böser Absicht, sondern weil niemand ihnen klar gesagt hat: das hier nicht.

Vierte Annahme: "Audit-Logs reichen, um Verstöße zu finden." Falsch. Audit-Logs zeigen, welcher User wann welchen Prompt geschickt hat. Sie zeigen nicht, was im Prompt drinstand. Wer Verstöße finden will, braucht DLP auf Endpoint-Ebene oder einen vorgeschalteten Proxy.

Diese vier Annahmen erklären, warum "wir haben jetzt ChatGPT Enterprise" eben kein Datenschutzkonzept ist. Es ist ein Werkzeugkauf. Das Konzept fehlt noch.

Die Subprocessor-Kette, die niemand liest

Ein Punkt, der in den meisten Diskussionen untergeht. Sie haben mit OpenAI einen Vertrag. OpenAI hat mit Microsoft Azure einen Vertrag. Azure hat mit lokalen Rechenzentrumsbetreibern Verträge. Jede Stufe hat eigene Subprocessor-Listen, die sich periodisch ändern.

In einem Projekt vor sechs Monaten haben wir die Subprocessor-Listen von drei großen KI-Anbietern verglichen. Insgesamt vierundsiebzig Unterauftragsverarbeiter, davon einundzwanzig in Drittstaaten, davon vierzehn in den USA. Jeder dieser Subprocessor kann theoretisch Daten sehen, die durch das System fließen. Die Verträge regeln das, aber lesen tut sie kaum jemand.

Wer Klasse 3 oder 4 in Cloud-KI schickt, sollte zumindest wissen, mit wie vielen Drittparteien er das tut.

Drei Projektszenarien

Theorie ist gut, Beispiele sind besser. Drei Szenarien aus echten Projekten, anonymisiert.

Szenario 1: Beratungshaus, achtzig Mitarbeiter, Mandantendaten in ChatGPT

Das oben beschriebene Beratungshaus hat ChatGPT Enterprise eingeführt, sechs Wochen läuft es, Mitarbeitende sind begeistert. Wir machen ein Audit.

In den ersten acht analysierten Verläufen tauchten auf:

• Drei vollständige Mandantenverträge mit Klarnamen, Adressen, Vertragssummen
• Eine Liste von Bewerbern für eine Senior-Position mit Lebenslaufdetails
• Eine interne Strategie-Diskussion über die Beendigung einer Mandatsbeziehung

Was hat ChatGPT Enterprise falsch gemacht? Nichts. Das Tool hat exakt das getan, was die Nutzenden eingegeben haben. Es hat die Daten nicht weitergegeben (laut AVV), es hat sie auch nicht zum Training verwendet (laut AVV). Aber sie waren trotzdem in einem System mit US-Bezug, ohne dass jemals ein Transfer Impact Assessment für diese Datenkategorien gemacht wurde.

Was haben wir empfohlen? Drei Schritte:

1. Sofort: Aussetzen von Klasse-3-Inhalten, schriftliche Mitarbeiterinformation. 2. Innerhalb 30 Tage: DSFA für die produktive Nutzung, dokumentierte Klassifizierungs-Matrix, verbindliche Schulung. 3. Innerhalb 90 Tage: Tool-Splitting. Klasse 1 und 2 weiter in ChatGPT Enterprise, Klasse 3 in Microsoft Copilot mit Sensitivity Labels, Klasse 4 in selbstgehostetem LLM für die zwei Use Cases, wo es nötig ist.

Ergebnis nach drei Monaten: 80 Prozent der ursprünglichen Use Cases laufen weiter. Zehn Prozent wurden gestrichen, weil sie sich nicht rechtfertigen ließen. Zehn Prozent wurden auf andere Tools verlagert.

Datenklassifizierung killt Use Cases nicht, sie sortiert sie. Die wertvollen bleiben. Die kosten- oder rechtlich problematischen werden früh erkannt.

Szenario 2: Maschinenbauer, sechshundert Mitarbeiter, Konstruktionsdaten in Copilot

Mittelständischer Maschinenbauer, exportorientiert, hat M365 mit Copilot ausgerollt. Kreis der Nutzenden anfangs Geschäftsführung und Teamleitungen, nach drei Monaten Ausweitung auf zweihundert Personen, darunter die komplette Konstruktionsabteilung.

Copilot zieht über Microsoft Graph automatisch Daten aus SharePoint. Die SharePoint-Berechtigungen sind über die Jahre gewachsen, Teilen war einfacher als nicht zu teilen, und damit hat Copilot Zugriff auf Konstruktionsordner, die eigentlich nur für die Konstruktion sichtbar sein sollten. Mitarbeitende aus dem Vertrieb können per Copilot-Frage Informationen abrufen, die sie ohne Copilot nie gesehen hätten.

Aus Datenschutzsicht: kein DSGVO-Verstoß im engeren Sinn, weil keine personenbezogenen Daten betroffen waren. Aus Geschäftsgeheimnis-Sicht: hochproblematisch. Das Geschäftsgeheimnisgesetz verlangt "angemessene Geheimhaltungsmaßnahmen", und ein offen zugängliches Copilot-Setup ist das Gegenteil davon.

Was haben wir empfohlen? Zwei Schritte:

1. Sensitivity Labels auf Konstruktionsdaten ausrollen, Copilot mit DLP-Regeln so konfigurieren, dass diese Klasse nicht in Antworten auftaucht. 2. Klassifizierungspflicht für neu erstellte Dokumente, technisch erzwungen, nicht freiwillig.

Ergebnis nach sechs Monaten: 92 Prozent der Konstruktionsdokumente korrekt klassifiziert (gemessen via Stichprobe). Zwei Vorfälle, in denen die Klassifizierung umgangen wurde, beide aus Versehen, beide korrigiert. Geschäftsführung schläft besser.

Bei Geschäftsgeheimnissen ist Datenklassifizierung sowohl DSGVO-Pflicht als auch Bedingung für Schutzansprüche im Streitfall. Wer das nicht macht, kann nicht klagen.

Szenario 3: Solo-Steuerberaterin, Mandanten-Steuerdaten in Claude

Steuerberaterin, Einzelpraxis, fünfzig Mandanten, hat Claude.ai im Pro-Tarif entdeckt und nutzt es seit drei Monaten täglich für Recherche, Bescheidanalyse, Mandantenkommunikation.

Steuerberaterinnen unterliegen der berufsrechtlichen Verschwiegenheit (§ 57 StBerG). Ein Bruch dieser Verschwiegenheit ist strafbar (§ 203 StGB). Claude.ai im Pro-Tarif hat keinen ausreichenden AVV für berufsrechtlich geschützte Mandantendaten. Auch wenn Anthropic die Daten nicht zum Training nutzt: das deutsche Strafrecht fragt nicht, wer was tatsächlich macht, sondern wer Zugriff haben könnte.

Aus Datenschutzsicht: DSGVO-Probleme, ja, aber überschaubar. Aus Berufsrechtssicht: existenzgefährdend. Bei einem Audit der Steuerberaterkammer wäre das ein Approbationsentzug.

Was haben wir empfohlen?

1. Sofort: Aussetzen aller mandantenbezogenen Nutzung. Reine Recherche-Use-Cases ohne Mandantenbezug bleiben erlaubt. 2. Innerhalb 60 Tage: Wechsel auf Claude for Work mit AVV oder Claude über Bedrock (AWS Frankfurt) mit dediziertem AVV. 3. Innerhalb 90 Tage: dokumentierte Mandanten-Information über KI-Nutzung in der Kanzlei, Opt-out-Möglichkeit für Mandanten.

Ergebnis nach drei Monaten: Steuerberaterin nutzt Claude weiterhin täglich, aber im richtigen Tarif, mit korrektem AVV. Drei Mandanten haben opt-out gewählt, fünfundvierzig haben opt-in unterschrieben. Berufsrechtlich sauber.

In regulierten Berufen ist Datenklassifizierung keine DSGVO-Frage, sondern eine Approbations-Frage. Wer die Klassifizierung nicht macht, riskiert nicht nur Bußgelder, sondern den Berufsstatus.

Wie ein Datenklassifizierungs-Workshop konkret abläuft

Ich werde oft gefragt, wie viel Zeit das alles kostet. Die ehrliche Antwort: weniger als gedacht, wenn man strukturiert vorgeht. Mehr, wenn man es ohne Plan macht. Hier ist der Drei-Tages-Plan, mit dem wir in Projekten meist starten.

Tag 1: Bestandsaufnahme

Vormittag: Stakeholder-Interviews. Geschäftsführung, IT, Datenschutzbeauftragter, je ein Vertreter aus den Hauptabteilungen. Jeweils 30 bis 45 Minuten. Frage 1: Welche Daten verarbeiten Sie regelmäßig? Frage 2: Welche davon würden Sie als sensibel einstufen, ohne nachzudenken? Frage 3: Welche KI-Tools nutzen Sie heute, offiziell oder inoffiziell?

Nachmittag: Datenkategorien sammeln und gruppieren. Auf einem großen Whiteboard oder Miro-Board, alle Datentypen, die in den Interviews aufgetaucht sind. Ziel: Sammlung von 40 bis 80 Datentypen, von "Marketingbroschüre" über "Bewerberlebenslauf" bis "M&A-Term-Sheet".

Output Tag 1: Liste mit Datentypen, ungeordnet, aber vollständig.

Tag 2: Klassifizierung und Tool-Mapping

Vormittag: Datentypen den vier Klassen zuordnen. Konsens-orientiert, mit Geschäftsführung und Datenschutzbeauftragtem im Raum. Streitfälle landen auf einem Parkplatz, kommen am Nachmittag dran.

Bei Streitfällen entscheiden zwei Fragen. Erstens: Was passiert im schlimmsten Fall, wenn diese Daten öffentlich werden? Zweitens: Welche Rechtsgrundlage haben wir für die Verarbeitung? Wenn die Antwort auf eins "ein Skandal" oder "ein Bußgeldverfahren" lautet, ist es mindestens Klasse 3.

Nachmittag: Tool-Inventar. Welche KI-Tools werden heute genutzt? Welche sind im Tarif welcher Reifegrad? Mapping zwischen Klassen und Tools, mit der Matrix von oben als Ausgangspunkt. Ergebnis: konkrete Aussagen wie "Klasse-3-Daten dürfen in Tool A, B, C, aber nicht in D, E, F".

Output Tag 2: Klassifizierungs-Tabelle und Tool-Matrix, beide als versionierte Dokumente.

Tag 3: Operationalisierung

Vormittag: Was muss geändert werden? Konkrete To-do-Liste. Ein Use Case wird gestrichen. Ein Tool wird gewechselt. Drei Sensitivity Labels werden definiert. Ein DLP-Regelsatz wird beauftragt. Die Schulung wird datiert. Die DSFA wird priorisiert.

Nachmittag: Kommunikation. Wer wird wann informiert? Was steht in der Mitarbeiter-Information? Wer ist Ansprechpartner bei Unsicherheit? Welche Eskalationskette gilt bei Verstößen?

Output Tag 3: Roadmap mit klaren Verantwortlichkeiten und Fristen.

In gut vorbereiteten Projekten reichen drei Tage. In schlecht vorbereiteten habe ich auch schon zwei Wochen gebraucht, weil die Stakeholder erst mal verstehen mussten, dass "alle dürfen alles" keine Strategie ist.

Was nach dem Workshop kommt

Ein häufiger Fehler: nach dem Workshop ist Sense. Die Klassifizierung steht, alle sind glücklich, das Excel-Dokument verschwindet im SharePoint. Sechs Monate später hat keiner mehr eine Ahnung.

Was funktioniert:

• Quartalsweise Reviews der Klassifizierung. Nicht aufwendig, ein 60-minütiger Termin reicht. Was hat sich geändert? Welche neuen Tools? Welche neuen Datenkategorien?
• Aufnahme der Klassifizierung in den KI-Beschaffungsprozess. Kein neues KI-Tool ohne Mapping zur Klassifizierungs-Matrix.
• Stichprobenartige Audits. Einmal im Halbjahr ein paar Dutzend echte ChatGPT-Verläufe oder Copilot-Anfragen anschauen, mit Datenschutzbeauftragtem und IT. Was tatsächlich verarbeitet wird, ist immer anders als das, was die Theorie sagt.

Was ich daraus gelernt habe

Wenn ich auf zwei Jahre KI-Beratung zurückblicke und sortiere, welche Projekte wirklich gut gelaufen sind und welche nicht, dann steht Datenklassifizierung an Platz eins der Erfolgsfaktoren. Nicht das hipste Modell, nicht der niedrigste Preis, nicht die schickste Integration. Ob die Datenklassifizierung steht oder nicht.

Sechs Beobachtungen, die ich mir notiert habe.

Eins. Unternehmen, die vor dem Tool-Kauf klassifizieren, sparen Geld. Sie kaufen passendere Tools, weniger Lizenzen, sie haben weniger Migration-Aufwand. Die Klassifizierung kostet zwei bis fünf Beratertage. Die Migration eines falsch gekauften Tools kostet zwei bis fünf Beratermonate.

Zwei. Mitarbeitende sind nicht das Problem. Mitarbeitende sind die Lösung, wenn sie verstehen, worum es geht. Niemand will Mandantendaten leaken. Sie tun es nur, weil ihnen niemand klar gesagt hat, was sensibel ist und was nicht. Eine gute Schulung mit konkreten Beispielen aus dem eigenen Betrieb wirkt Wunder.

Drei. Die Geschäftsführung muss mitziehen, sonst wird es nichts. Wenn die Geschäftsführung selbst Klasse-3-Daten in ChatGPT Free kippt, ist jede Klassifizierung Makulatur. Vorbild durch Tun ist hier nicht Floskel, sondern Voraussetzung.

Vier. Tools mit nativer Klassifizierungs-Unterstützung wie Microsoft Sensitivity Labels oder Google Data Loss Prevention sind unterbewertet. Sie sind oft schon im bestehenden Lizenzpaket enthalten, werden aber nicht aktiviert. Wer einen M365-Tarif hat, hat oft schon das Tooling, ohne es zu wissen.

Fünf. Die Matrix von oben hält in den meisten Projekten 18 bis 24 Monate. Dann zwingt entweder eine neue Tool-Generation oder eine neue Regulierung zur Anpassung. Wer die Matrix als lebendes Dokument behandelt, ist gut. Wer sie als einmal-und-fertig behandelt, hat nach zwei Jahren ein Problem.

Sechs, der wichtigste Punkt. Datenklassifizierung ist nicht das Ziel. Das Ziel ist eine KI-Nutzung, die sicher, regelkonform und produktiv ist. Klassifizierung ist nur der schnellste Weg dorthin. Wer das vergisst und Klassifizierung als Selbstzweck betreibt, baut Bürokratie. Wer das versteht, baut eine handfeste KI-Strategie.

Wenn der CTO vom Anfang dieses Artikels in einem halben Jahr noch mal mit mir Kaffee trinkt, möchte ich, dass er sagt: "Wir haben ChatGPT Enterprise. Und wir wissen genau, was rein darf und was nicht. Und unsere Mitarbeitenden auch."

Das wäre ein Satz, den ich gerne höre.

Wer wissen möchte, welche seiner Daten heute in welchen Tools landen und wie ein Klassifizierungs-Setup für das eigene Unternehmen konkret aussehen würde, bekommt im kostenlosen Automations-Check in etwa 30 Minuten eine erste Einschätzung.