AI Tax Assistant di Perusahaan: Data apa yang tidak boleh sembarang masuk prompt publik?

EPAJAK.OR.ID KNOWLEDGE SYSTEM

AI Tax Assistant di Perusahaan: Data apa yang tidak boleh sembarang masuk prompt publik?

FormatPost
Diperbarui12 September 2026
Waktu baca8 menit
KonteksPanduan praktis

Seorang staf menyalin surat pajak ke chatbot untuk meminta ringkasan. Nama perusahaan, NPWP, nilai transaksi, lawan transaksi, rekening, dan strategi jawaban ikut terkirim. Dalam dua menit ia memperoleh draft yang membantu. Pada saat yang sama, perusahaan kehilangan kendali atas ke mana data pergi, berapa lama disimpan, dan apakah vendor boleh menggunakannya.

Masalahnya bukan bahwa seluruh AI publik pasti membocorkan data. Masalahnya adalah staf tidak boleh mengasumsikan keamanan, kontrak, retensi, dan penggunaan data tanpa verifikasi. Informasi pajak berisi data pribadi, rahasia usaha, posisi hukum, serta informasi pihak ketiga. Satu prompt dapat memuat lebih banyak risiko daripada satu email.

Mulai dari klasifikasi, bukan daftar aplikasi

Kebijakan yang hanya berkata “jangan pakai ChatGPT” mudah dilanggar atau disiasati dengan alat lain. Klasifikasikan data dan tentukan lingkungan yang boleh memprosesnya. Nama produk dapat berubah; prinsipnya tetap.

Level publik mencakup aturan yang sudah dipublikasikan, contoh sintetis, dan informasi perusahaan yang memang tersedia untuk umum. Level internal mencakup prosedur umum, template, serta data operasional tanpa identitas sensitif. Level rahasia mencakup SPT, NPWP, NIK, gaji, rekening, invoice, kontrak, transfer pricing, serta data pelanggan dan pegawai. Level sangat terbatas mencakup kredensial, private key, seed phrase, strategi sengketa, laporan investigasi, dan data yang dilindungi privilege atau kewajiban khusus.

Prompt publik hanya menerima level publik dan, jika kebijakan mengizinkan, internal yang sudah disanitasi. Data rahasia masuk lingkungan enterprise yang telah dinilai atau tidak masuk model sama sekali. Data sangat terbatas memerlukan persetujuan khusus dan arsitektur ketat.

Identitas yang tidak boleh dianggap sepele

Nama, NIK, NPWP, alamat, tanggal lahir, nomor telepon, email, rekening, dan tanda tangan adalah identifier. Kombinasi beberapa field dapat mengidentifikasi orang meski nama dihapus. Gaji dan bukti potong mengungkap kondisi ekonomi. Data keluarga pada SPT menambah sensitivitas.

Jangan meminta staf “hapus nama saja”. Gunakan masking atau tokenisasi terstruktur. Ganti pihak dengan ID sintetis, generalisasi tanggal bila tidak penting, dan ubah nilai jika hanya menguji format. Pertahankan mapping di sistem terpisah dengan akses terbatas.

Periksa free text. Deskripsi invoice, alamat, nama file, dan komentar dapat membawa identitas. Lampiran PDF mempunyai metadata dan halaman yang tidak terlihat pada preview. Redaksi perlu memeriksa seluruh dokumen.

Rahasia usaha dan posisi pajak

Kontrak mengungkap harga, margin, pelanggan, hak, serta kewajiban. Memo transfer pricing mengungkap supply chain dan kebijakan grup. Workpaper pajak berisi judgement, kelemahan kontrol, dan exposure. Surat dari DJP dapat menunjukkan isu pengawasan.

Data semacam itu tidak otomatis aman hanya karena tidak memuat NIK. Kebocoran dapat merugikan negosiasi, reputasi, atau sengketa. NDA perusahaan dengan klien juga dapat melarang pengiriman ke subprocessor yang tidak disetujui.

Strategi jawaban pemeriksaan atau opini penasihat perlu perlakuan khusus. Memasukkannya ke layanan publik dapat memengaruhi kerahasiaan dan privilege tergantung konteks hukum. Libatkan legal sebelum memakai AI pada sengketa.

Kredensial tidak pernah masuk prompt

Password, OTP, API key, token sesi, sertifikat elektronik, kode otorisasi, private key, seed phrase, dan recovery code tidak boleh dikirim. AI tidak membutuhkan rahasia tersebut untuk menjelaskan prosedur. Screenshot layar dapat memuat QR atau token tanpa disadari.

Gunakan secret manager dan masking log. Sistem AI yang terhubung ke tool menerima credential melalui mekanisme aman, bukan teks prompt. Batasi scope, masa aktif, dan izin. Jangan memakai akun pribadi pegawai sebagai service account.

Jika kredensial terlanjur terkirim, anggap kompromi sesuai klasifikasi: cabut, rotasi, periksa log, dan laporkan insiden. Menghapus chat belum tentu membatalkan akses yang sudah terjadi.

Data pihak ketiga membawa kewajiban tambahan

Invoice vendor dan data pelanggan bukan milik perusahaan untuk digunakan tanpa batas. Kontrak, undang-undang perlindungan data, dan tujuan pengumpulan membatasi pemrosesan. Perusahaan perlu dasar, transparansi, minimisasi, serta perlindungan.

Jangan membuat proof of concept menggunakan satu folder invoice nyata hanya karena tersedia. Gunakan data sintetis. Jika pengujian produksi perlu, pilih sampel minimum, lakukan penilaian, dan batasi akses.

Periksa transfer lintas negara dan subprocessor. Penyedia AI dapat memproses data di lokasi berbeda. Daftar subprocessor, mekanisme transfer, enkripsi, retensi, dan notifikasi insiden perlu ditinjau oleh legal serta security.

Prompt, output, dan feedback semuanya dihitung

Tim sering fokus pada file upload tetapi lupa prompt teks. Pertanyaan “mengapa karyawan X menerima gaji Y?” sudah memuat data sensitif. Output model dapat mengulang data, membuat salinan baru, atau menyimpannya di log aplikasi internal.

Feedback yang dikirim pengguna, seperti menempelkan jawaban benar lengkap dengan data, juga bagian pemrosesan. Log observability, screenshot support, dan analytics dapat menjadi saluran sekunder. Petakan seluruh lifecycle.

Tentukan retensi untuk prompt, output, embedding, cache, dan backup. Hapus sesuai kebijakan serta kemampuan kontrak. Jangan menyimpan seluruh percakapan selamanya hanya karena berguna untuk training.

Public, enterprise, dan private deployment bukan label pemasaran

Nilai konfigurasi konkret. Apakah data dipakai melatih model? Berapa lama disimpan? Siapa dapat mengakses? Di mana diproses? Apakah tenant terisolasi? Apakah ada enkripsi, audit log, DLP, SSO, dan kontrol administrator? Apa yang terjadi saat kontrak berakhir?

Enterprise plan dapat lebih aman tetapi tidak otomatis cocok untuk semua data. Fitur connector atau browsing dapat mengirim data ke pihak lain. Plugin dan custom action menambah permukaan risiko. Default setting perlu ditinjau.

Lakukan data protection impact assessment untuk use case berisiko. Petakan kategori subjek, jenis data, tujuan, dasar pemrosesan, volume, pengguna, vendor, negara, retensi, keputusan otomatis, serta dampak bila salah atau bocor. Nilai necessity dan proportionality: apakah tujuan dapat dicapai dengan data lebih sedikit atau rules biasa?

Catat kontrol sebelum residual risk disetujui. Masking, private endpoint, no-training term, enkripsi, access review, retention limit, human review, dan incident response harus konkret. Risk owner menandatangani. Perubahan model, connector, atau scope memicu penilaian ulang.

Jaga record of processing. AI assistant bukan proyek terpisah dari governance privasi perusahaan. Data controller, processor, subprocessor, serta permintaan hak subjek perlu mempunyai jalur. Jika vendor tidak dapat mendukung penghapusan atau akses yang diperlukan, use case mungkin tidak layak.

Private deployment memberi kontrol lebih besar tetapi perusahaan tetap harus mengamankan model, vector database, endpoint, log, serta admin. Sistem lokal yang tidak dipatch bisa lebih berbahaya daripada layanan cloud yang dikelola baik.

Sanitasi yang benar untuk use case pajak

Untuk meminta penjelasan konsep, gunakan kasus sintetis: “PT A membayar vendor negara B sebesar 100 unit.” Hindari nama, nomor, dan nilai asli. Untuk memeriksa struktur memo, berikan heading dan klaim yang sudah dianonimkan.

Untuk ekstraksi invoice, jalankan pipeline terkontrol. Masking sebelum model dapat dilakukan pada field yang tidak diperlukan. Pertahankan dokumen asli di repository aman. Output memakai transaction ID, lalu sistem resmi menghubungkan kembali setelah review.

Untuk RAG pajak, masukkan peraturan publik dan kebijakan internal yang telah disetujui. Jangan otomatis mengindeks seluruh drive tax. Terapkan ACL hingga tingkat dokumen dan, bila perlu, chunk. Model tidak boleh menjawab data payroll kepada pengguna procurement hanya karena sama-sama pegawai.

Human review juga dapat membocorkan data

Reviewer eksternal atau vendor support mungkin melihat prompt. Tentukan siapa dan dalam kondisi apa. Gunakan role, just-in-time access, approval, dan logging. Sesi support direkam atau didokumentasikan sesuai kebijakan.

Jangan menyalin output ke email pribadi, chat, atau spreadsheet tidak terkelola. Jalur aman harus lebih mudah daripada jalur bayangan. Sediakan fitur ekspor dan kolaborasi resmi.

Training staf perlu contoh konkret. “Data sensitif” terlalu abstrak. Tunjukkan screenshot yang harus dipotong, prompt yang aman, dan proses eskalasi. Uji dengan phishing atau prompt yang meminta OTP.

Guardrail teknis yang masuk akal

Pasang DLP untuk mendeteksi pola NIK, NPWP, rekening, kartu, API key, dan kata kunci dokumen. DLP tidak sempurna; ia membantu mencegah kesalahan umum. Beri peringatan sebelum kirim dan blok kategori tinggi.

Gunakan allowlist aplikasi yang sudah dinilai. Terapkan SSO, MFA, role, dan admin control. Nonaktifkan training data bila tersedia. Batasi upload, connector, dan tool. Enkripsi data serta log.

Untuk model internal, lakukan prompt injection testing. Dokumen sumber diperlakukan sebagai data, bukan instruksi. Model tidak memperoleh hak mengirim email, membuat pembayaran, atau mengubah SPT tanpa approval.

Monitor pola, bukan isi berlebihan. Catat user, aplikasi, waktu, ukuran, klasifikasi, dan insiden dengan prinsip minimisasi. Audit akses administrator. Alert pada bulk upload atau data sangat terbatas.

Lakukan access recertification setiap kuartal untuk tax, payroll, dan sengketa. Pegawai pindah fungsi kehilangan hak lama. Akun vendor mempunyai expiry. Emergency access ditinjau setelah digunakan. Orphan account dinonaktifkan.

Model output juga dapat mengandung inferred sensitive data. Sistem mungkin menyimpulkan kondisi keuangan atau risiko pegawai dari transaksi. Larang profiling yang tidak diperlukan. Keputusan berdampak kepada orang tidak boleh dibuat hanya dari inferensi model tanpa dasar, notice, dan review yang sesuai.

Prosedur ketika data sudah terlanjur masuk

Hentikan penggunaan chat. Dokumentasikan aplikasi, akun, waktu, data, penerima, setting, dan tindakan. Jangan menghapus jejak sebelum incident team menilai. Hubungi security, privacy, legal, serta owner data.

Gunakan mekanisme vendor untuk menghapus atau membatasi data jika tersedia. Rotasi kredensial. Nilai kewajiban notifikasi berdasarkan jenis dan dampak. Periksa apakah output disalin ke tempat lain.

Fokus pada perbaikan sistem. Menghukum staf tanpa menyediakan alat aman mendorong shadow AI. Cari mengapa mereka memakai prompt publik: tekanan deadline, tidak ada akses enterprise, atau proses manual terlalu berat.

Governance yang menjaga produktivitas

Buat katalog use case: boleh, boleh dengan sanitasi, wajib enterprise, dan dilarang. Sediakan template prompt aman. Tetapkan owner dan jalur approval cepat untuk eksperimen. Review berkala karena fitur vendor berubah.

Ukur insiden, penggunaan alat resmi, waktu kerja, dan false block DLP. Kebijakan terlalu longgar bocor; kebijakan terlalu kaku dihindari. Perbaiki berdasarkan data.

AI tax assistant dapat membantu membaca peraturan, mencari dokumen, dan menyusun rekonsiliasi. Nilainya tidak mengharuskan perusahaan menyerahkan seluruh SPT ke prompt. Prinsipnya sederhana: gunakan data minimum, lingkungan sesuai klasifikasi, akses sesuai peran, dan review sesuai dampak.

Sebelum menekan enter, staf harus mampu menjawab empat pertanyaan: data siapa ini, apakah perlu untuk tugas, ke mana data pergi, dan siapa dapat melihatnya. Jika salah satu belum jelas, prompt belum siap. Kecepatan dua menit tidak sebanding dengan hilangnya kendali atas data pajak selama bertahun-tahun.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top