Evaluasi transparansi melalui tanda terima bukti, bukan skor

Mulai dengan identitas AI, peran produk, tujuan, dan batasan

Salam, nama karakter, atau suara yang hangat tidaklah cukup sebagai identifikasi. Antarmuka harus terus memperjelas bahwa pengguna sedang berinteraksi dengan sistem yang dihasilkan AI dan menyebutkan peran produk: misalnya, mengatur catatan, menghasilkan pemantik refleksi, atau menyusun opsi draf. Cantumkan tujuan berdampingan dengan batasan dan penggunaan yang tidak didukung secara eksplisit, bukan hanya dalam kebijakan yang tersembunyi jauh. Tanyakan di mana pengungkapan ini muncul selama orientasi (onboarding), obrolan biasa, mode suara, ekspor yang dibagikan, dan setelah pengguna kembali setelah waktu yang lama. Uji negatifnya adalah perintah peralihan peran (role-switching prompt): asisten boleh mengubah nada bicara untuk latihan fiksi, tetapi identitas AI dan operator sebenarnya harus tetap terlihat. Pasal 50 dari EU AI Act menyediakan referensi desain regional untuk memberi tahu orang-orang saat mereka berinteraksi dengan sistem AI tertentu. Penerapannya bersifat kontekstual, jadi gunakan ini sebagai salah satu sumber bukti, bukan sebagai kesimpulan hukum global.

Tuntut tanda terima terbaru untuk cakupan data dan memori

Tautan privasi tidak menunjukkan input mana yang membentuk interaksi ini. Indikator yang dapat digunakan mencantumkan cakupan aktif: pesan saat ini, file terlampir, pengaturan profil, konteks proyek, percakapan terdahulu, sumber terhubung, atau preferensi yang diingat. Indikator ini membedakan data yang digunakan untuk output ini dari data yang dikumpulkan untuk tujuan lain, serta menautkan setiap item ke kontrol peninjauan, koreksi, penonaktifan, atau kedaluwarsa. Cari cakupan yang sama dalam teks, suara, notifikasi, ekspor, dan perangkat yang terhubung. Uji negatifnya dilakukan dengan mengubah satu pengaturan memori, memulai percakapan baru, dan memeriksa apakah cakupan yang ditampilkan dan perilakunya diperbarui bersamaan. Jika labelnya berubah tetapi detail lama masih muncul, catat ketidakcocokan tersebut. Bagian ini tidak mengaudit arsitektur penyimpanan atau penyelesaian penghapusan; panduan transparansi data terpisah menangani tugas-tugas tersebut.

Hubungkan setiap output penting ke sumber, asumsi, dan hal-hal yang tidak diketahui

Pernyataan umum bahwa model mungkin salah terasa lebih lemah daripada penjelasan yang dilampirkan langsung pada output yang penting. Tanda terima harus mengidentifikasi fakta yang diberikan pengguna, sumber yang diambil beserta tanggalnya, pengaturan produk, kesimpulan asisten, konflik yang belum terselesaikan, dan informasi yang tidak dapat diakses oleh sistem. PAIR menyarankan untuk menjelaskan sumber data dan perilaku sistem dengan cara yang membantu orang mengukur tingkat ketergantungan mereka. Nilai keyakinan numerik tidak serta-merta berguna: nilai tersebut memerlukan arti yang jelas, bukti, dan sebuah tindakan. Uji dengan menghapus sebuah sumber, memberikan fakta yang bertentangan, dan membuka kembali respons lama setelah tanggal sumbernya lewat. Antarmuka harus menurunkan tingkat kepastian atau membeberkan ketidakpastian tersebut, alih-alih mempertahankan tingkat kepastian yang sama. Verifikasi fakta yang mendasarinya tetap menjadi alur kerja tersendiri dalam artikel pemeriksaan fakta terkait.

Uji apakah kontrol mengubah perilaku dan menyediakan jalur keluar yang bersih

Kontrol hanya dianggap berfungsi jika cakupan dan efeknya dapat diamati. Seseorang harus dapat mengedit preferensi yang tersimpan, mematikan suatu fitur, mempersempit personalisasi, menjeda notifikasi, mengekspor apa yang dijanjikan antarmuka, dan keluar tanpa asisten mengada-ada tentang kewajiban relasional. Untuk setiap kontrol, catat area yang terpengaruh, waktu efektif, konfirmasi, serta status rollback atau percobaan ulang. PAIR merekomendasikan penjelasan mengenai apa yang diubah oleh masukan pengguna dan kapan, sambil tetap mempertahankan opsi keluar (opt-out) atau rute pengaturan ulang (reset). Jalankan uji negatif dengan menonaktifkan satu sumber input dan memulai sesi yang tidak terkait di perangkat lain. Jika produk masih menggunakan sumber tersebut, atau jika proses keluar memerlukan negosiasi percakapan alih-alih kontrol akun biasa, tanda terima bukti tetap berstatus terbuka. Konfirmasi yang ramah bukanlah bukti bahwa status dasar sistem telah berubah.

Periksa pelaporan kesalahan, tinjauan manusia, banding, dan status penutupan

Tombol laporkan hanyalah awal dari jalur pemulihan (recourse). Antarmuka harus menyatakan apa yang dapat dilaporkan, bukti apa yang dilampirkan, apakah tersedia tinjauan otomatis atau manusia, bagaimana status dapat diperiksa, dan status akhir (terminal states) apa saja yang ada: diperbaiki, ditolak, tidak dapat direproduksi, digantikan, atau masih dalam peninjauan. Antarmuka harus memisahkan koreksi konten dari insiden produk dan mempertahankan versi, pengidentifikasi percakapan, serta hasil yang terlihat oleh pengguna tanpa memaksakan pengungkapan data yang tidak perlu. NIST Core mencakup umpan balik eksternal dan dokumentasi dampak di seluruh siklus hidup. Uji jalur tersebut dengan ketidakcocokan yang tidak berbahaya namun dapat direproduksi, lalu periksa konfirmasi tanda terima, perubahan status, penjelasan, dan cara untuk menyanggah atau menambahkan informasi. Jangan menyimpulkan bahwa keheningan berarti masalah telah selesai, dan jangan menganggap janji dari tim dukungan sebagai bukti sampai status akhir muncul.

Tautkan setiap tanda terima ke versi, tanggal, pemilik, dan riwayat perubahan

Transparansi menjadi tidak berlaku lagi saat produk berubah. Catat versi aplikasi, label model atau fitur saat diungkapkan, tanggal kebijakan atau halaman bantuan, lokal (locale) aktif, jenis perangkat, dan organisasi yang bertanggung jawab atas kontrol tersebut. Kemudian ulangi serangkaian pengujian kecil setelah adanya pembaruan materi: identitas AI, satu cakupan memori, satu output bersumber, satu tindakan keluar (opt-out), dan satu status laporan. NIST Playbook bersifat sukarela dan dirancang untuk penggunaan kontekstual, yang mendukung pemilihan bukti yang relevan dengan pendamping AI yang sebenarnya daripada sekadar meniru daftar periksa umum. Catatan rilis yang berbunyi “peningkatan pengalaman” tidak cukup untuk memetakan perubahan perilaku. Produk harus menandai apa yang berubah, apa yang tetap sama, dan apakah tanda terima yang lebih lama masih berlaku. Simpan tanda terima historis dengan tanggal, alih-alih menimpanya secara diam-diam.

Gunakan tanda terima tujuh baris sebagai syarat rilis (release gate), jangan pernah menjadikannya papan peringkat

Buat tujuh baris: identitas dan peran AI; tujuan dan batasan; cakupan data dan memori; sumber dan ketidakpastian; kontrol dan keluar; kesalahan dan banding; versi dan tanggal. Untuk setiap baris, catat lokasi yang terlihat, tindakan yang diaktifkan, uji negatif, hasil yang diamati, celah yang belum terselesaikan, penanggung jawab, dan tanggal pemeriksaan. Syarat rilis (release gate) meloloskan suatu baris hanya jika bukti ada dan tindakan berperilaku sesuai deskripsi. Cara ini tidak menambahkan poin, merata-ratakan celah yang tidak terkait, atau membandingkan produk secara publik. Rute keluar yang hilang tidak dapat diabaikan hanya karena ada penjelasan yang rapi di bagian lain. Periksa kembali tanda terima pada tugas yang sama setelah pembaruan, dan pertahankan status “tidak diketahui” jika bukti tidak tersedia. Metode ini mengubah transparansi dari sekadar slogan menjadi serangkaian klaim antarmuka yang dapat diuji kesalahannya (falsifiable) tanpa berpura-pura bahwa pengungkapan saja sudah membuktikan kualitas atau kesesuaian produk secara keseluruhan.

Lanjutkan topik ini