Wersja 2026-09 · obowiązuje od 3.09.2026

Polityka prywatności BloomDesk

DRAFT — dokument roboczy do weryfikacji przez kancelarię przed publikacją produkcyjną.

Wersja draft: 2026-09. Nie stanowi porady prawnej. Nie został zatwierdzony przez kancelarię.

Niniejsza Polityka dotyczy platformy BloomDesk (produkt SaaS). Administratorem w zakresie opisanych tu własnych procesów jest BloomTech Engineering Bogdan Kwiatkowski (dalej: „BloomTech Engineering”, „Usługodawca”).

---

1. Administrator

BloomTech Engineering jest administratorem danych osobowych w procesach, w których samodzielnie określa cele i sposoby ich przetwarzania, opisanych poniżej. Podmiot:

BloomTech Engineering Bogdan Kwiatkowski

Dane kontaktowe:

Adres siedziby / NIP / CEIDG — [DO USTALENIA PRZED PRODUKCJĄ / DO WERYFIKACJI KANCELARII] (nie duplikujemy tu konfiguracji Billing).

Platforma BloomDesk jest dostępna pod adresami:

---

2. Zakres Polityki

Niniejsza Polityka opisuje, w jaki sposób BloomTech Engineering przetwarza dane w związku z:

  • kontem i logowaniem do BloomDesk;
  • Zespołem (tenantem technicznym Klienta);
  • zaproszeniami do Zespołu;
  • rozliczeniami, subskrypcjami i fakturowaniem;
  • bezpieczeństwem i logami operacyjnymi;
  • Product Assistant (własny asystent AI na stronach BloomDesk);
  • informacyjnie — przetwarzaniem danych powierzonych przez Klienta (widget na stronie Klienta, rozmowy, RAG, Q&A, notatki AI).

Twarda zasada: sekcje opisujące BloomTech Engineering jako procesora mają charakter informacyjny. Nie zastępują obowiązku informacyjnego Klienta wobec osób korzystających z widgetu na stronie Klienta. Polityka pod adresem bloomdesk.pl/privacy nie jest centralną polityką prywatności wszystkich firm korzystających z BloomDesk.

Aktualny publiczny rejestr dalszych podmiotów: /subprocessors. Umowa powierzenia (DPA) jest osobnym dokumentem (/dpa) i nie zastępuje niniejszej Polityki.

---

3. Kiedy BloomTech Engineering jest administratorem

BloomTech Engineering jest administratorem m.in. w zakresie:

  • kont użytkowników BloomDesk (rejestracja, logowanie, bezpieczeństwo konta);
  • danych firmy / Zespołu niezbędnych do świadczenia platformy;
  • zaproszeń do Zespołu (adres e-mail zaproszonego, treść zaproszenia);
  • kontaktu z Usługodawcą;
  • metadanych rozliczeniowych i informacji o subskrypcjach;
  • fakturowania;
  • zapobiegania nadużyciom i bezpieczeństwa (fraud / security);
  • Product Assistant na bloomdesk.pl (własny czat produktowy BloomDesk);
  • własnych logów bezpieczeństwa i operacyjnych w zakresie własnych celów.

BloomTech Engineering działa jako niezależny administrator w zakresie własnych celów związanych z prowadzeniem konta, bezpieczeństwem i świadczeniem platformy. Nie wyłącza to odrębnej roli Klienta jako administratora danych jego pracowników lub współpracowników (np. służbowego adresu e-mail, stanowiska, decyzji o przydzieleniu dostępu). Relacje graniczne — [DO WERYFIKACJI KANCELARII].

---

4. Jakie dane własnych użytkowników przetwarzamy

W procesach, w których BloomTech Engineering jest administratorem, mogą być przetwarzane w szczególności:

  • adres e-mail, imię i nazwisko (jeśli podane);
  • dane logowania i sesji uwierzytelnienia (w tym niezbędne ciasteczko sesji);
  • dane Zespołu i profilu billingowego (nazwa firmy, NIP, adres, rodzaj nabywcy);
  • identyfikatory Stripe (Customer ID, Subscription ID, status, okres, plan) oraz saldo środków (impulsów);
  • referencje płatności i dane potrzebne do uprawnień (entitlements) — bez pełnych danych karty;
  • treść i metadane Product Assistant (wiadomości, identyfikator sesji);
  • adres IP, dane techniczne żądania, logi bezpieczeństwa i diagnostyki;
  • dowody akceptacji Regulaminu przez Zespół (documentId / skrót dokumentu) oraz logi doręczeń zmian Regulaminu.

Nie przechowujemy PAN, CVC ani pełnych danych instrumentu płatniczego. Właściwe dane karty obsługuje Stripe w ramach Stripe Checkout (hosted). [DO WERYFIKACJI KANCELARII] — mieszana rola Stripe (processor / controller).

---

5. Podstawy i cele przetwarzania

Cele (własne procesy administratora): prowadzenie konta i Zespołu, świadczenie platformy BloomDesk, rozliczenia i fakturowanie, bezpieczeństwo, obsługa techniczna, obowiązki prawne, Product Assistant.

Podstawy prawne — szkic, każda podstawa wymaga zatwierdzenia:

  • wykonanie umowy (art. 6 ust. 1 lit. b RODO) — [DO WERYFIKACJI KANCELARII];
  • prawnie uzasadniony interes (art. 6 ust. 1 lit. f RODO) — [DO WERYFIKACJI KANCELARII];
  • obowiązek prawny (art. 6 ust. 1 lit. c RODO), w tym rachunkowość — [DO WERYFIKACJI KANCELARII];
  • zgoda nie jest automatycznie wymagana przed każdą wiadomością w czacie i nie stosujemy checkboxa „wyrażam zgodę na przetwarzanie danych” przy każdej turze rozmowy.

Dokładne mapowanie cel → podstawa dla każdego procesu — [DO WERYFIKACJI KANCELARII].

---

6. Zaproszeni użytkownicy (art. 14)

Gdy Właściciel Zespołu (Klient) zaprasza osobę do BloomDesk, BloomTech Engineering może otrzymać adres e-mail zaproszonej osoby od Klienta, a nie od tej osoby. Poniższy opis jest szkicem (nie stanowi kompletnego art. 14).

  • Źródło: Klient / Właściciel, który wpisał adres e-mail w panelu.
  • Kategorie: adres e-mail; ewentualnie imię i nazwisko zapraszającego; nazwa Zespołu.
  • Cele przed powstaniem konta: wysłanie zaproszenia i umożliwienie dołączenia do Zespołu Klienta.
  • Podstawy: [DO WERYFIKACJI KANCELARII] (w tym ewentualny prawnie uzasadniony interes — bez twierdzenia w tym drafcie, która podstawa jest właściwa).
  • Odbiorcy: hosting poczty (OVHcloud MX Plan — produkcja) oraz logi transakcyjne wiadomości; infrastruktura niezbędna do świadczenia usługi.
  • Retencja: rekordy zaproszeń oraz logi e-mail — przez okres wynikający z obsługi zaproszenia i obowiązków prawnych (okres do ustalenia z kancelarią).
  • Prawa osoby bez konta: przysługują prawa z RODO; kontakt poza panelem — kanały z §19. Wiadomość zaproszenia zawiera krótką pierwszą warstwę informacji i link do niniejszej Polityki; nie zastępuje pełnej treści tego dokumentu.
  • Umowa: zaproszony, który dołącza do Zespołu, jest Authorized User Klienta. Nie zawiera osobnej umowy z BloomTech Engineering i nie składa osobnej akceptacji Regulaminu.

---

7. Kiedy BloomTech Engineering działa jako procesor Klienta

Dla danych przetwarzanych w ramach usług Klienta na BloomDesk:

``text Klient = administrator BloomTech Engineering = procesor ``

Dotyczy w szczególności:

  • rozmów prowadzonych przez widget BloomDesk na stronie Klienta;
  • treści przesyłanych przez użytkowników końcowych;
  • sesji rozmów i wiadomości;
  • dokumentów bazy wiedzy (RAG), chunków, embeddingów;
  • pozycji Q&A;
  • automatycznych notatek AI (session notes);
  • informacji wykorzystywanych do routingu pokoi;
  • Query Builder / Retrieval Gate;
  • innych treści Klienta przetwarzanych przez AI w celu świadczenia usługi.

BloomTech Engineering nie przedstawia się jako administrator wszystkich rozmów prowadzonych na stronach klientów.

Szczegóły powierzenia: /dpa. Publiczny rejestr dalszych podmiotów: /subprocessors.

---

8. Widget BloomDesk na stronie Klienta

W przypadku widgetu działającego na stronie Klienta administratorem danych rozmowy jest co do zasady ten Klient. BloomTech Engineering przetwarza dane na jego zlecenie.

Żądania dotyczące takiej rozmowy osoba powinna kierować przede wszystkim do Klienta. BloomTech Engineering pomaga Klientowi wykonać prawa osoby jako procesor, w granicach DPA i technicznych możliwości.

Widget kieruje użytkownika końcowego do Polityki prywatności Klienta (URL podawany przez Klienta), a nie do niniejszej Polityki BloomDesk.

[DO POTWIERDZENIA: ustawienie URL Privacy w panelu / wtyczce WordPress] — w repozytorium aplikacji SaaS brak kolumny z URL-em Privacy Klienta; konfiguracja — jeśli istnieje — może znajdować się we wtyczce WP (osobne repozytorium).

Szablon fragmentu do doklejenia przez Klienta: /docs/widget/privacy.

Komunikacja przeglądarki użytkownika końcowego z widgetem WordPress odbywa się przez proxy WordPress Klienta do infrastruktury BloomDesk (ai.bloomdesk.pl). Żądanie do hosta AI wykonuje serwer WordPress, a nie bezpośrednio przeglądarka odwiedzającego — w zakresie cookie Cloudflare na urządzeniu użytkownika widgetu.

---

9. AI, OpenRouter i Privacy Gateway

BloomDesk korzysta z infrastruktury OpenRouter do wnioskowania AI, w tym m.in.:

  • generowania odpowiedzi w czacie;
  • embeddingów (zapytania, dokumenty RAG, Q&A);
  • weryfikacji Q&A;
  • routingu;
  • Query Builder / Retrieval Gate;
  • automatycznych notatek AI.

W produkcji, przy włączonej bramce prywatności, chronione treści użytkownika i bazy wiedzy przechodzą przez Privacy Gateway przed wysłaniem do OpenRouter.

BloomDesk stosuje mechanizmy pseudonimizacji wybranych identyfikatorów przed przekazaniem treści dostawcom AI. Mechanizmy te ograniczają zakres przekazywanych danych identyfikujących, lecz nie zapewniają pełnej anonimizacji i mogą nie rozpoznać wszystkich danych osobowych zawartych w treści.

Rozpoznawane są obecnie wybrane kategorie (m.in. osoba, e-mail, telefon, PESEL, NIP, polski dowód osobisty). Inne dane (np. adres zamieszkania, tajemnice handlowe, URL, dane finansowe, hasła) mogą pozostać w treści bez zamiany, jeżeli nie zostaną rozpoznane.

Część konfiguracji AI (m.in. system prompt, opisy routingu, przykłady dodatnie) może być przekazywana do dostawcy modelu bez pseudonimizacji stosowanej do treści rozmów.

Środki techniczne runtime (nie gwarancja prawna): ZDR oraz data_collection=deny; odpowiedzi nie są zapisywane w response cache OpenRouter (X-OpenRouter-Cache: false). Nie oznacza to automatycznie wyłączenia wszystkich mechanizmów tymczasowego prompt caching po stronie Model Provider — zakres zależy od endpointu i polityki providera. [DO WERYFIKACJI OPERACYJNEJ PRZED PRODUKCJĄ] — snapshot warunków OpenRouter (Terms, DPA, SCC) dla używanego konta.

Dalsi Model Providers (dostawcy modeli wybierani przez OpenRouter w zależności od modelu) otrzymują treść potrzebną do wnioskowania. Nie kwalifikujemy ich automatycznie jako subprocesorów BloomDesk — [DO WERYFIKACJI KANCELARII]. Ujawniamy ich jako dalszych dostawców / odbiorców AI. Lista zależy od konfiguracji modeli; aktualny rejestr OpenRouter: https://openrouter.ai/providers.

---

10. RAG, Q&A, embeddingi i notatki AI

W roli procesora Klienta przetwarzane są m.in.:

  • dokumenty wgrane do bazy wiedzy i ich fragmenty;
  • wektory (embeddingi) — treść wysyłana do modelu embeddingowego podlega pseudonimizacji kategorii; oryginał w bazie Klienta pozostaje bez zamiany;
  • pytania i odpowiedzi Q&A;
  • notatki AI z rozmowy.

Przechowywanie: przez okres korzystania przez Klienta z usługi albo do usunięcia przez Klienta. Po ostatecznym usunięciu Zespołu dane operacyjne RAG/Q&A/rozmów są usuwane z systemu aktywnego (kaskada bazy), z uwzględnieniem cyklu rotacji backupów. Nie używamy sformułowania „bezterminowo”.

---

11. Płatności (Stripe)

Stripe tworzy płatne subskrypcje, obsługuje płatność i jest źródłem stanu subskrypcji/płatności.

BloomDesk zapisuje pomocniczo we własnej bazie m.in.: Stripe Customer ID, Subscription ID, status, okres, plan, saldo środków, referencje płatności i dane potrzebne do uprawnień.

BloomDesk nie przechowuje pełnych danych karty; właściwe dane instrumentu płatniczego obsługuje Stripe (Checkout / hosted surfaces).

Stripe może mieć role mieszane (procesor / własny administrator) — [DO WERYFIKACJI KANCELARII]. Stripe nie jest automatycznie subprocesorem danych rozmów / RAG / Q&A.

---

12. Fakturowanie (Fakturownia)

Fakturownia realizuje dokumenty sprzedażowe. Trafiają do niej dane wymagane do wystawienia faktury (nabywca, NIP, adres, pozycje, kwoty) — w procesie, w którym BloomTech Engineering jest administratorem własnych danych billingowych Klienta.

Fakturownia nie otrzymuje treści rozmów, dokumentów RAG ani Q&A.

---

13. Cloudflare

Ruch do bloomdesk.pl i ai.bloomdesk.pl ma docelowo przechodzić przez Cloudflare (reverse proxy, TLS, WAF, DDoS / security, ewentualnie mechanizmy rate-limit / challenge).

  • gdy BloomTech Engineering jest administratorem — Cloudflare działa jako procesor BloomTech Engineering;
  • gdy BloomTech Engineering przetwarza dane powierzone przez Klienta — Cloudflare działa jako subprocesor.

Nie zakładamy Cloudflare Web Analytics, Zaraz ani marketingowego trackingu, jeżeli nie są wdrożone. Nie twierdzimy, że Cloudflare automatycznie wymaga bannera zgód cookies. Status konkretnych cookies security Cloudflare (__cf_bm, cf_clearance itd.) — [DO USTALENIA PRZED PRODUKCJĄ] w zależności od włączonego zestawu funkcji.

---

14. Hosting, kopia zapasowa, poczta (OVHcloud)

Infrastruktura podstawowa: serwer dedykowany OVHcloud, region Europa, Polska, Warszawa (eu-central-waw). Na serwerze m.in.: aplikacja (Next.js), API AI (FastAPI), Postgres, Redis, procesy robocze, Loki, Grafana, Prometheus.

Grafana, Loki i Prometheus są self-hosted na infrastrukturze BloomTech Engineering — nie traktujemy ich jako zewnętrznych dostawców.

Kopia zapasowa pełnego serwera: OVHcloud, Europa, Niemcy, Limburg. Dokładna retencja kopii — [DO USTALENIA PRZED PRODUKCJĄ / DO KANCELARII]. Nie wymyślamy TTL.

Osobny backup Postgres — nie jest jeszcze zaprojektowany. Nie twierdzimy, że istnieje. Do ustalenia przed produkcją: częstotliwość, lokalizacja, szyfrowanie, TTL, test restore.

Poczta transakcyjna (produkcja): OVHcloud MX Plan (zaproszenia, reset hasła, powiadomienia o Regulaminie, e-maile billingowe). W tym zakresie BloomTech Engineering jest z reguły administratorem, a OVHcloud — procesorem. MX Plan nie jest automatycznie subprocesorem danych rozmów Klienta, dopóki nie wysyła treści tych rozmów.

Środowisko deweloperskie może używać innego SMTP — dokumenty opisują produkcję.

---

15. Retencja

| Kategoria | Okres (docelowy MVP) | Status | |---|---|---| | Konto / Zespół | Okres korzystania z usługi + obowiązki prawne (np. rachunkowość) | Obowiązuje | | Rozmowy (sesja, wiadomości, notatki AI związane z rozmową) | 180 dni od ostatniej aktywności rozmowy, następnie automatyczne usunięcie | [WYMAGA IMPLEMENTACJI PRZED PRODUKCJĄ] — w kodzie nie ma jeszcze crona purge rozmów; istnieje zamykanie sesji z bezczynności i flaga archiwum bez kasowania treści | | RAG / Q&A / dokumenty | Okres korzystania z usługi lub do usunięcia przez Klienta; po usunięciu Zespołu — usunięcie z systemu aktywnego | Kaskada przy usunięciu Zespołu istnieje; backup — rotacja | | Billing / ledger / faktury | Zgodnie z przepisami rachunkowymi; wpisy płatności mogą przetrwać usunięcie Zespołu | Obowiązuje | | Dowody akceptacji Regulaminu i doręczeń | Niezależnie od usunięcia konta/Zespołu | Okres [DO WERYFIKACJI KANCELARII] | | Logi aplikacyjne / security / access | Maksymalna standardowa retencja do 90 dni; konkretne TTL mogą być krótsze | [DO USTALENIA PRZED PRODUKCJĄ] — obecnie Loki 7 dni; Prometheus (metryki, nie logi) 15 dni. Nie wydłużamy Prometheus do 90 dni. | | Backup infrastruktury | Rotacja | TTL [DO USTALENIA PRZED PRODUKCJĄ] |

Purge rozmów (gdy wdrożony) ma obejmować dane związane z rozmową (sesja, wiadomości, notatki AI, metadane wyłącznie sesyjne), z wyłączeniem danych księgowych, billing ledger oraz statystyk anonimowych/agregowanych wymaganych niezależnie.

Prometheus: założenie projektowe, że etykiety nie zawierają e-maila, promptu, treści rozmów, tokenów ani pełnych identyfikatorów użytkownika. Nie jest to gwarancja certyfikacyjna — [DO WERYFIKACJI PRZED PRODUKCJĄ] na konfiguracji.

---

16. Transfery poza EOG

Hosting i kopia zapasowa serwera (Warszawa, Limburg) znajdują się w EOG.

OpenRouter (USA) oraz Model Providers mogą oznaczać transfer poza EOG. Mechanizm (DPA OpenRouter inkorporowane przez odniesienie do commercial Terms, SCC) — [DO WERYFIKACJI OPERACYJNEJ PRZED PRODUKCJĄ]: potwierdzenie, że warunki dotyczą używanego konta; zachowanie snapshotu / linku / daty wersji Terms i DPA OpenRouter.

---

17. Prawa osób

Przysługują prawa z RODO (dostęp, sprostowanie, usunięcie, ograniczenie, sprzeciw, przenoszenie), w granicach danej podstawy prawnej.

  • Dane platformy BloomDesk (konto, zaproszenie, billing): kontakt z BloomTech Engineering (§19). Osoby z kontem — kanały w panelu. Osoby zaproszone bez konta — strona bloomtech.pl oraz e-mail z §1.
  • Dane rozmowy na stronie Klienta: w pierwszej kolejności Klient (administrator). BloomTech Engineering wspiera Klienta jako procesor.

---

18. Cookies, pamięć przeglądarki, model bez bannera

BloomDesk projektuje własne mechanizmy storage tak, aby wykorzystywać wyłącznie mechanizmy konieczne do świadczenia żądanych usług i bezpieczeństwa. Nie obiecujemy absolutnego braku bannera w każdej konfiguracji.

Zamierzenia MVP:

  • brak marketingowych cookies;
  • brak przeglądarkowego analytics / trackingu (brak GA/GTM/Meta/Hotjar/Clarity/PostHog itd. po stronie BloomDesk);
  • Cloudflare wyłącznie jako warstwa security / infrastruktury;
  • ciasteczko sesji logowania = niezbędne;
  • Product Assistant: sessionStorage (bt_pa_public_* / bt_pa_docs_*) — token sesji i identyfikator sesji niezbędne do ciągłości rozmowy; pamięć znika z kartą/sesją przeglądarki;
  • widget WordPress Klienta (wg audytu wtyczki): brak własnych cookies i localStorage; sessionStorage (identyfikator sesji, offset pollingu, cache ostatnich wiadomości, last activity, znacznik po reCAPTCHA) — do końca sesji karty/okna.

[DO DECYZJI PRZED PRODUKCJĄ] — Product Assistant zapisuje także stan otwarcia okna (bt_pa_*_open). Token i ID sesji są silniej powiązane ze świadczeniem usługi; *_open jest preferencją interfejsu. Ocena pod art. 399 PKE. Preferowane rozwiązanie: usunąć persystencję *_open albo trzymać ją tylko w pamięci UI, jeśli nie jest konieczna do świadczenia usługi.

W przypadku dodania przez Klienta własnych integracji (np. Google reCAPTCHA, analytics, marketing) Klient odpowiada za ich ocenę obowiązków cookies / storage. reCAPTCHA jest opcjonalna we wtyczce WP; Google nie jest stałym subprocesorem BloomDesk dla każdego Klienta.

Nawet gdy technicznie niezbędny storage jest zwolniony z obowiązku zgody, pozostają obowiązki informacyjne RODO. Niniejsza Polityka stanowi informację dla procesów, w których BloomTech Engineering jest administratorem.

---

19. Kontakt

BloomTech Engineering Bogdan Kwiatkowski — [automatyzacja@bloomtech.pl](mailto:automatyzacja@bloomtech.pl), https://bloomtech.pl, https://bloomtech.pl/#contact.

---

20. Elementy wymagające decyzji kancelarii lub produkcji

Nie są ustalonymi faktami m.in.:

  • dokładne podstawy art. 6 dla poszczególnych procesów;
  • NIP / adres CEIDG;
  • relacje graniczne controller / processor / współadministrowanie;
  • mechanizm związania i dowodu wersji DPA wobec konkretnego Klienta ([DO USTALENIA PRZED PUBLIKACJĄ] — team_terms_acceptances dowodzi Regulaminu, nie automatycznie DPA);
  • mechanizm powiadamiania o zmianie subprocesorów i sprzeciwu;
  • kwalifikacja prawna OpenRouter Model Providers;
  • SCC / TIA / snapshot DPA OpenRouter dla konta produkcyjnego;
  • TTL backupu OVH (Limburg) i projekt backupu Postgres;
  • wdrożenie purge rozmów 180 dni;
  • finalna polityka retencji logów (maks. 90 dni vs. obecne Loki 7 dni);
  • zestaw funkcji Cloudflare i cookies security;
  • Product Assistant *_open;
  • URL Polityki Klienta w widgetcie WP.

Lista ta nie jest wyczerpująca.

Stały adres tej wersji: /privacy/2026-09

Aktualna wersjaStrona główna