KI-Datenschutz im MittelstandDaten schützen. Innovation ermöglichen.

01 / Rechtliche Grundlagen

Der wichtigste Irrtum: Die DSGVO verbietet keine KI mit personenbezogenen Daten

Zunächst eine grundlegende Klarstellung: DSGVO und GDPR sind zwei Bezeichnungen für dieselbe europäische Datenschutz-Grundverordnung.

Die Verordnung verbietet weder den Einsatz kommerzieller KI-Dienste noch die Verarbeitung personenbezogener Daten durch Sprachmodelle generell.

Entscheidend ist, ob die konkrete Verarbeitung zulässig und angemessen abgesichert ist.

Dazu gehören insbesondere eine geeignete Rechtsgrundlage, ein klarer Verarbeitungszweck, Datenminimierung, angemessene Sicherheitsmaßnahmen und gegebenenfalls ein Auftragsverarbeitungsvertrag mit dem KI-Dienstleister. Auch Aufbewahrungsfristen, Unterauftragsverarbeiter, mögliche Datenübermittlungen in Drittländer und Betroffenenrechte müssen berücksichtigt werden.

Dazu kommen Informationspflichten und die erforderliche Dokumentation, insbesondere im Verzeichnis der Verarbeitungstätigkeiten. Bei besonderen Datenkategorien wie Gesundheitsdaten sind zusätzlich die Voraussetzungen des Art. 9 DSGVO zu prüfen. Bei voraussichtlich hohem Risiko ist vorab eine Datenschutz-Folgenabschätzung nach Art. 35 erforderlich; bei ausschließlich automatisierten Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung ist Art. 22 zu beachten. Eine bloße menschliche Bestätigung ersetzt keine echte Prüfung. DSK: KI und Datenschutz

Ein Beispiel:

Ein Mitarbeiter möchte mit KI eine Antwort auf eine Kundenreklamation formulieren. Der Text enthält Namen, eine Bestellnummer und eine Beschreibung des Problems.

Das bedeutet nicht automatisch, dass die Anfrage unzulässig ist oder zwingend anonymisiert werden muss. Unter geeigneten rechtlichen und technischen Rahmenbedingungen kann auch ein externer KI-Dienst personenbezogene Daten verarbeiten.

Umgekehrt wird derselbe Vorgang nicht allein dadurch zulässig, dass ein Anbieter verspricht, Kundendaten nicht zum Training seiner Modelle zu verwenden.

„Kein Training mit Kundendaten“ ist ein wichtiger Vertrags- und Sicherheitsaspekt, aber kein vollständiges Datenschutzkonzept.

Ebenso wenig bedeutet Serverstandort Deutschland automatisch DSGVO-Konformität. Und auch ein vollständig lokales KI-Modell entbindet das Unternehmen nicht von Datenschutzpflichten.

Die richtige Frage lautet deshalb nicht: „Darf unsere KI personenbezogene Daten sehen?“

Sie lautet: „Welche Daten benötigt dieser Prozess tatsächlich, wer verarbeitet sie, auf welcher Grundlage und mit welchen Schutzmaßnahmen?“

02 / Weniger Daten übertragen

Die einfachste Datenschutzmaßnahme ist häufig auch die wirtschaftlichste

Bevor wir über Verschlüsselung, Pseudonymisierung oder KI-Gateways nachdenken, sollten wir uns fragen:

Braucht das Sprachmodell diese Daten überhaupt?

Praxisbeispiel: Umsatzauswertung aus dem ERP

Ein mittelständisches Industrieunternehmen möchte wissen, welche Produktgruppen sich im vergangenen Quartal besonders gut entwickelt haben.

Ein naheliegender, aber unnötig riskanter Ansatz wäre, eine umfangreiche Auftragstabelle als CSV zu exportieren und in einen KI-Chat hochzuladen.

Diese Tabelle enthält möglicherweise Kundennamen, Ansprechpartner, Anschriften, einzelne Bestellungen und weitere Informationen, die für die Auswertung gar nicht benötigt werden.

Deutlich besser ist folgende Vorgehensweise:

Das ERP-System berechnet zunächst selbst die benötigten Kennzahlen. Erst anschließend bekommt das Sprachmodell eine aggregierte Tabelle mit Produktgruppe, Umsatz, Absatzmenge und Vorjahresvergleich.

Das Ergebnis: weniger übertragene Informationen, geringere Risiken, meist weniger Token-Verbrauch und häufig sogar bessere Analysequalität.

Du bist Datenanalyst für ein mittelständisches Industrieunternehmen.

Ich möchte die Umsatzentwicklung nach Produktgruppen auswerten.

Erstelle auf Grundlage des nachfolgend beschriebenen Datenbankschemas eine ausschließlich lesende SQL-Abfrage, die pro Produktgruppe und Monat den Nettoumsatz, die Absatzmenge und die Anzahl der Bestellungen aggregiert.

Personenbezogene Daten, Kundennummern, Ansprechpartner, Adressen und Einzelbestellungsdetails sollen nicht im Abfrageergebnis erscheinen.

Berücksichtige mögliche Reidentifikationsrisiken bei sehr kleinen Gruppen und schlage gegebenenfalls Mindestgruppengrößen oder weitere Aggregation vor.

Erfinde keine Datenbanktabellen oder Spalten. Stelle Rückfragen, falls notwendige Schemaangaben fehlen.

Datenbankschema: [Hier ausschließlich das erforderliche Schema ohne echte Kundendaten einfügen]

Die vorgeschlagene SQL-Abfrage muss vor Ausführung geprüft und mit technisch beschränkten Leserechten ausgeführt werden. Ein Prompt ersetzt weder Datenbankberechtigungen noch die Prüfung des Ergebnisses auf Personenbezug.

Dieser Ansatz ist ein Beispiel für Privacy by Design: Datenschutz wird bereits in die Architektur des Arbeitsablaufs eingebaut. DSK: Technische und organisatorische Maßnahmen

Und genau darin liegt ein wesentlicher wirtschaftlicher Vorteil. Daten, die gar nicht übertragen werden, müssen nicht aufwendig erkannt, maskiert, zurückübersetzt oder bei einem externen Dienst gelöscht werden.

03 / Vier Architekturansätze

Vier Architekturansätze – und wann sich welcher lohnt

Für mittelständische Unternehmen kommen grundsätzlich vier Varianten infrage. Sie schließen sich nicht gegenseitig aus.

Variante A: Kommerzielle Unternehmens-KI

Für zahlreiche Unternehmen ist ein freigegebener KI-Dienst mit geeigneten Geschäftskundenbedingungen der wirtschaftlich sinnvollste Einstieg.

Infrage kommen beispielsweise entsprechende Unternehmensangebote von OpenAI, Anthropic oder Microsoft sowie KI-APIs über professionelle Cloud-Plattformen.

Die konkrete Auswahl sollte nicht allein an Modellqualität oder Preis festgemacht werden. Zu prüfen sind insbesondere Verträge, Verarbeitungslokationen, Lösch- und Aufbewahrungsregeln, Zugriffsrechte, Sicherheitsfunktionen und gegebenenfalls internationale Datenübermittlungen.

Wichtig ist außerdem die Unterscheidung zwischen privaten Abonnements und Unternehmensprodukten. Ein privat genutztes Pro-Abonnement besitzt nicht zwangsläufig dieselben vertraglichen Datenschutzbedingungen wie ein Unternehmensdienst desselben Anbieters.

Praxisempfehlung: Vor dem Kauf zusätzlicher Schutzsoftware zunächst prüfen, welche Kontrollmöglichkeiten der bereits eingesetzte Unternehmensdienst bietet.

Variante B: Vorhandene Unternehmenssicherheit nutzen

Viele mittelständische Unternehmen betreiben ohnehin Microsoft 365, Entra ID, SharePoint und verschiedene Endpoint-Sicherheitslösungen.

Dort existieren häufig bereits Funktionen für Zugriffskontrolle, Datenklassifizierung, Protokollierung und Data Loss Prevention (DLP).

DLP bezeichnet Mechanismen, die unerwünschte Übertragungen schutzbedürftiger Informationen erkennen oder verhindern sollen.

Diese bestehenden Möglichkeiten sollten vor der Einführung eines separaten KI-Datenschutzprodukts geprüft werden. Nicht jede erweiterte KI-spezifische Schutzfunktion ist allerdings in jeder Microsoft-365-Lizenz enthalten. Microsoft: DLP für Copilot

Ein häufig unterschätztes Problem sind außerdem über Jahre gewachsene Zugriffsrechte in SharePoint und anderen Wissenssystemen.

Ein KI-Assistent, der vorhandene Berechtigungen korrekt berücksichtigt, löst nicht das Problem, dass ursprünglich zu viele Mitarbeiter Zugriff auf bestimmte Dokumente erhalten haben. Microsoft: Daten, Datenschutz und Berechtigungen

Variante C: Ein zentraler Privacy-Layer

Sobald Unternehmen eigene KI-Anwendungen entwickeln, mehrere Modellanbieter einsetzen oder Agenten mit internen Systemen verbinden, wird eine zentrale technische Schutzschicht interessant.

Eine solche Architektur könnte vereinfacht so aussehen:

Dabei werden Daten vor dem Modellaufruf untersucht. Personenbezogene Angaben können bei Bedarf entfernt, durch Platzhalter ersetzt oder die Anfrage kann vollständig blockiert werden.

Der Vorteil: Die Datenschutzlogik wird an einer Stelle gepflegt und von mehreren Anwendungen wiederverwendet.

Das macht die Lösung besonders interessant für Unternehmen, die KI systematisch in ihre Prozesse integrieren möchten.

Variante D: Lokale KI

Eine weitere Möglichkeit ist, das Sprachmodell innerhalb der eigenen Infrastruktur oder einer entsprechend kontrollierten privaten Cloud-Umgebung zu betreiben.

Damit lassen sich externe Übertragungen bei der Inferenz vermeiden, sofern auch angrenzende Dienste, Telemetrie und Netzwerkzugriffe entsprechend kontrolliert werden.

Der Preis dafür sind zusätzlicher Betriebsaufwand, Hardware- oder Cloud-Kosten und die Notwendigkeit, Modellqualität und Leistungsfähigkeit passend zum Anwendungsfall auszuwählen.

Lokale KI ist also nicht automatisch die beste Datenschutzlösung. Sie ist vor allem dort interessant, wo die zusätzliche technische Kontrolle einen konkreten Mehrwert bietet.

04 / Pseudonymisierung

Pseudonymisierung: Identifikatoren ersetzen, ohne Prozesse unbrauchbar zu machen

Ein besonders interessanter Baustein ist die automatische Pseudonymisierung.

Dazu ein einfaches Beispiel aus dem Kundenservice.

Die ursprüngliche Nachricht lautet:

„Max Mustermann hat am 12. Oktober einen Defekt am Steuerungsmodul gemeldet. Bitte entwirf eine freundliche Antwort.“

Vor dem Versand an das Sprachmodell wird der Name lokal ersetzt:

„KUNDE_0042 hat am 12. Oktober einen Defekt am Steuerungsmodul gemeldet. Bitte entwirf eine freundliche Antwort.“

Das Sprachmodell erstellt seinen Antwortvorschlag auf Grundlage des Platzhalters.

Erst innerhalb der kontrollierten Unternehmensumgebung wird „KUNDE_0042“ bei Bedarf wieder zu „Max Mustermann“.

Das hat einen praktischen Vorteil: Die KI kann weiterhin den gewünschten Geschäftsvorgang bearbeiten, ohne für die eigentliche Textformulierung den Namen der betreffenden Person zu benötigen.

Wichtig: Das ist Pseudonymisierung, nicht automatisch Anonymisierung. Für das Unternehmen, das die Zuordnung wiederherstellen kann, bleiben die Daten personenbezogen. Auch andere Angaben können eine Person indirekt identifizierbar machen.

Die Empfängersicht ist gesondert zu prüfen: Der EuGH hat im Urteil C-413/23 P vom 4. September 2025 zur Datenschutzverordnung für EU-Organe klargestellt, dass pseudonymisierte Daten nicht für jede Person automatisch personenbezogen sind. Entscheidend sind die tatsächlichen Identifizierungsmöglichkeiten. Daraus folgt kein pauschaler Freibrief für Übermittlungen; die Informationspflichten des Verantwortlichen entfallen dadurch nicht. EuGH: Einordnung des Urteils

Welche Open-Source-Werkzeuge eignen sich?

Ein interessanter Kandidat ist Presidio (ursprünglich von Microsoft entwickelt).

Die Software kann verschiedene Arten personenbezogener Informationen anhand von Erkennungsmustern, Sprachmodellen und benutzerdefinierten Regeln erkennen und anschließend ersetzen oder maskieren.

Weitere spezialisierte Erkennermodelle wie GLiNER können Presidio ergänzen. Für deutsche Unternehmensdaten ist insbesondere die Kombination mehrerer Verfahren interessant: reguläre Ausdrücke, Prüfziffern, bekannte Stammdaten und kontextabhängige Erkennung.

Beispielsweise lässt sich eine Mitarbeiterpersonalnummer anhand der Datenbankstruktur meist zuverlässiger behandeln als durch die bloße Analyse ihres Zeichenwerts.

Doch ein entscheidender Punkt wird bei solchen Lösungen häufig unterschätzt:

Keine automatisierte PII-Erkennung garantiert, dass sämtliche personenbezogenen Informationen gefunden werden.

Auch die Presidio-Projektdokumentation weist ausdrücklich auf diese Grenze hin.

Deshalb sollte eine Pseudonymisierungslösung nicht einfach installiert und anschließend als „DSGVO-sicher“ deklariert werden.

Vor einer produktiven Nutzung braucht es Tests mit repräsentativen Datenstrukturen, dokumentierte Fehlerraten, geeignete Regeln für nicht überprüfbare Inhalte und ein klar definiertes Verhalten bei technischen Fehlern.

Du bist Testingenieur für eine Datenschutzkomponente.

Erstelle 100 vollständig synthetische deutsche Testfälle zur Erkennung personenbezogener Daten.

Berücksichtige Namen, Anschriften, geschäftliche Kontaktdaten, Personalnummern, Kundennummern, SQL-Daten, CSV-Dateien und JSON-Strukturen.

Ergänze schwierigere Beispiele, etwa Einzelunternehmen mit Personennamen, indirekt identifizierende Formulierungen und technische Produktnamen, die fälschlich als Personennamen erkannt werden könnten.

Gib für jeden Testfall den Eingabetext, die erwarteten Erkennungsstellen, den erwarteten Schutzmechanismus und mögliche Fehlerursachen an.

Verwende ausschließlich fiktive Daten.

Ziel ist eine nachvollziehbare Test-Suite, die sowohl übersehene personenbezogene Angaben als auch fälschliche Maskierungen sichtbar macht.

Das ist ein sinnvoller erster Schritt, bevor man echte Geschäftsdaten durch einen neuen Filter verarbeitet.

05 / Agenten absichern

KI-Agenten sind ein Sonderfall: Ein Filter vor dem Sprachmodell reicht nicht aus

Bei klassischen Chatbots kontrolliert man vor allem, welche Informationen der Nutzer eingibt und welche Antworten erzeugt werden.

Bei KI-Agenten ist die Situation komplexer.

Ein Softwareentwicklungsagent kann Dateien lesen, Shell-Befehle ausführen, Datenbanken abfragen, Git-Repositories bearbeiten und über externe Werkzeuge kommunizieren.

Angenommen, ein solcher Agent soll eine bestehende ERP-Anwendung analysieren und modernisieren.

Dabei entdeckt er eine Tabelle mit Mitarbeiterdaten. Selbst wenn sämtliche Anfragen an das Sprachmodell durch einen lokalen Pseudonymisierungsproxy geleitet werden, können zusätzliche Risiken bestehen.

Der Agent könnte beispielsweise über einen anderen Netzwerkpfad Daten übertragen, einen ungeprüften MCP-Server aufrufen oder personenbezogene Informationen in Logs und Entwicklungsartefakten ablegen.

Ein Datenschutzproxy schützt nur die Datenflüsse, die tatsächlich durch ihn hindurchlaufen.

Eine belastbare Agentenarchitektur benötigt deshalb mehrere Schutzmechanismen:

• Beschränkte Datei-, Datenbank- und Netzwerkzugriffe nach dem Prinzip minimaler Berechtigungen.
• Bevorzugt synthetische oder geeignete Testdaten statt vollständiger Produktivdaten.
• Freigegebene Modellanbieter und klar kontrollierte externe Werkzeuge.
• Schutz vor unbeabsichtigter Weitergabe von Zugangsdaten, Protokollen und sensiblen Inhalten.
• Menschliche Freigaben für besonders kritische oder irreversible Aktionen.

Gerade bei Softwaremigrationen kann diese Architektur die Produktivität erhalten, ohne den Agenten mit unnötigen Daten oder Berechtigungen auszustatten.

Die wirtschaftlich entscheidende Maßnahme ist häufig nicht ein besonders intelligenter Datenfilter, sondern eine sauber abgegrenzte Arbeitsumgebung.

06 / Kosten & Nutzen

Was kostet guter KI-Datenschutz – und wann rechnet er sich?

Datenschutz lässt sich nicht seriös allein anhand von Software-Lizenzkosten bewerten.

Ein kostenloses Open-Source-Werkzeug kann im Produktivbetrieb teuer werden, wenn es individuell angepasst, gegen Fehler abgesichert und bei jeder Änderung einer KI-Schnittstelle erneut getestet werden muss.

Umgekehrt kann eine kommerzielle Unternehmenslösung wirtschaftlich sehr attraktiv sein, wenn sie bereits den Großteil der Anforderungen abdeckt.

Die folgenden Größenordnungen sind illustrative Projektannahmen, keine statistisch erhobenen Durchschnittswerte oder Anbieterpreise:

Die Frage nach dem Return on Investment sollte daher auf zwei Ebenen beantwortet werden.

Erstens: Welchen wirtschaftlichen Nutzen erzeugt die KI-Anwendung?

Beispielrechnung: 30 Mitarbeiter sparen durch KI durchschnittlich zehn Minuten pro Arbeitstag. Bei 200 Arbeitstagen und einem kalkulatorischen Vollkostenstundensatz von 60 Euro entspricht das rechnerisch 60.000 Euro freigesetzter Arbeitskapazität pro Jahr.

Wenn davon tatsächlich nur 35 Prozent wirtschaftlich nutzbar werden, verbleiben 21.000 Euro jährlicher Nutzen.

Zweitens: Welche zusätzlichen Kosten verursacht die gewählte Datenschutzlösung?

Für diese 30 Mitarbeiter wäre ein selbst entwickeltes Datenschutzgateway mit beispielsweise 40.000 Euro Einführungs- und Betriebskosten im ersten Jahr allein für diesen Anwendungsfall wirtschaftlich schwer zu rechtfertigen.

Wenn dasselbe Gateway allerdings zehn produktive KI-Prozesse absichert, aufwendige manuelle Arbeit ersetzt und zusätzliche wirtschaftlich wertvolle Anwendungsfälle ermöglicht, kann die Rechnung völlig anders aussehen.

Daraus folgt ein wichtiger Grundsatz:

Nicht jede KI-Anwendung braucht ihre eigene Datenschutzarchitektur. Wiederverwendbare Schutzmechanismen können entscheidend sein, um den Datenschutzaufwand pro Anwendungsfall zu senken.

Dabei darf die Wirtschaftlichkeitsrechnung notwendige rechtliche Maßnahmen natürlich nicht als beliebig verzichtbare Optionen behandeln. Es geht darum, zwischen zulässigen Lösungen die geeignete und wirtschaftlich tragfähige auszuwählen.

07 / Der 30-Tage-Plan

So würde ich KI-Datenschutz in 30 Tagen pragmatisch angehen

Für ein mittelständisches Unternehmen mit vorhandener IT-Abteilung und ersten KI-Anwendungen muss ein sinnvoller Einstieg kein monatelanges Großprojekt sein.

Du unterstützt die IT- und Datenschutzverantwortlichen eines deutschen mittelständischen Unternehmens.

Analysiere den folgenden geplanten KI-Anwendungsfall.

Untersuche insbesondere:

1. Welche Daten für den Geschäftszweck tatsächlich notwendig sind.
2. Welche personenbezogenen oder vertraulichen Informationen verarbeitet werden könnten.
3. Welche Übertragungswege und externen Empfänger entstehen.
4. Welche datenschutzrechtlichen Fragen fachlich geklärt werden müssen.
5. Wie sich die Datenverarbeitung technisch reduzieren lässt.
6. Welche vorhandenen Sicherheitsmechanismen möglicherweise ausreichen.
7. Wann ein zusätzlicher Privacy-Layer oder lokale Inferenz sinnvoll sein könnte.
8. Welche offenen Fragen vor einer produktiven Freigabe bestehen.

Unterscheide rechtliche Prüfpunkte von technischen Empfehlungen und wirtschaftlichen Optimierungsmöglichkeiten.

Behaupte keine abschließende Rechtskonformität. Kennzeichne offene Informationen und Unsicherheiten.

Anwendungsfall: [Hier eine abstrahierte Beschreibung ohne unnötige personenbezogene Daten einfügen]

Solche Voranalysen können die Zusammenarbeit zwischen Fachabteilung, IT, Informationssicherheit und Datenschutz erheblich strukturieren.

Sie ersetzen aber nicht die erforderliche fachliche und gegebenenfalls rechtliche Prüfung.

08 / Typische Fehler

Was Unternehmen unbedingt vermeiden sollten

09 / KI als Unterstützung

Welche Rolle KI selbst bei der Datenschutzorganisation spielen kann

KI kann nicht nur Datenschutzrisiken erzeugen. Sie kann auch helfen, Datenschutzaufgaben effizienter vorzubereiten.

Beispielsweise bei der Strukturierung von Datenflüssen, der Erstellung von Dokumentationsentwürfen, der Suche nach unnötigen Datenfeldern oder der Entwicklung synthetischer Testdatensätze.

Eine besonders nützliche Anwendung ist die systematische Verbesserung vorhandener Geschäftsprozesse.

Du bist Enterprise-Architekt mit Schwerpunkt Datenminimierung, IT-Sicherheit und wirtschaftlicher Prozessautomatisierung.

Analysiere den folgenden Workflow und entwickle drei Alternativen:

A. Minimaler Umbau mit vorhandenen Systemen.

B. Zentraler Datenschutz-Layer mit regelbasierter und gegebenenfalls KI-gestützter Pseudonymisierung.

C. Stärker isolierte Lösung mit privater oder lokaler KI-Inferenz.

Vergleiche für jede Alternative die erwartete Reduktion unnötiger Datenübertragungen, mögliche Restrisiken, Integrationskomplexität, Wartungsaufwand und Auswirkungen auf die fachliche Qualität.

Schätze Einführungsaufwand und Betriebskosten nur unter expliziten Annahmen und kennzeichne sämtliche Zahlen als illustrative Schätzungen.

Empfiehl keine aufwendigere Architektur, sofern eine einfachere Lösung die beschriebenen Anforderungen voraussichtlich angemessen erfüllt.

Bestehender Workflow: [Abstrahierte Prozessbeschreibung]

Vorhandene Systeme: [ERP, CRM, Microsoft 365, KI-Dienste usw.]

Damit kann aus einer abstrakten Datenschutzdiskussion ein konkreter Architektur- und Wirtschaftlichkeitsvergleich werden.

10 / Datenschutz im Alltag

Fazit: Der beste KI-Datenschutz ist der, der im Alltag funktioniert

Der deutsche Mittelstand braucht keine pauschale Entscheidung zwischen öffentlicher KI-Cloud und vollständig abgeschotteter Eigeninfrastruktur.

Er braucht eine Architektur, die zum Schutzbedarf der Daten, zum tatsächlichen Geschäftsprozess und zu den verfügbaren Ressourcen passt.

Je nach Anwendungsfall kann eine Kombination aus freigegebenen Unternehmens-KI-Diensten, geeigneten Verträgen, klaren Zugriffsrechten, Datenminimierung und vorhandenen Sicherheitsfunktionen ausreichen. Entscheidend bleiben die rechtlichen Voraussetzungen und die Wirksamkeit der konkreten Schutzmaßnahmen.

Wo mehr erforderlich ist, können Open-Source-Werkzeuge wie Presidio, zentrale KI-Gateways, kontrollierte Agentenumgebungen und lokale Sprachmodelle zusätzliche Schutzmöglichkeiten eröffnen.

Entscheidend ist dabei nicht die Anzahl der eingesetzten Technologien, sondern ihre nachgewiesene Wirkung.

Ein Unternehmen, das den Großteil der für einen KI-Prozess unnötigen Daten gar nicht erst abruft, hat oftmals mehr erreicht als eines, das sämtliche Daten zunächst einsammelt und anschließend versucht, sie aufwendig zu maskieren.

Die wirtschaftlich und technisch überzeugendste Lösung beginnt deshalb meist nicht mit dem Kauf einer Datenschutzsoftware.

Sie beginnt mit drei einfachen Fragen:

Was soll die KI erreichen? Welche Informationen benötigt sie dafür wirklich? Und wie gestalten wir den Weg dorthin so einfach, kontrollierbar und datensparsam wie möglich?

Wer diese Fragen konsequent beantwortet, schafft eine gute Grundlage für produktive, verantwortungsvolle und nachhaltig betreibbare KI im Mittelstand.