Tesla, FSD, dan Batas yang Tidak Boleh Diserahkan ke Software

The Core Update

NTSB menyampaikan temuan awal soal kecelakaan Tesla di Katy, Texas, yang menabrak sebuah rumah pada Juni dan menewaskan Martha Avila, warga berusia 76 tahun.

Data kendaraan menunjukkan bahwa mobil melaju lebih dari 70 mil per jam saat menabrak rumah. Jalan tempat kejadian adalah jalan permukiman dua lajur dengan batas kecepatan 30 mil per jam. Cuaca cerah, jalan kering, dan kondisi masih terang.

Temuan pentingnya: pengemudi menekan pedal akselerator sampai 100%, sehingga mengambil alih atau meng-override Full Self-Driving (Supervised) milik Tesla.

Dengan kata lain, berdasarkan data awal NTSB, kendaraan tidak tiba-tiba memutuskan sendiri untuk melaju sekencang itu tanpa input manusia. Ada intervensi fisik dari pengemudi melalui pedal akselerator.

Ini sejalan dengan posisi Tesla setelah kecelakaan terjadi. Elon Musk sempat menyatakan bahwa narasi FSD sebagai penyebab kecelakaan tidak masuk akal karena FSD biasanya melaju pelan di jalan permukiman, sedangkan kecelakaan ini terjadi dalam kecepatan tinggi.

Namun temuan ini tidak otomatis menutup semua pertanyaan. NTSB masih menyebut laporan ini sebagai bagian dari investigasi awal. NHTSA juga ikut menyelidiki kejadian tersebut. Keluarga korban telah menggugat pengemudi dan Tesla, sementara pengemudi juga menghadapi dakwaan manslaughter.

Kasus ini menjadi pengingat penting: ketika software dipakai untuk membantu keputusan fisik di dunia nyata, batas antara bantuan, kontrol, dan tanggung jawab harus sangat jelas.

The Reality Check

Banyak perdebatan soal kendaraan semi-otonom sering berhenti di pertanyaan yang terlalu sempit: apakah software salah atau manusia salah?

Pertanyaan itu penting, tetapi tidak cukup.

Dalam sistem seperti Full Self-Driving (Supervised), Tesla sudah memberi syarat bahwa pengemudi harus tetap memperhatikan jalan dan siap mengambil alih kapan saja. Secara formal, tanggung jawab tetap ada pada manusia.

Masalahnya, pengalaman produk sering membentuk perilaku yang berbeda dari teks peringatan.

Jika sebuah sistem bisa menyetir, belok, menjaga jalur, membaca lingkungan, dan membuat keputusan rute, sebagian pengguna bisa mulai memperlakukannya seperti sistem yang lebih mandiri daripada yang sebenarnya. Kata “Supervised” menjadi penting secara hukum dan teknis, tetapi belum tentu cukup kuat secara perilaku.

Di sisi lain, kasus Texas ini juga menunjukkan sisi yang sering dilupakan: manusia tidak hanya bisa gagal mengambil alih, tetapi juga bisa mengambil alih dengan cara yang berbahaya.

Data NTSB menyebut pedal akselerator ditekan 100%. Itu bukan sekadar kelalaian pasif. Itu input aktif yang mengubah perilaku kendaraan.

Di sinilah desain sistem menjadi rumit.

Kalau sistem terlalu mudah dibatalkan oleh pengemudi, software bisa kalah oleh tindakan berbahaya. Kalau sistem terlalu sulit dibatalkan, software bisa dituduh mengambil kendali dari manusia. Kalau sistem memberi terlalu banyak kepercayaan diri, pengguna bisa lengah. Kalau sistem terlalu membatasi, pengguna bisa merasa sistem tidak berguna.

Tidak ada jawaban sederhana.

Tetapi ada prinsip dasar yang jelas: produk yang beroperasi di lingkungan berisiko tinggi tidak cukup hanya benar secara teknis. Ia juga harus sulit disalahpahami, sulit disalahgunakan, dan jelas dalam momen kritis.

Ini bukan hanya masalah mobil otonom. Pola yang sama muncul di banyak sistem digital.

Automation bisnis yang bisa mengirim pesan ke pelanggan tetap butuh batas. AI yang bisa memberi rekomendasi keputusan tetap butuh konteks. Dashboard yang memberi status operasional tetap butuh definisi. Sistem pembayaran, approval, akses admin, dan workflow internal tetap butuh guardrail.

Teknologi sering terlihat pintar saat kondisi normal. Ujian sebenarnya muncul saat manusia panik, salah paham, terburu-buru, lelah, atau mencoba memaksa sistem melakukan sesuatu di luar batas sehatnya.

Dalam kasus Tesla ini, detail seperti riwayat pencarian pengemudi tentang FSD yang dianggap “not aggressive enough” atau “too timid” juga memperlihatkan hal lain: pengguna bisa memiliki ekspektasi yang tidak sama dengan batas aman sistem.

Ketika ekspektasi pengguna lebih agresif daripada desain keselamatan, produk masuk wilayah berbahaya.

Bukan berarti semua kesalahan otomatis milik pembuat teknologi. Tetapi pembuat teknologi tetap perlu bertanya: apakah sistem kami cukup jelas untuk mencegah ekspektasi yang salah?

The Havedev Way

Dari sudut pandang Havedev, pelajaran terbesar dari kasus ini bukan hanya soal Tesla atau FSD. Pelajarannya lebih luas: automation tidak boleh hanya dirancang untuk kondisi ideal.

Sistem harus dirancang untuk kondisi manusiawi.

Manusia bisa salah baca. Manusia bisa terlalu percaya. Manusia bisa menekan tombol yang salah. Manusia bisa mencari cara mempercepat sistem. Manusia bisa mengabaikan peringatan yang sudah terlalu sering muncul.

Karena itu, ketika bisnis membangun AI, automation, dashboard, atau aplikasi internal, pertanyaan pentingnya bukan hanya:

• apakah sistem ini bisa berjalan otomatis?
• apakah proses ini bisa dipercepat?
• apakah user bisa melakukan lebih sedikit klik?
• apakah data bisa langsung diproses?

Pertanyaan yang lebih sehat adalah:

• apa yang terjadi kalau user salah paham?
• apa yang terjadi kalau user memberi input ekstrem?
• kapan sistem harus menolak tindakan?
• kapan sistem harus meminta konfirmasi tambahan?
• siapa yang tetap bertanggung jawab saat automation berjalan?
• status apa yang harus terlihat sebelum keputusan dibuat?

Di banyak proyek bisnis, masalah besar jarang dimulai dari teknologi yang kurang canggih. Masalah sering dimulai dari batas yang tidak didefinisikan.

Contohnya, automation follow-up lead bisa membantu sales. Tetapi kalau sistem tetap mengirim pesan saat lead sudah menolak, itu merusak pengalaman pelanggan.

Dashboard operasional bisa membantu manager. Tetapi kalau status “pending” tidak dibedakan antara menunggu customer dan menunggu tim internal, dashboard hanya mempercepat kebingungan.

AI support bisa membantu menjawab pertanyaan pelanggan. Tetapi kalau tidak tahu kapan harus eskalasi ke manusia, AI bisa terlihat percaya diri saat seharusnya berhenti.

Approval otomatis bisa mempercepat administrasi. Tetapi kalau tidak punya batas nominal, role, atau kondisi pengecualian, automation bisa mempercepat kesalahan.

Prinsipnya sama dengan teknologi bantuan mengemudi: semakin besar dampak keputusan, semakin jelas batas sistem harus dibuat.

Havedev biasanya melihat tiga hal sebelum menyarankan automation.

Pertama, status kerja harus jelas. Sistem perlu tahu pekerjaan sedang berada di tahap apa, siapa pemiliknya, dan tindakan berikutnya apa.

Kedua, guardrail harus ada. Tidak semua input harus diterima. Tidak semua proses harus otomatis. Tidak semua user harus bisa melewati batas hanya karena tombolnya tersedia.

Ketiga, handover ke manusia harus mudah dibaca. Automation yang sehat bukan automation yang pura-pura bisa menangani semua hal. Automation yang sehat tahu kapan harus berhenti dan meminta manusia mengambil keputusan.

Kasus Tesla di Texas adalah contoh ekstrem karena menyangkut nyawa. Tetapi pola dasarnya relevan untuk bisnis sehari-hari.

Sistem yang terlihat pintar tetap bisa gagal kalau manusia tidak memahami batasnya. Automation yang terlihat efisien tetap bisa berbahaya kalau tidak punya rem. AI yang terlihat membantu tetap bisa menciptakan risiko kalau semua keputusan dibuat terlalu otomatis.

Teknologi yang baik bukan hanya membuat pekerjaan bergerak lebih cepat. Teknologi yang baik juga membantu tim tahu kapan harus melambat, mengecek ulang, atau mengambil alih.

Sebelum menambahkan AI atau automation baru, bisnis perlu bertanya satu hal sederhana: apakah sistem ini punya batas yang cukup jelas saat manusia melakukan hal yang tidak ideal?

Kalau jawabannya belum jelas, mulai dari sana.

Dapatkan Audit Teknis Gratis untuk meninjau alur website, automation, AI, dan sistem internal yang perlu dibuat lebih jelas, lebih aman, dan lebih siap menghadapi kondisi nyata.

---

Sumber referensi berita: TechCrunch