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

Wanneer de Eén grote, mooie rekening aangekomen als een ongestructureerd document van 900 pagina’s – zonder gestandaardiseerd schema, 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 unit-testframework waar elk ontwikkelteam met een beperkt domein van kan leren.

Joy Shaw, belastingdirecteur bij Intuit, heeft meer dan dertig jaar bij het bedrijf gewerkt en heeft beide jaren meegemaakt Wet op belastingverlagingen en banen en de 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 distillatie ging heel snel met behulp van de tools, waardoor we konden beginnen met coderen nog voordat we de formulieren en instructies binnen hadden.”

Hoe de OBBB de lat hoger legde

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

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

De 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 tooling die nog niet bestonden.

Van ongestructureerd document tot domeinspecifieke code

De 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 belastingcodesecties, een consistent ankerpunt waarmee de modellen vergelijkingen konden maken tussen structureel inconsistente documenten.

Op de ondertekeningsdag had het team de voorzieningen al gefilterd voor degenen die van invloed waren op TurboTax-klanten, beperkt tot specifieke belastingsituaties en klantprofielen. Het parseren, afstemmen en filteren van voorzieningen is verplaatst van weken naar uren.

Deze taken werden afgehandeld door ChatGPT en LLM’s voor algemene doeleinden. Maar die tools stuitten op een harde grens toen het werk verschoof van analyse naar implementatie. TurboTax draait niet op 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 instrument 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 er wel is veranderd”, zei ze. “Dat versnelde het ontwikkelingsproces en stelde ons in staat ons alleen te concentreren op de dingen die wel veranderden.”

Bouwtools afgestemd op een foutdrempel van bijna nul

LLM’s voor algemene doeleinden brachten het team aan werkende code. Om die code verzendbaar te maken, waren twee eigen tools nodig die tijdens de OBBB-cyclus waren gebouwd.

Het eerste automatisch gegenereerde TurboTax-product volgt rechtstreeks 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 speciaal gebouwd unit-testframework. 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 mogelijk mis was,” zei Shaw. Het nieuwe raamwerk identificeert het specifieke codesegment dat verantwoordelijk is, genereert een verklaring en maakt het mogelijk de correctie binnen het raamwerk zelf uit te voeren.

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 de soorten capaciteiten rond determinisme en aantoonbaar corrigeren door middel van tests – dat is wat tot dat soort vertrouwen leidt”, zei Aerni.

De tooling zorgt voor 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 het resultaat correct is. “Het komt neer op het hebben van menselijke expertise om zo ongeveer alles te kunnen valideren en verifiëren”, zei Aerni.

Vier componenten die elk team uit de gereguleerde sector kan gebruiken

De OBBB was een fiscaal probleem, maar de onderliggende voorwaarden zijn niet uniek voor belastingen. Teams in de 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. Modellen voor algemene doeleinden kunnen goed omgaan met parseren, afstemmen en voorzieningen filteren. Dat is waar ze snelheid toevoegen zonder nauwkeurigheidsrisico’s te creëren.

2. Schakel over naar domeinbewuste tools wanneer analyse implementatie wordt. Modellen voor algemene doeleinden die code genereren in een eigen omgeving zonder deze te begrijpen, zullen output produceren die niet op schaal 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 testtools die fouten identificeren en oplossingen in de context mogelijk maken, maken door AI gegenereerde code verzendbaar.

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 gebruik maken van de mogelijkheden voor AI en menselijke intelligentie, zodat onze klanten krijgen wat ze nodig hebben uit de ervaringen die we bouwen”, aldus Aerni.