Eine kleine Änderung an einer KI-Anweisung kann grosse Auswirkungen auf Antworten und Aktionen haben. Mit nachvollziehbaren Versionen können Fachteam und Agentur erkennen, welcher Stand geprüft wurde und welcher tatsächlich läuft.
Ein Prompt ist Teil der Anwendung
Im Pilot wird eine Formulierung häufig direkt im Werkzeug verbessert. Das ist zum Ausprobieren praktisch. Sobald mehrere Personen eine produktive Anwendung verwenden, entsteht daraus jedoch eine Frage: Welche Anweisung hat die Antwort von gestern erzeugt, und wer hat sie seitdem verändert?
Eine Datei namens «Prompt final neu» löst dieses Problem nicht. Sie benötigen einen eindeutig bezeichneten Stand, einen nachvollziehbaren Änderungsgrund und eine Verbindung zur laufenden Anwendung. Versionierung bedeutet dabei mehr als eine fortlaufende Nummer im Dokumenttitel.
Die AWS-Dokumentation zu Promptversionen unterscheidet bearbeitbare Entwürfe und gespeicherte Snapshots für den Anwendungseinsatz. Dieses Prinzip lässt sich auch unabhängig vom konkreten Anbieter für die Zusammenarbeit mit einer KI-Agentur nutzen.
Was zu einer Version gehört
Der Wortlaut allein beschreibt das Verhalten nicht vollständig. Ein Prompt wirkt zusammen mit dem Modell, dessen Einstellungen, verfügbaren Werkzeugen und dem Kontext aus anderen Datenquellen. Halten Sie diese Bestandteile soweit fest, wie sie für Ihre Anwendung relevant sind.
Amazon Bedrock dokumentiert bei der Prompt-Erstellung unter anderem Variablen, Modellwahl und Inferenzparameter. Daraus ergibt sich eine wichtige Grenze: Zwei identische Anweisungstexte müssen bei unterschiedlichen Konfigurationen nicht dasselbe Verhalten zeigen.
Für die Projektabnahme empfehlen wir eine Versionskarte. Sie enthält einen kurzen Zweck, die technische Kennung, den Änderungsgrund und die Testreferenz. Vertrauliche Daten oder echte Zugangsschlüssel gehören nicht in den Anweisungstext und auch nicht in eine frei zugängliche Versionshistorie.
Ein ausgefülltes Beispiel
Eine fiktive Serviceassistenz erstellt Antwortentwürfe zu Lieferanfragen. Der bisherige Stand fragt nach, wenn kein bestätigter Liefertermin vorliegt. Die neue Fassung soll kürzer und freundlicher formulieren. Bei dieser Änderung darf die fachliche Grenze erhalten bleiben.
Eine geeignete Versionskarte könnte so aussehen:
Version: Serviceantwort 1.4, mit unveränderlicher technischer Kennung.
Zweck: bestätigte Informationen verständlich zusammenfassen.
Änderung: kürzere Einleitung und weniger Wiederholungen.
Unverändert zu prüfen: keine Lieferzusage ohne freigegebene Quelle.
Testbestand: 24 künstliche Fälle, davon acht ohne bestätigten Termin.
Ergebnis: ein Fall enthält eine unbelegte Zusage; Freigabe vorerst zurückgestellt.
Verantwortlich: fachliche Prüfung durch die Serviceleitung, technische Bereitstellung durch das Entwicklungsteam.
Die Fallzahlen sind frei gewählt und keine allgemeine Qualitätsvorgabe. Der Nutzwert liegt darin, dass eine gut gemeinte sprachliche Änderung anhand der geschäftlich wichtigen Grenze bewertet wird.
Entwurf, Prüfung und Freigabe trennen
Nicht jede gespeicherte Änderung sollte sofort live gehen. Ein schlanker Ablauf kann aus einem Entwurf, einem vergleichbaren Testlauf und einer benannten Freigabe bestehen. Die Fachperson bewertet das gewünschte Verhalten; die technische Person prüft zusätzlich die Einbindung und den tatsächlich ausgelieferten Stand.
Dokumentieren Sie abgelehnte Änderungen ebenfalls kurz. Sonst taucht dieselbe vermeintliche Verbesserung später erneut auf, ohne dass ihre frühere Nebenwirkung bekannt ist. Es reicht eine nachvollziehbare Notiz mit Testfall und Entscheidung; lange Sitzungsprotokolle sind nicht zwingend nötig.
Nach der Bereitstellung sollte eine kontrollierte Anfrage zeigen, welche Version aktiv ist. Eine Versionsanzeige in der Verwaltung oder ein technisches Ereignis kann diesen Nachweis liefern. Die Behauptung «wir haben die Datei ersetzt» reicht nicht, wenn mehrere Dienste oder Hintergrundprozesse unterschiedliche Stände verwenden könnten.
Rückkehrwege nicht voraussetzen
Eine frühere Promptversion lässt sich oft wieder aktivieren. Das garantiert aber nicht die Wiederherstellung des früheren Gesamtverhaltens. Wurde zwischenzeitlich auch das Modell eingestellt oder der Datenbestand verändert, bleibt der Kontext ein anderer.
Vereinbaren Sie deshalb, welche Komponenten bei einer Rückkehr gemeinsam berücksichtigt werden. Üben Sie diesen Wechsel in einer Testumgebung und prüfen Sie anschliessend die wichtigen Aufgaben. Für Anwendungen mit schreibenden Aktionen braucht es zusätzlich einen Umgang mit bereits begonnenen Vorgängen.
Die Versionshistorie sollte Ihrem Unternehmen zugänglich sein. Bei einem Agenturwechsel muss die neue Betreuung erkennen können, welche Stände existieren und wie die Freigabe funktioniert. Das gehört zu einer sauberen Übergabe, nicht erst zur Vorbereitung eines Konflikts.
Binden Sie diesen Ablauf in die Zuständigkeiten für Ihre KI-Systeme ein. Mit einclick als KI-Umsetzungspartner können Sie einen Änderungsprozess festlegen, der für Ihr Team verständlich bleibt und wichtige Anpassungen überprüfbar macht.
