Start with the bottleneck, not the model

The strongest starting point is a recurring task where people spend substantial time searching, sorting or drafting. Examples include qualifying an enquiry, preparing a reply or bringing information together.

Ambiguous, high-risk decisions make poor first use cases because apparent automation quickly becomes extra review work.

• The task occurs regularly in a similar form
• Suitable source data is available and current
• A wrong suggestion can be recognised and corrected
• Value can be measured through time, quality or throughput

Put sources and boundaries in the interface

Users should see what an answer is based on and what status it has. A draft is not a sent message, a recommendation is not an approval, and a summary does not replace its source.

These boundaries belong in the product through source links, editing, roles and precise action labels—not only in an internal policy.

Design the human handoff

A dependable assistant recognises when it should stop. Missing data, sensitive content, unusual cases or low confidence can trigger a handoff.

The handoff must preserve the conversation, relevant sources and the reason for escalation. Otherwise the person starts again and the promised efficiency disappears.

Clarify privacy and operations early

Before prototyping, establish which data is processed, where it is stored and who may access outputs. Personal or confidential content requires a deliberately chosen architecture.

Ongoing quality matters too: which examples are reviewed, how are problematic outputs reported, and who approves new sources or rules?

A useful first pilot

A four-to-six-week pilot should cover one narrow workflow with real cases. Measure handling time, correction effort and the quality of handoffs.

Expand only after that core works reliably. This protects the budget and builds trust with the people who use the system every day.

Mit dem Engpass beginnen, nicht mit dem Modell

Der beste Startpunkt ist eine wiederkehrende Tätigkeit, bei der Menschen viel Zeit mit Suchen, Sortieren oder Formulieren verbringen. Beispiele sind die Vorqualifizierung einer Anfrage, ein Antwortentwurf oder das Zusammenführen von Informationen.

Unklare Entscheidungen mit hohem Risiko sind dagegen ein schlechter erster Anwendungsfall. Dort wird aus vermeintlicher Automatisierung schnell zusätzlicher Prüfaufwand.

• Die Aufgabe tritt regelmäßig und ähnlich auf
• Geeignete Quelldaten sind verfügbar und aktuell
• Ein falscher Vorschlag lässt sich erkennen und korrigieren
• Der Nutzen kann über Zeit, Qualität oder Durchlauf messbar werden

Quellen und Grenzen gehören in die Oberfläche

Nutzer sollten erkennen, worauf eine Antwort basiert und welchen Status sie hat. Ein Entwurf ist kein Versand, eine Empfehlung ist keine Freigabe und eine Zusammenfassung ersetzt nicht die Quelldatei.

Solche Grenzen gehören nicht nur in eine interne Richtlinie. Sie müssen im Produkt sichtbar werden: durch Quellenlinks, Bearbeitungsmöglichkeiten, Rollen und klare Aktionsbezeichnungen.

Der menschliche Übergabepunkt

Ein verlässlicher Assistent kennt Situationen, in denen er nicht weiterarbeiten sollte. Unvollständige Daten, sensible Inhalte, ungewöhnliche Fälle oder eine geringe Sicherheit können eine Übergabe auslösen.

Die Übergabe muss Kontext erhalten: bisherige Eingaben, relevante Quellen und der Grund für die Eskalation. Sonst beginnt der Mensch wieder von vorne und der versprochene Effizienzgewinn verschwindet.

Datenschutz und Betrieb früh klären

Vor dem Prototyp sollte feststehen, welche Daten das System verarbeitet, wo sie gespeichert werden und wer auf Ergebnisse zugreifen darf. Für personenbezogene oder vertrauliche Inhalte braucht es eine bewusst gewählte Architektur.

Ebenso wichtig ist die laufende Qualität: Welche Beispiele werden geprüft? Wie werden problematische Ausgaben gemeldet? Wer entscheidet über neue Quellen oder Regeln?

Ein guter erster Pilot

Ein vier- bis sechswöchiger Pilot sollte einen engen Ablauf mit echten Fällen abdecken. Messbar werden Bearbeitungszeit, Korrekturaufwand und die Quote sinnvoller Übergaben.

Erst wenn dieser Kern verlässlich funktioniert, lohnt sich die Erweiterung. Das schützt Budget und schafft Vertrauen bei den Menschen, die täglich mit dem System arbeiten.