De wet in onze code

Toen we Premium te koop maakten, dachten we dat het juridische deel een paar pagina's tekst in de footer was. Dat klopte niet. Sommige plichten kun je helemaal niet in een tekst opschrijven, omdat ze voorschrijven hoe een functie gebouwd moet worden.

Vier voorbeelden waar dat bijzonder duidelijk werd. Vooraf, zodat duidelijk is wat dit is: een beschrijving van onze implementatie, geen juridisch advies. De regels hieronder zijn Duits recht, want daar is AlphaCloud actief.

De opzegknop die geen login mag hebben

Paragraaf 312k van het Duitse Burgerlijk Wetboek verplicht online gesloten contracten om een direct bereikbare manier van opzeggen te bieden. Dat levert eisen op die je achteraf niet met formuleringen kunt toevoegen:

• De pagina moet werken zonder in te loggen
• Hij moet in de footer van elke pagina staan
• Hij heeft twee stappen nodig: invullen, dan bevestigen via een ondubbelzinnig gelabelde knop
• Er moet een ontvangstbevestiging in tekstvorm de deur uit

Het laatste punt bepaalt de architectuur. Een opzegging is een eenzijdige verklaring en wordt van kracht bij ontvangst. Ze moet dus altijd worden vastgelegd en bevestigd, van wie ze ook komt.

Het formulier mag je nooit weigeren

Hier kostte de voor de hand liggende aanpak ons bijna een fout.

De voor de hand liggende aanpak: de opzegging alleen accepteren als de server ID en het e-mailadres bij een actief abonnement horen. Klinkt redelijk, en is twee keer fout.

Ten eerste zou het een echte klant buitensluiten die zich in zijn e-mailadres vertypt of een ander adres opgeeft. Zijn opzegging zou niet zijn ontvangen, het abonnement verlengt zich, en hij heeft bewijs dat hij het heeft geprobeerd.

Ten tweede, en dat is het onaangenamere deel: de foutmelding zelf zou een antwoord zijn. Wie "geen abonnement gevonden" terugkrijgt, weet dat deze server niet betaalt. Een Discord server ID is geen geheim, elk lid kan hem uitlezen. Het formulier zou een hulpmiddel worden om de servers van anderen af te tasten.

De oplossing scheidt twee dingen die als één voelen:

	Voorwaarde
Ontvangst van de verklaring	onvoorwaardelijk, altijd vastgelegd en bevestigd
Uitvoering van de opzegging	alleen als het opgegeven e-mailadres overeenkomt met de bekende koper

Al het andere komt in een wachtrij en wordt door een mens bekeken. Dat mag, omdat paragraaf 312k lid 2 uitdrukkelijk toestaat om naar identificerende gegevens te vragen. Alleen een login ervoor is verboden.

Om dezelfde reden mag het openbare antwoord pas de einddatum noemen als de identiteit bevestigd is. Anders wordt de bevestiging weer een orakel.

De herroeping die bewust wel een login heeft

Direct ernaast staat een functie die we andersom hebben gebouwd: herroeping met een terugbetaling naar rato zit achter een login.

Dat is geen tegenspraak. Paragraaf 312k gaat over opzegging, niet over herroeping, en er bestaat helemaal geen plicht om een online herroepingsformulier aan te bieden, zolang de vormvrije weg openblijft. Het verschil is het gevolg: een opzegging werkt voor de toekomst, een terugbetaling verplaatst nu geld, en die kun je niet terughalen.

Drie regels die daaruit volgen en die we niet afzwakken:

Geen verplichte reden. Paragraaf 355 lid 1 geeft het herroepingsrecht uitdrukkelijk zonder opgave van redenen. Het veld is optioneel en moet optioneel blijven, hoe verleidelijk een verplicht veld ook zou zijn voor de statistiek.

Na 14 dagen wordt alleen de automatische weg geweigerd, nooit de verklaring. De termijn wordt verlengd tot maximaal twaalf maanden en veertien dagen als de klant niet correct is geïnformeerd. Een algemeen "te laat" zou dus fout kunnen zijn.

De bescherming tegen dubbel uitbetalen is pessimistisch. De markering wordt gezet voordat de terugbetaling loopt. Mislukt de terugbetaling daarna, dan blijft de markering staan en neemt een mens het over. Twee keer uitbetalen is de enige uitkomst die niet te herstellen is.

Een Discord DM is geen duurzame gegevensdrager

Paragraaf 312f lid 3 vereist een contractbevestiging op een duurzame gegevensdrager, en die moet de gegeven toestemming weergeven.

Eerst stuurden we een Discord DM, omdat onze klanten daar toch al zitten. Dat volstaat niet. Een DM leeft op een platform dat wij niet beheren, en hij is niet opslaanbaar en niet onveranderbaar in de zin die de bepaling bedoelt.

Daarom kwam er een e-mail bij, en daarmee een ongemakkelijke afhankelijkheid: zijn de maildetails niet ingesteld, dan schrijft het versturen alleen een waarschuwing in de log en is de plicht niet vervuld. Een wettelijke plicht die aan een omgevingsvariabele hangt, is een toestand om je bewust van te zijn.

Geen btw, en dat moet overal hetzelfde luiden

AlphaCloud is een kleine ondernemer volgens paragraaf 19 van de Duitse wet op de omzetbelasting. Prijzen zijn eindprijzen, btw wordt nooit vermeld.

Dat klinkt als een voetnoot en is in werkelijkheid een consistentieklus over veel plekken: de prijzenpagina, het checkoutvenster, de voorwaarden, de privacyverklaring, de footer van de factuur en de configuratie bij de betaalprovider moeten allemaal hetzelfde zeggen. Er stond lange tijd een "exclusief btw" dat gewoon fout was.

En de AI

Sinds augustus 2026 gelden de transparantieverplichtingen van de Europese AI verordening volledig. Wie met een AI systeem praat, moet dat kunnen herkennen, uiterlijk bij de eerste interactie.

De belangrijkste zin voor ons uit die controle: een juridische pagina in de footer volstaat waarschijnlijk niet. De melding moet gebeuren waar de interactie gebeurt, dus in het Discord bericht zelf. Daarom stelt onze AI ticketsupport zich uit zichzelf voor en heeft hij een zichtbare knop om hem uit te schakelen. Onze uitgebreide beoordeling staat op AI transparantie.

De rode draad

Alle vier de voorbeelden hebben dezelfde vorm: de plicht leek een tekst en was in werkelijkheid een eis aan de structuur. Een login op de verkeerde plek, een foutmelding die te veel verraadt, een bevestiging in het verkeerde kanaal, een volgorde die een dubbele uitbetaling toelaat.

Daarom lezen we juridische tekst nu als een specificatie, en controleren we ook in de andere richting: doet de code echt wat onze voorwaarden zeggen? Precies bij die vraag vonden we twee echte afwijkingen, en daar is een apart artikel over.