Ein Multi­agenten­system für die Prüfung entwickeln

Aus einer Potenzial­analyse für die Abschluss­prüfung ist ein Leuchtturmvorhaben hervorgegangen, und ein Demonstrator ist entstanden. Es ist ein einzelner Agent mit Zugriff auf eine fiktive Mandantendaten­bank — Buchungs­journal, Anhang, Summen- und Saldenliste, Bilanz, Gewinn- und Verlustrechnung, Satzung — und auf den Leitfaden zur kritischen Würdigung. Er funktioniert, und genau daran lässt sich zeigen, was ihm fehlt: eine regulatorisch konforme Dokumentation, der Schutz sensibler Mandantendaten, die Fachsprache des Berufsstands, Unabhängigkeit von einem einzelnen Anbieter, Skalierbarkeit, eine eigene Oberfläche, die Fähigkeit zu lernen, und die Verbindung zur Prüfsoftware und zu den Vorsystemen der Mandanten. Die Aufgabe ist deshalb nicht, den Agenten zu verbessern, sondern die Architektur zu wechseln — und ein System zu entwickeln, das die Komplexität einer Jahresabschluss­prüfung tatsächlich abbildet und bis in den Praxiseinsatz kommt.

Der Prüfer prüft die Prüfung, nicht die Software den Prüfer. Die übliche Bauform gibt dem Prüfer Werkzeuge und lässt ihn arbeiten wie bisher, nur schneller. Hier läuft es umgekehrt: Das System erstellt zuerst einen vollständigen Prüfdurchlauf und legt ihn dem Prüfer zur Beurteilung vor. Diese Umkehrung ist die zentrale Entscheidung, aus der alles Weitere folgt, und sie hat einen praktischen Grund: Wer ein fertiges Ergebnis mit einer Liste offener Punkte vor sich hat, arbeitet an den Lücken. Wer ein leeres Formular und einen Assistenten vor sich hat, arbeitet von vorne. Die fachliche Verantwortung wandert dabei nicht mit. Sie bleibt vollständig beim Prüfer, und genau deshalb formuliert der Berichtsagent kein Prüfungs­urteil.

Geführte Freiheit, nicht ein leeres Eingabefeld. Der Prüfer arbeitet im Dialog mit einem Prüf­assistenten, und trotzdem ist die Anwendung mehr als ein Chatfenster. Ein reines Chatfenster überlässt dem Nutzer die volle Freiheit und damit die volle Orientierungs­last: Er muss selbst wissen, was er fragen soll. Ein vollständig geführter Assistent nimmt ihm Last ab und wird zur Zwangsjacke, sobald ein Prüfer fachlich anders vorgehen muss. Deshalb schlägt die Oberfläche den nächsten sinnvollen Schritt vor, ohne ihn zu erzwingen, und jede Systemaussage lässt sich an der Stelle überschreiben, an der sie steht, ohne Umweg über den Dialog. Bei Ergebnissen, die das System von selbst vorzieht, ist das die Bedingung: Sie sind nur vertretbar, wenn der Prüfer sie leicht einsehen, verstehen und übersteuern kann.

Ein Teil des Systems ist ausdrücklich keine KI. Die Zuordnung der Konten zum Kontenrahmen der Branche läuft regelbasiert und deterministisch, vor dem Agenten­durchlauf, und erzeugt die strukturierte Grundlage für alles Weitere. Der Grund steht in der Dokumentation in einem Satz: Bei einer regelbasierten Zuordnung ist keine Halluzination möglich. Dasselbe gilt für die Stichprobenziehung, die nach dem Prüfungs­standard regelbasiert erfolgt und von den Agenten bei Bedarf aufgerufen wird. In einem Vorhaben, das KI im Namen trägt, ist die Entscheidung, wo keine KI hingehört, die aufwendigere.

Entworfen wird spezifikations­getrieben, und die Umsetzung entsteht später KI-gestützt. Schon der Entwurf folgt dieser Ordnung: ein versioniertes Dokument, das wie Code geprüft wird, für Technik und Fachbereich gleichermaßen lesbar, in dem Entscheidungen, Sonderfälle und Abwägungen geklärt sind, bevor eine Zeile entsteht, dazu eine Architektur­dokumentation nach einem etablierten Rahmenwerk. Der Grund ist nicht Ordnungsliebe, sondern Prüfbarkeit: Erzeugter Code wächst schneller, als die Zeit reicht, ihn zu lesen, und wer einem Modell nur beschreibt, was er ungefähr will, bekommt bei jedem Durchlauf etwas anderes. Die Spezifikation ist zugleich die Dokumentation, die sonst am Ende fehlt — und weil hier ein Prüfungs­ablauf über neun Abschnitte abgebildet wird, ist sie zugleich das Dokument, gegen das später entwickelt wird.

Der Schnitt der Agenten kommt aus dem Berufsstand, nicht aus der Technik. Die neun Abschnitte folgen dem Qualitäts­management­handbuch des Berufsstands, von der Auftragsannahme über Risiko­beurteilung, Wesentlichkeit, interne Kontrollen und aussagebezogene Prüfungs­handlungen bis zu Berichterstattung und Archivierung. Mehrere Agenten arbeiten dabei in zwei Abschnitten: Der Plausibilitäts­check läuft früh als schnelle Konsistenz­prüfung und am Ende als Gesamtprüfung über alle Ergebnisse, die Durchsicht der Verträge und Protokolle liefert erst der Risiko­beurteilung und später der Berichterstattung. Ein Schnitt nach technischer Ähnlichkeit hätte kürzere Wege ergeben und wäre für jeden Prüfer unlesbar gewesen.

Jede Aussage zeigt auf eine Quellstelle, und gelöscht wird nicht, sondern versioniert. Eine Aussage wie „hier liegt ein Risiko“ ist in einem regulierten Beruf wertlos, wenn nicht sofort erkennbar ist, an welcher Stelle im Protokoll, in der Bilanz oder im Beleg sie herkommt. Deshalb trägt jede Ausgabe einen Verweis auf die konkrete Stelle und nicht nur auf das Dokument, und deshalb wird der Bestand fortgeschrieben statt überschrieben, damit im Nachhinein rekonstruierbar ist, wer wann was verändert hat, Mensch oder Agent. Diese Regel hat eine Grenze, und sie steht ausdrücklich im Papier: Wenn eine berechtigte Löschpflicht für personenbezogene Daten der Aufbewahrung entgegensteht, hat die Löschung Vorrang.

Keine Anbindung an die bestehende Prüfsoftware, und das ist eine Entscheidung, keine Lücke. Naheliegend wäre gewesen, das System an die im Verbund verbreitete Prüfsoftware anzudocken. Der Entwurf verzichtet darauf und entwickelt eine eigene, konsistente Datenbasis auf; Ergebnisse werden bei Bedarf exportiert. Der Preis ist doppelte Datenhaltung, der Gewinn ist die Freiheit von Altlasten in einer Landschaft, in der jeder Regionalverband seine eigene Systemwelt betreibt. Dieselbe Haltung gilt für die Modelle: Alles läuft in eigener Infrastruktur mit Ausnahme der Sprachinferenz, und die Mandantendaten verlassen sie nur als Kontextfenster einer einzelnen Anfrage, nicht dauerhaft.

Das Betriebs­modell trennt drei Verantwortungen, und nur eine davon ist nicht vergebbar. Der häufigste Denkfehler bei Systemen dieser Art ist, Betrieb als eine Rolle zu behandeln. Es sind drei: der technische Betrieb mit Verfügbarkeit, Störungs­behebung und Pflege, der klassische Server­kompetenz braucht und keine KI-Kenntnisse; die Weiter­entwicklung, die Regulatorik, neue Prüfungs­handlungen und Nutzerrückmeldungen aufnimmt; und die fachliche Hoheit über Prüfungs­handlungen, Freigaben und Schulung. Die ersten beiden sind extern vergebbar, die dritte nicht: Ein Dienstleister kann feststellen, ob ein Agent technisch korrekt arbeitet, nicht, ob eine Prüfungs­handlung fachlich richtig definiert ist. Dazu zwei Punkte, die Abhängigkeit verhindern: Der Quellcode wird dokumentiert und containerisiert übergeben, sodass der Verband den Dienstleister wechseln oder mehrere parallel beauftragen kann. Und die berufsrechtliche Verschwiegenheits­pflicht wird zentral über den Betreiber in die Kette hinein verpflichtet, statt jeden einzelnen Prüfer einen eigenen Vertrag mit dem Inferenzanbieter schließen zu lassen.

Bewusst eine junge Version, nicht eine reife. Angestrebt ist eine funktional vollständige, aber junge Systemversion, nicht die Reife einer Software, die seit zwanzig Jahren verbessert wird. Im KI-Umfeld verschieben sich Modell­qualität, Kosten und Anbieter­landschaft im Quartalstakt. Eine schnellere, günstigere erste Fassung zeigt früh, welche Elemente sich bewähren. Daraus folgt die Anforderung, die im Betriebs­modell steht: Weiter­entwicklung ist kein Sonderfall, den man einpreist, sondern der Normalzustand.