Human Approval Matrix & Governance Pilot Codex

Human Approval Matrix dan Governance Pilot Codex

Jawaban singkat

Human approval untuk Codex harus ditentukan berdasarkan dampak dan kemampuan membatalkan aksi. Kelasnya tiga: boleh otomatis di sandbox, wajib approval sebelum aksi material, dan dilarang bagi agent. Approval mengikat output tertentu melalui hash, mempunyai approver bernama dan expiry, serta gugur bila artefak berubah. "Ada manusia di loop" tanpa aturan itu bukan kontrol.

Tiga kelas aksi

Boleh otomatis mencakup pekerjaan reversibel di ruang terbatas: membaca data allowlist, membuat branch, menjalankan test, menyusun draft, membandingkan versi, dan menghasilkan exception queue. Syaratnya tidak ada external send, production write, credential sensitif, atau dampak pada hak seseorang.

Wajib approval mencakup perubahan yang dapat memengaruhi uang, kontrak, akses, pelanggan, pegawai, produksi, regulator, atau reputasi. Agent boleh menyiapkan candidate action dan review packet. Eksekusi dilakukan manusia atau adaptor setelah token approval valid.

Dilarang bagi agent mencakup self-approval, penggunaan credential personal, mengubah bukti setelah disetujui, menyembunyikan exception, mematikan log, dan mengambil keputusan final yang secara kebijakan harus dimiliki pejabat atau profesional. Larangan juga berlaku bila organisasi belum dapat membuat rollback atau menguji hasil secara layak.

Matriks dampak dan reversibility

Gunakan dua sumbu. Dampak rendah sampai tinggi mengukur konsekuensi finansial, legal, privacy, operasional, keselamatan, dan reputasi. Reversibility mengukur apakah aksi dapat dibatalkan cepat dan utuh. Draft internal yang belum dikirim berdampak rendah dan mudah dibalik. Transfer bank, filing, PHK, atau disclosure berdampak tinggi dan sulit atau tidak dapat dibalik.

Dampak rendah serta reversibel dapat berjalan otomatis dalam sandbox dengan sampling. Dampak sedang memerlukan checker sebelum pindah ke sistem resmi. Dampak tinggi atau sulit dibalik memerlukan approver sesuai delegation of authority, kadang lebih dari satu fungsi. Jika dampak belum diketahui, perlakukan sebagai kelas lebih tinggi sampai risk owner menilai.

Tambahkan dimensi data. Workflow yang hanya memakai data dummy berbeda dari workflow dengan data payroll atau pelanggan. Tambahkan dimensi privilege: read-only berbeda dari production write. Nilai transaksi juga memengaruhi jalur approval, tetapi threshold harus berasal dari kebijakan perusahaan, bukan angka generik dari artikel.

Maker-checker dan segregation of duties

Maker menyiapkan kandidat dan bukti. Checker memeriksa aturan serta detail. Approver mengambil keputusan sesuai kewenangan. Satu orang dapat memegang lebih dari satu peran pada pekerjaan ringan jika kebijakan mengizinkan, tetapi agent tidak boleh memalsukan pemisahan dengan menjalankan dua persona.

Pemilik agent, penulis ruleset, process owner, data owner, dan execution owner perlu dipetakan. Untuk perubahan ruleset kritis, reviewer berbeda dari pembuat. Untuk pembayaran, vendor master dan release dipisah. Untuk production change, protected branch, CI, change record, dan deploy approval tetap berlaku.

Isi review packet

Reviewer membutuhkan ringkasan tujuan dan keputusan yang diminta; identitas input dan checksum; versi aturan; diff; hasil test; exception; asumsi; sumber; dampak; expiry; serta rollback instruction. Bila output berisi ratusan baris, tampilkan agregat kontrol lalu sample dan exception. Jangan menyembunyikan raw evidence; berikan jalur untuk membukanya.

Tombol "Approve" tidak cukup jika reviewer tidak tahu apa yang disetujui. UI harus menunjukkan artefak, hash, scope aksi, target sistem, nilai atau volume, dan efek setelah eksekusi. Untuk perubahan sensitif, gunakan step-up authentication dan reason code.

Expiry, hash, dan rollback

Approval kedaluwarsa ketika waktu habis, input berubah, ruleset berubah, output berubah, approver kehilangan kewenangan, atau kondisi bisnis tidak lagi sama. Sistem memverifikasi semuanya sebelum eksekusi. Jangan memakai approval mingguan sebagai cek kosong untuk output yang belum ada.

Rollback harus spesifik. Untuk file: kembalikan commit. Untuk dashboard: pulihkan versi. Untuk master data: reverse change dengan log. Beberapa aksi tidak benar-benar dapat dibalik, seperti email terkirim, filing, transfer, atau keputusan pegawai. Karena itu gate harus lebih ketat dan dapat mensyaratkan simulasi atau dual approval.

Contoh matrix lintas fungsi

Candidate action	Kelas	Reviewer/approver	Bukti minimum
Draft variance narrative dari ekspor read-only	Otomatis di sandbox	Finance reviewer lewat sampling	totals, lineage, exception
Candidate journal	Wajib approval	Accounting checker dan controller	reconciliation, support, hash
Release pembayaran	Tidak dijalankan agent	Maker-checker-approver bank	approved payment pack
Draft kontrak dibanding playbook	Otomatis di workspace terbatas	Legal reviewer	clause diff, source version
Tanda tangan atau external send	Tidak dijalankan agent	Pejabat berwenang	final document dan authority
Draft surat HR dari template	Wajib review	HR dan pejabat terkait	employee request, template version
Final rating, PHK, promosi	Tidak diputuskan agent	Panel/pejabat manusia	proses dan bukti sesuai kebijakan
Patch kode di branch	Otomatis sampai PR	Code owner	tests, scan, diff
Merge/deploy production	Wajib approval	Engineering/change owner	CI, rollback, change record
Publikasi campaign	Wajib approval	Brand/legal/budget owner	claim check, preview, UTM

Mengukur governance pilot

Ukur kualitas kontrol, bukan jumlah output. Catat acceptance pass rate, false positive dan false negative pada exception, reconciliation difference, rework, reviewer minutes, approval rejection, override, rollback, kelengkapan evidence, serta insiden data. Target insiden data adalah nol, tetapi angka nol selama sampel kecil bukan bukti bahwa risiko hilang.

Lakukan sampling terhadap output yang diterima dan ditolak. Cari approval yang terlalu cepat, reviewer yang selalu menerima, ruleset yang sering dioverride, dan exception yang berulang. Governance yang sehat memperbaiki workflow; bukan menambah klik tanpa informasi.

Gunakan arsitektur Codex untuk mengikat gate ke pipeline dan panduan security serta UU PDP untuk batas data dan akses. Simulasi lintas fungsi dapat dimasukkan dalam pelatihan Codex untuk perusahaan.

Dasar faktual: apa yang memang dapat dilakukan Codex

[Fakta produk] OpenAI menjelaskan Codex sebagai agen software engineering. Ia dapat menerima tugas, membaca dan mengubah file di lingkungan kerja, menjalankan command, serta memakai hasil test, linter, atau type-check sebagai bukti. Pekerjaannya tetap perlu ditinjau dan divalidasi manusia sebelum perubahan diintegrasikan atau dijalankan. Dokumentasi dan repositori resmi Codex menjadi rujukan yang lebih tepat daripada demo singkat di media sosial.

Dari fakta itu, ada empat kemampuan yang relevan bagi perusahaan. Pertama, Codex bekerja pada artefak, bukan hanya percakapan. Kedua, ia dapat menjalankan langkah berurutan. Ketiga, hasilnya dapat diperiksa dengan alat yang deterministik. Keempat, ia dapat menyerahkan diff dan log agar reviewer tidak menebak apa yang berubah.

[Rekomendasi workflow] Penggunaan untuk finance, HR, legal, procurement, sales, atau operasi bukan fitur kepatuhan siap pakai dari OpenAI. Ini desain implementasi: tim menaruh skrip, template, aturan, data uji, dan instruksi kerja dalam repositori terkontrol; Codex mengolah ekspor read-only atau salinan tersanitasi; sistem resmi tetap menjadi sumber kebenaran. ERP, HRIS, Coretax, portal bank, portal regulator, dan tanda tangan pejabat tidak digantikan.

Pemisahan ini penting. Kemampuan mengedit CSV tidak berarti agent memahami kebijakan akuntansi perusahaan. Kemampuan membuat draft kontrak tidak menjadikannya penasihat hukum. Kemampuan menghasilkan file impor tidak memberinya wewenang untuk mengunggah, menandatangani, membayar, atau mengirim. Kewenangan selalu mengikuti struktur perusahaan, bukan kemampuan teknis model.

Pola kerja yang direkomendasikan

[Rekomendasi workflow] Pola yang aman dimulai dari trigger yang jelas: issue yang telah disetujui, folder masuk, jadwal closing, tiket, atau permintaan dengan pemilik. Sistem mengambil data minimum melalui path, tabel, atau domain yang diizinkan. Input dibekukan sebagai snapshot dan diberi checksum agar reviewer tahu persis bahan yang diproses.

Agent lalu membuat rencana singkat: tujuan, file yang akan disentuh, asumsi, pemeriksaan yang akan dijalankan, approval yang dibutuhkan, dan kondisi berhenti. Setelah itu barulah transformasi dilakukan di branch atau workspace terbatas. Semua template, aturan, dan instruksi seperti AGENTS.md diberi versi. Perubahan terhadap aturan tidak boleh menyelinap bersama hasil operasional.

Tahap verifikasi memakai pemeriksaan yang cocok dengan pekerjaan. Untuk data: schema, jumlah baris, total kontrol, duplikat, referential integrity, dan rekonsiliasi ke source. Untuk dokumen: kelengkapan field, nomor versi, tanggal berlaku, kutipan sumber, link, dan perbandingan dengan template. Untuk kode: unit test, integration test, lint, type-check, security scan, dan CI. Output yang lolos dikemas sebagai review packet berisi diff, exception, bukti test, hal yang belum terjawab, dan instruksi rollback.

Approval diberikan kepada artefak tertentu, bukan kepada instruksi samar. Identitas file, versi input, dan hash output dicatat. Jika isi berubah setelah approval, persetujuan batal dan harus diminta ulang. Eksekusi ke sistem resmi memakai adaptor terpisah dan service account terbatas. Setelah aksi, sistem merekonsiliasi hasil dan menyimpan evidence: siapa menyetujui, kapan, versi apa, hasil apa, serta apakah rollback diperlukan.

Acceptance checks yang layak dipakai

Acceptance check harus dapat menjawab "lulus atau gagal" tanpa bergantung pada rasa percaya kepada agent. Pemeriksaan minimum berikut dapat disesuaikan:

input berasal dari snapshot yang teridentifikasi dan tidak berubah selama run;
hanya path, tabel, command, dan domain allowlist yang diakses;
schema, tipe data, jumlah baris, serta total kontrol cocok dengan sumber;
exception tidak disembunyikan dalam output sukses;
dokumen memakai template dan versi aturan yang berlaku;
setiap klaim faktual memiliki sumber yang dapat dibuka;
seluruh test wajib berstatus lulus dan log mentah tersedia;
diff hanya menyentuh file yang tercantum dalam rencana;
review packet menyebut asumsi, limitasi, dan item yang perlu keputusan;
output yang disetujui mempunyai hash, approver, waktu kedaluwarsa, dan rollback instruction;
aksi pada sistem resmi direkonsiliasi terhadap paket yang disetujui;
data sementara dan log mengikuti jadwal retensi serta penghapusan.

Jangan memakai skor "confidence 95%" sebagai pengganti bukti. Angka tanpa kalibrasi pada kasus lokal tidak membantu approver. Tampilkan sumber, perbedaan, dan exception. Biarkan orang yang berwenang memutuskan.

Tindakan yang tetap di tangan manusia

Ada tindakan yang tidak layak diserahkan kepada agent, sekalipun output awalnya sering benar. Transfer uang, payroll release, perubahan rekening vendor atau pegawai, kredit, dan refund material harus melewati otorisasi manusia. Filing pajak atau regulator, deklarasi kepatuhan, token, sertifikat, serta tanda tangan elektronik juga tetap human-gated.

Kontrak, PO, offer letter, PHK, disiplin, rating kinerja, promosi, dan kompensasi final membutuhkan pejabat yang berwenang. Begitu pula pemilihan vendor, penyelesaian konflik kepentingan, publikasi eksternal, pernyataan media, production deploy, privileged command, account disable, tindakan containment destruktif, opini hukum, penerimaan risiko, opini audit, dan keputusan berdampak pada individu berdasarkan profiling.

Atur maker-checker secara nyata. Agent tidak boleh menjadi maker sekaligus checker hanya karena dua prompt dijalankan terpisah. Approver harus berbeda dari pemilik konfigurasi agent untuk aksi berisiko tinggi. Approval memiliki batas nilai, ruang lingkup, dan waktu. Sediakan kill switch serta jalur manual bila sistem gagal.

Security dan privasi minimum

Data perusahaan tidak otomatis aman hanya karena workflow berada di balik login. Petakan alirannya: dari mana input berasal, data apa yang ikut, di mana diproses, siapa yang dapat membaca log, berapa lama disimpan, dan ke mana output dikirim. Klasifikasikan data sebelum memilih tool. Terapkan purpose limitation, minimization, redaction atau tokenization, dan larang secrets masuk ke prompt, file kerja, screenshot, maupun log.

Gunakan SSO dan MFA bila tersedia, least privilege, service account terpisah, vault untuk secrets, serta elevasi berbatas waktu. Sandbox adalah default. Hak tulis dibatasi ke workspace yang memang dibutuhkan. Network deny-by-default lalu buka domain yang disetujui. Catat egress. Jangan menaruh credential produksi di lingkungan agent.

Dokumen, email, issue, dan halaman web adalah input tak tepercaya. Isinya dapat memuat instruksi yang mencoba mengubah perilaku agent. Pisahkan konten dari instruksi sistem, hilangkan active content, batasi ekstraksi, tandai provenance, dan minta review sebelum konten memicu aksi. Pin dependency, pindai package, tinjau connector pihak ketiga, dan gunakan branch terproteksi untuk konfigurasi penting.

[Konteks resmi Indonesia] UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur pemrosesan data pribadi, hak subjek data, kewajiban pengendali dan prosesor, perlindungan, serta penanganan pelanggaran. PP Nomor 71 Tahun 2019 memberi baseline penyelenggaraan sistem dan transaksi elektronik. Implementasi konkret tetap perlu diperiksa terhadap aturan pelaksana dan regulator sektor. Untuk HR, payroll, pelanggan, kesehatan, keuangan, monitoring, atau profiling, lakukan pemetaan data dan penilaian dampak yang proporsional sebelum pilot.

Cara menjalankan review mingguan

Tinjau sepuluh run secara acak dan seluruh run yang gagal. Bandingkan input, output, diff, serta keputusan reviewer. Kelompokkan kegagalan menjadi masalah data, aturan, tool, akses, atau judgment. Jangan langsung memperbaiki prompt bila sumbernya adalah master data yang buruk atau SOP yang bertentangan. Tetapkan owner dan tanggal perbaikan.

Periksa juga perilaku reviewer. Approval yang selalu lolos dalam hitungan detik adalah sinyal kontrol semu. Gunakan calibration case: dua reviewer menilai paket yang sama, lalu membahas perbedaan. Hasilnya dapat dipakai untuk memperjelas acceptance criteria dan escalation path.

Kondisi berhenti yang sering terlupakan

Agent harus berhenti ketika input tidak lengkap, schema berubah, total kontrol selisih, sumber tidak dapat ditelusuri, instruksi dokumen bertentangan dengan policy, akses baru diperlukan, atau aksi keluar dari scope. Status berhenti harus informatif: apa yang gagal, bukti, risiko bila diteruskan, dan siapa yang dapat menyelesaikannya.

Jangan mengubah stop menjadi warning hanya agar demo tampak mulus. Dalam operasi, kemampuan menolak pekerjaan yang tidak aman sama pentingnya dengan kemampuan menyelesaikan kasus normal. Ukur jumlah stop yang benar, stop palsu, serta kasus berisiko yang lolos.

Sumber primer

Regulasi dan dokumentasi produk dapat berubah. Periksa versi terbaru serta aturan sektor sebelum implementasi.

Langkah berikutnya

Jika tim Anda ingin mengubah satu use case menjadi workflow yang dapat diuji, direview, dan dihentikan dengan aman, diskusikan Pelatihan AI untuk Perusahaan. Fokus awalnya bukan demo sebanyak mungkin, melainkan satu pilot yang punya owner, acceptance checks, approval, dan evidence yang jelas.

Tags: #Human in the Loop #Codex #AI Governance #Internal Control #Risk Management

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital