Demo vendor AI biasanya optimistis.
“Model kami akurat.” “Bisa menghemat waktu.” “Integrasi mudah.” “Secure.” “Enterprise ready.”
Semua bagus sampai contract draft masuk.
Di situlah pertanyaan penting muncul.
Data pemerintah boleh dipakai training atau tidak? Kalau model berubah, siapa diberi tahu? Kalau AI salah, siapa tanggung jawab? Kalau kontrak selesai, data dikembalikan bagaimana? Kalau vendor tutup, layanan pemerintah bagaimana?
Procurement AI berbeda dari membeli printer.
Sistemnya probabilistik.
Model bisa update.
Vendor bisa memakai subprocessor.
Biaya bisa bergantung token.
Data bisa mengalir ke cloud.
Karena itu kontrak AI pemerintah perlu jauh lebih spesifik.
Bukan berarti Indonesia sudah punya satu template kontrak AI wajib yang berlaku untuk semua instansi.
Belum ada dasar untuk mengklaim itu.
Tapi best practice internasional sudah memberi arah yang cukup jelas.
Panduan procurement AI pemerintah Inggris menekankan data assessment, risk assessment, transparency, explainability, dan vendor lock-in.
OECD juga mencatat model contractual clauses untuk public procurement AI yang mencakup risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity, dan hak atas dataset.
Indonesia bisa belajar dari prinsip itu tanpa copy-paste.
Klausul pertama: tujuan dan scope
Kontrak harus jelas AI dipakai untuk apa.
Jangan cuma: “penyediaan platform AI.”
Terlalu broad.
Sebut use case.
Klasifikasi dokumen. Chatbot. Analisis data. Fraud detection.
Scope menentukan risk.
Kalau vendor nanti ingin menggunakan sistem untuk fungsi tambahan, harus ada change control.
Ini mencegah scope creep.
Pilot tidak diam-diam menjadi automated decision engine.
Fungsi baru perlu review.
Klausul kedua: ownership dan penggunaan data
Ini salah satu paling penting.
Data pemerintah milik siapa?
Apakah vendor boleh menyimpan?
Boleh dipakai untuk training model mereka?
Boleh dipakai meningkatkan service?
Boleh digabung dengan data customer lain?
Semua harus eksplisit.
Jangan mengandalkan default terms.
Pemerintah perlu memastikan purpose limitation.
Kalau data diberikan untuk menjalankan layanan, jangan otomatis berubah menjadi training dataset komersial.
Kalau memang ada training, perlu agreement spesifik.
Apa data? Apa anonymization? Berapa lama? Apa benefit?
Data deletion juga harus jelas.
Setelah kontrak selesai: berapa hari dihapus? backup bagaimana? log bagaimana? bukti deletion ada?
Klausul ketiga: lokasi dan transfer data
Instansi perlu tahu data diproses di mana.
Indonesia? Singapura? Amerika? Multi-region?
Ini terkait compliance dan security.
Tidak semua data wajib lokal secara universal.
Tapi lokasi harus diketahui.
Kalau vendor memakai subprocessor, siapa?
Cloud provider. Model provider. Analytics.
Daftar supply chain perlu visibility.
Kalau subprocessor berubah, apakah vendor wajib notice?
Untuk high-impact system, perubahan material sebaiknya tidak silent.
Klausul keempat: model yang digunakan
Nama produk AI tidak cukup.
Model version penting.
Kalau vendor hari ini pakai model A dan bulan depan ganti B, behavior bisa berubah.
Kontrak perlu mengatur change notification.
Perubahan apa yang dianggap material?
Model. Prompt. Data source. Threshold. Tool permission.
Tidak semua tweak perlu approval.
Tapi high-impact changes perlu governance.
Mungkin ada testing period.
Mungkin rollback.
Ini harus disepakati.
Klausul kelima: performance metric
Vendor bilang akurat 95 persen.
Akurat untuk apa?
Dataset mana? Bahasa apa? Metric apa?
Kontrak harus punya KPI yang relevan dengan use case.
Precision. Recall. False negative. Latency. Uptime.
Untuk chatbot, mungkin factual accuracy dan escalation.
Untuk document extraction, field accuracy.
Jangan pakai satu angka marketing.
Performance juga perlu diuji pada data Indonesia.
Kalau sistem dipakai Bahasa Indonesia, test harus Bahasa Indonesia.
Kalau dipakai daerah, sampling daerah.
Metric harus mencerminkan production.
Klausul keenam: human oversight
Siapa yang approve action?
Vendor jangan mendesain workflow seolah AI final authority.
Kontrak bisa menetapkan: use case tertentu wajib human review.
Vendor harus menyediakan interface untuk override.
Audit log.
Escalation.
Ini terutama untuk high-impact decision.
Human oversight bukan hanya policy internal pemerintah.
Platform harus memungkinkan.
Kalau system tidak punya control, policy tidak bisa dijalankan.
Klausul ketujuh: explainability
Instansi harus bisa memahami outcome.
Tidak harus source code.
Tapi vendor harus menyediakan dokumentasi.
Faktor. Limitation. Model card. Evaluation.
Untuk kasus individual, sistem perlu memberikan reason yang cukup.
Kalau vendor hanya bilang: “proprietary algorithm,” itu problem untuk layanan publik.
Black box mungkin acceptable di low-risk task.
Untuk high impact, semakin sulit.
Explainability harus masuk requirement awal.
Jangan minta setelah procurement.
Klausul kedelapan: incident notification
Kalau ada incident, berapa cepat vendor memberi tahu?
Security breach. Model malfunction. Data exposure. Wrong automated action.
Severity level perlu didefinisikan.
Critical incident mungkin dalam jam.
Minor dalam hari.
Kontrak juga harus mengatur cooperation.
Log. Root cause. Remediation.
Kalau vendor menemukan vulnerability yang memengaruhi pemerintah, notice wajib.
Jangan menunggu media.
Incident response adalah partnership.
Klausul kesembilan: security dan permission
AI agent bisa punya tool access.
Email. Database. File. Payment.
Kontrak perlu least privilege.
Credential management. Encryption. Access log. MFA.
Vendor tidak boleh punya admin access tanpa alasan.
Remote support harus dilog.
Subprocessor juga kena standar.
Security requirement jangan berhenti pada sertifikat.
Lihat architecture.
Prompt injection dan AI-specific risk perlu masuk assessment.
Klausul kesepuluh: audit rights
Pemerintah perlu hak memeriksa.
Tidak selalu full source code audit.
Bisa documentation review. Log access. Third-party report. Penetration test.
Untuk high-risk system, audit rights lebih kuat.
Kalau vendor menolak semua transparency karena proprietary, procurement team harus bertanya: apakah sistem ini cocok untuk pemerintah?
Contract tanpa audit rights membuat pemerintah bergantung pada self-claim vendor.
Klausul kesebelas: intellectual property
Siapa punya output?
Siapa punya fine-tuned model?
Siapa punya prompt?
Siapa punya dataset hasil labeling?
Ini bisa jadi konflik ketika kontrak selesai.
Misalnya pemerintah membayar labeling 1 juta dokumen.
Vendor menganggap dataset milik mereka.
Pemerintah menganggap aset negara.
Harus jelas.
IP clause menghindari sengketa.
Jangan baru dibahas saat exit.
Klausul kedua belas: portability dan exit
Ini sovereignty issue.
Kalau kontrak selesai, apa yang bisa dibawa?
Data. Embedding. Prompt. Workflow. Log. Configuration.
Dalam format apa?
Apakah vendor membantu migration?
Berapa biaya?
Vendor lock-in sering bukan dari model.
Dari integration.
Semakin dalam, semakin sulit pindah.
Exit plan harus ada dari awal.
Best procurement always thinks about ending.
Klausul ketiga belas: price change
AI pricing bisa berubah.
Per token. Per call. Per agent task.
Kontrak perlu cost control.
Budget cap. Rate limit. Forecasting.
Kalau model provider upstream menaikkan harga, apakah vendor bisa langsung pass through?
Harus ada rule.
Pemerintah perlu predictability.
AI agent bisa boros kalau looping.
Monitoring cost penting.
Jangan sampai invoice mengejutkan.
Klausul keempat belas: liability
Ini paling sensitif.
Kalau AI membuat kesalahan, siapa menanggung?
Tidak ada jawaban sederhana.
Tergantung fault.
Data pemerintah salah. Vendor bug. Model provider outage. Human misuse.
Kontrak perlu pembagian liability.
Indemnity. Cap. Insurance bila perlu.
Untuk high-impact system, jangan terima clause yang melepaskan seluruh tanggung jawab vendor.
Pemerintah juga tidak bisa memindahkan semua liability ke vendor.
Risk allocation harus fair.
Klausul kelima belas: compliance with future regulation
AI regulation berubah cepat.
Kontrak tiga tahun bisa melewati banyak aturan baru.
Perlu regulatory change clause.
Jika pemerintah menerbitkan requirement baru, vendor harus menyesuaikan.
Tapi biaya dan timeline juga harus diatur.
Tanpa itu, setiap perubahan jadi renegotiation besar.
Flexible contract lebih cocok untuk AI.
Klausul keenam belas: decommissioning
Ketika sistem berhenti, apa yang terjadi?
Credential dicabut. Data dihapus. Endpoint dimatikan. Model copy dihentikan. Backup ditangani.
Decommissioning harus formal.
Jangan biarkan shadow access.
Vendor offboarding sama penting dengan onboarding.
High-impact service mungkin butuh transition period.
Layanan publik tidak boleh berhenti mendadak.
Kontrak AI sebenarnya kontrak governance
Ini inti.
Pengadaan software lama fokus: harga, fitur, SLA.
AI menambah: data, model behavior, risk, explanation, autonomy, change.
Kontrak menjadi cara pemerintah mengubah prinsip governance menjadi kewajiban yang bisa ditegakkan.
Kalau policy bilang vendor harus transparan tetapi contract tidak punya clause, sulit enforce.
Kalau policy bilang data tidak boleh dipakai training tetapi terms vendor membolehkan, conflict.
Procurement adalah titik kontrol.
Sebelum sistem masuk.
Indonesia tidak perlu menunggu satu regulasi procurement AI sempurna untuk mulai bertanya hal-hal ini.
LKPP dan instansi pengadaan sudah punya kerangka pengadaan pemerintah.
AI menambah layer risiko yang perlu diterjemahkan ke requirement.
Untuk use case low risk, clause bisa ringan.
Untuk high impact, lebih detail.
Proporsional.
Jangan copy-paste 50 halaman ke semua vendor kecil.
Yang penting risk sesuai.
Ketika vendor AI masuk pemerintah, jangan hanya terpesona kemampuan model.
Pertanyaan kontrak harus sama seriusnya dengan pertanyaan demo.
Ada satu klausul yang sering underrated: acceptance testing. Pemerintah jangan hanya menerima sistem karena fitur bisa dibuka. Sebelum go live, vendor harus melewati test yang disepakati. Gunakan data representatif, skenario normal, edge case, dan failure case.
Acceptance criteria harus objektif. Misalnya false negative tidak boleh melewati batas tertentu, response time sesuai SLA, audit log tersedia, dan mekanisme human override bekerja. Kalau tidak lolos, deployment ditahan atau diperbaiki.
Kontrak juga perlu mengatur model degradation. Kadang performa turun bukan karena vendor mengubah model, tetapi karena data dunia nyata berubah. Untuk sistem jangka panjang, perlu periodic re-evaluation. Siapa membayar retest? Siapa menyediakan data? Apa threshold yang memicu remediation?
Lalu ada clause tentang subcontracting. Vendor utama bisa memakai vendor lain untuk labeling, hosting, moderation, atau support. Pemerintah perlu tahu ketika subprocessor menyentuh data atau fungsi kritis. Tanggung jawab utama tetap tidak boleh hilang di rantai subcontractor.
Dokumentasi juga harus menjadi deliverable. Architecture diagram, data flow, model description, admin procedure, recovery process, dan configuration tertentu perlu diserahkan sesuai scope. Kalau seluruh knowledge hanya ada di kepala engineer vendor, exit strategy tidak nyata.
Terakhir, kontrak perlu menentukan governance meeting. Untuk sistem high impact, tidak cukup bertemu ketika invoice. Review periodik membahas performance, incident, model changes, cost, dan upcoming risk. Ini membuat contract management berjalan selama lifecycle.
AI procurement bukan transaksi sekali beli. Ia hubungan operasional yang harus terus dikendalikan.
Karena demo menunjukkan apa yang sistem bisa lakukan saat semuanya berjalan benar.
Kontrak mengatur apa yang terjadi ketika realitas tidak seindah demo.
Bacaan terkait
Artikel ini berada dalam AI Governance dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Reports dan analisis mendalam.