KI-Proof-of-Concept

Eine KI-Idee klingt oft plausibel und lässt sich in einer Demo schnell zeigen. Ob sie mit den eigenen Daten, im eigenen Ablauf und zu vertretbaren Kosten funktioniert, zeigt sich erst unter realistischen Bedingungen. Ein Proof of Concept, kurz PoC, beantwortet das, bevor größere Investitionen anstehen.

Wir legen vorab fest, woran Erfolg gemessen wird, prüfen die Idee an echten Daten, vergleichen mehrere Ansätze und schätzen die Kosten für den Produktivbetrieb. Am Ende steht eine Entscheidungsvorlage. Ein PoC setzt eine konkrete Idee voraus. Wer erst herausfinden will, welche Ideen sich überhaupt lohnen, beginnt mit der KI-Beratung.

Mit einer Frage beginnen, die Ja oder Nein lautet

Am Anfang steht eine Fragestellung, die sich mit Ja oder Nein beantworten lässt, zum Beispiel: „Kann ein Modell eingehende Anfragen mit ausreichender Treffsicherheit dem richtigen Team zuordnen?“ Dazu gehören Erfolgskriterien, die messbar sind und schriftlich vor dem Start feststehen.

Gemessen wird zunächst die Qualität, je nach Aufgabe als Anteil richtiger Zuordnungen, als Anteil korrekter Antworten mit passender Quelle oder als Abweichung einer Prognose. Dazu braucht es einen Vergleichswert aus dem heutigen Ablauf, mit denselben Maßstäben gemessen, denn auch Menschen machen Fehler. Hinzu kommt die Wirkung, etwa Bearbeitungszeit je Vorgang oder Anteil automatisch erledigter Fälle, und schließlich Mindestwerte, ab denen die Lösung brauchbar ist, sowie Werte, bei denen das Vorhaben endet. Werden Kriterien erst nach dem Test festgelegt, lässt sich jedes Ergebnis passend deuten. Deshalb legen wir sie vorher mit dem Fachbereich fest.

Ein PoC läuft meist mit einem Ausschnitt der Daten, ohne Anbindung an Produktivsysteme und mit kleinem Team. Er klärt, ob die Idee grundsätzlich funktioniert. Ob die Menschen im Alltag damit arbeiten wollen, zeigt erst ein Pilot.

Daten: nicht nur die saubersten Beispiele

Die Daten bestimmen, wie aussagekräftig ein PoC ist. Wir wählen eine Stichprobe, die den Alltag abbildet, mit den schwierigen Fällen. Sie wird bereinigt: Doppelte, veraltete oder widersprüchliche Einträge fallen auf, Dokumente werden lesbar gemacht, Felder vereinheitlicht. Wo es eine richtige Antwort gibt, halten Fachleute sie fest, damit sich Ergebnisse prüfen lassen.

Testdaten bleiben strikt getrennt von den Daten, mit denen Prompts oder Modelle angepasst werden. Sonst sieht das Ergebnis besser aus, als es ist. Enthalten die Daten Personenbezug, klären wir Hosting, Auftragsverarbeitung und Anonymisierung vorab mit dem Datenschutz.

Ansätze vergleichen und messen

Für eine Aufgabe gibt es meist mehrere Wege: ein fertiges Produkt oder eine Funktion der eingesetzten Software, ein Sprachmodell mit Prompts und bei Bedarf einer Suche in Dokumenten, oder ein eigenes Modell. Das fertige Produkt ist oft der schnellste Weg, aber weniger anpassbar. Das Sprachmodell eignet sich für Texte, Dokumente und Dialoge. Ein eigenes Modell, ob klassisches Machine Learning oder angepasstes Sprachmodell, kommt bei Prognosen, speziellen Daten oder hohen Mengen infrage, braucht aber mehr Daten und Pflege.

Wir setzen die infrage kommenden Varianten schlank um. Der einfachste Ansatz ist die Vergleichsbasis, und ein aufwendigerer lohnt sich nur, wenn er messbar besser ist. Auch verschiedene Sprachmodelle prüfen wir gegeneinander, denn Ranglisten sagen wenig über die eigene Aufgabe aus.

Kern der Prüfung ist eine Sammlung von Testfällen mit erwarteten Ergebnissen, die gemeinsam mit dem Fachbereich entsteht. Sie enthält typische Fälle, Randfälle und Fälle, in denen die Lösung ausdrücklich nicht antworten oder an einen Menschen abgeben soll. Wo das Ergebnis eindeutig ist, etwa bei Kategorien oder Zahlen, wird automatisch geprüft. Bei freien Texten bewerten Fachleute Stichproben, ergänzt durch ein weiteres Modell als Prüfer. Eine Gesamtquote genügt nicht. Wir schauen, welche Fehler auftreten und wie schwer sie wiegen, denn ein falsch eingeordneter Newsletter ist anders zu bewerten als eine falsche Vertragsauskunft. Bei jeder Änderung von Modell oder Prompt laufen die Testfälle neu, damit Vergleiche fair bleiben.

Was am Ende auf dem Tisch liegt

Ein PoC mit wenigen Aufrufen sagt noch nichts über den laufenden Betrieb. Wir rechnen die gemessenen Werte deshalb auf realistische Mengen hoch. Bei den Kosten je Vorgang zählen verarbeitete Textmenge, Modellwahl und Zahl der Schritte, und Modelle, die vor der Antwort länger rechnen, verbrauchen mehr. Zum Betriebsaufwand gehören Monitoring, Pflege von Prompts und Daten, die Anpassung an neue Modellversionen und Support, dazu Schnittstellen zu Systemen, Berechtigungen, Protokollierung und Ausfallverhalten.

Daraus entsteht die Entscheidungsvorlage mit den Ergebnissen gegen die Kriterien, einer Kostenschätzung, den Risiken und einer Empfehlung. Weitermachen bedeutet einen Plan für Pilot und Betrieb. Anpassen heißt anderer Ansatz, bessere Daten oder engerer Umfang. Stoppen ist richtig, wenn die Kriterien klar verfehlt werden, und auch dann bleiben Testfälle und Erkenntnisse nutzbar.

Dass der Weg bis in den Betrieb nicht selbstverständlich ist, zeigen die Zahlen. Gartner prognostizierte 2024, dass bis Ende 2025 mindestens 30 Prozent der Projekte mit generativer KI nach dem Proof of Concept aufgegeben werden. Genannt wurden unter anderem Datenqualität, unzureichende Risikokontrolle, steigende Kosten und unklarer Nutzen. Nach einer Gartner-Umfrage unter CIOs vom Oktober 2026 legen die erfolgreicheren Unternehmen deutlich häufiger vorab fest, wann ein Pilot nicht in Produktion geht.

Aus unserer Sicht hängt vieles an drei Dingen: Kriterien, die vor dem Test feststehen, Daten, die den Alltag abbilden, und jemand im Fachbereich, der das Ergebnis verantwortet und auch einen Stopp akzeptiert. Was im Test ohne Einschränkung läuft, braucht im Betrieb außerdem Rechte und Protokolle. Das prüfen wir früh.