Закон у нашому коді

Коли ми зробили Premium доступним для купівлі, то вважали, що юридична частина це кілька сторінок тексту у футері. Це була помилка. Деякі обов'язки взагалі неможливо записати в текст, бо вони визначають, як має бути побудована функція.

Чотири приклади, де це стало особливо зрозуміло. Одразу, щоб було ясно, що це таке: опис нашої реалізації, а не юридична консультація. Правила нижче належать до німецького права, бо саме в Німеччині працює AlphaCloud.

Кнопка скасування, якій не можна мати вхід

Параграф 312k Цивільного кодексу Німеччини вимагає, щоб договори, укладені онлайн, мали безпосередньо доступний спосіб скасування. З цього випливають вимоги, які неможливо додати згодом формулюванням:

• Сторінка має працювати без входу
• Вона має бути у футері кожної сторінки
• Їй потрібні два кроки: ввести, а потім підтвердити через однозначно підписану кнопку
• Має надсилатися підтвердження отримання в текстовій формі

Останній пункт визначає архітектуру. Скасування це одностороннє волевиявлення, і воно набуває чинності з моменту отримання. Тож його треба завжди реєструвати й підтверджувати, хоч би від кого воно надійшло.

Форма ніколи не має тебе відхиляти

Саме тут очевидний підхід мало не призвів до помилки.

Очевидний підхід: приймати скасування, лише якщо ID сервера й електронна пошта збігаються з активною підпискою. Звучить розумно, і помилково двічі.

По-перше, це заблокувало б справжнього клієнта, який помилився в адресі пошти або вказав іншу. Його скасування не вважалося б отриманим, підписка продовжується, а в нього є докази, що він намагався.

По-друге, і це неприємніша частина: саме повідомлення про помилку було б відповіддю. Хто отримує у відповідь «підписку не знайдено», дізнається, що цей сервер не платить. ID сервера Discord не є секретом, будь-який учасник може його прочитати. Форма стала б інструментом для зондування чужих серверів.

Рішення розділяє дві речі, які здаються однією:

	Умова
Отримання волевиявлення	безумовне, завжди реєструється й підтверджується
Виконання скасування	лише якщо вказана пошта збігається з покупцем у наших записах

Усе інше потрапляє в чергу, і його перевіряє людина. Це допустимо, бо пункт 2 параграфа 312k прямо дозволяє запитувати дані для ідентифікації. Заборонено лише вхід перед цим.

З тієї самої причини публічна відповідь може назвати дату завершення лише після підтвердження особи. Інакше підтвердження знову стає оракулом.

Відмова від договору, яка свідомо має вхід

Поруч розташована функція, яку ми побудували навпаки: відмова від договору з пропорційним поверненням коштів доступна лише після входу.

Це не суперечність. Параграф 312k стосується скасування, а не відмови від договору, і взагалі немає обов'язку пропонувати онлайн-форму відмови, поки відкритий неформальний шлях. Різниця в наслідку: скасування діє на майбутнє, повернення коштів переміщує гроші зараз, і його не можна повернути назад.

Три правила, що з цього випливають і які ми не пом'якшуємо:

Жодної обов'язкової причини. Пункт 1 параграфа 355 надає право на відмову прямо без зазначення причин. Поле необов'язкове і має таким залишатися, хоч яким спокусливим було б обов'язкове для статистики.

Після 14 днів відхиляється лише автоматичний шлях, ніколи не саме волевиявлення. Строк подовжується до дванадцяти місяців і чотирнадцяти днів, якщо клієнта не поінформували належним чином. Тож загальне «запізно» могло б бути помилковим.

Захист від подвійної виплати песимістичний. Позначка ставиться до того, як виконується повернення коштів. Якщо повернення потім не вдається, позначка залишається, і справу бере людина. Подвійна виплата це єдиний результат, який неможливо виправити.

Особисте повідомлення в Discord не є довговічним носієм

Пункт 3 параграфа 312f вимагає підтвердження договору на довговічному носії, і воно має відтворювати надану згоду.

Спочатку ми надсилали особисте повідомлення в Discord, бо наші клієнти й так там. Цього недостатньо. Особисте повідомлення живе на платформі, яку ми не контролюємо, і воно не є ані придатним для зберігання, ані незмінним у тому сенсі, який має на увазі ця норма.

Тож додався лист електронною поштою, а з ним і неприємна залежність: якщо облікові дані пошти не задано, надсилання лише пише попередження в журнал, і обов'язок не виконано. Законний обов'язок, що залежить від змінної середовища, це стан, про який варто пам'ятати.

Без ПДВ, і всюди це має звучати однаково

AlphaCloud є малим підприємством відповідно до параграфа 19 Закону Німеччини про податок на додану вартість. Ціни є кінцевими, ПДВ ніколи не вказується.

Звучить як примітка, а насправді це завдання на узгодженість у багатьох місцях: сторінка цін, діалог оформлення покупки, умови, політика конфіденційності, футер рахунку й конфігурація в платіжного провайдера мають казати одне й те саме. У нас довгий час стояло «без урахування ПДВ», і це було просто неправильно.

І ШІ

З серпня 2026 року повністю діють обов'язки щодо прозорості європейського Закону про ШІ. Будь-хто, хто розмовляє із системою ШІ, має змогу це розпізнати, найпізніше під час першої взаємодії.

Найважливіше для нас речення з цієї перевірки: юридична сторінка у футері цього, ймовірно, не задовольняє. Розкриття має відбуватися там, де відбувається взаємодія, тобто в самому повідомленні Discord. Тому наша ШІ-підтримка в тікетах сама представляється й має видиму кнопку, щоб її вимкнути. Нашу детальну оцінку можна знайти на сторінці прозорості ШІ.

Спільна нитка

Усі чотири приклади мають однакову форму: обов'язок виглядав як текст, а насправді був вимогою до структури. Вхід не в тому місці, повідомлення про помилку, яке розкриває забагато, підтвердження не в тому каналі, порядок дій, що допускає подвійну виплату.

Тож тепер ми читаємо юридичний текст як специфікацію і перевіряємо також у зворотному напрямку: чи справді код робить те, що кажуть наші умови? Саме на цьому запитанні ми знайшли дві справжні розбіжності, і про них є окрема стаття.