13 · Grundlagen & Modelle

Proprietäres Modell

geschlossenes Modell, nur über Anbieter/API nutzbar.

Zugriff nur über die Schnittstelle des Anbieters: Man schickt Daten hin, bekommt Antworten zurück und bezahlt pro Nutzung. Dafür gibt es meist die stärksten Modelle und den geringsten Betriebsaufwand. Die Kehrseite ist Kontrollverlust — über Preise, Modelländerungen und die Frage, was mit den eigenen Daten geschieht. Verträge und Ausstiegspfade gehören deshalb zur Architektur.

Ein Beispiel

Ein Mittelständler baut seinen Angebotsprozess auf einem Cloud-Modell auf. Nach acht Monaten kündigt der Anbieter die genutzte Modellversion ab; die Nachfolgeversion formuliert anders, und die sorgfältig abgestimmten Anweisungen liefern plötzlich andere Ergebnisse. Nichts davon ist ein Vertragsbruch — Modellversionen haben Lebenszyklen wie Software. Nur hatte niemand damit gerechnet, dass ein Update das Verhalten ändert, ohne dass sich eine Zeile im eigenen Code bewegt.

Genauer betrachtet

Der Zugang läuft über die Schnittstelle des Anbieters. Damit liegen Versionierung, Verfügbarkeit, Preis und Verhalten außerhalb der eigenen Kontrolle. Ein Modellwechsel beim Anbieter kann Ergebnisse verändern, ohne dass im eigenen Code etwas geändert wurde.

Warum das zählt

Der entscheidende Unterschied zu klassischer Zulieferung: Sie kaufen keine Spezifikation, sondern ein Verhalten, das sich ändern darf. Wer proprietäre Modelle produktiv einsetzt, braucht deshalb drei Dinge im Vertrag und im Betrieb — eine Zusage zur Vorlaufzeit bei Abkündigungen, die Möglichkeit, eine Modellversion festzuschreiben, und eine eigene Testsuite, die nach jedem Wechsel durchläuft. Ohne die dritte merken Sie eine Verhaltensänderung erst, wenn ein Kunde sich beschwert.

Häufig missverstanden

Die Bindung entsteht selten über das Modell, sondern über alles drumherum: Prompts, Werkzeuganbindung, Auswertungen. Wer den Wechsel offenhalten will, muss diese Schicht austauschbar bauen.

Nachbarschaft

Verwandte Begriffe

Der Brief.