Leitport

WerkstattKI

Fremde KI-Werkzeuge prüfen — und was sich nicht prüfen lässt

Ein Werkzeug, das sich beim ersten Start ungefragt in die eigene Konfiguration schreibt, ist kein Einzelfall. Eine Prüfliste hilft — bis das Paket ein 123-MB-Binary mitliefert.

Wer KI-Werkzeuge einsetzt, installiert nicht nur ein Programm. Er installiert Anweisungen, die eine Maschine später als Auftrag liest — und die sich, anders als Code, nicht kompilieren lassen und deshalb auch niemand kompiliert.

Der Anlass für unsere Prüfliste war ein Anschauungsstück: ein frei verfügbares Erweiterungspaket, das sich beim ersten Lauf ungefragt in die globale Konfiguration des Nutzers schreibt — und im selben Dokument argumentiert, dass Rückfragen an den Menschen ein Zeichen von Schwäche seien. Beides zusammen ist die eigentliche Pointe: Das Werkzeug ändert die Arbeitsumgebung, und es bringt die Begründung gleich mit, warum man nicht nachfragen soll.

Die Liste, die vor der Installation steht

Verkürzt, aber vollständig genug, um sie zu benutzen:

Ein Prüfprogramm nimmt der Liste den mechanischen Teil ab: Es sucht nach unsichtbaren Zeichen, nach Symlinks, die aus dem geprüften Verzeichnis herausführen, und nach Konfigurationen, die sich selbst Rechte erteilen. Es ersetzt die Liste nicht. Die Fragen nach Quelle und Zweck kann kein Suchmuster beantworten.

Damit das Gate nicht am Rauschen stirbt, gibt es zwei Ränge: Befund — hat im Text keine harmlose Erklärung — und Form — auffällig, aber kein Fehler. Und wenn ein Befund nach Prüfung in Ordnung geht, wird er namentlich quittiert, mit Begründung, im selben Änderungssatz. Die Ausnahme wird sichtbar gemacht, statt die Regel aufzuweichen.

Der Punkt, an dem die Liste ins Leere greift

Beide bisher geprüften Werkzeuge liefern ihr Programm vorkompiliert aus: 42,5 MB das eine, 123,4 MB das andere. Damit ist der Punkt „alle Skripte gelesen“ wertlos — die Skripte sind nur noch der Installateur, das eigentliche Programm liest niemand.

Das ist kein Ausschlussgrund; sonst fiele die halbe Werkzeuglandschaft weg. Es verschiebt nur die Beweislast:

Wie so eine Prüfung ehrlich endet

Für eines der beiden Werkzeuge steht am Ende sinngemäss das hier: Das einzige Installationsskript wurde vollständig gelesen — es holt das Programm in ein temporäres Verzeichnis, verknüpft es und räumt auf; kein weiterer Netzverkehr. Keine Einträge in fremden Konfigurationsdateien, nachgeprüft. Zur Laufzeit schreibt es in zwei benannte Verzeichnisse, eines davon eine Datenbank mit Sitzungen und Protokollen.

Und dann: nicht prüfbar — das 123-MB-Programm selbst. Keine Bau-Bescheinigung, kein Projektverweis im Manifest. Die Signatur der Paketquelle belegt die Auslieferung, nicht den Bau.

Ein Werkzeug in diesem Zustand ist nicht „geprüft“. Es ist ein bewusst akzeptiertes Risiko — und das ist eine Entscheidung, die ein Mensch trifft und aufschreibt, kein Haken auf einer Liste.

Was daraus folgt

Der ehrliche Ertrag einer solchen Prüfung ist selten „unbedenklich“. Er ist eine Liste dessen, was man weiss, und eine kürzere Liste dessen, was man nicht weiss — beide aufgeschrieben, beide mit Datum.

Das klingt bescheidener, als es ist. Wer die zweite Liste führt, merkt beim nächsten Vorfall sofort, wo er nachsehen muss. Wer sie nicht führt, fängt bei null an und wird dabei feststellen, dass niemand mehr weiss, warum das Werkzeug ursprünglich installiert wurde.

Steht bei Ihnen dieselbe Frage an? Der erste Schritt ist ein Gespräch von dreissig Minuten, das nichts kostet.

Reden wir