Das Tool läuft.
Benutzt wird es nicht.

Bei der Abnahme einer KI-Anbindung frage ich nicht mehr, ob sie funktioniert. Das zeigen die Tests. Ich frage, wer in vier Wochen noch damit arbeitet – und darauf hat am Tag der Abnahme meistens niemand eine Antwort.

Vier Wochen nach dem Launch

Ein Verlauf, wie er bei KI-Projekten in kleinen Unternehmen typisch ist: Ein Betrieb mit gut zwanzig Leuten im Büro will Angebotstexte schneller schreiben. Gebaut wird ein interner Assistent, der aus den Eckdaten eines Auftrags einen Entwurf erzeugt, mit den hauseigenen Textbausteinen als Grundlage. Die Anbindung ist sauber, die Antworten sind brauchbar, es gibt eine einstündige Einführung für alle.

Vier Wochen später zeigen die Logs ein klares Bild. Drei Personen arbeiten täglich mit dem Werkzeug. Fünf haben es ein- oder zweimal ausprobiert. Der Rest hat es nie geöffnet. Gleichzeitig erwähnt jemand beiläufig, dass er seine Angebote „sowieso schon länger mit ChatGPT“ schreibt – im privaten Konto, mit Kundennamen und Preisen im Prompt.

Technisch ist an dieser Stelle nichts kaputt. Und genau das macht den Fall lehrreich: Es gibt kein Ticket, das man abarbeiten könnte. Die Geschäftsführung hat ein Werkzeug bezahlt, das kaum jemand nutzt, und ein Datenschutzproblem, von dem sie bis eben nichts wusste.

Die naheliegende Reaktion ist eine zweite Schulung und eine Rundmail mit der Bitte, das neue Werkzeug zu verwenden. Das ändert erfahrungsgemäß wenig, weil es an der falschen Stelle ansetzt. Niemand nutzt das Werkzeug nicht, weil er nicht weiß, wo der Button ist. Die Gründe liegen woanders, und ein Teil davon lässt sich messen.

Nutzung messen, nicht Aufrufe

Die meisten Anbindungen protokollieren, was für den Betrieb nötig ist: Anfrage, Antwort, Tokens, Latenz. Daraus lässt sich ablesen, ob das System läuft, aber nicht, ob es hilft. Dafür fehlt die wichtigste Information: Was hat die Person mit dem Ergebnis gemacht?

Es reicht, für jedes Ergebnis einen von drei Ausgängen festzuhalten. Übernommen, also ohne nennenswerte Änderung weiterverwendet. Bearbeitet, also als Ausgangspunkt genutzt. Verworfen, also gelöscht oder neu angefordert. Den Ausgang muss niemand von Hand eintragen, er ergibt sich aus dem, was im Formular passiert:

<?php

namespace App\Support\Ki;

use App\Models\KiErgebnis;

final class AusgangErfassen
{
  /**
   * Vergleicht den gespeicherten Text mit dem erzeugten Entwurf.
   *
   * Die Schwelle ist bewusst grob: Es geht nicht um die exakte Quote,
   * sondern um die Frage, ob ein Aufgabentyp überwiegend hilft oder
   * überwiegend Nacharbeit erzeugt.
   */
  public function __invoke(KiErgebnis $ergebnis, ?string $gespeichert): void
  {
    if ($gespeichert === null) {
      $ergebnis->update(['ausgang' => 'verworfen']);
      return;
    }

    similar_text($ergebnis->entwurf, $gespeichert, $prozent);

    $ergebnis->update([
      'ausgang' => $prozent >= 90 ? 'uebernommen' : 'bearbeitet',
    ]);
  }
}

Nach zwei Wochen lohnt ein Blick auf die Verteilung, getrennt nach Aufgabentyp und nach Person. Personenbezogene Auswertungen sind dabei heikel und in vielen Betrieben ein Fall für den Betriebsrat. Ich zeige sie deshalb nur aggregiert, ohne Namen: Es geht um die Frage, ob die Nutzung breit gestreut ist oder an wenigen Leuten hängt, nicht darum, wer wie viel macht.

Typischerweise zeigt sich zweierlei. Erstens hängt fast die gesamte Nutzung an den paar Leuten, die sich ohnehin für das Thema interessieren. Zweitens gibt es Aufgabentypen mit einer hohen Verwerfungsquote. Im Angebotsbeispiel wären das etwa Folgeangebote, bei denen der Entwurf die Absprachen aus dem letzten Telefonat nicht kennen kann. Wer das zweimal erlebt hat, probiert es kein drittes Mal – und erzählt es den Kollegen.

Private Konten als Anforderungsliste

Das private Chat-Konto ist der unangenehmste Teil des Befunds, aber auch der aufschlussreichste. Es zeigt, dass Bedarf da ist – nur nicht an der Stelle, an der das Projekt ihn vermutet hat.

Das Datenschutzproblem ist real. Für ein privates Verbraucherkonto gibt es keinen Vertrag zur Auftragsverarbeitung mit dem Unternehmen. Ob Eingaben zum Training verwendet werden, entscheidet die Person in ihren Kontoeinstellungen, nicht der Arbeitgeber. Und wenn die Person das Unternehmen verlässt, nimmt sie den Verlauf mit. Kundennamen und Preise haben dort nichts zu suchen.

Ein Verbot allein löst das trotzdem nicht. Wer mit einem privaten Werkzeug schneller ist als mit dem offiziellen, wird das Verbot als Hindernis erleben und im Zweifel umgehen. Brauchbarer ist die Frage, wofür das private Konto genutzt wird. In den Gesprächen, die ich dazu führe, kommen fast immer Dinge heraus, die im Projekt nie auf dem Plan standen: E-Mails an schwierige Kunden glätten, eine technische Beschreibung für Laien umschreiben, eine Tabelle aus einem PDF ziehen.

Das sind meist kleine, gut abgrenzbare Aufgaben. Viele davon lassen sich mit wenig Aufwand in das offizielle Werkzeug holen, und zwar mit genau dem Vorteil, den das private Konto nicht hat: Die Daten bleiben in einer Umgebung mit Vertrag, Protokoll und klaren Regeln. So wird aus dem Verbot ein Angebot – und das Angebot ist bequemer als der Umweg.

Drei Regeln statt eines Handbuchs

Das Gegenstück zum Wildwuchs ist das zwanzigseitige Regelwerk, das niemand liest. In einem Betrieb dieser Größe braucht es keines. Was es braucht, sind wenige Regeln, die sich jeder merken kann, und eine technische Umsetzung, die sie durchsetzt, ohne dass jemand daran denken muss.

• check_circle Kundendaten gehen nur in das offizielle Werkzeug, nie in ein privates Konto.
• check_circle Was das Haus verlässt – Angebot, Mail, Text auf der Website –, hat ein Mensch gelesen.
• check_circle Wer etwas Neues ausprobieren will, darf das. Er sagt nur Bescheid, wofür.

Die erste Regel lässt sich zum Teil im Code festhalten. Statt im Prompt zu hoffen, dass keine sensiblen Daten mitgeschickt werden, ordnet die Anbindung jedem Aufgabentyp eine Datenklasse und jeder Datenklasse die erlaubten Modelle zu. Die Datei liegt im Repository und läuft durch dasselbe Review wie jede andere Änderung. Das Budget pro Aufgabe steht gleich mit darin, dazu weiter unten mehr:

<?php

/**
 * Welche Daten an welches Modell gehen dürfen.
 *
 * Die Zuordnung hängt am Aufgabentyp, nicht am einzelnen Prompt: Ob ein
 * Angebot Kundendaten enthält, weiß man vorher, und eine Regel, die erst
 * zur Laufzeit raten muss, versagt im ungünstigsten Moment.
 */
return [
  'datenklassen' => [
    'oeffentlich' => ['modelle' => ['standard', 'schnell']],
    'intern'      => ['modelle' => ['standard']],
    // Nur Anbieter mit Auftragsverarbeitungsvertrag und EU-Verarbeitung.
    'kunde'       => ['modelle' => ['standard-eu']],
  ],

  'aufgaben' => [
    'angebot-entwurf' => ['datenklasse' => 'kunde',       'freigabe' => true,  'budget_cent' => 8],
    'mail-glaetten'   => ['datenklasse' => 'kunde',       'freigabe' => true,  'budget_cent' => 2],
    'text-fuer-laien' => ['datenklasse' => 'intern',      'freigabe' => false, 'budget_cent' => 2],
    'website-entwurf' => ['datenklasse' => 'oeffentlich', 'freigabe' => true,  'budget_cent' => 5],
  ],
];

Das Feld freigabe setzt die zweite Regel um: Ergebnisse mit diesem Merkmal lassen sich nicht direkt versenden, sondern landen als Entwurf, den jemand bestätigen muss. Die dritte Regel braucht keinen Code. Sie braucht nur jemanden, dem man Bescheid sagt, und das Versprechen, dass ein gescheiterter Versuch keine Folgen hat.

Budgets statt Rügen

Ein zuverlässiger Weg, frisch gewonnene Nutzer wieder zu verlieren, ist die erste Monatsrechnung. Sie fällt höher aus als erwartet, und die Reaktion ist eine Mail an alle, man möge sparsamer mit dem Werkzeug umgehen. Wer das liest, fragt sich zu Recht, ob er das Werkzeug überhaupt noch verwenden soll.

Das eigentliche Problem ist, dass niemand vorher wusste, was eine Aufgabe kosten darf. Wie man das misst, habe ich in Kosten pro Aufgabe statt pro Aufruf beschrieben. Für die Einführung zählt vor allem die Konsequenz daraus: Das Budget gehört an den Aufgabentyp, nicht an die Person, und es wird im Werkzeug sichtbar, bevor jemand es überschreitet.

// Ein Lauf, der das Budget seines Aufgabentyps überschreitet, wird nicht
// abgebrochen, sondern markiert. Abbrechen würde die Person bestrafen, die
// gerade eine schwierige Aufgabe hatte – das Signal ist für die Auswertung
// gedacht, nicht für sie.
$budget = config("ki.aufgaben.{$aufgabe}.budget_cent", 5);

if ($lauf->kostenCent() > $budget) {
  $lauf->markiere('ueber-budget');
}

Taucht ein Aufgabentyp regelmäßig über seinem Budget auf, ist das eine Frage an die Anbindung, nicht an die Nutzer: zu viel Kontext, ein zu teures Modell, zu viele Runden. Die Rechnung wird so zu einem Hinweis, wo die Technik nachgebessert werden muss, statt zu einem Grund, das Werkzeug zu meiden.

Einarbeitung gehört ins Angebot

Der größte Posten, der in KI-Projekten fehlt, ist Zeit. Nicht die Entwicklungszeit, sondern die Zeit, die die Leute brauchen, um ihre Arbeitsweise umzustellen. Wer seit zehn Jahren Angebote auf eine bestimmte Art schreibt, hat dafür eingeschliffene Handgriffe. Die ersten Wochen mit dem neuen Werkzeug sind langsamer als vorher, nicht schneller. Wer in dieser Zeit unter vollem Tagesgeschäft steht, kehrt zum Gewohnten zurück.

Dazu kommt eine Frage, die selten offen gestellt wird: Was habe ich davon? Wenn ein Werkzeug Arbeit schneller macht, liegt die Befürchtung nahe, dass am Ende einfach mehr Arbeit auf dem Tisch liegt oder eine Stelle weniger gebraucht wird. Darauf kann ich als Entwickler keine Antwort geben. Ich kann aber darauf hinweisen, dass die Frage im Raum steht, und darauf drängen, dass die Geschäftsführung sie beantwortet, bevor das Werkzeug ausgerollt wird.

Was ich selbst tun kann, schreibe ich inzwischen direkt ins Angebot:

• check_circle Zwei Wochen Pilotphase mit den Leuten, die schon Interesse zeigen, bevor alle es bekommen.
• check_circle Kurze Sitzungen am echten Arbeitsplatz statt einer großen Schulung im Besprechungsraum.
• check_circle Ein fester Termin nach vier Wochen, um die Nutzungsdaten gemeinsam anzusehen.
• check_circle Ein Kontingent für Anpassungen, die sich erst im Alltag zeigen.

Die Pilotgruppe ist dabei der wichtigste Hebel. Wer in einem kurzen Termin zeigt, wie er mit dem Werkzeug ein Angebot in zehn Minuten statt in vierzig schreibt, überzeugt die Kollegen eher als jede Rundmail. Das funktioniert aber nur, wenn das Werkzeug für genau diese Aufgabe vorher gut geworden ist – deshalb steht die Auswertung der Pilotphase vor dem Rollout, nicht danach.

Fazit

Ob eine KI-Anbindung im Alltag ankommt, entscheidet sich selten an der Modellwahl. Es entscheidet sich daran, ob jemand nach dem Launch hinsieht, wer sie nutzt und wofür, und ob das Projekt Zeit und Budget hat, darauf zu reagieren.

Als Entwickler kann ich einen erstaunlich großen Teil davon technisch abstützen: den Ausgang jedes Ergebnisses erfassen, Datenregeln in eine versionierte Datei schreiben, Kosten pro Aufgabe sichtbar machen statt pro Monat. Den Rest – Zeit für die Umstellung, eine ehrliche Antwort auf die Frage nach dem eigenen Nutzen – muss das Unternehmen selbst liefern. Meine Aufgabe ist, das vor Projektbeginn offen anzusprechen.

Und das private Chat-Konto ist dabei kein Gegner. Es ist die genaueste Anforderungsliste, die man in so einem Projekt bekommen kann.