Proof of Concept richtig aufsetzen: was er beweisen muss
Ein KI Proof of Concept ist kein kleiner Bau, sondern ein Test einer Hypothese. Er beantwortet eine Frage, die vor dem Start scharf formuliert sein muss: geht das, was wir vermuten, an unseren echten Daten und in unserem echten Ablauf. Der wichtigste Hebel ist das Paar aus Erfolgskriterium und Abbruchgrenze, beide vor dem ersten Handgriff festgelegt. Das Erfolgskriterium sagt, wann die Annahme belegt ist. Die Abbruchgrenze sagt, wann man aufhört, statt gutes Geld schlechtem hinterherzuwerfen. Getestet wird an echten Fällen, nicht an Spielzeugdaten, sonst beweist der PoC nur, dass etwas im Labor läuft. Am Ende steht kein weiteres Meeting, sondern ein Ja oder Nein.
Was ein Proof of Concept beweisen muss
Ein Proof of Concept ist kein verkleinertes Produkt. Er ist ein Test, und ein Test hat eine Frage. Bevor irgendjemand etwas baut, muss diese Frage auf einem Satz stehen: Wir glauben, dass KI aus unseren Lieferantenrechnungen den Rechnungsbetrag zuverlässig genug ausliest, um die manuelle Kontrolle zu ersetzen. Das ist eine Annahme, die stimmen oder fallen kann. Genau darum geht es.
Der häufigste Fehler ist, den PoC ohne diese eine Frage zu starten. Dann baut ein Team etwas, das grundsätzlich funktioniert, und am Ende weiß niemand, ob das ein Ja war. Ein PoC, der alles ein bisschen zeigt, beweist nichts. Ein PoC, der eine Annahme hart prüft, liefert eine Entscheidung.
Deshalb ist der erste Schritt nicht technisch. Er ist eine Formulierung: Welche eine Sache muss wahr sein, damit sich der weitere Weg lohnt. Wer diese Frage nicht in einem Satz sagen kann, hat noch keinen PoC, sondern eine Absichtserklärung.
Erfolgskriterium und Abbruchgrenze
Sobald die Annahme steht, braucht sie zwei Zahlen oder zwei klare Aussagen, die vor dem Bau festgelegt werden. Die erste ist das Erfolgskriterium: der Punkt, an dem die Annahme als belegt gilt. Die zweite ist die Abbruchgrenze: der Punkt, an dem man aufhört, weil sich der Fall in dieser Form nicht trägt.
Die Abbruchgrenze ist der Teil, den fast alle vergessen. Ohne sie läuft ein PoC weiter, solange noch Budget da ist, weil sich immer noch eine Stellschraube findet. Mit ihr wird aus einem offenen Experiment ein Test mit Ende. Ein PoC, den man nicht scheitern lassen kann, ist kein Test.
Ein Proof of Concept ohne Abbruchgrenze ist kein Test, sondern ein Projekt, das nie Nein sagen darf.
Beide Grenzen gehören an die reale Aufgabe, nicht an ein Bauchgefühl. Wenn heute eine Person achtzig Rechnungen am Tag prüft und dabei kaum Fehler macht, dann ist die Frage nicht, ob die KI perfekt ist, sondern ob sie gut genug ist, um diese Arbeit sinnvoll zu verändern. Das Erfolgskriterium hängt an der Baseline, dem gemessenen Ist-Zustand. Ohne Baseline schwebt jede Zahl in der Luft.
Echte Bedingungen statt Labor
Ein PoC beweist nur dann etwas, wenn er unter echten Bedingungen läuft. Echte Daten, echte Ausnahmen, der echte Ablauf drumherum. Wird ein PoC an sauber ausgewählten Beispielen getestet, beweist er, dass das Werkzeug im Labor funktioniert, und das war selten die Frage. Die Frage war, ob es mit euren tatsächlichen, unordentlichen Fällen klarkommt.
Genau hier trennt sich ein belastbarer PoC von einer hübschen Demo. Die Demo zeigt den Normalfall, glänzend und schnell. Der belastbare PoC sucht gezielt die schwierigen, seltenen und unangenehmen Fälle, weil dort die Wahrheit liegt. Was am schweren Fall scheitert, solange es billig ist, kostet später im Betrieb ein Vielfaches.
| Vager Wunsch | Testbares Erfolgskriterium | Abbruchgrenze |
|---|---|---|
| Die KI soll Rechnungen auslesen | Betrag bei 95 von 100 echten Rechnungen korrekt | unter 80 von 100, dann Stopp |
| Der Assistent soll Anfragen beantworten | die zehn häufigsten Fragen korrekt mit Quelle | keine belastbare Quelle möglich |
| Die Klassifizierung soll Zeit sparen | schneller als die Baseline bei gleicher Trefferquote | langsamer oder ungenauer als heute |
| Die Extraktion soll sauber genug sein | Ausnahmen sauber als unsicher markiert | Fehler still, ohne Warnung |
Die rechte Spalte ist die wichtigste. Sie zwingt dazu, das Scheitern vorher zu benennen, und macht damit aus einem Wunsch einen Test.
Die Aufsetz-Checkliste
Bevor du einen PoC startest, beantworte diese fünf Punkte. Bleibst du bei einem hängen, hast du den Grund gefunden, warum der Test später keine Entscheidung liefern würde.
- Die eine Annahme: steht sie auf einem Satz, prüfbar und nicht schwammig?
- Die Baseline: wie sieht der heutige Ablauf gemessen aus, in Zeit, Menge und Qualität?
- Das Erfolgskriterium: ab wann gilt die Annahme als belegt, in Zahlen an der Baseline?
- Die Abbruchgrenze: ab wann hörst du auf, statt weiter zu justieren?
- Die echten Fälle: liegen genug reale, auch schwierige Beispiele vor, freigegeben und nutzbar?
Kernsatz: Ein PoC ist zum kleinen Teil ein Bauprojekt und zum großen Teil eine Frage der Formulierung. Was du vorher als Kriterium festlegst, wird am Ende zu einer Entscheidung. Was du offen lässt, wird zu einem weiteren Meeting.
Häufige Irrtümer
- Ein PoC ist eine kleine Version des fertigen Produkts.
- Nein. Ein PoC ist ein Test einer Annahme, keine Vorstufe im Maßstab 1 zu 4. Er darf hässlich sein und vieles weglassen, solange er die eine Frage sauber prüft.
- Wenn der PoC läuft, kann er in den Betrieb.
- Selten. Ein PoC beweist, dass die Annahme trägt. Zwischen ihm und dem Betrieb liegen Rechte, Monitoring, Fehlerpfad und eine benannte Verantwortung. Der PoC entscheidet, ob dieser Weg sich lohnt, er ersetzt ihn nicht.
Fragen und Antworten
- Wie unterscheidet sich ein PoC von einem Pilot?
- Ein PoC prüft eine Annahme, oft außerhalb des laufenden Betriebs, an einem klar abgegrenzten Fall. Ein Pilot setzt eine Lösung bereits im echten Betrieb ein, zeitlich und im Umfang begrenzt, um zu sehen, ob sie im Alltag trägt. Der PoC kommt zuerst, der Pilot baut auf einem bestandenen PoC auf.
- Was, wenn wir das Erfolgskriterium vorher nicht kennen?
- Dann ist das die eigentliche erste Aufgabe. Meist steckt hinter einem fehlenden Kriterium eine fehlende Baseline: Ihr wisst noch nicht genau, wie gut der heutige Ablauf ist. Das lässt sich messen, und aus der Messung wird das Kriterium. Ohne diesen Schritt bleibt jeder PoC beliebig.
- Ist ein gescheiterter PoC verlorenes Geld?
- Nein, wenn er billig war und früh entschieden hat. Ein PoC, der nach zwei Wochen ein klares Nein liefert, hat euch vor einem Projekt bewahrt, das nach Monaten an derselben Stelle gescheitert wäre. Genau dafür ist die Abbruchgrenze da.
Sources and evidence
Es werden keine externen Statistiken oder Kundenergebnisse als belegt behauptet. Die Beispielzahlen in den Tabellen sind zur Veranschaulichung gewählt und ersetzen keine fallbezogene Festlegung.