Workflow persetujuan model AI adalah gerbang rilis yang menentukan apakah suatu rute model diizinkan untuk menangani traffic produksi. Rute bukan hanya nama model. Ia mencakup provider, keluarga endpoint, versi prompt, izin tool, perilaku fallback, pengaturan logging, guardrail biaya, pemilik, dan jalur rollback yang akan berjalan di balik sebuah fitur produk.
Itulah mengapa persetujuan harus dilakukan sebelum rute baru live. Sebuah model bisa terlihat aman dalam demo tetapi tetap gagal di produksi karena versi prompt yang salah dikirim, fallback mengarahkan traffic ke provider yang belum ditinjau, panggilan tool diberi otoritas terlalu besar, pengaturan logging menyimpan payload lebih lama dari yang diharapkan, atau finance tidak bisa merekonsiliasi pengeluaran setelah rollout.
Gunakan workflow persetujuan model AI ini untuk mengubah perubahan model menjadi file bukti yang dimiliki pembeli. Outputnya harus cukup jelas agar engineering, security, procurement, finance, dan product dapat menjawab pertanyaan yang sama nanti: apa yang disetujui, mengapa disetujui, bukti apa yang ditinjau, dan pemicu apa yang memerlukan peninjauan ulang?
Bagi pembeli Flatkey, peninjauan ini sebaiknya dilakukan di sekitar gateway route. Situs publik Flatkey saat ini memposisikan produk sebagai satu AI API gateway untuk akses model, routing, billing, analitik penggunaan, dan kontrol operasional, dengan satu API key, satu base URL, dan satu dashboard. Itu menjadikan gateway sebagai tempat yang berguna untuk memusatkan bukti rute. Namun hal ini tidak menghilangkan kebutuhan untuk memverifikasi logging yang spesifik per akun, ketentuan provider, perilaku model, penanganan data, dan tanggung jawab persetujuan sebelum peluncuran produksi.
Apa yang disetujui oleh workflow
Workflow persetujuan model AI harus menyetujui sebuah rute, bukan slogan vendor. Catatan persetujuan harus mengidentifikasi perilaku produksi yang tepat yang akan ada setelah rilis.
| Permukaan rute | Pertanyaan persetujuan | Bukti yang disimpan | Penghambat rilis |
|---|---|---|---|
| Use case | Tugas pengguna atau sistem apa yang akan dilakukan rute ini? | Ringkasan produk, klasifikasi data, dampak ke pengguna, kasus penyalahgunaan | Tugasnya samar atau kepemilikannya tidak jelas |
| Model dan provider | Model, provider, endpoint, region, dan jalur akun mana yang akan melayani traffic? | Dokumen provider, status model/versi, konfigurasi rute, daftar fallback | Fallback dapat memilih model yang belum disetujui |
| Prompt dan kebijakan tool | Instruksi, tool, skema, dan izin apa yang diizinkan? | Versi prompt, manifest tool, skema bertipe, tinjauan kode | Tool dapat mengambil tindakan yang tidak dapat dibatalkan tanpa kontrol |
| Paket evaluasi | Pengujian apa yang membuktikan rute cukup baik untuk use case ini? | Dataset eval, metrik, ambang batas, catatan peninjau, contoh kegagalan | Tidak ada ambang lulus/gagal yang spesifik untuk tugas |
| Kontrol keamanan dan penyalahgunaan | Bagaimana prompt injection, output tidak aman, kebocoran data, dan bypass kebijakan ditangani? | Kasus red-team, pengaturan filter, pengujian penolakan, alert pemantauan | Kegagalan yang diketahui tidak punya mitigasi atau pemilik |
| Data dan logging | Prompt, output, metadata, trace, dan baris billing mana yang disimpan? | Peta aliran data, sampel log, kelas retensi, uji redaksi | Penyimpanan payload mentah tidak jelas atau tidak terbatas |
| Biaya dan kapasitas | Pengeluaran, kuota, rate limit, timeout, dan perilaku fallback apa yang diizinkan? | Batas anggaran, sampel penggunaan, uji beban, pemilik finance | Mode kegagalan dapat menimbulkan pengeluaran tak terkendali |
| Rollout dan rollback | Bagaimana traffic akan dimulai, diperluas, dijeda, dan dikembalikan? | Feature flag, rencana canary, perintah rollback, kontak insiden | Rollback bergantung pada tebakan manual |
| Pemicu pembaruan | Perubahan apa yang memaksa persetujuan ulang? | Tanggal review, pemantauan deprecation model, kebijakan perubahan rute | Tidak ada yang bertanggung jawab atas drift setelah peluncuran |
Poin utamanya: persetujuan bukan rapat. Persetujuan adalah paket bukti plus kontrol rute.
Gunakan kerangka siklus hidup, bukan checklist sekali pakai
AI Risk Management Framework dari NIST adalah kerangka yang praktis karena mengatur pekerjaan di sekitar Govern, Map, Measure, dan Manage. Itu selaras dengan workflow persetujuan model AI:
| Fungsi AI RMF | Terjemahan untuk persetujuan rute |
|---|---|
| Govern | Tetapkan pemilik rute, pemilik risiko, pemilik finance, peninjau security, kebijakan persetujuan, dan aturan penghentian penggunaan |
| Map | Jelaskan use case, pengguna, data, provider hulu, batas model, dependensi rute, dan dampak bisnis |
| Measure | Jalankan evaluasi fungsional, pengujian adversarial, pemeriksaan keamanan, uji biaya, uji latensi, dan pemeriksaan observabilitas |
| Manage | Setujui, luncurkan, pantau, jeda, perbarui, atau hentikan rute berdasarkan bukti |
Generative AI Profile dari NIST juga penting karena sistem generatif menimbulkan risiko yang sering terlewat dalam review perubahan API biasa: prompt injection, halusinasi, paparan data, perluasan kemampuan yang tidak aman, drift model, dan penyalahgunaan downstream. Perlakukan kerangka ini sebagai cara untuk menstrukturkan keputusan, bukan pengganti bukti Anda sendiri.
Checklist workflow persetujuan model AI
Gunakan checklist ini untuk setiap rute model baru, perubahan prompt yang material, perubahan izin tool, fallback provider, atau migrasi endpoint.
- Tentukan rutenya.
Catat route ID, owner, fitur produk, environment, keluarga endpoint, model utama, model fallback yang diizinkan, akun provider, versi prompt, manifest tool, kelas data, dan pola traffic yang diharapkan.
- Klasifikasikan use case.
Tentukan apakah rute tersebut menyentuh data pelanggan, data karyawan, alur kerja yang diatur, keputusan keuangan, keputusan dukungan, tinjauan hukum, eksekusi kode, tindakan eksternal, atau konten yang sensitif terhadap keselamatan. Rute ringkasan dan agen pengembalian dana otonom tidak boleh memiliki tingkat persetujuan yang sama.
- Kumpulkan bukti model dan penyedia.
Simpan dokumentasi model dari penyedia, model card atau system card jika tersedia, status deprecation, dokumentasi penyaringan konten, ketentuan penanganan data, batasan regional, dan pengaturan di tingkat akun. Panduan versi model dari Google mengingatkan untuk menangkap apakah sebuah model bersifat stable, preview, experimental, deprecated, atau retired. Jangan menyetujui hanya berdasarkan nama tampilan yang ramah.
- Versikan prompt dan alat.
Panduan prompt dari OpenAI merekomendasikan prompt produksi yang dikelola lewat kode, input bertipe, code review, pengujian, cek evaluasi, dan rollout bertahap. Itulah pola yang tepat untuk workflow persetujuan model AI milik pembeli: perilaku prompt harus berada dalam proses rilis yang sama dengan perilaku kode.
- Bangun evaluasi spesifik tugas.
praktik terbaik evaluasi dari OpenAI memposisikan eval sebagai pengujian terstruktur untuk akurasi, performa, dan keandalan dalam sistem AI yang bervariasi. Persetujuan harus mensyaratkan paket eval khusus tugas, bukan hanya tangkapan layar benchmark generik. Sertakan kasus umum, kasus ekstrem, kasus adversarial, kasus multibahasa, kasus alat, dan contoh kegagalan yang diketahui.
- Jalankan pengujian keamanan dan penyalahgunaan.
Panduan LLM01 prompt injection dari OWASP memisahkan injeksi prompt langsung dan tidak langsung. Tambahkan pengujian untuk keduanya. Jika rute dapat memanggil alat, mengambil dokumen, menulis catatan, mengirim pesan, atau menjalankan kode, uji otoritas berlebihan, manipulasi argumen alat, konflik system prompt, dan instruksi tersembunyi dalam konten yang diambil.
- Verifikasi retensi data dan logging.
Tentukan apakah prompt, output, argumen alat, file, potongan yang diambil, trace, metadata permintaan, event audit, dan baris penagihan disimpan. Gunakan checklist retensi data AI API untuk memisahkan konten payload dari metadata, dan gunakan audit log untuk penggunaan AI API untuk membuktikan siapa yang mengubah kunci, rute, logging, kuota, dan kebijakan model.
- Tetapkan batas biaya, keandalan, dan fallback.
Catat anggaran token, anggaran permintaan, batas kuota, strategi timeout, kebijakan retry, daftar model fallback, circuit breaker, dan ambang peringatan. Fallback yang diam-diam memindahkan traffic ke model yang lebih kuat, lebih mahal, atau kurang ditinjau adalah kegagalan tata kelola meskipun pengalaman pengguna tampak baik.
- Setujui rollout bertahap dan pembaruan.
Rilis melalui canary, feature flag, bobot rute, atau allowlist tenant. Tetapkan pemeriksaan jam pertama, pemeriksaan hari pertama, pemeriksaan minggu pertama, dan pemicu pembaruan. Lakukan persetujuan ulang saat versi model berubah, ketentuan penyedia berubah, perilaku prompt berubah, izin alat berubah, logging berubah, profil biaya berubah, atau populasi pengguna berubah.
Bangun paket persetujuan
Workflow persetujuan model AI yang paling kuat meninggalkan paket persetujuan yang ringkas. Paket ini harus cukup singkat untuk ditinjau, tetapi cukup spesifik untuk diaudit.
| Field paket | Jawaban yang diperlukan | Artefak bukti | Pemicu pembaruan |
|---|---|---|---|
| Route ID | ID stabil untuk rute produksi ini | Konfigurasi rute gateway atau permintaan perubahan | Penggantian nama rute, penggabungan, atau pemisahan |
| Business owner | Siapa yang menerima risiko produk? | Catatan persetujuan | Perubahan pemilik |
| Technical owner | Siapa yang bisa menjeda atau melakukan rollback? | Dokumen on-call, runbook | Perubahan tim atau on-call |
| Data class | Data apa yang boleh masuk ke prompt, tools, file, dan retrieval? | Peta aliran data, kelas payload sampel | Sumber data baru atau segmen pelanggan baru |
| Model list | Model utama, model cadangan, keluarga endpoint, akun provider | Dokumen model/versi, pembacaan ulang rute | Model, cadangan, endpoint, atau provider baru |
| Prompt version | Prompt builder saat ini, skema, dan sumber instruksi sistem | Commit Git atau konfigurasi yang ditinjau | Perubahan prompt, skema, atau tool |
| Eval pack | Dataset, metrik, ambang batas, kegagalan, persetujuan peninjau | Laporan evaluasi | Perubahan model, prompt, data, atau distribusi pengguna |
| Safety controls | Filter konten, kebijakan penolakan, uji prompt injection, eskalasi ke manusia | Laporan pengujian dan pengaturan filter | Perubahan filter, kebijakan, atau klasifikasi risiko |
| Tool controls | Tool yang diizinkan, scope, argumen, persyaratan persetujuan | Manifest tool dan pengujian izin | Perubahan izin tool atau side effect |
| Logs and retention | Field metadata, kebijakan payload, kelas retensi, perilaku redaksi | Sampel log dan pembacaan ulang retensi | Perubahan ekspor, observabilitas, atau retensi |
| Cost controls | Anggaran, kuota, rate limit, peringatan, pemilik faktur | Sampel penggunaan dan ambang biaya | Perubahan harga, traffic, atau komposisi model |
| Rollout plan | Ukuran canary, metode rollback, kondisi penghentian | Flag fitur atau catatan bobot rute | Perluasan kohort rollout |
| Post-live monitoring | Metrik, alert, frekuensi peninjauan, jalur insiden | Tangkapan layar dashboard atau pembacaan ulang API | Alert terlewat, insiden, atau drift |
Paket ini juga merupakan aset procurement. Ini membuat peninjauan vendor menjadi konkret: alih-alih menanyakan apakah vendor sudah "enterprise ready," pembeli menanyakan bukti apa yang menunjukkan rute ini siap.
Pengujian pra-produksi sebelum suatu rute diluncurkan
Set pengujian harus sesuai dengan use case yang telah disetujui. Rute yang hanya memberi label pada tiket dukungan membutuhkan pengujian yang berbeda dari rute yang menulis SQL, menerbitkan refund, mengedit kode, atau meringkas catatan medis.
| Lintasan pengujian | Apa yang diuji | Bukti yang disimpan | Kondisi berhenti |
|---|---|---|---|
| Functional correctness | Output yang diharapkan pada tugas normal | Skor evaluasi, contoh kegagalan, catatan peninjau | Tingkat kelulusan di bawah ambang batas |
| Instruction hierarchy | Prompt sistem vs prompt pengguna yang bertentangan | Kasus adversarial | Prompt pengguna menimpa kebijakan sistem |
| Prompt injection | Injection langsung dan tidak langsung dalam teks pengguna, dokumen yang diambil, file, dan output tool | Transkrip red-team | Instruksi tersembunyi mengubah tugas |
| Tool authority | Pemilihan tool, ekstraksi argumen, scope, dan side effect | Log pemanggilan tool dan kasus penolakan | Tool dapat melakukan tindakan yang tidak disetujui |
| Data leakage | Eksposur rahasia, data pribadi, pengenal pelanggan, dan konteks yang diambil | Fixture test | Fixture sensitif muncul di output atau log |
| Content filtering | Kategori kebijakan input/output dan ambang tingkat keparahan | Konfigurasi filter dan kasus yang diblokir | Kategori yang diperlukan tidak dipantau atau diblokir |
| Cost and quota | Anggaran token, rate limit, pengeluaran fallback, lonjakan penyalahgunaan | Baris penggunaan dan pengujian alert | Pengeluaran dapat meningkat tanpa alert pemilik |
| Reliability | Timeout, retry, streaming, fallback, gangguan provider, circuit breaker | Drill kegagalan | Traffic pengguna terus melakukan retry ke kegagalan |
| Auditability | Perubahan kunci, perubahan rute, perubahan prompt, akses log, perubahan kuota | Sampel event audit | Perubahan tidak dapat ditautkan ke pelaku dan waktu |
| Rollback | Menonaktifkan rute, mengembalikan prompt, menghapus fallback, memulihkan model sebelumnya | Drill rollback | Rollback tidak dapat diselesaikan dengan cepat |
Dokumen penyaringan konten Azure OpenAI dari Microsoft berguna sebagai pengingat bahwa filter memiliki kategori, tingkat keparahan, pilihan konfigurasi, dan perilaku opsional. Catatan persetujuan Anda harus menangkap pengaturan aktual yang digunakan untuk rute tersebut, bukan hanya keberadaan fitur keamanan di suatu tempat dalam stack.
Contoh kebijakan rute
Persetujuan harus menghasilkan kebijakan rute yang dapat diimplementasikan oleh engineer dan diperiksa oleh reviewer. Skema yang tepat bergantung pada gateway Anda, tetapi bentuknya harus eksplisit.
route_id: support-summary-prod
owner:
product: support_ops
engineering: ai_platform
security: appsec
finance: finops
use_case:
task: summarize_support_threads
data_class: customer_support_confidential
allowed_environments: [production]
models:
primary: approved_summary_model_2026_07
fallbacks:
- approved_summary_backup_2026_07
denied:
- any_preview_model_without_reapproval
prompt:
source: app/prompts/support_summary.ts
reviewed_commit: 8f3c2d1
schema_required: true
tools:
allowed:
- read_ticket_metadata
denied:
- refund_customer
- send_email
logging:
payload_storage: disabled
metadata_retention_class: ops_metadata_90d
audit_events:
- route_change
- model_change
- prompt_change
- key_rotation
controls:
max_input_tokens: 8000
max_output_tokens: 700
monthly_budget_usd: 500
fallback_requires_same_data_policy: true
evals:
pack: support_summary_eval_2026_07
min_pass_rate: 0.95
required_tests:
- prompt_injection
- sensitive_data_fixture
- tool_scope
rollout:
canary_percent: 5
expand_after_hours: 24
rollback: disable_route_weight
renewal:
review_by: 2026-10-04
triggers:
- model_version_change
- prompt_change
- new_tool
- logging_change
- provider_terms_changeDi sinilah workflow persetujuan model AI menjadi operasional. Jika konfigurasi rute tidak dapat mengekspresikan keputusan, persetujuannya terlalu abstrak.
Cara ini sesuai dengan Flatkey
Flatkey dapat berfungsi sebagai permukaan operasional untuk workflow ini karena permukaan produk publik berfokus pada akses model terpadu, routing, penagihan, analitik penggunaan, batas kuota, dan satu dasbor untuk kunci serta routing. Homepage saat ini juga menampilkan pola request yang kompatibel dengan OpenAI menggunakan https://router.flatkey.ai/v1/chat/completions, sementara halaman harga dan model menjelaskan saldo prabayar, analitik penggunaan, harga model, dan cakupan provider.
Gunakan Flatkey sebagai permukaan bukti gateway, lalu verifikasi detail khusus akun berikut sebelum persetujuan:
- Model dan provider mana yang diaktifkan untuk rute tersebut.
- Keluarga endpoint mana yang digunakan setiap rute.
- Model fallback mana yang diizinkan dan ditolak.
- Kunci API, tim, proyek, dan environment mana yang dapat memanggil rute tersebut.
- Kontrol penggunaan, biaya, dan kuota mana yang tersedia untuk akun pembeli.
- Metadata request, event audit, dan catatan penagihan mana yang terlihat.
- Apakah prompt mentah, output, argumen tool, file, atau trace disimpan.
- Apakah perubahan rute, perubahan kunci, perubahan kuota, dan perubahan logging menghasilkan bukti yang dapat ditinjau.
Jangan ubah ini menjadi klaim kepercayaan yang generik. Gateway dapat mengurangi penyebaran provider dan memusatkan bukti, tetapi pembeli tetap memiliki workflow persetujuan model AI.
Pertanyaan procurement untuk diajukan
Tim procurement dan keamanan harus meminta bukti yang sesuai dengan rute, bukan hanya gambaran umum platform.
| Pertanyaan | Bukti yang baik | Bukti yang lemah |
|---|---|---|
| Model mana yang akan melayani rute ini? | Readback rute dengan model utama dan fallback | "Kami menggunakan model terbaik di kelasnya" |
| Apa yang terjadi jika model gagal? | Kebijakan timeout, retry, fallback, dan rollback | "Gateway yang menanganinya" |
| Data apa yang dicatat? | Contoh event metadata dan kebijakan payload | "Kami punya log" |
| Siapa yang dapat mengubah rute? | Daftar peran dan contoh event audit | "Admin dapat mengelolanya" |
| Evaluasi apa yang lolos? | Dataset, ambang batas, kegagalan, dan catatan reviewer | "Itu berhasil saat pengujian" |
| Kontrol keselamatan apa yang aktif? | Pengaturan filter, tes penolakan, kasus prompt-injection | "Keselamatan diaktifkan" |
| Apa yang ditinjau finance? | Baris penggunaan, snapshot harga, peringatan anggaran, jalur invoice | "Ada dasbor" |
| Apa yang memaksa persetujuan ulang? | Daftar pemicu tertulis dan owner | "Kami meninjau bila diperlukan" |
Hubungkan tinjauan ini dengan enterprise AI API gateway checklist untuk kontrol tingkat gateway, AI API vendor risk assessment untuk batas provider upstream, dan audit logs for AI API usage untuk bukti perubahan yang tahan lama.
Pembaruan dan dekomisioning
Kegagalan persetujuan terbesar adalah drift. Rute yang disetujui pada bulan Juli mungkin bukan rute yang berjalan pada bulan Oktober.
Tetapkan pemicu pembaruan sebelum peluncuran:
- Sebuah versi model menjadi deprecated, retired, preview-only, atau digantikan.
- Seorang provider mengubah penanganan data, content filtering, harga, region, atau dukungan fitur.
- Model fallback, bobot rute, keluarga endpoint, atau akun provider berubah.
- Prompt, schema, sumber retrieval, instruksi sistem, atau izin tool berubah.
- Grup pengguna baru, tier pelanggan, geografi, atau kelas data mulai menggunakan rute tersebut.
- Peringatan monitoring menunjukkan penurunan kualitas, keselamatan, latensi, biaya, atau penyalahgunaan.
- Insiden, eskalasi support, keluhan pelanggan, atau temuan procurement menyentuh rute tersebut.
Dekomisioning harus menjadi bagian dari workflow persetujuan model AI yang sama. Ketika sebuah rute dipensiunkan, catat rute pengganti, tanggal traffic drain, kunci yang dinonaktifkan, secret yang dihapus, log yang disimpan, penutupan penagihan, dan persetujuan akhir owner.
Pertanyaan yang sering diajukan
Apa itu workflow persetujuan model AI?
Workflow persetujuan model AI adalah proses tata kelola yang menentukan apakah suatu rute model dapat menangani lalu lintas produksi. Proses ini mencatat use case, jalur model/provider, kebijakan prompt dan tool, hasil evaluasi, kontrol keamanan, perilaku logging, pagar pembatas biaya, rencana peluncuran bertahap, dan pemicu pembaruan.
Siapa yang harus menyetujui rute model AI baru?
Minimal, persetujuan harus melibatkan pemilik produk, pemilik teknis, peninjau keamanan atau risiko, dan pemilik keuangan atau operasional. Rute dengan risiko lebih tinggi mungkin juga memerlukan tinjauan legal, pengadaan, privasi, dukungan, atau eksekutif.
Apakah model card sudah cukup untuk persetujuan?
Tidak. Model card atau system card memang bukti yang berguna, tetapi tidak membuktikan bahwa prompt, tools, fallback, logging, aliran data, kontrol biaya, dan perilaku peluncuran Anda aman untuk use case Anda. Rute tersebut tetap memerlukan paket persetujuannya sendiri.
Seberapa sering persetujuan model harus ditinjau?
Frekuensi peninjauan bergantung pada risiko, tetapi setiap rute harus memiliki pemicu pembaruan. Lakukan persetujuan ulang saat versi model, provider, prompt, izin tool, logging, kelas data, fallback, profil biaya, atau populasi pengguna berubah.
Bagaimana AI gateway membantu persetujuan model?
AI gateway dapat memusatkan akses model, kebijakan rute, kunci, penggunaan, biaya, kuota, dan bukti audit. Ini tidak menggantikan tata kelola pembeli. Gunakan gateway sebagai permukaan kontrol dan bukti, lalu verifikasi perilaku spesifik akun.
Kesimpulan
Workflow persetujuan model AI seharusnya membuat perubahan model produksi dapat ditinjau sebelum berubah menjadi insiden. Setujui rute, bukan nama model yang samar. Simpan berkas bukti dekat dengan gateway, wajibkan evaluasi khusus tugas, uji prompt injection dan otoritas tool, verifikasi logging dan kontrol biaya, dan tetapkan pemicu pembaruan sebelum permintaan pertama aktif. Saat Anda siap memusatkan akses model, routing, penggunaan, dan penagihan melalui satu gateway, tinjau harga dan katalog model Flatkey saat ini, lalu dapatkan key.
