KI-Automatisierung ausschreiben: ein prüfbares Projektbriefing

Ein brauchbarer Einstieg lautet beispielsweise: „Freigegebene Serviceanfragen aus dem zentralen Postfach werden dem richtigen Kunden zugeordnet, im CRM als Aufgabe angelegt und mit einem Antwortentwurf zur Prüfung vorgelegt.“ Dieser Satz enthält Eingang, Zuordnung, Zielsystem und menschliche Entscheidung.

„Wir möchten unsere Kommunikation mit KI modernisieren“ beschreibt dagegen eine Absicht, aber keinen abnehmbaren Auftrag. Anbieter können darunter Chatbots, Textwerkzeuge, E-Mail-Klassifikation oder eine neue Plattform verstehen. Präzisieren Sie deshalb, welche Arbeit nach dem Projekt tatsächlich anders ablaufen soll.

Eine frühere methodische Veröffentlichung des Fraunhofer IAO betont bereits die Auswahl konkreter Anwendungsfälle, klare Ziele und die Prüfung einfacherer Prozessverbesserungen. Die Quelle stammt aus 2019; wir verwenden diese Planungsprinzipien, keine damaligen Markt- oder Technologieannahmen. Fraunhofer IAO: Schritte zum KI-Pilotprojekt, erneut geprüft am 26. September 2026.

Ablauf und Menge. Dokumentieren Sie den heutigen Ablauf knapp. Wie viele Vorgänge treten in einem normalen Zeitraum auf? Welche Varianten sind häufig? Wo entstehen Rückfragen, doppelte Eingaben oder verspätete Übergaben? Welche Personen bearbeiten den Vorgang und welche Systeme verwenden sie?

Gemessen oder geschätzt. Trennen Sie gemessene Werte von Schätzungen. „Im letzten Monat wurden 420 Anfragen erfasst“ ist etwas anderes als „wahrscheinlich 500 bis 1.000“. Beides kann in einer ersten Anfrage stehen, muss aber unterschiedlich gekennzeichnet werden. Offene Daten dürfen nicht stillschweigend als feste Kalkulationsgrundlage dienen.

Beispiele. Geben Sie repräsentative Beispiele mit. Dazu gehören typische Eingänge, ein unvollständiger Fall und eine schwierige Ausnahme. Verwenden Sie dafür freigegebene anonymisierte oder synthetische Daten. Ein Anbieter braucht die Struktur des Problems, nicht automatisch vollständige Kundenakten im Erstgespräch.

Start und Abschluss. Beschreiben Sie den Startpunkt und den fachlichen Abschluss. Wenn der Auftrag mit einer eingehenden Anfrage beginnt und bei einer geprüften CRM-Aufgabe endet, ist eine anschließende Angebotserstellung nicht automatisch enthalten. Halten Sie solche Grenzen fest, damit später keine unterschiedliche Erwartung entsteht.

Erster Umfang. Ein Umfang kann beispielsweise eine Mailbox, einen CRM-Mandanten, zwei definierte Anfragearten und eine Sprache umfassen. Andere Postfächer, historische Datenmigration und automatische Vertragszusagen bleiben zunächst außerhalb. Diese Begrenzung ist keine technische Schwäche, sondern macht den ersten Auftrag prüfbar.

Abhängigkeiten. Nennen Sie außerdem Abhängigkeiten. Eine interne API-Freigabe, ein noch ungeklärter Tarif oder eine notwendige Datenbereinigung kann den Start beeinflussen. Zu jeder Voraussetzung gehören ein Verantwortlicher und eine Entscheidung, was geschieht, wenn sie nicht rechtzeitig erfüllt wird. Ein Terminplan ohne diese Abhängigkeiten ist wenig belastbar.

Für jede wesentliche Anforderung sind vier Angaben hilfreich: Kennung, gewünschtes Verhalten, Priorität und Nachweis. Vermeiden Sie Sätze wie „Das System soll intelligent und benutzerfreundlich sein“, wenn niemand weiß, wie das geprüft wird.

Die folgende Tabelle zeigt sechs synthetische Anforderungen an einen Ablauf für Serviceanfragen, jeweils mit Kennung und Nachweis bei der Abnahme.

Definieren Sie echte Muss-Kriterien sparsam und begründet. Ein gewünschtes Dashboard ist anders zu behandeln als die Vermeidung einer falschen Empfängeradresse. Wenn jede kosmetische Präferenz ein Muss wird, verlieren Anbieter und Prüfer den Überblick über die wesentlichen Grenzen.

Legen Sie fest, wer eine Abweichung akzeptieren darf. Die Person, die einen technischen Test prüft, ist möglicherweise nicht befugt, eine fachliche Anforderung zu ändern. Halten Sie diesen Entscheidungsweg fest, bevor Lieferdruck informelle Kompromisse verlockend macht.

Aktionen. Listen Sie Quelle, Ziel, benötigte Objektarten und konkrete Aktionen auf. „Verbindung zu Microsoft 365“ ist zu allgemein. Benennen Sie beispielsweise das freigegebene Postfach, die benötigte Leseoperation und den Ort, an dem ein Entwurf gespeichert werden soll. Dass ein Produkt eine Integration anbietet, beweist nicht jede gewünschte Funktion.

Feldbedeutung. Für Felder braucht es Bedeutung und Führung. Welche Kennung identifiziert einen Kunden? Welche Quelle darf eine Telefonnummer ändern? Bedeutet ein fehlender Wert „unbekannt“ oder „löschen“? Solche Unterschiede entscheiden über korrekte Verarbeitung und sollten nicht erst während der Umsetzung zufällig festgelegt werden.

Annahmen des Anbieters. Bitten Sie Anbieter, bestätigte Unterstützung, notwendige Anpassungen und ungeklärte Voraussetzungen getrennt auszuweisen. Eine geplante individuelle API-Verbindung ist ein anderer Aufwand als eine vorhandene Standardfunktion. Beide können sinnvoll sein; die Annahme muss im Angebot sichtbar bleiben.

Aufgabe des Modells. Beschreiben Sie, wofür das Modell gebraucht wird: Text zusammenfassen, Angaben vorschlagen, eine Kategorie wählen oder eine Antwort vorbereiten. Danach beschreiben Sie getrennt, welche Systemaktion folgen darf. Ein Modell, das einen richtigen Entwurf erstellt, hat damit noch keine Berechtigung zum Versand.

Schreibende Aktionen. Für jede schreibende Aktion brauchen Sie Ziel, zulässige Parameter und Freigaberegel. Legen Sie fest, welche Informationen die prüfende Person sieht und was bei Ablehnung geschieht. Warten ohne Antwort wird nicht stillschweigend als Zustimmung behandelt.

Geschäftsregeln. Auch bei einem Agenten gehören eindeutige Geschäftsregeln außerhalb der freien Textausgabe geprüft. Ein Kundenbezug, ein zulässiger Statusübergang und der Schutz vor doppelter Ausführung sollten nicht nur als Wunsch im Prompt stehen. Der Anbieter soll erklären, wo diese Kontrollen technisch und organisatorisch umgesetzt werden.

Erwartete Ergebnisse. Legen Sie die erwarteten Ergebnisse vor dem Test fest. Nutzen Sie normale Fälle und bewusst schwierige Varianten. Ein Prüfsatz nur mit perfekten Eingaben kann eine überzeugende Demonstration ermöglichen, ohne den späteren Betrieb abzubilden.

Fehlertypen. Unterscheiden Sie verschiedene Fehlertypen. Eine sprachlich holprige Formulierung ist nicht dasselbe wie eine falsche Kundenzuordnung. Bewerten Sie wesentliche Felder und Aktionen gesondert. Ein allgemeiner Prozentwert „Genauigkeit“ bleibt unklar, wenn nicht definiert ist, was gezählt wird und welche Fehler besonders schwer wiegen.

Wiederholte Tests. Bei generierten Inhalten können wiederholte Tests sinnvoll sein, weil Ergebnisse variieren können. Halten Sie Modell- und Konfigurationsstand sowie verwendete Beispiele fest. Ein einmal richtig beantworteter Fall beweist keine allgemeine Zuverlässigkeit. Verlangen Sie auch, dass unklare Fälle erkennbar zurückgestellt werden, statt eine scheinbar vollständige Antwort zu erzwingen.

Rahmenwerk. Das freiwillige NIST AI Risk Management Framework verbindet Kontext, Messung und laufenden Umgang mit Risiken. Es ist eine methodische Orientierung, keine automatische Abnahme oder gesetzliche Konformitätszusage. NIST AI RMF.

Die folgende Tabelle listet die fünf Läufe dieses synthetischen Abnahmelaufs auf, jeweils mit Eingang oder Änderung und dem erwarteten Ergebnis.

Diese fünf Fälle prüfen unterschiedliche Eigenschaften und sollten nicht in einem einzigen allgemeinen Demoergebnis verschwinden.

Dokumentieren Sie Beobachtung, Abweichung und Entscheidung je Fall. Wenn eine Abweichung akzeptiert wird, muss ihre Auswirkung verständlich sein. Ein offener Punkt wird entweder behoben, bewusst aus dem Umfang genommen oder als nachvollziehbare Einschränkung übernommen; er wird nicht durch einen pauschalen Gesamtstatus verdeckt.

Bewahren Sie genügend Nachweise für einen späteren erneuten Test auf. Ein Screenshot allein zeigt womöglich nicht, welche Eingabe oder Konfiguration das Ergebnis hervorgebracht hat. Speichern Sie den freigegebenen Testfall, die relevanten Einstellungen und den beobachteten Zustand im Zielsystem nach den im Projekt vereinbarten Zugriffs- und Aufbewahrungsregeln.

Betrieb. Benennen Sie, wer nach dem Start Warnungen bearbeitet, Zugänge erneuert, Änderungen prüft und offene Vorgänge nachholt. Unterscheiden Sie die Verfügbarkeit der Plattform von der erfolgreichen Bearbeitung eines Geschäftsfalls. Ein erreichbarer Server beweist nicht, dass jede Anfrage im CRM angekommen ist.

Übergabe. Die Übergabe sollte Konfiguration, Feldregeln, bekannte Grenzen, Testfälle und Zuständigkeiten enthalten. Vereinbaren Sie einen kurzen Wiederanlaufablauf und einen manuellen Ersatzweg. Eine zweite Person sollte einen typischen Fehler mithilfe dieser Unterlagen nachvollziehen können.

Änderungen. Für spätere Änderungen brauchen Sie einen geregelten Weg: Beschreibung, Aufwandsschätzung, Auswirkungsprüfung und Freigabe. Neue Datenfelder oder ein zusätzliches Postfach können den ursprünglichen Umfang verändern. Halten Sie die jeweils vereinbarte Version des Auftrags fest.

Bitten Sie jeden Anbieter um dieselbe Gliederung:

• Verständnis des Prozesses
• bestätigter Umfang
• offene Annahmen
• technische Lösung
• interne Mitwirkung
• Abnahme
• Betrieb
• Übergabe
• Kosten

Einmalige, laufende und verbrauchsabhängige Positionen stehen getrennt.

Lassen Sie erklären, welche Arbeit bei Ihnen bleibt. Ein scheinbar vollständiges Angebot kann umfangreiche Datenvorbereitung oder tägliche Ausnahmebearbeitung voraussetzen. Diese Aufgaben gehören in den Vergleich, auch wenn sie nicht auf der Rechnung des Dienstleisters erscheinen.

Bewerten Sie anschließend zuerst die Muss-Kriterien und dann Qualität der Umsetzung, Betrieb und Kosten. Eine gute Präsentation kann eine fehlende Kernfunktion nicht ersetzen. Umgekehrt sollte ein Anbieter offen über Grenzen sprechen können, ohne allein dafür schlechter bewertet zu werden als ein pauschales Versprechen.

Als nächsten Schritt brauchen Sie keinen langen Katalog. Schreiben Sie einen konkreten Vorgang auf, sammeln Sie repräsentative Fälle und benennen Sie die Person, die das fachliche Ergebnis abnimmt. Daraus lässt sich eine Projektbeschreibung entwickeln, mit der Angebote vergleichbar werden und die spätere Entscheidung nachvollziehbar bleibt.

Regeln Sie schließlich, wie nicht erreichte Abnahmekriterien behandelt werden. Welche Korrekturschleife ist vorgesehen, welche erneuten Fälle werden geprüft und wer entscheidet über einen kleineren Umfang? Eine technische Demonstration sollte nicht allein deshalb als erfolgreich gelten, weil der vereinbarte Termin erreicht ist. Halten Sie die verbleibenden Einschränkungen so fest, dass das spätere Betriebsteam sie tatsächlich nutzen kann.

Die folgenden Seiten und Beiträge behandeln verwandte Entscheidungen rund um KI-Automatisierungsprojekte.

• KI-Automatisierung für KMU: Aufgaben, Auswahl und Umsetzung
• KI-Automatisierungskosten und Wirtschaftlichkeit
• Agentur, Einstellung oder Software: wie die Umsetzung organisiert wird
• Entwurf und Freigabe: Menschen wirksam im Prozess behalten

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.