
Unser AI-Development Stack 2026: Wie wir mit Claude Code und MCP-Servern Software entwickeln
Vier Produkte, alle live, alle mit KI entwickelt. Erfahren Sie, wie wir mit Claude Code und MCP-Servern unseren Entwicklungs-Workflow revolutioniert haben.

Warum checkts.gpa.at keine Paragraphen erfindet, und was B2B-Entscheider:innen daraus mitnehmen können, bevor sie ihren eigenen Domain-Chatbot bauen. Eine Case Study zum AI-Chatbot für die GPA, gemeinsam mit Studio C gebaut.
Die meisten gehen davon aus: Niemand klickt sich zu den Quellen unter einer AI-Antwort durch, Hauptsache sie klingt überzeugend. Bei checkts.gpa.at, dem AI-Chatbot den wir mit Studio C für die GPA gebaut haben, stimmt das nicht. 88 Prozent der Nutzer:innen klappen den Paragraphen unter einer Antwort auf, 12 Prozent klicken direkt weiter ins Rechtsinformationssystem des Bundes. Menschen wollen die Quelle sehen.

Genau darauf haben wir die Architektur gebaut.
Wenn auf checkts.gpa.at jemand fragt "Wie lange ist meine Kündigungsfrist nach 8 Jahren im Job?", kommt keine vage Erklärung zurück. Der Bot liefert eine strukturierte Liste mit gesetzlichen Fristen nach Dienstjahren, zitiert § 20 Angestelltengesetz und setzt darüber den Hinweis "3 Rechtsquellen geprüft". Ein Klick weiter öffnet sich die Originalseite im RIS, dem offiziellen Rechtsinformationssystem. Unter jeder Antwort sitzt ein Daumen-Feedback-Button. Wer mehr braucht, bekommt ein Handoff-Angebot zu den Rechtsexpert:innen der GPA, also eine Übergabe an Menschen.

Nichts davon ist Zufall.
Bevor wir Code geschrieben haben, haben wir mit Studio C und der GPA die Rahmenbedingungen geklärt. Kunde ist die Gewerkschaft der Privatangestellten. Sie wollte Mitgliedern und Nicht-Mitgliedern eine niederschwellige Erstinformation anbieten. Keine Rechtsberatung, das war von Anfang an klar. Aber ein Werkzeug, das zwischen "Google-Suche nach kündigungsfrist österreich" und "Termin mit Jurist:in" eine brauchbare Zwischenstufe schafft.
Die Daten aus dem laufenden Betrieb zeigen, dass die schweren Themen die Nutzung dominieren. 27 Prozent der Topic-Klicks fallen auf Überstunden, 17 Prozent auf Kündigung, 16 Prozent auf Mobbing, 15 Prozent auf Gehaltsfragen. Drei Viertel der Nutzung stecken in den harten Themen. Urlaub und Krankenstand sind die Minderheit.

Das macht den Usecase so anspruchsvoll. Ein halluzinierter Paragraph im Kontext von Mobbing oder Kündigung bleibt nicht bei peinlich. Er wird zum echten Problem. Wenn der Bot § 20 AngG sagt, dann muss es § 20 AngG sein. Es gibt keine graue Zone.
Ein Large Language Model antwortet standardmäßig mit dem, was plausibel klingt. Das ist kein Bug, das ist die Grundfunktion. Wir haben diese Grundhaltung umgedreht.
Bei inhaltlichen Fragen muss der AI-Agent erst im RIS suchen, bevor er Paragraphen nennen darf. Ohne Quelle keine Zitation. Das ist Tool-Use als Pflicht, nicht als Option. Anschließend gleicht das System jede genannte Gesetzesstelle gegen die Suchergebnisse ab. Stimmt eine Referenz nicht überein, wird sie markiert und geloggt. Wir vertrauen dem Modell nicht, dass es Zitate treffsicher aus dem Gedächtnis zieht. Es darf nur das zitieren, was die Suche tatsächlich zurückgeliefert hat.
Dahinter liegt ein fest programmierter Ablauf: Der Agent recherchiert zuerst, arbeitet nur mit dem was er gefunden hat, und prüft am Ende ob die Zitate tatsächlich gedeckt sind. Klingt aufwendig. Ist es auch. Anders geht es nicht, wenn § 20 AngG wirklich § 20 AngG sein muss.
Die Verlässlichkeit kommt nicht aus einem besseren Modell. Sie kommt aus Tool-Use und Verifikation im Code. Du brauchst kein besseres Modell, du brauchst einen besseren Loop.
Die Gesetzes-Integration wurde zum Herzstück. Wir zogen sie früh aus dem Chatbot heraus und entwickelten sie als eigenständigen Baustein: ris-mcp, ein MCP-Server für das österreichische Rechtsinformationssystem, offen auf GitHub.
Im GPAI-Checker läuft die Logik als eingebettete CLI, direkt vom Agent angesteuert. Im Ökosystem steht der Server allen offen. Abgedeckt sind drei Quellen: Bundesrecht, Landesrecht, Verordnungen. Mit Caching, damit wiederkehrende Recherchen schnell bleiben.
Warum Open Source? Wir haben die Integration gebraucht, andere brauchen sie auch. Einmal gut gemacht, dann nutzen es alle.
Ein ehrlicher Chatbot ist einer, der weiß, wann er übergeben muss. Das haben wir direkt in die Architektur geschrieben.
Bei sensiblen Themen wie Kündigung, Mobbing und Insolvenz wird automatisch ein Handoff-Angebot in die Antwort eingefügt. Der Bot kann in diesen Fällen gar nicht einfach weiterreden, er muss an echte Berater:innen abgeben. Die Analytics zeigen, dass der Mechanismus genutzt wird: zwei Drittel der Handoffs kommen aus der Sidebar, der Rest über Mobile und Widget.

Dazu kommt eine Erkennung persönlicher Daten im Input: Namen, Sozialversicherungsnummern und Adressen werden blockiert, bevor sie ins Modell gelangen. Datensparsamkeit als Architektur, nicht als Policy-PDF im Keller.
Um das Ganze legt sich ein klarer Rahmen: Disclaimer-Modal beim ersten Besuch, permanenter Hinweisstreifen oben, Warn-Emoji am Ende jeder Antwort. Der Bot behauptet nirgends, Rechtsberatung zu sein. Er bleibt Erstinformation und sagt das laut.

Zwischen "das sieht in der Demo gut aus" und "das läuft in Produktion für tausende Nutzer:innen" liegt ein Berg aus Evaluierung und Guardrails. Den haben wir systematisch gebaut und über unseren AgentHub (Orchestrierung für AI-Agenten) und unser AI Gateway (die zentrale Schicht für Modellzugriffe und Guardrails) organisiert.
Die Prompt- und Tool-Logik läuft gegen eine Testsuite mit Baseline-Vergleichen. Jede Änderung muss eine Sammlung typischer Fragen bestehen, bevor sie in Produktion geht. Regressionen fallen im Test auf, nicht erst im User-Feedback.
Über 80 Governance-Regeln halten wir als strukturierte Vorgaben fest verdrahtet, nicht als flexiblen Prompt-Text. Beispiele: Pflicht-Disclaimer bei Kündigungsfragen, Handoff-Zwang bei Mobbing, Verbot konkreter Beratungsempfehlungen, Quellenpflicht bei Paragraphen-Nennung. Text-Anweisungen im Prompt lassen sich mit geschickten User-Eingaben aushebeln, strukturierte Regeln nicht.
Dazu kommen Guardrails auf mehreren Ebenen, gebündelt im AI Gateway: Erkennung persönlicher Daten, Rate-Limits pro IP, Security-Header, Content Security Policy, automatischer Handoff bei sensiblen Themen.
Im Deployment übernimmt der AgentHub den Auto-Rollback. Fällt ein Health-Check nach einer neuen Version, wird automatisch auf die vorherige zurückgefahren. Die "ich fixe es schnell"-Schleife entfällt, weil die Produktion nie in einem kaputten Zustand bleibt.
Das laufende Eval-Signal kommt aus der Nutzung selbst. Daumen-Feedback-Button unter jeder Antwort, Session-Analytics, Handoff-Klicks, Citation-Logs. "Wir evaluieren AI" heißt bei uns: automatisierte Evals, Guardrails auf mehreren Ebenen, laufende Feedback-Kanäle. Nicht: ein paar Prompts durchprobieren.
Die Kalibrierung kam nicht aus unserem Team. Sie kam aus der GPA selbst.
Während der gesamten Testphase haben wir eng mit Studio C und den Rechtsexpert:innen der GPA gearbeitet. Keine klassische Abnahme am Ende, sondern laufende Kalibrierung. Welche Antworten präzise genug sind, wo Tiefe fehlt, wo der Ton nicht passt und wo härter an Menschen übergeben werden muss.
An manchen Fragen war der Bot zu ungenau. Der Agent hatte nicht tief genug im RIS gesucht, die Quellenlage blieb dünn. Unsere Reaktion war nicht besseres Prompting, sondern breitere und tiefere RIS-Recherchen vor jeder Antwort. Antwortqualität und Quellenangaben verbesserten sich dabei gemeinsam.
Die Einsicht daraus ist für uns zentral geworden. Wer Halluzinationen bei fachlicher AI vermeiden will, braucht mehr Recherche, nicht bessere Formulierungen. Der Fix liegt im Agent-Verhalten, nicht im Textstil.
Fachliche AI ohne eingebundene Fachexpert:innen wird zum Blindflug. Wir haben die GPA-Jurist:innen zum Teil des Systems gemacht, nicht zu einer Prüfinstanz am Ende.
Und ehrlich: Ein AI-System kann jederzeit etwas Falsches ausspielen, das liegt in der Natur der Technologie. In den Themenbereichen, zu denen wir viel Feedback von den GPA-Rechtsexpert:innen bekommen haben, läuft der Bot heute verlässlich. Um auf jedem erdenklichen Use-Case top zu funktionieren, braucht es noch mehr Feedback-Zyklen. Das System ist fertig im Sinne von produktionsreif, nicht fertig im Sinne von ausgelernt.
Im Projekt hat sich gezeigt: Architektur, Evaluierung und der Expert:innen-Loop entscheiden mehr über die Qualität als die Wahl des Modells. Drei Prinzipien sind uns über die Zeit klar geworden:
Auf welcher Basis das alles läuft: Bei Honeyfield bauen wir solche Domain-Chatbots auf zwei Bausteinen. Das AI Gateway sorgt für DSGVO- und DORA-konformen Zugriff auf Foundation-Modelle und bündelt Rate-Limits, Observability und Guardrails an einer Stelle. Im AgentHub bauen wir die eigentliche Agent-Logik: Tool-Use, Eval-Pipelines, Handoff-Mechanik. Was im GPAI-Checker steckt, ist die Ausführung dieser Architektur für eine konkrete Domäne. Das Muster lässt sich übertragen.
Die Gegenposition zu alldem lautet: "AI bei Rechtsthemen ist grundsätzlich fahrlässig." Das Argument greift nur, wenn AI ohne Guardrails gebaut wird. Und die ehrliche Alternative ist nicht Einzelberatung für alle, sondern ein Mix aus Google-Suche, AK-Portal und Wartezeit auf einen Beratungstermin. Alles legitim, alles mit bekannten Schwächen. Der Chatbot schließt eine Lücke dazwischen, nicht alle Lücken.
Mit Studio C und der GPA haben wir gezeigt, dass AI und regulierte Domänen zusammengehen, wenn man die Architektur ernst nimmt. Ein Dank geht an Studio C für die präzise Kundenvertretung, die starke Briefing-Arbeit und die gemeinsame Projektführung. Und an die GPA, für den mutigen frühen Einsatz von AI im Mitgliederservice und für Rechtsexpert:innen, die sich die Zeit genommen haben, den Bot Stück für Stück zu kalibrieren.
Das Muster funktioniert nicht nur für Arbeitsrecht. Versicherung, HR, Steuerberatung. Überall wo ein falscher Paragraph richtig weh tut.
Wer sowas bauen will, kann sich melden. Der Beweis läuft unter checkts.gpa.at.

Vier Produkte, alle live, alle mit KI entwickelt. Erfahren Sie, wie wir mit Claude Code und MCP-Servern unseren Entwicklungs-Workflow revolutioniert haben.

Vibe Coding: Wie KI-gestützte Softwareentwicklung unser Business verändert hat

Künstliche Intelligenz verändert grundlegend, wie wir UX und UI gestalten. Entdecken Sie, wie KI im Frontend die Nutzererfahrung auf ein neues Level hebt.