IFRS 17 mengubah cara perusahaan asuransi mengukur, mengakui, dan mengungkapkan kewajiban kontrak asuransi. Di sisi lain, AI (termasuk machine learning dan generative AI) semakin sering dipakai untuk mempercepat rekonsiliasi data, mengotomasi kontrol, mendeteksi anomali, hingga membantu dokumentasi. Kombinasi keduanya menciptakan peluang efisiensi, namun juga memperluas permukaan serangan (attack surface) dan risiko breach yang dapat berdampak langsung pada kerahasiaan data, integritas pelaporan keuangan, dan ketersediaan sistem.

Artikel ini membahas kontrol defensif yang relevan untuk konteks AI dalam proses IFRS 17, dengan fokus pada pencegahan kebocoran data, perlindungan integritas angka, dan kesiapan audit. Tujuannya bukan sekadar “aman”, tetapi aman dengan bukti yang bisa ditunjukkan ke auditor dan manajemen risiko.

Kenapa AI di IFRS 17 Memperbesar Risiko Breach?

Dalam implementasi IFRS 17, data dan perhitungan biasanya melibatkan banyak sistem: polis, klaim, aktuaria, data warehouse, general ledger, serta tooling IFRS 17 (sub-ledger/engine). Ketika AI masuk ke rantai ini, terdapat beberapa pola risiko umum:

  • Data sensitif berpindah ke lebih banyak tempat (misalnya ke workspace data science, notebook, atau layanan AI pihak ketiga).
  • Kontrol akses menjadi kompleks karena ada pengguna baru (data scientist, engineer, vendor) dan endpoint baru (API, pipeline MLOps).
  • Risiko “shadow AI” meningkat, ketika staf memasukkan data kontrak atau angka ke tool AI publik tanpa persetujuan.
  • Integritas hasil berpotensi terganggu jika model, prompt, atau pipeline tidak terkontrol (contoh: perubahan versi model yang tidak terdokumentasi mengubah output).
  • Jejak audit (audit trail) bisa melemah jika AI menghasilkan ringkasan, mapping, atau rekomendasi tanpa pencatatan sumber dan parameter.

IFRS 17 bukan hanya soal menghitung, tetapi juga soal governance: data lineage, kontrol perubahan, dan kemampuan menjelaskan bagaimana angka terbentuk. Karena itu, kontrol breach untuk AI harus dirancang selaras dengan kebutuhan auditability dan model risk management.

Area AI yang Paling Sering Dipakai dalam IFRS 17 (dan Titik Risikonya)

1) Otomasi rekonsiliasi dan validasi data

AI dapat membantu menemukan ketidaksesuaian antar sumber data (polis vs klaim vs GL) dan memberi rekomendasi perbaikan. Risikonya: akses berlebihan ke data keuangan dan PII, serta potensi manipulasi output jika pipeline tidak dilindungi.

2) NLP untuk klasifikasi kontrak dan ekstraksi klausul

Model bahasa dapat membantu mengekstrak fitur kontrak, mengelompokkan produk, atau menandai klausul tertentu. Risikonya: dokumen kontrak adalah data sensitif; jika diproses di layanan yang tidak dikontrol, potensi kebocoran tinggi.

3) Forecasting dan analitik untuk asumsi

AI kadang dipakai untuk analitik tren klaim atau perilaku lapse. Risikonya: perubahan model/fitur dapat mengubah asumsi dan berdampak ke angka IFRS 17; kontrol perubahan dan validasi menjadi krusial.

4) Generative AI untuk dokumentasi dan “assistant” internal

Copilot internal bisa membantu membuat ringkasan kebijakan, prosedur, atau narasi disclosure. Risikonya: prompt dapat memaparkan data sensitif; asisten dapat “mengarang” bila tidak dibatasi; dan akses ke repositori dokumen perlu diawasi.

Kontrol Breach yang Wajib: Kerangka Praktis

Kontrol di bawah ini dapat dipetakan ke kerangka umum seperti ISO 27001, NIST CSF, serta praktik GRC. Yang penting adalah penerapannya spesifik pada alur IFRS 17 dan platform AI yang dipakai.

1) Data classification & kebijakan penggunaan AI

Mulai dari mendefinisikan kategori data yang beredar di proses IFRS 17: PII pemegang polis, data kesehatan (jika ada), data klaim, parameter asumsi, angka pelaporan, serta dokumen kontrak. Lalu tetapkan aturan yang tegas:

  • Data apa yang boleh diproses oleh AI, dan AI jenis apa (on-prem, private cloud, atau layanan pihak ketiga).
  • Larangan memasukkan data rahasia ke layanan AI publik atau akun pribadi.
  • Prosedur approval untuk use case baru, termasuk penilaian risiko dan mitigasi.

Dokumentasikan kebijakan ini dan pastikan ada pelatihan singkat untuk tim aktuaria, finance, IT, dan vendor. Dalam banyak kasus breach, masalahnya bukan teknologi canggih, melainkan perilaku dan ketidakjelasan aturan.

2) Kontrol akses berbasis peran (RBAC) + prinsip least privilege

AI membutuhkan akses data luas untuk “bermanfaat”, tetapi inilah penyebab utama eksposur. Terapkan:

  • RBAC untuk dataset IFRS 17, pipeline, dan model registry.
  • Separation of duties: yang membangun model/pipeline tidak otomatis bisa memodifikasi data produksi atau mem-publish hasil ke pelaporan.
  • MFA untuk semua akses administratif dan akses jarak jauh.
  • Just-in-time access untuk akses sensitif (misalnya akses sementara untuk investigasi).

Kontrol akses harus mencakup bukan hanya aplikasi, tetapi juga storage (object store), notebook, orchestration tool, dan secrets manager.

3) Proteksi data: enkripsi, DLP, dan tokenisasi

Untuk mencegah breach yang berdampak besar, proteksi data harus berlapis:

  • Enkripsi at-rest pada storage dan backup, serta enkripsi in-transit pada semua koneksi API/pipeline.
  • DLP (Data Loss Prevention) untuk mendeteksi dan mencegah data sensitif keluar melalui email, web upload, atau integrasi aplikasi.
  • Tokenisasi atau masking untuk PII saat data dipakai untuk eksperimen atau training model, kecuali benar-benar dibutuhkan.
  • Kontrol ekspor (download restriction) pada dataset IFRS 17 dan dokumen kontrak.

Jika menggunakan generative AI, pertimbangkan redaksi otomatis (menghapus PII) sebelum data masuk ke prompt, dan batasi konteks yang dapat diakses model.

4) Isolasi lingkungan: dev/test vs produksi

Salah satu sumber kebocoran adalah data produksi disalin ke laptop atau environment dev tanpa kontrol. Praktik minimal yang sebaiknya ada:

  • Environment separation yang jelas (dev/test/prod) dengan akun dan akses terpisah.
  • Data sintetis atau data yang sudah di-mask untuk dev/test.
  • Network segmentation dan pembatasan egress (keluar ke internet) dari environment sensitif.

Untuk IFRS 17, isolasi ini juga membantu menjaga integritas: output produksi hanya berasal dari pipeline yang disetujui.

5) Kontrol perubahan (change control) untuk model, prompt, dan pipeline

Dalam konteks pelaporan keuangan, perubahan sekecil apa pun harus dapat ditelusuri. Terapkan kontrol perubahan untuk:

  • Versi model (model registry) dan parameter training.
  • Prompt template dan aturan retrieval (jika memakai RAG) karena perubahan prompt bisa mengubah hasil.
  • Pipeline ETL/ELT yang mengalirkan data ke engine IFRS 17.

Tambahkan mekanisme approval, peer review, dan logging perubahan. Ini bukan hanya untuk keamanan, tetapi juga untuk audit trail dan investigasi jika terjadi perbedaan angka.

6) Logging, monitoring, dan deteksi anomali (berbasis risiko)

Kontrol breach yang efektif memerlukan visibilitas. Prioritaskan log pada titik-titik berikut:

  • Akses dataset (siapa, kapan, dari mana, berapa banyak data).
  • Penggunaan API AI (volume request, jenis data, error, dan pola yang tidak biasa).
  • Aktivitas administratif (perubahan izin, pembuatan token, rotasi kunci).
  • Ekspor data (download besar, query masif, atau ekstraksi di jam tidak wajar).

Gunakan alert berbasis baseline dan korelasikan dengan SIEM/SOC. Dalam proses IFRS 17, lonjakan akses menjelang penutupan buku bisa normal, tetapi tetap perlu threshold yang realistis.

7) Kontrol vendor dan pihak ketiga (termasuk layanan AI)

Jika AI atau tooling IFRS 17 melibatkan pihak ketiga, lakukan kontrol berikut:

  • Due diligence keamanan: posture security, sertifikasi, dan rekam jejak.
  • Kontrak dan DPA: kepemilikan data, lokasi pemrosesan, retensi, hak audit, dan kewajiban notifikasi insiden.
  • Batasan penggunaan data: pastikan data Anda tidak digunakan untuk melatih model umum vendor tanpa persetujuan.
  • Penilaian akses vendor: akses minimum, sesi tercatat, dan akun vendor yang dapat dinonaktifkan cepat.

Vendor risk sering menjadi jalur breach karena kontrol internal perusahaan tidak otomatis berlaku di lingkungan vendor.

8) Model risk management (MRM) yang terhubung ke kontrol keamanan

AI dalam IFRS 17 bukan sekadar aplikasi IT; ia memengaruhi angka pelaporan dan keputusan. Gabungkan MRM dengan keamanan:

  • Validasi model (akurasi, bias, stabilitas) dan dokumentasi asumsi.
  • Uji ketahanan terhadap input ekstrem dan skenario data kualitas buruk.
  • Kontrol drift: deteksi perubahan distribusi data yang memengaruhi output.
  • Explainability yang memadai untuk kebutuhan internal dan auditor.

Ini membantu mencegah “breach integritas”, yaitu kondisi di mana tidak ada data yang bocor, tetapi hasil pelaporan menjadi tidak dapat dipercaya akibat perubahan model yang tidak terkendali.

9) Incident response khusus AI + latihan tabletop

Rencana respons insiden untuk sistem IFRS 17 yang memakai AI sebaiknya mencakup:

  • Prosedur isolasi pipeline/model saat dicurigai ada kebocoran atau penyalahgunaan akses.
  • Penilaian dampak terhadap data sensitif dan terhadap angka pelaporan (apakah perlu restatement/re-run).
  • Preservasi bukti (log, artefak model, konfigurasi) untuk investigasi forensik.
  • Komunikasi internal: finance, aktuaria, risk, legal, compliance, dan IT.

Lakukan latihan tabletop minimal per semester, terutama menjelang periode tutup buku. Tujuannya mempercepat keputusan dan mengurangi kebingungan saat insiden terjadi.

Checklist Singkat: “Audit-Ready” untuk AI di IFRS 17

  • Data lineage terdokumentasi dari sumber hingga pelaporan, termasuk titik di mana AI memproses data.
  • RBAC + MFA aktif dan diaudit secara berkala.
  • Model/prompt/pipeline versioning dan change approval berjalan.
  • Logging mencakup akses data, aktivitas admin, dan penggunaan AI API.
  • DLP + enkripsi diterapkan pada data sensitif IFRS 17.
  • Vendor controls jelas (DPA, retensi, notifikasi insiden, hak audit).
  • Incident response sudah diuji dengan tabletop.

FAQ

1) Apakah penggunaan generative AI otomatis melanggar kerahasiaan data IFRS 17?

Tidak otomatis, tetapi risikonya tinggi jika kontrolnya lemah. Risiko utama muncul ketika data sensitif (misalnya PII pemegang polis atau angka pelaporan) dimasukkan ke layanan AI publik atau workspace yang tidak terkontrol. Mitigasinya adalah kebijakan penggunaan AI yang jelas, DLP, redaksi/masking data, serta penggunaan solusi AI yang memenuhi persyaratan keamanan dan perjanjian pemrosesan data.

2) Kontrol paling penting apa untuk mencegah breach saat AI mengakses data polis dan klaim?

Biasanya kombinasi least privilege (RBAC), enkripsi, dan DLP memberikan dampak paling besar. RBAC membatasi siapa yang bisa mengakses data; enkripsi mengurangi risiko jika storage/backup terekspos; dan DLP membantu mencegah data sensitif keluar melalui kanal yang tidak semestinya.

3) Bagaimana cara menjaga integritas angka IFRS 17 ketika model AI sering diperbarui?

Gunakan kontrol perubahan yang ketat: versioning untuk model dan prompt, approval sebelum rilis, serta logging yang lengkap. Tambahkan validasi model dan mekanisme deteksi drift. Untuk kebutuhan audit, pastikan Anda dapat menunjukkan model versi berapa yang digunakan untuk menghasilkan output periode tertentu, dengan parameter dan dataset yang relevan.

4) Apa yang harus diminta dari vendor AI atau vendor tooling IFRS 17 agar risiko breach terkendali?

Mintalah ketentuan tertulis tentang lokasi pemrosesan data, retensi, enkripsi, kontrol akses, logging, dan notifikasi insiden. Pastikan ada DPA, batasan penggunaan data (termasuk larangan melatih model umum menggunakan data Anda tanpa izin), serta opsi audit atau laporan keamanan berkala. Evaluasi juga bagaimana vendor mengelola akses administrator dan akses support.

5) Apakah kontrol keamanan AI ini harus terpisah dari kontrol IFRS 17?

Sebaiknya tidak. Kontrol keamanan perlu terintegrasi dengan kontrol pelaporan IFRS 17 karena tujuan akhirnya sama: menjaga keterandalan dan kepercayaan terhadap angka. Integrasi ini memudahkan audit trail, memperjelas akuntabilitas, dan mengurangi gap antara tim finance, aktuaria, dan IT.

Dengan pendekatan yang tepat, AI dapat mempercepat proses IFRS 17 tanpa mengorbankan keamanan. Kuncinya adalah menyamakan standar: setiap pemakaian AI yang menyentuh data IFRS 17 harus diperlakukan sebagai bagian dari sistem pelaporan yang kritikal, lengkap dengan kontrol akses, proteksi data, perubahan yang terdokumentasi, dan kesiapan respons insiden.

ai governanceaudit readinessbreach controlsCybersecurityData ProtectionGRCIFRS 17incident responseinsuranceMLOps Security
By