Donnerstag, 15.10.2026 11:10 | Force2Motion Sicher, privat – und trotzdem bequem? Wie viel darf meine KI?

Sicher, privat – und trotzdem bequem? Wie viel darf meine KI?

Ich wollte, dass mir eine KI (Mein Kumpel Claude) im Shop-Betrieb Routinearbeit abnimmt. Am Ende eines langen Tages stand fest: Die größte Arbeit war nicht die Technik, sondern die Frage, wie viel Zugriff ich ihr gebe – und wo nicht.

Die Ausgangslage

Ich betreibe einen Onlineshop und arbeite daneben als Sachverständiger für IT-Sicherheit und Datenschutz. In meinem zweiten Leben empfehle ich anderen, Zugriffe so knapp wie möglich zu halten. In meinem ersten Leben möchte ich, dass Bestände, Lieferzeiten und Artikeltexte sich möglichst von selbst pflegen.

Genau dafür arbeite ich seit einigen Wochen mit einer KI. Sie baut mir ein Wartungsportal, gleicht Lieferantenlisten ab und schlägt Änderungen vor. Irgendwann kommt zwangsläufig der Moment, in dem diese Vorschläge auch im Shop ankommen sollen. Und damit die Frage: Mit welchem Schlüssel?

Die 2FA-Frage: Wie meldet sich eine Maschine an?

Der naheliegende Weg war ein eigener Admin-Zugang für die Automatik. Meine eigene Regel lautet aber: Jeder Admin-Zugang bekommt eine Zwei-Faktor-Anmeldung. Gerade nach aktuellen Sicherheitsmeldungen aus der Shop-Welt ist das für mich nicht verhandelbar.

Eine Maschine kann keinen Code vom Handy abtippen. Also beginnt das Abwägen. Man kann den zweiten Faktor ersetzen, etwa durch eine Sperre, die Zugriffe nur vom eigenen Server zulässt. Oder man speichert das Geheimnis für die Codes gleich mit ab – und hat dann zwei Faktoren am selben Ort, also eigentlich nur noch einen.

Jede dieser Lösungen ist eine bewusste Ausnahme von der eigenen Regel. Das muss man aussprechen, statt es sich schönzurechnen oder schönzureden.

Rollen, die nicht halten, was sie versprechen

Das Shopsystem bietet ein feines Rollenkonzept: Artikel ja, Kunden und Bestellungen nein. Auf dem Papier perfekt. Bevor ich es nutze, habe ich es nur lesend getestet. Ergebnis: Eine Schnittstelle lieferte trotzdem eine positive Antwort auf die Frage nach Kundendaten.

Die Lehre daraus ist alt, wird aber oft vergessen. Ein Rechtekonzept, das in der Oberfläche greift, gilt nicht automatisch an jeder Schnittstelle. Und ein Zugangsschlüssel, der sich nicht widerrufen lässt, ist ein Risiko für seine gesamte Laufzeit. Ich habe den Weg verworfen und den Zugang wieder entfernt.

Beim Aufräumen fiel noch etwas auf: alte Test-Zugänge zur Datenbank mit Rechten auf alles. Niemand hatte sie gebraucht, niemand hatte sie entfernt. Solche Altlasten finden sich in fast jeder gewachsenen Umgebung.

Wo die Grenze verläuft: Befehlsliste statt Generalschlüssel

Mein erster Gedanke war, die Rechte auf zwei Felder zu beschränken: Bestand und Lieferstatus. Das wäre sicher gewesen – und nach zwei Wochen nutzlos. Denn die nächste Idee kommt bestimmt: Artikeltexte überarbeiten, fehlende Alternativ-Texte an Bildern ergänzen, neue Artikel anlegen. Eine Grenze, die bei jeder neuen Aufgabe verschoben werden muss, wird irgendwann aus Bequemlichkeit ganz aufgegeben.

Die nächste Idee war eine Grenze nach Datenart: Katalog ja, Personendaten nein. Fachlich richtig, praktisch schwierig. Ein Shop hat weit über hundert Tabellen, und bei vielen verrät der Name nicht, ob Personenbezug drinsteckt. Eine solche Liste pflegt auf Dauer niemand sauber.

Gelandet sind wir bei einem anderen Prinzip: ein kleines Programm im Shop mit einer festen Liste von Befehlen. Es nimmt keine freien Datenbankabfragen an, nur benannte Aufgaben wie „Bestand setzen“. Die Grenze zieht also nicht ein Rechtekonzept, sondern ein kurzer, lesbarer Code. Dafür gibt es zwei Türen, und beide schließe ich selbst auf:

• Jede einzelne Änderung gebe ich frei, mit vorher und nachher und der Möglichkeit, sie zurückzunehmen.
• Jeder neue Befehl kommt nur mit einer neuen Programmversion, die ich mir ansehe und selbst einspiele.

Die ehrliche Gegenfrage habe ich mir auch gestellt: Was müsste ein Angreifer tun, um eigenen Code unterzuschieben? Er bräuchte Schreibzugriff auf den Shop-Server. Wer den hat, hat ohnehin alles. Die Befehlsliste öffnet also keine neue Tür, sie begrenzt nur, was durch die vorhandene hindurchgeht.

Datenschutz: Was die KI nie sehen darf

Aus Sicht der DSGVO war mir ein Punkt wichtiger als alle anderen: Weder die KI in meinem Arbeitschat noch der Chat-Assistent, mit dem Kunden im Shop sprechen, sollen je an Kunden- oder Bestelldaten kommen. Das ist gelebte Datenminimierung nach Art. 5 DSGVO, und es ist auch Selbstschutz. Ein Kunde, der den Chat-Assistenten geschickt ausfragt, darf schlicht nichts finden, was er nicht finden soll.

Daraus ergeben sich einfache Regeln, die nicht verhandelt werden:

• Die KI liest den Shop nur, und personenbezogene Tabellen sind für sie gesperrt.
• Der Chat-Assistent hat gar kein Werkzeug Richtung Shop, nur einen Auszug der Artikeldaten.
• Zugangsdaten gebe ich nie im Chat weiter. Ich trage sie selbst dort ein, wo sie gebraucht werden. Und die KI öffnet keine Konfigurationsdatei mit Passwörtern, ohne vorher zu fragen (Okay wer das glaubt, ist selber schuld – Die KI kann in die Configs schauen und macht es auch – angeblich aus Versehen).

Diese Regeln gelten nicht nur, solange alles gut läuft. Sie gelten gerade dann, wenn etwas schiefgeht und die Versuchung groß ist, „mal eben schnell“ nachzusehen.

Neuer Code ohne FTP: Vier Augen beim Ausrollen

Die zweite große Baustelle war banaler und hat mich trotzdem am meisten genervt. Jede Verbesserung kam als ZIP-Datei, die ich von Hand per FTP hochladen musste. Das ist lästig, fehleranfällig und vom Tablet aus praktisch unmöglich.

Die Lösung ist ein privates Code-Repository. Die KI legt jede Änderung als Vorschlag ab. Ich sehe Zeile für Zeile, was sich ändert, und gebe mit einem Klick frei. Danach holt sich der Server den neuen Stand selbst. Das ist das Vier-Augen-Prinzip, ohne dass ich etwas hin- und herschieben muss.

Auf dem Weg dorthin standen einige Fragen, die man sich bei jedem solchen Dienst stellen sollte:

• Ist das wirklich privat? Ja, aber es liegt bei einem US-Anbieter. Für Programmcode vertretbar, für Kundendaten nicht. Und die kommen dort auch nie hinein.
• Was darf nie ins Repository? Zugangsdaten. Sie bleiben ausschließlich auf dem Server.
• Was darf der Server? Nur lesen. Selbst ein übernommener Server kann am Code nichts ändern.
• Womit melde ich mich an? Mit Zwei-Faktor-Anmeldung und über eine E-Mail-Adresse, die nirgends veröffentlicht ist. Die Service-Adresse aus dem Impressum ist für so etwas das falsche Ziel.

Und noch eine Erfahrung, die ich weitergeben möchte: Vor dem ersten echten Einsatz habe ich den Ablauf in einem Testordner ausprobiert. Verschwinden Dateien, die nicht im Repository stehen, etwa die Konfiguration? Nein. Trotzdem hat der erste echte Lauf eine kleine Lücke aufgezeigt: Eine Verwaltungsdatei war plötzlich im Browser lesbar. Kein Drama, aber ein gutes Beispiel dafür, dass jede neue Bequemlichkeit eine neue Angriffsfläche mitbringt. Man muss nach dem Einführen prüfen, nicht nur davor.

Der Zielkonflikt auf einen Blick

Jede Entscheidung des Tages ließ sich auf dieselben drei Fragen zurückführen. Die Tabelle zeigt, was jeweils gewonnen und was bezahlt wurde.

Keine Zeile ist kostenlos. Der Unterschied liegt darin, ob man den Preis kennt und bewusst zahlt.

Fazit: fünf Grundsätze, die ich mitnehme

• Bequemlichkeit ist eine Sicherheitsanforderung. Eine Lösung, die im Alltag nervt, wird umgangen. Wer Sicherheit will, muss den sicheren Weg zum einfachsten machen.
• Nicht vertrauen, nachprüfen. Ein Rechtekonzept gilt erst, wenn ein Test zeigt, dass es greift – vor dem Einsatz und danach.
• Die Grenze gehört dorthin, wo sie stabil bleibt. Lieber eine kurze Befehlsliste, die mit den Aufgaben wächst als eine Rechteliste, die keiner mehr überblickt.
• Die KI ist Mitarbeiterin, keine Administratorin. Sie schlägt vor, ich entscheide. Das gilt für Änderungen an Daten genauso wie für neuen Code.
• Ausnahmen aussprechen. Wo eine eigene Regel nicht passt, wird das bewusst entschieden und dokumentiert, nicht stillschweigend hingenommen.

Der Tag hat mehr Zeit gekostet als gedacht. Dafür arbeite ich jetzt mit einem System, dem ich als Sachverständiger genauso vertraue, wie als Shop-Betreiber, der abends einfach fertig sein will – und „fertig“ bin ich jetzt.