Die KI soll etwas herstellen, also braucht sie Zugang: warum im AIEE-Programm ein eigener Server steht

Der Reiz an KI-Werkzeugen beginnt dort, wo aus Zuschauen Arbeiten wird: Etwas soll entstehen, das am nächsten Tag noch läuft. Genau an dieser Stelle verlangt die Technik etwas, das in jedem Betrieb sorgfältig geregelt ist, nämlich Zugang bzw. Rechte. Wie man diesen Zugang gibt, ohne die eigene IT zum Versuchsfeld zu machen: das ist die Frage, auf die der AIEE-Server als Kern des Programms antwortet.

Eine KI, die etwas herstellen soll, braucht Werkzeug und Rechte

Eine KI-Programmierumgebung ist etwas anderes als ein Chatfenster. Im Chatfenster entsteht Text, den man anschließend selbst weiterverwendet. In einer Programmierumgebung entsteht ein Ergebnis, das von allein weiterläuft: eine Auswertung, ein Ablauf, ein kleines Programm. Solche Umgebungen wie z. B. Claude Code werden auf einem Rechner installiert und holen sich weitere Werkzeuge dazu. Dazu bekommen sie Rechte. Gemeint ist die Erlaubnis, Dateien zu lesen, zu schreiben und zu löschen sowie Programme zu starten. Diese Rechte werden benötigt, um die Aufgaben abzuarbeiten.

Eine neue Kraft soll ein Angebot schreiben. Dafür braucht sie den Schlüssel zum Aktenschrank, den Zugang zur Preisliste und das Recht auf Ablage im Laufwerk. Wer ihr beim Lesen zusieht und sonst nichts erlaubt, bekommt kein Angebot. Wer ihr dagegen sämtliche Schlüssel überlässt, hat ihr am ersten Tag auch die Personalakten und die Kundenkartei in die Hand gegeben. Beides ist unbefriedigend, und in beiden Fällen liegt es an der Umgebung.

Warum der Arbeitsrechner der unruhige Ort für die ersten Versuche ist

Auf dem eigenen Arbeitsgerät liegt alles beieinander: gespeicherte Zugänge, Kundenunterlagen, Jahre an Dateien, das Angebot neben dem privaten Foto. 3 Dinge gehen dort erfahrungsgemäß schief, alle 3 ohne böse Absicht:

• ein Passwort landet in einer Datei, die anschließend weitergereicht wird;
• ein Ordner wird aufgeräumt, der noch gebraucht wurde;
• Daten werden gelesen, die mit der Aufgabe nichts zu tun haben, einfach weil sie in der Nähe lagen.

Dazu kommt ein grundsätzlicher Punkt, und er wiegt schwerer als jeder einzelne Vorfall: Die persönliche IT vermischt sich mit einer Testumgebung. Gerade am Anfang kennt man die Grenzen des Werkzeugs noch nicht, weil man sie noch nicht erlebt hat. Wer sie erleben will, braucht einen folgenlosen Ort dafür.

Trennung hilft, und die 4 üblichen Wege dahin trennen unterschiedlich scharf

Die Antwort auf dieses Problem ist seit Jahrzehnten dieselbe und stammt aus der Werkstatt: Man probiert am Probestück, nicht am Kundenauftrag. Der Grund dafür ist in der IT derselbe wie an der Maschine: Ein Fehler kostet dort wenig, wo nichts Echtes danebenliegt. Deshalb steht in jedem Unternehmen mit eigener Software ein Testsystem neben dem laufenden. Für die ersten Schritte mit einer KI-Umgebung gilt dasselbe. Nur denkt hier selten jemand daran, weil das Werkzeug beim Öffnen aussieht wie ein Chatfenster.

Technisch heißt Trennung: 2 Arbeitsbereiche, die einander nicht sehen. Was im einen passiert, erreicht den anderen weder lesend noch schreibend. Dafür gibt es 4 gängige Wege, und der eigentliche Punkt ist ihre unterschiedliche Schärfe. Getrennt ist keine Eigenschaft, die ein Rechner hat oder nicht hat. Es ist eine Frage danach, welche Brücken zwischen beiden Seiten offen bleiben.

1. Eine virtuelle Maschine oder ein Container auf dem eigenen Rechner. Eine virtuelle Maschine ist ein vollständiger zweiter Rechner, der als Programm im ersten läuft. Sie hat eine eigene Festplatte, eigene Benutzer und ein eigenes Betriebssystem. Das Betriebssystem ist das Grundprogramm, das einen Rechner überhaupt bedienbar macht. Ein Container ist die schlankere Variante davon, ein abgeriegelter Arbeitsbereich für ein einzelnes Werkzeug. Anthropic, der Hersteller von Claude Code, empfiehlt in seiner Sicherheitsdokumentation genau diese beiden Wege. Der AIEE-Server geht diesen Weg zu Ende: ein eigener Server je Teilnehmer, fertig eingerichtet, als getrennte Instanz betrieben und in seiner Absicherung geprüft.
2. WSL. Die Abkürzung steht für Windows-Subsystem für Linux, eine mitgelieferte Funktion von Windows. Sie lässt Linux innerhalb des laufenden Windows mitlaufen. Linux ist ein freies Betriebssystem, auf dem ein großer Teil der Server weltweit arbeitet; im Büroalltag begegnet es den wenigsten. Dieser Weg ist der bequemste und zugleich der schwächste. Im Auslieferungszustand sieht Linux die Windows-Festplatte unter dem Namen /mnt/c und darf dort auch schreiben. Umgekehrt sieht Windows die Linux-Dateien. Auch Windows-Programme lassen sich aus Linux heraus starten, und sie laufen dann mit den Rechten des angemeldeten Windows-Nutzers. Microsoft beschreibt das in seiner eigenen Dokumentation als gewollte Bequemlichkeit und führt WSL an keiner Stelle als Sicherheitsgrenze. Die 3 oben genannten Unfälle können also weiterhin die echten Firmendaten treffen. Wer WSL als Versuchsraum nutzt, schaltet diese Brücken zuerst ab.
3. Ein zweites Betriebssystem auf demselben Rechner. Beim Einschalten wird ausgewählt, welches starten soll. Die Trennung ist dadurch schärfer als bei WSL, weil immer nur eines läuft. Vollständig ist sie jedoch nicht. Beide liegen auf derselben Festplatte, und solange diese unverschlüsselt ist, kann das eine System die Dateien des anderen lesen. Dazu kommt ein weiterer Punkt: Schon das Einrichten verändert die Aufteilung der Arbeitsplatte und verlangt damit den heikelsten Handgriff dieser 4 Wege.
4. Ein zweiter Rechner. Hier ist die Trennung vollständig, weil sie physisch ist. Zugleich ist es der Weg, für den Geld und Platz gebraucht werden.

Alle 4 Wege verlangen dasselbe, nur in unterschiedlicher Dosis: einrichten, sich ein Stück weit mit Linux auskennen, Zeit mitbringen. Am wenigsten kostet das Einrichten bei WSL, dort genügt ein einziger Befehl. Dafür ist anschließend am meisten nachzuarbeiten, bis wirklich getrennt ist. Bei der virtuellen Maschine und beim zweiten Betriebssystem liegt der Aufwand im Aufsetzen, beim zweiten Rechner in Anschaffung und Pflege. Auf eine Geschäftsführung, eine Meisterin oder eine kaufmännische Leitung trifft dieses Trio selten zu. Die Zeit fehlt ohnehin. Damit scheitert der Einstieg an der Einrichtung, lange bevor die erste inhaltliche Frage gestellt ist. Genau dieser Teil lässt sich jedoch einkaufen, und das ist die günstigste Stelle für ausgegebenes Geld.

Der AIEE-Server ist die Lehrwerkstatt zum Programm

An dieser Stelle setzt der Server an. In der Lehrwerkstatt eines Maschinenbauers stehen echte Maschinen, echtes Material und echte Werkzeuge. Was dort fehlt, ist der laufende Kundenauftrag. Genau deshalb darf dort jeder Handgriff einmal danebengehen, und genau deshalb lernt man dort mehr als beim Zusehen in der Fertigung.

Der AIEE-Server ist diese Lehrwerkstatt: eine vorbereitete, gesicherte Arbeitsumgebung, die nach dem Anmelden im Browser bereitsteht. Jeder Teilnehmer bekommt einen eigenen Server als getrennte Instanz. Die Einrichtung entfällt, die Werkzeuge sind vorhanden, die Rechte sind gesetzt. Verbindungen zu den eigenen Systemen des Teilnehmers bestehen dabei keine, und die Umgebung jedes Teilnehmers steht für sich.

Ausprobiert werden darf, was man will. Volle Rechte auf dem eigenen Server gehören zum Programm, und wer sie braucht, bekommt sie. Es gibt Vorhaben, in denen ein Teilnehmer von der ersten Stunde an einen eigenen Agentenserver aufbaut. Genau dafür braucht es volle Rechte. Am Anfang sind sie zurückgestellt. Das ist eine Sicherung für die ersten Schritte und keine Grenze des Angebots: Wer noch nicht weiß, was ein Befehl anrichtet, lässt ihn besser nicht als Erstes auf die Grundeinstellung los. Die einzige Grenze, die bleibt, ist die rechtliche. Sie steht in den Teilnahmebedingungen. Die Grenzen, um die es im Programm geht, sind ohnehin andere. Es sind die des Werkzeugs: was eine KI aus einer Anweisung macht, wo sie danebenliegt, und woran man das erkennt. Diese Grenzen selbst erlebt zu haben, ist der Unterschied zwischen einer Schulung und einer Erfahrung.

Der Nutzen fällt dabei auf 2 Seiten an. Der Teilnehmer arbeitet ab der ersten Stunde am Inhalt statt an der Installation. Und die IT des Unternehmens bleibt außen vor, ohne dass ihr etwas entgeht. Es wird nichts installiert, an den Geräten ändert sich nichts, Rechte im Firmennetz braucht es keine. Wer den Server nutzt, meldet sich im Browser an, so wie bei jedem anderen Dienst im Netz. Gerade in größeren Häusern ist genau das der Unterschied, der zählt: Eine Installation wie WSL setzt eine Hardware- und Softwarefreigabe voraus, und die Rechte dafür haben die wenigsten Beschäftigten überhaupt.

Der Vergleich mit den Baukasten-Werkzeugen, fair gerechnet

Die naheliegende Rückfrage lautet: Es gibt doch Baukasten-Werkzeuge, oft Low-Code genannt. Darin klickt man Abläufe zusammen, statt sie zu programmieren. Warum dann eine Programmierumgebung? Die Rückfrage ist berechtigt.

Solche Werkzeuge sind in vielen Unternehmen vorgegeben. Wer sie nutzen muss, nutzt sie, und das ist in Ordnung. Sie liefern für viele Standardaufgaben schnell ein Ergebnis. 3 Eigenschaften gehören jedoch mit auf die Rechnung:

• Es bleibt ein vorgefertigter Rahmen. Die Bausteine stammen vom Anbieter, und was er nicht vorgesehen hat, steht auch nicht zur Verfügung.
• Der Name Low-Code trifft die Sache nur halb. Jedes dieser Werkzeuge bringt ein eigenes System mit eigener Ablauflogik mit, in das man sich einarbeiten muss. Wer Automatisierung aus früheren Zeiten kennt, tut sich damit leicht und ist schnell produktiv. Für alle anderen ist es neuer Stoff, und an einzelnen Stellen wird trotz des Namens doch programmiert.
• Es entsteht Abhängigkeit. Wie stark sie ausfällt, ist je Werkzeug verschieden: Manche geben die gebauten Abläufe als Datei heraus, andere behalten sie bei sich. Laufen lassen kann man das Gebaute in aller Regel jedoch nur im Werkzeug selbst, und damit hängt der Betrieb am Vertrag mit dem Anbieter.

Mit einer Programmierumgebung kommt am Ende dasselbe Ergebnis heraus. Der Weg dorthin ist jedoch ein anderer, und der Unterschied zeigt sich erst nach dem ersten Projekt. Was dabei entsteht, ist mehr als ein Skript:

• Skripte, also Textdateien mit Arbeitsanweisungen, die ein Rechner der Reihe nach abarbeitet;
• richtige Programme und fertig gebaute Anwendungen;
• Agenten-Abläufe, in denen eine KI eine Aufgabe von Anfang bis Ende führt;
• eigene Schnittstellen zu Altsystemen, also Andockstellen, an denen 2 Programme miteinander sprechen.

Die Bandbreite ist dabei der eigentliche Punkt. Ein enger Rahmen fehlt, und damit fehlt auch die Grenze dessen, was gebaut werden kann. Am deutlichsten zeigt das der Anschluss an ein Altsystem. Bei einem Baukasten-Werkzeug muss er programmiert werden, sofern es ihn nicht fertig gibt. In einer Programmierumgebung entsteht er im selben Zug mit allem anderen.

Das Gebaute läuft anschließend eigenständig, und diese Eigenständigkeit lässt sich bewusst einplanen. Sie kann unabhängig von der Umgebung sein, in der das Ergebnis entstanden ist. Das Ergebnis liegt in Dateien, die einem selbst gehören. Und sie kann unabhängig von einzelnen Anbietern sein. Möglich ist das mit einer Baukasten-Lösung ebenso, soweit wir es überblicken. Der Unterschied liegt im Rahmen, innerhalb dessen gebaut wird.

Kommunikation statt Oberfläche

Der große Vorteil dieser Arbeitsweise liegt in dem, was wegfällt: die Regeln einer Oberfläche, eine fremde Ablauflogik, aneinandergereihte Kästchen mit selten selbsterklärender Beschriftung. Gelernt werden muss vor allem eines, und es ist genau das, was eine erfahrene Führungskraft ohnehin beherrscht: Kommunikation. Man sagt, was man erreichen will. Man prüft, was zurückkommt. Und man arbeitet gemeinsam an der Lösung. Wer einen Auftrag so beschreiben kann, dass ihn ein neuer Mitarbeiter ohne Rückfrage ausführt, hat die entscheidende Fähigkeit bereits.

Ganz ohne Technik geht es dabei allerdings nicht. Was bleibt, ist wenig und alltäglich: anmelden, Dateien ablegen und im Einzelfall entscheiden, was man der KI erlaubt. Der letzte Punkt ist der wichtigste, weil er beim Menschen bleibt. Anthropic hält das für Claude Code ausdrücklich fest. Die Umgebung hat genau die Rechte, die man ihr gibt. Die Prüfung dessen, was sie vorschlägt, liegt beim Anwender. Eine solche Freigabe zu erteilen ist jedoch nicht schwerer, als eine Rechnung abzuzeichnen. Man sieht, was getan werden soll, und entscheidet.

Das ist eine andere Art der Zusammenarbeit, und aus unserer Sicht die stärkere. Der Grund liegt weniger in der Bequemlichkeit als in der Richtung, in die sich die Werkzeuge entwickeln. Die Fähigkeit, ein Problem präzise zu beschreiben, gewinnt an Wert. Das Bedienwissen einer bestimmten Oberfläche verliert mit jeder neuen Version ein Stück davon.

Dagegen bietet ein Baukasten-Werkzeug Übersicht, eine eingeführte Freigabepraxis und einen Vertragspartner, den die IT bereits geprüft hat. Wo die IT ein solches Werkzeug vorgibt, hat sie dafür gute Gründe, und daran ändert ein Programm wie AIEE nichts. Dennoch lohnt es, die andere Arbeitsweise einmal selbst erlebt zu haben, und zwar vor der Entscheidung über ein größeres Vorhaben. Wer beide Wege aus eigener Anschauung kennt, entscheidet über Aufwand, Bindung und Nutzen mit eigenen Argumenten statt mit denen eines Anbieters.

Dieser Text beschreibt, wie und warum der Server im AIEE-Programm eingesetzt wird. Die Angaben zu WSL beziehen sich auf den Auslieferungszustand, wie Microsoft ihn dokumentiert; jede der beschriebenen Brücken lässt sich mit Aufwand schließen. Welcher Weg im einzelnen Unternehmen der passende ist, hängt von den Vorgaben der IT, vom vorhandenen Werkzeugbestand und vom Ziel des jeweiligen Vorhabens ab.