Das Dilemma von IT-Teams: Führt eine AI-Domain wirklich AI-Traffic?

Das Dilemma von IT-Teams: Führt eine AI-Domain wirklich AI-Traffic?

Dass .ai in der Adresse des Pakets vorkommt, beweist nicht, dass das Paket im Netzwerk Anfragen an ein KI-Modell sendet; das können nur Anfrageprotokoll, Zielendpunkt und übertragene Daten belegen.

Diese Unterscheidung wirkt klein, hat für die Unternehmens-IT jedoch erhebliche Folgen. Die Domain einer Lernplattform kann „ai“ enthalten, ihre Kommunikation kann künstliche Intelligenz erwähnen, und die Plattform kann KI sogar in einigen Workflows einsetzen. Nichts davon bedeutet, dass das gerade geprüfte SCORM-Training mit einem KI-Service kommuniziert.

Ein SCORM-Paket, das ein Unternehmen für eine Arbeitssicherheits- oder DSGVO-Schulung hochlädt, kann ausschließlich HTML, JavaScript, Bilder, Videos, Fragen und die standardmäßige SCORM-Kommunikation enthalten. In diesem Fall schreibt das Paket Fortschritt, Punktzahl, Abschluss und gelegentlich Zeitangaben in das LMS. Das ist das tatsächliche Verhalten im Netzwerk. Nicht das, was der Domainname suggeriert.

Die zentrale Frage für IT-Teams sollte lauten:

Nicht: „Wie wird dieser Inhalt genannt?“, sondern: „An welches Ziel sendet der Browser welche Daten und zu welchem Zweck?“

Dieser Ansatz wirkt manchmal aufwendiger. Doch genau das ist Sicherheit ein Stück weit: nicht Etiketten, sondern Verhalten prüfen. Allein anhand der Aufschrift „Chemiebaukasten“ auf einer Schachtel lässt sich nicht erkennen, was darin ist. Menschen vertrauen gern auf Etiketten; Netzwerkpakete respektieren diese Gewohnheit eher wenig.

Eine Domain ist keine Technologieklassifizierung

Eine Domainendung ist keine technische Aussage. .ai, .com, .org oder eine andere Endung erklärt weder, mit welchen Services eine Anwendung kommuniziert, wo Daten verarbeitet werden noch welche Informationen vom Client abfließen.

Ebenso ist das Wort „AI“ in der Broschüre eines Produkts für sich genommen kein Sicherheitsbefund. Die Broschüre kann beschreiben, bei welchen Problemen das Produkt künstliche Intelligenz nutzt. Ein Netzwerkprotokoll zeigt hingegen, was die aktuell ausgeführte Komponente tatsächlich tut. Beides zu verwechseln, verwandelt eine Architekturprüfung in das Lesen eines Marketingtexts.

Bei Nextrain kann KI für die Erstellung von Trainings, die Strukturierung von Inhalten, die Generierung von Fragen, die Gestaltung von Lernreisen und die Erstellung von Berichten eingesetzt werden. Daneben können SCORM-1.2- und SCORM-2004-Pakete importiert werden; Inhalte, die ein Unternehmen bereits erstellt oder von anderer Stelle bezogen hat, lassen sich also unter einem Dach verwalten.

Diese beiden Situationen sind voneinander zu trennen:

Geprüfte Situation Frage des IT-Teams Erwarteter Nachweis
Statisches SCORM-Training Ruft das Paket außerhalb des LMS einen Service auf? Browser-Netzwerkprotokolle, DNS-Protokolle, Proxy-Logs
SCORM-LMS-Kommunikation Welche Lerndaten schreibt das Paket ins LMS? SCORM-API-Aufrufe, Abschluss- und Punktzahlaufzeichnungen
KI-gestützte Interaktion Wird tatsächlich eine KI-Funktion aufgerufen? Anfrage-URL, Anfragekörper, Antwortstrom
Nutzung externer Inhalte Woher stammen Videos, Fonts, Analysen oder Medien? Domains Dritter, CDN- und Medienaufrufe
Datenschutzprüfung Enthält die Anfrage personenbezogene Daten oder sensible Inhalte? Payload-Prüfung, Maskierungs- und Zugriffsprotokolle

Die vielleicht wichtigste Zeile der Tabelle ist die dritte: Wird tatsächlich eine KI-Funktion aufgerufen? Dass es innerhalb eines Produkts eine KI-Funktion gibt, bedeutet nicht, dass jeder Kurs, jeder Nutzer und jede Sitzung diese Funktion verwendet.

Das ist, als würde man in einem elektrifizierten Gebäude annehmen, dass in jedem Raum gleichzeitig ein Ofen läuft. Kabel können vorhanden sein; die Last entsteht erst, wenn der Schalter betätigt wird.

Was macht ein SCORM-Paket eigentlich?

SCORM ist ein Standard, der es Trainings ermöglicht, mit dem LMS zu kommunizieren. Ein Paket enthält in der Regel Inhaltsdateien, ein Inhaltsmanifest und JavaScript, das den Lernfortschritt steuert. Wenn das Paket im LMS geöffnet wird, kann der Inhalt über den Browser die standardmäßige SCORM-API erreichen und Informationen wie diese übermitteln:

Die Unterschiede zwischen SCORM 1.2 und SCORM 2004 können wichtig sein; für die Prüfung von KI-Traffic bleibt die Kernfrage jedoch gleich: Mit welchen Zielen kommuniziert das Paket außerhalb der standardmäßigen Lernaufzeichnungen des LMS?

Ein SCORM-Paket ist technisch gesehen Webinhalt, der im Browser läuft. Deshalb kann speziell in das Paket eingefügter JavaScript-Code, soweit dies erlaubt ist, versuchen, verschiedene Netzwerkanfragen zu erzeugen. Ein Paket kann externe Bilder laden, Videos aufrufen, Analysedaten senden oder Anfragen an eine API stellen. Wenn der Designer dies wünscht, kann es sogar einen Endpunkt eines KI-Service ansprechen.

Doch zwischen „kann“ und „tut“ liegt ein Unterschied so groß wie ein Netzwerk-Gateway.

Der SCORM-Standard selbst erfordert keine KI-Aufrufe. Der Standard befasst sich mit der Speicherung des Lernstatus [SCORM 1.2, 2001; SCORM 2004, 2004]. Ein SCORM-Paket automatisch mit dem Label „KI-Risiko“ zu versehen, ist daher keine technische Klassifizierung, sondern der vorschnelle Cousin der Vorsicht.

Wohin sollte das IT-Team zuerst schauen?

Eine Sicherheitsbewertung sollte den Datenfluss abbilden, statt ein Produkt mit einem einzigen Wort zu klassifizieren. Der richtige Ausgangspunkt besteht meiner Ansicht nach darin, die Frage „Gibt es KI?“ in besser beobachtbare Teile zu zerlegen.

1. Paketinhalt entpacken und Manifest lesen

Ein SCORM-Paket ist normalerweise ein komprimiertes Archiv. Die Prüfung kann mit folgenden Dateien beginnen:

Das Manifest zeigt den Einstiegspunkt und die Ressourcen des Pakets. Es beschreibt möglicherweise nicht das gesamte Netzwerkverhalten; für das Verständnis der Paketstruktur ist es jedoch ein guter Ausgangspunkt.

In JavaScript-Dateien sollten insbesondere folgende Ausdrücke gesucht werden:

fetch(
XMLHttpRequest
WebSocket
EventSource
sendBeacon
axios
https://
wss://

Das Auffinden dieser Begriffe ist nicht automatisch ein Risikobefund. Moderne Webinhalte können Netzwerkanfragen stellen. Die Prüfung endet hier nicht; untersucht wird, an welche Domain, mit welchen Daten und zu welchen Zeitpunkten dieser Aufruf erfolgt.

Dass ein Kurs zum Laden eines Videos eine Medienadresse aufruft, ist nicht dasselbe wie das Senden einer Freitextfrage eines Nutzers an einen Endpunkt eines generativen Modells. Beides ist „Traffic“, doch Risikoprofile, Datenkategorien und Kontrollanforderungen unterscheiden sich.

2. Das tatsächliche Netzwerkprotokoll im Browser beobachten

Ein SCORM-Paket sollte in einer Testumgebung mit dem normalen Nutzerablauf ausgeführt werden. Es genügt nicht, nur den Startbildschirm zu öffnen. Quizze sollten bearbeitet, Abschnitte durchlaufen, Videos geöffnet, vorhandene Freitextfelder ausgefüllt und der Abschlussprozess beendet werden.

Anschließend sollten in den Netzwerkprotokollen des Browsers folgende Fragen gestellt werden:

Besonders POST-Anfragen verdienen Aufmerksamkeit. Sie können darauf hinweisen, dass Daten vom Client gesendet werden. Dennoch ist nicht jedes POST ein KI-Aufruf: Auch die Speicherung von Punktzahlen, Formularübermittlungen, Sitzungsverwaltung oder Ereignisaufzeichnungen können dahinterstehen. Ohne diese Unterscheidung zu dem Schluss „Wir haben POST gesehen, also gibt es KI“ zu kommen, ist, als würde man bei Regen jede Wolke für einen Brand halten.

3. DNS-, Proxy- und Firewall-Protokolle gemeinsam lesen

Browser-Entwicklertools sind nützlich; die Sicht auf das Unternehmensnetzwerk ist jedoch umfassender. Das IT-Team sollte, wenn möglich, folgende Protokolle im selben Zeitraum vergleichen:

Wenn ein Inhalt nur auf genehmigte Domains zugreift, ist das ein nachvollziehbares und begrenztes Netzwerkverhalten. Aufrufe neuer oder unbekannter Endpunkte sollten hingegen untersucht werden. Das Kriterium sollte nicht lauten: „Sieht der Name nach AI aus?“ Einige KI-Services können gewöhnlich wirkende Domains verwenden; manche vollständig KI-freien Plattformen können dagegen die Endung .ai haben.

Aus Sicht des Netzwerks sind Endungen Dekoration, Routing-Protokolle dagegen Beweise.

Welche Signale sind wichtig, um KI-Traffic zu unterscheiden?

KI-Traffic hat keine einzige technische Signatur. Einige Hinweise können die Prüfung jedoch an die richtige Stelle lenken.

Bei einer generativen KI-Interaktion ist häufig Folgendes zu sehen:

Dagegen sind die folgenden Verhaltensweisen für sich genommen keine KI-Aufrufe:

Bei Nextrain können Interaktionen wie KI-gestützte Hilfe innerhalb eines Trainings gestaltet werden. Wird eine solche Interaktion verwendet, muss das IT-Team sie als separaten Datenfluss bewerten. Das Verhalten eines klassischen SCORM-Pakets ohne KI-Interaktion sollte dagegen anhand des Paketinhalts und der Netzwerkspuren bewertet werden. Dass beide auf derselben Plattform vorhanden sind, zeigt nicht, dass sie dasselbe Netzwerkverhalten haben.

An dieser Stelle denke ich an die hartnäckige Unterscheidung, die Kalde beim Schreiben von Szenarien trifft: Was den Ausgang einer Geschichte verändert, ist nicht, vor welcher Tür eine Figur steht, sondern welche Entscheidung sie trifft. Auch bei der Netzwerkprüfung ist die Domain die Tür; die Anfrage ist die Entscheidung. Die Sicherheitsentscheidung sollte auf Letzterem beruhen.

Warum ist „Alles sperren“ keine ausreichende Richtlinie?

Dass Unternehmen beim Thema künstliche Intelligenz vorsichtig sind, ist nachvollziehbar. Insbesondere bei Daten im Anwendungsbereich der DSGVO, Kundeninformationen, Geschäftsgeheimnissen, Gesundheitsdaten oder Leistungsdaten von Mitarbeitenden ist Vorsicht kein Zusatz, sondern eine Designvoraussetzung.

Doch alles in einer Kategorie zu sperren, kann zwei unterschiedliche Kosten unsichtbar machen:

  1. Tatsächliche Risiken können übersehen werden.
    Auch ein Service ohne .ai-Endung kann Daten nach außen übertragen. Ein Domainfilter ersetzt keine Kontrolle des Datenflusses.

  2. Unbedenkliche oder erforderliche Lernabläufe können unterbrochen werden.
    Wird ein SCORM-Inhalt ohne KI-Aufrufe allein wegen der Assoziation seines Domainnamens gesperrt, können Mitarbeitende nicht auf das Training zugreifen; die IT kann zugleich nicht eindeutig erklären, welches technische Verhalten sie blockiert hat.

Eine interessantere Situation, die mir begegnet ist: Dasselbe Unternehmen kann einerseits sagen: „Lasst uns alles sperren, was KI enthält“, und andererseits fragen, warum der Schulungsbericht nicht aktuell ist. Dieser Widerspruch ist nicht böswillig. Menschen denken den Schutz vor Risiken und die Aufrechterhaltung des Betriebs oft auf getrennten Bildschirmen. Systeme müssen jedoch beides gleichzeitig bewältigen.

Eine bessere Richtlinie trifft vor einem kategorischen Verbot folgende Unterscheidungen:

Das lockert die Sicherheit nicht. Im Gegenteil: Es macht die Kontrolle präziser.

Praktische Checkliste für die Prüfung von SCORM und KI

IT-, Informationssicherheits-, Rechts- und Schulungsteams betrachten dieselbe Datei mit unterschiedlichen Fragen. Am sinnvollsten ist es, die Bewertung nicht einem einzigen Team zu überlassen, ohne dabei Verantwortlichkeiten zu verwischen.

Die folgende Checkliste kann für eine erste Bewertung verwendet werden:

Diese Liste ist kein bürokratisches Ritual. Eine gut geführte Prüfungsdokumentation ist verlässlicher als das Gedächtnis, wenn sechs Monate später die Frage kommt: „Warum hatten wir diesen Zugriff freigegeben?“ Das menschliche Gedächtnis ist erstaunlich kreativ; Logs sind es deutlich weniger.

Fazit: Die Broschüre beschreibt Absicht, das Netzwerkverhalten beweist sie

Ein Unternehmen kann Grenzen für den Einsatz künstlicher Intelligenz setzen. Es kann sogar sehr strenge Grenzen setzen. Das ist eine vollkommen legitime Managemententscheidung. Doch die technische Entsprechung dieser Grenze sollte nicht eine Domainendung, eine Produktkategorie oder ein einzelnes Wort in einer Broschüre sein.

Die Prüfung durch das IT-Team sollte auf drei Ebenen erfolgen:

  1. Was enthält das Paket?
    Manifest, JavaScript, externe Ressourcen und Konfigurationen.

  2. Was tut der Browser?
    Netzwerkanfragen, Ziele und Datenkörper im tatsächlichen Nutzerablauf.

  3. Was bedeutet das für das Unternehmen?
    DSGVO, Datenklassifizierung, erlaubte Endpunkte, Zugriffskontrolle und betriebliche Auswirkungen.

Ein System mit einer KI-Funktion ist nicht dasselbe wie ein System, das in jeder Sitzung KI-Traffic erzeugt. Auch eine .ai-Domain ist kein Beleg für einen KI-Aufruf. Der Beleg ist die Anfrage, die im Netzwerk lebt, einen Zeitstempel hat und deren Ziel und Payload sichtbar sind.

Für IT-Teams sollte der sicherste Reflex nicht „alles sperren“ sein, sondern zu erkennen, welche Tür tatsächlich geöffnet wird. Dieser Ansatz nimmt Sicherheit ernster und lässt Schulungs-, Compliance- und Arbeitssicherheitsprozesse nicht unnötig im Dunkeln.

Hinweise

  1. SCORM 1.2, 2001. Standardisiertes technisches Modell für die Kommunikation von Lerninhalten mit einem LMS.
  2. SCORM 2004, 2004. Erweiterter SCORM-Standard einschließlich Regeln für Sequenzierung und Navigation.