KI-Proof-of-Concept: In vier bis acht Wochen klären, ob KI Ihre Aufgabe löst
Kurz gesagt
Ein KI-Proof-of-Concept prüft in vier bis acht Wochen mit echten Daten, ob eine KI eine klar umrissene Aufgabe gut genug löst. Vorher werden Umfang, Messgrößen und Zielwerte schriftlich festgelegt, etwa eine Erkennungsrate oder die eingesparte Bearbeitungszeit pro Vorgang. Am Ende steht eine begründete Entscheidung: ausbauen, anpassen oder stoppen. Viele PoCs scheitern nicht an der Technik, sondern an fehlenden Zielen, schlechten Daten und fehlender Planung für den Betrieb.

Was ein KI-Proof-of-Concept ist und was nicht
Ein Proof of Concept (PoC) beantwortet eine einzige Frage: Funktioniert dieser Ansatz mit unseren Daten gut genug für unseren Zweck? Er ist bewusst klein, zeitlich begrenzt und auf eine messbare Entscheidung ausgerichtet. Er ist keine Vorführung mit ausgewählten Beispielen und kein halbfertiges Produkt, das nach dem Test einfach weiterläuft.
| Stufe | Frage | Daten | Ergebnis |
|---|---|---|---|
| Demo | Was kann die Technik grundsätzlich? | Beispieldaten | Eindruck, keine Aussage über Ihren Fall |
| Proof of Concept | Löst KI unsere Aufgabe gut genug? | echte Daten, oft aus der Vergangenheit | Messwerte und Entscheidung |
| Pilot | Funktioniert es im Alltag mit echten Nutzern? | laufende Daten in einem begrenzten Bereich | Erfahrung im Betrieb, Akzeptanz, Aufwand |
| Produktivbetrieb | Läuft es zuverlässig in der Fläche? | alle relevanten Daten, angebunden | Nutzen im Tagesgeschäft |
Die Stufen zu trennen, schützt vor falschen Erwartungen. Wer aus einem PoC direkt einen Produktivbetrieb erwartet, wird enttäuscht. Wer nach einer Demo ohne PoC investiert, geht ein Risiko ein, das sich mit wenigen Wochen Arbeit hätte klären lassen.
Den richtigen Umfang für einen KI-PoC wählen
Der häufigste Fehler ist ein zu großer PoC. Ein guter Umfang erfüllt diese Bedingungen:
- Es geht um einen Prozess und eine Aufgabe, etwa die Prüfung einer Bauteilfamilie, die Einordnung eingehender E-Mails einer Abteilung oder Antworten auf Fragen zu einem bestimmten Handbuchbestand.
- Die Aufgabe kommt häufig vor, bindet Fachkräfte oder verursacht Fehler, deren Folgen alle kennen.
- Die nötigen Daten existieren und sind zugänglich oder lassen sich in wenigen Wochen erfassen.
- Es gibt Menschen, die die Aufgabe heute erledigen, Ergebnisse bewerten können und Zeit dafür bekommen.
- Funktioniert der Ansatz, lässt er sich auf weitere Produkte, Standorte oder Abteilungen übertragen.
Halten Sie ebenso fest, was ausdrücklich nicht dazugehört: die vollständige Anbindung an alle Systeme, eine ausgefeilte Oberfläche oder ein Rechte- und Rollenkonzept für das ganze Unternehmen. Das kommt später, wenn feststeht, dass sich der Ausbau lohnt.
Erfolgskriterien vor dem Start festlegen
Ohne Zielwert lässt sich nicht entscheiden, ob ein PoC erfolgreich war. Legen Sie vor dem Start schriftlich fest:
- Fachliche Messgröße: Was genau wird gemessen? Beispiele sind der Anteil erkannter Fehler, der Anteil richtiger Antworten mit Quelle, die Abweichung einer Prognose oder der Anteil vollständig automatisch bearbeiteter Vorgänge.
- Zielwert und Mindestwert: Ab welchem Wert lohnt sich der Ausbau, unter welchem Wert wird gestoppt?
- Vergleichswert: Wie gut ist der heutige Prozess? Eine KI muss nicht perfekt sein, sondern besser oder schneller als der Ist-Zustand, oder Fachkräfte spürbar entlasten.
- Gewicht der Fehler: Ist ein übersehener Fehler schlimmer als ein Fehlalarm? Davon hängt ab, wie Schwellen eingestellt werden.
- Testmenge: Mit welchen Daten wird gemessen? Am besten mit Fällen, die das Modell vorher nicht gesehen hat, ausgewählt von den Fachleuten.
- Weitere Anforderungen: Antwortzeit, Betrieb lokal oder in der EU, Datenschutz und Nachvollziehbarkeit.
Ein Beispiel mit typischen Werten: Für eine Sichtprüfung könnte das Ziel lauten, mindestens 98 % der fehlerhaften Teile zu erkennen und höchstens 2 % der guten Teile fälschlich auszusortieren, gemessen an 500 Teilen, darunter rund 100 fehlerhafte, die zwei Prüfer unabhängig bewertet haben. Wie solche Prüfungen technisch aufgebaut sind, beschreibt der Ratgeber KI in der Qualitätskontrolle. Für einen Wissensassistenten könnte gelten: 80 von 100 Testfragen werden korrekt und mit richtiger Quelle beantwortet, und wenn die Information fehlt, sagt der Assistent das, statt zu raten.
Der Zeitplan: vier bis acht Wochen
| Phase | Dauer | Inhalt | Ergebnis |
|---|---|---|---|
| Vorbereitung | 3 bis 5 Tage | Zielbild, Messgrößen, Datenzugang, Ansprechpersonen | abgestimmter PoC-Steckbrief |
| Datenprüfung | 1 bis 2 Wochen | Daten sichten und bereinigen, Testmenge festlegen, wo nötig beschriften | belastbare Datengrundlage oder frühes Stopp-Signal |
| Umsetzung | 2 bis 4 Wochen | Modell oder Ablauf bauen, mehrere Ansätze vergleichen, Schwellen abstimmen | funktionierender Prototyp |
| Bewertung | 3 bis 5 Tage | Messung an der Testmenge, Durchsicht mit dem Fachbereich, Einschätzung des Ausbaus | Ergebnisbericht und Entscheidungsvorlage |
Zusammen ergibt das vier bis acht Wochen, abhängig von Datenlage und Abstimmungswegen. Länger sollte ein PoC nicht laufen. Zieht er sich, ist das meist ein Zeichen für einen zu großen Umfang oder fehlende Daten. Ausnahmen sind Fälle, in denen Daten erst erfasst werden müssen, etwa Sensordaten aus dem Normalbetrieb einer Maschine. Dann verlängert sich vor allem die Datenphase.
Auf Ihrer Seite braucht es ein kleines Team:
- eine fachliche Ansprechperson, die die Aufgabe kennt, Beispiele liefert, Zwischenergebnisse bewertet und dafür einige Stunden pro Woche einplant,
- eine Ansprechperson in der IT, die den Zugang zu Daten und Systemen öffnet und auf Sicherheitsvorgaben achtet,
- den Datenschutz, sobald personenbezogene Daten im Spiel sind, und zwar von Beginn an,
- eine Person aus der Leitung, die die Zielwerte mit festlegt und am Ende über den Ausbau entscheidet.
Warum viele PoCs nie produktiv werden
Gartner erwartete 2024, dass mindestens 30 % der Projekte mit generativer KI bis Ende 2025 nach dem Proof of Concept aufgegeben werden, und nannte als Gründe schlechte Datenqualität, unzureichende Risikokontrollen, ausufernden Aufwand und unklaren geschäftlichen Nutzen. Unsere Beobachtung aus Projekten deckt sich damit. Die häufigsten Ursachen:
- Es gab kein messbares Ziel. Am Ende sind alle beeindruckt, aber niemand kann sagen, ob es reicht.
- Der PoC lief mit sauberen Vorzeigedaten, die Wirklichkeit ist unordentlicher.
- Die IT hat gebaut, aber im Fachbereich fühlt sich niemand zuständig oder will das Ergebnis nutzen.
- Der Betrieb wurde nicht mitgedacht. Wer betreibt das System, wer überwacht die Qualität, wer trainiert nach? Ohne Antwort bleibt der Prototyp liegen.
- Datenschutz und Betriebsrat kamen zu spät dazu. Ihre Bedenken tauchen auf, wenn der Ausbau beschlossen werden soll, und stoppen alles.
- Die Anbindung wurde unterschätzt. Ein Modell in einer eigenen Oberfläche erzeugt Doppelarbeit, Nutzen entsteht erst in den Systemen, in denen tatsächlich gearbeitet wird.
- Es sollte zu viel auf einmal getestet werden. Mehrere Anwendungsfälle parallel verteilen die knappe Zeit der Fachleute und liefern am Ende überall nur halbe Antworten.
Vom PoC in den Betrieb
Ist der PoC erfolgreich, folgen meist ein Pilot in einem begrenzten Bereich und danach der Ausbau. Dabei verschiebt sich der Schwerpunkt von der Frage „Funktioniert es?“ zu „Läuft es zuverlässig, sicher und wartbar?“.
- Anbindung: Daten kommen automatisch aus den Quellsystemen, Ergebnisse fließen zurück ins ERP, ins Ticketsystem oder an die Linie.
- Betrieb: Überwachung von Verfügbarkeit und Antwortzeiten, Updates, Sicherung, klare Zuständigkeiten und Reaktionszeiten nach vereinbartem SLA.
- Qualität im Zeitverlauf: Daten ändern sich, neue Produkte kommen hinzu. Die Trefferquote muss laufend gemessen werden, und es braucht einen Weg, das Modell nachzutrainieren.
- Sicherheit und Rechte: Anmeldung über bestehende Firmenkonten, Rollen und Protokolle.
- Schulung: Nutzerinnen und Nutzer müssen wissen, was das System kann und wo seine Grenzen liegen.
Planen Sie diese Punkte schon in der Bewertungsphase grob ein. Eine gute Entscheidungsvorlage enthält deshalb neben den Messwerten eine Einschätzung von Aufwand, Zeitplan und Risiken für den Ausbau. Wie ein vollständiges Projekt abläuft, beschreibt der Ratgeber KI entwickeln lassen.
So arbeiten wir
Bei uns beginnt jedes Vorhaben mit einem Erstgespräch von 60 Minuten. Danach legen wir Umfang, Messgrößen und Zielwerte gemeinsam in einem kurzen Steckbrief fest, prüfen die Daten und bauen einen Prototyp mit Ihren echten Daten, in der Regel in vier bis acht Wochen. Am Ende erhalten Sie Messwerte, eine ehrliche Einschätzung und einen Vorschlag für die nächsten Schritte, auch wenn dieser lautet, dass ein anderer Weg besser passt als KI. Die einzelnen Schritte finden Sie unter Ablauf eines KI-Projekts.
Wenn Sie noch keinen konkreten Anwendungsfall haben, hilft der KI-Potenzial-Check bei der Auswahl. Wie Sie Ihre Daten vorab prüfen, steht im Ratgeber Daten für KI vorbereiten.
Häufige Fragen
Wie lange dauert ein KI-Proof-of-Concept?
In der Regel vier bis acht Wochen. Einige Tage entfallen auf Vorbereitung und Zielvereinbarung, ein bis zwei Wochen auf die Datenprüfung, zwei bis vier Wochen auf die Umsetzung und einige Tage auf die Bewertung. Länger dauert es vor allem dann, wenn Daten erst erfasst werden müssen, etwa Sensordaten aus dem laufenden Betrieb einer Maschine.
Was ist der Unterschied zwischen Proof of Concept und Pilot?
Der Proof of Concept prüft mit echten, oft historischen Daten, ob die KI die Aufgabe fachlich gut genug löst. Der Pilot prüft danach im Alltag, mit echten Nutzern und laufenden Daten in einem begrenzten Bereich, ob das System zuverlässig funktioniert, akzeptiert wird und den erwarteten Nutzen bringt. Erst danach folgt der Ausbau in die Fläche.
Welche Erfolgskriterien sind für einen KI-PoC sinnvoll?
Eine fachliche Messgröße mit Ziel- und Mindestwert, ein Vergleich mit dem heutigen Prozess und eine feste Testmenge, die das Modell vorher nicht kannte. Typische Größen sind Erkennungs- und Fehlalarmrate, der Anteil korrekter Antworten mit Quelle, die Prognosegenauigkeit oder die eingesparte Bearbeitungszeit pro Vorgang. Ergänzend zählen Antwortzeit, Datenschutz und Nachvollziehbarkeit.
Was passiert, wenn der Proof of Concept scheitert?
Dann haben Sie mit überschaubarem Aufwand eine wichtige Erkenntnis gewonnen. Ein guter Ergebnisbericht zeigt, woran es lag: zu wenige oder ungeeignete Daten, zu hohe Anforderungen oder ein Prozess, der sich anders besser lösen lässt. Oft ergibt sich daraus ein zweiter Anlauf mit angepasstem Umfang oder der Plan, gezielt Daten zu sammeln.
Wird der Prototyp aus dem PoC später weiterverwendet?
Teilweise. Erkenntnisse, Datenaufbereitung und das gewählte Modell fließen in die Umsetzung ein. Der Prototyp selbst ist aber auf schnelle Prüfung ausgelegt, nicht auf Dauerbetrieb. Für den Produktivbetrieb kommen Schnittstellen, Rechteverwaltung, Überwachung, Sicherung und Tests hinzu. Planen Sie diesen Schritt bewusst ein, statt den Prototyp einfach weiterlaufen zu lassen.


