Hukum di Dalam Kode Kami

Saat kami membuat Premium bisa dibeli, kami mengira bagian hukumnya hanyalah beberapa halaman teks di footer. Itu keliru. Beberapa kewajiban sama sekali tidak bisa dituangkan ke dalam teks, karena kewajiban itu menentukan bagaimana sebuah fitur harus dibangun.

Empat contoh di mana hal ini terlihat sangat jelas. Sebelumnya, supaya jelas apa artikel ini: ini adalah gambaran implementasi kami, bukan nasihat hukum. Aturan di bawah ini adalah hukum Jerman, tempat AlphaCloud beroperasi.

Tombol pembatalan yang tidak boleh punya login

Pasal 312k Kitab Undang-Undang Hukum Perdata Jerman mewajibkan kontrak yang dibuat secara online untuk menyediakan cara membatalkan yang bisa dijangkau langsung. Dari situ muncul persyaratan yang tidak bisa ditambahkan belakangan lewat kata-kata:

• Halamannya harus berfungsi tanpa login
• Halamannya harus ada di footer setiap halaman
• Dibutuhkan dua langkah: mengisi, lalu mengonfirmasi lewat tombol yang labelnya tidak ambigu
• Konfirmasi penerimaan dalam bentuk teks harus dikirim

Poin terakhir itulah yang menentukan arsitekturnya. Pembatalan adalah pernyataan sepihak dan berlaku saat diterima. Jadi pembatalan harus dicatat dan dikonfirmasi selalu, dari siapa pun datangnya.

Formulir tidak boleh menolakmu

Di sinilah pendekatan yang paling jelas hampir membuat kami melakukan kesalahan.

Pendekatan yang paling jelas: hanya menerima pembatalan kalau ID server dan email cocok dengan langganan aktif. Kedengarannya masuk akal, dan salah dua kali.

Pertama, itu akan mengunci pelanggan sungguhan yang salah ketik email atau memberikan alamat lain. Pembatalannya dianggap tidak pernah diterima, langganannya diperpanjang, dan dia memegang bukti bahwa dia sudah mencoba.

Kedua, dan ini bagian yang lebih tidak enak: pesan error itu sendiri sudah merupakan jawaban. Siapa pun yang mendapat balasan "tidak ada langganan ditemukan" jadi tahu bahwa server ini tidak membayar. ID server Discord bukan rahasia, anggota mana pun bisa membacanya. Formulir itu akan menjadi alat untuk mengintip server orang lain.

Solusinya memisahkan dua hal yang terasa seperti satu:

	Syarat
Penerimaan pernyataan	tanpa syarat, selalu dicatat dan dikonfirmasi
Pelaksanaan pembatalan	hanya jika email yang dikirim cocok dengan pembeli yang tercatat

Semua yang lain masuk ke antrean dan ditinjau oleh manusia. Itu diperbolehkan karena pasal 312k ayat 2 secara tegas mengizinkan meminta data identifikasi. Yang dilarang hanyalah login di depannya.

Dengan alasan yang sama, respons publik hanya boleh menyebutkan tanggal berakhir setelah identitas terkonfirmasi. Kalau tidak, konfirmasi itu kembali menjadi orakel.

Penarikan yang sengaja memakai login

Tepat di sebelahnya ada fitur yang kami bangun dengan cara sebaliknya: penarikan dengan pengembalian dana proporsional ada di balik login.

Itu bukan kontradiksi. Pasal 312k mengatur pembatalan, bukan penarikan, dan sama sekali tidak ada kewajiban menyediakan formulir penarikan online selama jalur informal tetap terbuka. Perbedaannya ada pada akibatnya: pembatalan berlaku untuk masa depan, pengembalian dana memindahkan uang sekarang, dan tidak bisa ditarik kembali.

Tiga aturan yang mengikutinya, dan tidak kami longgarkan:

Tanpa alasan wajib. Pasal 355 ayat 1 memberikan hak penarikan secara tegas tanpa perlu menyebutkan alasan. Kolomnya opsional dan harus tetap opsional, betapa pun menggodanya kolom wajib untuk keperluan statistik.

Setelah 14 hari, hanya jalur otomatis yang ditolak, bukan pernyataannya. Jangka waktunya bisa diperpanjang hingga dua belas bulan dan empat belas hari kalau pelanggan tidak diberi informasi dengan benar. Jawaban "terlambat" secara umum karena itu bisa saja salah.

Perlindungan terhadap pembayaran ganda bersifat pesimistis. Penandanya dipasang sebelum pengembalian dana dijalankan. Kalau pengembalian dananya kemudian gagal, penandanya tetap ada dan manusia mengambil alih. Membayar dua kali adalah satu-satunya hasil yang tidak bisa dipulihkan.

DM Discord bukan media yang tahan lama

Pasal 312f ayat 3 mewajibkan konfirmasi kontrak pada media yang tahan lama, dan konfirmasi itu harus memuat kembali persetujuan yang telah diberikan.

Awalnya kami mengirim pesan langsung lewat Discord, karena di sanalah pelanggan kami berada. Itu tidak memenuhi syarat. Sebuah DM hidup di platform yang tidak kami kendalikan, dan tidak bisa disimpan maupun tidak bisa diubah dalam arti yang dimaksud ketentuan itu.

Jadi ditambahkan email, dan bersamanya sebuah ketergantungan yang tidak nyaman: kalau kredensial email tidak diatur, pengiriman hanya menulis peringatan ke log dan kewajibannya tidak terpenuhi. Kewajiban hukum yang bergantung pada sebuah variabel lingkungan adalah keadaan yang patut disadari.

Tanpa PPN, dan itu harus terbaca sama di mana pun

AlphaCloud adalah usaha kecil menurut pasal 19 Undang-Undang PPN Jerman. Harga adalah harga akhir, PPN tidak pernah dicantumkan.

Kedengarannya seperti catatan kaki, padahal sebenarnya tugas konsistensi di banyak tempat: halaman harga, dialog checkout, syarat layanan, kebijakan privasi, footer tagihan, dan konfigurasi di penyedia pembayaran semuanya harus mengatakan hal yang sama. Lama sekali ada tulisan "belum termasuk PPN" yang sebenarnya salah.

Lalu soal AI

Sejak Agustus 2026, kewajiban transparansi dari AI Act Eropa berlaku sepenuhnya. Siapa pun yang berbicara dengan sistem AI harus bisa mengenalinya, paling lambat pada interaksi pertama.

Kalimat terpenting bagi kami dari tinjauan itu: halaman hukum di footer kemungkinan besar tidak memenuhinya. Pengungkapannya harus terjadi di tempat interaksi terjadi, jadi di dalam pesan Discord itu sendiri. Karena itu, support tiket AI kami memperkenalkan dirinya tanpa diminta dan punya tombol yang terlihat untuk mematikannya. Penilaian lengkap kami ada di transparansi AI.

Benang merahnya

Keempat contoh punya bentuk yang sama: kewajibannya tampak seperti teks, padahal sebenarnya persyaratan terhadap struktur. Login di tempat yang salah, pesan error yang membuka terlalu banyak, konfirmasi lewat saluran yang salah, urutan yang memungkinkan pembayaran ganda.

Jadi kini kami membaca teks hukum seperti spesifikasi, dan kami juga memeriksa ke arah sebaliknya: apakah kode benar-benar melakukan apa yang dikatakan syarat kami? Tepat dalam pertanyaan itu kami menemukan dua perbedaan nyata, dan ada artikel tersendiri tentang keduanya.