Woher stammt dein KI-Modell — und weiß das überhaupt jemand?

Ich dokumentiere meinen Weg in die KI-Sicherheit öffentlich. Diesmal habe ich im TryHackMe-Raum „KI-Modelle & Daten" etwas gemacht, das meiner späteren Beratungsarbeit sehr nahekommt: ein kleines Audit an einem KI-Modell. Keine spektakuläre Live-Attacke — sondern genau das, was im echten Leben am Anfang steht: die Dokumentation lesen und die Risiken bewerten. Modellkarte, Angaben zu den Trainingsdaten, Trainingsverfahren, Lizenz, das ausgelieferte Modell-Artefakt. Stück für Stück durchgehen und jedes Detail einordnen.

Die wichtigste Erkenntnis kam nicht aus einem einzelnen Befund, sondern aus dem Gesamtbild. Sie lautet, etwas zugespitzt:

In der Praxis kann fast niemand zuverlässig nachvollziehen, womit ein fremdes KI-Modell trainiert wurde — woher die Daten stammen, was sie enthalten und ob sie manipuliert wurden.

Wichtig ist das Wort fremd. Wer ein Modell selbst mit einer sauber dokumentierten Daten-Pipeline trainiert, kann die Herkunft kennen. Das Problem ist die Black Box bei zugekauften und vortrainierten Modellen — also bei genau dem, was die allermeisten Unternehmen tatsächlich einsetzen. Und selbst Prüfwerkzeuge wie Membership-Inference-Tests (sie zeigen, ob bestimmte Daten im Training waren) oder Modellkarten liefern bestenfalls Stichproben, nie die ganze Wahrheit.

Hier sind die fünf Punkte, die mich am meisten zum Nachdenken gebracht haben.

1. Die Trainingsdaten sind eine Black Box vor der Black Box

Sicherheitsrisiken bei KI entstehen nicht erst, wenn das Modell live geht. Sie werden lange vorher geformt — in den Daten. Und genau dort beginnt das Problem: Trainingsdaten stammen oft aus schlecht dokumentierten, ungeprüften Quellen. Die meisten Organisationen haben keine verlässliche Antwort auf drei simple Fragen: Woher kamen die Daten? Was steckte drin? Wurden sie manipuliert?

Im Audit stand etwa, das Modell sei auf „öffentlich verfügbaren Web-Quellen wie Foren und Q&A-Seiten" trainiert worden. Klingt harmlos — ist es aber nicht. Foren und Q&A-Seiten sind von jedem editierbar. Das macht sie zu einem realistischen Einfallstor für Data Poisoning: Ein Angreifer kann gezielt Inhalte platzieren, die später in den Trainingskorpus gescraped werden. Bei einem Klassifikator kann so eine versteckte Hintertür entstehen — ein Auslöser, der das Modell zuverlässig falsch entscheiden lässt.

Meine Lektion fürs Bewerten: Die entscheidende Frage ist nicht „woher", sondern „Kann ein Angreifer diese Quelle beeinflussen — und ist die Filterung belegt?" Steht beides auf „nein", ist das kein Fußnoten-Risiko, sondern ein ernstes Finding.

2. Was einmal in den Gewichten steckt, bekommt man kaum wieder heraus

Beim massenhaften Web-Scraping landen routinemäßig Dinge im Datensatz, die dort nichts zu suchen haben: personenbezogene Daten (PII) und sogar echte Zugangsdaten, die irgendwo öffentlich herumlagen. Diese Informationen werden ins Modell eintrainiert — sie verteilen sich über die Gewichte.

Das Tückische: Anders als bei einem Datenbankeintrag gibt es kein „Zeile löschen". Eine einzelne Information aus einem trainierten Modell zuverlässig zu entfernen, ist praktisch extrem schwer. Es gibt zwar Forschung zum „Machine Unlearning", aber die ist unausgereift und unsicher. Der einzig wirklich verlässliche Weg ist oft, neu zu trainieren — teuer und aufwändig. Heißt im Klartext: Was an PII einmal drin ist, bleibt mit hoher Wahrscheinlichkeit drin. Über Memorization kann ein Modell solche Inhalte später sogar wieder ausspucken — ein direktes Datenschutz- und DSGVO-Thema.

3. „Effizienz"-Entscheidungen tragen unsichtbare Risiken

Beim Bauen eines Modells werden Entscheidungen getroffen, die nach reiner Technik klingen, aber das Sicherheitsverhalten verändern können — und die fast nie dokumentiert werden. Zwei Beispiele aus dem Raum:

• Quantisierung — das Modell wird „komprimiert", um Speicher und Rechenzeit zu sparen. Das kann das Verhalten messbar verändern, inklusive der Sicherheits-Ausrichtung.
• Föderiertes Lernen — das Modell wird verteilt über viele Teilnehmer trainiert. Klingt datenschutzfreundlich, öffnet aber neue Angriffsflächen, wenn einzelne Teilnehmer bösartig sind.

Das Muster dahinter: Organisationen kassieren den Effizienzgewinn — und kaufen sich dabei unbemerkt unbekannte Verhaltensänderungen mit ein, weil niemand sie aufschreibt.

4. Fine-Tuning erbt alles — auch die Schwächen

Die meisten Modelle in Unternehmen sind nicht von Grund auf neu trainiert, sondern aus einem Basismodell feinabgestimmt. Das Problem: Beim Fine-Tuning erbt man sämtliche Eigenschaften des darunterliegenden Modells — auch dessen Schwachstellen und dessen ungeklärte Herkunft.

Noch unangenehmer: Die mühsam antrainierte Sicherheits-Ausrichtung ist erstaunlich fragil. Forschung zeigt, dass schon eine Handvoll adversarialer Beispiele (in der Größenordnung von rund zehn) ausreicht, um die Schutzmechanismen spürbar aufzuweichen. Feinabgestimmte Modelle sind dadurch messbar anfälliger für Prompt Injection als ihre Basismodelle. Man kann die Sicherheit eines Modells also unbeabsichtigt verschlechtern, während man es eigentlich nur für die eigene Aufgabe anpassen wollte.

5. Niemand kann in ein Modell hineinschauen

Am Ende läuft alles auf eine fundamentale Eigenschaft hinaus: Die Gewichte eines trainierten Modells sind intransparent. Es sind Milliarden von Zahlen, aus denen sich nicht ablesen lässt, was das Modell „weiß" oder warum es so entscheidet, wie es entscheidet.

Sicherheitstests können dieses Verhalten deshalb nur stichprobenartig abtasten, nie vollständig verifizieren. Und der wichtigste Transparenzmechanismus, den wir haben — die Modellkarte — ist freiwillig, häufig unvollständig und manchmal gar nicht vorhanden. Genau das hat mein kleines Audit greifbar gemacht: Ich konnte nur bewerten, was in der Doku stand. Alles, was nicht dokumentiert war, blieb ein blinder Fleck — und blinde Flecken sind im Sicherheitskontext immer das Risiko.

Die drei Fragen, die du vor jedem KI-Einsatz stellen solltest

Wenn ich dieses Audit auf einen praktischen Kern eindampfe, bleiben drei Fragen — und genau die gehören in jedes Beschaffungs- und Onboarding-Gespräch, bevor ein KI-Modell ins Unternehmen kommt:

• Woher stammt dieses Modell? — Basismodell, Anbieter, Lieferkette, Lizenz.
• Was steckt darin? — Welche Daten, aus welchen Quellen, mit welcher Filterung?
• Weiß das überhaupt jemand? — Gibt es belegte Antworten, oder nur Behauptungen?

In den meisten Fällen wird die ehrliche Antwort auf die dritte Frage „nein" lauten. Und das ist genau der Punkt: Man muss diese Unsicherheit nicht beseitigen können — aber man muss sie kennen, benennen und in die Risikobewertung aufnehmen.

Mein Fazit

Dieser Raum hat meine Perspektive verschoben. Ich hatte KI-Sicherheit vorher stark vom laufenden System her gedacht — Prompt Injection, Jailbreaks, Output-Filter. Aber die gefährlichsten Risiken werden viel früher geformt: in ungeprüften Daten-Pipelines, bei der Vorab-Schulung, beim Fine-Tuning — lange bevor überhaupt jemand an „Sicherheit" denkt. Und weil ein trainiertes Modell eine Black Box ist, kann man diese Altlasten hinterher kaum noch auflösen.

Für meine Arbeit heißt das: Ein KI-Audit fängt nicht beim API-Endpunkt an, sondern bei der Herkunft. Wer ein Modell einsetzt, übernimmt dessen gesamte Vergangenheit — die dokumentierte und die undokumentierte. Die richtigen Fragen zu stellen, ist dabei kein bürokratischer Akt, sondern die erste echte Sicherheitsmaßnahme.

Das war die nächste Station meiner Lernreise. Ich dokumentiere alles hier weiter — Schritt für Schritt, ehrlich, aus der Praxis.

▶ Lernreise auf YouTube verfolgen KI-Modell auditieren lassen