Security, Privacy & UU PDP untuk Codex di Perusahaan

Security, Privacy, dan UU PDP untuk Corporate AI Agents

Jawaban singkat

Codex aman dipilotkan di perusahaan hanya bila data flow, akses, network, secrets, input tak tepercaya, approval, logging, retensi, dan respons insiden dibatasi sejak desain. Sandbox membantu, tetapi bukan izin untuk memasukkan semua data. UU PDP dan PP 71/2019 menjadi baseline Indonesia; kebutuhan sektor, dasar pemrosesan, kontrak prosesor, serta keputusan hukum tetap harus diverifikasi oleh fungsi yang berwenang.

Mulai dari aliran data, bukan daftar fitur

Gambar satu run dari awal sampai akhir. Catat sistem sumber, field yang diambil, lokasi snapshot, workspace pemrosesan, model dan connector, log, reviewer, output, eksekusi, arsip, serta penghapusan. Untuk setiap perpindahan, jawab siapa pengendali akses, tujuan pemrosesan, klasifikasi, retensi, dan jalur egress.

Artefak yang tampak biasa dapat sensitif. Workbook payroll memuat identitas dan kompensasi. Ticket IT dapat memuat token yang terlanjur ditempel pengguna. Kontrak berisi rahasia dagang. CRM mengandung kontak. Log command dapat menyalin path, query, atau potongan data. Threat model harus mencakup input, output, telemetry, backup, dan salinan sementara.

Baseline UU PDP dan sistem elektronik

[Konteks resmi Indonesia] UU 27/2022 mengatur pelindungan data pribadi, termasuk hak subjek data dan kewajiban pihak yang memproses data. PP 71/2019 mengatur penyelenggaraan sistem dan transaksi elektronik. UU ITE beserta perubahannya relevan pada konteks dokumen dan transaksi elektronik. Artikel ini bukan opini hukum; tim perlu memeriksa dasar pemrosesan, peran pengendali/prosesor, transfer, retensi, hak subjek, dan kewajiban insiden sesuai kasus serta aturan sektor terbaru.

[Rekomendasi workflow] Untuk workflow HR, payroll, customer, health, finance, monitoring, dan profiling, lakukan assessment mirip DPIA yang proporsional: tujuan, necessity, data minimum, pihak terlibat, risiko terhadap individu, kontrol, residual risk, dan owner penerima risiko. Catat processor register dan kewajiban vendor. Jangan menyebut workflow "patuh UU PDP" hanya karena ada checkbox consent atau redaction.

Threat model Codex

Prompt injection dari dokumen

Invoice, CV, kontrak, issue, email, dan web page tidak boleh dianggap instruksi. File dapat menyisipkan kalimat yang meminta agent membuka secrets, mengubah rules, atau mengirim data. Perlakukan konten sebagai data. Isolasi parser, hilangkan macro dan active content, gunakan allowlisted extraction, tandai provenance, dan larang perubahan privilege berdasarkan isi dokumen.

Akses berlebihan

Agent yang dapat membaca seluruh drive atau data warehouse akan memperbesar blast radius. Gunakan scoped path, view read-only, row/column filter, dan service account per workflow. Pisahkan identity operator, agent, approver, dan execution adapter. Lakukan access review berkala dan cabut akses pilot saat selesai.

Secrets dan credential

Secrets tidak boleh muncul di prompt, repository, output, atau log. Simpan di vault dan inject hanya ke adaptor yang memerlukannya. Agent tidak membutuhkan token bank, sertifikat pajak, private key production, atau password pengguna. Rotasi credential bila terpapar dan anggap log sebagai sumber kebocoran yang harus diuji.

Network dan supply chain

Gunakan deny-by-default egress. Buka domain tertentu, metode tertentu, dan periode tertentu. Catat request keluar. Pin dependency, gunakan lockfile, periksa package baru, serta review connector. Jangan memberi agent kebebasan memasang tool dari internet ketika dokumen tak tepercaya berada di konteks yang sama.

Integrity dan approval bypass

Template, rule, prompt, AGENTS.md, serta scripts harus versioned. Lindungi branch dan butuhkan reviewer untuk konfigurasi kritis. Approval mengikat hash output dan ruleset. Perubahan setelah approval, termasuk regenerasi kecil, membatalkan izin eksekusi.

Workflow aman untuk dokumen tak tepercaya

Dokumen masuk ditempatkan di area karantina. Sistem memindai tipe file, macro, archive, dan active content; membuat salinan pasif; lalu parser terbatas mengambil field allowlist. Classifier menentukan jenis data dan routing. Provenance melekat pada setiap field. Codex hanya menerima teks hasil ekstraksi dan aturan tetap. Ia menghasilkan candidate output tanpa network dan tanpa secrets. Reviewer melihat dokumen asli, hasil ekstraksi, diff, exception, serta test sebelum apa pun diteruskan.

Acceptance checks: hash file asli tersimpan; active content tidak dieksekusi; parser tidak keluar dari container; field di luar allowlist dibuang; tidak ada outbound request; setiap output menunjuk sumber; PII yang tidak dibutuhkan sudah dihapus; review packet lengkap; file sementara terhapus sesuai retensi.

Logging tanpa membuat kebocoran baru

Audit log harus cukup untuk merekonstruksi keputusan, tetapi tidak perlu menyalin seluruh data. Simpan run ID, identitas sumber, checksum, versi model/config, command, status test, diff reference, approver, action, dan reconciliation. Mask token serta field sensitif. Batasi pembaca log, atur retensi, dan uji prosedur deletion.

Pisahkan operational log dari evidence yang wajib dipertahankan. Debug mode yang verbose tidak boleh aktif permanen di produksi. Jika investigasi perlu data tambahan, gunakan approval time-bound dan dokumentasikan alasan. Log juga harus memuat penolakan, override, serta usaha akses yang diblokir.

Respons insiden dan kill switch

Tentukan sinyal penghentian: egress tak dikenal, secret terdeteksi, output menyentuh path terlarang, mismatch hash, lonjakan exception, atau aksi tanpa approval. Kill switch harus menghentikan connector dan service account, bukan sekadar menutup UI. Simpan snapshot forensik sesuai kebijakan tanpa memperluas paparan.

Runbook menyebut siapa incident commander, siapa menangani privacy, legal, vendor, komunikasi, dan recovery. Deklarasi insiden, notifikasi pelanggaran, account disable, containment destruktif, serta risk acceptance adalah keputusan manusia. Setelah insiden, rotasi secrets, perbaiki control, ulangi benchmark, dan minta persetujuan sebelum mengaktifkan kembali.

Checklist sebelum pilot

Pastikan ada owner bisnis dan owner risiko; data-flow map; classification; dasar serta tujuan pemrosesan yang dikaji; source read-only; data dummy atau tersanitasi; access matrix; SSO/MFA; vault; network allowlist; prompt-injection defense; dependency review; retention; redaction log; approval matrix; rollback; incident route; vendor assessment; benchmark kasus lokal; dan jadwal access review.

Hubungkan kontrol ini ke arsitektur Agentic Work System dan human approval matrix. Tim yang akan menjalankan tabletop dapat memakai kerangka pelatihan Codex.

Dasar faktual: apa yang memang dapat dilakukan Codex

[Fakta produk] OpenAI menjelaskan Codex sebagai agen software engineering. Ia dapat menerima tugas, membaca dan mengubah file di lingkungan kerja, menjalankan command, serta memakai hasil test, linter, atau type-check sebagai bukti. Pekerjaannya tetap perlu ditinjau dan divalidasi manusia sebelum perubahan diintegrasikan atau dijalankan. Dokumentasi dan repositori resmi Codex menjadi rujukan yang lebih tepat daripada demo singkat di media sosial.

Dari fakta itu, ada empat kemampuan yang relevan bagi perusahaan. Pertama, Codex bekerja pada artefak, bukan hanya percakapan. Kedua, ia dapat menjalankan langkah berurutan. Ketiga, hasilnya dapat diperiksa dengan alat yang deterministik. Keempat, ia dapat menyerahkan diff dan log agar reviewer tidak menebak apa yang berubah.

[Rekomendasi workflow] Penggunaan untuk finance, HR, legal, procurement, sales, atau operasi bukan fitur kepatuhan siap pakai dari OpenAI. Ini desain implementasi: tim menaruh skrip, template, aturan, data uji, dan instruksi kerja dalam repositori terkontrol; Codex mengolah ekspor read-only atau salinan tersanitasi; sistem resmi tetap menjadi sumber kebenaran. ERP, HRIS, Coretax, portal bank, portal regulator, dan tanda tangan pejabat tidak digantikan.

Pemisahan ini penting. Kemampuan mengedit CSV tidak berarti agent memahami kebijakan akuntansi perusahaan. Kemampuan membuat draft kontrak tidak menjadikannya penasihat hukum. Kemampuan menghasilkan file impor tidak memberinya wewenang untuk mengunggah, menandatangani, membayar, atau mengirim. Kewenangan selalu mengikuti struktur perusahaan, bukan kemampuan teknis model.

Pola kerja yang direkomendasikan

[Rekomendasi workflow] Pola yang aman dimulai dari trigger yang jelas: issue yang telah disetujui, folder masuk, jadwal closing, tiket, atau permintaan dengan pemilik. Sistem mengambil data minimum melalui path, tabel, atau domain yang diizinkan. Input dibekukan sebagai snapshot dan diberi checksum agar reviewer tahu persis bahan yang diproses.

Agent lalu membuat rencana singkat: tujuan, file yang akan disentuh, asumsi, pemeriksaan yang akan dijalankan, approval yang dibutuhkan, dan kondisi berhenti. Setelah itu barulah transformasi dilakukan di branch atau workspace terbatas. Semua template, aturan, dan instruksi seperti AGENTS.md diberi versi. Perubahan terhadap aturan tidak boleh menyelinap bersama hasil operasional.

Tahap verifikasi memakai pemeriksaan yang cocok dengan pekerjaan. Untuk data: schema, jumlah baris, total kontrol, duplikat, referential integrity, dan rekonsiliasi ke source. Untuk dokumen: kelengkapan field, nomor versi, tanggal berlaku, kutipan sumber, link, dan perbandingan dengan template. Untuk kode: unit test, integration test, lint, type-check, security scan, dan CI. Output yang lolos dikemas sebagai review packet berisi diff, exception, bukti test, hal yang belum terjawab, dan instruksi rollback.

Approval diberikan kepada artefak tertentu, bukan kepada instruksi samar. Identitas file, versi input, dan hash output dicatat. Jika isi berubah setelah approval, persetujuan batal dan harus diminta ulang. Eksekusi ke sistem resmi memakai adaptor terpisah dan service account terbatas. Setelah aksi, sistem merekonsiliasi hasil dan menyimpan evidence: siapa menyetujui, kapan, versi apa, hasil apa, serta apakah rollback diperlukan.

Acceptance checks yang layak dipakai

Acceptance check harus dapat menjawab "lulus atau gagal" tanpa bergantung pada rasa percaya kepada agent. Pemeriksaan minimum berikut dapat disesuaikan:

input berasal dari snapshot yang teridentifikasi dan tidak berubah selama run;
hanya path, tabel, command, dan domain allowlist yang diakses;
schema, tipe data, jumlah baris, serta total kontrol cocok dengan sumber;
exception tidak disembunyikan dalam output sukses;
dokumen memakai template dan versi aturan yang berlaku;
setiap klaim faktual memiliki sumber yang dapat dibuka;
seluruh test wajib berstatus lulus dan log mentah tersedia;
diff hanya menyentuh file yang tercantum dalam rencana;
review packet menyebut asumsi, limitasi, dan item yang perlu keputusan;
output yang disetujui mempunyai hash, approver, waktu kedaluwarsa, dan rollback instruction;
aksi pada sistem resmi direkonsiliasi terhadap paket yang disetujui;
data sementara dan log mengikuti jadwal retensi serta penghapusan.

Jangan memakai skor "confidence 95%" sebagai pengganti bukti. Angka tanpa kalibrasi pada kasus lokal tidak membantu approver. Tampilkan sumber, perbedaan, dan exception. Biarkan orang yang berwenang memutuskan.

Tindakan yang tetap di tangan manusia

Ada tindakan yang tidak layak diserahkan kepada agent, sekalipun output awalnya sering benar. Transfer uang, payroll release, perubahan rekening vendor atau pegawai, kredit, dan refund material harus melewati otorisasi manusia. Filing pajak atau regulator, deklarasi kepatuhan, token, sertifikat, serta tanda tangan elektronik juga tetap human-gated.

Kontrak, PO, offer letter, PHK, disiplin, rating kinerja, promosi, dan kompensasi final membutuhkan pejabat yang berwenang. Begitu pula pemilihan vendor, penyelesaian konflik kepentingan, publikasi eksternal, pernyataan media, production deploy, privileged command, account disable, tindakan containment destruktif, opini hukum, penerimaan risiko, opini audit, dan keputusan berdampak pada individu berdasarkan profiling.

Atur maker-checker secara nyata. Agent tidak boleh menjadi maker sekaligus checker hanya karena dua prompt dijalankan terpisah. Approver harus berbeda dari pemilik konfigurasi agent untuk aksi berisiko tinggi. Approval memiliki batas nilai, ruang lingkup, dan waktu. Sediakan kill switch serta jalur manual bila sistem gagal.

Security dan privasi minimum

Data perusahaan tidak otomatis aman hanya karena workflow berada di balik login. Petakan alirannya: dari mana input berasal, data apa yang ikut, di mana diproses, siapa yang dapat membaca log, berapa lama disimpan, dan ke mana output dikirim. Klasifikasikan data sebelum memilih tool. Terapkan purpose limitation, minimization, redaction atau tokenization, dan larang secrets masuk ke prompt, file kerja, screenshot, maupun log.

Gunakan SSO dan MFA bila tersedia, least privilege, service account terpisah, vault untuk secrets, serta elevasi berbatas waktu. Sandbox adalah default. Hak tulis dibatasi ke workspace yang memang dibutuhkan. Network deny-by-default lalu buka domain yang disetujui. Catat egress. Jangan menaruh credential produksi di lingkungan agent.

Dokumen, email, issue, dan halaman web adalah input tak tepercaya. Isinya dapat memuat instruksi yang mencoba mengubah perilaku agent. Pisahkan konten dari instruksi sistem, hilangkan active content, batasi ekstraksi, tandai provenance, dan minta review sebelum konten memicu aksi. Pin dependency, pindai package, tinjau connector pihak ketiga, dan gunakan branch terproteksi untuk konfigurasi penting.

[Konteks resmi Indonesia] UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur pemrosesan data pribadi, hak subjek data, kewajiban pengendali dan prosesor, perlindungan, serta penanganan pelanggaran. PP Nomor 71 Tahun 2019 memberi baseline penyelenggaraan sistem dan transaksi elektronik. Implementasi konkret tetap perlu diperiksa terhadap aturan pelaksana dan regulator sektor. Untuk HR, payroll, pelanggan, kesehatan, keuangan, monitoring, atau profiling, lakukan pemetaan data dan penilaian dampak yang proporsional sebelum pilot.

Cara menjalankan review mingguan

Tinjau sepuluh run secara acak dan seluruh run yang gagal. Bandingkan input, output, diff, serta keputusan reviewer. Kelompokkan kegagalan menjadi masalah data, aturan, tool, akses, atau judgment. Jangan langsung memperbaiki prompt bila sumbernya adalah master data yang buruk atau SOP yang bertentangan. Tetapkan owner dan tanggal perbaikan.

Periksa juga perilaku reviewer. Approval yang selalu lolos dalam hitungan detik adalah sinyal kontrol semu. Gunakan calibration case: dua reviewer menilai paket yang sama, lalu membahas perbedaan. Hasilnya dapat dipakai untuk memperjelas acceptance criteria dan escalation path.

Sumber primer

Regulasi dan dokumentasi produk dapat berubah. Periksa versi terbaru serta aturan sektor sebelum implementasi.

Langkah berikutnya

Jika tim Anda ingin mengubah satu use case menjadi workflow yang dapat diuji, direview, dan dihentikan dengan aman, diskusikan Pelatihan AI untuk Perusahaan. Fokus awalnya bukan demo sebanyak mungkin, melainkan satu pilot yang punya owner, acceptance checks, approval, dan evidence yang jelas.

Tags: #Codex Security #UU PDP #Privacy #AI Governance #Cybersecurity

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital