Ich habe versucht, ein LLM seine eigenen Steuerfehler fangen zu lassen. Es kann das nicht — und genau das erwies sich als das ganze Geschäftsmodell.
Die Aussage war grammatikalisch perfekt. Das war das Problem.
Ich erinnere mich noch an die erste Position, bei der ich innegehalten und meinen Kaffee abgestellt habe. Eine KI hatte einen Satz zum neuen OBBBA-Zinsabzug für Pkw-Darlehen entworfen, und er lautete: „Der neue OBBBA-Zinsabzug für Pkw-Darlehen ist ein above-the-line-Abzug, der das AGI des Mandanten senkt.“ Der Satz war sauber. Er war selbstbewusst. Er war so formatiert wie jede verteidigungsfähige Position, die ich je gelesen hatte. Und er war genau in der Weise falsch, die einen echten Menschen echtes Geld kostet.
Der Abzug für Zinsen auf qualifizierte Personenkraftwagen-Darlehen (QPVLI) ist ein below-the-line-Abzug nach §63(b)(7). Er senkt nicht das adjusted gross income. Ihn above the line zu setzen ist kein Tippfehler, den man beim erneuten Lesen auffängt. Er verschiebt leise das AGI, und das AGI ist die Zahl, von der die Hälfte der Erklärung abhängt. Was mich überraschte, war nicht, dass ein Modell eine Gesetzesvorschrift leicht falsch traf. Es war, wie gut die falsche Antwort aussah.
Ein halluziniertes Zitat ist leicht zu erwischen. Eine selbstbewusste Fehlklassifikation, geschrieben in perfektem Steuerenglisch, ist die, die eingereicht wird.
Das war der Moment, in dem das eigentliche Problem für mich scharf wurde. Die Branche hat drei Jahre damit verbracht, die Erstellung steuerlicher Arbeit zu automatisieren, und sie hat das wirklich gut gemacht. Thomson Reuters bereitet 1040er automatisch vor. CCH Axcess entwirft Advisory Insights über Tausende von Kanzleien hinweg. Blue J beantwortet Recherchefragen in Klartext. Die Erstellung ist im Begriff, gelöst zu werden. Aber der Schritt nach der Erstellung, jener, bei dem jemand entscheiden muss, ob die Position nach dem Gesetz tatsächlich verteidigungsfähig ist, wurde demselben probabilistischen Modell überlassen, das sie entworfen hatte. Und nach IRC §6662 landet die 20-prozentige genauigkeitsbezogene Strafe bei dem Menschen, der die Erklärung unterschrieben hat — nicht bei dem Algorithmus, der sie geschrieben hat.
Ich habe eine Woche lang versucht, das Modell seine eigene Hausaufgabe benoten zu lassen.
Mein erster Instinkt war der naheliegende, und ich will ehrlich sagen, dass ich ihm länger nachgejagt bin, als ich hätte sollen. Wenn das Modell die Position entwerfen kann, kann ein ausreichend guter Prompt es doch sicher die Position prüfen lassen. Also habe ich es versucht. Ich gab ihm das Gesetz. Ich gab ihm die QPVLI-Regel ausbuchstabiert. Ich bat es, die eigene Ausgabe zu prüfen und alles zu markieren, was einen Abzug in die falsche Zeile setzte.
Es fing einiges. Anderes verpasste es. Und die Fehlgriffe waren die beunruhigende Sorte, denn wenn es bei der Prüfung falsch lag, lag es mit derselben flüssigen Selbstsicherheit falsch wie beim Entwerfen. Der Selbstcheck lief durch dieselben Gewichte, die den Fehler überhaupt erst erzeugt hatten. Ein Modell sich selbst überwachen zu lassen heißt, das Ding, das den Fehler gemacht hat, auch das Ding sein zu lassen, das den Fehler bemerkt — mit derselben Argumentation, die ihn verursacht hat.
Ich erinnere mich, das einem Kollegen zu erklären und mich selbst laut sagen zu hören: „Wir können einem LLM nicht vertrauen, ein LLM zu überwachen.“ Dieser Satz war der Moment, in dem das Design für mich umschlug. Ich hatte versucht, das Modell genauer zu machen. Die eigentliche Antwort war, dem Modell überhaupt nicht mehr die Rolle des Richters anzuvertrauen.
Man kann ein probabilistisches System nicht deterministisch machen, indem man es höflich bittet. Man verlagert das Urteil nach draußen.
Die Unterscheidung, die ich zu lange brauchte, um zu verinnerlichen, lautet: Erstellung und Verifikation sind nicht dieselbe Aufgabe, nur leichter oder schwerer. Es sind unterschiedliche Probleme. Erstellung belohnt Flüssigkeit, Abdeckung und Plausibilität — genau das, wofür ein Sprachmodell gebaut ist. Verifikation belohnt, bei einer bestimmten Regel nachweislich recht zu haben und einem Prüfer, der nicht im Raum war, den Rechenweg zeigen zu können. Das sind gegensätzliche Temperamente. Ich hörte auf zu versuchen, ein System beides machen zu lassen.
Was bedeutet „Agent berät, Code entscheidet“ eigentlich?
Ich will präzise sein bei der Architektur, bei der ich gelandet bin, denn die Formulierung kann wie Marketing klingen, bis man sieht, wo die Linie gezogen wird. In StatuteGuard, der Demo, die ich gebaut habe, erledigt das Sprachmodell genau eine Aufgabe: Es liest unordentliche natürliche Steuersprache und schlägt einen strukturierten, typisierten Claim vor. Das ist der einzige neuronale Schritt. Darin ist es wirklich gut, und wenn es unsicher ist, enthält es sich und die Position wird an einen Menschen eskaliert, statt ein geratenes Urteil zu bekommen.
Alles danach ist Code. Über das Urteil entscheidet eine deterministische Policy-Engine, echtes OPA/Rego mit einem identischen Pure-Python-Zwilling, die Regeln ausführt, die ich gegen das Primärrecht ausgeschrieben habe. Neuronale Extraktion, symbolische Verifikation. Das Modell berät. Der Code entscheidet. Und der Unterschied ist nicht akademisch, denn der Code lässt sich von einem gut geschriebenen Absatz nicht aus seiner Antwort herausreden.
Der Teil, den ich nicht erwartet hatte, so sehr zu schätzen, ist die Lesbarkeit. Die Policies sind keine Blackbox, der man blind vertrauen soll. Es sind Entscheidungstabellen und Rego-Quelltext, die man öffnen und selbst gegen das Gesetz prüfen kann.
Dieser Screenshot ist die gesamte These in einem Panel. Ein Head of Tax sollte mit dem Compliance-Partner sitzen, die Regel öffnen und sie gegen §30D bestätigen können, bevor man einem einzigen Urteil vertraut. Wenn die Logik ein Absatz Modell-Reasoning ist, geht das nicht. Wenn es eine Regel ist, die man lesen kann, geht es.
Was passiert also, wenn der Code Nein sagt?
Als ich diese OBBBA-Pkw-Darlehen-Position zum ersten Mal durch das fertige Gate laufen ließ, habe ich tatsächlich gelächelt. Das Modell hatte den Claim „above-the-line, senkt AGI“ genau wie zuvor entworfen. Aber diesmal sah sich die deterministische Engine den extrahierten Claim an, glich ihn mit der kodierten §63(b)(7)-Regel ab und lieferte ein hartes Urteil: BLOCK. Nicht einreichen.
Was ich an dieser Ansicht überzeugend finde — und was ich hoffe, dass ein Steuerleser überzeugend findet — ist die Kaskade. Die Engine sagt nicht nur „falsche Zeile“. Sie zeigt die fünf nachgelagerten Stellen, die eine falsche AGI-Senkung korrumpieren würden: das adjusted gross income selbst, die AGI-gekoppelte Landes-Einkommensteuer, den Medicare-IRMAA-Beitragszuschlag, die 7,5-%-Abzugsgrenze für medizinische Ausgaben und die einkommensabhängige Rückzahlung von Studentendarlehen. Ein falsch klassifizierter Abzug ist nicht ein Fehler. Es ist ein kleiner Explosionsradius, und das Panel macht den Radius sichtbar.
Dann animiert es die Begründung — das Stück, an dem mir am meisten liegt. Es geht die Zitationskette Knoten für Knoten über den IRC-Querverweisgraphen entlang, sodass das „Nein“ nie eine bloße Behauptung bleibt.
Hier ist das Detail, zu dem ich immer wieder zurückkomme, weil es beweist, dass dies kein Spielzeugproblem ist. Laut der eigenen README der Demo ist die Fehlbezeichnung „above the line“ nichts, was ich erfunden habe, um einen Bösewicht zu haben. Es ist ein dokumentierter Konsensfehler, den gängige Guidance zur Steuererstellung veröffentlicht hat — einschließlich der Website von H&R Block. Eine plausible, gut geschriebene, weit wiederholte falsche Antwort ist genau der Fehlermodus, für den ein deterministisches Gate da ist. Dass die Menge selbstbewusst ist, verschiebt den Abzug nicht zum AGI. Das entscheidet das Gesetz — und jetzt auch der Code.
Der gefährlichste Steuerfehler ist nicht der, der falsch aussieht. Es ist der, der richtig aussieht, richtig klingt und in der Guidance dreier Anbieter auftaucht.
Wenn Sie sich damit beschäftigen wollen, läuft die Demo unter veriprajna.com/de/demos/statuteguard-ki-entworfene-steuerpositionen-verifizieren. Sie können Ihre eigene Position einfügen und zusehen, wie das Gate entscheidet.
Das Feature, das ich fast falsch gemacht hätte: zu wissen, wann man „Ich weiß es nicht“ sagt
Ich muss den Fehler eingestehen, den ich beinahe eingebaut hätte, denn es ist der, den jeder Engineer, der ein Verifikationswerkzeug baut, machen will. Mein früher Instinkt war, die Maschine alles beantworten zu lassen. Abdeckung fühlte sich wie das Ziel an. Ein Werkzeug, das zu jeder Position ein Urteil liefert, wirkt fertiger als eines, das manchmal mit den Schultern zuckt.
Dieser Instinkt ist falsch, und eine konkrete Position hat mir gezeigt, warum. Nehmen Sie den §280A-Home-Office-Abzug. Ob ein Gästezimmer „regelmäßig und ausschließlich“ als Hauptgeschäftsort genutzt wird, ist ein facts-and-circumstances-Test. Es gibt keine saubere Regel zum Kodieren, weil die Antwort davon abhängt, wie ein echter Mensch einen echten Raum tatsächlich nutzt. Würde ich die deterministische Engine zwingen, darüber zu entscheiden, täte ich genau das, wogegen ich dies gebaut habe: ein selbstbewusstes Urteil dort zu erzeugen, wo die ehrliche Antwort lautet „ein Mensch muss sich das ansehen“.
Das Gate hat also vier Urteile, nicht zwei. PASS, wenn die Position verteidigungsfähig ist. BLOCK, wenn sie dem kodierten Gesetz widerspricht. NEEDS-REVIEW, wenn es ein echter Graubereich ist. OUT-OF-COVERAGE, wenn die Vorschrift in dieser Version schlicht nicht kodiert ist. Die letzten beiden bedeuten dasselbe Ehrliche: Ein Mensch entscheidet das, nicht die Maschine. Den Eskalationspfad zu bauen fühlte sich an wie das Eingeständnis einer Grenze. Tatsächlich ist es das wichtigste Feature im Produkt, denn eine Verifikationsschicht, die nie „Ich weiß es nicht“ sagt, ist nur ein zweites Modell, das mit Extra-Schritten blufft.
Die Zahlen — und genau das, was sie nicht behaupten
Ich gehe mit dem Benchmark vorsichtig um, vorsichtiger, als ein Marketer es von mir wollen würde, denn die Art, wie diese Zahlen üblicherweise formuliert werden, ist eine Lüge. Ich habe die deterministische Engine gegen ein gelabeltes Golden Set von 42 vorklassifizierten Positionen laufen lassen (14 clean, 16 error, 12 escalate) und gemessen, was die Schicht tut.
Auf diesem 42-Fälle-Golden-Set: 71,4 % deterministische Abdeckung, das heißt, die Engine hat diesen Anteil selbst zu PASS oder BLOCK aufgelöst und den Rest korrekt eskaliert. 100 % Gate-Präzision, das heißt, null korrekte Positionen wurden fälschlich geblockt. 100 % Fehlerfang-Vollständigkeit bei den kodierten Vorschriften. 100 % der Graubereiche korrekt eskaliert. Der Durchsatz lag bei Zehntausenden Positionen pro Sekunde (etwa 58.000 in dem Lauf, den ich gescreenshottet habe, obwohl das maschinenabhängig ist), weil Verifikation Infrastruktur ist, kein Modellaufruf.
Jetzt der Teil, auf dem ich bestehe. Diese Zahlen sind wahr auf diesem Golden Set, nicht als Open-World-Garantie. Ich werde Ihnen nicht sagen, StatuteGuard sei „100 % genau“, denn dieser Satz ist unehrlich in dem Moment, in dem man das gelabelte Set verlässt. Was ich Ihnen sage, ist subtiler und, wie ich finde, haltbarer: Weil das Urteil deterministischer Code ist, ist sein Verhalten bei den kodierten Vorschriften reproduzierbar und nachweisbar, keine driftende Wahrscheinlichkeit. Ich habe sogar jedes der 42 Urteile gegen OPA 1.17.1 und den Pure-Python-Zwilling gegengeprüft, und sie stimmten exakt überein. Das ist die Behauptung, hinter der ich stehen kann. Sie beschreibt die Schicht, nicht das Modell.
„100 % Genauigkeit“ ist eine Marketingzahl. „Reproduzierbar bei den kodierten Vorschriften, mit ehrlicher Eskalation überall sonst“ ist eine Engineering-Zahl. Ich würde lieber die zweite ausliefern.
Und deshalb altert das nicht aus. Ein besseres Basismodell nächstes Jahr kann einem Prüfer immer noch nicht beweisen, welche gesetzliche Vorschrift welche Position gestützt hat. Abdeckung, Gate-Präzision und ein einreichbarer Prüfpfad sind Eigenschaften der Verifikationsschicht. Sie sind keine Modellfehlerrate, die schrumpft, wenn Modelle besser werden.
Das Artefakt, von dem ich nicht wusste, dass ich es baue, bis ein Prüfer danach fragte
Ich hatte nicht vor, ein Compliance-Dokument zu bauen, aber je mehr Steuerleute ich sprach, desto öfter endete das Gespräch am selben Punkt: „schön, es hat den Fehler gefangen — aber was gebe ich dem IRS?“ Also schreibt jedes Urteil jetzt einen einreichbaren §6662-Sorgfaltsnachweis, ein druckbares Arbeitspapier, das dokumentiert, dass die Position vor der Einreichung gegen das Gesetz verifiziert wurde. Quell-Arbeitspapier, Vorschrift, Primärquelle, der extrahierte Claim, das Bestimmungsnarrativ, die vollständige Zitationskette. Es ist der Nachweis, dass tatsächlich eine Reasonable-Cause-/Due-Care-Position eingenommen wurde — und das zählt direkt unter den AICPA-SSTS-Revisionen, wirksam ab Januar 2024.
Es gibt noch einen Grund, warum mir der Ort wichtig ist, an dem das läuft, und er wurde konkret nach dem Heppner-Urteil (SDNY, Februar 2026), das die Frage einer Privilege-Waiver aufwarf, wenn Mandantenrecherche in ein öffentliches KI-Werkzeug eingespeist wird. StatuteGuard läuft standardmäßig vollständig lokal ohne API-Schlüssel. Keine Position und keine Mandantendaten verlassen den Perimeter. Nach Heppner ist eine geschlossene, lokale, auditierbare Architektur nicht nur ein Nice-to-have bei einem Security Review. Sie ist rechtlich materiell. Ich habe die Local-first-Haltung nicht für dieses Urteil entworfen. Aber das Urteil ist der Grund, warum ich jetzt damit anfange.
Zur Einordnung der Tragweite: Die US-Kosten für Business-Steuer-Compliance liegen bei über 126 Milliarden USD pro Jahr (WP1-Solution-Research, 2026), und die IRC-§6662-Strafe beträgt 20 % der Unterzahlung, mit §6663-Betrugsrisiko bis 75 %. Wenn die Erstellung automatisiert ist und die Strafe persönlich, ist der Verifikationsschritt der, der einen Head of Tax nachts wachhalten sollte.
Was ich inzwischen wirklich glaube
Ich habe damit angefangen zu denken, ich baue eine bessere Steuer-KI, und ich will am Ende klar sagen, dass ich falsch lag, was das Problem war. Ihre Steuer-KI hat kein Genauigkeitsproblem. Sie hat ein Verifikationsproblem, und ein besseres Modell wird es nicht beheben, denn die 20-prozentige Strafe landet auf Ihrer Unterschrift, nicht auf seinen Gewichten. Das Personalisieren und Automatisieren der Erstellung steuerlicher Arbeit ist echter Fortschritt. Es ist auch nicht dasselbe wie nachzuweisen, dass eine Position verteidigungsfähig ist — und die Branche hat beides stillschweigend so behandelt, als wären sie es.
Die Demo steht unter veriprajna.com/de/demos/statuteguard-ki-entworfene-steuerpositionen-verifizieren, falls Sie das Gate zu knacken versuchen wollen. Das würde ich wirklich gern sehen.
Und wenn Sie lieber zusehen wollen, wie das Gate entscheidet, statt mich dabei zu lesen, hier läuft das Ganze von Ende zu Ende.
Hier also die Frage, die ich Steuerverantwortlichen immer wieder stelle — und ich habe noch keine bequeme Antwort darauf. Wenn eine KI eine Position entwirft und Sie die Erklärung unterschreiben, welches Artefakt beweist, dass Sie sie verifiziert haben, statt ihr zu vertrauen? Wenn die ehrliche Antwort lautet „nichts, ich habe dem Modell vertraut“, dann ist das Modell nicht Ihr Assistent. Es ist Ihr Mitunterzeichner — und man kann es nicht zur Prüfung vorladen.
