AI Search dan Privacy: Data Apa yang Jangan Dipublikasikan demi Entity Completeness

Ada godaan baru dalam proyek AI visibility.

“Biar entity makin lengkap, kita publish semuanya.”

Nama lengkap.

Tanggal lahir.

Nomor telepon personal.

Riwayat pendidikan.

Alamat.

Daftar keluarga.

Nomor registrasi.

Foto dokumen.

Relationship.

Email.

Semakin banyak field, dianggap semakin mudah AI memahami entity.

Logika ini berbahaya.

Entity completeness bukan tujuan yang mengalahkan privacy.

Website tidak perlu berubah menjadi dossier publik hanya supaya knowledge graph terlihat rapi.

Untuk Indonesia, UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi sudah menjadi kerangka utama pelindungan data pribadi. JDIH Komdigi menegaskan bahwa pengendali data wajib melindungi data pribadi, mencegah akses tidak sah, dan menjalankan kewajiban terkait pemrosesan, penghentian, serta penghapusan data sesuai ketentuan.

Jadi sebelum bertanya “field apa lagi yang bisa kita tambahkan?”, organisasi harus bertanya:

“Apakah data ini memang perlu dipublikasikan?”

Public entity information dan personal data bukan hal yang sama

Untuk organisasi, beberapa fakta memang wajar public.

Nama legal perusahaan.

Alamat kantor publik.

Website resmi.

Nomor customer service.

Produk.

Layanan.

Leadership yang memang dipublikasikan secara institusional.

License atau certification yang memang harus public.

Tetapi ketika entity adalah orang, boundary lebih sensitif.

Nama CEO public tidak berarti nomor ponsel CEO public.

Jabatan public tidak berarti alamat rumah public.

Speaker bio public tidak berarti tanggal lahir lengkap perlu dipublikasikan.

Profile professional tidak berarti identitas keluarga perlu masuk.

Entity resolution tidak membutuhkan semua personal attribute.

Use minimal sufficient identity.

Cukup untuk membedakan.

Tidak berlebihan.

Data minimization harus menang

UU PDP mengatur prinsip dan kewajiban dalam pemrosesan data pribadi. Walaupun implementasi legal spesifik harus ditentukan bersama counsel sesuai konteks, practical principle-nya jelas: organisasi tidak boleh menganggap semua data yang dimiliki boleh dipublikasikan.

AI Search team seharusnya punya rule:

Kalau data tidak dibutuhkan untuk tujuan publik yang legitimate, jangan publish hanya untuk “AI clarity”.

Contoh.

Untuk membedakan dua dokter dengan nama sama:

Nama.

Gelar.

Spesialisasi.

Institusi.

Official profile.

Mungkin cukup.

Tidak perlu:

NIK.

Alamat rumah.

Nomor personal.

Nama pasangan.

Tanggal lahir detail.

Complete identity tidak sama dengan total identity.

Gunakan purpose.

Data apa yang hampir selalu harus diperlakukan hati-hati?

Nomor identitas nasional.

Passport.

Financial account.

Card number.

Personal authentication data.

Private email.

Personal phone yang tidak dimaksudkan sebagai business contact.

Home address.

Precise personal location.

Health data.

Biometric data.

Sexual life.

Genetic data.

Personal financial condition.

Child data.

Private employment record.

Credential.

Password.

Security answer.

Internal employee ID jika bisa membuka system.

Family relationship jika tidak punya reason public.

Data kategori sensitif atau spesifik harus diperlakukan sesuai hukum dan risk.

Jangan memasukkan hanya karena schema atau graph punya field.

Schema field bukan perintah untuk mengisi.

Structured data bukan form wajib

Google Organization atau Person structured data punya berbagai property.

Itu tidak berarti semua property harus diisi.

Hal yang sama berlaku pada internal knowledge graph.

Ontology punya 100 field.

Entity mungkin hanya membutuhkan 12.

Jangan mengubah optional field menjadi data collection target.

Technical completeness sering menjadi lawan privacy.

Data architect suka null sedikit.

Privacy governance tahu null kadang benar.

Field kosong bisa berarti:

Tidak diperlukan.

Tidak tersedia.

Tidak boleh dipublikasikan.

Unknown.

Restricted.

Bukan data quality failure.

Buat status.

Jangan memaksa.

Contact detail publik harus function-specific

Contoh perusahaan ingin AI memahami contact.

Gunakan:

Customer service email.

Public phone.

Office address.

Press contact jika relevant.

Investor relations.

Bukan nomor WhatsApp pribadi founder hanya karena response lebih cepat.

Personal contact sering bocor dari:

PDF.

Old presentation.

WHOIS lama.

Event brochure.

Press kit.

Directory.

AI Search audit justru seharusnya menemukan exposure dan mengurangi risiko.

Bukan menyalin ulang ke canonical page.

Visibility program perlu privacy review.

Leadership bio juga harus minimal

Public profile perlu:

Nama.

Jabatan.

Relevant expertise.

Official image.

Public professional profile.

Career history yang relevan.

Tidak perlu menjadi biodata lengkap.

Tanggal lahir?

Tanya purpose.

Home town?

Tanya purpose.

Family?

Tanya purpose.

Personal social media?

Apakah account professional dan intended public?

Jangan membuat AI entity page seperti data broker profile.

Reputasi bukan alasan menghapus privacy boundary.

Employee directory jauh lebih sensitif

Banyak organisasi ingin memperkuat author entity.

Bagus.

Tetapi jangan publish semua employee.

Gunakan role yang memang public-facing.

Author.

Researcher.

Executive.

Spokesperson.

Professional license holder.

Support team tidak perlu full identity.

Internal staff list bisa memberi attacker:

Nama.

Role.

Department.

Email pattern.

Office.

Manager.

Semua bisa dipakai social engineering.

Entity completeness punya security consequence.

Privacy dan security bertemu.

Data anak harus diberi threshold sangat tinggi

Kalau organisasi melayani sekolah, parenting, entertainment, atau family service, jangan menganggap data anak sama dengan data adult.

Public profile anak, precise location, schedule, school, health condition, family detail, dan identifier punya risk tinggi.

UU PDP memberi perhatian pada data pribadi anak sebagai kategori yang memerlukan pelindungan khusus.

Untuk content strategy, rule paling aman adalah:

Jangan publish personal detail anak kecuali benar-benar diperlukan, ada legal basis dan governance yang tepat, serta risk sudah dinilai.

AI visibility bukan justification.

Medical dan legal client juga perlu boundary

Website klinik ingin entity complete.

Publish doctor profile, license information yang memang public, specialization, schedule.

Jangan publish patient case detail yang bisa diidentifikasi.

Case study perlu de-identification dan consent sesuai context.

Firma hukum ingin menunjukkan expertise.

Jangan publish confidential client fact.

Case detail harus melalui legal review.

AI Search memperbesar rediscoverability.

Informasi yang dulu terkubur dalam PDF bisa muncul kembali dalam summary.

Jadi privacy review harus mempertimbangkan bukan hanya siapa yang membaca halaman, tetapi seberapa mudah informasi dapat diekstrak, diringkas, dan digabungkan.

Mosaic effect penting

Satu data terlihat harmless.

Kota tinggal.

Tanggal lahir.

Nama ibu.

Jabatan.

Foto badge.

Digabungkan, risk meningkat.

Entity page tidak boleh dinilai field per field saja.

Lihat combination.

Mosaic effect adalah kondisi ketika beberapa data terpisah digabungkan menjadi profile yang jauh lebih sensitif.

AI sangat bagus dalam synthesis.

Artinya organization perlu lebih konservatif terhadap kombinasi public data.

Bukan panic.

Risk-aware.

Public data pihak ketiga tidak otomatis aman untuk direpublish

“Kan sudah ada di LinkedIn.”

Bukan otomatis permission.

“Kan ada di directory.”

Belum tentu boleh disalin.

“Kan Google sudah tahu.”

Bukan legal basis.

Organisasi harus menentukan source, purpose, dan rights.

Kalau membuat employee profile, gunakan data yang disetujui melalui corporate process.

Jangan scrape personal social media lalu masukkan ke knowledge graph.

AI Search optimization tidak mengubah etika data collection.

Internal knowledge graph juga perlu privacy tier

Tidak semua internal data boleh menjadi public.

Buat graph class:

Public.

Internal.

Confidential.

Restricted.

Public export hanya mengambil class Public.

Jangan mengandalkan developer mengingat field mana sensitive.

Policy engine.

Access control.

Data classification.

Approval.

Audit.

Graph yang sama bisa melayani website, chatbot internal, dan compliance system, tetapi output masing-masing harus filtered.

Data lineage membantu mencegah leak.

Kalau field berasal dari HR system, default jangan public.

Kalau field berasal dari corporate website, likely public but still review.

Source matters.

Jangan publish credential dan security metadata

API key.

Secret.

Token.

Internal hostname.

Admin email.

Security architecture detail yang tidak intended public.

Backup path.

Cloud bucket.

Private endpoint.

Internal ticket.

Incident contact personal.

AI Search crawler tidak perlu semua itu.

Security through obscurity memang bukan strategy utama, tetapi voluntary overexposure juga bukan best practice.

Entity completeness harus berhenti sebelum operational security.

Apa yang sebaiknya dipublikasikan untuk entity clarity?

Untuk organization:

Legal name.

Brand name.

Official website.

Public address.

Public contact.

Industry.

Product/service.

Leadership role tertentu.

Parent/subsidiary relationship yang public.

Official profiles.

Relevant public identifier.

Current policy.

Untuk person public-facing:

Name.

Role.

Organization.

Professional expertise.

Official profile.

Relevant credential yang intended public.

Public work.

Contact melalui organization.

Itu sering sudah cukup.

Lebih banyak bukan otomatis lebih baik.

Privacy review sebelum publish

Buat checklist.

Apakah data personal?

Apakah diperlukan untuk purpose publik?

Apakah source legitimate?

Apakah subject reasonably expects publication?

Apakah ada legal basis/consent sesuai kebutuhan?

Apakah data sensitif?

Apakah combination menambah risk?

Apakah ada safer alternative?

Apakah contact bisa diganti role-based?

Apakah precise data bisa digeneralisasi?

Apakah retention/publication period perlu dibatasi?

Kalau tim tidak bisa menjawab, stop.

Jangan publish dulu.

Correction dan removal harus tersedia

Entity data bisa berubah.

Orang resign.

Nomor berubah.

Profile tidak lagi relevant.

Consent berubah jika consent adalah basis yang digunakan.

Subject meminta correction.

UU PDP memberikan hak dan kewajiban terkait data pribadi yang perlu dihormati sesuai scope hukum.

Operationally, website perlu:

Correction contact.

Removal workflow.

Owner.

Verification.

Change log.

Propagation check.

Internal graph update.

Search/cache consideration.

Tidak semua downstream system bisa dikontrol.

Tetapi canonical source harus benar.

AI Search seharusnya membuat organisasi lebih disiplin soal privacy, bukan lebih agresif mengumpulkan data

Ada irony.

GEO ingin entity lebih jelas.

Privacy ingin data minimal.

Keduanya tidak harus konflik.

Entity clarity bisa dibangun melalui relationship yang relevan.

Company A owns Brand B.

Person C is CEO of Company A.

Product D belongs to Brand B.

Office E is located in Jakarta.

Tidak perlu mengisi seluruh kehidupan Person C.

Knowledge graph yang bagus bukan graph dengan field terbanyak.

Graph bagus punya relationship yang benar, source, scope, dan permission.

Null yang aman lebih baik daripada data lengkap yang berlebihan.

Pada akhirnya, data yang jangan dipublikasikan adalah data yang tidak punya legitimate public purpose, terlalu sensitif, terlalu granular, atau menciptakan risk yang tidak sebanding dengan manfaat entity clarity.

AI tidak membutuhkan nomor identitas seseorang untuk memahami jabatan mereka.

Search tidak membutuhkan alamat rumah founder untuk memahami perusahaan.

Knowledge graph tidak membutuhkan data keluarga untuk membedakan brand.

Jadi ketika tim berkata:

“Biar AI makin yakin, kita tambah saja datanya,”

jawaban governance harus sederhana:

“Tambah data hanya kalau memang perlu, legal, aman, dan relevan.”

Entity completeness bukan excuse untuk overexposure.

Di era AI synthesis, justru data minimization menjadi semakin penting karena informasi yang tersebar sedikit-sedikit sekarang jauh lebih mudah digabungkan menjadi profile yang sebelumnya tidak pernah kita niatkan untuk membuat.