KI-Prototyp in drei Tagen: vom Papierprozess zum produktiven Service

Wie lange dauert es, aus einer Idee einen produktiven KI-Service zu machen? In diesem Projekt: zwei Tage Aufbau plus ein Tag Nacharbeit. Danach lief der Service produktiv in Azure, mit CI/CD, Infrastruktur als Code und Betriebskosten unter einem Cent je Durchlauf. Dieser Beitrag zeigt, was diese Geschwindigkeit möglich gemacht hat und wo die Fallen lagen. Das Projekt ist real, ein Fensterbau-Betrieb, hier anonymisiert dargestellt.

Die Ausgangslage: Abtippen als Engpass

Der Betrieb kalkuliert Angebote auf Basis von Leistungsverzeichnissen (LVs), die als PDF eingehen. Bisher hieß das: PDF öffnen, relevante Positionen suchen, Maße abtippen, Einheiten im Kopf umrechnen, alles in die Kalkulations-Excel übertragen. Zwei bis vier Stunden je LV, und jede Person überträgt anders.

Der Engpass ist dabei nicht das Rechnen. Die Kalkulation selbst beherrscht das Team. Der Engpass ist das Übertragen, und genau das lässt sich automatisieren. Diese Diagnose ist der wichtigste Schritt des ganzen Projekts, denn sie bestimmt den Zuschnitt: Der Service muss nicht kalkulieren können. Er muss Positionen zuverlässig aus einem PDF in eine feste Excel-Struktur bringen.

Warum zwei Tage reichen: der Zuschnitt

Drei Entscheidungen haben den Prototyp klein gehalten, ohne ihn zum Wegwerfartefakt zu machen.

E-Mail als einzige Schnittstelle. Kein Portal, kein Login, keine Nutzerverwaltung. Das LV geht per E-Mail an ein Fach-Postfach, die Antwort kommt als Excel an denselben Absender zurück. Damit entfällt der komplette Frontend-Aufwand, und das Team kann den Service ohne Schulung nutzen. Zugelassen sind nur Absender der Kundendomain, andere E-Mails werden abgewiesen.

Eine feste Zielstruktur. Die Antwort ist keine Freitext-Zusammenfassung, sondern eine Tabelle exakt in der Struktur der vorhandenen Kalkulations-Excel. Das LLM strukturiert die Positionen, ein Regelwerk im Code berechnet daraus die Angebotszeilen. Die Regeln stehen im Code, nicht im Prompt. Das macht die Ergebnisse reproduzierbar und prüfbar.

Markieren statt schätzen. Fehlt im LV ein Wert, den die Kalkulation braucht, schätzt der Service nichts. Die Zeile bekommt eine Warnung und ist in der Antwort gelb hinterlegt. Die fachliche Prüfung bleibt beim Menschen, aus Stunden Übertragung werden Minuten Kontrolle. Bei drei realen LVs mit 13 bis 46 Seiten lag die Prüfzeit unter fünf Minuten.

Vier Wege im Vergleich

Vor dem Aufbau standen vier Optionen im Raum. Der Vergleich lohnt sich, weil er zeigt, woran die naheliegenden Alternativen scheitern.

Kriterium	Per Hand	ChatGPT mit Skill	n8n-Workflow	Eigener Service
Durchlaufzeit je LV	Stunden	Minuten, je Person	Minuten, ein Lauf	Minuten, ohne Zutun
Ergebnisqualität	Format von Hand eingehalten, kein Protokoll	Antwort und Format schwanken	Schema im Parser, Regelwerk fehlt	Regelwerk im Code, Warnung je Zeile
Nutzung im Team	je Person getrennt	Skill je Konto	eine Instanz für alle	Postfach, kein Login
Datenschutz	bleibt im Haus	Verlauf beim Anbieter	Self-Hosting möglich	Azure EU, Endpunkt wählbar
Aufwand und Kosten	Arbeitszeit je Lauf	Abo und Prompt-Pflege je Nutzer	Hosting, Lizenz, Node-Pflege	unter 1 Cent je Lauf

ChatGPT mit einem hinterlegten Skill ist schnell aufgesetzt, aber nicht belastbar: Antwort und Format schwanken, es gibt keine Warnhinweise, und jede Person arbeitet in ihrem eigenen Konto. Ein n8n-Workflow trägt schon weiter, ihm fehlt aber das fachliche Regelwerk. Der eigene Service verbindet beides, und der Einrichtungsaufwand dafür waren eben jene drei Tage.

Die Referenzarchitektur

Die Architektur folgt einem einfachen Prinzip: Das Postfach ist die einzige Schnittstelle nach außen, alles dahinter skaliert automatisch.

Ein Vorgang läuft so ab:

1. Die E-Mail mit dem LV-PDF trifft im Projektpostfach ein.
2. Die Logic App prüft Absender und Anhang, legt das PDF im Archiv ab und stößt die Verarbeitung an.
3. Der Extraktor liest die Textebene des PDFs. Nur Scan-Seiten ohne Textebene gehen an die externe OCR-API, im Alltag rund ein Prozent.
4. Das Sprachmodell liefert die strukturierten Positionen, das Regelwerk im Extraktor berechnet die Angebotszeilen.
5. PDF und Ergebnisdatei bleiben 90 Tage im Blob Storage.
6. Die Angebots-Excel geht über dasselbe Postfach an den Absender zurück.

Quer über alle Schichten: Managed Identity statt Passwörter, Autoscaling, ein Ausgabenlimit für die OCR-API und eine begrenzte Aufbewahrung.

Tag drei: die Nacharbeit am OCR-Pfad

Die zwei Aufbautage lieferten einen Service, der digitale PDFs sauber verarbeitet. Der dritte Tag gehörte dem Fall, der im Plan zu kurz gekommen war: gescannte LVs ohne Textebene. Ein reales 25-Seiten-Scan-Dokument brachte zwei Erkenntnisse, die den Nachbesserungstag wert waren.

Erstens: Textebene vor OCR. Bei der OCR-Verarbeitung fielen 11 Prozent der Mengen in die Lücken zwischen den erkannten Regionen. Beim direkten Lesen der Textebene: 0 Prozent. Seitdem wird OCR nur noch für Seiten genutzt, die wirklich keine Textebene haben.

Zweitens: OCR einkaufen statt selbst betreiben. Das zunächst selbst gehostete OCR-Modell schaffte rund drei Minuten je Seite und riss beim 25-Seiten-Scan das Job-Zeitbudget. Schneller ging es nur mit parallelen Replicas oder mehr vCPUs, und beides kostet Grundlast: mehr als 4 vCPUs gab es in diesem Setup nur über Workload Profiles mit rund 64 € Fixkosten im Monat. Die externe OCR-API rechnet dagegen je verarbeiteter Seite ab, rund 9 Cent für den kompletten Scan. Für einen Randfall, der ein Prozent der Seiten betrifft, lohnen sich weder Fixkosten noch Betriebskomplexität.

Was der Betrieb kostet

Die Zahlen stammen aus der Kostenerhebung der Produktionsumgebung. Alle bisherigen Durchläufe zusammen: unter fünf Cent.

Position	Grundlage	Kosten
Logic App	Postfach-Anbindung inkl. aller Abruf-Trigger	0,02 € / Monat
Container Apps	Extraktor, im Freikontingent des Verbrauchsplans	0,00 €
Storage	PDF-Archiv, Cool-Tier, 90 Tage	unter 0,01 € / Monat
Sprachmodell (extern)	abhängig von der LV-Länge	0,002 bis 0,009 € / LV
OCR-API (extern)	nur Scan-Seiten, Normalfall null	3,50 € / 1.000 Seiten

Ein kleines LV mit 13 Seiten kostet also 0,2 bis 0,4 Cent, ein großes mit 46 Seiten unter einem Cent. Die laufenden Kosten sind damit keine Entscheidungsgröße. Die eingesparte Bearbeitungszeit ist es.

Ein Detail verdient Aufmerksamkeit: Sprachmodell und OCR laufen außerhalb der Azure-Budget-Alarme. Wer nur ein Azure-Budget setzt, überwacht die externen APIs nicht mit. Die Limits gehören zusätzlich in die Konsolen der Anbieter.

Prototyp heißt nicht Wegwerfcode

Der Grund, warum aus dem Prototyp ohne Umbau ein produktiver Service werden konnte: Er wurde von Anfang an wie Software behandelt, nicht wie ein Experiment.

Jede Codeänderung läuft über einen Pull Request mit Review, automatischen Tests und CVE-Scans, dann wird das Container-Image automatisch gebaut und digest-gepinnt. Die Infrastruktur liegt komplett in Terraform: Der Plan zeigt vorab jede Änderung, eine zweite Person gibt frei, und nach jedem Apply läuft ein Smoke-Test. Angemeldet wird ohne Passwörter, GitHub authentifiziert sich bei Azure über kurzlebige OIDC-Identitäten, die Logic App ruft den Extraktor per Managed Identity auf.

Das klingt nach viel Prozess für drei Tage. Tatsächlich ist es der Grund, warum drei Tage reichen: Die Umgebung lässt sich aus dem Repository jederzeit identisch wieder aufbauen. Fehlversuche kosten Minuten, nicht Nachmittage.

Dazu gehört auch der Fehlerpfad: Scheitert die Extraktion, enthält die Antwort den Rohtext und einen Hinweis. Jeder Lauf endet in einem Ergebnis oder einer Fehlermeldung, nie in Stille. Ein Dokument geht nicht verloren.

Lessons Learned

Was ich aus den drei Tagen mitnehme, in der Reihenfolge ihrer Wichtigkeit:

1. Den Engpass präzise benennen, bevor gebaut wird. Nicht „die Angebotserstellung automatisieren", sondern „das Übertragen automatisieren, das Kalkulieren beim Team lassen". Der enge Zuschnitt ist der Hauptgrund für das Tempo.
2. Eine vorhandene Schnittstelle nutzen. E-Mail rein, Excel raus. Kein Frontend, kein Login, keine Schulung. Die Akzeptanz im Team kommt über den vertrauten Kanal.
3. Fachliche Regeln in den Code, nicht in den Prompt. Das LLM strukturiert, der Code rechnet. Nur so werden Läufe reproduzierbar und prüfbar.
4. Unsicherheit sichtbar machen statt überspielen. Eine gelb markierte Zeile mit Warnung ist mehr wert als eine plausible Schätzung. Das entscheidet darüber, ob das Team dem Ergebnis vertraut.
5. Die Textebene schlägt OCR. Erst prüfen, was das PDF schon mitbringt. OCR ist der teure Sonderweg für den Randfall, nicht der Standard.
6. Make or Buy am realen Dokument entscheiden. Die Rechnung „selbst hosten vs. API" sah auf dem Papier anders aus als am echten 25-Seiten-Scan. Ein einziges reales Testdokument hat die Entscheidung gedreht.
7. Kostenlimits bei jedem Anbieter setzen. Azure-Budgets decken externe APIs nicht ab. Je Anbieter ein eigenes Limit, sonst gibt es einen blinden Fleck genau dort, wo die variablen Kosten entstehen.
8. CI/CD und Infrastruktur als Code von Tag eins. Nicht als Overhead, sondern als Beschleuniger: reproduzierbare Umgebung, gefahrlose Iteration, und der Prototyp ist am Ende schon das Produkt.

Das Takeaway

Drei Tage vom Papierprozess zum produktiven KI-Service sind machbar, aber nicht, weil KI-Modelle inzwischen so gut sind. Sondern weil der Zuschnitt stimmt: ein präzise benannter Engpass, eine vorhandene Schnittstelle, feste Regeln im Code und eine Umgebung, die sich jederzeit reproduzieren lässt. Das LLM ist dabei der kleinste Baustein. Die Arbeit steckt im Drumherum, und genau das Drumherum entscheidet, ob aus dem Demo-Effekt ein Werkzeug wird, das ein Team täglich nutzt.