Scope-Vorlage für ein KI-MVP: Abnahmekriterien, Eval-Set, Launch-Gate und was in den SoW gehört

Den Scope für ein KI-MVP zu schreiben ist etwas anderes als bei einem normalen Software-MVP, denn das System ist probabilistisch, nicht deterministisch. "Nutzer kann Passwort zurücksetzen" ist ein Binärfall, den du als Pass-Fail-Test formulieren kannst. "Der Assistent antwortet korrekt" ist es nicht, denn dieselbe Frage kann andere Antworten liefern, sobald sich Modellversion, Temperatur oder Formulierung ändern. Du ersetzt "es funktioniert" also durch vier Dinge, die im Statement of Work benannt sein müssen, bevor Geld fließt: ein versioniertes Eval-Set mit Goldantworten, eine Zielmetrik samt Schwellenwert auf diesem Set, ein Launch-Gate, das über den Go-Live entscheidet, und die explizite Behandlung des unsicheren Falls samt Rollback. Wenn der Scope eines Anbieters "KI-Assistenten bauen" lautet und keines dieser Dinge enthält, hat er eine Demo abgegrenzt, und du zahlst die Lücke beim Härten drauf. Die kopierfertige Vorlage findest du weiter unten.

Das ist das Dokument, das Gründer intern herumschicken, bevor sie kaufen. Es ist aus der Bauperspektive geschrieben, mit den unbequemen Fragen explizit benannt. Die regulatorischen Daten sind Stand Mitte 2026 und dort abgesichert, wo sie in Bewegung sind.

Willst du diesen Scope auf Herz und Nieren prüfen lassen, bevor du bei einer Agentur unterschreibst?

Kostenloses Erstgespräch buchen

Warum "es funktioniert" bei KI nicht funktioniert

Bei normaler Software ist die Abnahme binär: Bei Eingabe X erwarte Ausgabe Y, fertig. Ein LLM gibt bei derselben Eingabe über mehrere Durchläufe hinweg unterschiedliche Ausgaben, also steht hinter "der Chatbot antwortet präzise" kein Test. Keine Zahl, kein definiertes Set, keine Untergrenze, nichts zum Abzeichnen und nichts, worüber man bei schlechter Qualität streiten könnte. Die Lösung ist statistisch, nicht binär. Du akzeptierst eine gemessene Quote auf einem definierten Set, idealerweise über mehrere Durchläufe gemittelt, und für reproduzierbare Regressionsprüfungen fixierst du die Temperatur auf null, wo der Anwendungsfall es zulässt. Die zweite Falle folgt sofort: Ein Fix für einen Fall bricht still einen anderen, also muss das Eval-Set als Gate bei jeder Prompt- oder Modelländerung laufen, nicht einmal am Ende. Genau dieser eine Schwenk, von "es funktioniert" zu "es überschreitet diese Latte auf diesem Set, jedes Mal", ist der ganze Sinn eines gut abgegrenzten KI-Builds.

Was ein Statement of Work für ein KI-MVP festlegen muss

Jeder Abschnitt verdient seinen Platz. Die tragenden sind das Eval-Set, die Abnahmekriterien und das Launch-Gate.

Abschnitt	Was er festlegen muss
Problem + ein Ergebnis	Ein Satz. Die eine Nutzeraufgabe, die das MVP erfüllen muss. Alles, was ihr nicht dient, ist out of scope.
In und out of scope	Zwei Listen. Die Out-of-Scope-Liste ist die tragende: Benenn die verlockenden Dinge, die du nicht baust (Mehrsprachigkeit, Sprache, Fine-Tuning, Mobile), damit sie zu Change Requests werden, nicht zu Annahmen.
Funktionale + KI-Verhaltensspezifikation	Normale Anforderungen plus das KI-Verhalten: Aufgabe, Tonalität, Verweigerungsverhalten (wann es "Ich weiß es nicht" sagen muss), Zitatpflicht und Fallback bei niedriger Konfidenz oder fehlendem Retrieval-Treffer. Hier kodierst du den unsicheren Fall.
Abnahmekriterien	Zielmetrik plus Schwellenwert auf einem benannten Eval-Set. Niemals "es funktioniert". Beispiele unten.
Das Eval-Set	Wie viele Fälle (rund 100 ist eine praktikable MVP-Untergrenze, ~200 für ein vollständigeres Set; zehn sagen dir fast nichts), wem die Goldantworten gehören (ein Fachexperte auf deiner Seite, nicht der Anbieter allein) und wie jeder Fall bewertet wird: deterministische Prüfungen für objektive Felder, ein LLM-as-judge mit binärem Pass-Fail für nuancierte Qualität, menschliche Prüfung zur Kalibrierung.
Launch-Gate + Rollback	Die messbare Latte für den Go-Live, vereinbart von Produkt, Engineering und QA, bevor Tests geschrieben werden, plus ein Auto-Rollback-Auslöser und ein Kill-Kriterium.
Daten	Quellen, Herkunft, Nutzungsrechte (Training und Retrieval), PII-Behandlung und Speicherort. Die Modell-API, die Prompts sieht, ist ein Sub-Prozessor: Sie braucht einen DPA und eine No-Training-, Zero-Retention-Konfiguration, keine Consumer-Bedingungen.
Nicht-funktionale Anforderungen	Latenzbudget (bei Streaming-UIs ist time-to-first-token das primäre SLA), Kosten-pro-Aktion-Budget (Output-Tokens kosten ein Mehrfaches von Input, und agentische Flows fächern eine Aktion in viele Calls auf) und Logging jedes Modell-Calls.
Sicherheit und Compliance	Auth, Berechtigungsmodell und Mandantentrennung, GDPR (Verzeichnis von Verarbeitungstätigkeiten, Rechtsgrundlage, DPIA bei hohem Risiko, Sub-Prozessor-DPAs) und EU-AI-Act-Transparenz, wo die App mit Nutzern spricht.
Meilensteine, Zahlung, IP, Übergabe	Phasen aus Discovery, Build, Eval und Härtung, Launch, mit Zahlung je Phase. IP geht mit der Zahlung an dich über. Eine benannte Liste der Übergabeartefakte.

Abnahmekriterien: falsch versus richtig

Das ist der Abschnitt, der entscheidet, ob du einen Anbieter an irgendetwas binden kannst.

Falsch, weil es keine Zahl, kein Set und keine Untergrenze gibt: "der Chatbot beantwortet Kundenfragen korrekt", "der Assistent ist präzise und hilfreich", "das Modell halluziniert selten", "es funktioniert gut im Test".

Richtig, auf dem vereinbarten 100-Fall-Eval-Set mit fixen Goldantworten:

mindestens 90% getreue Antworten, im abgerufenen Kontext verankert, bewertet von einem LLM-as-judge mit binärem Pass-Fail und gegen menschliche Labels kalibriert;
mindestens 85% Antwortrelevanz;
unter 2% schädliche oder richtlinienwidrige Ausgaben, als hartes Gate, bei dem jede einzelne schädliche Ausgabe den Launch blockiert;
Verweigerung oder Eskalation bei mindestens 95% der nicht beantwortbaren Testfälle;
p95 time-to-first-token unter 2 Sekunden, p95 vollständige Antwort unter 4 Sekunden;
Kosten unter EUR 0,05 pro Konversation beim vereinbarten Modell;
keine Regression unter eine Untergrenze im Eval-Lauf vor einem Deploy.

Behandle die exakten Schwellenwerte als Ausgangspunkte, die du gegen dein Risiko verhandelst, nicht als Evangelium. Anbieter nennen häufig Faithfulness ab 0,75 und Halluzination unter 5% (1% bei hohem Einsatz) als produktive Ausgangspunkte; leg deine danach fest, was dich eine falsche Antwort kostet. Das Eval-Set, das du hier abgrenzt, ist genau der Nachweis, den die technische Due Diligence eines Investors verlangen wird, was wir in der Checkliste zur technischen Due Diligence für KI-MVPs behandeln, und die Bewertungsmethoden stehen in wann sich LLM-Evals lohnen.

Die kopierfertige Scope-Vorlage

Einfügen, Klammern ausfüllen, Nichtzutreffendes löschen. Schick sie herum, bevor du ein einziges Angebot annimmst.

KI-MVP-Scope / SoW, [Projektname]
Datum [Datum] · Version [v0.1] · Owner [Name]

1. Problem + ein Ergebnis. Problem: [ein Satz]. Das eine Ergebnis, das dieses MVP liefern muss: [Nutzer] kann [X tun], damit [Y].

2. Scope. In scope: [Feature 1], [Feature 2]. Out of scope, nur per Change Request: [Mehrsprachigkeit], [Sprache], [Fine-Tuning], [Mobile].

3. Funktional + KI-Verhalten. Funktional: [Liste]. KI-Verhalten: Aufgabe [genau was], Tonalität [knapp, keine Spekulation], Zitate [muss oder darf nicht in Quellen verankern], Verweigerung [bei out of scope oder niedriger Konfidenz "Ich weiß es nicht" sagen oder eskalieren], Fallback [Sekundärmodell, gecachte Antwort oder menschliche Übergabe].

4. Abnahmekriterien. Auf dem vereinbarten [100]-Fall-Eval-Set: Faithfulness >= [90]%; Relevanz >= [85]%; schädliche Ausgaben < [2]% (jeder einzelne Fail blockiert den Launch); korrekte Verweigerung >= [95]% bei nicht beantwortbaren Fällen; p95 time-to-first-token < [2]s; p95 vollständige Antwort < [4]s; Kosten pro Konversation < [EUR 0.05] bei Modell [X]; keine Regression unter eine Untergrenze vor dem Deploy.

5. Eval-Set. Größe [100] Fälle ([X] Happy Path, [Y] Edge, [Z] nicht beantwortbar). Owner der Goldantworten: [Fachexperte des Kunden]. Bewertung: deterministische Prüfungen für [objektive Felder], LLM-as-judge Pass-Fail für [Qualität], menschliche Prüfung zur Kalibrierung. Gespeichert und versioniert in [Ort].

6. Launch-Gate + Rollback. Go-Live, wenn alle Untergrenzen aus Abschnitt 4 erreicht sind, abgezeichnet von [Produkt] + [Engineering] + [QA]. Rollback: Wenn [Metrik] über ein [Fenster] unter [Untergrenze] fällt, automatisch zurückrollen. Kill-Kriterium: Nicht ausliefern, wenn [Faithfulness < X% oder eine schädliche Ausgabe].

7. Daten. Quellen [Liste], Herkunft und Rechte [je Quelle], PII [was und wie behandelt], Speicherort [EU-Region]. Modellanbieter: DPA unterzeichnet, No-Training, Zero-Retention.

8. Nicht-funktionale Anforderungen. Latenz- und Kostenbudgets wie in Abschnitt 4. Observability: jeden Modell-Call loggen (Prompt, Antwort, Tokens, Kosten) in [Tool], tägliche Kostenwarnung bei [Schwellenwert].

9. Sicherheit + Compliance. Auth [Methode], Berechtigungen und Mandantentrennung [Modell], GDPR (Verzeichnis von Verarbeitungstätigkeiten, Rechtsgrundlage, DPIA bei hohem Risiko, Sub-Prozessor-DPAs), EU-AI-Act-Artikel-50-Transparenz ab dem 2. August 2026, wenn die App mit Nutzern spricht, ohne einen Plan, der eine nicht in Kraft getretene Verzögerung voraussetzt.

10. Meilensteine + Zahlung. Discovery, Build, Eval und Härtung, Launch, Zahlung je Phase. IP wird mit Zahlung an [Kunde] übertragen. Übergabe: Eval-Set und Ergebnisse, Prompt- und Modellregister, Architektur- und Datenflussdiagramm, Runbook, Zugriff auf Logs, Credentials. Abzeichnung: Kunde [__] Anbieter [__] Datum [__].

"Wenn der Scope dir nicht in Zahlen sagen kann, wie gut genug aussieht und was passiert, wenn das Modell falsch liegt, dann ist es kein Scope. Es ist ein Wunsch. Das Eval-Set und das Launch-Gate sind die zwei Zeilen, die aus einer KI-Demo etwas machen, das du tatsächlich kaufen kannst."

Eine Anmerkung zum AI Act

Wenn deine App mit Nutzern interagiert, gelten die Transparenzpflichten aus Artikel 50 des EU AI Act, einschließlich der Information der Nutzer, dass sie es mit KI zu tun haben, ab dem 2. August 2026 und sind von den vorgeschlagenen Änderungen weitgehend unberührt. Die meisten Hochrisiko-Pflichten waren ebenfalls dann fällig. Eine vorläufige Einigung 2026 würde die eigenständigen Hochrisiko-Pflichten auf Ende 2027 verschieben, aber Stand Mitte 2026 ist das noch nicht Gesetz und tritt erst mit der förmlichen Annahme in Kraft. Grenz deinen Compliance-Plan nicht um eine Verzögerung herum ab, die nicht in Kraft getreten ist.

Häufig gestellte Fragen

Wie schreibt man Abnahmekriterien für ein KI-Feature?

Nicht als "es funktioniert." Du definierst eine Zielmetrik und einen Schwellenwert auf einem benannten Eval-Set, zum Beispiel mindestens 90% getreue Antworten auf einem 100-Fall-Set, unter 2% schädliche Ausgaben, p95-Latenz unter 4 Sekunden und Kosten unter EUR 0,05 pro Konversation. Da das System probabilistisch ist, akzeptierst du eine gemessene Quote über mehrere Durchläufe, kein einzelnes Pass-Fail.

Was ist ein Eval-Set?

Ein versioniertes, eigenes Set repräsentativer Eingabefälle mit vereinbarten Goldantworten, das dazu dient, Qualität objektiv zu messen und Regressionen bei jeder Prompt- oder Modelländerung abzufangen. Rund 100 Fälle sind eine praktikable MVP-Untergrenze, etwa 200 für ein vollständigeres Set. Zehn Fälle sagen dir fast nichts.

Wem sollte das Eval-Set gehören?

Einem Fachexperten auf deiner Seite, nicht dem Anbieter allein. Die Person, die weiß, wie eine korrekte Antwort aussieht, muss die Goldantworten definieren, sonst lässt du den Erbauer seine eigenen Hausaufgaben benoten.

Wie werden Eval-Fälle bewertet?

Auf drei Arten, oft kombiniert: deterministische Code-Prüfungen für objektive Felder wie Daten, IDs und JSON-Form; ein LLM-as-judge für nuancierte Qualität, mit binärem Pass-Fail statt einer 1-bis-5-Skala; und menschliche Prüfung, um den Judge aufzubauen und zu kalibrieren.

Was ist ein Launch-Gate für eine LLM-App?

Die messbare Latte, die über den Go-Live entscheidet: die Schwellenwerte, die das System auf dem Eval-Set erreichen muss, vereinbart von Produkt, Engineering und QA, bevor ein einziger Test geschrieben wird. Unterhalb der Latte lieferst du nicht aus. Es definiert auch einen Rollback-Auslöser und ein Kill-Kriterium.

Was gehört in ein Statement of Work für KI?

Problem und ein Ergebnis, in und out of scope, funktionale Anforderungen plus eine KI-Verhaltensspezifikation (Tonalität, Verweigerung, Zitate, Fallback), Abnahmekriterien als Metrik plus Schwellenwert auf einem Eval-Set, das Eval-Set selbst, das Launch-Gate und Rollback, Datenrechte sowie PII und Speicherort, nicht-funktionale Anforderungen (Latenz, Kosten pro Aktion, Logging), Sicherheit und Compliance sowie Meilensteine, Zahlung, IP und Übergabeartefakte.

Warum kann ich nicht einfach "die KI antwortet korrekt" in den Scope schreiben?

Weil das Modell nicht-deterministisch ist. Dieselbe Frage kann unterschiedliche Antworten erzeugen, also steht hinter "korrekt" kein Test. Du brauchst ein definiertes Set, eine Metrik und eine Untergrenze, sonst gibt es nichts zum Abzeichnen und nichts, worüber man bei schlechter Qualität streiten kann.

Wie behandle ich den Fall, dass die KI falsch liegt oder unsicher ist?

Leg ihn im Scope fest: einen Verweigerungs- oder "Ich weiß es nicht"-Pfad, Eskalation an einen Menschen oder einen Fallback. Dann testest du ihn, indem du nicht beantwortbare Fälle ins Eval-Set aufnimmst und vom System verlangst, bei sagen wir mindestens 95% davon zu verweigern oder zu eskalieren.

Welche Datenklauseln braucht ein KI-MVP-SoW?

Herkunft und Nutzungsrechte für Trainings- und Retrieval-Daten, PII-Behandlung, EU-Datenspeicherort, wo relevant, und einen DPA mit dem Modellanbieter, konfiguriert auf No-Training und Zero-Retention. Die Modell-API, die Nutzer-Prompts sieht, ist ein Sub-Prozessor.

Betrifft der EU AI Act meinen KI-MVP-Scope?

Wenn deine App mit Nutzern interagiert, gelten die Transparenzpflichten aus Artikel 50 ab dem 2. August 2026. Die meisten Hochrisiko-Pflichten waren ebenfalls dann fällig; eine vorgeschlagene Verzögerung würde eigenständige Hochrisiko-Pflichten auf Ende 2027 verschieben, aber das ist noch nicht Gesetz, also grenz nicht darum herum ab.

Fazit

Ein KI-MVP-Scope ist nur so gut wie sein Eval-Set und sein Launch-Gate. Diese zwei Zeilen machen aus einem vagen "baut uns einen Assistenten" etwas, an das ein Anbieter gebunden werden kann und das ein Investor später respektieren wird.

Bevor du also ein Angebot annimmst, schreib das eine Ergebnis auf, zieh die Out-of-Scope-Linie, definier die Metrik und die Untergrenze auf einem Set, das dein eigener Experte besitzt, entscheide, was passiert, wenn das Modell unsicher ist, und benenn die Latte, die es live gehen lässt. Die Vorlage oben ist der Ausgangspunkt. Füll sie zuerst aus, und die Angebote, die du zurückbekommst, drehen sich um dasselbe, was die einzige Art ist, sie zu vergleichen.

Willst du das Eval-Set und das Launch-Gate fest in deinen MVP-Scope eingebaut haben?