SocialHub.AI
Baru · diluncurkan per ruang kerja

Tata Kelola AI: Introspeksi & Persetujuan

Flash menempatkan setiap tindakan yang diinisiasi AI di balik mekanisme otorisasi per tindakan — auto, review atau forbidden — yang dikonfigurasi per ruang kerja di konsol Aktivitas & Persetujuan AI. Bagi klien AI melalui MCP, ini berarti dua hal: Anda dapat menemukan objek bisnis dan tindakan yang diizinkan untuk Anda lakukan sebelum bertindak, dan panggilan penulisan Anda mengembalikan hasil terstruktur — dieksekusi, menunggu persetujuan manusia, atau ditolak dengan alasan yang dapat dibaca mesin.

Panduan ini mencakup alat introspeksi, semantik penulisan di bawah mekanisme peninjauan, dan siklus hidup persetujuan. Ini dibangun di atas server MCP yang diatur yang didokumentasikan dalam panduan Integrasi MCP. Untuk gambaran umum bisnis, lihat halaman produk AI Governance & Approvals. Pengaturan routing diaktifkan secara bertahap — perilaku di bawah ini berlaku saat tindakan yang diatur diluncurkan ke ruang kerja Anda.

Introspeksi Bisnis object (cakupan introspection:read)

Tiga alat baca memungkinkan klien AI mempelajari bentuk bisnis sebelum menyentuhnya: objek mana yang ada (termasuk bidang kustom dan objek kustom ruang kerja sendiri), apa arti setiap atribut, bagaimana objek saling terkait, dan tindakan mana yang dapat dieksekusi — dengan prasyarat dan perlengkapan saat ini. Agen yang berperilaku baik akan memanggil ini terlebih dahulu dan hanya mengusulkan tindakan yang benar-benar diizinkan oleh perlengkapan tersebut.

list_objectsbaca

Temukan objek bisnis yang tersedia untuk ruang kerja kunci: anggota, pesanan, kupon, kampanye, toko, produk, segmen, tag — ditambah objek kustom apa pun yang telah ditentukan ruang kerja. Mengembalikan kunci, label, dan arti satu baris untuk setiap object. Panggil terlebih dahulu untuk mempelajari apa yang ada sebelum membaca atau bertindak.

Parameter: (none)
describe_objectbaca

Bentuk lengkap dari object: atributnya (termasuk bidang kustom ruang kerja) dengan tipe dan makna bisnisnya, dan hubungannya dengan objek lain (misalnya, pesanan milik anggota; kupon dapat diterbitkan untuk anggota). Bidang PII dikembalikan hanya sebagai metadata — nama, tipe, semantik, dan bendera pii — tidak pernah nilainya.

Parameter: object
list_actionsbaca

Tindakan yang dapat dilakukan oleh klien AI, dengan prasyarat setiap tindakan dan perlengkapan otorisasi saat ini (otomatis / tinjau / dilarang) seperti yang dikonfigurasi oleh ruang kerja. Filter berdasarkan object untuk hanya melihat tindakan yang terkait dengannya. Apa yang dikembalikan persis seperti yang akan diberlakukan oleh lapisan tata kelola — gunakan ini untuk menghindari pengajuan tindakan yang akan ditolak.

Parameter: object?

PII hanya berupa metadata, sesuai desain. Introspeksi menjelaskan bidang yang menyimpan informasi pribadi (nama, jenis, arti, dan bendera pii) tetapi tidak pernah mengembalikan nilainya. Membaca data anggota sebenarnya dilakukan melalui alat baca anggota dan cakupannya sendiri.

Contoh: jelaskan object, lalu periksa roda giginya

Contoh deskriptif bentuk permintaan/respons (disingkat — respons sebenarnya mencantumkan setiap bidang dan tindakan):

// describe_object { "object": "member" }
{
  "object": "member",
  "label": "Member",
  "meaning": "A loyalty program member owned by this workspace.",
  "fields": [
    { "name": "email",            "type": "string",  "pii": true,
      "meaning": "Contact email. PII: metadata only — values are never returned here." },
    { "name": "tier",             "type": "string",  "pii": false,
      "meaning": "Current loyalty tier." },
    { "name": "membership_no",    "type": "string",  "pii": false, "custom": true,
      "meaning": "Workspace-defined custom field." }
  ],
  "relationships": [
    { "to": "order",  "kind": "has_many",  "meaning": "Orders placed by this member." },
    { "to": "coupon", "kind": "has_many",  "meaning": "Coupons issued to this member." },
    { "to": "tag",    "kind": "has_many",  "meaning": "Tags currently applied to this member." }
  ]
}
// list_actions { "object": "member" }
{
  "actions": [
    { "action": "issue_coupon",     "gear": "review",
      "preconditions": ["member has consent", "coupon pool has stock"] },
    { "action": "earn_points",      "gear": "auto",
      "preconditions": ["amount within the workspace cap"] },
    { "action": "assign_tag",       "gear": "auto",
      "preconditions": ["tag exists and is active"] },
    { "action": "add_member_note",  "gear": "auto",
      "preconditions": ["note passes server-side sanitation"] },
    { "action": "send_campaign",    "gear": "review", "locked": true,
      "preconditions": ["sending can never be auto — a human always approves"] }
  ]
}

gear yang Anda lihat adalah perlengkapan yang akan diberlakukan — ruang kerja mengkonfigurasinya per tindakan di konsol, dan pemutus sirkuit per tindakan dapat menurunkan tindakan ke review kapan saja (hanya turun secara otomatis; hanya manusia yang dapat mengembalikannya). Periksa kembali dengan list_actions daripada menyimpan perlengkapan untuk sesi yang panjang.

Tuliskan alat di bawah perlengkapan peninjauan: tertunda / ditolak

Ketika alat tulis MCP menargetkan tindakan yang perlengkapannya adalah review, panggilan tersebut tidak mengeksekusi efek samping. Ia mengembalikan hasil terstruktur: proposal tersebut dimasukkan dalam antrian untuk persetujuan manusia (pending), atau ditolak mentah-mentah (refused) dengan reason_code dan suggested_action yang dapat dibaca mesin.

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}
// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}
reason_codeArtiApa yang harus dilakukan agen Anda
gear_forbiddenPengaturan tindakan diatur ke terlarang untuk ruang kerja ini (atau tindakan tersebut tidak pernah dapat otomatis — misalnya, mengirim — dan dipanggil dengan cara yang membutuhkan otomatis).Jangan coba lagi. Munculkan penolakan tersebut; tindak lanjuti. suggested_action (biasanya tindakan alternatif atau 'meminta seseorang untuk mengganti gigi').
recently_rejectedSeorang manusia baru-baru ini menolak proposal yang sama untuk target yang sama — platform tidak akan mengantrekannya kembali.Hormati keputusan manusia. Jangan mengusulkan ulang atau mengubah kata-katanya; ikuti saja. suggested_action.

Setiap penolakan membawa reason_code dalam bentuk ini ditambah suggested_action — perlakukan kode di atas sebagai kode yang akan digunakan untuk percabangan dan bidang tersebut sebagai bidang yang dapat diperluas. Penolakan adalah batasan tegas yang harus Anda pahami, bukan kesalahan yang perlu dicoba lagi: jangan pernah mengubah kata-kata dalam proposal untuk menghindari penolakan.

Siklus persetujuan

Proposal pending diselesaikan dengan satu cara: approved, rejected, atau expired. Manusia bertindak atas proposal tersebut di konsol Aktivitas & Persetujuan AI (tunggal atau batch berdasarkan jenis tindakan); email ringkasan harian menampilkan apa yang menunggu.

StatusBagaimana hal itu terjadiKemudian
pendingAlat tulis dipanggil saat mekanisme tindakan sedang ditinjau — proposal tersebut diantrekan untuk persetujuan manusia.disetujui · ditolak · kedaluwarsa
approvedManusia telah menyetujuinya. Sebelum dieksekusi, platform memvalidasi ulang alasan yang dinyatakan oleh AI; jika alasan tersebut tidak lagi berlaku (misalnya, pelanggan telah membeli kembali), tindakan tersebut tidak dieksekusi.terminal (hasil dicatat dalam log keputusan; dapat dicabut secara individual)
rejectedSeorang manusia menolaknya, opsional dengan catatan. Proposal yang sama kemudian ditolak dengan keterangan recently_rejected jika diajukan kembali.terminal
expiredTidak ada keputusan dalam 7 hari — proposal kedaluwarsa dengan sendirinya dan tidak ada yang dieksekusi.terminal

Jaminan idempotensi

  • Satu persetujuan, satu eksekusi. Menyetujui proposal mengeksekusi tindakannya tepat satu kali; persetujuan berulang memutar ulang hasil yang tersimpan tanpa efek samping kedua.
  • Pengiriman ulang tidak menduplikasi. Memanggil alat tulis lagi untuk proposal yang sama saat masih tertunda akan menghasilkan hasil pending dan proposal_id yang sama — tidak mengantrekan kartu kedua.
  • Persetujuan divalidasi ulang, eksekusi bersifat kondisional. Pada saat persetujuan, platform memeriksa ulang apakah alasan yang dinyatakan AI masih berlaku; jika tidak lagi berlaku (misalnya, pelanggan sudah membeli kembali), tidak ada yang dieksekusi — hasilnya dicatat sebagai pengganti tindakan.
  • Semuanya diaudit dan dapat dicabut secara individual. Proposal, keputusan, jalur otorisasi (auto atau manusia yang ditunjuk), eksekusi, dan hasil semuanya tercatat dalam log keputusan, di mana satu entri dapat dibatalkan.

Server adalah batasnya. Mekanisme, validasi ulang, kedaluwarsa, dan pemutus sirkuit per tindakan diberlakukan di sisi Flash — tidak pernah dipercayakan pada penalaran agen atau konfirmasi sisi kliennya. Tindakan tipe pengiriman tidak pernah dapat dijalankan secara otomatis, apa pun yang diminta klien.

Primitif transparansi & inventaris model kotak kaca

Disiplin kotak kaca yang sama — setiap keputusan otomatis dicatat dan dapat dijelaskan, data pribadi dijauhkan dari konteks model — meluas melampaui tindakan yang diatur: untuk bereksperimen dengan optimasi lalu lintas, untuk permintaan LLM keluar, dan untuk inventaris model ML klasik yang mendukung pemeringkatan, prediksi, dan deteksi di seluruh produk.

Optimasi otomatis lalu lintas A/B: log keputusan

Kampanye berulang (otomatisasi dan perjalanan) dapat memilih untuk Mengoptimalkan lalu lintas secara otomatis dari waktu ke waktu, yang mengalokasikan ulang bobot pengiriman di seluruh varian eksperimen berdasarkan kinerja klik yang diamati. Setiap pengalokasian ulang dapat diaudit:

  • Log keputusan hanya-tambah. Setiap penghitungan ulang per jam menulis satu catatan dengan bobot yang diterapkan dan alasan yang mudah dibaca manusia. Catatan tidak pernah ditulis ulang — log adalah riwayat lengkap mengapa lalu lintas terlihat seperti itu.
  • Pembagian yang dikonfigurasi tidak pernah diubah. Pembagian yang dikonfigurasi untuk eksperimen Anda tetap tidak berubah sebagai dasar; bobot yang dioptimalkan dihitung dan dicatat bersamaan dengannya.
  • Batas eksplorasi: 10%. Bobot setiap varian tidak pernah turun di bawah 10%, sehingga setiap varian terus menerima trafik dan pembalikan tetap terdeteksi.
  • Pembagian merata hingga ≥100 pengiriman per varian. Bobot tetap pada pembagian yang dikonfigurasi hingga setiap varian memiliki setidaknya ~100 pengiriman — tidak ada alokasi ulang pada data tipis, dan tidak ada "pemenang" statistik yang pernah diumumkan oleh mekanisme ini.

Penyembunyian PII LLM di batas penyedia

Sebelum setiap permintaan meninggalkan Flash untuk penyedia LLM eksternal, pengidentifikasi pribadi anggota disembunyikan — diterapkan pada batas penyedia, sehingga setiap fitur AI melewatinya:

  • Nama samaran deterministik. Alamat email, nomor telepon, dan deretan angka seperti kartu digantikan dengan token pengganti yang stabil. Pengidentifikasi yang sama selalu dipetakan ke nama samaran yang sama, sehingga penalaran model di seluruh permintaan tetap koheren.
  • Masking berlaku untuk setiap permintaan keluar dari setiap fitur AI — tidak ada yang perlu diaktifkan, dan tidak dapat dimatikan dari produk.
  • Hanya masker, tidak pernah dibuka. Pemetaan bersifat satu arah pada batas keluaran: keluaran model tidak pernah ditulis ulang untuk mengembalikan pengidentifikasi sebenarnya, sehingga PII mentah tidak dapat bolak-balik melalui respons LLM.

Mengapa ini penting hari ini. Perintah AI Flash dibangun dari agregat dan data kampanye, bukan catatan pribadi — celah penyamaran adalah jaminan yang diberlakukan yang tetap berlaku seiring berkembangnya fitur AI, bukan tambalan untuk kebocoran.

Inventaris model kotak kaca

Setiap kemampuan prediktif atau statistik dalam produk adalah model deterministik klasik — tidak ada penilaian kotak hitam, tidak ada pengambilan sampel, sehingga data yang sama selalu menghasilkan model yang sama. Masing-masing membawa gerbang kejujuran eksplisit: di bawah gerbang tersebut, ia memancarkan nothing alih-alih tebakan, dan setiap skor dikirimkan dengan angka-angka yang diperlukan untuk menghitung ulang. Inventaris saat ini:

ModelPowersPintu kejujuran
Peningkatan dua model (dua penyesuaian logistik deterministik)SoClaw peringkat daftar kerja pemulihan pelanggan — nilai-berisiko × peningkatan, dilatih pada RCT pengujian berkelanjutan program itu sendiriHanya mengaktifkan ≥200 baris yang diproses dan matang, ≥50 baris yang ditahan, dan ≥20 konversi, dengan kedua kecocokan tersebut konvergen — di bawah itu, peringkat kembali ke nilai risiko murni. Anggota dengan peningkatan negatif (jangan diganggu) akan tenggelam; setiap tugas menyimpan cuplikan skornya.
Gamma antar-pembelian per anggota (metode momen)Tanggal pembelian berikutnya yang diharapkan pada profil + kondisi segmen “Hari Hingga Pembelian Berikutnya yang Diharapkan” (negatif = terlambat)Membutuhkan ≥3 celah yang diamati (yaitu ≥4 pembelian) dan gerbang koefisien variasi (≤1,5) pada keteraturan ritme — pembeli yang tidak teratur akan mendapatkan NULL, bukan tanggal yang dibuat-buat. Tanggal yang diharapkan di masa lalu akan dipancarkan sebagai sinyal keterlambatan yang jujur.
Regresi logistik L2-teratur per timKecenderungan klik (0–100), disesuaikan setiap malam berdasarkan pengiriman 90 hari terakhir tim sendiri.Label hanya klik (tidak pernah dibuka — Apple MPP memperbesarnya); fitur klik sebelumnya yang dijaga kebocorannya; penurunan gradien batch penuh deterministik pada jadwal tetap. Gerbang kecocokan ≥500 pengiriman / ≥30 klik / ≥50 anggota; sebuah anggota membutuhkan ≥3 pengiriman terbaru untuk diberi skor.
Item kNN yang dinormalisasi kosinusPemasangan produk "juga dibeli" di seluruh permukaan rekomendasico_count / √(pembeli(A) × pembeli(B)) mengoreksi bias popularitas; pasangan membutuhkan ≥2 pembeli bersama untuk terwujud; jumlah pembelian bersama mentah disimpan bersama skor sebagai bukti yang dapat diperiksa.
Aturan asosiasi (dukungan / kepercayaan / peningkatan)Saran penjualan silang, yang diambil setiap malam dari baris pesanan pedagangSuatu aturan membutuhkan ≥3 pesanan yang terjadi bersamaan dan kepercayaan ≥5%; setiap aturan menyimpan jumlah pesanan mentah yang menjadi sumbernya, sehingga angka apa pun dapat dihitung ulang secara manual. Permukaan profil anggota mengecualikan produk yang sudah dimiliki dan hanya ditampilkan untuk pembeli aktif.
Pencilan statistik yang kuat (median / MAD)Itu behavior_outlier detektor kecurangan poinPersyaratan z yang kuat ≥ 6 ditambah batas bawah absolut (≥10 transaksi perolehan; tim dengan kurang dari 50 anggota aktif dilewati); deduplikasi per anggota berdasarkan bulan; hanya pembekuan — ini membuka tinjauan dan tidak pernah membatalkan dengan sendirinya.
Bahaya proporsional Kaplan-Meier + Cox (kemungkinan parsial Nelder-Mead)Retensi berdasarkan kelompok pendaftaran bulanan + panel “korelasi retensi dengan apa”Definisi tercetak pada tampilan: pelanggan berhenti berlangganan = 90 hari tanpa pembelian, pelanggan yang tidak pernah membeli dikecualikan, kelompok di bawah 30 anggota disembunyikan dan diungkapkan. Model Cox membutuhkan ≥30 kejadian berhenti berlangganan yang diamati dan dibatasi hingga 3 kovariat; korelasi diberi label korelasi, bukan sebab-akibat.
Holt-Winters (musiman mingguan, konstanta tetap)Prospek pendapatan 14 hari ke depan di dasborKonstanta penghalusan tetap — tidak ada permukaan penyetelan per tim; membaca metrik pendapatan bersertifikat yang sama seperti setiap layar lainnya; garis putus-putus + pita kesalahan dengan basis dolarnya tercetak; sepenuhnya tersembunyi di bawah riwayat 4 minggu; diberi label proyeksi, bukan komitmen.

Tidak satu pun dari model ini yang bertindak sendiri: mereka memberi peringkat, memberi skor, dan menandai, dan segala sesuatu yang menggerakkan uang atau menghubungi anggota masih melewati mekanisme tindakan yang diatur di atas.

Untuk detail teknik lengkap pada setiap model — metode, input, kolom output, gerbang kejujuran, dan permukaan konsumsi — lihat Referensi Model Prediktif.