Der Proof of Concept lief. Seitdem steht er.
Der Bericht liegt vor, die Geschäftsführung hat ihn gesehen. Ein Jahr später ist nichts davon im Einsatz. An der Technik liegt das selten. Die Gründe, aus denen ein KI-Pilot stehen bleibt, sind wenige, und sie stecken fast immer schon im ersten Entwurf.
- PoC (Proof of Concept)
- Ein Proof of Concept, kurz PoC, prüft im Kleinen, ob sich eine Idee technisch umsetzen lässt. Der Produktivbetrieb verlangt anderes: echte Daten mit Ausnahmen, eine benannte Zuständigkeit, Anbindung an bestehende Systeme. In diesem Abstand bleiben KI-Piloten stehen.
Warum Piloten stehen bleiben
Während des Piloten sieht man keinen dieser Punkte. Er ist so angelegt, dass sie nicht auffallen.
Saubere Daten im Test
Für den Piloten sucht jemand die zehn besten Dokumente heraus. Im Betrieb kommen Scans aus 2014, drei Fassungen derselben Vorlage und Tabellen mit leeren Spalten. Hier sinkt die Trefferquote, und die Diskussion beginnt.
Niemand betreibt es
Wer aktualisiert den Index, wer nimmt Rückfragen an, wer merkt, dass die Qualität nachlässt? Zwischen IT und Fachbereich bleibt das offen. Das System wird nicht abgeschaltet, es wird nur nicht mehr benutzt.
Keine Freigaben eingebaut
Was passiert bei einer offensichtlich falschen Ausgabe? Wer stoppt, wo wird bestätigt? Solange das offen ist, unterschreibt niemand den Antrag für den Betrieb. Viele Piloten hängen an genau diesem Punkt, nicht an der Technik.
Kosten je Anfrage unbekannt
Der Pilot lief mit 40 Anfragen am Tag über das Konto eines Entwicklers. Was 4.000 Anfragen kosten, welches Modell das noch trägt und wer die Rechnung bekommt, hat niemand ausgerechnet.
Nutzer waren nicht dabei
Der Pilot wurde für den Fachbereich gebaut, nicht mit ihm. Die Leute, die das System täglich bedienen sollen, sehen es zum ersten Mal in der Abschlusspräsentation. Sie finden in fünf Minuten die drei Fälle, die nicht funktionieren.
Sicherheitsfreigabe fehlt
Der Pilot lief mit einer Testdatei auf einem Notebook. Für den Betrieb müssen Datenschutz, IT-Sicherheit und oft der Betriebsrat zustimmen. Wer damit erst nach dem Piloten anfängt, verliert Monate.
Alle sechs lassen sich vor dem Piloten festlegen. Nachträglich ist das mühsam. Vorher kostet es fast nichts.
Weitermachen, neu prüfen oder einstellen
Nicht jeder stehen gebliebene Pilot muss wieder laufen. Wir sortieren nach Wirkung im Alltag und nach Umsetzungssicherheit.
Direkt in den Betrieb
Es fehlen nur Anbindung und Zuständigkeit. Das läuft in einigen Wochen. Hier fangen wir an.
Prüfung wiederholen
Erst mit Ausnahmedaten testen und sehen, wo die Qualität einbricht. Danach wird entworfen, nicht vorher.
Später
Dass es geht, ist klar. Es gibt keinen Grund zur Eile, also rückt es nach hinten.
Einstellen
Was hier landet, wird beendet. Auch das gehört zu unserer Arbeit.
Pilot gegen Betrieb
Dieselbe Idee, zwei verschiedene Anforderungen. Die rechte Spalte ist das, was ein Proof of Concept in der Regel nicht liefert.
| Kriterium | Im Piloten | Im Betrieb |
|---|---|---|
| Daten | Zehn ausgewählte Dokumente | Alles, was im Dateiserver liegt, samt Ausnahmen |
| Erfolgskriterium | „Es funktioniert“ | Stunden, die messbar wegfallen |
| Anbindung | Daten per Hand eingespielt | Schnittstellen zu ERP, Dokumentenablage, Postfach |
| Zuständigkeit | Der Entwickler des Piloten | Eine benannte Person im Fachbereich |
| Fehlerfall | Wird weggeklickt | Stoppregel und Freigabe, dokumentiert und eingebaut |
| Kosten | Testkonto | Kosten je Anfrage bekannt, Budget freigegeben |
| Freigaben | Keine | Datenschutz, IT-Sicherheit, bei Bedarf Betriebsrat |
Sieben Schritte, an jedem Ende ein Ausstieg
Am Ende jedes Schritts entscheiden Sie, ob es weitergeht. Wer aufhört, bekommt die Ergebnisse bis dahin ausgehändigt.
Die Schritte sind getrennt, damit Sie aussteigen können. Wer alles auf einmal beauftragt, spricht Unstimmigkeiten unterwegs ungern an.
Anfrage
Wo hängt es gerade? Unterlagen des alten Piloten sehen wir uns an, auch wenn eine andere Firma ihn gebaut hat.
Beratung
Einordnung nach Wirkung und Sicherheit. Reihenfolge festlegen, Kandidaten fürs Einstellen benennen.
Konzept
Erfolgskriterium in Zahlen, Stoppregel und Betreiber stehen hier schriftlich fest, dazu der Festpreis.
Entwicklung
Gebaut wird mit echten Daten samt Ausnahmen. Die Anbindung an Ihre Systeme kommt zuerst, nicht zuletzt.
Review
Der Fachbereich benutzt das System und sammelt, was nicht passt. Wir arbeiten die Liste ab.
Abnahme
Geprüft wird gegen das Kriterium aus Schritt 3. Es wird nachträglich nicht verschoben.
Betrieb
Handbuch, Überwachung, Übergabe an Ihre benannte Person. Auf Wunsch bleiben wir im Wartungsvertrag.
Was schon im Piloten festgelegt gehört
Sechs Entscheidungen, die im Proof of Concept selten getroffen werden. Genau sie fehlen später beim Antrag für den Betrieb.
Wer sie am Anfang trifft, zahlt dafür fast nichts. Wer sie am Ende nachholt, zahlt mit Monaten.
Drei veröffentlichte Projekte, alle im Betrieb
Wir zeigen keine Piloten als Referenz. Auf der Seite stehen nur Systeme, die übergeben sind und beim Kunden laufen.
Zu jedem gibt es eine Fallstudie mit Aufbau und Zahlen.
Fünf Fragen zu Ihrem Piloten
Wenn Sie drei davon nicht aus dem Stand beantworten können, lohnt es sich, beim Konzept neu anzusetzen.
Vom Piloten in den Betrieb: häufige Fragen
Verwandte Themen
KI-Agentur München
Produktive KI-Agenten statt Pilotprojekte, mit Festpreis und Vor-Ort-Terminen.
KI-Beratung München
Potenzialanalyse und Roadmap, bevor gebaut wird. Auch mit einem Nein als Ergebnis.
EU AI Act Dokumentation
Risikoeinordnung, Systemregister und technische Beschreibung für Betreiber.
Zeigen Sie uns den Piloten, so wie er ist.
In dreißig Minuten sagen wir Ihnen, ob es sich lohnt, ihn weiterzuführen. Wenn nicht, sagen wir auch das.