Hukum Privasi Membentuk Desain
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 4 dari 6 dalam bab Kualitas dan Tata Kelola Data, bab 5 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Kenali Data Anda · Berikutnya: Persetujuan dan Hak untuk Dilupakan
Pertanyaan yang dijawab modul ini: Apa yang diminta oleh regulasi privasi dan industri dari sebuah desain Salesforce?
Ketika saya bekerja di Australia, saya bertemu banyak calon arsitek yang belum pernah mendengar tentang GDPR. Orang Eropa sering belum pernah mendengar tentang hukum privasi California, atau Kanada, atau Brasil. Itu wajar: Anda mengenal aturan di tempat Anda bekerja. Tetapi hukum-hukum ini menjangkau lintas negara, dan membentuk desain sistem meskipun tidak satu pun yang membahas Salesforce. Jadi semuanya layak masuk ke kursus arsitektur data.
Anda tidak perlu menjadi pengacara. Anda perlu melihat bahwa sebuah regulasi bisa mengubah di mana data disimpan, apa yang Anda kumpulkan, siapa yang melihatnya, mengapa Anda boleh memakainya, berapa lama Anda menyimpannya, ke mana Anda mengirimnya, apakah Anda bisa menghapusnya, riwayat apa yang Anda simpan, dan apa yang bisa Anda buktikan kemudian. Itu bukan hanya pertanyaan hukum. Itu pertanyaan arsitektur data.
Modul ini adalah panduan arsitektur, bukan nasihat hukum. Tim hukum dan kepatuhan memutuskan hukum mana yang berlaku dan apa yang diwajibkannya. Arsitek mengubah persyaratan itu menjadi desain yang bisa ditegakkan.
Hukum Tidak Berhenti di Perbatasan
Section titled “Hukum Tidak Berhenti di Perbatasan ”Kesalahpahaman terbesar lebih dulu: “kami tidak berada di Eropa, jadi GDPR tidak berlaku.” Mungkin, mungkin juga tidak. Cakupan wilayah GDPR menjangkau organisasi di luar UE yang menawarkan barang atau jasa kepada orang-orang di UE, atau memantau perilaku mereka di sana (Pasal 3, Regulation (EU) 2016/679 (opens in a new tab)). Jadi di mana kantor pusat perusahaan Anda bukanlah akhir dari pertanyaannya. Di mana pelanggan Anda, karyawan Anda, orang-orang yang datanya Anda simpan, sistem Anda, pemroses data Anda? Ke mana data itu berpindah? Itu lanskap dari bab 4 lagi. Anda tidak bisa mengambil keputusan privasi yang baik tanpa mengetahui ke mana data pergi.
Regulasi yang Perlu Anda Kenali
Section titled “Regulasi yang Perlu Anda Kenali ”Inilah nama-nama yang perlu diketahui seorang arsitek, beserta cakupan masing-masing. Ini tabel pengenalan, bukan matriks keberlakuan: jangan membacanya lalu memutuskan “kami punya pelanggan di California, jadi persyaratan X berlaku.” Itu keputusan tim Hukum. Tugas Anda adalah cukup tahu untuk mengajukan pertanyaannya sebelum sistemnya dibangun.
| Hukum atau standar | Di mana atau apa | Mengapa arsitek perlu mengenalinya |
|---|---|---|
| GDPR (opens in a new tab) | Uni Eropa | Data pribadi, pemrosesan yang sah, hak individu, retensi, transfer, privasi sejak desain |
| CCPA, sebagaimana diubah oleh CPRA (opens in a new tab) | California | Hak konsumen atas informasi pribadi yang dikumpulkan bisnis tentang mereka |
| PIPEDA (opens in a new tab) | Kanada | Cara organisasi sektor swasta menangani informasi pribadi |
| LGPD (opens in a new tab) | Brasil | Undang-undang umum perlindungan data pribadi Brasil |
| Privacy Act 1988 (opens in a new tab) | Australia | Cara organisasi menangani informasi pribadi, berdasarkan Australian Privacy Principles |
| HIPAA (opens in a new tab) | Layanan kesehatan AS | Informasi kesehatan yang dilindungi dalam konteks yang tercakup |
| PCI DSS (opens in a new tab) | Kartu pembayaran | Melindungi data akun kartu pembayaran |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Perusahaan publik AS | Kontrol dan bukti di balik pelaporan keuangan |
| COPPA (opens in a new tab) | AS, anak-anak di internet | Informasi pribadi yang dikumpulkan secara online dari anak-anak |
Daftarnya terus bertambah (makin banyak negara bagian AS punya hukumnya sendiri), dan hukum-hukum itu berubah. Itulah sebabnya saya tidak ingin Anda menghafal tabel lalu merasa sudah mempelajari arsitektur privasi. Pelajari nama-namanya, lalu pelajari pertanyaan-pertanyaan yang tetap berlaku setelah semuanya berubah.
Kesamaan di Antara Hukum-hukum Itu
Section titled “Kesamaan di Antara Hukum-hukum Itu ”Detailnya berbeda, tetapi hukum-hukum privasi besar terus kembali ke beberapa hal yang sama, dan masing-masing berdampak pada arsitektur.
Hak. Orang bisa meminta untuk melihat data mereka, memperbaikinya, menghapusnya, dan membawanya pergi; menurut hukum California dan Brasil, mereka juga bisa menolak (opt out) agar data mereka tidak dijual. Setiap permintaan itu berarti menemukan data orang tersebut, seluruhnya.
Transfer. GDPR dan LGPD mengendalikan data pribadi yang keluar dari yurisdiksinya dan meminta perlindungan yang memadai di tempat tujuannya; PIPEDA mengharapkan tingkat perlindungan yang sama ketika pihak ketiga memproses data itu, di mana pun ia berada. Itu lanskap lagi: panah mana yang melintasi perbatasan?
Pemberitahuan pelanggaran data. Ketika data pribadi terekspos, hukum mengharapkan Anda memberi tahu otoritas, dan terkadang orang-orang yang terdampak, dalam tenggat waktu yang berbeda-beda menurut hukumnya. Anda tidak bisa memberi tahu tentang data yang tidak Anda ketahui keberadaannya, atau menyebutkan apa yang terekspos jika Anda tidak bisa menemukan salinannya.
Akuntabilitas. Anda harus bisa menunjukkan kepatuhan: catatan tentang apa yang Anda proses dan mengapa, penilaian dampak untuk pemrosesan berisiko tinggi, dan, menurut GDPR dan LGPD, seorang petugas pelindungan data (data protection officer). Arsitekturnya harus menghasilkan catatan-catatan itu.
Mulailah dari Apa yang Bersifat Pribadi
Section titled “Mulailah dari Apa yang Bersifat Pribadi ”Sebelum melindungi informasi pribadi, temukan dulu. Sebagian jelas: nama, alamat rumah, telepon, email. Sebagian tidak: lokasi, pengenal perangkat, alamat IP, gambar, data perilaku, apa pun yang bisa ditautkan kembali ke seseorang. Dan konteks itu penting. Sebuah pengiriman Steve Trucking membawa nama, alamat, nomor telepon, catatan pengiriman, dan foto Penerima. Sebuah foto mungkin memperlihatkan kotak di teras, atau seseorang, atau bagian dalam sebuah rumah. Pengirimannya adalah data operasional, tetapi sebagian atributnya bersifat pribadi. Itulah sebabnya modul 3 mengklasifikasikan bidang-bidang: privasi dimulai dengan mengetahui apa yang Anda simpan.
Di Mana Ia Tinggal?
Section titled “Di Mana Ia Tinggal? ”“Salesforce.” Kemungkinan besar tidak hanya Salesforce. Apakah ia datang dari Mitra Ritel? Apakah disalin ke Snowflake, diserap oleh Data 360, ditulis ke log integrasi, diekspor oleh pengguna, tertinggal di riwayat bidang, diarsipkan, disalin ke sandbox, diteruskan ke mitra, dipakai dalam percakapan agen? Data pribadi menyebar. Jadi ketika tim Hukum bertanya “di mana kita menyimpan informasi orang ini?”, “kami tahu di mana nilai terkininya” bukanlah jawaban. Saya ingin lanskap dan silsilah datanya: ke mana salinan-salinannya pergi.
Satu nomor telepon, banyak salinan. Privasi juga berlaku untuk salinan-salinannya.
Mengapa Anda Boleh Memakainya?
Section titled “Mengapa Anda Boleh Memakainya? ”Memiliki data dan boleh memakainya bukanlah hal yang sama. Steve Trucking punya nomor telepon seorang Penerima untuk mengoordinasikan pengiriman hari ini. Apakah itu menjadikannya daftar pemasaran? Tidak. Dasar hukumnya bergantung pada yurisdiksi dan situasinya, dan tim Hukum yang memandunya, tetapi arsitekturnya harus membawa jawabannya: mengapa data itu dikumpulkan, pemakaian apa yang diizinkan, apakah persetujuan dibutuhkan, diberikan, ditarik, dan untuk kanal, alamat, dan tujuan mana. Izin untuk memakai data harus bisa direpresentasikan sebagai data, karena dokumen kebijakan tidak bisa mengambil keputusan saat runtime. Modul berikutnya memodelkannya.
Mengumpulkan Lebih Sedikit Adalah Keputusan Arsitektur
Section titled “Mengumpulkan Lebih Sedikit Adalah Keputusan Arsitektur ”Salah satu kontrol privasi terkuat adalah tidak mengumpulkan datanya, atau tidak menyalinnya ke tempat yang tidak membutuhkannya. Apakah Snowflake butuh nomor telepon Penerima? Apakah analitik butuh alamat jalan lengkap? Apakah sandbox butuh foto pengiriman yang asli? Apakah agen butuh detail pribadi Penerima untuk menjawab pertanyaan ini? Jika tidak, kontrol terkuatnya mungkin adalah tidak menaruhnya di sana. Setiap salinan yang tidak Anda buat adalah salinan yang tidak perlu Anda amankan, simpan, hapus, lacak persetujuannya, audit, atau laporkan saat terjadi kebocoran. Data sensitif yang paling murah untuk dikelola adalah data yang tidak pernah Anda salin.
Retensi Adalah Bagian dari Model
Section titled “Retensi Adalah Bagian dari Model ”“Kita simpan semuanya dulu saja” adalah sebuah kebijakan retensi. Hanya saja kebijakan yang buruk. Untuk data penting, saya ingin tahu pada saat desain berapa lama kita membutuhkannya dan mengapa; apakah sebuah regulasi menetapkan batas minimum atau regulasi lain menetapkan batas maksimum; kapan waktunya mulai dihitung; dan apa yang terjadi di akhir: hapus, arsipkan, hilangkan identitasnya, dan di mana salinan-salinannya? Catatan keuangan mungkin harus disimpan selama periode tertentu. Kode gerbang seorang Penerima tidak punya tujuan apa pun bertahun-tahun setelah pengirimannya. Keputusan-keputusan itu tidak menunggu sampai database menjadi besar.
Dianonimkan, Dipseudonimkan, Dienkripsi, Disamarkan
Section titled “Dianonimkan, Dipseudonimkan, Dienkripsi, Disamarkan ”Ganti “Jane Smith” dengan 7F92A1. Apakah Jane sudah dianonimkan? Tidak, jika tabel lain masih menyatakan 7F92A1 = Jane Smith. Itulah pseudonimisasi: pengenal langsungnya diganti, tetapi datanya bisa ditautkan kembali memakai informasi yang disimpan terpisah, dan menurut GDPR data yang dipseudonimkan tetaplah data pribadi (Pasal 4 angka 5). Anonimisasi melangkah lebih jauh: datanya tidak lagi bisa secara wajar ditautkan ke orangnya (Konsiderans 26). Jadi ketika seseorang berkata “kita tidak perlu menghapusnya, kita hapus saja namanya,” berhati-hatilah. Jika orangnya masih bisa diidentifikasi secara wajar, Anda belum melewati garis itu. Apakah sebuah hasil memenuhi hukum adalah keputusan tim Hukum; tugas arsitek adalah menyatakan dengan tepat apa yang dilakukan sistem: bisakah ditautkan kembali, kunci apa yang tersisa, di mana pemetaannya?
Pakai kata-katanya dengan tepat, karena masing-masing menyelesaikan masalah yang berbeda. Enkripsi melindungi data dari pengungkapan yang tidak sah; pengguna yang berwenang tetap bisa mendekripsinya. Penyamaran (masking) mengubah apa yang dilihat pengguna atau lingkungan tertentu. Pseudonimisasi memisahkan identitas langsung sambil tetap menyisakan jalan kembali. Anonimisasi menghilangkan kemampuan yang wajar untuk mengidentifikasi orangnya. Hanya yang terakhir yang membuat data tidak lagi “pribadi.”
Regulasi Menjadi Persyaratan
Section titled “Regulasi Menjadi Persyaratan ”Tim Hukum tidak perlu menyuruh saya membuat set izin; itu bagian saya. Tim Hukum mungkin berkata “hanya karyawan dengan kebutuhan bisnis yang sah yang boleh mengakses kategori informasi pribadi ini.” Lalu saya menerjemahkannya: siapa mereka, bagaimana kita mengidentifikasi kategorinya, bagaimana akses diberikan, apa yang terjadi ketika seseorang berganti pekerjaan, bisakah sebuah integrasi membacanya, bisakah agen, bisakah diekspor, dan bagaimana kita membuktikan siapa yang melihatnya? Pemilik menetapkan kebijakan; arsitek menegakkannya. Tim hukum dan kepatuhan menetapkan kewajibannya, pemilik data menetapkan kebijakan bisnisnya, dan arsitek merancang penegakannya.
Dari regulasi ke bukti: tim hukum menafsirkan, pemilik menetapkan kebijakan, arsitek membuatnya berjalan dan bisa dibuktikan.
Dan kepatuhan bukanlah sebuah produk. Anda tidak bisa membeli “kepatuhan: aktif.” Enkripsi bisa mendukung sebuah persyaratan, fitur audit menyediakan bukti, alat retensi menjalankan kebijakan, data persetujuan mendukung pemakaian yang diizinkan, tetapi melisensikan sebuah fitur tidak membuat arsitektur menjadi patuh. Kepatuhan datang dari keseluruhan desain: orang, kebijakan, proses, data, kontrol, dan bukti. Salesforce adalah bagian darinya, bukan seluruhnya. Dan jika sebuah kebijakan cukup penting untuk ditegakkan, tanyakan apakah ia cukup penting untuk dibuktikan: siapa yang mengakses rekaman ini pada 17 Maret, siapa yang mengubah bidang ini, apa isi ekspor itu? Modul 6 membahas buktinya.
Privasi Mengubah Lanskap
Section titled “Privasi Mengubah Lanskap ”Di Steve Trucking, data pribadi Penerima datang melalui tiga integrasi mitra. Salesforce membutuhkannya untuk menjalankan pengiriman; kru membutuhkan sebagian, hanya untuk titik pemberhentian mereka sendiri, hanya di hari itu; Snowflake menginginkan analitik pengiriman; keuangan butuh cukup data untuk menagih, tetapi bukan yang dilihat kru. Dan satu Mitra Ritel tidak boleh pernah melihat Penerima milik mitra lain. Privasi mengubah panah-panahnya: bidang tertentu tidak dikirim ke Snowflake, analitik mendapat versi yang kurang bisa diidentifikasi, kru hanya melihat titik pemberhentian mereka, retensi di hilir berbeda dari retensi operasional. Persyaratan privasi tidak berdiri di samping diagram lanskap. Ia mengubahnya.
Pertanyaan yang Bertahan Lebih Lama daripada Regulasinya
Section titled “Pertanyaan yang Bertahan Lebih Lama daripada Regulasinya ”Regulasi berubah, jadi bawalah serangkaian pertanyaan yang tahan lama untuk setiap data sensitif atau yang diatur regulasi:
- Apa itu? Pribadi, sensitif, keuangan, kesehatan, pembayaran, data anak-anak, atau diatur regulasi lainnya?
- Di mana ia tinggal? Setiap salinannya: integrasi, riwayat, analitik, arsip, sandbox, log, pemakaian oleh AI.
- Mengapa kita boleh memakainya? Tujuan dan dasar hukum apa yang berlaku? Apakah persetujuan terlibat?
- Siapa yang boleh memakainya? Orang, sistem, mitra, integrasi, agen.
- Berapa lama kita menyimpannya, dan apa yang terjadi di akhir?
- Bisakah orangnya menggunakan hak-haknya atas data itu? Akses, koreksi, penghapusan, portabilitas, keberatan, sebagaimana diatur hukum.
- Bisakah kita membuktikan apa yang terjadi? Akses, perubahan, ekspor, persetujuan, penghapusan, retensi.
Tata Kelola AI Sedang Menjadi Hukum
Section titled “Tata Kelola AI Sedang Menjadi Hukum ”AI menambah satu lagi konsumen data yang dikelola. Bisakah sebuah sistem AI memakai data ini, untuk tujuan apa, sebagai grounding, digabungkan dengan apa, diulang dalam keluarannya, dicatat di mana, untuk berapa lama? Tata kelola AI sedang bergeser dari kebijakan perusahaan menjadi hukum: Undang-Undang AI Uni Eropa (AI Act, Regulation (EU) 2024/1689 (opens in a new tab)) adalah contoh luas yang pertama. Apa yang diwajibkannya bergantung pada sistem dan pemakaiannya. Arah bagi arsitek jelas: AI tidak berada di luar tata kelola; AI adalah satu lagi konsumen data yang dikelola.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Di mana data yang diatur regulasi atau sensitif masuk, tinggal, berpindah, dan disalin di seluruh lanskap.
- Bagaimana kebijakan hukum dan kepatuhan menjadi persyaratan yang bisa ditegakkan, tanpa arsitek menafsirkan hukumnya.
- Apakah setiap sistem yang menerima data sensitif memang membutuhkannya, atau versi yang kurang bisa diidentifikasi sudah cukup.
- Bagaimana retensi, penghapusan, anonimisasi, pseudonimisasi, perlindungan, dan bukti membentuk siklus hidup data.
- Bukti apa yang harus ada untuk menunjukkan bahwa kontrol-kontrol penting benar-benar bekerja.
Regulasi tidak menjadi arsitektur hanya dengan mencantumkan namanya di sebuah slide. Regulasi menjadi arsitektur ketika ia mengubah cara data dikumpulkan, diklasifikasikan, dipindahkan, dilindungi, disimpan, dihapus, dan dibuktikan.
Jelajahi
Section titled “Jelajahi ”- Sumber resmi regulasi-regulasi itu ditautkan di tabel di atas, dicek 2026-10-14 (bahasa Inggris dan bahasa aslinya).
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab): Pasal 3 (cakupan wilayah), Pasal 4 angka 5 (pseudonimisasi), Konsiderans 26 (informasi anonim).
- Regulation (EU) 2024/1689 (AI Act) (opens in a new tab), EUR-Lex.