Der KI-Prototyp läuft. Aber ist er bereit für den Livebetrieb?

Ein mit KI gebauter Prototyp kann funktionieren und trotzdem nicht produktionsreif sein. Die häufigsten Risiken sind API-Keys im Frontend, Autorisierung nur in der Oberfläche, ein Datenmodell und eine Datenbank ohne Migrationsdateien (Stichwort: fehlende Datenintegrität), zu weit gefasste Zugriffsrechte auf angebundene Systeme, Logging mit personenbezogenen Daten und fehlende Tests. Die meisten davon lassen sich mit überschaubarem Aufwand beheben, und Sie können sie zum Teil selbst prüfen. Wie, steht weiter unten.

Die Werkzeuge sind gut geworden. In wenigen Stunden steht eine Oberfläche, die funktioniert, mit Datenbank, Login und einem Deployment, das man Kollegen zeigen kann. Was sie zeigen, stimmt auch. Was sie nicht zeigen, ist alles, was darunter liegt.

Das ist kein Argument gegen diese Werkzeuge. Für viele Vorhaben sind sie die richtige Wahl, und wir raten regelmäßig dazu, sie zu benutzen. Es ist ein Argument dafür, einmal nachzusehen, bevor echte Nutzer oder echte Daten dazukommen.

Dieser Text ist eine Liste dessen, was wir dabei typischerweise finden, und wie Sie es bei sich selbst prüfen können, ohne uns dafür zu brauchen.

Ein Kunde hatte über mehrere Wochen eine Anwendung gebaut, Feature für Feature, und jedes einzelne davon funktionierte. Was fehlte, war eine Entscheidung darüber, wie das Ganze aufgebaut sein sollte, bevor das erste Feature entstand. Kein Framework, keine erkennbaren Konventionen, jede Funktion einzeln entwickelt, ohne zu prüfen, ob es dafür längst eine etablierte Bibliothek gibt. Jede Iteration hat gelöst, was gerade anlag, und dabei die Struktur weiter verschoben. Das geht eine Weile gut, weil das Modell auf jede Anfrage etwas Lauffähiges liefert. Nach einigen Wochen war eine Codebasis entstanden, die sich in angemessener Zeit weder lesen noch sinnvoll reviewen ließ, und ohne Tests ließ sich auch nicht feststellen, was eine Änderung an anderer Stelle kaputt macht.

Der zweite Fall ist ein Sicherheitsthema. Ein Kunde hatte eine Anwendung mit Microsoft 365 Anbindung entwickelt. Anstatt einer eigenen in Microsoft Entra registrierten Anwendung griff er auf die Exchange Online API mit seinem Exchange-Admin-Account via Delegated Access zu. Damit hatte die Anwendung Zugriff auf sämtliche Postfächer der Organisation, ohne eingeschränkten Scope und ohne Trennung zwischen Lesen und Schreiben. Ein Fehler im Code hätte Inhalte verschieben oder löschen können, ohne dass es aufgefallen wäre. Dazu verarbeitet die Anwendung eingehende Nachrichten und reicht deren Inhalt an ein Sprachmodell weiter. Eine präparierte Mail, die Anweisungen enthält, passiert die Schutzmechanismen von Exchange, weil sie technisch kein Angriff ist, sondern erst im Modell als Anweisung wirkt.

Beide Fälle haben gemeinsam, dass in der Oberfläche nichts darauf hindeutete. Die Anwendung lief.

Sechs Dinge lassen sich prüfen, die meisten davon ohne fremde Hilfe.

Secrets im Frontend. Öffnen Sie die Anwendung im Browser, dann die Entwicklertools, und suchen Sie im ausgelieferten JavaScript nach Ihren API-Keys. Wenn Sie fündig werden, kann das jeder andere auch. Das passiert häufiger, als man denkt, weil es funktioniert und deshalb nicht auffällt. Schlüssel gehören auf den Server, und die Anwendung ruft die fremde API von dort auf, nicht aus dem Browser.

Berechtigungen, die es nur in der Oberfläche gibt. Melden Sie sich als normaler Nutzer an und rufen Sie einen Endpunkt direkt auf, den eigentlich nur Administratoren erreichen dürften. Wenn der Button nur ausgeblendet ist, der Endpunkt dahinter aber nicht nachfragt, wer gerade anfragt, dann ist die Berechtigung Dekoration. Autorisierung gehört serverseitig hinter jede einzelne Route.

Ein Datenmodell ohne Migrationen. Fragen Sie sich, was passiert, wenn Sie in drei Monaten eine Spalte umbenennen müssen, während Nutzer mit der Anwendung arbeiten. Wenn die Antwort ist, dass Sie die Datenbank neu aufsetzen, dann steht die Anwendung an dem Punkt, an dem Prototypen typischerweise neu gebaut werden. Migrationen sind kein Luxus, sie sind die Voraussetzung dafür, dass es überhaupt eine zweite Version geben kann.

Angebundene Systeme mit zu vielen Rechten. Sehen Sie nach, mit welchem Konto Ihre Anwendung auf Exchange, das CRM oder das ERP zugreift. Wenn es ein Admin-Konto ist, hat die Anwendung alle Rechte, die dieser Mensch hat. Registrieren Sie stattdessen eine eigene Anwendung mit eigenen Rechten und geben Sie ihr nur die Scopes, die sie wirklich braucht. Lesend, wenn sie nur liest.

Logging, das zu viel mitschreibt. Schauen Sie in Ihre Logs. Wenn dort komplette Request-Bodies stehen, dann stehen dort auch Namen, Adressen und Inhalte, in einem Dienst, dessen Standort und Aufbewahrungsdauer vermutlich niemand geprüft hat. Das ist der stillste der sechs Punkte und der, der am ehesten zum Datenschutzproblem wird.

Keine Tests. Solange eine Person am Code arbeitet und alles im Kopf hat, geht das gut. Es wird zum Problem, sobald eine zweite Person dazukommt oder die erste zurückkehrt, nachdem sie einen Monat an etwas anderem gearbeitet hat. Sie brauchen keine vollständige Testabdeckung. Sie brauchen Tests um das herum, was nicht kaputtgehen darf.

Fünf dieser sechs Punkte lassen sich nachträglich beheben, mit überschaubarem Aufwand. Secrets umziehen, Autorisierung nachrüsten, Rechte einschränken, Logging bereinigen, Tests schreiben. Unangenehm, aber machbar.

Das Datenmodell ist der Punkt, an dem das nicht mehr gilt. Es steckt in jeder Zeile, die darauf aufsetzt, und je länger die Anwendung wächst, desto mehr Code hängt daran. Deswegen ist die wichtigste Entscheidung nicht die, welche Bibliothek Sie einsetzen, sondern die, die Sie treffen, bevor der erste Prompt geschrieben ist. Ohne definierten Scope trifft das Modell die Architekturentscheidungen implizit, eine nach der anderen, und niemand hat sie je bewusst getroffen.

Wenn die Anwendung etwa nur ein internes Werkzeug für eine Handvoll Kolleginnen und Kollegen ist, keine personenbezogenen Daten anfasst, kein produktives System beschreibt und ein Ausfall verkraftbar wäre, dann bauen Sie sie weiter, wie Sie sie gebaut haben. Die Punkte oben sind trotzdem einen Nachmittag wert, aber es besteht vorerst kein Anlass, jemanden dafür zu beauftragen.

Die Lage ändert sich an drei Stellen. Wenn echte Nutzer damit arbeiten. Wenn Kundendaten hineinlaufen. Wenn jemand anderes als der Autor den Code weiterentwickeln soll.

Wenn Sie unsicher sind, an welchem dieser Punkte Sie stehen, hilft möglicherweise unsere kurze Einschätzung weiter. Zehn Fragen, danach eine Empfehlung, gelegentlich auch die, es ohne uns zu machen. 

Fragebogen