Wie formulierst du Ausschreibungen für KI-Projekte mit prüfbaren Ergebnissen?

Ausschreibungen für KI-Projekte werden prüfbar, wenn ihr vor der Angebotseinholung festlegt, welche Eingaben zu welchen Ergebnissen führen müssen und welche Aktionen ausgeschlossen sind. Ein gemeinsames Testpaket samt Abnahmekriterien macht Angebote vergleichbar. „Ein KI-Assistent für unseren Kundenservice“ beschreibt dagegen noch keinen abgrenzbaren Auftrag.

Für Unternehmen mit 10 bis 250 Mitarbeitern reicht als Ausgangspunkt oft ein einzelner Ablauf, etwa die Vorbereitung von Antworten auf Statusanfragen. Wie solche Abläufe technisch verbunden werden können, erläutert unsere Seite KI-Automatisierung. Hier geht es darum, die Anforderungen dafür vor einer Beauftragung aufzuschreiben. Der Beitrag behandelt die private Angebotseinholung, keine Anleitung für ein öffentliches Vergabeverfahren.

Beschreibt den Weg vom Eingang bis zur Freigabe

Beginnt mit einem Vorgang, den eine fachlich zuständige Person heute vollständig bearbeiten kann. Haltet fest, wo er ankommt, welche Informationen jemand nachschlägt und woran das Team erkennt, dass er erledigt ist. Ungeklärte Zuständigkeiten werden durch ein Sprachmodell nicht eindeutig.

Eine brauchbare Leistungsbeschreibung benennt auch die Grenze des Auftrags: Darf das System lediglich einen Entwurf anlegen oder zusätzlich einen Datensatz ändern? Welche Datenquelle ist bei widersprüchlichen Angaben maßgeblich? Wer übernimmt einen Vorgang, wenn diese Quelle nicht erreichbar ist?

Gebt allen Anbietern dieselbe Beschreibung und denselben Stand der Unterlagen. Beantwortet fachliche Rückfragen in einer gemeinsamen Ergänzung. Sonst bewertet ihr später unterschiedliche Annahmen, obwohl die Angebote ähnlich heißen.

Fiktive Übung für eine ausschreibungsfähige Aufgabenbeschreibung

Fiktive Übung, kein Kundenprojekt und kein durchgeführter Produkttest. Ein Unternehmen mit angenommenen 60 Mitarbeitern möchte Lieferstatusanfragen vorbereiten lassen. Die folgenden Angaben sind eine ausfüllbare Vorlage; Systemnamen, Datenfelder und Grenzwerte müssen durch den eigenen Betriebsfall ersetzt werden.

Die wichtigste Formulierung ist hier „bestätigter Liefertermin“. Ein Wunschdatum aus einer Kundenmail und ein vom Unternehmen bestätigter Termin sind unterschiedliche Informationen. Die Ausschreibung muss diese Unterscheidung vorgeben, damit eine überzeugend formulierte Antwort nicht als richtig gewertet wird, obwohl ihre Grundlage falsch ist.

Macht aus jedem Risiko einen Abnahmetest

Stellt vor dem Anbietertermin ein freigegebenes Testpaket zusammen. Nutzt künstliche Daten oder Daten, deren Verwendung für diesen Zweck geklärt ist. Zu jedem Eingang gehört eine fachlich geprüfte Erwartung. Trennt einige Fälle für die spätere Abnahme ab, damit die Vorführung nicht nur bekannte Muster abspielt.

Für die fiktive Übung könnten die folgenden Fälle verbindliche Prüfpunkte sein. Die rechte Spalte beschreibt erwartetes Verhalten, keine gemessenen Ergebnisse:

Vereinbart zusätzlich, wie Bearbeitungszeit und Korrekturen erfasst werden. „90 Prozent richtig“ ist ohne Nenner wenig hilfreich: Zählen unbeantwortete Eingänge mit? Gilt ein Entwurf mit richtiger Anrede, aber falschem Termin als Fehler? Bewertet kritische Fehler separat und verlangt ihre Behebung samt erneuter Prüfung vor der Freigabe. Eine bestandene Stichprobe garantiert keine fehlerfreien künftigen Eingaben.

Verlangt einen technischen Kontrollpunkt

Eine Anweisung wie „Bitte immer vorher fragen“ ist noch kein Nachweis für eine wirksame Versandsperre. Lasst euch zeigen, was bei Zustimmung, Ablehnung und ausbleibender Antwort tatsächlich passiert.

Dass eine solche Sperre technisch abbildbar ist, zeigt die n8n-Dokumentation zu menschlichen Freigaben: Vor ausgewählten Werkzeugaufrufen kann ein Workflow warten; Zustimmung führt die Aktion aus, Ablehnung verhindert sie. Daraus folgt keine Empfehlung für eine bestimmte Plattform. Es ist ein konkreter Ansatzpunkt für die Anforderung, dass der Kontrollpunkt im angebotenen System vor der Aktion liegen muss.

Bestellt die Übergabe gleich mit

Schreibt als eigenes Lieferergebnis auf, was euer Team nach Projektende erhält: Ablaufbeschreibung, Konfiguration, Feldzuordnung, Testfälle, Fehlerliste und Anleitung für den manuellen Weiterbetrieb. Benennt außerdem, wer Konten verwaltet, Störungen bearbeitet und Änderungen an Datenquellen nachzieht.

n8n dokumentiert den Export und Import von Workflows als JSON-Dateien. Ein solcher Export kann Teil einer Übergabe sein. Er beweist allein aber noch keinen funktionsfähigen Betrieb an anderer Stelle. Verlangt deshalb einen Wiederanlauf mit den vorgesehenen Zugängen. Prüft Exportdateien vor der Weitergabe auf vertrauliche Angaben; auch die Herstellerdokumentation weist auf mögliche Zugangsinformationen in enthaltenen Einstellungen hin.

Lasst Einrichtung, interne Mitwirkung, Lizenzen, Verbrauch und Betreuung getrennt ausweisen. Für die spätere Angebotsprüfung ergänzt der Beitrag Was in einem guten Automatisierungsangebot stehen muss diese Leistungsbeschreibung. Weitere Fehlerfälle könnt ihr mit der Arbeitsvorlage zum Testen einer Automatisierung festhalten.

Wenn noch unklar ist, welcher Ablauf sich ausreichend eingrenzen lässt, beginnt mit einer Prozessanalyse. Das Ziel vor der Angebotseinholung ist eine Aufgabe, deren Eingang, Ergebnis und Grenzen euer Team selbst erklären und prüfen kann.