18.4 Data dan State: Jangan Biarkan AI Bermain Sendiri

API dan contract hanya sebagian dari cerita; data dan state juga perlu diatur dengan jelas agar AI tidak membuat kekacauan.

Bayangkan Anda sedang mengembangkan sistem pemesanan tiket konser. Modul-modul sudah dipisah rapi, API sudah punya contract yang jelas. Kemudian Anda meminta AI untuk menambahkan fitur “pengembalian tiket” karena banyak pelanggan mengeluh. AI dengan sigap menulis kode: mengambil data pemesanan, mengubah status tiket, mengurangi stok, lalu mencatat refund. Semua terlihat beres.

Diagram berikut memperlihatkan alur data dari modul pemesanan ke modul pembayaran, dengan titik-titik di mana schema, ownership, lifecycle, dan konsistensi harus dijaga.

flowchart TD A[Pelanggan Checkout] --> B[Modul Pemesanan] B --> C{Schema: tiket, status, harga} C --> D[Ownership: Modul Pemesanan] D --> E[Lifecycle: tiket aktif] E --> F[Modul Pembayaran] F --> G{Transaction: bayar} G --> H[Status: terbayar] H --> I[AI diminta refund] I --> J{Idempotency: cek refund ganda} J -->|valid| K[Modul Pemesanan ubah status] J -->|gagal| L[Tolak refund] K --> M{Transaction: refund + stok} M --> N[Konsistensi terjaga]

Tapi seminggu kemudian, laporan keuangan menunjukkan angka aneh. Ada tiket yang dikembalikan dua kali. Ada refund yang tercatat tetapi tiket tetap aktif. Stok yang seharusnya kembali tersedia malah tidak bertambah. Setelah ditelusuri, masalahnya bukan di logika bisnis. Masalahnya adalah AI tidak tahu siapa pemilik data, kapan data boleh diubah, dan bagaimana memastikan perubahan itu konsisten.

Di sinilah schema, ownership, lifecycle, dan konsistensi data menjadi penting. Bukan sekadar istilah teknis, tetapi fondasi agar AI bisa bekerja tanpa merusak sistem.

Schema adalah cetak biru data. Ketika sebuah tabel atau dokumen memiliki schema yang jelas, AI bisa membaca struktur, tipe, dan relasi tanpa harus menebak. Tanpa schema, AI akan membuat asumsi sendiri: kolom status mungkin dianggap string, padahal seharusnya enum; field harga mungkin dibaca sebagai teks, padahal harus numerik. Setiap asumsi yang salah bisa merembet ke modul lain.

Berikut contoh definisi schema tabel tiket dalam format YAML yang mencakup field, tipe, constraint, dan aturan ownership:

schema:
  table: tiket
  fields:
    - name: id
      type: uuid
      constraint: primary_key
    - name: pemesanan_id
      type: uuid
      constraint: foreign_key -> pemesanan.id
    - name: status
      type: enum
      values: [aktif, terpakai, refunded, kadaluarsa]
      default: aktif
    - name: harga
      type: decimal(10,2)
      constraint: not_null
    - name: created_at
      type: timestamp
      default: now()

ownership:
  modul_pemesanan:
    create: true
    read: true
    update: [status, updated_at]
    delete: false
  modul_pembayaran:
    create: false
    read: true
    update: false
    delete: false
  modul_refund:
    create: false
    read: true
    update: [status]
    delete: false

Ownership data menentukan siapa yang berhak membuat, membaca, mengubah, dan menghapus data. Dalam sistem yang baik, setiap data punya pemilik yang jelas. Modul pemesanan bertanggung jawab atas data pemesanan. Modul pembayaran bertanggung jawab atas data transaksi. Ketika AI diminta mengubah status tiket, ia harus tahu bahwa data itu milik modul pemesanan, bukan milik modul refund. Jika aturan ini tidak tegas, AI bisa sembarangan menulis ke tabel yang seharusnya hanya dibaca, atau mengubah data yang sedang diproses modul lain.

Lifecycle data mengatur perjalanan data dari lahir hingga dihapus. Data pemesanan lahir saat pelanggan checkout, hidup selama tiket digunakan, dan bisa diarsipkan setelah acara selesai. AI perlu memahami lifecycle ini agar tidak melakukan operasi yang tidak masuk akal, misalnya mengembalikan tiket yang sudah dipakai, atau menghapus data yang masih diperlukan audit.

Konsistensi adalah mekanisme yang memastikan data tetap benar meskipun banyak perubahan terjadi bersamaan. Dalam sistem pemesanan tiket, satu tiket tidak boleh dikembalikan dua kali. Di sinilah konsep seperti transaction, idempotency, dan retry masuk. Transaction memastikan bahwa rangkaian perubahan terjadi secara atomik: jika satu langkah gagal, semua perubahan dibatalkan. Idempotency memastikan bahwa operasi yang sama bisa dijalankan berkali-kali tanpa efek ganda. Retry memungkinkan AI mencoba ulang operasi yang gagal tanpa membuat efek ganda pada data.

Tanpa mekanisme ini, AI seperti anak kecil yang diberi mainan mahal tanpa pengawasan. Ia bisa mengubah data seenaknya, menimpa milik orang lain, dan meninggalkan kekacauan yang sulit dilacak. Dengan schema, ownership, lifecycle, dan konsistensi yang jelas, AI menjadi asisten yang andal. Ia bisa mengakses data yang tepat, memodifikasinya dengan aman, dan meninggalkan jejak yang bisa diverifikasi.

Data dan state yang terkelola dengan baik juga membuat AI lebih mudah diberi konteks. Ketika Anda memberi prompt pada AI, Anda bisa merujuk pada schema yang sudah dikenal, bukan menjelaskan struktur data dari nol. Anda bisa menyebut “ubah status pemesanan menjadi refunded” dan AI akan tahu tabel mana, kolom mana, dan aturan apa yang berlaku.

Setelah data dan state aman, tantangan berikutnya adalah memastikan bahwa AI sendiri tidak menjadi celah keamanan atau titik kegagalan. Di sinilah security dan reliability harus menjadi bagian dari desain awal, bukan tambahan di akhir.