Intuit Mempercepat Penerapan Kode Pajak Jadi Beberapa Jam – Solusi Workflow untuk Tim di Sektor Terkendali!

Ketika One Big Beautiful Bill muncul sebagai dokumen sebesar 900 halaman tanpa struktur yang jelas, tim TurboTax dari Intuit menghadapi tantangan: bisakah AI mempercepat proses implementasi yang biasanya memakan waktu berbulan-bulan menjadi hanya hitungan hari tanpa mengorbankan akurasi?

Yang mereka buat lebih dari sekadar cerita pajak. Ini adalah template kerja, memadukan alat AI komersial, bahasa khusus domain yang dimiliki, dan kerangka uji unit yang dapat dipelajari oleh tim pengembangan dengan batasan domain mana pun.

Joy Shaw, direktur pajak di Intuit, sudah lebih dari 30 tahun bekerja di perusahaan ini dan pernah melewati proses perubahan besar sebelumnya. “Ada banyak kebisingan dalam hukum tersebut, dan kami bisa menarik keluar implikasi pajaknya, menyoroti ketentuan pajak individual yang relevan dengan pelanggan kami,” ujar Shaw dalam sebuah wawancara. “Proses distilasi ini sangat cepat menggunakan alat yang ada, jadi kami bisa mulai coding bahkan sebelum mendapatkan formulir dan petunjuk resmi.”

Bagaimana OBBB meningkatkan standar

Ketika Tax Cuts and Jobs Act disahkan pada 2017, tim TurboTax bekerja tanpa bantuan AI. Prosesnya memakan waktu berbulan-bulan, dengan persyaratan akurasi yang sangat tinggi.

Kami harus membaca undang-undang, mengkodekan bagian yang merujuk pada bagian undang-undang lainnya, dan mencoba memahami sendiri,” jelas Shaw.

OBBB datang dengan persyaratan akurasi yang sama, tetapi dalam konteks yang berbeda. Dengan lebih dari 900 halaman, strukturnya jauh lebih kompleks dibandingkan TCJA. Dokumen itu tidak memiliki skema yang standar dan versi DPR serta Senat menggunakan bahasa yang berbeda untuk menjelaskan ketentuan yang sama. Tim harus mulai melakukan implementasi sebelum IRS menerbitkan formulir atau instruksi resmi.

Pertanyaannya adalah, bisakah alat AI memperpendek timeline tanpa mengorbankan keluaran? Menjawab ini memerlukan urutan dan alat spesifik yang saat itu belum tersedia.

Dari dokumen tak terstruktur ke kode yang sesuai domain

Sementara OBBB masih dibahas di Kongres, tim TurboTax sudah mulai mengerjakannya. Menggunakan model bahasa besar, tim merangkum versi DPR, lalu versi Senat, dan kemudian mengadaptasi perbedaan di antaranya. Kedua kamar merujuk pada bagian kode pajak yang sama, menjadikannya sebagai titik acuan yang konsisten untuk membandingkan dokumen yang secara struktural tidak konsisten.

Hingga hari penandatanganan, tim telah menyaring ketentuan yang mempengaruhi pelanggan TurboTax, terfokus pada situasi pajak dan profil pelanggan tertentu. Proses pengolahan, rekonsiliasi, dan penyaringan ketentuan kini bisa berlangsung dalam hitungan jam.

Tugas-tugas ini ditangani oleh ChatGPT dan LLM umum. Namun, alat ini menemui batasan ketika kerja beralih dari analisis ke implementasi. TurboTax tidak menggunakan bahasa pemrograman standar. Mesin perhitungan pajaknya dibangun di atas bahasa khusus yang dimiliki dan dipelihara di Intuit. Model yang menghasilkan kode untuk basis kode tersebut harus menerjemahkan teks hukum ke dalam sintaks yang belum pernah mereka pelajari dan memahami bagaimana ketentuan baru berinteraksi dengan kode yang sudah ada tanpa merusak sistem yang sudah berjalan.

Claude menjadi alat utama untuk pekerjaan penerjemahan dan pemetaan ketergantungan itu. Shaw mengatakan alat ini dapat mengidentifikasi apa yang berubah dan apa yang tidak, sehingga para pengembang dapat fokus hanya pada ketentuan baru. “Ia bisa berintegrasi dengan hal-hal yang tidak berubah dan mengidentifikasi ketergantungan pada apa yang telah berubah,” tambahnya. “Ini mempercepat proses pengembangan dan memungkinkan kami memfokuskan diri pada hal-hal yang memang perlu diperbarui.”

Membangun alat dengan ambang kesalahan mendekati nol

LLM umum membuat tim dapat menghasilkan kode yang fungsional. Namun, untuk menjadikannya siap kirim, diperlukan dua alat khusus yang dibangun sepanjang siklus OBBB.

Yang pertama secara otomatis menghasilkan layar produk TurboTax langsung dari perubahan hukum. Sebelumnya, para pengembang harus menyiapkan layar tersebut secara individual untuk setiap ketentuan. Alat baru ini menangani sebagian besar proses secara otomatis, dengan kustomisasi manual hanya di bagian yang diperlukan.

Yang kedua adalah kerangka uji unit yang dirancang khusus. Intuit selalu menjalankan tes otomatis, tetapi sistem sebelumnya hanya memberikan hasil pass/fail. Ketika sebuah tes gagal, pengembang harus membuka file data pengembalian pajak untuk melacak penyebabnya.

“Otomasi memberi tahu kami tentang hasil, tapi kami harus mengecek file data pajak sebenarnya untuk melihat apa yang mungkin salah,” ungkap Shaw. Kerangka baru ini mengidentifikasi segmen kode spesifik yang bertanggung jawab, menghasilkan penjelasan, dan membolehkan perbaikan dilakukan di dalam kerangka itu sendiri.

Shaw menekankan bahwa akurasi untuk produk pajak konsumen harus dekat dengan 100 persen. Sarah Aerni, VP teknologi untuk Grup Konsumen di Intuit, mengatakan bahwa arsitekturnya harus menghasilkan hasil yang deterministik. “Memiliki kemampuan di sekitar determinisme dan hasil yang dapat diverifikasi melalui pengujian — itu yang membawa kepercayaan,” ungkap Aerni.

Alat tersebut mengelola kecepatan. Namun, Intuit juga menggunakan alat evaluasi berbasis LLM untuk memvalidasi output yang dihasilkan AI, dan bahkan alat tersebut memerlukan keahlian ahli pajak manusia untuk menilai apakah hasilnya benar. “Pada akhirnya, penting untuk memiliki keahlian manusia untuk memvalidasi dan memverifikasi hampir semua hal,” tegas Aerni.

Empat komponen yang dapat digunakan oleh tim di industri yang diatur

OBBB adalah masalah pajak, tetapi kondisi yang mendasarinya tidak unik untuk pajak. Tim di sektor kesehatan, layanan keuangan, teknologi hukum, dan kontrak pemerintah sering menghadapi kombinasi yang sama: dokumen regulasi yang kompleks, tenggat waktu ketat, basis kode yang bersifat khusus, dan toleransi kesalahan yang sangat rendah.

Berdasarkan implementasi Intuit, empat elemen alur kerja ini bisa diterapkan di lingkungan pengembangan dengan batasan domain lain:

1. Gunakan LLM komersial untuk analisis dokumen. Model umum sangat baik dalam pengolahan, rekonsiliasi, dan penyaringan ketentuan. Di sinilah mereka menambah kecepatan tanpa mengorbankan akurasi.

2. Berpindahlah ke alat yang memahami domain ketika analisis menjadi implementasi. Model umum yang menghasilkan kode di lingkungan khusus tanpa memahaminya tidak akan mampu menghasilkan output yang dapat dipercaya secara skala.

3. Bangun infrastruktur evaluasi sebelum tenggat waktu, bukan saat sprint. Pengujian otomatis generik hanya memberikan output pass/fail. Alat pengujian khusus domain yang mengidentifikasi kegagalan dan memungkinkan perbaikan di lokasi adalah yang membuat kode yang dihasilkan AI bisa dikirim.

4. Gunakan alat AI di seluruh organisasi, tidak hanya di bagian teknik. Shaw mengatakan Intuit melatih dan memantau penggunaan di semua fungsi. Kefasihan dalam AI didistribusikan di seluruh organisasi, bukan hanya terkonsentrasi di para pengadopsi awal.

“Kami terus menggali peluang antara AI dan kecerdasan manusia, sehingga pelanggan kami mendapatkan apa yang mereka butuhkan dari pengalaman yang kami bangun,” ungkap Aerni.