Intuit comprimeerde maandenlange implementatie van de belastingwetgeving in uren en bouwde een workflow die elk team uit de gereguleerde sector kan aanpassen

Wanneer Een grote, mooie rekening arriveerde als een ongestructureerd document van 900 pagina’s – zonder gestandaardiseerd formulier, zonder gepubliceerde IRS-formulieren en een harde verzenddeadline – had het TurboTax-team van Intuit een vraag: kon AI een maandenlange implementatie in dagen comprimeren zonder aan nauwkeurigheid in te boeten?

Wat ze daarvoor hebben gebouwd, is niet zozeer een belastingverhaal als wel een sjabloon, een workflow die commerciële AI-tools combineert, een eigen domeinspecifieke taal en een aangepast raamwerk voor unit-testing waar elk ontwikkelteam met een domeinbeperking van kan leren.

Joy Shaw, directeur Tax bij Intuit, heeft ruim dertig jaar bij het bedrijf gewerkt en veel meegemaakt Wet op belastingvermindering en werkgelegenheid en OBBB. “Er was veel ruis in de wet zelf, en we waren in staat om de fiscale implicaties eruit te halen, deze te beperken tot de individuele belastingbepalingen, en deze te beperken tot onze klanten”, vertelde Shaw aan VentureBeat. “Dat soort destillatie ging heel snel met behulp van de tools, en stelde ons in staat om te beginnen met coderen, zelfs voordat we de formulieren en instructies binnen kregen.”

Hoe OBBB de lat hoger legde

Toen in 2017 de Tax Cuts and Jobs Act werd aangenomen, werkte het TurboTax-team de wetgeving zonder hulp van AI door. Het duurde maanden en de nauwkeurigheidseisen lieten geen ruimte voor kortere wegen.

“Vroeger moesten we de wet doorlopen en codeerden we secties die naar andere codesecties verwijzen en probeerden we er zelf achter te komen”, zei Shaw.

OBBB arriveerde met dezelfde nauwkeurigheidseisen, maar met een ander profiel. Met meer dan 900 pagina’s was het structureel complexer dan de TCJA. Het kwam als een ongestructureerd document zonder gestandaardiseerd schema. De versies van het Huis en de Senaat gebruikten verschillende talen om dezelfde bepalingen te beschrijven. En het team moest met de implementatie beginnen voordat de IRS officiële formulieren of instructies had gepubliceerd.

De vraag was of AI-tools de tijdlijn konden comprimeren zonder de output in gevaar te brengen. Het antwoord vereiste een specifieke volgorde en tool die nog niet bestonden.

Van ongestructureerd document tot domeinspecifieke code

OBBB was nog steeds in het Congres toen het TurboTax-team eraan begon te werken. Met behulp van grote taalmodellen vatte het team de versie van het Huis van Afgevaardigden samen, vervolgens de versie van de Senaat, en verzoende vervolgens de verschillen. Beide kamers verwezen naar dezelfde onderliggende secties van de belastingwetten, een consistent ankerpunt waardoor de modellen vergelijkingen konden maken tussen structureel inconsistente documenten.

Op de dag van ondertekening had het team de voorzieningen al gefilterd voor degenen die van invloed waren op TurboTax-klanten, waarbij ze zich beperkten tot specifieke belastingsituaties en klantprofielen. Parsing, polling en bepalingsfiltering zijn verplaatst van weken naar uren.

Deze taken werden afgehandeld door ChatGPT en algemene LLM’s. Maar die tools stuitten op een harde grens toen het werk verschoof van analyse naar implementatie. TurboTax draait niet in een standaard programmeertaal. De belastingberekeningsengine is gebouwd op een eigen domeinspecifieke taal die intern bij Intuit wordt onderhouden. Elk model dat code voor die codebase genereert, moet juridische tekst vertalen naar syntaxis waarop het nooit is getraind, en identificeren hoe nieuwe bepalingen interageren met decennia aan bestaande code zonder te breken met wat al werkt.

Claude werd het belangrijkste hulpmiddel voor dat vertaal- en afhankelijkheidskarteringswerk. Shaw zei dat het kon identificeren wat er veranderde en wat niet, waardoor ontwikkelaars zich alleen op de nieuwe bepalingen konden concentreren. “Het is in staat om te integreren met de dingen die niet veranderen en de afhankelijkheden te identificeren van wat wel is veranderd”, zei ze. “Het versnelde het ontwikkelingsproces en stelde ons in staat ons alleen te concentreren op de dingen die veranderden.”

Het bouwhulpmiddel kwam overeen met een foutdrempel van bijna nul

LLM’s voor algemene doeleinden hebben de teamwerkcode gemaakt. Om deze code te kunnen verzenden waren twee eigen tools nodig die tijdens de OBBB-cyclus waren gebouwd.

Het eerste automatisch gegenereerde TurboTax-product beschermt rechtstreeks tegen de wetswijzigingen. Voorheen stelden ontwikkelaars deze schermen voor elke voorziening afzonderlijk samen. De nieuwe tool verwerkte het merendeel automatisch, met handmatige aanpassingen alleen waar dat nodig was.

De tweede was een op maat gemaakt raamwerk voor het testen van eenheden. Intuit had altijd geautomatiseerde tests uitgevoerd, maar het vorige systeem leverde alleen maar geslaagde/mislukte resultaten op. Wanneer een test mislukte, moesten ontwikkelaars het onderliggende belastingaangiftebestand handmatig openen om de oorzaak op te sporen. “De automatisering zou je vertellen of je geslaagd of mislukt bent, je zou in het daadwerkelijke belastinggegevensbestand moeten graven om te zien wat er mis zou kunnen zijn gegaan,” zei Shaw. Het nieuwe raamwerk identificeert het specifieke codesegment dat verantwoordelijk is, genereert een verklaring en zorgt ervoor dat de oplossing binnen het raamwerk zelf kan worden aangebracht.

Shaw zei dat de nauwkeurigheid voor een consumentenbelastingproduct bijna 100 procent moet zijn. Sarah Aerni, VP technologie van Intuit voor de Consumer Group, zei dat de architectuur deterministische resultaten moet opleveren. “Het hebben van dit soort capaciteiten rond determinisme en aantoonbaar correct door middel van testen – dat is wat tot dat soort vertrouwen leidt”, zei Aerni.

De tool regelt de snelheid. Maar Intuit gebruikt ook op LLM gebaseerde evaluatietools om door AI gegenereerde output te valideren, en zelfs daarvoor is een menselijke belastingexpert nodig om te beoordelen of de output correct is. “Het komt neer op het hebben van menselijke expertise om bijna alles te kunnen valideren en verifiëren”, zei Aerni.

Vier componenten die elk gereguleerd industrieteam kan gebruiken

OBBB was een fiscaal probleem, maar de onderliggende omstandigheden zijn niet uniek voor belastingen. Teams op het gebied van gezondheidszorg, financiële dienstverlening, juridische technologie en overheidscontracten worden regelmatig met dezelfde combinatie geconfronteerd: complexe regelgevingsdocumenten, harde deadlines, bedrijfseigen codebases en een fouttolerantie van bijna nul.

Op basis van de implementatie van Intuit zijn vier elementen van de workflow overdraagbaar naar andere ontwikkelomgevingen met beperkte domeinen:

1. Gebruik commerciële LLM’s voor documentanalyse. Algemene modellen kunnen goed omgaan met parseren, pollen en leveringsfilters. Dit is waar ze snelheid toevoegen zonder de nauwkeurigheid in gevaar te brengen.

2. Schakel over naar domeinbewuste tools wanneer analyse overgaat in implementatie. Generieke modellen die code genereren in een propriëtaire omgeving zonder deze te begrijpen, zullen output produceren die op grote schaal niet kan worden vertrouwd.

3. Bouw evaluatie-infrastructuur vóór de deadline, niet tijdens de sprint. Generieke geautomatiseerde tests leveren resultaten op die wel/niet slagen. Domeinspecifieke tests die fouten identificeren en oplossingen in de context mogelijk maken, zijn wat door AI gegenereerde code verzendt.

4. Implementeer AI-tools in de hele organisatie, niet alleen op het gebied van engineering. Shaw zei dat Intuit het gebruik van alle functies trainde en monitorde. De kennis van AI was verdeeld over de hele organisatie en niet geconcentreerd bij early adopters.

“We blijven hier inzetten op de mogelijkheden van AI en menselijke intelligentie, zodat onze klanten krijgen wat ze nodig hebben uit de ervaringen die we bouwen”, aldus Aerni.