Seorang account manager mengoreksi informasi pelanggan pada hari Senin. Pada hari berikutnya, AI agent masih memakai ringkasan lama yang tersimpan dari percakapan sebelumnya. Dokumen sumber sudah diperbarui, tetapi informasi yang diturunkan dari dokumen itu belum ikut berubah. Masalah seperti ini membuat retensi memori AI agent perlu dirancang sebagai proses operasional, bukan sekadar pilihan menyimpan seluruh riwayat chat.
Memori dapat membantu kesinambungan pekerjaan, tetapi juga membawa informasi yang salah, kedaluwarsa, atau di luar hak akses pengguna saat ini. Panduan ini membahas apa yang layak disimpan lintas sesi, bagaimana menandai asalnya, dan bagaimana menguji pencabutan atau penghapusan. Ini kerangka rancangan teknis dan proses, bukan penetapan jangka retensi hukum untuk setiap perusahaan.
Pisahkan Empat Tempat Informasi Dapat Bertahan
Istilah “AI ingat” sering menyatukan beberapa mekanisme berbeda. Tim IT dan data owner perlu membuat inventaris tempat penyimpanan yang sebenarnya. Jangan menjawab permintaan penghapusan dengan menghapus tampilan percakapan saja jika ringkasan dan indeks turunannya masih dapat digunakan agent.
- Konteks sesi: informasi yang disertakan dalam satu pekerjaan atau rangkaian interaksi aktif.
- Riwayat percakapan: pesan dan respons yang disimpan aplikasi untuk penelusuran atau kelanjutan interaksi.
- Memori lintas sesi: fakta, preferensi, atau ringkasan yang dipilih agar dapat dipakai kembali pada pekerjaan berikutnya.
- Log dan salinan operasional: jejak alat, observabilitas, cache, indeks, ekspor, dan backup yang mungkin menyimpan salinan berbeda.
Knowledge base RAG biasanya berisi dokumen sumber yang dikelola organisasi. Memori lintas sesi lebih sering berasal dari interaksi dan hasil pekerjaan agent. Keduanya dapat saling memengaruhi, tetapi tidak boleh memiliki aturan pengesahan yang sama secara otomatis. Lihat juga pengelolaan versi dan pencabutan knowledge base RAG untuk lifecycle korpus dokumen.
Tentukan Tujuan Sebelum Menyimpan Fakta
Untuk setiap kandidat memori, tanyakan pekerjaan apa yang membutuhkannya lagi, siapa yang boleh memakai, dari mana asal informasi, dan sampai kapan manfaatnya masih ada. “Mungkin berguna suatu hari” merupakan dasar yang lemah untuk menyimpan catatan pelanggan atau karyawan tanpa batas.
Contoh yang relatif terarah adalah preferensi format laporan tim yang telah disahkan. Contoh yang perlu pembatasan lebih ketat adalah kesimpulan model tentang kondisi finansial pelanggan dari percakapan negosiasi. Kesimpulan tersebut tidak layak berubah menjadi fakta permanen hanya karena telah diringkas.
Dalam pembahasan context engineering Anthropic, pengelolaan konteks mencakup pemilihan informasi yang relevan, pemadatan, pencatatan terstruktur, dan strategi untuk pekerjaan panjang. Teknik tersebut menjelaskan cara membawa informasi, bukan bukti bahwa semua catatan layak disimpan atau benar. Kebijakan organisasi tetap menentukan batas pemakaiannya.
Gunakan Metadata yang Membuat Memori Dapat Diperiksa
Minimal simpan ID memori, pemilik data, lingkup organisasi atau pelanggan, sumber, waktu dibuat, waktu terakhir diverifikasi, status, serta aturan kedaluwarsa. Pisahkan label fakta terkonfirmasi, informasi yang diberikan pengguna, dan inferensi model. Reviewer harus dapat melihat mengapa informasi tertentu muncul kembali.
Memori yang disarikan dari dokumen perlu membawa ID serta versi dokumen. Jika sumber dicabut, sistem dapat menemukan ringkasan turunannya. Tanpa hubungan tersebut, penghapusan akan berubah menjadi pencarian manual yang sulit dibuktikan lengkap. Prinsip data lineage enterprise membantu merancang ketertelusuran ini.
Jangan Memakai Approval Lama untuk Kewenangan Baru
Memori “PIC pernah mengizinkan pengiriman laporan” tidak boleh dijadikan wewenang untuk mengirim dokumen lain pada kesempatan berikutnya. Persetujuan tindakan harus memiliki lingkup, objek, penerima, dan masa berlaku yang dapat diperiksa. Preferensi pengguna dan otorisasi tindakan merupakan dua jenis informasi berbeda.
Demikian pula, saat seorang pegawai berpindah unit, agent wajib mengikuti hak akses terkini. Fakta bahwa ia pernah melihat informasi tidak menjamin informasi itu boleh diambil kembali. Pemeriksaan akses perlu dilakukan saat retrieval dan sebelum jawaban ditampilkan, termasuk ketika jawabannya berasal dari ringkasan yang telah tersimpan.
Memori juga tidak boleh menyeberangi batas tenant atau pelanggan. Gunakan identitas dan filter akses yang ditegakkan aplikasi, bukan hanya kalimat “jangan campur pelanggan” dalam prompt. Uji pencarian dengan pertanyaan yang sama pada dua pengguna berbeda untuk membuktikan batasnya bekerja.
Rancang Perubahan, Kedaluwarsa, dan Penghapusan
Tetapkan status aktif, perlu verifikasi ulang, digantikan, dicabut, dan dihapus sesuai kebutuhan sistem. Memori yang kedaluwarsa tidak harus langsung diubah menjadi fakta baru. Agent dapat menyatakan bahwa informasi belum diverifikasi dan meminta sumber terkini ketika keputusan memerlukan kepastian.
Penghapusan perlu menjangkau penyimpanan aktif serta salinan turunan yang masih dipakai: ringkasan, indeks pencarian, cache, dan konteks pekerjaan yang akan dilanjutkan. Backup dan log dapat memiliki mekanisme berbeda; pemilik sistem harus mendokumentasikan perlakuannya serta batas teknisnya. Jangan menjanjikan penghapusan seketika dari semua salinan tanpa bukti implementasi.
Contoh Ilustratif: Catatan PIC yang Sudah Berubah
Ini ilustrasi rancangan, bukan portofolio Layana. Agent menyimpan ringkasan “persetujuan pelanggan melalui PIC A”. Perusahaan kemudian memperbarui PIC menjadi B. Sistem menandai memori lama sebagai digantikan dan menghubungkannya dengan sumber terbaru. Pekerjaan yang belum selesai membaca ulang status sebelum menyiapkan tindakan berikutnya.
Jika satu pekerjaan masih memegang konteks lama, ia harus berhenti pada gerbang pemeriksaan, bukan melanjutkan berdasarkan otorisasi yang tersimpan. Log mencatat bahwa memori lama tidak dipakai dan sumber baru diperiksa. Perubahan ini diuji pula setelah proses dihentikan lalu dilanjutkan kembali.
Uji Memori dari Sudut Pandang Pengguna yang Kehilangan Akses
Pilot sebaiknya memakai data sintetis atau data yang telah disamarkan dengan persetujuan pemilik. Buat catatan uji yang unik agar kemunculannya dapat dilacak. Setelah memori disimpan, lakukan koreksi sumber, cabut akses pengguna, hapus memori, dan mulai sesi baru. Periksa apakah informasi lama masih muncul melalui jawaban, kutipan, pencarian, atau ringkasan pekerjaan.
Uji pula dokumen yang berisi instruksi untuk “ingat selamanya” atau “abaikan aturan penghapusan”. Masukan tersebut tidak boleh mengubah kebijakan retensi. Bila sistem menerima usulan memori dari model, aplikasi perlu memvalidasi jenis data dan lingkupnya sebelum menyimpan.
KPI yang relevan meliputi ketepatan sumber memori, tingkat penggunaan informasi kedaluwarsa, keberhasilan pencabutan pada jalur yang diuji, waktu pemenuhan koreksi, dan jumlah memori tanpa pemilik. Ukur manfaat kesinambungan pekerjaan bersama biaya review dan penyimpanan. Ingatan yang lebih panjang tidak otomatis membuat agent lebih berguna.
Mulai dari Satu Use Case dan Lifecycle yang Jelas
Pilih satu jenis memori yang kegunaannya jelas, misalnya konteks proyek internal yang telah disahkan. Tentukan pemilik, masa berlaku yang disepakati, jalur koreksi, serta skenario pengujian. Perluasan ke data pelanggan atau konteks lintas unit memerlukan penilaian serta batas akses tambahan.
Melalui layanan AI dan machine learning Layana, tim dapat mendiskusikan kebutuhan penyimpanan dan integrasi dalam konteks proses bisnis. Diskusikan pemetaan lifecycle memori AI agent dengan membawa jenis informasi, sistem penyimpanan, pemilik data, dan contoh perubahan yang harus dihormati agent. Jadikan bukti koreksi dan pencabutan sebagai bagian acceptance pilot.
Gambar utama merupakan ilustrasi konseptual pemilahan dan penghentian penggunaan memori, bukan tampilan produk atau dokumentasi proyek.