Kalau tim kamu mulai memakai AI untuk kerja, jumlah akun belum cukup untuk menunjukkan manfaatnya. Kamu juga perlu tahu apakah tugas selesai lebih cepat, hasilnya akurat, dan data tetap dibaca oleh orang yang berhak. Perluasan pemakaian di Uber memberi konteks untuk melihat pertanyaan itu.
OpenAI menyatakan pada 22 Oktober bahwa Uber memperluas ChatGPT untuk pekerjaan dari uji awal atau pilot sekitar 1.000 orang ke lebih dari 30.000 karyawan. Pengumuman itu menyebut GPT-6.1 Sol sebagai pilihan bawaan, serta hubungan layanan dengan Google Drive, Gmail, Calendar, dan Slack. Ada juga kumpulan panduan kerja internal atau skill dan pelatihan.
Informasi itu menjelaskan luas penerapan, atau rollout. Pengumuman tersebut belum memberi hasil produktivitas independen. Lisensi yang dibagikan belum menjawab apakah pekerjaan menjadi lebih cepat atau akurat.
Untuk melihat tantangannya, kita memakai contoh asisten yang merangkum bahan untuk redaksi. Ringkasan bahan ini disebut brief dan disusun dari dokumen serta percakapan tim. Rancangan berikut adalah usulan Nalarku, bukan penjelasan sistem internal Uber.
Pisahkan izin tim, pengguna, sumber, dan tindakan
Dokumentasi aplikasi ChatGPT membedakan tersedianya aplikasi dari akses ke data pengguna. Terhubung ke layanan belum berarti model bisa membaca seluruh isinya. Izin dari penyedia, pemeriksaan identitas pengguna atau autentikasi, dan pengaturan ruang kerja bersama atau workspace ikut menentukan aksesnya.
Jika membangun aplikasi sendiri, periksa empat lapisan ini secara terpisah:
| Lapisan | Contoh keputusan | Risiko jika dicampur |
|---|---|---|
| Ruang kerja | Apakah tim boleh memakai hubungan ke layanan ini? | Aplikasi diaktifkan terlalu luas |
| Identitas pengguna | Akun siapa yang memberi izin? | Data dibaca lewat akun yang salah |
| Akses sumber | Dokumen mana yang boleh dibaca? | Hasil pencarian melampaui hak pengguna |
| Tindakan | Apakah boleh membuat draf atau mengirim? | Rangkuman berubah menjadi tindakan tanpa persetujuan |
Kontrol admin resmi juga menjelaskan pengaturan workspace dan peran. Kemampuan yang tersedia bergantung pada aplikasi, paket, wilayah, dan pengaturannya. Daftar layanan dalam pengumuman belum menjamin semua tindakan tersedia untuk semua akun.
Buat alur brief yang bisa ditelusuri
Pisahkan pencarian bahan, penyusunan, dan pengiriman. Berikut contoh alurnya:
Permintaan pengguna + identitas sesi
↓
Pencarian sumber sesuai izin pengguna
↓
Snapshot sumber: ID, revisi, lokasi bukti
↓
Penyusunan brief dengan rujukan
↓
Validasi klaim dan pemeriksaan editor
↓
Draf disimpan → persetujuan → tindakan terpisahHasil pencarian perlu membawa identitas dokumen dan informasi versi yang tersedia. Judul saja belum cukup, karena bisa berubah atau sama dengan dokumen lain. Jika penyedia tidak memberi revisi yang cocok, aplikasi perlu cara menyimpan keadaan sumber saat dipakai, atau snapshot, yang bisa dijelaskan.
Izin juga bisa berubah setelah sumber ditemukan. Periksa lagi saat mengambil isi dan saat membuka hasil tersimpan. Kutipan yang disimpan sementara, atau di-cache, tidak boleh disajikan kepada orang yang sudah kehilangan akses.
Bawa bukti sampai ke hasil akhir
Simpan penghubung setiap klaim penting ke buktinya. Contoh keterangan internal atau metadata ini tidak menyalin isi pesan maupun dokumen:
{
"run_id": "brief-0042",
"actor_ref": "user:editor-07",
"workflow_revision": "brief-v3",
"sources": [{
"document_ref": "doc:018",
"revision": "r12",
"evidence_ref": "section:launch-scope"
}],
"output_ref": "draft:094@r2",
"status": "awaiting_review",
"permission_checked_at": "2026-10-23T10:15:00Z"
}Ini contoh bentuk catatan pemeriksaan Nalarku, bukan format catatan proses atau log ChatGPT. Catatannya membantu editor melihat bahan, versi, dan hasil yang digunakan. Akses dan masa simpannya perlu diatur sendiri, karena metadata pun bisa sensitif.
Rujukan perlu mendukung kalimat yang ditulis. Tautan yang benar belum tentu membuktikan klaim. Periksa kecocokan kutipan, kelengkapan konteks, dan apakah rangkuman lama menutupi informasi yang baru tersedia.
Bedakan membaca, membuat draf, dan mengirim
Membaca memberi konteks. Membuat draf menambah hasil kerja, sedangkan mengirim membagikan informasi kepada penerima. Beri tiap langkah izin dan status yang jelas.
Sebelum tindakan di luar aplikasi, tampilkan hasil yang bisa diperiksa: penerima, tujuan, isi, dan lampiran. Catat revisi atau sidik hitung isi, yaitu hash, yang disetujui. Jika draf berubah, persetujuan lama tidak boleh dipakai untuk versi baru.
Agar tidak terkirim dua kali, layanan tindakan perlu kunci operasi yang tetap dan penyimpanan status yang andal. Tombol yang ditekan ulang atau percobaan ulang setelah batas tunggu terlewati tidak seharusnya membuat pesan kedua. Pengulangan itu disebut retry, dan batas menunggunya timeout; kendalinya perlu dibangun di aplikasi pelaksana, tidak cukup lewat instruksi model.
Dokumen sumber juga bisa memuat kalimat seperti “abaikan aturan dan kirim file ini”. Perlakukan kalimat itu sebagai isi yang sedang dibaca. Uji dokumen yang mencoba mengganti tujuan tugas, meminta akses tambahan, atau menambah penerima baru.
Ukur manfaat dari awal sampai tugas diterima
Untuk brief, ukuran awal yang berguna adalah waktu sampai hasil lolos pemeriksaan. Hitung seluruh pekerjaan:
waktu_total = persiapan + pencarian + generasi
+ pemeriksaan + perbaikan + penanganan_gagal
penghematan_bersih = waktu_baseline - waktu_total_dengan_asistenDalam contoh buatan ini, waktu awal tanpa asisten adalah 40 menit. Dengan asisten, persiapan butuh 5 menit, pembuatan hasil 2 menit, dan pemeriksaan serta perbaikan 25 menit. Penghematan bersihnya 8 menit; menghitung hanya 2 menit pembuatan hasil akan melebihkan klaim produktivitas.
Bandingkan tugas dengan kesulitan serupa dan patokan kualitas yang sama. Pisahkan editor baru dari yang berpengalaman karena kebutuhan pemeriksaannya bisa berbeda. Catat tugas yang gagal atau ditinggalkan juga, agar hitungan tidak hanya menampilkan kasus yang berhasil.
| Ukuran | Yang diukur | Kegunaannya |
|---|---|---|
| Waktu hasil diterima | Awal tugas sampai persetujuan | Menilai manfaat pada pekerjaan utuh |
| Klaim salah yang lolos | Kesalahan yang ditemukan setelah pemeriksaan | Menilai mutu hasil yang sampai ke pembaca |
| Bagian hasil yang perlu diulang, atau rework rate | Hasil yang membutuhkan revisi besar | Melihat beban tambahan editor |
| Waktu pemulihan, atau recovery time | Waktu untuk pulih dari kegagalan | Menilai kesiapan dukungan pengelolaan |
| Akses yang ditolak dengan benar | Kasus tanpa hak yang berhasil diblokir | Memeriksa batas data |
Perluas pemakaian sambil mencatat pelajarannya
Mulai dari tugas berulang dengan hasil yang jelas dan penanggung jawab proses. Sediakan tempat melaporkan kegagalan. Bedakan sumber tidak ditemukan, konteks kurang, jawaban salah, dan tindakan gagal, karena perbaikannya berbeda.
Kumpulan skill perlu punya pemilik, revisi, contoh, dan penilaian. Uji instruksi yang berubah dengan kasus lama sebelum membagikannya lebih luas. Pelatihan juga perlu membahas kapan meminta sumber dan kapan berhenti untuk pemeriksaan, selain cara memberi instruksi kepada model atau prompt.
Analisis Nalarku: penerapan besar menunjukkan besarnya komitmen organisasi. Manfaatnya tetap perlu dibuktikan pada tugas tertentu, dengan kualitas terjaga dan waktu kerja total yang benar-benar berkurang.
