KI-StrategieProof of ConceptKI-Einführung

Was ein vierwöchiger KI-Proof-of-Concept beweisen sollte, bevor Sie skalieren

Viele KI-Piloten überzeugen in der Demo und bleiben vor dem Betrieb stecken. Was vier Wochen Test beweisen sollten und wie Sie über den nächsten Schritt entscheiden.

Von Nichita Railean, CTOVeröffentlicht 11. Oktober 20265 Min. Lesezeit

Ein Proof of Concept, der in der Demo beeindruckt, kann trotzdem das Falsche für die Skalierung sein. Das Modell bewältigt die Beispielfälle, der Raum ist überzeugt, und ein paar Monate später ist das Projekt still eingeschlafen. Gartner berichtete im Januar 2026, dass bis Ende 2025 mindestens die Hälfte der Projekte mit generativer KI nach dem Proof of Concept aufgegeben wurde, wegen schlechter Datenqualität, unzureichender Risikokontrollen, steigender Kosten oder unklaren Geschäftsnutzens.

Keiner dieser Gründe betrifft die Frage, ob das Modell die Aufgabe lösen kann. Das ist meist der einfache Teil. Ein guter Proof of Concept ist darauf angelegt, die schwierigeren Fragen zu beantworten, solange noch wenig auf dem Spiel steht. Wenn Sie noch überlegen, welchen Prozess Sie testen, beginnen Sie mit fünf Fragen, die den richtigen ersten Prozess finden.

Eine Demo ist kein Beweis

Eine Demo zeigt, dass etwas möglich ist. Ein Beweis zeigt, dass es mit Ihren Daten, bei Ihrem Volumen und für die Menschen funktioniert, die damit arbeiten werden. Der Unterschied zählt, weil das Modell nur ein kleiner Teil eines funktionierenden Systems ist. In einem bekannten Paper über Machine Learning im Produktivbetrieb zeigten Ingenieure von Google, dass der Modellcode nur einen kleinen Bruchteil eines realen Systems ausmacht und die Infrastruktur drumherum umfangreich und komplex ist.

Ein vierwöchiger Test sollte deshalb mehr leisten als die Frage, ob das Modell die Arbeit erledigen kann. Er sollte die schmalste echte Version des gesamten Ablaufs durchspielen: echter Input, der eingeht, das Modell, das seinen Schritt erledigt, das Ergebnis, das dort landet, wo Menschen arbeiten, und eine Person, die es korrigieren kann.

Legen Sie die Messlatte vor Woche eins fest

Ein Pilot ohne vereinbarte Definition von Erfolg zieht sich oft in die Länge, weil jedes Ergebnis Auslegungssache ist. Vereinbaren Sie drei Dinge, bevor irgendetwas gebaut wird.

Ein Testset mit echten Fällen. Sammeln Sie historische Beispiele mit bekanntem richtigem Ergebnis, in der Mischung, die tatsächlich bei Ihnen ankommt, auch die schwierigen. Der Leitfaden von Anthropic zu Evaluierungen empfiehlt Testsets, die die reale Verteilung der Aufgabe abbilden und Grenzfälle enthalten.
Ein Ausgangswert. Messen Sie, wie die Arbeit heute erledigt wird: Zeit pro Vorgang, Fehlerquote, Durchlaufzeit. Googles Rules of Machine Learning stellen Kennzahlen an den Anfang und raten, im bestehenden System so viel wie möglich zu erfassen, bevor Sie festlegen, was das neue leisten soll.
Eine Schwelle für jede Kennzahl. Halten Sie fest, welches Ergebnis eine Skalierung rechtfertigt und bei welchem Sie stoppen. Formulieren Sie jede Schwelle konkret und messbar: "die richtige Kategorie bei Routineanfragen und keine selbstsicheren Fehler bei Erstattungen" statt "funktioniert gut".

Fünf Dinge, die vier Wochen beweisen sollten

Jede Zeile unten entspricht einem Grund, warum Piloten später scheitern. Nutzen Sie die Tabelle als Agenda für die Abschlussbesprechung.

Frage	Belege, die zählen	Warnsignal
Ist die Qualität mit echten Daten gut genug?	Ergebnisse auf dem vereinbarten Testset, aufgeschlüsselt nach Fallart, mit Fehlern, die von den Menschen geprüft wurden, die die Arbeit machen	Ergebnisse nur für Beispiele, die während der Entwicklung ausgewählt wurden
Scheitert es auf sichere Weise?	Unsichere Fälle werden einer Person vorgelegt, und die verbleibenden Fehler sind leicht abzufangen	Falsche Antworten, die genauso sicher wirken wie richtige
Kommt es im Betrieb an die Daten?	Es lief mit echten Exporten oder Live-Anbindungen, und Zugriff und Datenschutz sind für die nächste Phase geklärt	Testdaten, die für den Piloten von Hand bereinigt wurden
Sind die laufenden Kosten bekannt?	Kosten pro Vorgang, im Test gemessen und mit dem realen Volumen multipliziert, einschließlich Prüfzeit	Eine Schätzung auf Basis einer Handvoll Durchläufe
Werden die Menschen es nutzen?	Das Team hat es im normalen Arbeitsablauf genutzt und möchte es behalten	Feedback nur vom Auftraggeber des Projekts

Zu den Daten: Enthalten die Testfälle personenbezogene Daten, gilt die DSGVO für den Piloten genauso wie für den Betrieb. Verwenden Sie nur die Daten, die der Test braucht (der Grundsatz der Datenminimierung in Artikel 5), und klären Sie vor Woche eins, wie Sie sie verwenden dürfen.

Die Kosten verdienen eine eigene Prüfung. Gartner weist darauf hin, dass Projekte, die im Proof of Concept tragfähig wirken, im Betrieb zum Budgetproblem werden können, weil sich kleine Kosten pro Nutzung über Nutzer und Anwendungsfälle vervielfachen. Messen Sie die Kosten pro Vorgang während des Piloten, und lesen Sie die tatsächlichen Kosten eines KI-Systems, um zu sehen, was Sie sonst noch einplanen müssen.

Ein Vier-Wochen-Plan, der Raum für die Antwort lässt

Vier Wochen reichen, wenn der Umfang ein Prozess und eine Entscheidung ist. Ein Ablauf, der funktioniert:

Woche 1: vereinbaren und sammeln. Legen Sie die Messlatte fest, stellen Sie das Testset zusammen, sichern Sie den Zugang zu den echten Daten und benennen Sie die Personen, die das System ausprobieren.
Woche 2: den schmalen Pfad bauen. Verbinden Sie Input, Modell und Output durchgängig, nur für den Hauptfall. Lassen Sie am Ende der Woche das vollständige Testset laufen, auch wenn die Ergebnisse schwach sind.
Woche 3: den Nutzern vorlegen. Lassen Sie das Team es parallel zum normalen Prozess mit echter Arbeit nutzen, sodass noch nichts davon abhängt. Protokollieren Sie jede Korrektur und messen Sie die Kosten pro Vorgang.
Woche 4: verbessern, wiederholen, entscheiden. Beheben Sie die häufigsten Fehlerarten, lassen Sie das Testset erneut laufen und schreiben Sie eine einseitige Entscheidungsvorlage, die die Zahlen der Messlatte gegenüberstellt.

Genau darum geht es, wenn dasselbe Testset in Woche zwei und Woche vier läuft. So wird Fortschritt zu einer Zahl, und die Abschlussbesprechung wird keine Debatte über Eindrücke. Das AI Risk Management Framework des NIST sagt, dass KI-Systeme vor dem Einsatz und regelmäßig im Betrieb getestet werden sollten, und das Testset, das Sie jetzt aufbauen, kann zum Regressionstest für das Live-System werden.

Skalieren, anpassen oder stoppen

Am Ende von Woche vier gibt es drei ehrliche Ergebnisse.

Skalieren, wenn jede Zeile der Tabelle belegt ist, die Messlatte erreicht ist und eine benannte Person im Unternehmen das Ergebnis verantwortet. Die nächste Phase ist Engineering-Arbeit: Integration, Monitoring, Zugriffskontrolle und Support.
Anpassen, wenn eine oder zwei Zeilen schwach sind und die Lösung klar ist, etwa eine fehlende Datenquelle. Vereinbaren Sie eine kurze Verlängerung mit festem Enddatum und derselben Messlatte. Anpassen darf kein Dauerzustand werden.
Stoppen, wenn die Qualität weit von der Messlatte entfernt ist oder der Nutzen verschwindet, sobald laufende Kosten und Prüfzeit eingerechnet sind. Ein Pilot, der nach vier Wochen so endet, hat seine Aufgabe erfüllt: Er hat Ihnen ein viel größeres Projekt erspart.

In unseren Projekten gelangen vor allem die Piloten reibungslos in den Betrieb, deren Entscheidungsregeln vorher aufgeschrieben wurden. Um eine realistische Messlatte zu setzen, schätzen Sie mit dem ROI-Rechner, was der Prozess heute wert ist, oder sehen Sie sich typische Workflows nach Unternehmensbereich an, um Kandidaten zu finden, die sich zu testen lohnen.