Begrifflich lohnt sich eine erste Unterscheidung. Model Theft im engeren Sinne meint die direkte, unrechtmäßige Aneignung eines Modells als Artefakt – etwa das Kopieren der Modelldateien mitsamt ihren Gewichten von einem Server, einem Laptop oder einem Speichermedium. Es ist im Kern ein klassischer Datendiebstahl, der sich zufällig auf ein KI-Modell bezieht. Model Extraction dagegen ist subtiler: Hier wird ein Modell nicht direkt entwendet, sondern über seine legitime Schnittstelle so intensiv befragt, dass sich aus den Eingaben und den zugehörigen Antworten ein funktionales Abbild rekonstruieren lässt. Am Ende steht ein Ersatzmodell, das dem Original in seinem Verhalten nahekommt, ohne dass je eine Datei kopiert wurde.
Beide Phänomene laufen auf dasselbe Ergebnis hinaus: Der Wettbewerbsvorteil, den ein Unternehmen durch sein Modell hat, wird untergraben. Wer ein leistungsfähiges Modell über Monate entwickelt und teuer trainiert hat, muss damit rechnen, dass ein Nachbau einen Bruchteil dieses Aufwands kostet. Genau diese Asymmetrie – hohe Kosten für das Original, geringe Kosten für die Kopie – macht Modelldiebstahl wirtschaftlich attraktiv und damit zu einem realen Risiko für jeden, der KI-Modelle als Kern seines Geschäfts betreibt.
Um Model Theft ernst zu nehmen, hilft ein Blick darauf, was ein Modell überhaupt wert macht. Der Wert steckt selten in der öffentlich bekannten Grundarchitektur – die ist oft dokumentiert oder gar quelloffen. Der Wert liegt in der Kombination aus drei Dingen: erstens den trainierten Parametern (den Gewichten), die das gesamte gelernte Wissen des Modells verkörpern; zweitens den Daten, mit denen trainiert oder feinjustiert wurde und die häufig proprietär und mühsam kuratiert sind; und drittens dem Erfahrungswissen darüber, wie das Modell konfiguriert, optimiert und in einen produktiven Kontext eingebettet wurde. Diese Kombination ist schwer zu replizieren – und genau deshalb ein Ziel.
Für viele mittelständische Unternehmen entsteht dieser Wert nicht durch das Training riesiger Basismodelle, sondern durch das Feinjustieren vorhandener Modelle auf den eigenen Anwendungsfall. Ein auf firmeneigene Serviceanfragen trainiertes Modell, ein auf Fachterminologie spezialisierter Textklassifikator oder ein Prognosemodell für die eigene Produktion kann ein zentrales Alleinstellungsmerkmal sein. Wird es kopiert oder nachgebaut, verliert das Unternehmen genau den Vorsprung, den es sich erarbeitet hat.
Model Theft gehört in eine Familie von KI-Sicherheitsrisiken, die sich teils überlappen, aber unterschiedliche Ziele verfolgen. Während Data Poisoning darauf abzielt, ein Modell durch manipulierte Trainingsdaten zu verfälschen, und Prompt Injection ein bereits laufendes System zu unerwünschtem Verhalten verleitet, geht es beim Modelldiebstahl nicht um Manipulation, sondern um Aneignung. Verwandt sind Angriffe wie Model Inversion und Membership Inference, die aus einem Modell Rückschlüsse auf seine Trainingsdaten ziehen – sie stehlen zwar nicht das Modell selbst, gefährden aber vertrauliche oder personenbezogene Informationen, die im Modell mitschwingen. Diese Nachbarschaft ist wichtig, weil ein durchdachtes Schutzkonzept meist mehrere dieser Risiken zugleich adressiert.
Der prominenteste und zugleich am schwersten fassbare Weg ist die Extraction über eine öffentlich erreichbare Schnittstelle. Die Grundidee lässt sich neutral so beschreiben: Ein Modell verrät durch seine Antworten viel über sein gelerntes Verhalten. Wer es in sehr großem Umfang mit gezielten Eingaben befragt und die Antworten sammelt, kann daraus ein eigenes Modell trainieren, das dem Original nachempfunden ist. Aus Verteidigersicht ist entscheidend, dass ein solcher Vorgang sich in der Regel als ungewöhnlich intensives und systematisches Nutzungsmuster äußert – und genau daran lässt er sich erkennen und begrenzen (siehe Kapitel 05).
Wichtig ist die Einordnung: Nicht jede intensive Nutzung ist ein Angriff, und die Grenze zwischen legitimer Vielnutzung und Extraction ist fließend. Deshalb setzen Schutzmaßnahmen hier nicht auf pauschale Verbote, sondern auf Maß und Beobachtung – etwa auf Nutzungsgrenzen, Authentifizierung und die Auswertung von Zugriffsmustern. Ziel ist nicht, legitime Kunden auszubremsen, sondern das wirtschaftliche Kalkül eines Nachbaus zu verschlechtern.
Weniger elegant, aber oft wirksamer ist der direkte Zugriff auf das Modell als Datei. Modelle liegen letztlich als Dateien auf Servern, in Container-Umgebungen, in Backups oder auf Entwickler-Rechnern. Überall dort, wo Menschen oder Systeme Zugriff haben, besteht ein potenzieller Abflusspunkt – sei es durch böswillige Insider, durch versehentlich zu weit gefasste Berechtigungen, durch ungeschützte Speicherorte oder durch klassische IT-Sicherheitslücken. Aus dieser Perspektive ist Model Theft in weiten Teilen ein Spezialfall des Schutzes vertraulicher Daten: Wer seine Modell-Artefakte wie Kronjuwelen behandelt und den Zugriff strikt begrenzt, schließt einen Großteil dieser Wege.
Auch die Lieferkette spielt eine Rolle. Wird ein Modell an Dienstleister, Entwicklungspartner oder in Cloud-Umgebungen weitergegeben, verlässt es die unmittelbare Kontrolle des Unternehmens. Ohne klare vertragliche und technische Leitplanken kann es dort kopiert, weiterverwendet oder unzureichend geschützt werden. Dieser Aspekt verbindet die technische mit der organisatorisch-rechtlichen Ebene, die Kapitel 06 vertieft.
Eine eigene Kategorie bilden Angriffe, die nicht das Modell, sondern die in ihm enthaltenen Informationen ins Visier nehmen. Bei der Model Inversion versucht ein Angreifer, aus den Ausgaben eines Modells Merkmale der ursprünglichen Trainingsdaten zu rekonstruieren. Bei der Membership Inference geht es um die Frage, ob ein bestimmter Datensatz Teil des Trainings war – was bei personenbezogenen Daten heikel ist. Beide Angriffe stehlen zwar nicht das Modell im Sinne des Geschäftsgeheimnisses, berühren aber Datenschutz und Vertraulichkeit unmittelbar. Deshalb gehören sie in ein umfassendes Schutzkonzept, auch wenn sie strenggenommen kein Model Theft im engeren Sinne sind. Auf welchem Weg genau solche Rückschlüsse gelingen, ist hier bewusst nicht Gegenstand – für die Verteidigung genügt das Wissen, dass die Menge und der Detailgrad der ausgegebenen Informationen ein Einfallstor sein können.
Die Modellgewichte sind das offensichtlichste Ziel. Sie sind das Ergebnis des gesamten Trainings und enthalten in verdichteter Form alles, was das Modell gelernt hat. Wer sie besitzt, besitzt faktisch das Modell – unabhängig davon, wie teuer das Training war. Deshalb sind die Gewichtsdateien das Asset, das den strengsten Zugriffsschutz verdient: verschlüsselte Speicherung, strikt begrenzter Zugang und eine klare Kontrolle darüber, wer sie exportieren oder kopieren darf.
Die Architektur und die zugehörigen Hyperparameter sind demgegenüber weniger geheimnisträchtig, weil viele Grundarchitekturen öffentlich bekannt sind. Der eigentliche Wert steckt in den konkreten Konfigurations- und Optimierungsentscheidungen, die im Betrieb gereift sind. Diese lassen sich zwar nicht so einfach kopieren wie eine Datei, verkörpern aber Erfahrungswissen, das ein Wettbewerber gern übernehmen würde. Sie gehören deshalb in die vertrauliche Dokumentation und nicht in öffentlich zugängliche Ablagen.
Für viele Unternehmen sind nicht die Gewichte, sondern die Daten das eigentliche Kronjuwel. Ein sorgfältig kuratierter, annotierter und über Jahre gepflegter Datensatz ist häufig der größte und am schwersten ersetzbare Wert – und zugleich der sensibelste, wenn er personenbezogene oder vertrauliche Informationen enthält. Modelldiebstahl im weiteren Sinne bedroht diese Daten auf zwei Wegen: direkt, wenn die Datensätze selbst kopiert werden, und indirekt, wenn über Inferenz-Angriffe Rückschlüsse auf sie möglich sind. Der Schutz der Trainingsdaten ist damit sowohl eine Frage des geistigen Eigentums als auch des Datenschutzes.
Ein häufig übersehenes Asset sind die Prompts und Systemanweisungen, mit denen ein Unternehmen ein Modell steuert. Gerade bei Anwendungen, die auf vorhandenen Basismodellen aufsetzen, steckt viel Wettbewerbsvorteil in der Kunst, das Modell durch gut entwickelte Anweisungen, Vorlagen und Kontextinformationen zum gewünschten Verhalten zu bringen. Diese Prompt-Logik ist quasi der „Bauplan“ der Anwendung – und sie ist oft erstaunlich schlecht geschützt, etwa weil sie im Klartext in Konfigurationen liegt oder über unbedachte Ausgaben preisgegeben werden kann. Wer in Prompt-Entwicklung investiert, sollte diese Arbeit ebenso als geistiges Eigentum behandeln wie ein trainiertes Modell.
Der offensichtlichste Schaden ist der Verlust geistigen Eigentums. Ein Modell, das ein Unternehmen von Wettbewerbern abhebt, verliert seinen Wert, sobald es kopiert oder funktional nachgebaut wird. Der Vorsprung, der monate- oder jahrelange Investitionen in Daten, Rechenleistung und Fachwissen verkörpert, schmilzt – während der Nachahmer nur einen Bruchteil dieses Aufwands trägt. Für Unternehmen, deren Geschäftsmodell auf einem differenzierenden Modell beruht, ist das eine existenzielle Bedrohung.
Ein zweites, oft unterschätztes Risiko betrifft den Datenschutz. Modelle, die auf personenbezogenen Daten trainiert wurden, können unter bestimmten Umständen Informationen über diese Daten preisgeben – etwa über die bereits erwähnten Inferenz-Angriffe. Wird ein solches Modell gestohlen oder extrahiert, verlässt nicht nur das Modell die Kontrolle des Unternehmens, sondern potenziell auch ein Fenster auf die zugrunde liegenden Daten. Damit wird aus einem IP-Problem zugleich ein datenschutzrechtliches, das Meldepflichten und Betroffenenrechte berühren kann. Ob und in welchem Umfang ein konkreter Vorfall datenschutzrechtlich relevant ist, ist eine Frage des Einzelfalls und gehört in fachkundige Hände.
Über den unmittelbaren IP-Verlust hinaus entstehen weitere Folgeschäden, die sich gegenseitig verstärken:
Diese Risiken sind selten gleich verteilt. Für ein Unternehmen, dessen Modell nur intern Prozesse unterstützt, wiegt der IP-Verlust weniger schwer als für einen Anbieter, der sein Modell als Produkt vermarktet. Deshalb ist die nüchterne Frage „Was würde es uns konkret kosten, wenn dieses Modell morgen bei einem Wettbewerber läge?“ der beste Ausgangspunkt, um den angemessenen Schutzaufwand zu bestimmen – nicht mehr, aber auch nicht weniger.
Die Grundidee defensiver KI-Sicherheit lautet Verteidigung in der Tiefe: Statt auf eine einzelne Schutzwand zu setzen, werden mehrere Schichten kombiniert, sodass das Versagen einer Schicht nicht sofort zum Totalverlust führt. Für den Schutz von Modellen bedeutet das, Schnittstelle, Ausgaben, Speicherung und Beobachtung parallel abzusichern. Die folgenden Bausteine sind bewusst herstellerneutral beschrieben.
An der Schnittstelle sind zwei Maßnahmen besonders wirksam. Rate Limiting und Nutzungsquoten begrenzen, wie viele Anfragen ein Konto in einem Zeitraum stellen darf. Da eine Extraction auf sehr großen Abfragemengen beruht, erhöht eine sinnvolle Begrenzung den Aufwand deutlich – ein Nachbau wird langsamer, teurer und auffälliger. Die Kunst liegt darin, Grenzen so zu setzen, dass sie legitime Vielnutzer nicht stören, ungewöhnliche Massenabfragen aber ausbremsen. Ergänzend sorgt eine starke Authentifizierung dafür, dass jede Nutzung einem Konto zugeordnet ist. Das verhindert anonyme Massenzugriffe und schafft die Grundlage, um auffälliges Verhalten überhaupt einem Verursacher zuzuordnen und gegebenenfalls einzuschreiten.
Eine zweite Stellschraube ist die Beschränkung dessen, was ein Modell nach außen gibt. Je detailreicher und informationsreicher eine Ausgabe ist, desto mehr lässt sich daraus ableiten – sowohl für einen Nachbau als auch für Inferenz-Rückschlüsse. Deshalb gilt der Grundsatz der Sparsamkeit: Ausgaben auf das fachlich Notwendige begrenzen, interne Zusatzinformationen nicht unnötig mitliefern und rohe, besonders aussagekräftige Detailwerte zurückhaltend behandeln. Parallel dazu ist die Erkennung von Anomalien zentral: Systematische, ungewöhnlich gleichförmige oder extrem umfangreiche Nutzungsmuster können auf eine Extraction hindeuten. Ein Monitoring, das solche Muster meldet, verwandelt einen unbemerkten Abfluss in einen erkennbaren Vorfall, auf den man reagieren kann.
Watermarking verfolgt einen anderen Zweck: Es verhindert Diebstahl nicht, sondern macht ihn nachweisbar. Dabei wird einem Modell oder seinen Ausgaben ein unauffälliges, robustes Kennzeichen mitgegeben, das später erlaubt, ein verdächtiges Fremdmodell als Ableitung des eigenen zu erkennen. Das ist vor allem als Grundlage für rechtliche Schritte wertvoll. Ergänzt wird all dies durch den klassischen Schutz der Modell-Artefakte selbst: verschlüsselte Speicherung der Gewichtsdateien, strikt nach dem Prinzip der minimalen Rechte vergebene Zugriffe, abgesicherte Backups und eine kontrollierte Ausleitung. Weil viele Diebstähle über den direkten Dateizugriff laufen, ist dieser unspektakuläre Baustein oft der wirksamste.
Der wirksamste organisatorische Hebel ist das Prinzip der minimalen Rechte: Zugriff auf Modelle, Trainingsdaten und Prompt-Logik erhält nur, wer ihn für seine Aufgabe wirklich benötigt – und nur so lange, wie er ihn braucht. Das klingt selbstverständlich, wird in der Praxis aber oft verletzt, etwa durch großzügig vergebene Sammelberechtigungen, vergessene Zugänge ausgeschiedener Mitarbeitender oder breit geteilte Entwicklungsumgebungen. Ein regelmäßiger, dokumentierter Blick darauf, wer worauf zugreifen kann, deckt solche Lücken auf und schließt sie.
Aus dem Prinzip der minimalen Rechte folgt ein sauberes Rollen- und Berechtigungskonzept für die gesamte KI-Umgebung. Entscheidend ist, dass Zugriffe nicht nur begrenzt, sondern auch nachvollziehbar sind: Wer hat wann auf welches Modell oder welchen Datensatz zugegriffen, wer hat Exporte oder Kopien vorgenommen? Eine solche Protokollierung wirkt doppelt – präventiv, weil sie unbedachtes Verhalten hemmt, und aufklärend, weil sie im Verdachtsfall nachvollziehbar macht, was geschehen ist. Wichtig ist dabei, die Protokollierung selbst datenschutzkonform auszugestalten; Mitbestimmungs- und Datenschutzaspekte sind zu berücksichtigen und im Einzelfall fachkundig zu prüfen.
Sobald Modelle, Daten oder Prompts die eigenen vier Wände verlassen – etwa zu Dienstleistern, Entwicklungspartnern oder in Cloud-Umgebungen – wird der vertragliche Schutz zentral. Geheimhaltungsvereinbarungen (NDAs) verpflichten Partner zur Vertraulichkeit; Verträge zur Auftragsverarbeitung regeln den Umgang mit personenbezogenen Daten; Lizenz- und Nutzungsbedingungen legen fest, was mit einem Modell geschehen darf und was nicht. Für die eigenen Beschäftigten schaffen klare arbeitsvertragliche Regelungen und Geheimhaltungsklauseln eine wichtige Grundlage. Auch in die andere Richtung ist Sorgfalt geboten: Wer fremde Modelle oder Daten nutzt, sollte deren Lizenzbedingungen kennen, um nicht selbst gegen Auflagen zu verstoßen. Die konkrete Ausgestaltung solcher Verträge gehört in fachjuristische Hände.
Ein zentraler, oft unterschätzter Punkt betrifft den Schutz als Geschäftsgeheimnis. Nach dem einschlägigen Rechtsrahmen genießen Informationen den Schutz als Geschäftsgeheimnis in der Regel nur dann, wenn ihr Inhaber angemessene Geheimhaltungsmaßnahmen ergriffen hat. Für KI-Modelle bedeutet das eine wichtige Konsequenz: Der rechtliche Schutz und der technisch-organisatorische Schutz hängen zusammen. Wer sein Modell, seine Daten und seine Prompts nicht erkennbar als vertraulich behandelt, riskiert nicht nur den faktischen Abfluss, sondern womöglich auch den rechtlichen Schutzanspruch. Technische Zugriffsbeschränkungen, Vertraulichkeitsvermerke, NDAs und dokumentierte Prozesse zahlen damit unmittelbar auf die rechtliche Verteidigungsfähigkeit ein. Ob die getroffenen Maßnahmen im konkreten Fall als „angemessen“ gelten, ist eine Frage des Einzelfalls und mit einer Fachjurist:in zu klären.
Vereinfacht stehen sich zwei Grundmodelle gegenüber. Beim Self-Hosting betreibt ein Unternehmen ein Modell auf eigener oder selbst kontrollierter Infrastruktur. Beim API-Bezug nutzt es ein Modell, das ein Anbieter betreibt, über eine Schnittstelle. Beide Modelle haben eigene Stärken – und verschieben die Angriffsfläche für Model Theft in unterschiedliche Richtungen.
Self-Hosting spielt seine Stärken aus, wenn ein Unternehmen ein eigenes, differenzierendes Modell besitzt oder mit besonders sensiblen Daten arbeitet. Der große Vorteil ist die Datenhoheit: Modell, Trainingsdaten, Eingaben und Prompts verlassen die kontrollierte Umgebung nicht. Die Kehrseite ist Verantwortung: Der gesamte Schutz – vom Zugriffskonzept über die Verschlüsselung der Gewichtsdateien bis zur Absicherung der Infrastruktur – liegt beim Unternehmen selbst. Self-Hosting verlagert das Risiko also nicht weg, sondern in den eigenen Verantwortungsbereich, wo es aktiv gemanagt werden muss. Für Organisationen ohne ausreichende Sicherheitskompetenz kann das paradoxerweise riskanter sein als ein gut gewählter API-Bezug.
Der Bezug über eine API ist attraktiv, wenn ein Unternehmen keine eigene Modell-Differenzierung anstrebt, sondern leistungsfähige Basismodelle nutzen möchte, ohne Infrastruktur und Modellschutz selbst stemmen zu müssen. Der Schutz der Modelldateien liegt dann beim Anbieter. Der entscheidende Preis dafür ist jedoch, dass Eingaben und Prompts das Unternehmen verlassen. Damit verschiebt sich das Schutzthema: Nicht mehr die Gewichtsdatei ist das Hauptrisiko, sondern die Frage, was mit den eingespeisten Daten und den wertvollen Prompts beim Anbieter geschieht. Datenhoheit wird hier zur Vertrags- und Auswahlfrage – Standort der Verarbeitung, Zusagen zur Nicht-Weiterverwendung von Eingaben, Zertifizierungen und Transparenz des Anbieters werden zu zentralen Kriterien.
Der wichtigste Rat für den Mittelstand lautet: Verhältnismäßigkeit. Kein Unternehmen muss jeden denkbaren Angriff abwehren; es muss den Aufwand für einen Diebstahl so weit erhöhen, dass er sich mit Blick auf den Wert des Modells nicht lohnt. Ein absoluter Schutz existiert nicht – wohl aber ein angemessener. Die gute Nachricht: Viele Bausteine sind keine KI-Spezialität, sondern solide IT-Sicherheit. Wer bereits Zugriffskonzepte, Verschlüsselung und Protokollierung betreibt, muss diese „nur“ konsequent auf Modelle, Trainingsdaten und Prompts ausweiten.
Damit Modellschutz nicht im Sande verläuft, braucht es klare Verantwortlichkeit. In der Praxis bewährt sich, eine Person oder ein kleines Team an der Schnittstelle von IT-Sicherheit, Datenschutz und Fachbereich zu benennen, das den Überblick über die schützenswerten Assets behält und die Maßnahmen koordiniert. Ebenso wichtig ist ein Grundverständnis in der Breite: Beschäftigte, die mit Modellen und Prompts arbeiten, sollten wissen, dass diese ein schützenswertes Gut sind – und welche einfachen Regeln gelten. So wird aus einer technischen Einzelmaßnahme eine tragfähige, gelebte Schutzkultur.
Der EU AI Act ist im Kern ein Produktsicherheits- und Grundrechtegesetz. Für Hochrisiko-Systeme verlangt er nach aktuellem Stand unter anderem ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit. Der Schutz eines Modells vor unbefugtem Zugriff und Manipulation zahlt unmittelbar auf diese Sicherheitsanforderung ein: Ein Modell, das gestohlen oder heimlich nachgebaut werden kann, ist nicht angemessen abgesichert. Maßnahmen gegen Model Theft sind damit nicht nur IP-Schutz, sondern können zugleich Teil der Erfüllung solcher Sicherheitspflichten sein – für Anbieter wie in Teilen für Betreiber. Ob und in welchem Umfang ein konkretes System betroffen ist und welche Pflichten greifen, ist eine Frage des Einzelfalls und mit einer Fachjurist:in zu klären.
Die DSGVO kommt ins Spiel, sobald ein Modell auf personenbezogenen Daten trainiert wurde oder solche verarbeitet. Hier verbindet sich Modellschutz mit Datenschutz auf mehreren Ebenen. Erstens erhöhen die bereits erwähnten Inferenz-Risiken die Wahrscheinlichkeit, dass aus einem Modell Rückschlüsse auf personenbezogene Trainingsdaten möglich sind – ein Datenschutzthema. Zweitens verlangt die DSGVO angemessene technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten; viele Bausteine des Modellschutzes – Zugriffsbeschränkung, Verschlüsselung, Protokollierung – erfüllen diese Anforderung mit. Drittens berühren Betriebsmodelle wie der API-Bezug die Datenhoheit und werfen Fragen zu Auftragsverarbeitung und Verarbeitungsort auf. Beide Regime gelten parallel und ergänzen sich; sie verdrängen einander nicht.
Für die Praxis ist das eine gute Nachricht: Wer sein Modell konsequent schützt, arbeitet zugleich an mehreren Compliance-Zielen. Zugriffsbeschränkungen, ein sauberes Rollenkonzept, Verschlüsselung, Protokollierung und geprüfte Anbieterverträge sind Bausteine, die sowohl dem Schutz geistigen Eigentums als auch den Sicherheits- und Datenschutzanforderungen dienen. Statt Modellschutz, AI-Act-Konformität und DSGVO getrennt zu betreiben, lohnt es sich, sie als ein zusammenhängendes Sicherheits- und Governance-Thema zu behandeln – idealerweise eingebettet in eine schlanke KI-Governance und, wo sinnvoll, gestützt auf ein Managementsystem für KI. Welche konkreten Pflichten im Einzelfall gelten, ist fachjuristisch zu bewerten.
