Checklist Memilih atau Membangun Produk AI Second Brain

Vendor menunjukkan chatbot yang hafal nama anggota tim, bisa mencari dokumen, dan membuat email. Kelihatannya siap dipakai. Tiga pertanyaan kemudian, demo mulai retak: apakah memory dapat dikoreksi, apakah task bisa lanjut setelah restart, dan apakah agent bisa membedakan hak baca dengan hak mengirim?

Label second brain terlalu longgar untuk dijadikan kriteria pembelian. Tim perlu menguji kemampuan yang konkret. Checklist ini berlaku untuk membeli SaaS maupun membangun sendiri.

Mulai dari masalah, bukan stack

Tulis satu workflow yang ingin diperbaiki. Sebutkan aktor, sumber data, keputusan berulang, titik handoff, action, dan biaya error. "Membuat perusahaan lebih pintar" tidak dapat dievaluasi. "Mengurangi waktu onboarding account manager dari tiga hari menjadi empat jam tanpa retrieval lintas client" dapat diuji.

Second brain adalah gabungan state, memory terkurasi, retrieval, context engineering, tools, action, dan governance. Tidak semua use case membutuhkan semuanya. Jika kebutuhan hanya pencarian SOP, knowledge base dengan RAG mungkin cukup dan lebih murah.

1. Outcome dan batas sistem

• Apa workflow spesifik yang dibantu?
• Siapa owner bisnis dan teknisnya?
• Apa metrik awal: waktu handoff, error, resolution time, atau task terlambat?
• Keputusan apa yang tidak boleh diambil agent?
• Kapan manusia wajib masuk?

Minta vendor menyebutkan batas produk. Jawaban "bisa untuk semua departemen" adalah sinyal sales, bukan desain. Produk yang matang tahu kapan ia hanya mencari, kapan membuat draft, dan kapan berhenti.

2. Memory dan lifecycle

Periksa apakah sistem membedakan histori chat, workflow state, user preference, fakta, pengalaman, dan policy. Tidak harus memakai istilah akademis, tetapi perilakunya harus berbeda.

• Apa yang otomatis disimpan?
• Apakah setiap memory punya source, timestamp, scope, dan status?
• Dapatkah user melihat alasan memory dibuat?
• Bagaimana koreksi, supersede, expiry, dan deletion bekerja?
• Apakah procedural memory dibatasi hak tulisnya?
• Apakah temporary chat benar-benar tidak dipakai sebagai memory?

Uji langsung. Masukkan fakta yang salah, koreksi, lalu mulai sesi baru. Lihat versi mana yang diambil dan apakah histori perubahan tersedia.

3. Retrieval dan context

Vector search bukan jawaban lengkap. Tanyakan dukungan metadata filter, keyword/full-text, reranking, structured query, citation, serta authorization.

• Apakah permission diperiksa sebelum retrieval?
• Bisakah data dua tenant terisolasi secara kuat?
• Bagaimana dokumen kedaluwarsa diturunkan atau diblokir?
• Bisakah pengguna melihat sumber yang dipakai?
• Bagaimana sistem menghadapi sumber yang konflik?
• Apakah context dikompaksi dan diambil just-in-time?

Buat evaluation set dari pertanyaan nyata, termasuk kasus dengan nama mirip dan versi lama. Nilai retrieval dahulu, baru kualitas jawaban. Model tidak bisa memperbaiki sumber yang salah secara konsisten.

4. State dan continuity

Memory tentang user tidak sama dengan state pekerjaan. Untuk workflow panjang, tanyakan:

• Apakah ada checkpoint yang durable?
• Bisakah task resume setelah timeout, restart, atau pergantian operator?
• Apakah artifact dan hasil tool disimpan terpisah dari chat?
• Bagaimana retry dan idempotency ditangani?
• Apakah approval pending tetap aman setelah proses dilanjutkan?
• Dapatkah state dibatalkan atau di-rollback?

Simulasikan kegagalan di tengah workflow. Produk yang hanya lancar selama satu sesi belum menyelesaikan continuity.

5. Tools dan action

Daftar semua tool dan permission-nya. Tool yang terlalu generik memperbesar blast radius.

• Apakah read, draft, dan execute dipisah?
• Apakah parameter divalidasi di luar model?
• Credential memakai least privilege?
• Action mana yang memerlukan approval spesifik?
• Apakah hasil diverifikasi dari environment?
• Adakah timeout, rate limit, stopping condition, dan kill switch?
• Apakah operasi destructive punya rollback atau backup?

Untuk pembelian, minta demonstrasi refusal dan approval, bukan hanya success path. Agent yang aman harus mampu berhenti.

6. Security, privacy, dan governance

Petakan data sensitif, lokasi penyimpanan, subprocessors, encryption, retention, backup, serta incident response. Periksa SSO, RBAC/ABAC, secret management, tenant isolation, dan audit export.

Tanyakan apakah data digunakan untuk training, bagaimana opt-out bekerja, dan apa yang terjadi pada embedding serta cache ketika data dihapus. Minta bukti kontrol yang relevan, tetapi jangan menganggap sertifikat menggantikan pengujian arsitektur.

Untuk build sendiri, buat data owner dan policy owner. Untuk SaaS, perjelas pembagian tanggung jawab. Vendor mengamankan platform; pelanggan tetap bertanggung jawab atas permission connector dan workflow yang dibuat.

7. Observability dan evaluasi

Minimal, tim harus bisa melihat state transition, memory read/write, retrieval source, tool call, approval, error, dan artifact. Log perlu redaction dan retention tersendiri.

Bangun eval set sebelum rollout. Masukkan happy path dan adversarial path: prompt injection di dokumen, cross-tenant query, policy basi, tool timeout, dan memory konflik. Ukur task success, groundedness, permission violation, human correction, latency, dan biaya.

Jangan menerima satu angka "akurasi AI". Tanyakan dataset, definisi sukses, baseline, serta distribusi error.

8. Harness dan workflow operasional

Jangan membeli atau membangun sistem yang cuma terlihat pintar saat demo. Minta harness yang bisa mengulang kasus nyata, kasus gagal, dan kasus berisiko dengan hasil yang dapat dibandingkan. Minimal harus ada evaluation set, expected behavior, log sumber, snapshot state, validasi parameter tool, dan regression test.

Workflow juga harus kelihatan ujung ke ujung: plan, build, test, review, approval, execute, verifikasi. Bukan agent diberi prompt lalu dilepas. Setiap langkah perlu owner, acceptance criteria, timeout, retry, dan stopping condition. AI boleh ngebut; kontrol kualitas tetap di kita.

Tes harness ketika model, prompt, connector, policy, atau schema memory berubah. Kalau vendor tidak bisa menunjukkan apa yang diuji dan bagaimana regresi dideteksi, klaim akurasi mereka belum cukup. No bs: sistem yang tidak repeatable belum layak memegang workflow penting.

9. Economics dan exit plan

Hitung biaya model, embedding, storage, connector, observability, evaluasi, serta review manusia. Volume memory cenderung naik; retention yang buruk membuat biaya dan risiko tumbuh bersamaan.

• Berapa biaya per workflow selesai, bukan per token saja?
• Apakah model dan storage dapat diganti?
• Bisakah memory, metadata, audit, serta artifact diekspor?
• Apa format ekspornya?
• Bagaimana deletion saat kontrak berakhir?
• Apakah ada lock-in pada connector atau prompt proprietary?

Build sendiri memberi kontrol, tetapi menambah beban operasi. Buy mempercepat implementasi, tetapi perlu exit plan. Pilihan hybrid sering masuk akal: source dan policy tetap milik perusahaan, sementara inference atau UI memakai vendor.

Fakta versus interpretasi

Fakta: NIST AI RMF menyusun aktivitas Govern, Map, Measure, dan Manage. Anthropic menyarankan mulai dari solusi sesederhana mungkin dan menambah kompleksitas hanya ketika hasil membaik. Dokumentasi OpenAI menunjukkan conversation state adalah hal yang dikelola dalam aplikasi/API.

Interpretasi: tidak ada skor universal yang membuat produk otomatis layak disebut second brain. Bobot harus mengikuti risiko workflow. Sistem content research dan sistem pembayaran tidak boleh dinilai dengan threshold sama.

Fakta: MCP membantu interoperabilitas tools dan data. Interpretasi: dukungan MCP bagus untuk portability, tetapi daftar server tanpa permission review justru dapat memperlebar attack surface.

Build, buy, atau hybrid?

Pilih buy bila workflow relatif standar, kecepatan penting, dan kontrol vendor memenuhi kebutuhan. Pilih build bila memory model, permission, atau integrasi adalah diferensiasi inti dan tim sanggup mengoperasikan evaluasi serta security. Pilih hybrid bila data, policy, dan audit harus tetap internal, tetapi tim ingin memakai model atau orchestration terkelola.

Rekomendasi default: lakukan pilot sempit dengan arsitektur yang mudah dibuang. Hindari migrasi semua dokumen sebelum eval membuktikan nilai. Gunakan data sintetis atau subset terkontrol lebih dulu, lalu naikkan sensitivitas bertahap.

Red flags saat demo

Waspadai klaim "unlimited memory" tanpa lifecycle, "fully autonomous" tanpa action tier, dan "enterprise secure" tanpa jawaban soal isolation. Citation yang hanya menunjuk satu dokumen juga belum membuktikan potongan yang dipakai benar.

Red flag terbesar adalah tidak adanya jalur koreksi. Semua sistem akan salah. Pertanyaan profesional bukan apakah error terjadi, tetapi seberapa cepat ditemukan, seberapa jauh dampaknya, dan apakah ia dapat dibersihkan sampai turunannya.

Skenario demo yang wajib diminta

Jangan membiarkan vendor memilih seluruh jalan cerita. Siapkan paket kecil berisi dua tenant, dua versi policy, satu fakta yang kemudian dikoreksi, dan workflow yang terputus di tengah. Minta produk mencari jawaban, menunjukkan sumber, melanjutkan task setelah sesi baru, lalu menghapus satu memory. Terakhir, gunakan user tanpa izin untuk mencoba membaca tenant lain.

Nilai perilaku, bukan kepiawaian presenter. Apakah sumber lama ditolak? Apakah koreksi mempertahankan histori? Apakah approval masih terikat pada objek yang sama setelah resume? Apakah penghapusan mencakup turunan? Simpan screen recording dan export log agar tim teknis dapat memeriksa klaim setelah rapat.

Scorecard yang tidak mudah dimanipulasi

Beri bobot sesuai workflow. Untuk riset konten, groundedness dan ekspor sumber mungkin lebih berat daripada latency. Untuk finance, isolation, approval, dan audit harus menjadi gate: nilai bagus di fitur lain tidak dapat menutup kegagalan kontrol dasar. Tandai setiap jawaban sebagai terbukti dalam demo, terbukti lewat dokumen, hanya dijanjikan, atau tidak tersedia.

Lakukan reference check dengan pertanyaan yang spesifik: berapa lama deletion selesai, error paling sering apa, dan berapa jam per minggu untuk merawat evaluasi? Pelanggan yang sudah melewati enam bulan operasi memberi gambaran berbeda dari studi kasus peluncuran.

Keputusan setelah pilot

Tulis memo satu halaman: metrik sebelum dan sesudah, insiden, biaya per workflow, pekerjaan manual yang masih wajib, serta risiko yang belum ditutup. Keputusan "belum" sah jika source atau permission belum siap. Jangan memaksakan ROI positif dengan mengabaikan waktu review manusia.

Kontrak juga perlu memuat exit drill. Ekspor memory beserta metadata, artifact, dan audit; impor subset ke tempat netral; lalu verifikasi deletion di vendor. Exit plan yang belum pernah dicoba hanyalah harapan.

Kesimpulan praktis

Produk AI second brain layak dipilih jika ia memecahkan workflow nyata, menjaga continuity, mengambil sumber yang benar, dapat dikoreksi, dan bertindak dalam batas yang terlihat. Kemampuan model hanya satu bagian.

Gunakan checklist sebagai gate. Jika memory tidak punya provenance, retrieval tidak terisolasi, state tidak durable, atau action tidak dapat diaudit, jangan perluas akses. Mulai read-only, ukur hasil, lalu buka kemampuan sedikit demi sedikit. No bs: produk yang tidak lolos uji sederhana belum pantas memegang ingatan operasional perusahaan.

Referensi primer

• NIST -- AI Risk Management Framework
• Anthropic -- Building Effective AI Agents
• Anthropic -- Effective Context Engineering for AI Agents
• OpenAI API -- Conversation State
• Model Context Protocol -- Introduction
• OWASP -- Top 10 for LLM Applications

← Artikel sebelumnya · Hub Second Brain · Artikel berikutnya →