Decisions API adalah layanan kecerdasan buatan (artificial intelligence atau AI) yang dirancang untuk menghasilkan penilaian terstruktur dalam aplikasi.
OpenAI mengumumkan Decisions API keluar dari beta melalui kanal pengumuman pengembang pada 22 Oktober 2026 waktu UTC, atau 23 Oktober WIB.[1] Layanan ini ditujukan untuk mengevaluasi masukan dan menghasilkan keputusan terstruktur, bukan menulis jawaban panjang seperti chatbot.[1][2] Perkembangan tersebut penting karena menempatkan kecerdasan buatan pada simpul kecil alur aplikasi: memilih kategori, menilai kondisi, atau menentukan ke mana sebuah permintaan diteruskan.
Yang berubah setelah beta
Pengumuman menyebut penambahan integrasi GPT-Live, prompt caching, masukan JSON, gambar dalam instruksi pertanyaan, serta batas hingga 400 pertanyaan per permintaan.[1] Angka terakhir meningkat dari 200 pada beta menurut dokumentasi produk.[2] Ini adalah kapasitas pertanyaan dalam satu permintaan, bukan jaminan bahwa seluruh tugas bisnis dapat diselesaikan sekaligus tanpa pengawasan.
Dokumentasi menjelaskan tiga jenis keluaran: predicate berupa estimasi probabilitas suatu kondisi, choice untuk memilih dari opsi yang disediakan, dan score untuk penilaian berdasarkan tingkat berurutan.[2] Dengan demikian, pengembang harus menentukan apa yang hendak dinilai sebelum meminta model bekerja. Ruang jawaban sengaja dibatasi, bukan dibiarkan menjadi percakapan bebas.
Dokumentasi juga membedakan Decisions dari Responses API dengan Structured Outputs ketika aplikasi membutuhkan objek sesuai skema sendiri, atau function calling ketika model perlu meminta pemanggilan alat.[2] Pembedaan ini penting: memilih kategori tiket tidak sama dengan merumuskan penjelasan pelanggan, apalagi menjalankan perubahan pada rekening atau basis data.
Keluaran cepat bukan kewenangan bertindak
Menurut dokumentasi, aplikasi milik pengembang tetap menjalankan tindakan yang dipilih berdasarkan jawaban Decisions.[2] API mengembalikan penilaian; tanggung jawab untuk menghubungkannya dengan aksi berada pada rancangan sistem. Analisis AIGEO.ID: batas ini justru merupakan bagian paling penting dari berita tersebut. Keputusan model tidak boleh berubah menjadi izin universal hanya karena format jawabannya rapi.
Sebagai contoh hipotetis, sebuah platform layanan pelanggan dapat meminta AI menentukan apakah pesan berkaitan dengan pembayaran, pengiriman, atau keluhan produk. Hasilnya sebaiknya dipakai untuk menyusun antrean. Jika pesan menyangkut pengembalian uang, klasifikasi saja tidak cukup menjadi dasar pencairan. Pemeriksaan transaksi dan persetujuan pihak berwenang perlu ditempatkan sebagai langkah tersendiri.
Contoh lain ialah penyaringan dokumen internal. Sebuah tim dapat menguji apakah dokumen relevan untuk proyek tertentu, tetapi label tidak relevan sebaiknya tidak otomatis memicu penghapusan. Pengarsipan sementara dan peninjauan manusia memberikan jalan koreksi. Rekomendasi ini merupakan penilaian operasional redaksi, bukan pernyataan bahwa produk menyediakan seluruh pengamanan tersebut secara bawaan.
Apa yang perlu diuji organisasi Indonesia
Saran pertama adalah menyiapkan contoh berbahasa Indonesia yang mencerminkan penggunaan nyata, termasuk campuran istilah asing, singkatan, serta pesan yang tidak lengkap. Tetapkan jawaban rujukan sebelum pengujian. Jangan hanya menghitung berapa banyak keluaran yang sesuai format; periksa pula kasus yang masuk kategori salah dan akibat praktisnya bagi pengguna.
Saran kedua, pisahkan kesalahan yang dampaknya ringan dari yang berat. Salah menempatkan tiket informasi tidak setara dengan menolak permintaan mendesak. Organisasi dapat menetapkan jalur tinjauan untuk kasus ambigu, lalu mencatat apakah manusia membatalkan keputusan model. Tujuannya bukan mengejar otomatisasi terbesar, melainkan mengetahui keputusan mana yang layak didelegasikan secara terbatas.
Saran ketiga, ukur keseluruhan alur. Waktu jawaban model hanyalah satu komponen di antara antrean, akses data, pengawasan, dan tindakan lanjutan. Demonstrasi yang terasa cepat belum membuktikan bahwa layanan pelanggan menjadi lebih baik. Uji dengan proses lama sebagai pembanding dan jangan mengubah standar mutu hanya agar percobaan terlihat berhasil.
Kesimpulannya, keluarnya Decisions API dari beta memperluas pilihan untuk membangun aplikasi AI yang terarah.[1][2] Nilai praktisnya perlu diuji pada tugas tertentu, bukan disimpulkan dari istilah keputusan. Bagi calon pengguna, pertanyaan utamanya bukan apakah AI dapat memilih jawaban, melainkan kapan pilihan itu boleh dipercaya, siapa yang dapat mengoreksi, dan apa yang terjadi saat pilihan tersebut salah.
Sources
[1] https://community.openai.com/t/decisions-api-is-now-generally-available-with-new-updates/1408934/1
[2] https://developers.openai.com/api/docs/guides/decisions
Bacaan terkait AIGEO.ID: audit benchmark chatbot dan evaluasi AI agents. Pembaca disarankan membandingkan klaim teknologi dengan dokumen sumber primer dan tanggal pengukuran sebelum menarik kesimpulan.
Audit sumber primer: apa yang benar-benar berubah pada 22 Oktober 2026
Dalam pengumuman resmi 22 Oktober 2026, OpenAI menyatakan Decisions API tersedia secara umum setelah periode beta publik. Perubahan yang disebut mencakup integrasi GPT-Live, prompt caching, masukan JSON asli, pemrosesan regional di Amerika Serikat dan Uni Eropa, serta kemampuan mengajukan sampai 400 pertanyaan dalam satu permintaan. Produk ini memusatkan tugas pada jawaban terbatas, bukan menulis paragraf panjang. Status ‘general availability’ merupakan status produk menurut penyedia; itu bukan sertifikasi bahwa seluruh pengguna atau wilayah telah memenuhi setiap kebutuhan kepatuhan.
Tiga tipe keluaran utamanya adalah predicate, yaitu estimasi probabilitas suatu kondisi; choice, memilih dari opsi yang ditentukan aplikasi; dan score, memberi nilai menurut rubrik berurutan. Masing-masing mempunyai konsekuensi evaluasi. Probabilitas harus diuji kalibrasinya, pilihan harus diuji kesalahan rute, dan skor harus diuji konsistensi antarcontoh. Menampilkan angka kepercayaan tinggi bukan bukti keputusan benar. Pemilik aplikasi harus menetapkan kapan keputusan boleh dieksekusi otomatis dan kapan memerlukan manusia.
Menghitung biaya token tanpa mengarang ROI
Harga yang diumumkan pada tanggal tersebut adalah US$0,10 per satu juta token input non-cache dan US$0,01 per satu juta token input cache. Tidak ada biaya token output menurut pengumuman itu. Rumus sederhana: biaya = token non-cache/1.000.000 × US$0,10 + token cache/1.000.000 × US$0,01. Ini harga API yang diumumkan, bukan harga akhir setiap perusahaan; kontrak, pajak, jaringan, aplikasi, dan perubahan tarif perlu dicek tersendiri.
| Skenario hipotetis | Token non-cache | Token cache | Biaya token |
|---|---|---|---|
| A: satu juta token biasa | 1.000.000 | 0 | US$0,10 |
| B: satu juta token cache | 0 | 1.000.000 | US$0,01 |
| C: 8 juta biasa + 2 juta cache | 8.000.000 | 2.000.000 | US$0,82 |
Pada skenario C, 8×US$0,10 + 2×US$0,01 = US$0,82. Nilai ini tidak termasuk biaya penyimpanan, penyiapan cache, jaringan, pemantauan, evaluasi kesalahan, dan pekerjaan manusia. Jangan mengubahnya menjadi rupiah dengan kurs yang tidak disebutkan tanggal dan sumbernya. Untuk layanan ber-volume tinggi, tarif rendah memang menarik, tetapi keputusan rute yang salah dapat jauh lebih mahal daripada token yang dihemat.
Contoh desain: rute keluhan pelanggan yang dapat diaudit
Misalkan sebuah perusahaan menerima 100.000 tiket sebulan. Aplikasi meminta Decisions API memilih antara ‘pertanyaan umum’, ‘keluhan transaksi’, ‘dugaan penipuan’, dan ‘butuh klarifikasi’. Untuk kasus dugaan penipuan, sistem tidak boleh langsung menutup tiket hanya karena probabilitasnya rendah. Ia perlu mengirim ke tim pemeriksaan dengan aturan yang sudah disetujui. Audit harus membandingkan hasil terhadap label manusia yang ditetapkan sebelumnya dan memisahkan kesalahan berat dari kesalahan ringan.
Jika dari 1.000 tiket yang benar-benar merupakan dugaan penipuan, sistem menemukan 950, recall untuk kelas itu = 950/1.000 = 95%. Tetapi 50 yang terlewat mungkin berdampak serius. Jika ada 500 tiket lain yang salah ditandai sebagai penipuan, beban pemeriksa juga naik. Tanpa menghitung false positive, false negative, dan biaya tiap kelas, angka recall 95% tidak cukup untuk menyatakan sistem siap produksi. Contoh ini adalah ilustrasi metode, bukan benchmark Decisions API.
Lima pemeriksaan sebelum produksi
Pertama, gunakan dataset evaluasi yang tidak dipakai menyusun contoh prompt. Kedua, bandingkan latensi median dan p95 dengan jalur Responses API pada perangkat dan beban yang sama; klaim ‘hingga 10 kali lebih cepat’ adalah klaim produk yang tidak otomatis berlaku pada semua tugas. Ketiga, tetapkan ambang eskalasi berdasarkan biaya kesalahan, bukan sekadar probabilitas tertinggi. Keempat, periksa lokasi pemrosesan dan kebijakan retensi sesuai paket layanan serta jenis data. Kelima, simpan jejak versi model, input yang boleh dicatat, keputusan, dan hasil pemeriksaan.
Pengumuman OpenAI juga memuat contoh pelanggan dan pengukuran internal, tetapi angka tersebut berasal dari konteks evaluasi masing-masing pihak. Perbandingan dengan produk pesaing atau estimasi penghematan nasional membutuhkan eksperimen independen. Artikel ini tidak mengklaim telah menjalankan benchmark produksi atau mengakses statistik pelanggan OpenAI.
FAQ singkat
Apakah Decisions API menggantikan chatbot? Tidak secara langsung. Ia dirancang untuk pertanyaan dengan jawaban terbatas, sedangkan chatbot sering perlu menghasilkan teks panjang dan penjelasan. Keduanya dapat dipakai bersama dalam satu alur kerja.
Apakah 400 pertanyaan berarti 400 tindakan otomatis aman? Tidak. Batas jumlah pertanyaan dalam permintaan adalah kemampuan antarmuka, bukan izin menjalankan tindakan berisiko tanpa pemeriksaan.
Apakah harga token murah menjamin ROI? Tidak. ROI harus menghitung integrasi, pengawasan, kegagalan, serta manfaat bisnis yang benar-benar terukur.
Metode AIGEO.ID: angka produk diambil dari pengumuman resmi 22 Oktober 2026; tabel biaya dan contoh tiket merupakan perhitungan hipotetis dengan input terbuka. Tidak ada hasil uji vendor independen yang diklaim.





Komentar & Diskusi