Mencatat kerja agent AI tanpa menyalin rahasia pelanggan

2026-10-23 · Agus Ramdan

Agent AI gagal menyelesaikan permintaan pelanggan. Tim membuka log untuk mencari penyebabnya, lalu menemukan seluruh percakapan, alamat pengiriman, dan isi dokumen ikut tersimpan. Masalah awalnya mungkin hanya sambungan yang terputus. Sekarang tim juga harus memikirkan siapa yang bisa membaca salinan data tersebut.

Itu contoh hipotetis, tetapi keputusan desainnya dekat dengan pekerjaan sehari-hari: supaya mudah diperiksa, aplikasi mencatat semuanya. Kebiasaan ini terasa membantu ketika pengujian masih memakai data contoh. Begitu agent menangani pelanggan sungguhan, log dapat menjadi tempat penyimpanan kedua yang luput dari perhatian.

Saya lebih memilih catatan yang menjawab apa yang terjadi, tanpa otomatis menyimpan seluruh bahan yang dibaca agent. Tim tetap membutuhkan bukti untuk mengusut kegagalan. Bukti itu perlu dipilih, bukan ditumpuk.

Log adalah tujuan pengiriman data juga

Data pelanggan biasanya diperiksa saat masuk ke aplikasi dan saat dikirim ke penyedia model. Perjalanan ke sistem pemantauan sering dianggap urusan teknis belaka. Padahal, menyalin respons alat ke log berarti mengirim data ke tempat lain, lengkap dengan aturan akses dan masa simpannya sendiri.

Dokumentasi OpenTelemetry tentang penanganan data sensitif mengingatkan bahwa pengumpulan telemetri dapat menangkap informasi pribadi atau sensitif secara tidak sengaja. Implementer bertanggung jawab memahami data yang dikumpulkan, termasuk yang dikeluarkan pustaka instrumentasi. Perangkat observability tidak dapat menentukan sendiri informasi mana yang sensitif dalam konteks bisnis kita.

Pada usaha jasa, catatan konsultasi bisa sensitif. Pada toko, gabungan nama, nomor kontak, dan riwayat pesanan juga perlu dilindungi. Jangan menilai hanya satu kolom. Beberapa atribut yang tampak biasa dapat mengungkap identitas ketika disatukan.

Tentukan pertanyaan sebelum menentukan kolom

Mulailah dari pertanyaan operasional yang benar-benar perlu dijawab. Apakah agent berhenti karena alat tidak tersedia? Apakah aplikasi menolak suatu tindakan? Apakah hasil sudah dikirim atau masih menunggu persetujuan?

Untuk pertanyaan itu, tim biasanya bisa memakai jenis tindakan, waktu kejadian, hasil pemeriksaan izin, kategori kegagalan, dan durasi. Mencatat kategori “akses ditolak” sering lebih berguna daripada menyalin dokumen yang ditolak. Mengetahui alat pencarian gagal merespons tidak selalu memerlukan seluruh permintaan pelanggan.

Ini rekomendasi desain, bukan skema wajib dari OpenTelemetry. Bentuk catatan harus mengikuti kebutuhan aplikasi. Jika suatu atribut tidak membantu investigasi, evaluasi layanan, atau kewajiban yang sudah ditetapkan, tanyakan mengapa atribut itu masih dikumpulkan.

OpenTelemetry menyebut pendekatan tersebut sebagai minimisasi data: kumpulkan yang punya tujuan observability, hindari informasi pribadi yang tidak diperlukan, dan tinjau kembali atribut secara berkala. Lebih mudah mencegah salinan terbentuk daripada membersihkan salinan yang sudah tersebar.

Pisahkan catatan proses dari isi percakapan

Bayangkan agent membantu permintaan retur. Catatan proses cukup menunjukkan bahwa agent membaca kebijakan retur, memeriksa kelayakan, lalu menyerahkan keputusan kepada petugas. Tim bisa menambahkan kategori alasan penyerahan, misalnya bukti pembelian belum lengkap.

Isi keluhan pelanggan, foto dokumen, dan alamat tidak otomatis perlu berada dalam catatan proses tersebut. Jika petugas perlu membacanya, arahkan pemeriksaan ke aplikasi sumber yang menerapkan otorisasi. Jangan membuat setiap orang yang bisa melihat dashboard teknis ikut mendapat akses ke seluruh bahan kasus.

Pemisahan ini tidak berarti catatan harus kehilangan keterkaitan. Aplikasi dapat memakai referensi terbatas yang menghubungkan kejadian dengan kasus di sistem sumber. Namun, referensi itu juga perlu ditinjau: apakah bisa ditebak, membuka akses tanpa pemeriksaan, atau menghubungkan seseorang dengan informasi sensitif?

Contoh ini merupakan usulan alur kerja, bukan laporan implementasi tertentu. Prinsipnya adalah menjaga kegunaan catatan tanpa menjadikannya arsip percakapan bayangan.

Jangan mengandalkan pesan kepada model

Instruksi seperti “jangan tampilkan data pribadi” tetap berguna, tetapi tidak cukup untuk mengendalikan pencatatan. Middleware dapat merekam permintaan sebelum model menerimanya. Pustaka instrumentasi dapat mencatat respons alat setelah model selesai. Model mungkin sama sekali tidak mengendalikan kedua jalur tersebut.

OWASP LLM02:2025 membahas risiko pengungkapan informasi sensitif dalam aplikasi LLM. Panduan itu mencakup sanitasi data dan pembatasan akses sesuai kebutuhan. OWASP juga mengingatkan bahwa batasan dalam system prompt tidak selalu dipatuhi dan dapat dilewati. Karena itu, jangan menjadikan prompt sebagai satu-satunya perlindungan.

Tempatkan keputusan pencatatan pada kode dan konfigurasi yang bisa diperiksa. Gunakan daftar atribut yang diizinkan sebagai titik awal, lalu tangani bidang bebas dengan hati-hati. Menambahkan satu kolom “detail kesalahan” yang menerima teks apa pun bisa membatalkan banyak pembatasan di tempat lain.

Penyaringan membantu, tetapi punya batas

OpenTelemetry mendokumentasikan beberapa pilihan pengolahan: menghapus atau mengubah atribut tertentu, menyaring span atau metrik, menerapkan daftar atribut yang diizinkan, serta mentransformasikan data. Pilihan itu berguna ketika instrumentasi sudah menghasilkan atribut yang tidak diperlukan.

Tetap utamakan pencegahan di sumber. Penyaringan setelah pengumpulan bukan alasan untuk mengirim semua isi percakapan terlebih dahulu. Periksa jalur sebenarnya: apakah data mentah sempat ditulis ke penyimpanan lokal, dikirim ke tujuan lain, atau tercetak ketika proses gagal?

Hash juga bukan jaminan anonimitas. OpenTelemetry memperingatkan bahwa nilai asal yang kecil dan mudah diprediksi, seperti identitas numerik, dapat ditebak kembali lewat pencocokan hash. Mengganti nama kolom menjadi “anonim” tidak mengubah sifat risikonya. Pilih penghapusan, pengelompokan, atau bentuk referensi lain berdasarkan kebutuhan dan ancaman yang dihadapi.

Uji dengan data sintetis yang sengaja mudah dikenali

Sebelum memakai data pelanggan, buat kasus uji dengan nama dan alamat rekaan yang jelas. Jalankan permintaan berhasil, kegagalan alat, penolakan izin, dan proses yang terhenti. Setelah itu, cari penanda rekaan tadi di setiap tujuan pencatatan yang diketahui.

Periksa lebih dari dashboard utama. Pesan kesalahan aplikasi, ekspor laporan, dan berkas debug bisa menyimpan data yang tidak muncul di tampilan biasa. Uji pula batas panjang: teks yang dipotong tetap bisa memuat informasi pribadi pada bagian awalnya.

Catat hasil pengujian beserta cakupannya. Jika tim baru memeriksa satu penyimpanan, tulis demikian. Klaim “tidak ada kebocoran” terlalu luas bila jalur lain belum diperiksa. Pengujian ini mencari bukti perilaku pencatatan, bukan memberikan jaminan kepatuhan menyeluruh.

Atur siapa yang membaca dan kapan data dihapus

Catatan yang sudah diminimalkan masih perlu pengendalian akses. Petugas layanan, pengembang, dan pengelola keamanan mungkin membutuhkan tampilan berbeda. Akses untuk menilai jumlah kegagalan tidak otomatis memerlukan akses ke rincian setiap kasus.

Tentukan masa simpan berdasarkan tujuan dan kewajiban yang berlaku, bukan karena penyimpanan masih murah. Pastikan penghapusan juga dipikirkan untuk ekspor dan salinan pendukung. Tidak ada satu durasi yang tepat bagi semua bisnis; kebutuhannya harus dinilai dalam konteks masing-masing.

Untuk memulai minggu ini, pilih satu alur agent yang sudah dipakai. Daftar seluruh tujuan pencatatannya, bandingkan atribut dengan pertanyaan investigasi, lalu hapus pengumpulan yang tidak diperlukan. Jalankan kembali kasus uji sintetis sebelum memperluas perubahan. Tim akan memperoleh catatan yang lebih mudah diperiksa sekaligus mengurangi jumlah salinan data pelanggan yang harus dijaga.

Sumber