SLA AI gateway bisa terlihat sederhana sampai insiden model pertama terjadi. Seorang pembeli melihat persentase ketersediaan, alamat dukungan, dan janji bahwa gateway merutekan permintaan. Tim produksi tetap harus menjawab pertanyaan yang lebih sulit: endpoint mana yang dicakup, provider upstream mana yang gagal, apakah fallback mengubah kontrak model, bukti apa yang dibutuhkan support, dan apakah ada pemulihan otomatis.
Gunakan checklist SLA AI gateway ini untuk mengubah bahasa vendor menjadi file bukti. Tujuannya bukan bernegosiasi dengan slogan. Tujuannya adalah mengetahui apa yang dicakup SLA, apa yang dikecualikan, bagaimana routing dan fallback dibuktikan, dan apa yang harus ditinjau tim Anda sebelum perpanjangan.
Secara khusus untuk Flatkey, Service Level Agreement publik yang diperiksa pada 6 Juli 2026 menyatakan bahwa cakupan yang dijamin adalah dashboard yang di-host, API gateway, routing, metering, dan layanan akun yang dioperasikan langsung oleh Flatkey. Targetnya adalah ketersediaan bulanan 99,5% untuk endpoint yang dicakup, mengecualikan outage penyedia model AI pihak ketiga dan kegagalan di sisi provider, meminta pelanggan mengirim request ID, timestamp, error, endpoint, email akun, dan ringkasan dampak untuk support, serta tidak menciptakan kredit otomatis kecuali ada perjanjian tertulis terpisah yang menyatakan sebaliknya. Perlakukan ini sebagai bukti awal, lalu verifikasi akun Anda, kelas traffic, kebijakan fallback, dan proses support sebelum traffic produksi bergantung padanya.
Jawaban Singkat: Pertanyaan SLA AI Gateway
| Area SLA | Tanyakan ini sebelum menandatangani atau memperpanjang | Bukti yang perlu disimpan | |---|---|---| | Layanan yang dicakup | Dashboard, API gateway, routing, metering, akun, dan fungsi support mana yang dicakup? | URL SLA saat ini, jadwal kontrak, daftar endpoint, dan tangkapan layar bertanggal. | | Perhitungan ketersediaan | Apakah ketersediaan diukur oleh pemantauan vendor, probe pelanggan, status publik, atau laporan kontrak? | Laporan ketersediaan bulanan, log probe, ekspor insiden, dan metode perhitungan. | | Provider pihak ketiga | Apakah outage model upstream, rate limit, pembatasan regional, perubahan model, dan kegagalan di sisi provider dikecualikan? | Tautan status provider, body error model, log route, dan teks pengecualian vendor. | | Routing | Model, provider, akun, region, atau grup mana yang dicoba terlebih dahulu? | Request ID, route yang dipilih, model ID, family endpoint, pemilik kunci, dan timestamp. | | Fallback | Error mana yang memicu retry, fallback, antrean, atau perilaku fail-closed? | Kebijakan fallback, jejak route, jumlah retry, model akhir, dan bukti output yang diterima. | | Support | Bukti apa yang harus dikirim, dan jalur severity apa yang berlaku? | Template tiket, request ID, endpoint, timestamp, error, ringkasan dampak, dan timeline respons. | | Pemulihan | Apakah service credit otomatis, berdasarkan kasus per kasus, atau hanya dalam perjanjian tertulis terpisah? | Klausul pemulihan SLA, amandemen kontrak, permintaan kredit, dan persetujuan finance. | | Perpanjangan | Apa yang harus ditinjau sebelum periode berikutnya? | Register insiden, pengecualian fallback, hasil support, event kuota, perubahan harga, dan persetujuan route. |
Jawaban praktis SLA AI gateway adalah ini: pisahkan tanggung jawab gateway dari tanggung jawab provider upstream, lalu uji rutenya. Jika pembeli tidak dapat memeriksa route, fallback, tiket support, dan bukti ketersediaan bulanan, SLA belum siap untuk tata kelola produksi.
Pisahkan Uptime Gateway Dari Ketersediaan Model Upstream
Pertanyaan pertama SLA AI gateway adalah apakah vendor menjanjikan gateway, model upstream, atau hasil akhir pengguna sepenuhnya. Itu adalah lapisan yang berbeda.
SLA publik Flatkey saat ini membuat pemisahan itu eksplisit: layanan yang dioperasikan Flatkey dan dicakup berada dalam ruang lingkup, sementara provider model pihak ketiga, outage provider, rate limit provider, perubahan kebijakan, pembatasan regional, perilaku model, dan kegagalan di sisi provider berada di luar SLA. Itu cukup umum dalam pembelian gateway sehingga procurement tidak boleh pernah memperlakukan satu angka uptime sebagai "semua permintaan model akan berhasil."
Gunakan pemisahan ini dalam file bukti:
| Lapisan | Apa yang bisa gagal | Bukti pembeli | |---|---|---| | Klien dan SDK | Base URL salah, key salah, endpoint tidak didukung, timeout terlalu rendah, parser error. | Konfigurasi klien, versi SDK, body permintaan, timeout, dan log lokal. | | Gateway | Autentikasi, routing, metering, endpoint gateway, dashboard, log penggunaan, layanan akun. | SLA gateway, request ID, jejak route, status, catatan penggunaan, dan tiket support. | | Provider upstream | Outage provider, kuota provider, pensiun model, blok regional, penolakan kebijakan, perilaku spesifik model. | Status provider, halaman kuota provider, body error upstream, model ID, dan keputusan fallback. | | Alur kerja bisnis | Dampak pengguna, kedalaman antrean, output menurun kualitasnya, sasaran internal terlewat. | Timeline insiden, kelas traffic terdampak, ringkasan dampak pelanggan, keputusan rollback. |
Di sinilah SLA AI gateway menjadi operasional. Pembeli harus meminta jejak level route, bukan hanya angka uptime bulanan.
Pertanyaan Routing Dan Fallback
Routing adalah bagian dari SLA AI gateway yang paling sering kurang dispesifikasikan. Gateway mungkin mendukung beberapa model dan provider, tetapi keandalan produksi bergantung pada route mana yang diizinkan untuk setiap kelas traffic.
Dokumentasi gateway resmi dari vendor lain menunjukkan mengapa detail ini penting. Dokumentasi AI Gateway Vercel menjelaskan routing provider dan fallback model, termasuk kontrol atas urutan routing dan perilaku fallback. Dokumentasi fallback modelnya menyatakan bahwa backup dapat dicoba secara berurutan ketika model utama gagal atau tidak tersedia. Dokumentasi Pydantic AI Gateway menjelaskan grup routing di mana prioritas dan bobot menentukan failover atau load balancing, dengan fallthrough ketika anggota berprioritas lebih tinggi tidak tersedia, terkena rate limit, atau mengalami error. Ini adalah contoh kategori yang berguna, bukan jaminan Flatkey. Ini menunjukkan pertanyaan yang harus diajukan pembeli kepada gateway mana pun, termasuk Flatkey.
Gunakan tabel routing ini sebelum menyetujui fallback otomatis:
| Failure signal | Default buyer question | Safe evidence | |---|---|---| | Gateway 401 or 403 | Apakah key, akun, environment, atau cakupan policy salah? | Pemilik key, environment, error auth, dan catatan penolakan policy. | | Model not found | Apakah model yang diminta ada di katalog saat ini untuk akun ini? | Baris katalog, ID model, family endpoint, dan bukti tanggal publish atau tanggal uji. | | Provider 429 | Apakah kuota akun, region, model, atau deployment ini habis? | Halaman kuota, body error upstream, data retry-after, dan kebijakan fallback. | | Provider 5xx or timeout | Apakah gateway harus retry, beralih ke route model yang sama, mengantre, atau fail closed? | Trace route, jumlah retry, ambang timeout, hasil akhir, dan catatan biaya. | | Context limit or unsupported input | Apakah fallback diizinkan jika model cadangan mengubah konteks, tools, vision, atau perilaku media? | Kontrak model, uji fitur, pemeriksaan output yang diterima, dan persetujuan product owner. | | Policy or safety rejection | Apakah provider lain diizinkan menerima request yang sama? | Batas data, persetujuan provider, klasifikasi prompt, dan tanda tangan persetujuan compliance. | | Unknown failure | Apa kondisi berhentinya? | Runbook insiden, jumlah percobaan maksimum, aturan fail-closed, dan eskalasi ke support. |
Bukti SLA AI gateway yang paling kuat adalah route trace yang menyebut route awal, aturan fallback, route akhir, dan alasan setiap transisi terjadi.
Fallback Tidak Selalu Menjadi Kemenangan Reliabilitas
Tim procurement sering bertanya apakah gateway memiliki fallback otomatis. Tim platform sebaiknya menjawab dengan pertanyaan kedua: fallback ke apa?
Peralihan otomatis dari satu akun ke akun lain untuk model yang sama dan sudah disetujui bisa masuk akal. Peralihan dari satu family model ke family model lain dapat mengubah kualitas, penanganan data, latensi, format output, perilaku tools, kebijakan gambar atau video, dan biaya. Sebagian traffic seharusnya fail closed karena fallback yang tersembunyi akan memperburuk insiden.
Tentukan fallback berdasarkan kelas traffic:
| Traffic class | Fallback posture | Why | |---|---|---| | Customer chat | Gunakan hanya route ekuivalen yang disetujui, atau kembalikan error yang terkontrol. | Kualitas dan keamanan yang terlihat oleh pengguna harus tetap dapat diprediksi. | | Internal summarization | Retry, antrekan, atau gunakan route yang disetujui dengan biaya lebih rendah. | Latensi dapat ditukar dengan biaya dan penyelesaian. | | Evaluations and benchmarks | Fail closed. | Perubahan model yang tersembunyi merusak data perbandingan. | | Finance-sensitive batch jobs | Antrekan atau minta persetujuan sebelum fallback. | Retry dan model cadangan dapat melipatgandakan pengeluaran. | | Agent workflows with tools | Fallback hanya setelah perilaku tool-call diuji. | Skema tool dan perilaku streaming dapat berbeda antar provider. | | Regulated or customer-isolated traffic | Fail closed kecuali provider cadangan dan region sudah disetujui sebelumnya. | Batas data dan bukti procurement lebih penting daripada penyelesaian otomatis. |
Ini adalah pengujian yang dimiliki buyer: jalankan prompt yang sama melalui route utama dan route fallback yang diusulkan, lalu bandingkan bentuk respons, log, biaya, latensi, output yang diterima, dan bukti support. Jangan anggap SLA AI gateway selesai sampai bukti fallback tersedia.
Pertanyaan Dukungan Untuk Paket Bukti
SLA Flatkey saat ini meminta pelanggan menghubungi support dengan email akun, endpoint yang terdampak, request ID jika tersedia, timestamp, pesan error, dan ringkasan dampak. Itu adalah template yang berguna untuk proses support SLA AI gateway apa pun.
Sebelum peluncuran, buat paket support dengan field berikut:
| Field | Why it matters | |---|---| | Account email and workspace | Memungkinkan support menemukan tenant, key, dan entitlement yang सही. | | Affected endpoint | Memisahkan insiden chat, responses, messages, image, video, dan dashboard. | | Request IDs | Menghubungkan log aplikasi ke trace gateway dan upstream. | | Timestamps with timezone | Mencegah ketersediaan bulanan dan jendela insiden bergeser. | | Model ID and route class | Menunjukkan kebijakan route dan family provider mana yang terlibat. | | Error messages and status codes | Memisahkan kegagalan auth, kuota, timeout, provider, dan parser. | | Impact summary | Menjelaskan user yang terdampak, revenue, job, kedalaman antrean, atau workflow internal. | | Customer-side retries | Menunjukkan apakah percobaan duplikat meningkatkan biaya atau beban. | | Required action | Menjelaskan apakah Anda memerlukan diagnosis, penonaktifan route, review kredit, atau tindak lanjut kontrak. |
Hubungkan paket support ini ke proses audit logs AI API usage Anda. Jika request ID dan bukti route tidak tersedia setelah insiden, proses support menjadi latihan mengandalkan ingatan.
Pertanyaan Remedi Dan Kredit
Bagian remedi dari SLA AI gateway penting karena sering kali menentukan apa yang sebenarnya dapat dipulihkan oleh buyer. Target 99,5% tanpa klausul kredit berbeda dengan SLA yang dikomitmenkan dengan kredit layanan otomatis, persyaratan pemberitahuan tertulis, pengecualian, dan tenggat klaim.
SLA publik Flatkey menyatakan tidak ada kredit layanan otomatis, refund, penalti, atau liquidated damages kecuali perjanjian tertulis terpisah memberikan remedi yang berbeda. Setiap penyesuaian goodwill, koreksi saldo, atau perbaikan support ditangani kasus per kasus berdasarkan perjanjian pengguna dan kebijakan yang berlaku.
Itu tidak membuat SLA menjadi tidak berguna. Itu berarti procurement harus mengajukan pertanyaan yang tepat:
- Apakah SLA publik merupakan keseluruhan perjanjian, atau ada jadwal enterprise terpisah?
- Jika ada kredit, berapa jendela klaimnya?
- Bukti apa yang harus diberikan pelanggan?
- Apakah gangguan pada penyedia upstream dikecualikan bahkan ketika gateway memilih upstream tersebut?
- Apakah pemeliharaan terjadwal dan tindakan keamanan darurat dikecualikan?
- Apakah latensi, kualitas model, throttling, dan perilaku fallback tercakup atau hanya ketersediaan?
- Apakah upaya perbaikan berlaku untuk saldo prabayar, kredit tagihan, pengembalian dana, perbaikan dukungan, atau hak pemutusan kontrak?
- Siapa di bagian keuangan yang menyetujui klaim akhir?
Jawabannya harus berada dalam file vendor yang sama dengan penilaian risiko vendor API AI. Legal dan keuangan memerlukan bukti yang sama seperti yang digunakan insinyur platform saat peninjauan insiden.
Kuota, Batas Rate, Dan Ketergantungan Penyedia
SLA AI gateway dapat valid sementara permintaan tetap gagal karena kuota penyedia upstream habis. Inilah sebabnya bukti kuota harus masuk ke dalam tinjauan SLA.
Dokumentasi kuota Azure OpenAI dari Microsoft menyebutkan bahwa batas token per menit dan permintaan per menit berlaku per wilayah, langganan, dan jenis model atau deployment. Dokumentasi AWS Bedrock juga mengarahkan tim ke service quotas untuk sumber daya Bedrock dan mencatat bahwa inferensi model dikendalikan oleh kuota penggunaan token. Fakta penyedia ini bukan janji Flatkey. Ini adalah pengingat bahwa bentuk akun upstream dapat menentukan apakah fallback tersedia selama insiden nyata.
Tambahkan pemeriksaan ini ke file peluncuran:
| Pemeriksaan ketergantungan | Bukti | |---|---| | Cakupan kuota upstream | Wilayah, akun atau langganan, model, jenis deployment, TPM/RPM atau padanan dari penyedia. | | Cakupan kuota gateway | Kunci, tim, lingkungan, grup model, batas anggaran, dan jendela reset. | | Anggaran retry | Jumlah retry maksimum, kebijakan jitter/backoff, dan pagar pembatas biaya. | | Kapasitas fallback | Kuota jalur cadangan, ketersediaan model, dan persetujuan penyedia. | | Perilaku throttling | Kode error, sinyal retry-after, eskalasi dukungan, dan penanganan yang dilihat pengguna. |
Jika kuota tidak diukur oleh pemilik yang sama dengan routing, tinjauan SLA AI gateway akan melewatkan mode kegagalan yang paling umum: rute ada, tetapi akun tidak dapat menyerap lalu lintas produksi.
Tinjauan Staging Flatkey
Untuk Flatkey, bukti produk publik yang diperiksa pada 6 Juli 2026 mendukung satu gateway API AI, satu API key, base URL router yang kompatibel dengan OpenAI https://router.flatkey.ai/v1, visibilitas penggunaan dan penagihan yang berorientasi pada dashboard, tinjauan harga, dan penempatan terkait routing. Snapshot API harga yang aktif mengembalikan success: true, versi harga a42d372ccf0b5dd13ecf71203521f9d2, 45 baris model, 48 vendor, metadata endpoint yang didukung untuk pesan Anthropic, Gemini generateContent, pembuatan gambar, OpenAI chat completions, dan permintaan video, plus status ketersediaan available dan unknown_failure di seluruh baris.
Gunakan itu hanya sebagai bukti publik bertanggal. Itu tidak membuktikan upaya perbaikan SLA akun Anda, tingkat dukungan, keberhasilan rute, kelayakan fallback, ketersediaan model permanen, latensi, cakupan kepatuhan, atau harga spesifik akun.
Tinjauan staging SLA AI gateway Flatkey harus mencakup:
- Buka halaman harga saat ini dan pilih model atau keluarga rute yang tepat.
- Konfirmasikan baris model dan keluarga endpoint di akun atau dashboard Anda.
- Jalankan permintaan berisiko rendah melalui
https://router.flatkey.ai/v1. - Ambil ID permintaan, ID model, endpoint, stempel waktu, status, unit penggunaan, bukti biaya, dan pemilik kunci.
- Jalankan satu pengujian kegagalan yang disetujui: model salah, batas kuota, timeout, atau fallback dinonaktifkan.
- Konfirmasikan di mana bukti dukungan muncul di log.
- Tentukan kelas lalu lintas mana yang dapat fallback dan mana yang harus fail closed.
- Tambahkan field paket dukungan ke runbook insiden.
- Simpan SLA saat ini, harga, bukti rute, dan jalur dukungan di folder bukti vendor.
Ketika bukti itu ada, platform, pengadaan, dan keuangan dapat mengevaluasi file yang sama alih-alih berdebat dari tangkapan layar.
Daftar Periksa Pemicu Perpanjangan
Jangan meninjau SLA AI gateway hanya sekali. Tambahkan pemicu perpanjangan agar file pembeli tetap mutakhir.
| Pemicu | Apa yang perlu diperiksa ulang | |---|---| | Pembaruan halaman SLA atau kontrak | Ruang lingkup, pengecualian, upaya perbaikan, proses dukungan, dan detail kontak. | | Keluarga model baru | Endpoint, penyedia, kuota, batas data, unit harga, dan kebijakan fallback. | | Kelas lalu lintas produksi baru | Postur failover, tingkat keparahan dukungan, dan persetujuan pemilik. | | Insiden atau nyaris celaka | Jejak rute, linimasa dukungan, dampak ke pengguna, dampak biaya, dan tindakan pencegahan. | | Perubahan kuota penyedia | Kapasitas cadangan, perilaku throttling, dan alokasi lalu lintas. | | Perubahan harga | Biaya per permintaan, anggaran retry, biaya model fallback, dan ambang keuangan. | | Tinjauan keamanan atau kepatuhan | Cakupan logging, retensi, persetujuan penyedia, dan tinjauan akses. |
Hubungkan daftar periksa ini kembali ke daftar periksa enterprise AI API gateway. SLA adalah satu bagian dari paket bukti enterprise, bukan lencana kepercayaan yang berdiri sendiri.
Kesalahan Umum
| Kesalahan | Mengapa ini merugikan | Pemeriksaan yang lebih baik | |---|---|---| | Menganggap target uptime gateway sebagai jaminan keberhasilan model | Penyedia upstream, kuota, kebijakan, dan perilaku model dapat dikecualikan. | Pisahkan bukti gateway, penyedia, klien, dan alur kerja bisnis. | | Menanyakan apakah fallback ada, tetapi tidak ke apa ia beralih | Model cadangan dapat mengubah output, batas data, fitur, dan biaya. | Setujui fallback berdasarkan kelas trafik dan kontrak model. | | Tidak menyimpan request ID apa pun | Dukungan tidak dapat menghubungkan log pelanggan ke log rute secara andal. | Tambahkan penangkapan request ID ke setiap rute produksi. | | Mengabaikan cakupan kuota | Rute cadangan dapat ada tetapi tetap melakukan throttling saat trafik puncak. | Simpan bukti kuota upstream dan gateway bersama-sama. | | Berasumsi kredit diberikan otomatis | Banyak SLA mensyaratkan perjanjian terpisah, proses klaim, atau tinjauan per kasus. | Simpan ketentuan pemulihan dan pemilik klaim sebelum peluncuran. | | Meninjau hanya saat pembelian | Katalog model, kuota, dan jalur dukungan berubah. | Tambahkan pemicu pembaruan dan pemeriksaan ulang berbasis insiden. |
Pertanyaan yang sering diajukan
Apa itu SLA AI gateway?
SLA AI gateway mendefinisikan target ketersediaan, cakupan, pengecualian, proses dukungan, dan pemulihan untuk layanan gateway yang dioperasikan vendor. SLA ini mungkin tidak mencakup gangguan penyedia model pihak ketiga, batas kuota, perilaku model, konfigurasi pelanggan, atau setiap hasil fallback.
Apakah SLA AI gateway menjamin setiap permintaan model berhasil?
Tidak. SLA AI gateway dapat mencakup ketersediaan gateway sambil mengecualikan kegagalan penyedia upstream, batas laju penyedia, perubahan kebijakan, perilaku model, kredensial pelanggan, pemeliharaan terjadwal, atau masalah di sisi pelanggan. Periksa teks pengecualian dan bukti rute.
Apa yang harus ditanyakan procurement tentang fallback model?
Procurement harus menanyakan error apa yang memicu fallback, model atau penyedia mana yang disetujui sebagai cadangan, apakah fallback mengubah penanganan data atau perilaku output, bagaimana retry ditagihkan, dan di mana bukti rute disimpan setelah insiden.
Bukti apa yang harus diterima support selama insiden SLA?
Support harus menerima email akun, endpoint yang terdampak, request ID, cap waktu, pesan error, ID model, kelas rute, ringkasan dampak, dan perilaku retry pelanggan. SLA publik Flatkey saat ini meminta beberapa dari bidang ini, termasuk endpoint, request ID, cap waktu, error, dan ringkasan dampak.
Apakah kredit layanan otomatis?
Tidak selalu. SLA publik Flatkey menyatakan bahwa kredit layanan otomatis, pengembalian dana, penalti, atau liquidated damages tidak dibuat kecuali perjanjian tertulis terpisah menyatakan sebaliknya. Pembeli harus mengonfirmasi klausul pemulihan, batas waktu klaim, dan jalur persetujuan.
Seberapa sering tim harus meninjau SLA AI gateway?
Tinjau SLA AI gateway saat pembelian, pembaruan, perubahan rute besar, keluarga model baru, kelas trafik produksi baru, perubahan harga, perubahan kuota, dan setelah setiap insiden material atau nyaris gagal.
Rekomendasi Akhir
SLA AI gateway hanya berguna jika dapat diuji. Mulailah dengan SLA publik atau yang dikontrakkan, pisahkan cakupan gateway dari cakupan penyedia upstream, jalankan uji rute dan fallback, simpan request ID, definisikan bukti dukungan, dan tambahkan pemicu pembaruan.
Flatkey dapat membantu tim memusatkan akses model, routing, peninjauan harga, dan bukti penggunaan di balik satu alur kerja gateway. Sebelum penerapan produksi, verifikasi model, endpoint, perilaku rute, proses dukungan, dan bukti SLA yang tepat untuk akun Anda. Lalu dapatkan kunci saat Anda siap menguji alur kerja SLA AI gateway dengan trafik staging yang nyata.
