Ein digitaler Mitarbeiter ist eine kontrollierte Rolle. Aufgabe, Daten, Freigabe und Rückfallweg entscheiden über den Nutzen.

Vertrieb, Office und Hotel brauchen unterschiedliche Grenzen

Im Vertrieb kann ein Pilot Anfragen vorstrukturieren; verbindliche Angebote brauchen eine festgelegte Freigabe. Im Office kann er Informationen zuordnen oder einen Entwurf vorbereiten; Zahlungen und weitreichende Änderungen bleiben gesondert kontrolliert. Jede Rolle erhält eigene erlaubte Aktionen und Testfälle.

Ein Hotelszenario, etwa das Vorbereiten einer Antwort auf eine Gästefrage, ist ein Konzeptbeispiel. Es beweist keine einsatzfertige Hotel-Lösung; deren Status bleibt auf der Leistungsseite als Planung erkennbar. Prüfen Sie generell falsche Angaben, fehlende Quellen, unerlaubte Aktionen und die Übergabe an eine zuständige Person.

Vertrieb: von der Anfrage zur geprüften CRM-Aufgabe

Wofür: Wiederkehrende Anfragen sollen mit ihrem Kontext bei der richtigen Person ankommen. Die Rolle bereitet eine Antwort und den nächsten Arbeitsschritt vor. Sie entscheidet weder über den Kunden noch über einen verbindlichen Preis. Der mögliche Nutzen ist weniger Such- und Übertragungsarbeit; eine Zeitersparnis muss im eigenen Betrieb gemessen werden.

So läuft unser Funktionsbeispiel AN-1042: Eine fiktive Anfrage nennt acht Personen und den Wunsch nach einem zentralen CRM. Daraus entsteht ein Antwortentwurf mit Rückfragen zum bisherigen System, ohne Preis- oder Terminzusage. Der Vertrieb prüft Quelle, Empfänger und Formulierung. Erst seine Freigabe ergibt im Beispiel einen Vermerk und eine Aufgabe: Bedarf klären.

So setzen wir den Ablauf auf: Vorhandenes Formular, Postfach und CRM prüfen; erforderliche Felder, Verantwortliche und erlaubte Quellen festlegen; zunächst Entwürfe ohne Versand erstellen; anschließend den freigegebenen Übergabeschritt anbinden. Ob eine konkrete Schnittstelle passt, wird vor dem Auftrag geklärt. Zur Übergabe gehören Testfälle, Berechtigungen, ein Prüfprotokoll und ein Weg zurück zum manuellen Ablauf.

Besser so: Fehlende Angaben als Rückfrage ausgeben, einen Entwurf eindeutig kennzeichnen und doppelte Anfragen erkennen. Nicht so: Preise erfinden, Termine zusagen oder Kontakte ohne geklärten Zweck in weitere Systeme kopieren. Der Fehlerfall zeigt absichtlich eine Anfrage ohne ausreichenden Umfang. Nach dem Ergänzen muss der Mensch erneut freigeben.

Abnahme: Anfrage, Quelle, Entwurf und CRM-Aufgabe lassen sich derselben Kennung zuordnen. Unvollständige oder doppelte Eingänge erzeugen keine unkontrollierten Folgeaktionen. Messen Sie vor und während des Piloten Bearbeitungszeit, nötige Korrekturen und Fehlzuordnungen. Ein erfolgreich abgespieltes Website-Beispiel ersetzt diesen Test im Zielsystem nicht.

Vertrieb: Normalfall und fehlende Angaben ausprobieren

CRM und Anfrageprozess: Leistungsumfang ansehen

Office: vom Beleg zur freigegebenen Zuordnung

Wofür: Dokumente sollen mit nachvollziehbarer Zuordnung und offener Aufgabe weiterbearbeitet werden können. Die Rolle hilft beim Lesen und Vorbereiten; eine zuständige Person entscheidet über die Übernahme. Das ist sinnvoll, wenn Mitarbeiter ähnliche Belege regelmäßig übertragen oder Rückfragen aus Dokumenten zusammensuchen.

Unser Funktionsbeispiel DOC-1042 enthält einen Servicebericht zum Auftrag AU-318 und eine offene Ersatzteilfrage. Die Rolle bereitet eine Zuordnung und eine Office-Aufgabe vor. Das Office vergleicht beides mit dem Beleg und prüft den Ablageort. Nach Freigabe zeigt das Beispiel einen Prüfvermerk mit Dokumentkennung, Ziel und Aufgabe. Es lädt keine Datei hoch und verändert kein echtes System.

So entsteht die Umsetzung: Belegarten und Ablagestruktur sichten; benötigte Felder und Zugriffsrechte vereinbaren; unleserliche und mehrdeutige Dokumente in eine Prüfliste geben; Ausgabe gegen das Original anzeigen; erst den freigegebenen Schritt in das vorhandene Office-System übernehmen. Eine einfache feste Zuordnungsregel kann geeigneter sein als KI. Wir prüfen das vor einer Erweiterung.

Besser so: Original und Auszug gemeinsam prüfen, die Auftragsnummer eindeutig verknüpfen und Änderungen protokollieren. Nicht so: Eine schlecht erkannte Nummer still ergänzen, Dokumente automatisch löschen oder aus einem Beleg eine Zahlung auslösen. Bei unleserlicher Zuordnung bleibt der Vorgang gesperrt. Das Ergänzen eines Werts ist noch keine Freigabe.

Abnahme: Richtige, unleserliche, doppelte und nicht zuordenbare Belege testen. Prüfen, ob fehlende Angaben sichtbar bleiben, dieselbe Datei keine doppelten Aufgaben erzeugt und Zugriffe auf den nötigen Bereich beschränkt sind. Erst gemessene Korrekturrate und Bearbeitungsaufwand zeigen, ob sich der Ablauf für Ihr Office eignet.

Office: Beleg und fehlende Zuordnung ausprobieren

Microsoft 365: Zusammenarbeit und Zugänge planen

Warum Quellen, Rechte und Freigaben zusammengehören

Nachrichten und Dokumente sind Arbeitsmaterial, keine Befehle an das System. OWASP beschreibt, wie fremde Inhalte unerwünschte Anweisungen einschleusen können (Prompt Injection). Deshalb gehören getrennte Quellen, begrenzte Berechtigungen, Prüfung der Ausgabe und gezielte Fehlerfälle zum Entwurf eines Ablaufs. Ein gut formulierter Prompt allein beseitigt das Risiko nicht.

OWASP behandelt außerdem zu weitreichende Handlungsmöglichkeiten als eigenes Risiko (Excessive Agency). Unsere Praxisempfehlung: zunächst nur einen Entwurf erstellen, Änderungen auf wenige erlaubte Aktionen begrenzen und folgenreiche Schritte ausdrücklich freigeben lassen. Das NIST AI Risk Management Framework dient als methodische Grundlage für die laufende Bewertung; es zertifiziert weder diese Beispiele noch eine Kundenumsetzung.

Vor dem Auftrag halten wir Ausgangslage, Ziel, Datenzugänge, Verantwortliche, Prüfkriterien und laufende Kosten fest. Der Pilot beginnt mit einem begrenzten Vorgang. Ein Produktionsstart folgt erst nach Prüfung im vereinbarten System. Die Beispiele zeigen die Bedienlogik mit fiktiven Daten; sie belegen keine bereits erzielten Kundenergebnisse.

Im Überblicksbeispiel prüfen Sie diese Grenze selbst: Vertrieb liest den freigegebenen Leitfaden CRM-01, Office den Ablageplan OFF-01. Fehlt ein Preis, entsteht eine Rückfrage ohne erfundene Summe. Fehlt der Lesezugriff, bleibt der Quelleninhalt gesperrt und es entsteht kein Entwurf. Erst in der Prüfung können Sie Quelle und Entwurf bestätigen und den Vorschlag im Beispiel freigeben. Der automatische Durchlauf erteilt keine Freigabe. Alle Daten sind fiktiv; die Ausgabe folgt festen Regeln und verwendet keine laufende KI. Für einen echten Pilot müssen Quellenzugriff, Antwortqualität und die konkrete Übergabe im Zielsystem geprüft werden.

Quelle, Rückfrage und Freigabe selbst prüfen

OWASP: Risiken durch fremde Anweisungen

OWASP: zu weitreichende Handlungsrechte

Readiness: Voraussetzungen vor dem Pilot klären

Recruiting-Roadmap: einen Gesprächstermin abstimmen

Das Organisationsbeispiel ORG-1042 zeigt einen engen Ablauf: Zeitwunsch aufnehmen, mit der Team-Verfügbarkeit und der Rückmeldung des Gesprächspartners abgleichen, einen Nachrichtenentwurf vorbereiten und durch einen Menschen prüfen lassen. Es geht um Terminabstimmung; Bewerber werden weder bewertet noch ausgewählt. Die Recruiting-Rolle bleibt Roadmap und ist nicht aktiv buchbar.

Ist die Zeit frei und die Rückmeldung vorhanden, entsteht ein Vorschlag zur Prüfung. Ist das Team belegt, fragt der Entwurf nach anderen Zeiten. Fehlt eine Antwort, bittet er um Bestätigung der Verfügbarkeit. Eine fehlende Antwort darf nicht als Zustimmung erscheinen. Das Beispiel schlägt keinen unbelegten Ersatztermin vor.

Vergleichen Sie in der Prüfung den Entwurf mit dem sichtbaren Testplan. Erst die eigene Bestätigung vermerkt die Prüfung im Beispiel; das automatische Abspielen erteilt sie nicht. Alle Angaben sind fiktiv und die Texte folgen festen Regeln. Das Beispiel führt keine KI aus, verschickt keine Nachrichten und bucht keine Termine. Für einen späteren realen Einsatz müssten Quellen, Rechte, Zuständigkeit, Versand und Fehlerfälle gesondert geprüft werden.

Terminabstimmung und Grenzen selbst ansehen

Bestehende Lösungen für Personalvermittlung