Kebijakan redaksi AI API adalah buku pedoman tentang apa yang boleh dikirim tim Anda ke model, apa yang boleh disimpan setelah model merespons, apa yang muncul di log permintaan, dan apa yang dapat dilihat dukungan saat pelanggan membuka tiket. Ini penting karena prompt dan output tidak lagi sekadar input developer yang bersifat sementara. Mereka menjadi catatan debug, bukti audit, tangkapan layar, ekspor, lampiran dukungan, dan materi tinjauan pengadaan.
Versi yang lemah dari kebijakan ini hanya mengatakan "jangan log data sensitif." Itu tidak cukup. Tim membutuhkan keputusan di مستوى field, pemilik, jendela retensi, dan penanganan pengecualian sebelum trafik produksi mencapai gateway model. Kebijakan redaksi AI API yang baik memberi tahu engineering kapan harus memblokir permintaan, security kapan harus menyamarkan data, support kapan harus meredaksi tiket, dan procurement bukti apa yang membuktikan alur kerja terkontrol.
Flatkey berguna dalam pembahasan ini karena situs publik saat ini memposisikan flatkey.ai sebagai satu API key untuk trafik GPT, Claude, Gemini, dan model lain yang resmi, dengan analitik penggunaan, kontrol biaya, dan satu invoice lintas provider. Perlakukan itu sebagai permukaan akses dan tinjauan yang terpadu. Jangan perlakukan itu sebagai pengganti klasifikasi data, tinjauan hukum, kebijakan retensi, atau alur kerja redaksi dukungan Anda sendiri. Sebelum rollout, verifikasi pengaturan akun yang tepat, log, ekspor, perilaku retensi, dan cakupan DPA di akun pembeli Anda sendiri.
Kebijakan Redaksi AI API: Versi Singkat
Kebijakan redaksi AI API seharusnya menjawab lima pertanyaan operasional sebelum sebuah prompt mencapai produksi:
| Pertanyaan | Keputusan kebijakan | Pemilik |
|---|---|---|
| Data apa yang dilarang dalam prompt? | Blokir secret, data pembayaran, kredensial mentah, kunci privat, dan data teregulasi yang tidak didukung sebelum panggilan API | Pemilik security |
| Data apa yang bisa disamarkan dan dikirim? | Ganti pengenal langsung dengan token, hash, label, atau placeholder sintetis ketika kualitas tugas tetap terjaga | Pemilik aplikasi |
| Apa yang disimpan dalam log? | Utamakan log hanya metadata secara default; simpan cuplikan payload hanya untuk kasus debug yang disetujui | Pemilik platform |
| Apa yang dapat dilihat support? | Redaksi prompt pelanggan, output, lampiran, tangkapan layar, dan trace sebelum berbagi tiket | Pemilik support |
| Kapan redaksi boleh diabaikan? | Wajibkan pengecualian bernama, tujuan insiden, batas akses, tanggal retensi, dan persetujuan legal/security | Pemilik tata kelola |
Tujuan praktisnya bukan menghapus setiap detail yang berguna. Tujuannya adalah mempertahankan cukup bukti untuk debug, merekonsiliasi penggunaan, dan mendukung pelanggan tanpa mengubah prompt, output, log, atau tiket menjadi catatan sensitif yang tidak terkontrol.
Mulailah Dengan Peta Data, Bukan Daftar Regex
Redaksi prompt LLM biasanya gagal ketika tim memulai dengan daftar sempit regular expression. Regex membantu menemukan pola yang jelas, tetapi tidak mendefinisikan kebijakan. Mulailah dengan memetakan di mana trafik AI muncul:
| Permukaan catatan | Field umum | Penanganan default |
|---|---|---|
| Isi prompt | Teks pengguna, argumen tool, konteks yang diunggah, dokumen yang diambil, instruksi sistem | Klasifikasikan sebelum dikirim; blokir atau tokenisasi nilai sensitif |
| Output model | Jawaban yang dihasilkan, sitasi, pemanggilan tool, kode, JSON terstruktur | Scan sebelum ditampilkan, disimpan, diekspor, atau disalin ke tiket |
| Metadata gateway | Provider, model, status, latensi, jumlah token, request ID, workspace, lingkungan | Simpan untuk operasi dan penagihan kecuali mengungkap konten sensitif |
| Log payload gateway | Prompt, respons, input/output tool, lampiran, input embedding | Dimatikan secara default atau vault debug dengan retensi singkat |
| Tiket dukungan | Laporan pelanggan, prompt yang disalin, output, tangkapan layar, file HAR, stack trace | Redaksi sebelum dibagikan secara luas; pisahkan bukti insiden dari dukungan rutin |
| Ekspor analitik | Baris biaya, baris penggunaan, label pelanggan/tim, kategori error | Deklasifikasi label saat ekspor keluar dari tim operasional |
Peta ini seharusnya menjadi lampiran kebijakan redaksi AI API Anda. Ini memberi reviewer tempat untuk mengajukan pertanyaan konkret: field mana yang diklasifikasikan, mana yang disamarkan, mana yang disimpan, dan peran mana yang dapat menyetujui pengecualian.
Klasifikasikan Prompt Sebelum Panggilan Model
Kontrol retensi provider memang penting, tetapi itu bukan pengganti kebersihan prompt. Dokumentasi kontrol data API OpenAI saat ini menyatakan bahwa data API tidak digunakan untuk melatih model OpenAI kecuali pelanggan secara eksplisit ikut serta, tetapi juga menjelaskan log pemantauan penyalahgunaan yang dapat berisi prompt, respons, dan metadata turunan dan disimpan hingga 30 hari secara default. Dokumentasi API dan retensi data Anthropic juga membedakan pengaturan penanganan data, zero data retention, dan kasus di mana input dan output yang ditandai untuk keselamatan dapat disimpan.
Artinya kebijakan Anda sebaiknya tidak bergantung pada "provider tidak akan melatih dari data itu" sebagai satu-satunya kontrol. Kebijakan redaksi AI API produksi harus mendefinisikan apa yang tidak pernah melewati batas:
| Jenis data | Tindakan yang direkomendasikan | Contoh pengganti |
|---|---|---|
| API keys, session tokens, OAuth refresh tokens, private keys | Blokir permintaan dan beri tahu pemilik | SECRET_BLOCKED |
| Nomor kartu pembayaran dan detail bank | Blokir kecuali jika ada alur kerja pembayaran yang disetujui dan patuh | PAYMENT_FIELD_REMOVED |
| Kata sandi atau jawaban pemulihan | Blokir dan buat tiket keamanan | CREDENTIAL_REMOVED |
| Pengidentifikasi pribadi langsung yang tidak diperlukan untuk kualitas tugas | Tokenisasi atau generalisasi | CUSTOMER_4821, city_region |
| ID akun yang diperlukan untuk debugging | Hash atau gunakan ID pengganti internal | acct_hash_... |
| Prompt sistem internal dan teks kebijakan tersembunyi | Jangan diekspos ke input pengguna atau tiket dukungan | SYSTEM_CONTEXT_REDACTED |
Klasifier prompt tidak harus sempurna untuk bisa berguna. Ia membutuhkan jalur eskalasi. Jika permintaan berisi kredensial, blokir. Jika berisi data pribadi yang tidak diperlukan model, mask. Jika produk benar-benar membutuhkan nilai sensitif, minta tujuan yang terdokumentasi, rute model yang terbatas, pemilik retensi, dan peninjau.
Bagi tim yang membangun klasifier mereka sendiri, Google Sensitive Data Protection adalah materi referensi resmi yang berguna untuk konsep de-identification dan transformasi redaksi. Gunakan sebagai sumber pola desain, bukan sebagai bukti bahwa gateway tertentu telah mengaktifkan kontrol tersebut.
Pindai Output Sebelum Menjadi Catatan
Privasi output prompt sering terlewat karena tim menganggap jawaban model sebagai artefak tampilan. Dalam praktiknya, output disalin ke tiket, disimpan dalam riwayat chat, disematkan ke analitik, dilampirkan ke laporan bug, dan ditempel ke email pelanggan. Kebijakan output Anda setidaknya harus mencakup empat risiko:
| Risiko output | Kontrol |
|---|---|
| Model mengulang konten prompt sensitif | Pindai teks yang dihasilkan sebelum persistensi dan berbagi ke dukungan |
| Model mengungkap instruksi sistem atau konteks tersembunyi | Deteksi dan blokir pola kebocoran kebijakan/preamble |
| Model mengarang fakta pribadi atau finansial | Wajibkan peninjauan yang sadar sumber sebelum penggunaan yang diatur atau berdampak ke pelanggan |
| Model menyertakan kode tidak aman, secret, atau kredensial | Karantina dan arahkan ke peninjauan keamanan |
OWASP's LLM02 sensitive information disclosure mengategorikan risiko ini sebagai risiko model dan aplikasi yang dapat mencakup data pribadi, detail keuangan, rekam medis, data bisnis rahasia, kredensial, dan dokumen hukum. Ini pengingat yang berguna: kebijakan redaksi AI API bukan hanya penyaringan input. Ini juga inspeksi output, kontrol penyimpanan, dan kontrol alur kerja dukungan.
Untuk alur kerja berisiko tinggi, pisahkan jawaban yang dihasilkan dari prompt mentah. Simpan transkrip yang telah direduksi untuk operasi rutin dan simpan bukti mentah hanya di vault insiden terbatas ketika ada tujuan yang disetujui.
Buat Redaksi Log AI API Berbasis Metadata Dulu
Redaksi log AI API harus dimulai dengan default berbasis metadata dulu. Kebanyakan tim platform membutuhkan request ID, nama model, kode status, latensi, jumlah token, percobaan route, environment, pemilik, dan field biaya. Mereka tidak selalu membutuhkan prompt mentah dan respons mentah.
Dokumentasi logging Cloudflare's AI Gateway adalah contoh yang baik tentang mengapa perbedaannya penting: dokumentasi itu menjelaskan kontrol untuk mengumpulkan log dan mengumpulkan payload log secara terpisah, plus field DLP ketika kebijakan terpicu. Dokumen observability Vercel's AI Gateway menjelaskan logging pengeluaran, penggunaan model, dan metrik observability untuk monitoring dan debugging. Contoh-contoh itu bukan klaim fitur Flatkey. Mereka menunjukkan pola operasional yang harus dievaluasi setiap pembeli gateway: metadata, payload, sinyal DLP, retensi, dan penghapusan adalah keputusan yang terpisah.
Gunakan kebijakan log ini sebagai dasar:
| Field log | Default | Pengecualian |
|---|---|---|
| Request ID, workspace, environment, route, model, provider | Pertahankan | Tidak ada; diperlukan untuk dukungan dan audit |
| Status, kode error, latensi, event retry/fallback | Pertahankan | Tidak ada; diperlukan untuk tinjauan reliabilitas |
| Penggunaan token dan estimasi biaya | Pertahankan | Didentifikasi ulang label pelanggan/tim dalam ekspor keuangan jika diperlukan |
| Isi prompt dan respons | Jangan simpan secara default | Vault debug retensi singkat dengan insiden bernama |
| Argumen tool dan output tool | Redaksi per field; simpan hanya cuplikan yang disetujui | Insiden keamanan atau kasus bug yang dapat direproduksi |
| Kategori kecocokan DLP | Simpan ID kebijakan dan kategori | Hindari menyimpan secret yang cocok itu sendiri |
Kebijakan redaksi AI API juga harus mendefinisikan mekanisme penghapusan. Siapa yang bisa menghapus log? Siapa yang bisa menempatkan legal hold? Apa yang terjadi pada analitik turunan setelah payload mentah dihapus? Jika tim tidak bisa menjawab pertanyaan-pertanyaan itu, logging payload belum siap untuk penggunaan produksi yang luas.
Redaksi Tiket Dukungan Sebelum Menyebar
Tiket dukungan adalah tempat kontrol rekayasa yang cermat sering bocor. Seorang pelanggan menempelkan prompt lengkap ke dalam tiket. Seorang engineer melampirkan trace dengan body request. Sebuah tangkapan layar menyertakan kunci. Sebuah makro dukungan meneruskan utas ke vendor lain. Tiba-tiba rekaman sensitif itu tidak hanya berada di jalur model; ia juga ada di help desk, notifikasi email, ekspor gudang data, dan retrospektif insiden.
Kebijakan redaksi AI API Anda harus memperlakukan dukungan sebagai permukaan yang terpisah:
| Aset dukungan | Peninjauan yang diperlukan |
|---|---|
| Prompt atau output model yang disalin | Redaksikan pengenal, rahasia, dan data yang diatur sebelum visibilitas dukungan yang lebih luas |
| Tangkapan layar | Potong atau blur kunci, email, ID pelanggan, body request, dan prompt tersembunyi |
| Berkas HAR atau trace | Hapus header otorisasi, cookie, payload, dan URL bertanda tangan |
| Lampiran tiket | Redaksikan atau hapus berkas sensitif sebelum eskalasi |
| Eskalasi ke vendor | Bagikan data reproduksi minimum, bukan konten pelanggan mentah |
Dokumentasi API resmi Zendesk mendukung model operasi ini dengan mendokumentasikan redaksi untuk string dalam komentar tiket, plus endpoint terpisah untuk redaksi lampiran komentar. Bahkan jika tim Anda menggunakan help desk yang berbeda, poin kebijakannya sama: redaksi dukungan harus menjadi alur kerja yang bernama, bukan pembersihan ad hoc setelah seseorang menyadari adanya nilai yang bocor.
Tentukan Pengecualian Sebelum Insiden
Setiap kebijakan yang ketat memerlukan jalur pengecualian yang terkontrol. Tanpa itu, tim akan melewati kebijakan secara informal atau menyimpan terlalu sedikit bukti untuk menyelesaikan masalah produksi.
Gunakan catatan pengecualian ini:
| Bidang | Nilai yang diperlukan |
|---|---|
exception_id |
ID unik yang terkait dengan insiden atau investigasi |
business_purpose |
Debugging, tinjauan penipuan, tinjauan keselamatan, legal hold, atau dukungan yang disetujui pelanggan |
data_scope |
Field yang diizinkan secara tepat, bukan "payload penuh" secara default |
access_group |
Orang atau peran yang dinamai dengan akses terbatas waktu |
retention_until |
Tanggal atau peristiwa yang mengakhiri pengecualian |
reviewer |
Keamanan, hukum, privasi, atau pemilik produk |
customer_notice_required |
Ya/tidak dengan alasan |
deletion_or_redaction_task |
Tiket tindak lanjut yang menutup siklus |
Jalur pengecualian harus cukup ketat untuk mencegah akses payload mentah secara sembarangan dan cukup cepat untuk respons insiden. Untuk debugging rutin, gunakan reproduksi sintetis atau fixture yang sudah direduksi terlebih dahulu. Untuk legal hold, pertahankan hanya cakupan yang diwajibkan oleh penasihat hukum. Untuk dukungan pelanggan, mintalah persetujuan sebelum menggunakan konten mentah yang disediakan pelanggan di luar konteks dukungan aslinya.
Tetapkan Kepemilikan di Dalam Kebijakan
Kebijakan tanpa pemilik menjadi shelfware. Tetapkan keputusan berdasarkan permukaan:
| Permukaan | Pemilik utama | Pemilik cadangan | Frekuensi peninjauan |
|---|---|---|---|
| Classifier prompt dan aturan pemblokiran | Rekayasa keamanan | Platform aplikasi | Bulanan dan setelah insiden |
| Pemindai output | Rekayasa produk | Trust and safety | Bulanan |
| Field log gateway | Rekayasa platform | Rekayasa keamanan | Triwulanan |
| Jadwal retensi | Privasi/hukum | Rekayasa keamanan | Triwulanan |
| Alur kerja redaksi dukungan | Operasi dukungan | Operasi keamanan | Bulanan |
| Dek identifikasi ekspor dan analitik | Operasi data/keuangan | Privasi/hukum | Triwulanan |
| Persetujuan pengecualian | Dewan keamanan/privasi | Komandan insiden | Setiap pengecualian |
Tinjau kebijakan redaksi AI API setelah perubahan model besar, modalitas baru, alat dukungan baru, prosesor data baru, dan setiap insiden yang melibatkan paparan prompt atau output. Redaksi bukan proyek regex sekali jadi. Itu adalah kontrol hidup yang mengikuti siklus hidup lalu lintas AI.
Bagaimana Pembeli Flatkey Harus Menggunakan Kebijakan Ini
Jika tim Anda sedang mengevaluasi akses AI API terpadu, gunakan kebijakan ini sebagai daftar periksa pengadaan. Ajukan pertanyaan yang sama apakah lalu lintas melewati akun penyedia langsung, proxy internal, atau gateway terkelola:
- Field request mana yang terlihat dalam log, ekspor, faktur, dashboard, dan alur kerja dukungan?
- Apakah logging payload dapat dinonaktifkan, dibatasi cakupannya, atau dibatasi waktunya?
- Siapa yang dapat melihat prompt dan output mentah?
- Bagaimana tiket dukungan dan lampiran direduksi?
- Pengaturan retensi mana yang bersifat kontraktual, dapat dikonfigurasi, atau hanya praktik operasional?
- Bagaimana penyedia menangani subprosesor, cakupan DPA, legal hold, dan permintaan penghapusan?
- Bukti apa yang dapat diekspor pembeli untuk audit tanpa mengekspor konten pelanggan mentah?
Halaman publik Flatkey saat ini menempatkannya di sekitar satu hal kunci, akses model, analitik penggunaan, kontrol biaya, saldo prabayar, dan satu faktur lintas penyedia. Itu menjadikannya tempat yang relevan untuk memusatkan tinjauan operasional AI API. Pembeli tetap perlu memvalidasi kontrol spesifik akun sebelum memperlakukan gateway apa pun sebagai sistem pencatatan untuk privasi, retensi, atau bukti dukungan. Untuk konteks paket saat ini, model, dan top-up, tinjau harga Flatkey sebelum persetujuan.
Daftar Periksa Implementasi
Gunakan daftar periksa ini sebelum peluncuran produksi pertama:
- Klasifikasikan prompt, output, metadata, log, tiket, tangkapan layar, dan bidang ekspor.
- Blokir rahasia dan kredensial sebelum permintaan AI API.
- Tokenisasi atau generalisasi pengidentifikasi pribadi yang tidak diperlukan untuk kualitas tugas.
- Simpan log metadata sebagai default dan minta persetujuan untuk penangkapan payload mentah.
- Tetapkan jendela retensi singkat untuk payload debug yang disetujui.
- Pindai output sebelum penyimpanan, ekspor analitik, atau berbagi ke dukungan.
- Redaksi tiket dukungan, lampiran, tangkapan layar, dan jejak sebelum eskalasi.
- Dokumentasikan pemilik pengecualian, tanggal retensi, dan tugas penghapusan.
- Verifikasi kontrol data penyedia, ketentuan DPA, cakupan subprocessors, dan pengaturan akun.
- Tinjau kebijakan redaksi AI API setelah insiden, model baru, dan alat dukungan baru.
FAQ
Apa itu kebijakan redaksi AI API?
Kebijakan redaksi AI API mendefinisikan bidang sensitif apa saja yang harus diblokir, disamarkan, di-tokenisasi, dipertahankan, dihapus, atau disetujui di seluruh prompt, output model, log gateway, ekspor, dan tiket dukungan. Ini lebih spesifik daripada pernyataan privasi karena menetapkan penanganan dan penanggung jawab di مستوى bidang.
Apakah zero data retention dari penyedia sudah cukup?
Tidak. Zero data retention atau retensi yang dimodifikasi dapat mengurangi penyimpanan di sisi penyedia, tetapi itu tidak mengklasifikasikan prompt Anda sendiri, membersihkan log Anda, meredaksi tiket dukungan, atau mengatur ekspor. Perlakukan retensi penyedia sebagai satu kontrol di dalam kebijakan redaksi AI API yang lebih luas.
Apakah log AI API harus menyertakan prompt dan output?
Log hanya metadata seharusnya menjadi default untuk sebagian besar lalu lintas produksi. Simpan prompt dan output mentah hanya ketika tujuan debugging atau kepatuhan telah disetujui, akses dibatasi, retensi singkat, dan tugas pembersihan dilacak.
Bagaimana dukungan harus menangani prompt pelanggan?
Dukungan harus meminta reproduksi sekecil mungkin yang diperlukan, meredaksi prompt dan output yang disalin sebelum dibagikan lebih luas, menghapus rahasia dari jejak dan tangkapan layar, serta hanya menyimpan bukti mentah dalam alur kerja insiden atau dukungan yang dibatasi dengan pemilik retensi.
Di mana tim Flatkey harus memulai?
Mulailah dengan tautan internal antara logging payload, retensi data, dan tata kelola gateway: tinjau logging payload AI API, pasangkan dengan daftar periksa retensi data AI API, petakan ke daftar periksa gateway AI API GDPR Anda, lalu dapatkan kunci dan verifikasi pengaturan khusus akun sebelum produksi.
Poin Utama Akhir
Kebijakan redaksi AI API yang tahan lama adalah kebijakan yang dapat dijalankan oleh pengembang, tim dukungan, peninjau privasi, dan pemilik keuangan Anda bersama-sama. Pertahankan metadata yang berguna. Samarkan atau blokir nilai sensitif sebelum menyebar. Simpan payload mentah hanya untuk pengecualian yang disebutkan. Redaksi tiket dukungan sebelum eskalasi. Lalu gunakan surface tinjauan gateway, dokumentasi penyedia terbaru, dan bukti DPA Anda sendiri untuk membuktikan bahwa kebijakan itu bukan hanya tertulis, tetapi juga berjalan.
