KI selbst betreiben oder aus der Cloud beziehen?

Trenn zuerst die Daten, dann die Systeme

Bevor du Betriebsmodelle vergleichst, brauchst du eine Einteilung eurer Daten in wenige Klassen, etwa offen, intern, vertraulich und besonders geschützt. Erst danach lässt sich sagen, welche Arbeitslast überhaupt zur Auswahl steht. Ohne diese Einteilung wird die Diskussion grundsätzlich geführt und endet bei der Haltung statt beim Fall.

Dabei zeigt sich meist, dass der größte Teil der Anwendungsfälle mit internen, aber nicht besonders schützenswerten Inhalten arbeitet: Protokolle, Entwürfe, Recherche, Zusammenfassungen. Für diese Masse ist der Streit um den Serverstandort teuer und wenig ergiebig. Übrig bleibt eine kleine Menge echter Sonderfälle, und für die lohnt sich die aufwendigere Lösung.

Was Cloud-Betrieb tatsächlich zusichert

Eine Region in der EU ist eine Aussage über den Verarbeitungsort, nicht automatisch über jeden Zugriff. Prüf getrennt: wo verarbeitet wird, wo Protokolldaten liegen, von wo aus der Support im Störungsfall zugreifen darf und wie lange Eingaben zwischengespeichert werden. Diese vier Punkte gehören in den Vertrag und nicht in eine Produktbroschüre.

Der zweite Punkt ist der Trainingsausschluss. Endkundenangebote und Unternehmensangebote desselben Anbieters unterscheiden sich häufig genau hier, und die Zusage steht im Unternehmensvertrag, nicht in der App. Wer das nicht trennt, verbietet ein Modell, das in der richtigen Bezugsform unproblematisch gewesen wäre.

Eigene Hardware rechnet sich über die Auslastung

Eine gekaufte oder fest gemietete Beschleunigerkarte kostet dasselbe, ob sie zu fünf oder zu achtzig Prozent ausgelastet ist. Die Cloud rechnet dagegen je Anfrage oder je Stunde ab. Daraus folgt die eigentliche Rechnung: Ab welcher gleichmäßigen Grundlast liegt der eigene Betrieb unter den laufenden Kosten der Cloud, und wie sicher ist diese Grundlast über die Abschreibungsdauer?

In die eigene Rechnung gehören die Posten, die im Angebotspreis der Hardware nicht auftauchen: Strom und Kühlung, Stellplatz, ein zweites System für Ausfälle, Aktualisierung von Treibern und Laufzeitumgebung und vor allem Personal, das den Betrieb übernehmen kann. Der letzte Posten ist am Markt der knappste und wird beim ersten Überschlag fast immer vergessen.

Beschaffung braucht außerdem Vorlauf. Wer eine Anwendung zunächst mit gemieteter Rechenzeit erprobt, kann sie später verlagern. Wer umgekehrt auf gekaufte Hardware wartet, hält das ganze Vorhaben so lange an.

Der Modellwechsel ist der unterschätzte Unterschied

In der Cloud ist ein neueres Modell eine Zeile in der Konfiguration. Im eigenen Betrieb bedeutet dasselbe: Gewichte laden, Speicherbedarf prüfen, Laufzeitumgebung aktualisieren, Antwortzeiten neu messen und die Anweisungen nachziehen. Das ist alles machbar, aber es ist ein Vorgang mit Termin und Verantwortlicher, keine Einstellung.

Feinabgestimmte Modelle verschärfen das. Sie hängen an einer Modellversion, und wenn diese abgelöst wird, ist die Feinabstimmung zu wiederholen. Halte deshalb Trainingsdatensatz und Aufbereitungsschritte versioniert im eigenen Haus, unabhängig davon, wo trainiert wurde.

Der geteilte Betrieb ist kein Kompromiss aus Feigheit

Die tragfähigste Aufteilung verläuft an der Schutzklasse: Die Masse der Aufgaben läuft beim Cloud-Anbieter, die wenigen Fälle mit besonders geschützten Daten laufen auf eigenen Systemen mit einem kleineren Modell. Ein vorgeschaltetes Gateway entscheidet anhand der Klassifizierung, wohin eine Anfrage geht, und hält diese Entscheidung im Protokoll fest.

Damit daraus nicht zwei getrennte Welten werden, braucht es gemeinsame Punkte: eine Schnittstelle für alle Anwendungen, ein einheitliches Protokollformat und dieselben Anweisungen, soweit die Modelle das hergeben. Wo zwei Teams zwei Betriebswelten getrennt pflegen, entstehen genau die Kosten, die man mit der Aufteilung sparen wollte.