La legge dentro il nostro codice
Un pulsante di disdetta che deve funzionare senza login. Un modulo che non deve mai respingerti. Perché per noi gli obblighi legali sono architettura, non testo di contorno.

Quando abbiamo reso acquistabile Premium, pensavamo che la parte legale fosse qualche pagina di testo nel footer. Era sbagliato. Alcuni obblighi non si possono proprio scrivere in un testo, perché stabiliscono come deve essere costruita una funzionalità.
Quattro esempi in cui la cosa è diventata particolarmente chiara. Una premessa, perché sia chiaro di cosa si tratta: è una descrizione della nostra implementazione, non una consulenza legale. Le regole che seguono sono di diritto tedesco, perché è lì che opera AlphaCloud.
Il pulsante di disdetta che non può avere un login
Il paragrafo 312k del codice civile tedesco impone che i contratti conclusi online offrano un modo direttamente raggiungibile per disdirli. Ne nascono requisiti che non puoi aggiungere dopo con qualche frase:
- La pagina deve funzionare senza accedere
- Deve stare nel footer di ogni pagina
- Servono due passaggi: inserire i dati, poi confermare con un pulsante dall'etichetta inequivocabile
- Deve partire una conferma di ricezione in forma testuale
L'ultimo punto determina l'architettura. Una disdetta è una dichiarazione unilaterale e ha effetto con la ricezione. Quindi deve essere registrata e confermata sempre, da chiunque provenga.
Il modulo non deve mai respingerti
È qui che l'approccio più ovvio per poco non ci è costato un errore.
L'approccio ovvio: accettare la disdetta solo se ID del server ed email corrispondono a un abbonamento attivo. Sembra ragionevole, ed è sbagliato due volte.
Primo, escluderebbe un cliente vero che sbaglia a digitare l'email o indica un indirizzo diverso. La sua disdetta non sarebbe stata ricevuta, l'abbonamento si rinnova, e lui ha in mano la prova di averci provato.
Secondo, ed è la parte più spiacevole: il messaggio di errore stesso sarebbe una risposta. Chi riceve "nessun abbonamento trovato" scopre che quel server non paga. L'ID di un server Discord non è un segreto, qualsiasi membro può leggerlo. Il modulo diventerebbe uno strumento per sondare i server altrui.
La soluzione separa due cose che sembrano una sola:
| Condizione | |
|---|---|
| Ricezione della dichiarazione | incondizionata, sempre registrata e confermata |
| Esecuzione della disdetta | solo se l'email inserita corrisponde all'acquirente registrato |
Tutto il resto finisce in una coda e viene esaminato da una persona. È ammesso perché il paragrafo 312k, comma 2, consente espressamente di chiedere dati identificativi. È vietato solo un login davanti.
Per lo stesso motivo la risposta pubblica può indicare la data di fine solo dopo che l'identità è confermata. Altrimenti la conferma torna a essere un oracolo.
Il recesso che ha volutamente un login
Proprio accanto c'è una funzionalità che abbiamo costruito al contrario: il recesso con rimborso proporzionale sta dietro un accesso.
Non è una contraddizione. Il paragrafo 312k riguarda la disdetta, non il recesso, e non esiste alcun obbligo di offrire un modulo di recesso online, purché la via informale resti aperta. La differenza è la conseguenza: una disdetta agisce sul futuro, un rimborso sposta denaro adesso, e non si può riprendere indietro.
Tre regole che ne derivano, e che non ammorbidiamo:
Nessun motivo obbligatorio. Il paragrafo 355, comma 1, concede il recesso espressamente senza indicarne i motivi. Il campo è facoltativo e deve restare facoltativo, per quanto un campo obbligatorio sarebbe allettante per le statistiche.
Dopo 14 giorni viene rifiutata solo la via automatica, mai la dichiarazione. Il termine si allunga fino a dodici mesi e quattordici giorni se il cliente non è stato informato correttamente. Un "troppo tardi" generico potrebbe quindi essere sbagliato.
La protezione contro il doppio pagamento è pessimista. Il contrassegno viene impostato prima che parta il rimborso. Se poi il rimborso fallisce, il contrassegno resta e subentra una persona. Pagare due volte è l'unico esito che non si può sanare.
Un DM di Discord non è un supporto durevole
Il paragrafo 312f, comma 3, richiede una conferma del contratto su un supporto durevole, e deve riprodurre il consenso dato.
All'inizio inviavamo un messaggio diretto su Discord, perché è il canale in cui i nostri clienti si trovano comunque. Non basta. Un DM vive su una piattaforma che non controlliamo, e non è né archiviabile né inalterabile nel senso inteso dalla norma.
Così si è aggiunta un'email, e con essa una dipendenza scomoda: se le credenziali di posta non sono impostate, l'invio scrive solo un avviso nel log e l'obbligo non è soddisfatto. Un obbligo di legge appeso a una variabile d'ambiente è una situazione di cui vale la pena essere consapevoli.
Niente IVA, e deve leggersi uguale ovunque
AlphaCloud è una piccola impresa ai sensi del paragrafo 19 della legge tedesca sull'IVA. I prezzi sono prezzi finali, l'IVA non viene mai indicata.
Sembra una nota a piè di pagina ed è in realtà un lavoro di coerenza su molti punti: la pagina dei prezzi, la finestra di checkout, i termini, l'informativa sulla privacy, il piè di pagina delle fatture e la configurazione presso il fornitore di pagamenti devono dire tutti la stessa cosa. Per molto tempo avevamo un "IVA esclusa" che era semplicemente sbagliato.
E l'IA
Da agosto 2026 si applicano per intero gli obblighi di trasparenza dell'AI Act europeo. Chiunque parli con un sistema di IA deve poterlo riconoscere, al più tardi alla prima interazione.
La frase più importante per noi emersa da quella verifica: una pagina legale nel footer probabilmente non basta. L'informazione deve avvenire dove avviene l'interazione, quindi nel messaggio Discord stesso. Per questo il nostro supporto ticket con IA si presenta da solo e ha un pulsante visibile per disattivarlo. La nostra valutazione dettagliata è in AI transparency.
Il filo comune
Tutti e quattro gli esempi hanno la stessa forma: l'obbligo sembrava un testo ed era in realtà un requisito sulla struttura. Un login nel posto sbagliato, un messaggio di errore che rivela troppo, una conferma nel canale sbagliato, un ordine delle operazioni che consente un doppio pagamento.
Per questo ora leggiamo i testi legali come una specifica, e controlliamo anche nell'altra direzione: il codice fa davvero ciò che dicono i nostri termini? Proprio su questa domanda abbiamo trovato due divergenze reali, e su quelle c'è un articolo a parte.
Altri articoli
Perché quasi tutto in AlphaCloud resta gratuito
La maggior parte dei bot Discord chiude le funzionalità più utili dietro un abbonamento. Noi volutamente no, e ha meno a che fare con la generosità di quanto sembri.
Dietro le quinteTenere d'occhio 4.000 server Discord: Grafana, PostHog e cosa ci hanno mostrato
Un loop che causava in silenzio metà del nostro traffico, tre milioni di richieste inutili al giorno e un attacco finito dopo un minuto. Cosa vede il nostro monitoraggio, e cosa volutamente non vede.
Dietro le quinteCosa ha portato alla luce un audit del nostro sistema di pagamento
Due problemi critici, e nessuno dei due era dove avremmo guardato. Un resoconto aperto su errori che nel frattempo sono stati corretti.