UMOWA POWIERZENIA PRZETWARZANIA DANYCH (DPA)
Asellio.eu — Reef Sentinel Sp. z o.o.
Obowiązuje od: 27.07.2026 r. · Wersja: 2026-07-27-b2b
Usługodawca / Procesor: Reef Sentinel Sp. z o.o., Sadurki 122, 24-150 Nałęczów, NIP 7162851708, KRS 0001229979, e-mail: info@asellio.eu
Klient / Administrator: podmiot B2B rejestrujący konto Asellio.eu (merchant / operator sklepu).
> Status dokumentu: publiczna wersja operacyjna z załącznikami A–C, aktualizowana wraz ze zmianami usługi i podprocesorów.
---
1. Przedmiot i role
1. Klient jest administratorem danych osobowych przetwarzanych w związku z korzystaniem z Usługi Asellio.eu przez klientów końcowych sklepu Klienta oraz operatorów Klienta.
2. Reef Sentinel Sp. z o.o. („Procesor”) przetwarza te dane wyłącznie w imieniu Klienta, na podstawie dokumentowanych instrukcji (konfiguracja produktu, Regulamin, niniejsza Umowa), zgodnie z art. 28 RODO.
3. Niniejsza Umowa uzupełnia Regulamin B2B Asellio.eu oraz Politykę Prywatności Administratora (Reef Sentinel) w zakresie relacji B2B.
2. Zakres i cel przetwarzania
Przetwarzanie obejmuje dane niezbędne do świadczenia platformy SaaS Asellio: widget chat + AI assistant, Live Inbox, moduł leadów, analytics konwersji, billing oraz panel operatora — zgodnie z Załącznikiem A.
Dane przechowywane są głównie w Supabase (Postgres, region UE), wektorach Qdrant, plikach object storage (Hetzner / R2) oraz u podprocesorów wymienionych w Załączniku C.
3. Obowiązki Procesora
Procesor zobowiązuje się m.in. do:
przetwarzania danych wyłącznie na udokumentowane polecenie Klienta;
zapewnienia poufności osób upoważnionych do przetwarzania;
wdrożenia środków technicznych i organizacyjnych (TOM — Załącznik B);
korzystania wyłącznie z podprocesorów z Załącznika C (z ogólną zgodą Klienta i procedurą powiadomień o zmianach);
wsparcia Klienta w realizacji praw osób, których dane dotyczą (w zakresie technicznie możliwym);
usuwania lub zwrotu danych po zakończeniu Usługi, z uwzględnieniem polityki retencji (`backend/core/data_retention.py`, runbook OPS).
4. Obowiązki Administratora (Klienta)
Klient odpowiada m.in. za:
wskazanie właściwej podstawy prawnej wobec klientów końcowych sklepu;
transparentność wobec klientów końcowych (polityka prywatności sklepu, cookies/CMP);
instrukcje co do zakresu przetwarzania (włączenie/wyłączenie modułów, konfiguracja widgetu);
nieprzekazywanie do Usługi danych bez odpowiedniego uprawnienia.
5. Podprocesorzy
Klient wyraża ogólną zgodę na korzystanie z podprocesorów niezbędnych do świadczenia Usługi, wymienionych w Załączniku C i w publicznym rejestrze `docs/legal/subprocessors.md` (strona publiczna `/subprocessors`).
Procesor informuje Klienta o planowanych zmianach listy podprocesorów z wyprzedzeniem co najmniej 30 dni (kanał: e-mail i changelog produktu). Klient może wnieść uzasadniony sprzeciw zgodnie z Regulaminem.
6. Transfery poza EOG
Część podprocesorów (m.in. dostawcy LLM, Stripe, e-mail US) może przetwarzać dane poza EOG. Procesor stosuje odpowiednie zabezpieczenia przewidziane w RODO, w szczególności Standardowe Klauzule Umowne (SCC).
Szczegóły podstaw transferu dla poszczególnych dostawców (SCC / adekwatność / inne) są utrzymywane w rejestrze podprocesorów i dokumentacji kontraktowej.
7. Incydenty bezpieczeństwa
Procesor informuje Klienta bez zbędnej zwłoki o naruszeniu ochrony danych osobowych mającym wpływ na dane powierzone przez Klienta, z informacjami wymaganymi art. 33 ust. 3 RODO, o ile są dostępne.
Procedura operacyjna: `docs/compliance/runbooks/privacy-incident-response.md` (Sprint 2).
8. Audyt i współpracja
Na uzasadniony wniosek Klienta Procesor udostępnia informacje niezbędne do wykazania zgodności z art. 28 RODO (m.in. TOM, rejestr podprocesorów), w rozsądnym zakresie, z zachowaniem poufności i bez naruszenia bezpieczeństwa innych klientów.
9. Czas trwania i usunięcie danych
Umowa obowiązuje przez czas korzystania z Usługi. Po zakończeniu:
dane operacyjne Klienta w Supabase/Qdrant/R2 są usuwane zgodnie z procedurą offboarding (`hard_delete_tenant` + purge per tenant);
okresy retencji w trakcie umowy — zgodnie z macierzą retencji (Załącznik A, sekcja retencja);
dane billing/faktury — przechowywane przez okres wymagany przepisami (wyłączone z auto-purge).
10. Zmiany DPA
Procesor może aktualizować DPA z ważnych powodów prawnych lub technicznych. Nowa wersja wymaga akceptacji w panelu (mechanizm `accepted_dpa_version`).
11. Kontakt
Sprawy DPA i ochrony danych: info@asellio.eu
---
Załącznik A — Opis przetwarzania (Data Processing Description)
Wersja techniczna: 2026-07-27 · Stack: Supabase (Postgres) + Qdrant + object storage
Poniższy opis mapuje moduły produktu do kategorii danych, operacji i retencji. Odniesienia do tabel Supabase są zgodne z `backend/core/data_retention.py`.
---
A.1. Widget chat + AI assistant
| Aspekt | Opis |
|---|---|
| Kategorie osób | Klienci końcowi sklepu Klienta (kupujący, odwiedzający); anonimowi odwiedzający przed identyfikacją |
| Kategorie danych | Treść wiadomości chat (pytania/odpowiedzi); metadane sesji (`session_id`, `visitor_id` po zgodzie analytics); język rozmowy; identyfikatory produktów w rekomendacjach; opcjonalnie dane kontaktowe jeśli użytkownik je poda w treści |
| Operacje | Zbieranie (widget → API), utrwalanie (`chat_logs`, `query_logs`), organizowanie (historia sesji), wykorzystywanie (generowanie odpowiedzi LLM, RAG z Qdrant), usuwanie (retencja 180d / 90d) |
| Store | `chat_logs`, `query_logs`, `commercial_signals`, `alerts`, `qa_match_events` (Supabase); embeddingi/chunki w Qdrant |
| Retencja | `chat_logs` 180 dni · `query_logs` 90 dni · `commercial_signals` 365 dni · `alerts` / `qa_match_events` 180 dni |
| Uwagi | Pipeline LLM stosuje limity kontekstu i redakcję PII w output (`LLM_REDACT_OUTPUT_PII`). Widget analytics (`visitor_id`, eventy konwersji) — tylko po zgodzie użytkownika sklepu (moduł analytics — patrz A.4). |
---
A.2. Live Inbox (operator na żywo)
| Aspekt | Opis |
|---|---|
| Kategorie osób | Klienci końcowie sklepu; operatorzy Klienta (konsultanci) |
| Kategorie danych | Treść wiadomości (klient ↔ operator); metadane handoff (`session_id`, `visitor_id`, status, ticket_number); skrócone podsumowanie kontekstu (`context_summary`); załączniki (jeśli włączone) |
| Operacje | Utworzenie handoff, kolejkowanie, realtime/polling, zapis historii, archiwizacja, usuwanie po retencji |
| Store | `inbox_handoffs`, `inbox_messages` (Supabase); Supabase Realtime (transport) |
| Retencja | 365 dni (`created_at`) dla obu tabel |
| Uwagi | Legacy tabela `handoff_requests` (Firestore) — nieaktywna w nowym stacku; wyłącznie cleanup migracyjny jeśli resztki istnieją. |
---
A.3. Leads / CRM
| Aspekt | Opis |
|---|---|
| Kategorie osób | Potencjalni klienci / leady ze sklepu Klienta |
| Kategorie danych | Imię, e-mail, telefon (jeśli podane), źródło leada, notatki operatora, status lejka, historia zdarzeń |
| Operacje | Rejestracja leada (formularz/widget), aktualizacja statusu, eksport, usuwanie |
| Store | Docelowo Supabase (migracja z legacy). Obecny kod `backend/repositories/leads.py` wskazuje na legacy Firestore — traktowane jako dług techniczny do jednorazowej migracji/cleanup (nie core P0). |
| Retencja (docelowa) | 730 dni dla rekordów lead + zdarzeń (po migracji do Supabase) |
| Uwagi | Live Inbox może tworzyć powiązane rekordy w `inbox_handoffs` niezależnie od modułu leads. |
---
A.4. Analytics / funnel (Conversation-to-Revenue)
| Aspekt | Opis |
|---|---|
| Kategorie osób | Anonimowi odwiedzający sklepu (po zgodzie analytics w widgetcie) |
| Kategorie danych | `visitor_id` (UUID), `session_id`, typ eventu, hash zapytania (`query_hash`), długość zapytania, metadane atrybucji zakupu (`order_id`, kwota — bez danych osobowych kupującego) |
| Operacje | Zbieranie (po opt-in), utrwalanie, agregacja funnel, usuwanie |
| Store | `conversion_events` (Supabase) |
| Retencja | 365 dni |
| Uwagi | Oddzielone od chat runtime — pełna treść rozmowy nie trafia do `conversion_events`. Szczegóły: `docs/privacy-analytics.md`. |
---
A.5. Billing / faktury
| Aspekt | Opis |
|---|---|
| Kategorie osób | Przedstawiciele Klienta B2B; dane firmy Klienta |
| Kategorie danych | NIP/VAT, nazwa firmy, adres, e-mail rozliczeniowy, historia subskrypcji, identyfikatory Stripe, numery faktur iFirmy |
| Operacje | Rozliczenia, wystawianie faktur, audyt zmian planu |
| Store | Supabase (`tenants`, profile billing, outbox faktur); Stripe (płatności); iFirma (dokumenty księgowe) |
| Retencja | Wyłączone z auto-purge — 5–10 lat (zgodnie z obowiązkami podatkowymi i rachunkowymi) |
| Uwagi | Akceptacja DPA/Terms zapisywana w `tenants.billing.legal_acceptance`. |
---
A.6. Panel operatora / admin (użytkownicy B2B Klienta)
| Aspekt | Opis |
|---|---|
| Kategorie osób | Pracownicy/współpracownicy Klienta; użytkownicy wewnętrzni Reef Sentinel (super-admin) |
| Kategorie danych | E-mail, rola RBAC, przypisanie `tenant_id`, logi aktywności panelu, preferencje językowe |
| Operacje | Uwierzytelnianie (Firebase Auth), autoryzacja (RBAC), audyt |
| Store | Firebase Auth + Supabase (`tenants`, konfiguracje); logi aplikacji (hosting) |
| Retencja | Konto aktywne przez czas umowy + okres po rozwiązaniu wynikający z Regulaminu |
| Uwagi | Dane super-admin Reef Sentinel — Administrator w rozumieniu Polityki Prywatności Asellio (relacja B2B z Klientem to niniejsza DPA dla danych klientów końcowych sklepu). |
---
A.7. Pliki i baza wiedzy (RAG)
| Aspekt | Opis |
|---|---|
| Kategorie osób | Brak bezpośrednio — przetwarzane treści pochodzą od Klienta |
| Kategorie danych | Dokumenty KB, opisy produktów, embeddingi wektorowe, pliki crawl |
| Operacje | Upload, indeksacja, wyszukiwanie semantyczne, usuwanie przy offboarding tenanta |
| Store | Qdrant (wektory); object storage Hetzner/R2 (pliki źródłowe) |
| Retencja | Czas życia konta + usunięcie przy `hard_delete_tenant` |
| Uwagi | Klient odpowiada za legalność wgranych treści. |
---
Załącznik B — Środki techniczne i organizacyjne (TOM)
Opis środków zgodny z art. 32 RODO, pogrupowany wg celów: Poufność, Integralność, Dostępność, Odporność.
---
B.1. Poufność (Confidentiality)
| Środek | Implementacja w Asellio |
|---|---|
| Kontrola dostępu | RBAC (`super_admin`, `store_admin`); izolacja per `tenant_id` w warstwie aplikacji; `access_control_repository.tenant_access_allowed()` |
| Least privilege | Klucze service-role Supabase tylko backend/worker; brak bezpośredniego dostępu sklepu do DB |
| Uwierzytelnianie | Firebase Auth (panel); widget HMAC (`widget-session`) dla publicznych endpointów chat |
| Poufność personelu | Dostęp do prod na zasadzie need-to-know; secrets w Coolify / env na serwerze Hetzner |
| Szyfrowanie in transit | TLS 1.2+ na wszystkich połączeniach API; HTTPS do Supabase, Qdrant, storage |
| Minimalizacja danych | Analytics: hash+length zamiast pełnego `query_text`; redakcja PII w output LLM |
---
B.2. Integralność (Integrity)
| Środek | Implementacja |
|---|---|
| Walidacja wejścia | Pydantic DTO; guardrails LLM (`LLM_SECURITY_ENABLED`, limity znaków) |
| Audyt billing | `legal_acceptance_log`, `billing_stripe` append_audit |
| Wersjonowanie prawne | `CURRENT_DPA_VERSION`, log akceptacji per tenant |
| Integralność plików | Object storage z kontrolą dostępu; checksumy przy uploadzie (crawl pipeline) |
---
B.3. Dostępność (Availability)
| Środek | Implementacja |
|---|---|
| Hosting | Hetzner (własny VPS) + Coolify — backend, worker, frontend |
| Baza danych | Supabase managed Postgres (backupy dostawcy) |
| Monitoring | Logi aplikacji; Langfuse (LLM traces); alerty operacyjne (docelowo) |
| RPO / RTO | Parametry odtwarzania i ciągłości działania są określane kontraktowo (SLA/uzgodnienia indywidualne) |
---
B.4. Odporność (Resilience) i procedury
| Środek | Implementacja |
|---|---|
| Retencja i purge | Cron `DATA_RETENTION_CRON_*`; runbook `docs/compliance/runbooks/data-retention.md` |
| Incident response | Runbook `privacy-incident-response.md` (Sprint 2) |
| Rate limiting | Publiczne endpointy (trial, widget, chat) — throttling per IP/tenant |
| Backup restore | Procedura odzyskiwania Supabase z backupu dostawcy — runbook OPS (Sprint 2) |
---
B.5. Ocena skutków / DPIA
Moduły wysokiego ryzyka (chat z PII klientów końcowych, LLM) — Klient jako Administrator ocenia konieczność DPIA po swojej stronie. Procesor udostępnia niniejszy TOM i Załącznik A jako input.
---
Załącznik C — Podprocesorzy
Aktualna lista (single source of truth): [`docs/legal/subprocessors.md`](../../legal/subprocessors.md) · publicznie: https://asellio.eu/subprocessors
Aktualizacje: powiadomienie Klientów ≥30 dni przed dodaniem lub zamianą podprocesora przetwarzającego dane powierzone (kanał: e-mail i changelog produktu).
Skrót (pełna tabela w pliku powyżej — kolumny: provider, service, data_categories, location, transfer_mechanism, role, since, last_reviewed):
| Provider | Service | Location (skrót) | Transfer |
|---|---|---|---|
| Supabase | Postgres, Realtime | UE | EOG |
| Qdrant | Vector DB | UE | EOG/SCC |
| Hetzner | Object storage + app hosting (Coolify, VPS) | DE / UE | EOG |
| Cloudflare | R2 (legacy) / CDN | UE/US | SCC |
| Stripe | Payments | EU/US | SCC |
| iFirma | Invoicing | PL | EOG |
| Brevo / Resend | EU / US | EOG/SCC | |
| OpenRouter / OpenAI / Anthropic | LLM | US/EU | SCC |
| Langfuse | LLM observability | UE | EOG/SCC |
| Google Firebase | Panel auth | US/EU | SCC |
Legacy (nieaktywny): Google Firestore — wyłącznie resztki danych do migracji/cleanup.
Szczegóły procedury 30-dniowego notice i aktualnych podstaw transferu są utrzymywane operacyjnie w rejestrze podprocesorów i dokumentacji umownej.