Memilih Arsitektur Opt-Out AI Training untuk Data Sensitif

Memilih arsitektur opt-out AI training untuk data sensitif bukan sekadar menambah tombol “jangan gunakan data saya untuk pelatihan AI”. Tantangan utamanya adalah memastikan keputusan pengguna benar-benar dipatuhi di seluruh sistem: API operasional, cache, data lake, backup, feature store, hingga pipeline training model.

Untuk tim kecil hingga menengah, keputusan arsitektur yang tepat biasanya bukan yang paling “terdistribusi”, melainkan yang paling mudah diaudit, dikendalikan, dan dipelihara. Artikel ini membahas pendekatan praktis untuk memilih desain backend yang seimbang antara compliance, biaya operasional, dan risiko inkonsistensi.

Masalah yang Sebenarnya: Opt-Out Bukan Hanya Flag di Database

Pada aplikasi yang memproses data sensitif seperti data kesehatan, opt-out AI training memiliki beberapa konsekuensi teknis yang sering diremehkan:

• Status consent harus terversi, karena kebijakan dapat berubah dari waktu ke waktu.
• Data yang sudah terlanjur tersebar ke cache, message bus, data lake, backup, atau dataset training harus bisa ditelusuri.
• Penghapusan harus propagatif, bukan hanya menghapus record utama di database operasional.
• Audit harus kuat, tetapi audit log tidak boleh membocorkan data sensitif baru.
• Pipeline training perlu menghormati kebijakan terbaru, termasuk mencegah data masuk lagi pada training berikutnya.

Artinya, desain arsitektur harus menjawab dua pertanyaan:

1. Bagaimana sistem memutuskan apakah data seorang pengguna boleh dipakai untuk training?
2. Bagaimana sistem memastikan keputusan itu diterapkan konsisten ke semua turunan data?

Prinsip Desain untuk Data Sensitif

1. Pisahkan identitas consent dari data domain

Jangan menempelkan seluruh logika consent ke tabel domain seperti health_records. Lebih aman bila consent menjadi entitas sendiri, misalnya user_consent atau processing_policy_decision, sehingga perubahan kebijakan tidak merusak model data utama.

2. Gunakan keputusan berbasis kebijakan, bukan boolean tunggal

Field seperti ai_training_opt_out = true terlihat sederhana, tetapi cepat menjadi sempit. Dalam praktik, Anda sering membutuhkan:

• jenis pemrosesan: analytics, personalization, model training
• sumber keputusan: user action, legal requirement, default policy
• versi kebijakan yang berlaku
• waktu efektif keputusan

Karena itu, model berbasis event atau record historis biasanya lebih aman daripada satu flag yang ditimpa berkali-kali.

3. Anggap data turunan sebagai warga kelas satu

Banyak kegagalan compliance terjadi karena tim hanya memikirkan data primer di database aplikasi. Padahal data sensitif sering sudah disalin ke:

• Redis atau cache aplikasi
• search index
• message queue atau event log
• data warehouse / data lake
• feature store untuk machine learning
• artefak dataset intermediate
• backup dan snapshot

Arsitektur yang baik harus punya peta propagasi penghapusan dan penegakan consent untuk semua lapisan itu.

Monolit Modular vs Service Terpisah

Kapan monolit modular lebih tepat

Untuk tim kecil hingga menengah, monolit modular sering menjadi pilihan terbaik. Semua modul utama—akun, consent, ingestion, export, dan pipeline trigger—masih berada dalam satu codebase dan satu boundary deploy, tetapi dipisah secara tegas di level domain dan interface.

Kelebihan:

• lebih mudah menjaga konsistensi transaksi antara perubahan consent dan penandaan data terkait
• lebih sederhana untuk debugging karena trace tersebar lebih sedikit
• biaya operasional lebih rendah
• lebih mudah menerapkan migration skema dan validasi aturan secara seragam

Kekurangan:

• risiko coupling tinggi bila batas modul longgar
• pipeline AI bisa membebani aplikasi utama jika tidak dipisah di level worker/queue
• skalabilitas organisasi lebih terbatas jika tim dan domain tumbuh cepat

Kapan service terpisah masuk akal

Service terpisah layak dipilih bila consent dan governance sudah menjadi concern lintas banyak sistem, misalnya satu pengguna memiliki data di beberapa produk atau beberapa data processor internal.

Kelebihan:

• kebijakan consent terpusat dan bisa digunakan banyak layanan
• lebih jelas untuk ownership tim governance/compliance
• memudahkan penerapan policy enforcement di banyak consumer

Kekurangan:

• latensi dan kegagalan jaringan menambah risiko saat validasi consent dilakukan runtime
• eventual consistency lebih sering muncul
• biaya observability, retry, idempotency, dan schema evolution naik signifikan

Rekomendasi praktis

Jika Anda belum memiliki banyak produk independen, mulai dari monolit modular dengan boundary domain yang tegas. Pisahkan concern consent dalam modul sendiri, dan siapkan interface agar nanti bisa diekstrak menjadi service jika benar-benar diperlukan. Ini biasanya memberi rasio terbaik antara maintainability dan compliance readiness.

Sinkron vs Event-Driven untuk Perubahan Consent

Pendekatan sinkron

Dalam pendekatan sinkron, saat pengguna mengubah opt-out, API langsung:

1. menyimpan keputusan consent baru
2. menandai entitas terkait untuk dieksklusi
3. mengembalikan status berhasil hanya jika langkah penting selesai

Bagus untuk: sumber kebenaran utama, validasi cepat, dan operasi yang harus konsisten segera.

Masalahnya: Anda tidak bisa secara realistis membersihkan semua turunan data secara sinkron dalam satu request. Menghapus dari data lake, search index, cache global, dan pipeline training bisa memakan waktu lama.

Pendekatan event-driven

Pada pendekatan event-driven, perubahan consent menghasilkan event seperti ConsentRevokedForTraining, lalu worker terpisah menangani propagasi penghapusan dan penandaan blokir.

Bagus untuk:

• proses lintas sistem
• retry otomatis
• skalabilitas operasional
• pelacakan langkah-langkah asinkron

Risikonya:

• event bisa terlambat diproses
• consumer bisa gagal atau tertinggal
• sistem menjadi eventually consistent

Pola yang biasanya paling aman: hybrid

Untuk fitur opt-out AI training, pola yang sering paling masuk akal adalah:

• sinkron untuk menyimpan keputusan consent dan memblokir pemakaian data baru di sistem inti
• event-driven untuk propagasi penghapusan dan cleanup ke sistem turunan

Dengan begitu, data baru berhenti mengalir secepat mungkin, sementara data lama dibersihkan melalui pipeline asinkron yang dapat diaudit.

POST /v1/consents/ai-training/opt-out

1. Simpan consent_version baru
2. Set training_eligible = false pada profil/policy cache utama
3. Tulis outbox event: ConsentRevokedForTraining
4. Commit transaksi
5. Worker memproses event:
   - hapus cache
   - tandai record di data lake untuk purge
   - invalidasi feature store entry
   - kirim delete job ke training dataset builder
   - catat audit trail

Perhatikan penggunaan outbox pattern pada langkah 3. Ini membantu mencegah kondisi di mana data consent tersimpan tetapi event tidak pernah terkirim.

Soft Delete vs Hard Delete

Soft delete

Soft delete berarti data ditandai sebagai tidak aktif atau tidak boleh diproses, tetapi record fisiknya tetap ada.

Kelebihan:

• memudahkan audit dan rollback operasional
• lebih aman untuk referential integrity
• lebih murah diterapkan di sistem operasional

Kekurangan:

• mudah bocor ke query atau pipeline yang lupa memfilter
• bukan solusi cukup untuk kebutuhan penghapusan nyata di sistem turunan

Hard delete

Hard delete berarti data dihapus secara fisik dari media penyimpanan tertentu.

Kelebihan:

• mengurangi risiko pemrosesan ulang secara tidak sengaja
• lebih kuat untuk kebutuhan minimisasi data

Kekurangan:

• lebih sulit untuk audit dan investigasi insiden
• bisa memutus lineage bila tidak didesain benar
• lebih kompleks pada backup dan storage append-only

Pendekatan yang umumnya realistis

Gunakan kombinasi berikut:

• soft delete / deny-list logic di sistem operasional untuk memblokir penggunaan segera
• hard delete atau purge terjadwal di sistem turunan seperti cache, feature store, dataset export, dan area staging training
• retention-controlled backup handling untuk backup yang tidak praktis dimodifikasi langsung

Kesalahan umum adalah memaksakan hard delete instan di semua lapisan, termasuk backup immutable. Pada banyak sistem, yang lebih masuk akal adalah memastikan backup memiliki masa retensi jelas, akses ketat, dan tidak digunakan untuk memulihkan data pengguna ke jalur training tanpa re-apply policy.

Data Lineage, Audit Log, dan Consent Versioning

Data lineage: tahu data pergi ke mana

Tanpa lineage, Anda tidak tahu komponen mana yang harus dibersihkan saat pengguna opt-out. Minimal, simpan metadata berikut:

• ID subjek atau pseudonymous subject key
• sumber data asal
• waktu ingest
• dataset/export job yang menerima data tersebut
• feature set atau training batch yang mengonsumsi data
• status purge terakhir

Lineage tidak harus langsung berupa platform besar. Untuk tim kecil, tabel relasional yang mencatat hubungan subject - artifact - processing purpose sudah sangat membantu.

Audit log: catat keputusan, bukan isi sensitif

Audit log sebaiknya menyimpan:

• siapa atau sistem apa yang membuat perubahan
• aksi yang dilakukan
• waktu kejadian
• versi kebijakan atau consent
• cakupan pemrosesan yang terkena
• hasil propagasi per target sistem

Hindari menyalin payload data sensitif penuh ke audit log. Audit harus cukup untuk pembuktian, bukan menjadi sumber kebocoran baru.

Consent versioning: wajib bila kebijakan bisa berubah

Jika aplikasi Anda pernah mengubah teks kebijakan, default consent, atau tujuan pemrosesan, maka versioning sangat penting. Model minimalnya:

consent_policies
- policy_version
- purpose
- text_hash
- effective_at

user_consents
- user_id
- purpose
- decision            -- allow / deny
- policy_version
- decided_at
- source              -- app_ui / support / migration
- event_id            -- untuk idempotensi

Dengan model ini, Anda dapat menjawab pertanyaan audit seperti: “Pada saat data masuk ke batch training X, consent versi berapa yang berlaku?”

Propagasi Penghapusan ke Cache, Data Lake, Backup, dan Training Pipeline

1. Cache dan search index

Cache biasanya yang paling mudah dibersihkan, tetapi juga paling sering dilupakan. Simpan strategi invalidasi yang eksplisit:

• hapus key berbasis user ID atau subject key
• gunakan TTL sebagai lapisan pengaman tambahan, bukan mekanisme utama
• jika ada search index, kirim delete/update operation terpisah

2. Data lake dan warehouse

Pada storage analitik, penghapusan sering tidak instan. Yang realistis:

• tandai subjek sebagai tidak boleh dipakai lagi
• jalankan job purge periodik pada partisi/dataset terkait
• pastikan query builder untuk training selalu join ke deny-list terbaru sampai purge selesai

Ini penting karena banyak sistem analitik bersifat append-only. Menunggu purge penuh tanpa deny-list sementara adalah risiko besar.

3. Backup dan snapshot

Backup sering menjadi area abu-abu operasional. Praktik aman:

• dokumentasikan bahwa backup tidak menjadi jalur pemrosesan aktif
• batasi retensi backup
• jika restore diperlukan, jalankan proses re-sanitasi atau re-apply consent sebelum sistem aktif kembali

Jangan mengklaim “data sudah dihapus sepenuhnya” jika backup lama masih menyimpannya tanpa kontrol restore yang ketat.

4. Training pipeline dan artefak model

Ini bagian paling sulit. Ada perbedaan penting antara:

• mencegah data masuk ke training berikutnya
• menghapus pengaruh data dari model yang sudah dilatih

Untuk banyak tim aplikasi, target realistis awal adalah memastikan:

1. data pengguna tidak masuk ke batch training baru setelah opt-out
2. dataset intermediate yang masih bisa dikontrol dibersihkan
3. lineage menunjukkan model atau batch mana yang pernah mengonsumsi data tersebut

Jika organisasi Anda perlu menangani machine unlearning atau retraining khusus, itu harus diposisikan sebagai capability terpisah dengan biaya komputasi dan kompleksitas tinggi.

Contoh Alur Data yang Praktis

Alur saat user opt-out

1. User mengubah preferensi di aplikasi.
2. API consent memvalidasi identitas dan menyimpan record consent versi baru.
3. Sistem inti langsung menandai subject sebagai training-ineligible.
4. Outbox event dibuat dalam transaksi yang sama.
5. Consumer event menjalankan cleanup per target: cache, index, lake, feature store, dataset staging.
6. Setiap target menulis hasil ke tabel status propagasi.
7. Dashboard internal menampilkan apakah seluruh target sudah sinkron.

Contoh tabel status propagasi

deletion_propagation_status
- request_id
- user_id
- target_system       -- cache, lake, feature_store, training_staging
- status              -- pending, success, failed
- last_error
- updated_at

Tabel ini sangat membantu untuk operasional harian, retry, dan audit.

Matriks Keputusan Arsitektur

Anti-Pattern yang Sering Terjadi

1. Hanya menyimpan boolean di tabel user

Ini membuat audit lemah dan sulit menjawab kapan kebijakan berubah.

2. Menghapus record utama tanpa memikirkan data turunan

Data bisa tetap ada di cache, lake, dan staging training sehingga opt-out hanya tampak benar di permukaan.

3. Mengandalkan TTL cache sebagai mekanisme compliance

TTL membantu, tetapi tidak cukup. Anda tetap butuh invalidasi aktif.

4. Event-driven tanpa idempotensi

Job propagasi hampir pasti akan retry. Jika consumer tidak idempotent, hasilnya bisa acak dan sulit diaudit.

5. Audit log menyimpan payload sensitif penuh

Ini menambah permukaan risiko dan sering tidak diperlukan.

6. Menganggap backup bisa dipurge seperti database biasa

Pada banyak organisasi, backup immutable tidak dapat dimodifikasi langsung. Yang diperlukan adalah kontrol retensi dan restore procedure yang aman.

7. Tidak ada ownership per target sistem

Jika tidak jelas siapa yang bertanggung jawab membersihkan feature store atau data lake, propagasi akan berhenti di sistem yang “di luar aplikasi”.

Implementasi Minimal yang Disarankan untuk Tim Kecil hingga Menengah

Jika Anda belum punya platform data besar, baseline berikut biasanya cukup kuat:

• Monolit modular dengan modul consent terpisah
• Database relasional untuk user consent, consent policy, audit, dan propagation status
• Outbox pattern untuk menerbitkan event perubahan consent
• Queue worker untuk cleanup asinkron
• Deny-list enforcement di query pembentuk dataset training
• Lineage sederhana untuk mapping user ke artifact/dataset utama
• Dashboard operasional untuk memantau status propagasi per request

Ini jauh lebih realistis daripada langsung membangun microservices penuh, data catalog besar, dan workflow ML kompleks yang belum tentu bisa dipelihara tim kecil.

Contoh Kontrak Event dan API

Contoh payload API

POST /v1/users/{userId}/consents
Content-Type: application/json

{
  "purpose": "ai_training",
  "decision": "deny",
  "policy_version": "2025-01",
  "source": "app_ui",
  "request_id": "7f3d1c2a"
}

Contoh event internal

{
  "event_type": "ConsentRevokedForTraining",
  "event_id": "evt_01",
  "request_id": "7f3d1c2a",
  "user_id": "u_123",
  "purpose": "ai_training",
  "policy_version": "2025-01",
  "effective_at": "2026-07-14T10:00:00Z"
}

Pastikan request_id atau event_id digunakan untuk idempotensi di consumer.

Testing dan Debugging yang Sering Terlupakan

Test yang perlu ada

• contract test untuk event consent
• integration test antara API consent, outbox, dan worker
• end-to-end test yang memverifikasi data tidak lagi muncul di dataset training
• failure-path test untuk retry worker dan duplicate event
• restore simulation untuk memastikan backup restore tidak mengaktifkan ulang data tanpa policy enforcement

Debugging checklist

• cek apakah consent terbaru benar-benar yang terbaca oleh pipeline training
• cek apakah event outbox terkirim setelah commit, bukan sebelum commit
• cek consumer mana yang tertinggal berdasarkan propagation status
• cek query training apakah masih membaca snapshot lama atau cache lama
• cek apakah ada jalur ekspor data manual di luar pipeline resmi

Checklist Implementasi

1. Tentukan purpose yang jelas: apakah opt-out hanya untuk AI training atau juga analytics/personalization.
2. Buat model consent versioning, bukan boolean tunggal.
3. Pisahkan modul consent dari domain data utama.
4. Terapkan sinkron untuk blokir awal dan event-driven untuk propagasi.
5. Gunakan outbox pattern untuk keandalan event.
6. Definisikan daftar sistem turunan: cache, index, lake, feature store, staging, backup.
7. Buat propagation status table dan dashboard operasional.
8. Terapkan deny-list enforcement pada query atau builder dataset training.
9. Simpan audit log minim data sensitif.
10. Dokumentasikan kebijakan backup, retensi, dan prosedur restore.
11. Tambahkan test end-to-end untuk membuktikan opt-out benar-benar bekerja.
12. Tetapkan owner per target sistem agar cleanup tidak menjadi tanggung jawab anonim.

Kesimpulan

Untuk aplikasi yang memproses data sensitif, arsitektur opt-out AI training yang baik biasanya bukan yang paling kompleks, melainkan yang paling mudah memastikan tiga hal: keputusan consent tercatat dengan benar, pemakaian data baru berhenti segera, dan data lama dibersihkan atau diblokir secara terukur di seluruh turunan sistem.

Bagi tim kecil hingga menengah, pilihan yang paling sering rasional adalah monolit modular + consent versioning + outbox + worker event-driven + deny-list pada pipeline training. Pendekatan ini memberi jalur audit yang jelas, biaya operasional yang masih masuk akal, dan ruang evolusi jika kelak sistem perlu dipisah menjadi layanan terpisah.