Kein ML-Team: Wer betreibt nach dem Start ein LLM-System für Support-Tickets und Dokumente auf Ihren eigenen Servern?

Ein LLM-System, das Support-Tickets sortiert und Dokumente auf Ihren eigenen Servern liest, braucht auch nach dem Start jemanden, der es betreibt. LLM steht für Large Language Model, ein großes Sprachmodell, also die Art von KI hinter ChatGPT. Ein Unternehmen ohne Team für maschinelles Lernen (ML) hat drei Wege. Die Firma, die das System gebaut hat, kann es im Rahmen eines Supportvertrags weiter betreiben. Nach einer Übergabe kann stattdessen Ihr IT-Team es übernehmen oder sich die Arbeit mit der Firma teilen. Auf jedem Weg muss jemand die Qualität der Antworten regelmäßig prüfen und jede Änderung am Modell freigeben, bevor sie live geht.

Was gehört nach dem Start zum Betrieb eines LLM-Systems?

Nach dem Start besteht der Betrieb eines LLM-Systems aus diesen wiederkehrenden Aufgaben:

• Die Server, oft mit GPUs (den Chips, auf denen Sprachmodelle laufen), und Updates der Software, die das Modell ausführt
• Die eingesetzte Modellversion und die Entscheidung, wann sie gewechselt wird
• Die regelmäßige Bewertung der Antworten an einer festen Stichprobe Ihrer eigenen Tickets und Dokumente
• Die Review-Queue, also die Fälle, die die Software an eine Person übergibt, und die Mitarbeiter, die sie abarbeiten
• Änderungen auf Ihrer Seite, etwa ein neues Formular, eine neue Ticketkategorie oder eine neue Geschäftsregel
• Logs, die festhalten, was das System getan hat, und Zugriffsrechte auf Tickets und Dokumente
• Ausfälle in der Nacht und die Person, die dann angerufen wird

vLLM ist ein Open-Source-Programm, mit dem sich Modelle auf eigenen Servern betreiben lassen. Seine Sicherheitsseite auf GitHub, abgerufen am 20. Oktober 2026, führt einen Sicherheitshinweis vom 6. Oktober 2026 zu einem Fehler, der in Version 0.31.0 behoben wurde. Der Titel des Hinweises lautet: „Ein übergroßes min_tokens in einer Anfrage lässt die vLLM-Engine hängen, während /health grün bleibt“. In diesem Titel ist min_tokens eine Einstellung der Anfrage für die Mindestlänge der Antwort.

Ein Monitoring-Tool fragt eine Adresse wie /health ab, um festzustellen, ob ein Server läuft. In dem Fall, den der Hinweis von vLLM beschreibt, wirkt der Server gesund, obwohl er keine Anfragen mehr beantwortet. Das Monitoring eines LLM-Systems sollte echte Testanfragen senden und prüfen, ob Antworten zurückkommen.

Worin unterscheidet sich unser eigenes System von einem Helpdesk-Tool mit eingebauter KI?

Bei einem Helpdesk-Tool, das als Software as a Service (SaaS) verkauft wird, also als Tool, das Sie über das Internet mieten, betreibt der Anbieter den Dienst, und das Modell läuft auf den Servern des Anbieters oder auf denen von Unternehmen, mit denen er zusammenarbeitet. Ihre Tickets gehen an den Anbieter und an diese Unternehmen. Der Artikel über KI-Software zur Dokumentenverarbeitung oder eine individuelle LLM-Pipeline behandelt die Wahl zwischen einem solchen Tool und einem eigenen System.

Zendesk, ein Helpdesk-Anbieter, schreibt auf seiner Seite zu generativer KI, am selben Tag abgerufen, dass „Zendesk LLMs auf zwei Arten in die Services integriert“. Die eine nutzt Modelle, die auf Plattformen „wie AWS Bedrock, Microsoft Azure, Groq oder Fireworks AI“ gehostet werden, und für diesen Fall sagt Zendesk, dass „der LLM-Anbieter niemals auf Ihre Servicedaten zugreift“. Die andere nutzt Modelle, die „direkt vom Modellanbieter gehostet“ werden, etwa von OpenAI und Google Gemini. Für diese sagt Zendesk, dass der an das Modell gesendete Text und seine Antworten „in keinem Logging-Mechanismus gespeichert“ werden.

Intercom, ein weiterer Helpdesk-Anbieter, veröffentlicht eine Liste seiner Unterauftragsverarbeiter, also der Unternehmen, die in seinem Auftrag Daten verarbeiten. Die Liste, gültig ab dem 25. Juni 2026 und am selben Tag abgerufen, nennt unter anderem OpenAI, Anthropic, Google und Microsoft für die „KI-Verarbeitung“. Auf der Seite heißt es, die Listen „können von Intercom von Zeit zu Zeit aktualisiert werden“.

Kann die Firma, die unser LLM-System gebaut hat, es weiter betreiben?

Die Firma, die das System gebaut hat, bietet möglicherweise einen Supportvertrag an, also einen Vertrag, nach dem sie das System nach dem Start am Laufen hält. Prüfen Sie, was der Vertrag zu diesen Punkten sagt:

• Was als Vorfall gilt, etwa ein Stillstand des Systems oder ein Feld, das in vielen Dokumenten falsch gelesen wird, und wie schnell jemand auf jede Art von Vorfall reagiert
• Wer sich auf Ihren Servern anmelden darf, über welche Konten und wie dieser Zugriff protokolliert wird
• Wer die Server bezahlt und wer entscheidet, wann mehr Kapazität nötig ist
• Was als Änderungsantrag gilt, etwa ein neuer Dokumenttyp oder eine neue Ticketkategorie, und wie er abgerechnet wird
• Welche Berichte Sie jeden Monat erhalten, etwa Qualitätswerte, Volumen der Review-Queue und Vorfälle

Wenn die Firma das System betreibt, verlangt das Ihren Mitarbeitern am wenigsten ab. Das Know-how bleibt dann allerdings bei der Firma, und Ihr Unternehmen ist bei den meisten Änderungen auf sie angewiesen. Was Ihnen gehören sollte, wenn die Firma geht, behandelt der Artikel über die Fragen, die ein COO vor der Unterschrift stellen sollte.

Unser IT-Team hat keine ML-Erfahrung. Kann es das System übernehmen?

Ein IT-Team, das bereits die Server Ihres Unternehmens betreibt, kann in der Regel die Server, Zugriffsrechte, Backups und das Monitoring des LLM-Systems in seine Arbeit aufnehmen. Die Aufgaben, die für Sprachmodelle typisch sind, etwa Qualitätswerte zu lesen und eine neue Modellversion zu testen, erfordern zuerst eine Schulung.

Für die Übergabe braucht das IT-Team Runbooks, also Schritt-für-Schritt-Anleitungen für die täglichen Aufgaben und für jeden bekannten Fehlerfall, etwa eine volllaufende Review-Queue. Außerdem braucht das Team die Teststichprobe Ihrer Tickets und Dokumente mit den richtigen Antworten und das Skript, das das System daran bewertet. Code und Modelldateien gehören auf einen Speicher, den Ihr Unternehmen kontrolliert.

Eine Testumgebung, also eine Kopie des Systems, in der Änderungen ausprobiert werden, bevor sie echte Tickets erreichen, sollte schon vor dem Start existieren. Dort kann auch die Schulung stattfinden: Ihr Team erledigt die Routineaufgaben an der Kopie, und die Entwickler der Firma prüfen die Arbeit.

Änderungen an Prompts und Regeln brauchen einen Verantwortlichen. Ein Prompt ist der Text, der dem Modell sagt, was es tun soll. Wenn sich ein Formular ändert oder eine neue Ticketkategorie hinzukommt, muss jemand den Prompt oder die Regeln anpassen und die Bewertung an der Teststichprobe wiederholen. Entscheiden Sie, ob diese Person in der IT sitzt, bei der Firma oder in dem Team, das den Prozess verantwortet, etwa im Support.

Wie würde eine Aufteilung zwischen unserem IT-Team und der Firma funktionieren?

Bei einer Aufteilung behält Ihr IT-Team die Server und die Zugriffe, und die Firma wird für Änderungen am Modell und für Qualitätsprobleme hinzugezogen.

Eine Aufteilung kann eine Lücke lassen. Wenn die Qualität sinkt, gibt die IT womöglich dem Modell die Schuld und die Firma den Servern. Der Vertrag sollte deshalb schriftlich festhalten, wer was entscheidet.

Zum Beispiel gibt Ihr Unternehmen jede neue Modellversion frei, nachdem die Firma sie an der Teststichprobe bewertet hat. Ein Qualitätsproblem zu beheben ist Aufgabe der Firma, während der Zugriff auf die Server eine Entscheidung Ihres IT-Teams bleibt. Benennen Sie außerdem die Person, die als Erste nachsieht, wenn nachts ein Alarm ausgelöst wird, und wie sie die andere Seite erreicht.

Warum sinkt die Qualität der Antworten nach dem Start manchmal?

Die Genauigkeit kann driften, sich also langsam verändern, ohne dass eine Fehlermeldung erscheint. Neue Ticketthemen nach einer Produkteinführung, ein geändertes Formular oder eine neue Modellversion können jeweils eine solche Drift auslösen. Die Server laufen weiter wie zuvor, deshalb zeigt das Server-Monitoring den Rückgang nicht.

Drift wird sichtbar, wenn dieselbe Stichprobe Ihrer Tickets und Dokumente mit den richtigen Antworten erneut bewertet wird. Das sollte nach Plan geschehen, zum Beispiel monatlich, und nach jeder Änderung am Modell, am Prompt oder an den Regeln. Vergleichen Sie jeden Wert mit dem, der beim Start festgehalten wurde.

Die Artikel über einen festgefahrenen KI-Pilot und über die Fragen eines COO erklären, wie Sie die Teststichprobe aufbauen. Welchen Weg Sie auch wählen, der Vertrag sollte die Person benennen, die die erneute Bewertung durchführt, und festlegen, wer die Ergebnisse sieht.

Wer entscheidet, wann das Modell gewechselt wird?

Bei einem Open-Weight-Modell auf Ihren eigenen Servern entscheidet Ihr Unternehmen, wann es wechselt. Ein Open-Weight-Modell ist ein Modell, dessen Hersteller die Modelldateien veröffentlicht, damit jeder sie unter seiner Lizenz herunterladen und betreiben kann. Die Lizenz gilt trotzdem, und eine neuere Version kann unter einer anderen Lizenz erscheinen.

Die Gemma-Modelle von Google sind ein Beispiel. Die Seite zu Gemma 3 auf der Modellplattform Hugging Face, am selben Tag abgerufen, verweist auf die Gemma Terms of Use, die eine Prohibited Use Policy einbeziehen. Der Open-Source-Blog von Google schrieb am 2. April 2026: „Gemma-4-Modelle sind die ersten im Gemmaverse, die unter der von der OSI anerkannten Lizenz Apache 2.0 veröffentlicht werden.“ Ein Wechsel von Gemma 3 zu Gemma 4 ändert daher die Lizenz, die Ihre Juristen lesen: statt Googles eigener Bedingungen gilt Apache 2.0, eine Open-Source-Lizenz.

Ein System auf Ihren eigenen Servern kann trotzdem ein Modell über eine gehostete API aufrufen, also über eine Internetverbindung zu den Servern eines anderen Unternehmens. Dieses Modell wird nach dem Zeitplan jenes Unternehmens außer Betrieb genommen. Die Seite von Anthropic zur Abkündigung von Modellen, am selben Tag abgerufen, sagt: „Anfragen an Modelle nach dem Datum der Außerbetriebnahme schlagen fehl.“ Anthropic gibt nach eigenen Angaben Kunden mit aktiven Deployments „mindestens 60 Tage Vorlauf vor der Außerbetriebnahme öffentlich veröffentlichter Modelle“. Die Seite ergänzt, dass ihre Daten für die eigenen Plattformen von Anthropic gelten und dass Amazon Bedrock und Google Cloud „ihre eigenen Zeitpläne für die Außerbetriebnahme festlegen“.

Jeder Wechsel bedeutet, die neue Version an Ihrer Stichprobe zu bewerten, bevor sie live geht, und die alte Version bereitzuhalten, falls die Werte sinken. Die Seite von Anthropic empfiehlt, „Ihre Anwendungen lange vor dem Datum der Außerbetriebnahme gründlich mit den neuen Modellen zu testen.“

Kann ein Support-Ticket das System austricksen?

Prompt Injection ist ein Angriff, bei dem an das System gesendeter Text Anweisungen enthält, die sich an das Modell richten. Support-Tickets kommen von außerhalb Ihres Unternehmens, deshalb bleibt ein System, das sie liest, angreifbar, solange es läuft. Die OWASP Top 10 for LLM Applications 2025, eine Risikoliste des Sicherheitsprojekts OWASP, am selben Tag abgerufen, führen Prompt Injection an erster Stelle. Ein Beispiel lautet: „Ein Angreifer schleust einen Prompt in einen Kundensupport-Chatbot ein und weist ihn an, vorherige Richtlinien zu ignorieren, private Datenspeicher abzufragen und E-Mails zu versenden, was zu unbefugtem Zugriff und einer Ausweitung von Berechtigungen führt.“

Designregeln gegen Prompt Injection, etwa dem System nicht mehr Zugriff zu geben, als seine Aufgabe erfordert, stehen im Artikel über einen festgefahrenen Pilot. OWASP nennt außerdem eine Maßnahme, die während des Betriebs zu wiederholen ist: „Führen Sie regelmäßig Penetrationstests und Angriffssimulationen durch und behandeln Sie das Modell dabei als nicht vertrauenswürdigen Nutzer“. Bei Penetrationstests versuchen Tester mit Ihrer Erlaubnis gezielt, in das System einzudringen.

Penetrationstests gehören in den Plan der Betriebsaufgaben, und der Vertrag sollte festlegen, welche Seite sie beauftragt und die Befunde behebt. Logs können den vollständigen Text von Tickets enthalten. Entscheiden Sie also, wer sie lesen darf und wie lange sie aufbewahrt werden.

Was kostet der Betrieb des Systems jeden Monat, und was sollten wir vor der Unterschrift fragen?

Die monatlichen Kosten auf eigenen Servern beginnen bei den Servern und ihren GPUs, gekauft oder gemietet, und bei der Arbeitszeit der Mitarbeiter für die Review-Queue. Hinzu kommen ein Supportvertrag, wenn die Firma eine Rolle behält, und erneute Tests nach jeder Änderung. Zahlen werden hier nicht genannt, weil jede von Ihren Volumen und Ihrem Setup abhängt.

Wie sich die Kosten zusammensetzen, hängt vom gewählten Weg ab. Betreibt die Firma das System, steckt ein großer Teil der Kosten im Supportvertrag. Nach einer Übergabe entfällt mehr davon auf die Arbeitszeit Ihrer eigenen Mitarbeiter, einschließlich der Schulung.

Stellen Sie jeder Firma, die anbietet, das System zu bauen und zu betreiben, dieselben Fragen:

• Welche Betriebsaufgaben übernehmen Sie nach dem Start, und welche erledigt unser IT-Team?
• Wie oft bewerten Sie das System an unserer Teststichprobe?
• Wer bezahlt die erneuten Tests, wenn eine von uns genutzte Modellversion außer Betrieb genommen wird?
• Was erhält unser IT-Team bei der Übergabe, und wie prüfen Sie, ob es das System allein betreiben kann?

Lizenzbedingungen unterscheiden sich von Modell zu Modell, und Datenschutzregeln unterscheiden sich je nach Land. Dieser Artikel ist keine Rechtsberatung, prüfen Sie die für Sie geltenden Bedingungen also mit einem Anwalt.

Wo passt amBrain ins Bild?

Das einzige Sprachmodell-Projekt, das amBrain öffentlich beschreibt, ist dieses: „Wir haben eine LLM-Integration innerhalb des FinTech-Perimeters eines Kunden in Produktion gebracht: die Extraktion und Normalisierung unstrukturierter Mitteilungen von Brokern und Handelsplätzen – Kapitalmaßnahmen, Instrumenten- und Margin-Änderungen – zu strukturierten Datensätzen, die das Handelssystem verarbeitet.“

Dieser Artikel ist keine Case Study und beschreibt keine Arbeit für Kunden. Die zitierte Zeile sagt nicht, wer dieses System heute betreibt, wo sein Modell läuft oder welche Schritte dieses Artikels es umfasste. Die Support-Tickets, Dokumente und Betriebswege in diesem Artikel sind allgemeine Beispiele und stammen weder aus diesem Projekt noch aus anderer Arbeit von amBrain.

Die hier genannten Anbieter, Modellhersteller und Softwareprojekte sind Beispiele anhand veröffentlichter Seiten, und der Artikel behauptet keine Beziehung zwischen amBrain und einem von ihnen. Der Artikel nennt weder Preise noch Zeitpläne oder Bedingungen von amBrain.

amBrain entwickelt seit 2019 Software. Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“ Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben Fragen wie jeder anderen Firma.