Polityka prywatności Mnemy
Obowiązuje od: [⬜ UZUPEŁNIĆ: data publikacji] Wersja: 1.0 · opisuje stan kodu z 16 sierpnia 2026 (migracje do 0072)
Ten dokument mówi, co robimy z danymi osób korzystających z Mnemy. To, co dzieje się z danymi, które organizacja klienta *wprowadza* do Mnemy — nazwiska uczestników spotkań, treść nagrań — opisuje umowa powierzenia.
Podstawa faktyczna. Zdania o mechanizmach pochodzą z przeglądu kodu (86 ustaleń, każde sprawdzone drugim przebiegiem przeciw źródłom). Pięć zdań „prawie prawdziwych" zostało po drodze poprawionych — m.in. twierdzenie o pięcioletniej retencji dziennika audytu, która nie istnieje.
1. Kto odpowiada za dane
Administrator: [⬜ UZUPEŁNIĆ: pełna nazwa, forma prawna], [⬜ UZUPEŁNIĆ: adres], NIP [⬜ UZUPEŁNIĆ], REGON [⬜ UZUPEŁNIĆ][, KRS ⬜].
Kontakt we wszystkich sprawach dotyczących danych: kontakt@komi-t.pl.
[⬜ UZUPEŁNIĆ: „Nie wyznaczyliśmy Inspektora Ochrony Danych — przy naszej skali nie mamy takiego obowiązku." ALBO dane IOD.]
2. Jakie dane zbieramy
2.1 Dane konta
| Dane | Skąd | Po co |
|---|---|---|
| Imię i nazwisko | Rejestracja albo zaproszenie | Żeby w organizacji było wiadomo, kto co zrobił |
| Adres e-mail (login) | Jw. | Logowanie, kod resetu, powiadomienia |
| Hasło | Ustawia użytkownik | Uwierzytelnienie — przechowujemy wyłącznie skrót |
| Rola (administrator / członek) | Nadaje administrator | Zakres uprawnień |
| Czas ostatniego logowania, licznik nieudanych prób, blokada | Powstaje samo | Ochrona konta przed zgadywaniem hasła |
Adres bywa w Mnemie w trzech miejscach naraz i mówimy to wprost, bo wpływa na realizację praw: w koncie (jako login), na liście osób organizacji oraz — do wygaśnięcia — w zapisie rejestracji. Przy wysyłce pierwszeństwo ma adres z konta.
2.2 Czego nie zbieramy — i jeden wyjątek
Aplikacja nie odczytuje ani nie zapisuje adresu IP ani informacji o przeglądarce. Żadna z 42 tabel bazy nie ma takiej kolumny; sesja i token nie zapisują, skąd nastąpiło logowanie.
Wyjątek: serwer prowadzi techniczne dzienniki dostępu (nginx i serwer aplikacji), do których trafiają adresy IP i adresy żądań. To jest przetwarzanie danych osobowych, choć dzieje się poniżej aplikacji. [⬜ UZUPEŁNIĆ: okres przechowywania dzienników — rotacja nie jest dziś ustawiona.]
Nie używamy narzędzi analitycznych ani marketingowych. Sprawdzone w kodzie: zero Google Analytics, zero pikseli, zero zewnętrznych skryptów. Kroje pisma pobieramy w czasie budowania i serwujemy z własnego serwera, więc przeglądarka nie łączy się przy tym z nikim innym.
2.3 Ciasteczka
Mnema ustawia jedno ciasteczko: sesja, po zalogowaniu. Jest httpOnly (JavaScript go nie widzi), sameSite=lax, żyje 14 dni. Zawiera losowy token; w bazie leży wyłącznie jego skrót SHA-256, więc z bazy nie da się go odtworzyć.
Nie ma ciasteczek analitycznych ani marketingowych, więc nie ma też banera zgody — nie mamy o co pytać.
W pamięci przeglądarki zostają drobne ustawienia widoku, a przy instalacji jako aplikacja — pliki potrzebne do działania bez sieci.
3. Cele i podstawy prawne
| Cel | Podstawa (RODO) |
|---|---|
| Świadczenie usługi: konto, praca w organizacji | art. 6 ust. 1 lit. b |
| Rozliczenia i dokumenty księgowe | art. 6 ust. 1 lit. b i lit. c |
| Bezpieczeństwo: dziennik zdarzeń, blokada po nieudanych logowaniach | art. 6 ust. 1 lit. f |
| Powiadomienia o zadaniach i spotkaniach | art. 6 ust. 1 lit. b — to jest sama usługa, nie marketing |
Nie wysyłamy marketingu, nie profilujemy i nie podejmujemy zautomatyzowanych decyzji wywołujących skutki prawne.
4. Komu przekazujemy dane
| Kto | Co dostaje | Po co |
|---|---|---|
| Stripe Payments Europe | Identyfikator i nazwa organizacji, adres e-mail administratora kupującego, liczba miejsc albo godzin | Płatności. Numeru karty nie widzimy i nie przechowujemy |
| Brevo | Adres odbiorcy, temat i treść wiadomości | Wysyłka poczty |
| Dostawca powiadomień push przeglądarki | Sam sygnał „obudź się" — bez treści | Powiadomienia na telefon |
| [⬜ UZUPEŁNIĆ: dostawca hostingu] | Wszystko, co jest na serwerze | Utrzymanie |
Model językowy. To, czy treść wychodzi poza serwer, zależy od ustawienia organizacji (polityka modelu), widocznego dla administratora. Domyślnie tryb chmurowy jest wyłączony.
Nie sprzedajemy danych i nie udostępniamy ich nikomu poza powyższymi wykonawcami oraz organami, którym musimy je wydać z mocy prawa.
5. Jak długo trzymamy dane
| Dane | Jak długo |
|---|---|
| Nagranie audio spotkania | 30 dni od spotkania (domyślnie; zamrażane osobno przy każdym spotkaniu, organizacja może ustawić inaczej). Potem plik znika z dysku; zostaje zapis, że spotkanie było — z tytułem, czasem trwania i listą uczestników |
| Zapis rejestracji | Niewykorzystany — do wygaśnięcia kodu (24 h). Wykorzystany — 90 dni |
| Sesje | 14 dni albo do wylogowania |
| Tokeny urządzeń i kalendarza | Do wybranej daty (domyślnie 90 dni) albo do odwołania |
| Konto | Do usunięcia przez administratora albo żądania z art. 17 |
| Transkrypty i wpisy bazy wiedzy | Organizacja może ustawić politykę usuwania, ale nic nie uruchamia jej automatycznie — trzeba o to poprosić |
| Pozostałe dane (zadania, notatki, komentarze, dziennik zdarzeń i 33 inne rodzaje) | Bezterminowo, do żądania usunięcia albo zamknięcia organizacji |
Dwa ostatnie wiersze są niewygodne i dlatego stoją tu wprost. Skracanie tych okresów jest u nas robotą do zrobienia, a nie stanem faktycznym.
6. Jak chronimy dane
Wymieniamy środki, które naprawdę są w kodzie:
- Rozdzielenie organizacji na poziomie bazy. 39 z 42 tabel ma reguły dostępu
w samym Postgresie (Row Level Security), łącznie 75 polityk; rola aplikacji nie ma prawa ich obejść. Do tego drugi filtr w kodzie każdego zapytania. Żeby dane jednej organizacji trafiły do drugiej, muszą zawieść obie bariery — a każdą sprawdza się osobno, celowo ją psując.
- Hasła liczone algorytmem scrypt (n=16384, r=8, p=1), z losową solą,
porównywane w czasie stałym. Hasła jawnego nie ma nigdzie, także w kopiach. Wymóg: co najmniej 10 znaków. Po serii nieudanych prób konto jest czasowo blokowane, a blokada sama się kończy.
- Tokeny (sesja, urządzenie, kalendarz, zaproszenie, reset) leżą w bazie
wyłącznie jako skróty SHA-256.
- HTTPS na całej drodze do przeglądarki.
- Dziennik zdarzeń zapisuje, kto i kiedy zmienił dane.
Czego nie ma — mówimy to, zamiast przemilczeć:
- brak logowania dwuskładnikowego;
- token kalendarza jedzie w adresie URL (tak działa subskrypcja kalendarza
w Google i Apple — inaczej się nie da), więc trafia do historii przeglądarki i dzienników pośredników. Kto go zdobędzie, zobaczy terminy do czasu odwołania tokenu. Token można odwołać w każdej chwili;
- [⬜ UZUPEŁNIĆ: czy dysk serwera jest szyfrowany];
- [⬜ UZUPEŁNIĆ: gdzie leżą kopie zapasowe i czy są szyfrowane];
- dwie tabele porównywarki modeli nie mają rozdzielenia organizacji — dziś są
puste i nie trafiają do nich dane klientów.
7. Prawa osób
Przysługuje prawo dostępu, sprostowania, usunięcia, ograniczenia, przenoszenia, sprzeciwu wobec przetwarzania opartego na uzasadnionym interesie oraz skargi do Prezesa UODO.
Wniosek: kontakt@komi-t.pl albo przez administratora organizacji. Odpowiadamy w ciągu miesiąca.
Co potrafimy dziś i czego jeszcze nie:
- Dostęp (art. 15) — przygotowujemy dokument z 24 kategoriami danych.
Trzy kategorie trzeba dziś dołożyć ręcznie, bo automat ich nie obejmuje: zapisane subskrypcje powiadomień, spotkania zaplanowane przez tę osobę oraz jej udział w cudzych spotkaniach. Naprawiamy to; do tego czasu uzupełniamy wniosek ręcznie.
- Usunięcie (art. 17) — kasujemy albo, tam gdzie wiersz musi zostać jako
dowód podstawy prawnej (np. zgoda na nagrywanie), usuwamy z niego treść, zostawiając sam fakt zdarzenia.
- Załączniki i pliki wymagają osobnego kroku i są w dokumencie oznaczone.
8. Zmiany
O istotnych zmianach informujemy pocztą na adres konta, z wyprzedzeniem co najmniej 14 dni. Historia wersji jest w repozytorium produktu.