Regulamin dla gmin

Niniejszy Regulamin (dalej: Regulamin Gmin) określa zasady udostępnienia subdomeny Serwisu lokalsi.link dla jednostek samorządu terytorialnego (dalej: Gmina).

Postanowienia ogólne

Strony umowy

• Operator Serwisu (Tomek): MAGNET MEDIC Tomasz Fiedoruk (jednoosobowa działalność gospodarcza), NIP 2530148533, REGON 331412634, ul. Dworcowa 19, 78-550 Czaplinek. Kontakt: formularz online (preferowany; w korespondencji rejestrowanej — adres siedziby).
• Gmina: jednostka samorządu terytorialnego, reprezentowana przez wójta / burmistrza / prezydenta miasta lub upoważnionego pracownika urzędu.

Cel udostępnienia subdomeny

Operator udostępnia Gminie subdomenę w postaci {nazwa-gminy}.lokalsi.link w celu prezentacji lokalnych aktorów gospodarczych (POI) zarejestrowanych dobrowolnie i samodzielnie przez tych aktorów.

Glosariusz — terminy używane w Regulaminie

Niniejszy regulamin używa terminów prawnych z RODO i orzecznictwa europejskiego. Poniższa lista wyjaśnia je w sposób przystępny dla osób bez wykształcenia prawniczego.

Status prawny Gminy — klauzula krytyczna (UNIKAJĄCA joint-controllership)

Niniejsza sekcja stanowi podstawowe ustalenie ról stron w rozumieniu RODO. Jej akceptacja jest warunkiem zawarcia umowy.

Gmina jako skin / container — nie administrator danych POI

Strony zgodnie ustalają, że w odniesieniu do danych POI publikowanych w subdomenie Gminy:

1. Administratorem danych firmowych POI w rozumieniu art. 4 pkt 7 RODO jest wyłącznie Właściciel POI (osoba fizyczna prowadząca działalność gospodarczą lub inny aktor, który zarejestrował POI).
2. Procesorem danych firmowych POI w rozumieniu art. 4 pkt 8 RODO jest wyłącznie Operator Serwisu (Tomek).
3. Gmina NIE jest administratorem ani współadministratorem danych POI. Gmina pełni wyłącznie rolę:
   • Container / hosting nazwy domeny — subdomena prezentuje POI z obszaru gminy, ale Gmina nie zarządza tymi danymi.
   • Konsumenta zagregowanych statystyk anonimowych — opisanych w sekcji „Statystyki dla Gminy".
4. Gmina nie wykonuje żadnej z czynności charakteryzujących administratora lub współadministratora danych, w szczególności:
   • Nie ustala celów przetwarzania danych POI.
   • Nie ustala sposobów przetwarzania danych POI.
   • Nie moderuje treści POI ani komentarzy.
   • Nie weryfikuje danych POI przed publikacją ani po publikacji.
   • Nie ma dostępu do panelu administracyjnego Serwisu.
   • Nie ma dostępu do bazy danych Serwisu.
   • Nie otrzymuje danych identyfikujących Właścicieli POI (email, NIP, dane szczegółowe).
   • Nie wpływa na decyzje co do retencji danych.

Tło prawne — orzecznictwo TSUE

Niniejsza konstrukcja podziału ról została ukształtowana w celu unikania ryzyka współadministrowania (joint controllership) w rozumieniu art. 26 RODO, w świetle orzeczeń Trybunału Sprawiedliwości UE:

• Wyrok TSUE z 5 czerwca 2018 r. w sprawie C-210/16 (Wirtschaftsakademie Schleswig-Holstein) — administrator strony Fanpage Facebook = współadministrator z Meta.
• Wyrok TSUE z 29 lipca 2019 r. w sprawie C-40/17 (Fashion ID) — włączenie wtyczki społecznościowej na stronę = współadministrowanie w zakresie zbierania danych przez wtyczkę.

Zgodnie z powyższym orzecznictwem, samo posiadanie subdomeny nie czyni Gminy współadministratorem, o ile Gmina nie podejmuje decyzji o celach lub sposobach przetwarzania. Akceptacja niniejszego Regulaminu = zobowiązanie Gminy do nieprzekraczania granic tej roli.

Konsekwencje przekroczenia roli

Jeśli Gmina chciałaby:

• Moderować, akceptować lub odrzucać POI / komentarze.
• Weryfikować dane Właścicieli POI przed publikacją.
• Otrzymywać szczegółowe dane Właścicieli POI.
• Brandować Serwis we własnej tożsamości wizualnej w sposób sugerujący, że Gmina jest dostawcą Serwisu.
• Wskazywać Gminę jako administratora danych w polityce prywatności subdomeny.

— to stałaby się współadministratorem z Operatorem w rozumieniu art. 26 RODO. Wówczas wymagane jest:

1. Zawarcie odrębnej umowy o współadministrowaniu (art. 26 RODO) określającej zakresy odpowiedzialności.
2. Aktualizacja polityki prywatności o status Gminy jako współadministratora.
3. Utworzenie wspólnego punktu kontaktowego dla osób, których dane dotyczą.
4. Akceptacja solidarnej odpowiedzialności za naruszenia (art. 82 ust. 4 RODO).
5. Zmiana modelu finansowego — usługa staje się zamówieniem publicznym podlegającym ustawie Prawo zamówień publicznych (PZP).

W fazie pilota Operator nie oferuje modelu współadministrowania. Gmina zainteresowana taką współpracą powinna skierować zapytanie na formularz kontaktowy.

Co Gmina otrzymuje w ramach pilota

Subdomena

• Adres subdomeny: {nazwa-gminy}.lokalsi.link.
• Skin wizualny dostosowany do herbu / kolorystyki Gminy (na życzenie).
• Strona startowa z mapą obszaru Gminy.
• Lista POI z obszaru Gminy.
• Strona informacyjna o Gminie (treść dostarcza Gmina; Operator publikuje).

Wsparcie

• Konsultacja techniczna w zakresie konfiguracji subdomeny (jednorazowo, do 4 godzin roboczych).
• Asysta przy promocji w lokalnych mediach Gminy.

Statystyki dla Gminy — wyłącznie zagregowane i anonimowe

Zakres przekazywanych statystyk

Gmina otrzymuje (raz w miesiącu, drogą emailową lub w panelu dashboard) wyłącznie statystyki zagregowane i anonimowe:

Czego Gmina NIE otrzymuje

Operator nie przekazuje Gminie:

• Listy POI z danymi kontaktowymi (email, telefon prywatny).
• Danych poszczególnych Właścicieli POI (imię, NIP).
• Treści ani autorów komentarzy.
• Adresów IP odwiedzających.
• Per-POI statystyk wyświetleń.
• Jakichkolwiek danych mogących identyfikować osoby fizyczne.

Klauzula odmowy wydania danych

W razie żądania Gminy o szczegółowe dane Właścicieli POI (np. „listę POI z emailami do zorganizowania szkolenia"), Operator odmawia wydania powołując się na:

• Brak podstawy prawnej w art. 6 RODO po stronie Gminy.
• Status Operatora jako procesora — działanie wyłącznie na polecenie administratora (POI), nie Gminy.
• Brak zgody Właścicieli POI na transfer danych do Gminy.

Operator skieruje Gminę do bezpośredniego kontaktu z poszczególnymi Właścicielami POI, którzy dobrowolnie podejmą decyzję o ujawnieniu danych Gminie.

Opcjonalna weryfikacja POI przez UM (badge fizyczny)

W ramach modelu D2POI Gmina może opcjonalnie weryfikować fizyczne istnienie POI w terenie i wystawić publiczny badge „Zweryfikowany przez UM [nazwa gminy]" w profilu punktu. Procedura: właściciel POI zgłasza prośbę w panelu (`/p/{slug}/edit`) → urzędnik UM odwiedza fizycznie lokalizację lub weryfikuje dane przez CEIDG/dokumenty → wystawia badge ważny 12 miesięcy.

Klauzula krytyczna — weryfikacja NIE czyni Gminy współadministratorem

Strony zgodnie ustalają, że:

1. Weryfikacja UM = atestacja istnienia fizycznego POI w terenie (lub atestacja zgodności z rejestrem CEIDG). Gmina sprawdza CZY POI istnieje, NIE sprawdza CO POI publikuje.
2. Weryfikacja NIE jest kontrolowaniem danych firmowych POI. Gmina nie weryfikuje, nie zmienia, nie moderuje treści wpisu POI (nazwy, adresu, telefonu, godzin, opisu, zdjęć). Zakres weryfikacji: tylko czy POI fizycznie istnieje pod podanym adresem i prowadzi działalność.
3. Wynik weryfikacji (badge „zweryfikowany" lub jego cofnięcie) ujawnia wyłącznie rezultat atestacji — nie ujawnia danych szczegółowych POI ani danych ujawnionych podczas weryfikacji (NIP, imię właściciela, telefon prywatny).
4. Weryfikacja NIE czyni Gminy współadministratorem (joint-controller) w rozumieniu art. 26 RODO. Konstrukcja zgodna z orzecznictwem TSUE C-210/16 (Wirtschaftsakademie) i C-40/17 (Fashion ID) — Gmina nie podejmuje decyzji o celach ani sposobach przetwarzania danych POI.
5. Niezależnie od ewentualnych opłat za weryfikację (w fazie pilota: bezpłatna; w przyszłości możliwa: jednorazowa opłata weryfikacyjna lub model revenue-share z Operatorem), opłata nie zmienia statusu prawnego Gminy. Gmina pozostaje skin/container.

Procedura

Co Gmina widzi w panelu weryfikacji

Urzędnik UM uzyskuje dostęp wyłącznie do następujących informacji o POI ze swojej gminy w panelu `/admin/verifications`:

• Nazwa POI (publiczna)
• Adres publiczny (publiczny)
• Telefon publiczny (publiczny)
• Status zgłoszenia weryfikacji

Gmina NIE widzi: emaila logowania POI, NIP-u, imienia i nazwiska właściciela, treści komentarzy, IP-hashy odwiedzających, audit-logów. Te dane pozostają wyłącznie u Operatora Serwisu (procesor).

Opcjonalna monetyzacja POI przez Gminę

Niniejsza Platforma umożliwia Gminie uruchomienie własnego, w pełni niezależnego systemu odpłatnego uczestnictwa dla POI (np. pakiet premium płatny przez właściciela POI bezpośrednio Gminie). Decyzja o wprowadzeniu opłat, ich wysokości, zasadach pobierania, zwrotów i obsługi reklamacji należy wyłącznie do Gminy.

Klauzula krytyczna — Operator NIE jest merchantem dla POI

Strony zgodnie ustalają, że:

1. Operator Serwisu nie pobiera żadnych opłat od POI ani bezpośrednio, ani pośrednio. Operator nie jest stroną stosunków finansowych pomiędzy Gminą a POI.
2. Gmina, działając jako operator monetyzacji POI:
   • staje się administratorem danych płatniczych POI w rozumieniu RODO (kwoty, daty, historia płatności, podstawy fakturowe);
   • jest zobowiązana do zawarcia własnej umowy powierzenia przetwarzania danych (DPA) z każdym POI przed uruchomieniem mechanizmu odpłatności;
   • samodzielnie odpowiada za zgodność pobieranych opłat z przepisami prawa, w tym z ustawą z 8 marca 1990 r. o samorządzie gminnym (art. 7, art. 9) i ustawą z 20 grudnia 1996 r. o gospodarce komunalnej (art. 10);
   • integruje wybraną przez siebie bramkę płatności (PayU, Przelewy24, Stripe) we własnym koncie merchanta;
   • Operator nie ma dostępu do danych transakcji POI (kwoty, history, statusy) ani do panelu bramki płatności.
3. Operator widzi wyłącznie zagregowane dane statystyczne dotyczące liczby POI w stanie „premium" w danym miesiącu (jeśli Gmina dobrowolnie udostępnia tę statystykę). Operator nie widzi kwot wpłat, list płatników ani historii transakcji. Dane te nie pozwalają na identyfikację indywidualnego POI ani kwot transakcji — są równoważne statystykom anonimowym opisanym w sekcji „Statystyki dla Gminy".
4. Wynagrodzenie Operatora z tytułu niniejszej Umowy (roczna opłata licencyjna, sekcja „Płatności") nie zawiera prowizji od transakcji POI ani nie jest zależne od skali monetyzacji prowadzonej przez Gminę. Operator nie jest pośrednikiem płatniczym w rozumieniu ustawy z 19 sierpnia 2011 r. o usługach płatniczych ani agentem płatniczym w rozumieniu dyrektywy PSD2.
5. Gmina zobowiązuje się do nieobciążania Operatora roszczeniami POI wynikającymi z monetyzacji, w tym przez regres, przypozwanie (art. 84 k.p.c.) lub wezwanie do udziału w postępowaniu sądowym. Wszelkie roszczenia POI dotyczące monetyzacji (zwroty, reklamacje, spory umowne) Gmina rozstrzyga samodzielnie.
6. Niezależnie od wprowadzenia monetyzacji, Gmina pozostaje skin/container (sekcja „Status prawny Gminy") i nie staje się współadministratorem danych firmowych POI ani danych platformowych Operatora.

Domyślny stan platformy

W ramach standardowej licencji POI korzystają z funkcjonalności Serwisu bezpłatnie. Wprowadzenie monetyzacji POI jest opcją Gminy — w razie jej niewprowadzenia POI pozostają bezpłatnymi użytkownikami platformy. Gmina samodzielnie zapewnia, że jej regulamin monetyzacji POI spełnia obowiązki informacyjne wobec POI, w tym wynikające z przepisów o ochronie konsumentów w zakresie mającym zastosowanie.

Moduł zgłoszeń mieszkańców (SERIA F F-D) — Gmina jako odrębny administrator

Zakres modułu

Moduł zgłoszeń obejmuje:

• Formularz publiczny /zglos-problem dostępny dla każdego mieszkańca (zalogowanego lub anonimowo z podaniem adresu email);
• Pięć kategorii zgłoszeń: śmieci/odpady, zagrożenie bezpieczeństwa, droga/chodnik, nielegalne wydarzenie, inne;
• Foto opcjonalne (do 10 MB, JPEG/PNG/WebP, automatyczny strip EXIF + content-addressable storage);
• Geolokalizacja GPS (haversine ≤200m od mapy gminy);
• Panel moderacyjny w /admin/incidents dostępny dla pracowników Urzędu Gminy (scope per gmina, anti-cross-tenant);
• Workflow statusowy: oczekuje → w trakcie → rozwiązane / odrzucone / spam;
• Mail-back do zgłaszającego po każdej zmianie statusu (DSA art. 17 ust. 1 — statement of reasons z uzasadnieniem decyzji + flaga human/automated + ścieżka odwołania).

Klauzula krytyczna — Gmina jako odrębny administrator (NIE joint-controller)

Strony zgodnie ustalają, że w zakresie modułu zgłoszeń mieszkańców:

1. Urząd Gminy jest odrębnym administratorem danych (RODO art. 4 pkt 7) w zakresie:
   • treści zgłoszeń przekazanych do rozpatrzenia (opis, foto, lokalizacja);
   • danych kontaktowych zgłaszającego (adres email, zaszyfrowany at-rest przez Operatora, deszyfrowany server-side wyłącznie dla wysyłki maila przez Urząd);
   • decyzji moderacyjnych (statusy + uzasadnienia publiczne + notatki wewnętrzne);
   • komunikacji z zgłaszającym (wiadomości UM → reporter forwardowane przez Mailer Operatora).
2. Operator pozostaje administratorem warstwy technicznej (RODO art. 4 pkt 7):
   • szyfrowanie at-rest danych zgłaszającego (AEAD XChaCha20-Poly1305-IETF z kluczami w /etc/vps-ai/lokalsi/, niedostępne dla UM);
   • transport email (Brevo API) — Operator widzi metadane wysyłki (czas, status), ale NIE treść w plain;
   • audyt każdej dekrypcji emaila zgłaszającego (point_audit_log) — Operator wykrywa anomalie typu „mass-decrypt" przez moderatora UM;
   • retencja danych według polityki cron (foto 30-180 dni od rozstrzygnięcia per kategoria; dane kontaktowe 12 miesięcy).
3. To NIE jest joint-controllership. Każda strona określa cel (UM — rozpatrzenie zgłoszenia; Operator — utrzymanie platformy) i środki (UM — proces moderacji; Operator — infrastruktura) samodzielnie i niezależnie. Zob. analogia z orzecznictwa europejskiego (Trybunał Sprawiedliwości UE — sprawy 2018-2019 dotyczące współadministrowania w przypadku wspólnego określania celów i środków).
4. Strony zawierają odrębną Umowę o współpracy w zakresie przetwarzania zgłoszeń (Załącznik 1 do niniejszego Regulaminu) — NIE jest to umowa powierzenia przetwarzania (DPA per RODO art. 28), lecz porozumienie między dwoma odrębnymi administratorami określające: (a) podział odpowiedzialności, (b) zakres wzajemnej współpracy, (c) wzajemne obowiązki informacyjne.
5. NDA dla pracowników Gminy: Gmina zobowiązuje się, że pracownicy mający dostęp do panelu moderacyjnego są związani klauzulą poufności (analogicznie do obowiązków wynikających z art. 7 ust. 5 ustawy o pracownikach samorządowych). Każda dekrypcja emaila zgłaszającego jest logowana w audycie i widoczna dla Operatora — w przypadku wykrycia nadużycia (np. masowa eksfiltracja kontaktów) Operator może zawiesić dostęp do modułu z 24-godzinnym wyprzedzeniem.

Klauzula art. 81 PrAut + art. 9 RODO — ochrona wizerunku osób na zdjęciach

W formularzu /zglos-problem (krok 2 — foto + opis) wyświetlane jest ostrzeżenie informacyjne: „Nie fotografuj rozpoznawalnych osób bez ich zgody (art. 81 prawa autorskiego + art. 9 RODO). Zdjęcie powinno pokazywać problem, nie ludzi.". Operator nie posiada automatycznego mechanizmu rozpoznawania twarzy (defer do F-D v2; opcjonalna face blur OpenCV w planach). Moderator UM jest zobowiązany do oceny każdego zdjęcia przed jego upublicznieniem (status w trakcie lub rozwiązane) — w razie wątpliwości moderator powinien skontaktować się z zgłaszającym i poprosić o zgodę osoby przedstawionej na zdjęciu LUB odrzucić zgłoszenie z odpowiednim uzasadnieniem.

Mechanizm anti-abuse

Operator stosuje opcjonalne mechanizmy ochrony przed nadużyciem modułu zgłoszeń:

• Reputacja zgłaszającego (slow-growth +1 punkt/dzień max za checkin spatial proof). Zgłaszający z reputacją ≥ 20 punktów + min. 7 dni od rejestracji + 0 odrzuconych zgłoszeń → trusted (zgłoszenia auto-przyjmowane do statusu w trakcie, skip moderation queue).
• Spamhaus DNSBL — opcjonalna weryfikacja adresu IP zgłaszającego względem listy Spamhaus ZEN (off-by-default w fazie pilotażu; włączane manualnie przez Operatora pod atakiem). Zob. Polityka prywatności sekcja F oraz analiza UK adequacy.
• Cloudflare Turnstile — opcjonalny CAPTCHA fallback (off-by-default). Włączany manualnie pod atakiem (DDoS, bot flood). Wymaga uprzedniej akceptacji DPA Cloudflare przez Operatora (RODO art. 28).
• Anti-mobbing (D12): komentarze pod zgłoszeniami są wyłączone. Mieszkańcy mogą jedynie wyrazić poparcie reakcją „+1 Też tu byłem" (jednostronna, anti-revenge-comment).

Dodatkowa opłata licencyjna za moduł zgłoszeń

Moduł zgłoszeń mieszkańców jest opcjonalny i wymaga osobnej opłaty licencyjnej w wysokości 3 000 PLN netto rocznie (flat — niezależnie od pasma liczby mieszkańców Gminy). Opłata pokrywa: hosting bezpiecznego storage foto (outside web-root, anti path-traversal), audit log dekrypcji emaila reportera, monitoring SLA panelu moderacyjnego (mail-back <5 min p99). Włączenie modułu wymaga uprzedniego zaakceptowania Załącznika 1 (Umowa o współpracy w zakresie przetwarzania zgłoszeń).

Konta mieszkańców (SERIA F F-C lite) — system rejestracji

Zakres systemu kont

• Rejestracja: /u/login — magic-link two-step (GET=peek, POST=consume; anti-prefetch Gmail/Outlook). Lazy account creation przy pierwszym zalogowaniu.
• Tożsamość mieszkańca: losowy pseudonim (`random_nick` formatu Anonimowy_Drozd_3F2A) + awatar SVG Initials generowany lokalnie (zero zewnętrznych usług). Mieszkaniec NIE podaje imienia, nazwiska ani innych danych identyfikujących.
• Email: zaszyfrowany at-rest (AEAD XChaCha20-Poly1305-IETF) z kluczami w /etc/vps-ai/lokalsi/. Email NIE jest widoczny publicznie ani Urzędowi Gminy — używany wyłącznie do magic-link logowania.
• Sesja: 30 dni (long-session z uwagi na rzadkość logowań — analog D2 magic-link). HttpOnly + Secure + SameSite=Strict cookie.
• Funkcje: ocena 1-5 gwiazdek POI + opcjonalny komentarz (anti-mobbing przez politykę moderacji POI ownera per E-seria); checkin spatial proof (max 1/dzień/POI, +1 reputation slow-growth); zgłaszanie incydentów (z trusted threshold gdy reputacja ≥ 20 + ≥7 dni + 0 dismissed).

Prawo do usunięcia (RODO art. 17)

Mieszkaniec może w każdej chwili usunąć swoje konto przez panel /u/profile (przycisk „Usuń konto"). Po usunięciu:

• Cryptographic erasure: email_enc nadpisany na NULL, blind index zastąpiony sentinel'em (`del:{random_hex}` 64 znaki), nick zmieniony na deleted#{id};
• Sesje: wszystkie aktywne tokeny sesji unieważnione (revoke);
• Cache awatara: lokalny plik SVG usunięty + CF purge URL /avatar/{seed}.svg;
• Incident reports: email kontaktowy reportera wyzerowany (analogiczna cryptographic erasure); historia incydentów (resolved/dismissed/spam) jest detached od konta (reporter_resident_id → NULL) — Gmina zachowuje treść zgłoszenia (UM jako odrębny administrator może mieć podstawę zatrzymania w interesie publicznym), ale powiązanie z konkretną osobą jest zerwane;
• Audyt erasure: wpis do point_audit_log z action gdpr17_erasure + diff_json reason — Operator ma dowód realizacji żądania (rozliczalność art. 5 ust. 2 RODO).

Brak współadministrowania z Gminą w zakresie kont

System kont mieszkańców jest funkcjonalnością Operatora — Gmina nie jest administratorem danych kont (nick, email, awatar). Gmina nie widzi listy zarejestrowanych mieszkańców ani ich emaili. W zakresie zgłoszeń incydentów Gmina widzi w panelu moderacyjnym wyłącznie pseudonim (nick) zgłaszającego + ewentualnie ostrzeżenie „zaszyfrowany email" + przycisk „Wyślij wiadomość" (z audytem dekrypcji po stronie Operatora).

Brak moderacji POI przez Gminę (kontekst — NIE dotyczy zgłoszeń mieszkańców)

Gmina nie ma prawa moderowania, edytowania, usuwania ani weryfikowania treści POI ani komentarzy w subdomenie. Jeśli Gmina uważa, że konkretna treść narusza prawo lub Regulamin, kieruje zgłoszenie w trybie notice-and-takedown (formularz /zglos) na zasadach identycznych jak każdy inny zgłaszający.

Wyjątek: moduł zgłoszeń mieszkańców (§moduł zgłoszeń) — tam Gmina jest moderatorem zgłoszeń jako odrębny administrator danych. Klauzula braku moderacji NIE dotyczy treści zgłaszanych przez mieszkańców do Urzędu.

Polityka prywatności subdomeny

W subdomenie Gminy obowiązuje Polityka prywatności Operatora (lokalsi.link/polityka-prywatnosci). Gmina nie jest wymieniona w tej polityce jako administrator ani współadministrator. Gmina nie publikuje własnej polityki prywatności dotyczącej danych POI — w przeciwnym razie powstałoby ryzyko sugerowania współadministrowania.

Sukcesja władz Gminy

Zmiana wójta / burmistrza / prezydenta miasta

Umowa wiąże Gminę jako jednostkę samorządu terytorialnego, nie zaś konkretne osoby pełniące funkcje. Zmiana osoby reprezentującej Gminę (np. po wyborach samorządowych) nie powoduje automatycznego wygaśnięcia umowy.

Aktualizacja danych kontaktowych

Gmina zobowiązuje się do aktualizacji danych kontaktowych (urzędnik prowadzący sprawę, email) w ciągu 30 dni od zmiany.

Wypowiedzenie po zmianie władz

Nowe kierownictwo Gminy może wypowiedzieć umowę z 90-dniowym wyprzedzeniem.

Płatności — model licencji rocznej

Model licencji

Udostępnienie subdomeny dla Gminy odbywa się w modelu rocznej opłaty licencyjnej. Wysokość opłaty zależy od pasma liczby mieszkańców Gminy.

Pasmo VI (miasta >250 000 mieszkańców) wymaga indywidualnej wyceny — Operator i Gmina ustalają zakres SLA, customizacji oraz cenę w odrębnej Umowie. Powyżej progu PZP 170 000 PLN netto = wymagany pełny tryb zamówień publicznych.

Kwoty w tabeli powyżej to ceny netto. Do każdej z nich doliczany jest VAT w stawce 23% zgodnie z ustawą z 11 marca 2004 r. o podatku od towarów i usług. Operator jest czynnym płatnikiem VAT — faktura zawiera kwotę netto + VAT + brutto.

Warunki płatności

• Termin płatności: 30 dni od daty wystawienia faktury.
• Faktura wystawiana jednorazowo za cały rok subskrypcyjny (z góry).
• Opcjonalnie, na wniosek Gminy: 50% przy podpisaniu Umowy + 50% w terminie 30 dni od dnia uruchomienia subdomeny.
• Wszystkie tiery mieszczą się poniżej progu zamówienia krajowego 170 000 PLN netto z ustawy Prawo zamówień publicznych (próg obowiązujący od 1 stycznia 2026 r.) — Gmina nie jest zobowiązana do przeprowadzenia przetargu. Dla zamówień powyżej 30 000 PLN netto Gminy zazwyczaj stosują wewnętrzne procedury rozeznania rynku (np. notatka służbowa, 3 oferty). Procedura proceduralna dla danej Gminy zależy od jej regulaminów wewnętrznych.

Standardowa licencja jako pełne wynagrodzenie

Roczna opłata licencyjna stanowi pełne wynagrodzenie Operatora z tytułu niniejszej Umowy. Operator nie pobiera prowizji od transakcji prowadzonych przez Gminę z POI (sekcja „Opcjonalna monetyzacja POI przez Gminę"). Jeżeli Strony zdecydują się w przyszłości na model revenue share, wymaga to zawarcia osobnego aneksu do Umowy.

Klauzula KNF/PSD2 freeze: w przypadku zawarcia aneksu o modelu revenue share, Strony zobowiązują się do uzyskania opinii prawnej dotyczącej wymogów licencyjnych KNF (ustawa z 19 sierpnia 2011 r. o usługach płatniczych, dyrektywa PSD2) przed uruchomieniem przepływów finansowych pomiędzy Stronami z tytułu monetyzacji POI. Klauzula zapobiega nieświadomemu wejściu Operatora w status pośrednika płatniczego wymagającego licencji KNF.

Pro-rata refund przy wcześniejszym wypowiedzeniu

W przypadku wypowiedzenia Umowy przez Gminę przed upływem rocznego okresu subskrypcyjnego (w szczególności przez nowe kierownictwo po wyborach samorządowych, sekcja „Sukcesja władz"), Operator zwraca proporcjonalną część opłaty licencyjnej za miesiące niewykorzystane (pro-rata, liczone w miesiącach pełnych po upływie okresu wypowiedzenia 90 dni). Klauzula chroni dyscyplinę budżetową Gminy zgodnie z ustawą o finansach publicznych.

Zmiana warunków cenowych

Operator zastrzega prawo do indeksacji opłat licencyjnych corocznie o wskaźnik inflacji GUS (CPI). Inne zmiany cenowe wymagają 90-dniowego wyprzedzenia — Gmina może wypowiedzieć umowę bezpłatnie w ciągu 90 dni od powiadomienia.

Limitacja odpowiedzialności Operatora

W zakresie dopuszczalnym przez prawo:

1. Całkowita odpowiedzialność Operatora z tytułu niniejszej Umowy, niezależnie od podstawy prawnej roszczenia (delikt, kontrakt, bezpodstawne wzbogacenie), ograniczona jest do kwoty wynagrodzenia brutto zapłaconego przez Gminę w ostatnich 12 miesiącach przed zdarzeniem wywołującym szkodę.
2. Operator nie odpowiada za:
   • Utracone korzyści Gminy lub POI.
   • Pośrednie szkody wynikające z przerw w działaniu Platformy.
   • Decyzje biznesowe Gminy dotyczące monetyzacji POI (sekcja „Opcjonalna monetyzacja POI przez Gminę").
   • Roszczenia POI wynikające z relacji finansowej Gmina–POI.
   • Szkody wynikające z działania siły wyższej, w tym incydentów u dostawców infrastruktury (Cloudflare, Hetzner Online GmbH, Brevo) — pełna lista dostawców w Polityce prywatności.
   • Treści publikowane przez Właścicieli POI (Operator jest procesorem, nie kontrolerem treści — patrz sekcja „Status prawny Gminy").
3. Ograniczenie nie dotyczy szkód wyrządzonych umyślnie lub wynikających z rażącego niedbalstwa Operatora (art. 473 § 2 Kodeksu cywilnego).
4. Strony oświadczają, że ograniczenia z ust. 1-2 zostały uzgodnione indywidualnie i są proporcjonalne do wynagrodzenia z Umowy (orzecznictwo SN: dopuszczalność umownego ograniczenia odpowiedzialności w stosunkach B2B). Gmina potwierdza, że ograniczenia odpowiedzialności są adekwatne do ryzyk związanych z usługą licencyjną o charakterze informacyjno-mapowym, a wynagrodzenie uwzględnia tę alokację ryzyka (dla zgodności z dyscypliną budżetową gminy i wymogami RIO).
5. Operator deklaruje posiadanie ubezpieczenia OC działalności IT w okresie obowiązywania Umowy (suma gwarancyjna deklarowana w Załączniku do Umowy; w fazie pilotażu: 250 000 PLN).

Wypowiedzenie umowy

Wypowiedzenie przez Gminę

Gmina może wypowiedzieć umowę z 90-dniowym wyprzedzeniem, bez podania przyczyny. W okresie wypowiedzenia:

• Subdomena działa normalnie.
• POI są informowane o planowanym wygaśnięciu subdomeny (na 60 dni przed).
• POI otrzymują możliwość przeniesienia wpisu pod domenę główną lokalsi.link lub eksportu danych.

Wypowiedzenie przez Operatora

Operator może wypowiedzieć umowę z 30-dniowym wyprzedzeniem w razie:

• Naruszenia Regulaminu przez Gminę (np. próba moderacji POI, żądanie udostępnienia danych).
• Wykorzystywania subdomeny w sposób sprzeczny z prawem.
• Sugerowania, że Gmina jest dostawcą lub administratorem Serwisu.
• Zakończenia świadczenia Serwisu (z zachowaniem analogicznej procedury change-of-control).

Skutki wypowiedzenia

• Subdomena {nazwa-gminy}.lokalsi.link jest dezaktywowana.
• POI z obszaru gminy pozostają dostępne pod główną domeną lokalsi.link.
• Statystyki dotychczas przekazane Gminie pozostają w jej posiadaniu (jako anonimowe, nie podlegają zwrotowi).

Postanowienia końcowe

Zmiana Regulaminu

Operator zastrzega prawo zmiany Regulaminu. O zmianach Gmina zostanie poinformowana emailowo z 60-dniowym wyprzedzeniem. Brak zgody = prawo wypowiedzenia umowy.

Jurysdykcja i prawo właściwe

W sprawach nieuregulowanych Regulaminem stosuje się prawo polskie, w szczególności:

• RODO oraz ustawa z 10 maja 2018 r. o ochronie danych osobowych.
• Ustawa z 23 kwietnia 1964 r. Kodeks cywilny.
• Ustawa z 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną.
• Ustawa z 8 marca 1990 r. o samorządzie gminnym.
• Ustawa z 11 września 2019 r. Prawo zamówień publicznych (jeśli zastosowanie).

Spory rozstrzyga sąd właściwy dla siedziby Operatora.

Klauzula salwatoryjna

Jeśli którekolwiek postanowienie Regulaminu zostanie uznane za nieważne, pozostałe postanowienia pozostają w mocy.

Powiązane dokumenty

• Polityka prywatności
• Regulamin dla właścicieli POI
• Strona praw RODO
• Formularz zgłoszeń DSA
• Załącznik 1 — Umowa o współpracy w zakresie przetwarzania zgłoszeń mieszkańców

Załącznik 1 — Umowa o współpracy w zakresie przetwarzania zgłoszeń mieszkańców

§1. Strony Załącznika

1. Operator (administrator warstwy technicznej): MAGNET MEDIC Tomasz Fiedoruk, NIP 2530148533, adres: ul. Dworcowa 19, 78-550 Czaplinek;
2. Urząd Gminy (administrator decyzji moderacyjnych): jednostka samorządu terytorialnego sygnująca Umowę główną (Regulamin Gmin) wraz z włączeniem modułu zgłoszeń.

§2. Przedmiot Załącznika

Załącznik określa zasady przetwarzania danych osobowych zgłaszających (mieszkańców) w ramach modułu zgłoszeń, gdzie:

• Operator jest administratorem danych warstwy technicznej (szyfrowanie at-rest, transport email, retencja);
• Urząd Gminy jest administratorem danych decyzji moderacyjnych (statusy + uzasadnienia + notatki + komunikacja z reporterem).

Strony zgodnie ustalają, że niniejszy stosunek prawny nie stanowi powierzenia przetwarzania w rozumieniu RODO art. 28 ani współadministrowania w rozumieniu RODO art. 26. Każda strona określa cele i środki przetwarzania w swoim zakresie samodzielnie i niezależnie.

§3. Obowiązki Operatora

1. Szyfrowanie at-rest wszystkich danych zgłaszającego (email AEAD XChaCha20-Poly1305-IETF, klucze poza web-rootem w /etc/vps-ai/lokalsi/);
2. Storage outside web-root dla zdjęć (/var/www/lokalsi/storage/incidents/, niedostępne bezpośrednio przez HTTP, wymagana autoryzacja przez /api/incident-photo?id=);
3. Anti path-traversal defense (lstat S_IFLNK check + realpath + str_starts_with positive assertion);
4. Audyt każdej dekrypcji emaila zgłaszającego (point_audit_log z action reporter_email_decrypt + diff_json reason + actor_id);
5. Anti-cross-tenant guard (JOIN points WHERE municipality_id=? — moderator Gminy A nie widzi zgłoszeń Gminy B);
6. Mail-back transport przez Brevo (RODO art. 28 — Brevo jest sub-processorem Operatora dla transportu wyłącznie; obecna DPA Brevo dostępna publicznie);
7. Retencja danych według polityki cron (foto 30-180 dni od rozstrzygnięcia per kategoria; dane kontaktowe 12 miesięcy od rozstrzygnięcia; audit log dekrypcji 12 miesięcy);
8. Notice o nadużyciach — Operator zobowiązuje się powiadomić Urząd Gminy w przypadku wykrycia anomalii w panelu moderacyjnym (np. masowa dekrypcja emaili przez jednego pracownika) z 24-godzinnym wyprzedzeniem przed ewentualnym zawieszeniem dostępu;
9. Breach notification — Operator zgłasza incydenty bezpieczeństwa danych do PUODO w terminie 72 godzin (RODO art. 33) oraz informuje Urząd Gminy w pierwszej możliwej chwili.

§4. Obowiązki Urzędu Gminy

1. Wyznaczenie pracowników mających dostęp do panelu /admin/incidents — dostęp ograniczony do osób z aktualnie obowiązującym upoważnieniem do przetwarzania danych osobowych (analogicznie do art. 7 ust. 5 ustawy o pracownikach samorządowych);
2. NDA dla pracowników — pracownicy mający dostęp do panelu są związani klauzulą poufności w zakresie danych zgłaszających;
3. Statement of reasons (DSA art. 17 ust. 1) — Urząd zobowiązany do podania uzasadnienia merytorycznego (publicMessage) przy każdej decyzji odrzucone lub spam. Brak uzasadnienia powoduje błąd 422 (server-side enforcement);
4. Termin moderacji — bez zbędnej zwłoki (DSA art. 17 ust. 5). Zalecany 7 dni roboczych dla statusu w trakcie, 30 dni dla finalnego rozstrzygnięcia;
5. Counter-claim handling (DSA art. 20 ust. 1-3) — odpowiedzi reportera na mail-back (Reply-To [email protected]) Urząd zobowiązany rozpatrzeć w 7 dni roboczych. Operator forwarduje odpowiedzi do Urzędu i monitoruje SLA. Klauzula safety valve: jeśli Urząd nie odpowie w terminie 7 dni roboczych, Operator samodzielnie podejmuje decyzję w sprawie counter-claim w kolejnych 7 dniach (typowo: utrzymanie decyzji Urzędu z uzasadnieniem braku odpowiedzi, lub w wyjątkowych przypadkach — przywrócenie zgłoszenia gdy treść decyzji budzi wątpliwości natury prawnej). Operator wydaje decyzję jako dostawca usług pośrednich per DSA art. 20 ust. 1 lit. c — Operator NIE deleguje obowiązku rozpatrzenia counter-claim na Urząd, a jedynie umożliwia Urzędowi pierwszeństwo rozpatrzenia jako merytorycznie właściwemu administratorowi danych decyzyjnych;
6. Klauzula informacyjna RODO art. 13 — Urząd zapewnia, że jego klauzula informacyjna na własnej stronie internetowej zawiera informację, że może być administratorem danych zgłaszających przekazanych z platformy LOKALSI w zakresie ich rozpatrzenia (podstawa: art. 6 ust. 1 lit. e RODO — zadanie publiczne);
7. Zakaz eksfiltracji — Urząd zobowiązuje się nie kopiować masowo emaili zgłaszających poza panel moderacyjny (np. import do CRM, list emailowych dla newsletterów urzędu). Każda dekrypcja emaila jest logowana w audycie Operatora;
8. Obsługa żądań RODO — Urząd jako odrębny administrator obsługuje żądania zgłaszających dotyczące danych będących w jego zakresie odpowiedzialności (np. dostęp do treści decyzji moderacyjnych, sprostowanie publicMessage). Operator obsługuje żądania dotyczące swojej warstwy (np. usunięcie konta mieszkańca, dostęp do audit logu dekrypcji).

§5. Podział odpowiedzialności (kompetencji administratora)

§6. Brak odpowiedzialności solidarnej

Strony zgodnie ustalają, że NIE ponoszą solidarnej odpowiedzialności za naruszenia RODO w zakresie modułu zgłoszeń. Każda strona odpowiada wyłącznie za naruszenia w obrębie swojej kompetencji administratora (§5 powyżej).

W szczególności:

• Operator nie odpowiada za błędne decyzje moderacyjne Urzędu (np. nieuzasadnione odrzucenie, brak publicMessage, nadużycie panelu);
• Urząd nie odpowiada za błędy warstwy technicznej Operatora (np. utrata zdjęć, awaria szyfrowania, breach kluczy);
• W przypadku roszczeń osoby trzeciej skierowanych do jednej ze stron, druga strona zobowiązuje się do współpracy informacyjnej (przekazanie posiadanych dowodów na żądanie sądu lub PUODO), ale nie do regresu finansowego.

§7. Termin obowiązywania

Załącznik obowiązuje od dnia włączenia modułu zgłoszeń w Umowie głównej (Regulamin Gmin) i wygasa wraz z wygaśnięciem Umowy głównej LUB w momencie pisemnego wypowiedzenia przez którąkolwiek ze stron z 30-dniowym wyprzedzeniem.

Po wygaśnięciu Załącznika:

• Operator zobowiązuje się do zachowania danych w retencji wynikającej z polityki cron (foto 30-180 dni / dane kontaktowe 12 miesięcy) lub do natychmiastowej cryptographic erasure na żądanie Urzędu;
• Urząd traci dostęp do panelu /admin/incidents w terminie 30 dni od wygaśnięcia;
• Aktywne zgłoszenia w statusie oczekuje / w trakcie są zamykane statusem odrzucone z uzasadnieniem „Moduł zgłoszeń został zakończony — skontaktuj się bezpośrednio z Urzędem Gminy" + mail-back do każdego reportera.

§8. Prawo właściwe i jurysdykcja

Załącznik podlega prawu polskiemu. Spory rozstrzyga sąd właściwy dla siedziby Operatora (Czaplinek, woj. zachodniopomorskie).

§9. Podpis i akceptacja

Akceptacja Załącznika następuje poprzez łączną akceptację z Umową główną (Regulamin Gmin) — Urząd Gminy akceptuje Załącznik 1 w momencie podpisania Umowy głównej z włączeniem modułu zgłoszeń.

W przypadku Gmin, które już mają zawartą Umowę główną BEZ modułu zgłoszeń, włączenie modułu wymaga osobnej akceptacji Załącznika 1 w formie pisemnej (z podpisem wójta/burmistrza/prezydenta miasta lub upoważnionego pracownika urzędu).

Wersja: 1.6 · Data: 2026-05-25 · Kontakt: formularz kontaktowy