Enterprise Controls and TrustJuly 13, 2026Flatkey

Daftar Periksa DPA AI Gateway: Pertanyaan Pemrosesan Data untuk Pembeli Model Routing

Daftar periksa DPA AI gateway yang praktis bagi tim pengadaan, keamanan, dan platform saat meninjau model routing, log, retensi, subprocessors, dan akses dukungan.

Daftar periksa DPA AI gateway harus lebih dari sekadar memastikan bahwa vendor memiliki halaman legal. Bagi pembeli model routing, pertanyaan yang sebenarnya adalah apakah perjanjian pemrosesan data yang ditandatangani sesuai dengan jalur yang benar-benar akan digunakan aplikasi Anda: log gateway, penyedia model upstream, akses dukungan, routing regional, kontrol retensi, hak penghapusan, dan pemberitahuan insiden.

Gunakan daftar periksa DPA AI gateway ini sebelum menyetujui lapisan akses model terpadu, DPA gateway LLM, atau perjanjian pemrosesan data API AI. Ini bukan nasihat hukum. Ini adalah daftar bukti praktis untuk tim platform, keamanan, pengadaan, dan legal yang perlu memastikan DPA selaras dengan perilaku routing teknis.

Flatkey cocok untuk tinjauan ini karena situs publik saat ini menempatkan flatkey.ai di sekitar satu API key, base URL yang kompatibel dengan OpenAI di https://router.flatkey.ai/v1, visibilitas penggunaan dan biaya, log permintaan, model routing, dan akses penyedia melalui satu dasbor. Perlakukan halaman produk tersebut sebagai bukti penyaringan yang bersifat sementara. Untuk persetujuan, lampirkan formulir pesanan yang ditandatangani, DPA, pengaturan akun, dan konfirmasi dukungan apa pun yang mengontrol beban kerja Anda yang sebenarnya.

Jika Anda sedang membangun rangkaian kontrol yang lebih luas, padukan tinjauan ini dengan daftar periksa gateway API AI GDPR, daftar periksa gateway API AI enterprise, daftar periksa retensi data API AI, dan harga Flatkey terkini.

Daftar Periksa DPA AI Gateway: Mulailah Dengan Rute

Kesalahan pertama adalah meninjau vendor secara umum. DPA harus cocok dengan rute tertentu. Chatbot dukungan, pengklasifikasi dokumen batch, asisten coding, dan alur kerja media multimodal dapat memiliki kelas data, endpoint, ketentuan penyedia, perilaku penyimpanan, dan akses dukungan yang berbeda.

Sebelum tinjauan legal, bekukan fakta-fakta rute berikut:

Bidang rute	Pertanyaan yang harus dijawab	Bukti yang disimpan
Pemilik beban kerja	Siapa yang memiliki fitur dan data yang dikirim melaluinya?	Pemilik produk, pemilik platform, peninjau keamanan
Lingkungan	Apakah ini pengembangan, staging, produksi, atau spesifik pelanggan?	Konfigurasi rute, nama proyek, tag lingkungan
Jenis endpoint	Apakah panggilan berupa chat, responses, messages, image, video, embeddings, files, atau alur kerja tool?	Endpoint gateway dan endpoint penyedia upstream
Kelas data	Apakah prompt, file, gambar, audio, konten pelanggan, kredensial, atau data terregulasi akan lewat?	Catatan klasifikasi data dan payload contoh yang telah disunting
Jalur penyedia	Penyedia model mana yang dapat menerima permintaan di bawah routing normal dan fallback?	Kebijakan rute, daftar penyedia, urutan fallback
Jalur logging	Sistem mana yang dapat menyimpan metadata permintaan, prompt, output, error, tiket dukungan, atau ekspor?	Pengaturan gateway, dokumen penyedia, konfigurasi observabilitas
Jalur retensi	Apa yang dipertahankan oleh gateway, penyedia upstream, tool dukungan, dan cadangan?	DPA, dokumen privasi, pengaturan retensi, prosedur penghapusan
Ruang lingkup persetujuan	Apa yang disetujui, dan apa yang memerlukan tinjauan baru?	Catatan keputusan dan tanggal kedaluwarsa tinjauan

Daftar periksa DPA AI gateway harus diakhiri dengan catatan persetujuan khusus rute, bukan pernyataan luas bahwa "AI disetujui."

Sepuluh Pertanyaan Pemrosesan Data yang Harus Diajukan Pembeli

Gunakan pertanyaan-pertanyaan ini sebagai daftar periksa DPA vendor AI inti untuk pembelian model routing apa pun.

#	Pertanyaan DPA	Mengapa ini penting untuk model routing	Bukti yang dapat diterima
1	Siapa pengendali, pemroses, dan sub-pemroses untuk setiap rute?	Gateway dapat memproses data secara langsung dan juga meneruskannya ke penyedia model upstream.	DPA yang ditandatangani, daftar subpemroses, peta rute/penyedia
2	Kategori data apa saja yang termasuk dalam cakupan?	"Data API" dapat mencakup prompt, output, file yang diunggah, gambar, log, metadata, data penagihan, dan tiket dukungan.	Jadwal kategori data, contoh payload, pengaturan akun
3	Penyedia mana yang dapat menerima permintaan?	Routing dinamis dan fallback dapat mengubah rantai pemrosesan.	Kebijakan rute, daftar penyedia yang diizinkan, aturan fallback
4	Apakah prompt dan output disimpan?	Log gateway dan log pemantauan penyalahgunaan penyedia dapat memiliki perilaku retensi yang berbeda.	Konfigurasi retensi gateway, kontrol data penyedia, bukti ZDR/MAM jika berlaku
5	Metadata apa yang dipertahankan?	Bahkan jika konten tidak disimpan, metadata dapat mengungkap pengguna, beban kerja, biaya, waktu, IP, atau ID pelanggan.	Skema log, bidang analitik, contoh ekspor penagihan
6	Akses dukungan apa yang diizinkan?	Penyelidikan dukungan dapat mengekspos catatan permintaan, tangkapan layar, log, atau metadata akun.	Kebijakan akses dukungan, catatan transparansi akses, proses redaksi tiket
7	Subpemroses mana yang digunakan?	DPA tidak lengkap jika tidak mengungkap layanan yang memproses data pelanggan.	Daftar subpemroses saat ini dan proses pemberitahuan
8	Proses penghapusan atau pengembalian apa yang tersedia?	Pengadaan perlu mengetahui bagaimana konten yang disimpan, log, file, dan catatan akun dihapus atau diekspor.	SLA penghapusan, langkah API/dashboard, catatan pengecualian backup
9	Di mana data diproses dan disimpan?	Routing regional, region penyedia, tim dukungan, dan log mungkin tidak berada di lokasi yang sama.	Ketentuan residensi data, pengaturan region rute, dokumentasi region penyedia
10	Pemberitahuan insiden dan bukti audit apa yang akan tersedia?	Pembeli membutuhkan linimasa untuk pemberitahuan pelanggaran, komunikasi insiden, dan bukti setelah masalah routing.	Ketentuan pemberitahuan DPA, SLA, kontak keamanan, laporan audit, alur kerja insiden

Jika jawabannya berubah berdasarkan endpoint, fitur, penyedia, atau tingkatan akun, catat pengecualian itu dalam daftar periksa DPA gateway AI alih-alih meratakannya.

Samakan Bahasa DPA Dengan Pemrosesan Teknis

Kontrak pemroses bergaya Pasal 28 berfokus pada objek, durasi, sifat, tujuan, kategori data, hak pengendali, instruksi pemroses, kerahasiaan, keamanan, subpemroses, penghapusan atau pengembalian, dan bantuan untuk hak subjek data. Itu adalah istilah hukum. Pembeli gateway tetap harus menerjemahkannya ke dalam fakta rekayasa.

Gunakan pemetaan ini:

Istilah DPA	Terjemahan teknis untuk AI gateway
Objek	Inferensi model, routing, metering, logging, penagihan, dukungan, dan administrasi akun
Durasi	Berapa lama kontrak berjalan, plus berapa lama log, file, tiket dukungan, dan cadangan tetap tersimpan
Sifat dan tujuan	Meneruskan permintaan ke penyedia model, mengembalikan output, mengukur penggunaan, mendeteksi penyalahgunaan, mendukung insiden
Kategori data pribadi	Konten prompt, konten output, file yang diunggah, pengenal pengguna, alamat IP, metadata akun, kontak penagihan
Instruksi pemroses	Rute yang diizinkan, kelas data yang diblokir, penyedia yang disetujui, komitmen tanpa pelatihan, pengaturan retensi
Subpemroses	Penyedia model upstream, hosting cloud, pembayaran, analitik, dukungan, pemantauan, email, dan vendor keamanan
Tindakan keamanan	Enkripsi, kontrol akses, logging, manajemen kunci, segmentasi, proses kerentanan, bukti audit
Penghapusan atau pengembalian	Penghapusan konten, penghapusan file, kedaluwarsa log, redaksi tiket dukungan, format ekspor, pengecualian backup

Di sinilah banyak tinjauan perjanjian pemrosesan data API AI gagal. DPA mungkin menyatakan bahwa pemroses bertindak atas instruksi, sementara rute produk diam-diam memungkinkan fallback ke beberapa penyedia. Catatan persetujuan harus menyebutkan penyedia mana yang diizinkan, mana yang diblokir, dan siapa yang dapat mengubah kebijakan itu.

Verifikasi Retensi Berdasarkan Endpoint Dan Fitur

Kontrol data penyedia sering kali bersifat spesifik per fitur. Dokumentasi kontrol data platform OpenAI menjelaskan pembatasan pelatihan API, retensi default pemantauan penyalahgunaan, kontrol Zero Data Retention atau Modified Abuse Monitoring yang disetujui, dan perilaku state aplikasi yang spesifik per endpoint. Dokumentasi retensi data API Anthropic memisahkan pemrosesan Claude API dari pemrosesan marketplace cloud dan menjelaskan kelayakan ZDR berdasarkan fitur. Dokumentasi ZDR Gemini Developer API dari Google menjelaskan pembatasan pelatihan untuk layanan berbayar dan kasus tingkat fitur di mana prompt, respons, file, grounding, state, atau perilaku cache mungkin masih penting.

Artinya, "kami punya ZDR" saja tidak cukup untuk DPA gateway LLM. Tanyakan:

Apakah endpoint yang tepat memenuhi syarat untuk kontrol retensi?
Apakah proyek, organisasi, atau akun yang tepat telah disetujui?
Apakah fallback diarahkan ke penyedia atau fitur yang tidak tercakup?
Apakah file, gambar, audio, video, tools, penelusuran web, eksekusi kode, context caching, batch jobs, atau percakapan stateful mengubah retensi?
Apakah log pemantauan penyalahgunaan, state aplikasi, log gateway, catatan dukungan, catatan penagihan, dan cadangan ditangani secara terpisah?

Untuk rute produksi, simpan matriks retensi satu baris:

Sistem	Konten disimpan?	Metadata disimpan?	Periode retensi	Jalur penghapusan	Bukti
Aplikasi	Ya atau tidak	Ya atau tidak	Kebijakan internal	Proses penghapusan aplikasi	Peta data internal
Gateway	Ya atau tidak	Ya atau tidak	Pengaturan akun atau ketentuan vendor	Dasbor/API/dukungan	Bukti gateway
Penyedia A	Ya atau tidak	Ya atau tidak	Kontrol penyedia	Kebijakan penyedia	Dokumen penyedia
Penyedia B fallback	Ya atau tidak	Ya atau tidak	Kontrol penyedia	Kebijakan penyedia	Dokumen penyedia
Alat dukungan	Ya atau tidak	Ya atau tidak	Kebijakan tiket	Redaksi/penghapusan tiket	Bukti dukungan

Daftar periksa DPA AI gateway lengkap hanya ketika setiap salinan yang disimpan memiliki pemilik, alasan, dan jalur penghapusan atau kedaluwarsa.

Tinjau Log Gateway Secara Terpisah Dari Ketentuan Penyedia

Log gateway berguna untuk keandalan, kontrol biaya, debugging, dan peninjauan audit. Log juga merupakan permukaan pemrosesan data yang terpisah. Dokumentasi gateway publik dari penyedia infrastruktur menunjukkan mengapa pembeli harus menanyakannya secara eksplisit: log permintaan dapat mencakup prompt pengguna, respons model, penyedia, stempel waktu, status, penggunaan token, biaya, durasi, dan metadata klien, dan batas log persisten dapat bervariasi حسب paket.

Tanyakan pertanyaan logging berikut sebelum menandatangani:

Apakah gateway dapat menyimpan prompt atau output lengkap, atau hanya metadata?
Apakah logging prompt dan respons dapat dinonaktifkan per rute, lingkungan, workspace, atau pelanggan?
Apakah field sensitif dapat dihilangkan, disamarkan, di-hash, atau dihapus sebelum logging?
Apakah log disalin ke analitik, data warehouse, peringatan, tiket dukungan, atau ekspor?
Siapa yang dapat melihat log, dan apakah setiap akses dicatat?
Apakah log dapat dihapus lebih awal, diekspor untuk audit, atau dikecualikan dari alur kerja dukungan?
Apakah DPA mencakup log sebagai data pelanggan, data sistem, atau keduanya?

Inilah perbedaan antara peninjauan DPA secara hukum dan daftar periksa DPA gateway AI secara operasional. Jika kebijakan keamanan Anda mengatakan prompt tidak boleh disimpan, rute tersebut harus membuktikan bahwa gateway, penyedia, dan jalur dukungan mengikuti aturan yang sama.

Periksa Subprosesor Dan Peralihan Penyedia

Akun penyedia langsung biasanya memiliki satu rantai pemroses utama. Model router dapat memiliki rantai yang lebih besar karena satu rute aplikasi dapat menyentuh gateway, penyedia hulu, alat observabilitas, infrastruktur pembayaran, alat dukungan, dan hosting cloud. Jika fallback diaktifkan, sebuah permintaan dapat dialihkan ke penyedia kedua ketika penyedia pertama gagal.

Paket DPA harus menjawab:

Pertanyaan subprosesor	Apa yang harus diperiksa
Subprosesor saat ini	Apakah ada daftar yang dipublikasikan, dan apakah mencakup hosting, penyedia model, dukungan, analitik, dan vendor penagihan?
Pemberitahuan perubahan	Bagaimana pembeli akan menerima pemberitahuan tentang subprosesor baru?
Hak keberatan	Apakah pembeli dapat keberatan, menghentikan, menonaktifkan rute, atau membatasi penyedia?
Allowlist penyedia	Apakah procurement dapat menyetujui serangkaian penyedia terbatas untuk beban kerja tertentu?
Perilaku fallback	Apakah fallback dapat dinonaktifkan untuk rute sensitif?
Cakupan regional	Apakah subprosesor dan region penyedia selaras dengan persyaratan residensi data pembeli?
Alur ketentuan kontraktual	Apakah komitmen subprosesor mencakup kerahasiaan, keamanan, penghapusan, dan dukungan insiden?

Bagi pembeli Flatkey, gabungkan bukti rute publik dan harga dengan kontrol spesifik akun. Jika rute Anda menggunakan satu key untuk beberapa model, bukti DPA tetap harus menyatakan penyedia hulu mana yang dapat memproses setiap kelas data yang disetujui.

Minta Bukti Dukungan, Insiden, Dan Audit

Akses dukungan mudah terlewatkan karena biasanya terjadi setelah sesuatu rusak. Untuk peninjauan DPA gateway, dukungan adalah bagian dari pemrosesan.

Mintalah:

Kontak dukungan dan jalur eskalasi untuk insiden keamanan atau privasi.
Apakah staf dukungan dapat melihat prompt, output, log, file yang diunggah, tangkapan layar, atau metadata pelanggan.
Apakah akses dukungan dibatasi waktu, disetujui, dan dicatat.
Apakah catatan transparansi akses tersedia untuk akun yang memenuhi syarat.
Bagaimana tiket dukungan dihapus detailnya ketika berisi contoh prompt atau output.
Timeline pemberitahuan insiden mana yang berlaku di bawah DPA, ketentuan, SLA, atau addendum keamanan.
Apakah vendor akan membantu permintaan subjek data, penghapusan, ekspor, dan pertanyaan regulator.

AI Risk Management Framework dari NIST berguna sebagai referensi tata kelola di sini karena mendorong organisasi untuk mengatur, memetakan, mengukur, dan mengelola risiko AI alih-alih menyetujui satu rute lalu melupakannya. Untuk model router, itu berarti peninjauan DPA harus dapat diperbarui. Tetapkan tanggal peninjauan, tunjuk pemilik bukti, dan periksa kembali ketentuan penyedia sebelum perubahan rute besar.

Susun Paket Bukti

Hasil praktisnya adalah paket bukti kecil yang bisa dibaca oleh tim legal, keamanan, pengadaan, dan platform.

Item paket	File atau catatan yang disimpan
Ringkasan rute	Workload, pemilik, endpoint, kelas data, penyedia yang disetujui, perilaku fallback
DPA	Perjanjian pemrosesan data yang ditandatangani dan setiap lampiran keamanan atau regional
Peta data	Alur prompt/output dari aplikasi ke gateway ke penyedia ke log/support
Matriks retensi	Retensi gateway, penyedia, aplikasi, support, penagihan, dan cadangan
Bukti subprosesor	Daftar subprosesor terkini dan proses pemberitahuan perubahan
Kontrol akun	Persetujuan ZDR/MAM, residensi data, pengaturan logging, allowlist rute, pengaturan redaksi
Sampel log	Contoh yang sudah direda kси yang menunjukkan field yang disimpan, bukan rahasia
Alur penghapusan	Cara konten, file, log, tiket, dan catatan akun dihapus atau dikembalikan
Alur insiden	Linimasa pemberitahuan, kontak, eskalasi, dan bukti yang tersedia setelah suatu kejadian
Keputusan persetujuan	Peninjau, pengecualian, tanggal kedaluwarsa, dan pemicu perubahan rute

Untuk Flatkey, tambahkan bukti publik terkini dari beranda, kebijakan privasi, halaman harga, ketentuan, SLA, dan dasbor akun. Halaman publik dapat membantu pembeli menyaring layanan, tetapi bukti yang spesifik untuk akun harus menjadi penentu keputusan akhir.

Tanda Bahaya yang Harus Menghentikan Persetujuan

Hentikan peninjauan rute ketika salah satu hal berikut belum terselesaikan:

DPA menyebut vendor gateway tetapi tidak menyebut jalur penyedia model hulu.
Fallback dapat mengirim data sensitif ke penyedia yang tidak disetujui.
Log prompt atau output diaktifkan, tetapi DPA atau tinjauan keamanan tidak mencakupnya.
Vendor mengatakan "no training" tetapi tidak dapat menjawab retensi, akses support, penghapusan, atau subprosesor.
ZDR dijanjikan secara luas, tetapi endpoint, fitur, atau akun yang dipilih tidak memenuhi syarat.
Tiket support dapat menyertakan prompt mentah tanpa proses redaksi.
Perubahan subprosesor tidak memiliki jalur pemberitahuan.
Routing regional diasumsikan tetapi tidak dibuktikan oleh kontrak, pengaturan akun, atau bukti penggunaan.
Harga, log, dan ekspor penggunaan berisi pengenal pelanggan yang tidak disertakan dalam peta data.
Persetujuan tidak memiliki pemilik atau tanggal peninjauan.

Tanda-tanda bahaya ini tidak selalu berarti vendor tidak dapat digunakan. Artinya, checklist DPA AI gateway belum selesai.

Seperti Apa Persetujuan yang Baik

Catatan persetujuan yang kuat itu singkat dan dapat diuji:

Bidang persetujuan	Contoh redaksi
Ruang lingkup	"Rute triase dukungan produksi, prompt teks saja, tanpa unggahan file, hanya penyedia A dan B yang disetujui."
Kelas data	"Teks dukungan pelanggan setelah redaksi rahasia dan pembayaran pada level aplikasi."
Logging	"Gateway menyimpan metadata saja. Aplikasi menyimpan transkrip yang sudah direda kси selama 30 hari. Retensi penyedia mengikuti kontrol akun yang disetujui."
Pembatasan	"Tidak ada penelusuran web, unggah file, input gambar, unggah batch, atau fallback di luar allowlist."
Bukti	"DPA ditandatangani, daftar subprosesor disimpan, matriks retensi dilampirkan, konfigurasi rute diekspor."
Pembaruan	"Tinjau lagi sebelum menambah penyedia, mengubah keluarga endpoint, mengaktifkan log prompt penuh, atau mengirim data teregulasi."

Format ini membuat DPA menjadi operasional. Developer tahu apa yang boleh mereka routing. Pengadaan tahu apa yang disetujui. Keamanan tahu apa yang harus dipantau. Legal memiliki bukti, bukan janji yang tercecer.

Checklist DPA AI Gateway Final

Sebelum Anda membeli atau memperluas model router, pastikan item berikut:

Checklist DPA AI gateway menyebutkan rute, endpoint, daftar penyedia, kebijakan fallback, dan kelas data yang tepat.
Perjanjian pemrosesan data AI API mencakup prompt, output, file, log, metadata, tiket support, catatan penagihan, dan subprosesor jika berlaku.
Logging gateway dan retensi penyedia ditinjau sebagai sistem yang terpisah.
Klaim ZDR, no-training, atau retensi yang dimodifikasi terkait dengan akun, proyek, endpoint, dan fitur yang tepat.
Peralihan penyedia memiliki allowlist, pemilik, dan pemicu peninjauan.
Penghapusan, ekspor, akses support, pemberitahuan insiden, dan pemberitahuan perubahan subprosesor didokumentasikan.
Halaman vendor publik diperlakukan sebagai bukti penyaringan bertanggal, bukan pengganti DPA yang ditandatangani.
Persetujuan memiliki pemilik, tanggal kedaluwarsa, dan aturan untuk perubahan rute.

Jika tim Anda menginginkan satu API key dan satu dashboard untuk akses multi-model, mulai dengan Flatkey dan simpan checklist DPA AI gateway ini di samping tinjauan rute teknis. Dapatkan key, konfirmasi kontrol akun saat ini, dan setujui setiap rute dengan disiplin yang sama seperti yang Anda gunakan untuk pemroses data produksi lainnya.