Lokale KI oder Cloud-Dienst?

Die Frage „lokal oder Cloud?“ klingt nach zwei Antworten. In der Praxis liegen dazwischen mehrere Betriebsformen: ein Modell auf einem Rechner im Haus, ein Dienst in einer europäischen Cloud, eine Schnittstelle bei einem globalen Anbieter und ein klassisches Programm, das ohne Modell auskommt und mit festen Regeln arbeitet. Die Wahl hängt an vier Größen: welche Daten verarbeitet werden, wie schwer ein Fehler wiegt, wer den Betrieb verantwortet und wie ein Ausstieg aussieht.

Die Fallbeispiele in diesem Beitrag sind als fiktives Beispiel gekennzeichnet: ein Dokumentenfall und ein Prüffall, wie sie in vielen Betrieben vorkommen. Preise werden nicht genannt, weil sie sich mit den Modellversionen ändern. Empfohlen wird kein Anbieter.

Die beiden Grundpfade und die gemeinsame Prüfstelle davor zeigt die folgende Grafik.

Welche Daten dürfen wohin?

Vor der Technikfrage steht eine Sortierung der Daten. Für die Praxis genügen drei Klassen: Angaben, die ohnehin öffentlich sind, interne Angaben ohne Personenbezug und Angaben, die sich auf Personen beziehen. Die dritte Klasse ist die entscheidende, und sie wächst schneller als erwartet. Ein Vertragsentwurf enthält Namen und Konditionen. Eine Support-Anfrage enthält oft den Namen der meldenden Person. Ein Bewerbungsdokument fällt in eine Kategorie mit besonderen Anforderungen.

Zu jeder Klasse gehören vier Fragen an den Dienst oder das Modell: Wird die Eingabe gespeichert? Wird sie zum Training verwendet? Wo steht die Verarbeitung, und wer kann darauf zugreifen? Und was geschieht bei einer Kündigung mit den Daten? Diese Fragen lassen sich mit Dokumentation und Vertrag beantworten, nicht mit einem Datenblatt zur Modellgröße.

Ein zweiter Weg ist die Aufteilung. Der vollständige Text bleibt im Haus, und nur der Teil, der für die Aufgabe nötig ist, wird übergeben. Ein Betrieb kann zum Beispiel Namen und Anschriften vor der Übergabe entfernen und das Ergebnis anschließend wieder zusammenführen. Das kostet einen Arbeitsschritt und verändert die Risikolage deutlicher als die Wahl zwischen zwei ähnlichen Diensten.

Wo aus technischen Daten personenbezogene werden, verläuft die Grenze fließend. Das gilt für Maschinendaten ebenso wie für Bürodokumente. Wie schnell dabei aus einem Messwert eine Aussage über eine Person wird, beschreibt der Beitrag über den Umgang mit Beschäftigtendaten an der Anlage.

Wer wissen will, ob für ein Vorhaben zusätzliche Pflichten gelten, kommt an der Rollenfrage nicht vorbei. Ob ein Betrieb ein System nur einsetzt oder als Betreiber in der Lieferkette Verantwortung trägt, ordnet der Beitrag dazu ein, welche Pflichten aus dem AI Act den Betrieb treffen.

Wer wartet Modell und Hardware?

Ein Modell im Haus ist ein Stück Infrastruktur. Es braucht einen Rechner mit passender Ausstattung, einen Platz mit Strom und Kühlung, ein Betriebssystem mit Aktualisierungen und jemanden, der nach einem Ausfall handelt. Dazu kommt die Pflege des Modells selbst. Eine neue Version kann Aufgaben anders lösen als die alte, im guten wie im schlechten Fall. Wer sie einspielt, sollte vorher dieselbe Stichprobe wie bei der Einführung durchlaufen lassen.

Ein Dienst verlagert diese Arbeiten. An die Stelle von Hardware und Arbeitszeit tritt ein Entgelt, das an der Nutzungsmenge hängt und sich ändern kann. Beide Wege haben einen Aufwand, der in Angeboten regelmäßig fehlt: die Zeit für Rückfragen der Beschäftigten. Ein Modell, das plausibel klingende, aber falsche Antworten liefert, erzeugt Nacharbeit, und diese Nacharbeit verteilt sich auf die Fachabteilung.

Ein Rechenbeispiel mit angenommenen Werten zeigt die Struktur. Beim eigenen Betrieb fallen die Anschaffung einmalig und die Arbeitszeit laufend an, unabhängig davon, wie oft das Modell genutzt wird. Beim Dienst wächst das Entgelt mit der Nutzungsmenge, dafür entfällt die Anschaffung. Bei wenigen Anfragen im Monat ist der Dienst deshalb meist die günstigere Variante, bei dauerhaft hoher Auslastung kann sich der eigene Betrieb rechnen. Ob eine der beiden Seiten tatsächlich günstiger ist, lässt sich ohne die aktuellen Preise und ohne die eigene Nutzungsmenge nicht sagen.

Wer den Betrieb vollständig selbst übernimmt, übernimmt auch die Abhängigkeit von einem Projekt oder einer Hardware. Wie sich diese Verschiebung auswirkt und warum ein Exit-Plan dazugehört, ordnet der Beitrag über Abhängigkeit und Ablösung bei offener Software ein.

Wo ein Modell laufen soll, ist davon getrennt zu betrachten. Ein Modell muss nicht zwingend im Rechenzentrum stehen. Ob eine Verarbeitung am Rand des Netzes sinnvoll ist, hängt an der Reaktionszeit und am Ausfallverhalten, was der Beitrag über die Verarbeitung am Rand statt in der Zentrale erklärt.

Wie misst man einen akzeptablen Fehler?

Ein Modell liefert Wahrscheinlichkeiten, keine Gewissheiten. Die Frage lautet deshalb nicht, ob Fehler vorkommen, sondern welche Fehler der Prozess verkraftet. Zwei Fehlerarten haben unterschiedliche Folgen: eine Meldung, die sich bei der Prüfung als folgenlos erweist, kostet Arbeitszeit. Ein Fall, der übersehen wird, kann beim Kunden landen.

Daraus folgt eine Reihenfolge für die Prüfung. Zuerst wird eine Stichprobe abgeschlossener Vorgänge zusammengestellt, deren Ergebnis bekannt ist. Dann läuft das Modell darüber, und eine Person vergleicht. Erst danach steht fest, wie oft das Ergebnis brauchbar war und in welchen Fällen nicht. Diese Prüfung braucht keine Statistiksoftware, sondern eine Tabelle und jemanden, der sie ausfüllt.

Im fiktiven Beispiel des Prüffalls markiert ein Modell Auffälligkeiten auf Fotos, und eine Person entscheidet, ob ein Teil nachgearbeitet wird. Der Betrieb legt vorher fest, dass eine übersehene Auffälligkeit, die beim Kunden ankommt, schwerer wiegt als eine zusätzliche Prüfung im Haus. Deshalb wird die Empfindlichkeit so eingestellt, dass lieber zu viel gemeldet wird. Die Folge sind mehr Prüfungen, und die Frage, ob sich das rechnet, hängt an der Zahl der Fehlmeldungen, die das Team dauerhaft akzeptiert.

Dieselbe Logik gilt, wenn ein Textmodell Entwürfe, Zusammenfassungen oder Auskünfte erzeugt. Wer das Ergebnis ohnehin liest und ändert, braucht eine andere Fehlertoleranz als eine Stelle, die es ungeprüft weitergibt. Wie ein erster Fall ausgewählt wird, bei dem ein Irrtum bezahlbar bleibt, beschreibt der Leitfaden dazu, mit welchem Problem ein Betrieb anfangen sollte.

Was die Frage nach dem Ort nicht beantwortet

Lokal oder Cloud ist keine Grundsatzentscheidung, sondern das Ergebnis von drei Antworten: Welche Daten sind betroffen? Wie schwer wiegt ein Fehler? Wer verantwortet den Betrieb? Erst danach ist der Ort eine Kosten- und Wartungsfrage. Ein Betrieb, der mit einem begrenzten Dienst anfängt, muss dafür nicht alle Daten in die Cloud geben; er muss wissen, welche Daten er übergibt und wer das Ergebnis prüft.

Offen bleibt die Vergleichbarkeit der Modelle. Ob ein Modell die eigenen Dokumente besser oder schlechter verarbeitet als ein anderes, lässt sich aus Anbieterdokumentation nicht ableiten, weil die Beispiele dort ausgewählt sind. Verlässlich ist nur ein Test mit den eigenen Unterlagen und einem bekannten Soll-Ergebnis. Ein solcher Test verliert allerdings seine Gültigkeit, sobald eine neue Modellversion erscheint. Diese Prüfung ist deshalb kein einmaliger Vorgang; sie kehrt mit jeder neuen Version wieder.