Das Szenario
Stell dir vor: Es ist Donnerstagnachmittag, und auf deinem Schreibtisch landet ein Security Questionnaire. 150 Fragen. Deadline: Montag. Die Antworten existieren irgendwo - verstreut in PDFs, Richtlinien, Wiki-Seiten und in den Köpfen von Kollegen, die gerade im Urlaub sind.
Frage 73: „Beschreiben Sie Ihren Incident Response Prozess.” Die Antwort steht in einem 40-seitigen Dokument von 2019. Irgendwo. Vielleicht Seite 12. Oder 28.
Das ist der Alltag in Compliance-Teams. 10-20 Stunden pro Fragebogen. Nicht weil die Arbeit komplex ist, sondern weil sie aus endlosem Copy-Paste besteht.
Mein Kunde, ein B2B-Compliance-SaaS-Anbieter, wollte das ändern.
Der Auftrag
Der Kunde kam mit einer klaren Vision: Ein System, das Security Questionnaires automatisch ausfüllt. Klingt erstmal nach einem klassischen AI-Projekt - nimm ein LLM, wirf Dokumente rein, fertig.
Aber so einfach ist es nicht.
Compliance ist kein Spielplatz für „ungefähr richtig”. Wenn du bei der ISO-27001-Frage „Ja” antwortest, obwohl die richtige Antwort „Nein” ist, kann das teuer werden. Audit-Konsequenzen, Vertrauensverlust, rechtliche Probleme.
Also stellte ich mir vor dem ersten Code-Commit drei Fragen:
Wo sind die harten Constraints? Fragebogen-Plattformen haben keine APIs. Wir müssen echte Browser-Flows automatisieren - mit Login, Multi-Page-Formularen und allem, was dazugehört.
Was ist compliance-relevant? Antworten müssen nachvollziehbar sein. Woher kommt die Information? Welches Dokument? Welche Seite? Und: Das System darf nicht selbst absenden - ein Mensch muss prüfen.
Wie messen wir Qualität? Bei AI-Projekten entscheidet nicht die Demo, sondern das Verhalten nach dem dritten Prompt-Change. Ohne Metriken fliegst du blind.
Die Lösung: Eine 3-Stufen-Pipeline
Trust Broker ist kein ChatGPT-Wrapper. Es ist eine Pipeline mit klaren Schnittstellen zwischen jedem Schritt:
Schritt 1: Parse Ein AI-gesteuerter Browser-Agent öffnet den Fragebogen und liest ihn strukturiert aus. Feldtypen, Validierungsregeln, Dropdown-Optionen, Multi-Page-Navigation - alles landet in einem JSON-Schema. Das Ergebnis ist eine stabile, testbare Grundlage, unabhängig davon, wie die UI gerade aussieht.
Schritt 2: Analyze Hier passiert die eigentliche Magie. Das System durchsucht die Wissensbasis des Kunden - zuerst kuratierte FAQ-Einträge, dann Dokumente. Ein LLM wählt die relevanten Quellen aus und generiert eine typkonforme Antwort mit Quellenangaben.
Schritt 3: Fill Der Browser-Agent navigiert zurück zum Formular und befüllt die Felder typgerecht - Radio-Buttons, Dropdowns, Textfelder. Aber - und das ist entscheidend - er klickt nicht auf „Absenden”. Das Formular ist vorausgefüllt, aber ein Mensch muss es freigeben.
Warum diese Architektur? Jeder Schritt hat definierte Inputs und Outputs. Das bedeutet: Ich kann jeden Schritt isoliert testen, debuggen und optimieren. Wenn die Dokumenten-Auswahl nicht gut genug ist, muss ich nicht das ganze System anfassen - nur Schritt 2.
Die erste Überraschung: LLM schlägt Embeddings
Jetzt wird’s interessant.
Wenn du heute an „AI-gestützte Dokumentensuche” denkst, denkst du wahrscheinlich an RAG mit Vector-Embeddings. Das ist der Standard-Ansatz: Dokumente in Vektoren umwandeln, in einer Datenbank speichern, bei einer Frage die ähnlichsten Vektoren finden.
Ich hatte die gleiche Annahme. Also baute ich beide Varianten und verglich sie.
Das Ergebnis hat mich überrascht.
| Ansatz | F1 Score | Precision | Recall |
|---|---|---|---|
| Embedding-Baseline | 0.439 | 30.8% | 84.7% |
| LLM (Google Gemini) | 0.568 | 71.9% | 70.7% |
| LLM (OpenAI GPT-4o-mini) | 0.559 | 43.3% | 92.0% |
Die LLM-basierte Metadatenanalyse war 29% besser als Embeddings. Nicht ein bisschen besser - deutlich besser.
Warum?
Bei einem überschaubaren Dokumentenkorpus (15-150 Dokumente, typisch für mittelständische Unternehmen) kann ein LLM die Metadaten - Titel, Beschreibung, Kategorie - direkt analysieren und verstehen. Es muss nicht den Umweg über semantische Ähnlichkeit gehen.
Das Beste daran: Keine Vector-Datenbank nötig. Weniger Infrastruktur. Weniger Wartung. Und das LLM kann erklären, warum es ein Dokument ausgewählt hat - das ist Gold wert für Compliance.
Wichtig dabei: Bei sehr großen Dokumentenmengen (1000+ Docs) würde ich wieder zu Embeddings greifen. Aber für den typischen Anwendungsfall? LLM gewinnt.
Die zweite Überraschung: Das teuerste Modell ist nicht das beste
Sechs Modelle. 21 Compliance-Fragen. Ein klarer Testfall.
| Modell | Accuracy | Geschwindigkeit | Kosten/Frage |
|---|---|---|---|
| GPT-4 Turbo | 100% | 3.9s | $0.044 |
| GPT-4o | 95.2% | 3.9s | $0.011 |
| GPT-5 | 80% | 24.2s | $0.342 |
| Gemini 2.5 Pro | 76.2% | 5.9s | $0.040 |
Ja, du liest richtig. GPT-5 war schlechter als GPT-4 Turbo. Langsamer. Teurer. Und weniger akkurat.
Das ist kein Fehler. Das ist die Realität von LLMs: „Neuer” oder „größer” heißt nicht automatisch „besser für deinen Use Case”.
Die praktische Konsequenz:
- Development: GPT-4o mit 95.2% Accuracy und $0.011 pro Frage
- Production: GPT-4 Turbo mit 100% Accuracy für Zero-Tolerance-Compliance
Der Unterschied? $12.000 pro Jahr bei 1.000 Fragen täglich - ohne Qualitätsverlust in Production.
Das weiß ich, weil ich es gemessen habe. Nicht geraten.
Der Speed-Trick: Knowledge Base First
Dokumenten-Extraktion ist langsam. PDF aufmachen, Text extrahieren, an LLM schicken - das dauert 8-12 Sekunden pro Frage.
Aber viele Compliance-Fragen sind Standardfragen. „Haben Sie eine Datenschutzrichtlinie?” kommt in jedem zweiten Fragebogen vor.
Die Idee: Bevor das System Dokumente durchsucht, schaut es in einer kuratierten Knowledge Base nach. Wenn dort eine Antwort liegt, sind wir in 2-4 Sekunden fertig.
Das Ergebnis: 50% schneller für häufige Fragen. Und konsistenter - die Knowledge-Base-Antworten variieren nicht von Durchlauf zu Durchlauf.
Browser-Automation ohne Wartungs-Albtraum
Jetzt zum kniffligen Teil: Die Formulare haben keine API.
Der klassische Ansatz wäre Selenium oder Playwright mit CSS-Selektoren. Das Problem: Fragebogen-Plattformen ändern ihre UI ständig. Der Button, der gestern #submit-btn hieß, heißt heute button.primary-action. Jede Änderung legt die Automation lahm.
Meine Lösung: AI-gesteuerte Browser-Agents.
Statt „Klicke auf Element mit ID xyz” sage ich dem Agent: „Fülle Frage x mit Antwort y aus.” Das LLM analysiert die Seite, findet die Felder, versteht den Kontext. Wenn sich die UI ändert, passt sich der Agent an.
Klingt nach Magie? Ist es ein bisschen. Aber es funktioniert erstaunlich robust.
Der wichtige Constraint: Der Agent darf niemals auf „Absenden” klicken. Das ist als Critical Error definiert. Wenn er es versucht, bricht alles ab. Compliance bedeutet: Ein Mensch muss die finale Freigabe geben.
Authorization: Vier Level, transparent
In B2B-SaaS ist Datentrennung nicht optional. Kunde A darf nicht die Dokumente von Kunde B sehen. Manche Dokumente brauchen ein NDA. Andere sind komplett intern.
Das Modell:
| Level | Regel |
|---|---|
| Public | Alle sehen es |
| Restricted | Nur autorisierte Kontakte |
| Requires NDA | Nur mit unterzeichnetem NDA |
| Internal | Nie über API zugänglich |
Der Clou: Wenn das System relevante Dokumente findet, die der User nicht sehen darf, zeigt es das an. „Ich habe 3 relevante Dokumente gefunden, aber für 2 davon brauchst du ein NDA.”
Warum? Die Alternative wäre: „Keine Information gefunden.” Das ist frustrierend und unklar. Liegt es am System? Gibt es wirklich nichts? Mit transparentem Feedback weiß der User, dass es eine Antwort gibt - er muss nur die Berechtigung holen. Das reduziert Support-Anfragen und baut Vertrauen auf.
Was ich an Infrastruktur gelernt habe
Inngest statt selbstgebauter Job-Queue
Mein erster Ansatz: Eine eigene Job-Queue mit Redis. 430 Zeilen Code für Job-Management, Retries, Cleanup.
Dann die Erkenntnis: Der Kunde nutzt bereits Inngest. Warum ein zweites System bauen?
Ergebnis: 430 Zeilen gelöscht. Durable Execution von Haus aus. Jobs überleben Service-Restarts. Bessere Observability.
OpenAPI → TypeScript für Cross-Service Type Safety
Der Browser-Agent läuft in Python (weil die Bibliothek es verlangt). Der Rest ist TypeScript. Wie verhindere ich Runtime-Fehler zwischen den Services?
Lösung: Der Python-Service generiert eine OpenAPI-Spec. Daraus generiere ich TypeScript-Types. Wenn jemand ein Feld in Python umbenennt, schreit der TypeScript-Compiler - nicht die Production.
Die Zahlen am Ende
Nach vier Monaten Solo-Entwicklung:
Qualität
- 100% semantische Accuracy (GPT-4 Turbo)
- 29% bessere Dokumenten-Auswahl als Embedding-Baseline
- 100% Type Compliance (Boolean bleibt Boolean)
Performance
- 3.9 Sekunden durchschnittliche Antwortzeit
- 50% schneller durch Knowledge-Base-First-Architektur
- 10 Sekunden gespart pro 100-Fragen-Batch (Authorization-Caching)
Kosten
- $0.011 pro Frage (GPT-4o) statt $0.044 (GPT-4 Turbo)
- 75% Kosteneinsparung für Development
- $12.000/Jahr Ersparnis bei 1.000 Fragen/Tag
Code
- 6 Microservices, sauber getrennt
- 430 Zeilen weniger durch Inngest-Migration
- Zero Runtime Type Errors durch OpenAPI-Codegen
Was ich anders machen würde
Evaluation von Tag 1. Die ersten zwei Wochen habe ich Features gebaut, bevor ich wusste, wie ich sie messen würde. Das Evaluation-Framework kam dann relativ früh – aber noch früher hätte noch bessere Erkenntnisse gebracht.
Weniger Perfektion im ersten Durchlauf. Die 4-Level-Authorization war von Tag 1 komplett implementiert. Im Nachhinein hätte „Public vs. Private” für den MVP gereicht. Die Komplexität kam zu früh.
Prompt-Versioning mit Performance-Daten. Die Prompts waren in Git, aber nicht mit historischen Performance-Metriken verknüpft. Bei Änderungen wusste ich, was sich geändert hat - aber nicht immer, wie sich die Accuracy verändert hat.
Kosten-Tracking von Tag 1. API-Kosten habe ich erst nach ein paar Wochen systematisch gemessen. Überraschung: Die teuersten Calls waren nicht die, die ich erwartet hatte. Früheres Monitoring hätte Design-Entscheidungen beeinflusst.
Weniger Abstraktion, mehr Pragmatismus. Mein erster Entwurf hatte elegante Interfaces für zukünftige Erweiterungen. Die meisten davon habe ich nie gebraucht. Simpler Code, der funktioniert, schlägt flexiblen Code, der nie erweitert wird.
Tech Stack
- Backend: TypeScript (Node 22, strict mode), Python (FastAPI für Browser-Agent)
- Infrastruktur: Docker Compose, Coolify für Deployments
- Datenbank: Directus CMS (Kundeninfrastruktur)
- Job-Processing: Inngest für Durable Execution
- LLM: Multi-Provider (OpenAI, Google, Anthropic), per Config wechselbar
- Testing: Vitest, 50 realistische Testfälle, Evaluation-Framework
Fazit
Trust Broker ist kein Demo-Projekt. Es ist ein produktionsreifes System mit messbarer Qualität und wartbarer Architektur.
Die wichtigste Erkenntnis: AI-Projekte brauchen Evaluation von Tag 1. Nicht als Nice-to-have, sondern als Kern des Produkts. Ohne Metriken fliegst du blind.
Die zweitwichtigste: Teste deine Annahmen. LLM schlägt Embeddings. GPT-4 schlägt GPT-5. Das weiß ich nicht, weil ich es gelesen habe - sondern weil ich es gemessen habe.