Data Processing Agreement DarhimLabs

Niniejsza Umowa Powierzenia Przetwarzania Danych Osobowych („DPA”) stanowi część umowy pomiędzy klientem korzystającym z platformy DarhimLabs („Administrator”) a DarhimLabs, marką należącą do osoby fizycznej Jan Juszczyk („Procesor”). Dokument określa zasady przetwarzania danych osobowych w imieniu Administratora, zakres instrukcji, listę subprocesorów, transfery poza EOG, audyty, środki techniczne i organizacyjne oraz zasady zwrotu lub usunięcia danych po zakończeniu umowy.

1. Definicje

Administrator oznacza klienta DarhimLabs, który samodzielnie decyduje o celach i sposobach przetwarzania danych osobowych swoich użytkowników, klientów, leadów, pacjentów, kandydatów, kontrahentów lub innych osób końcowych. Administrator odpowiada za podstawę prawną przetwarzania, treść klauzul informacyjnych, zakres zbieranych danych, retencję i sposób realizacji praw osób, których dane dotyczą.

Procesor oznacza DarhimLabs, markę należącą do osoby fizycznej Jan Juszczyk, który przetwarza dane osobowe wyłącznie na udokumentowane polecenie Administratora, w celu świadczenia usług AI Business OS. DarhimLabs nie decyduje samodzielnie o biznesowym celu przetwarzania danych klientów końcowych Administratora, chyba że odrębnie opisano rolę Administratora w Polityce prywatności.

Dane Klienta oznaczają wszystkie dane, które Administrator lub jego użytkownicy wprowadzają, przesyłają, synchronizują, importują lub generują w Platformie. Mogą obejmować treść rozmów, dane kontaktowe, załączniki, dokumenty bazy wiedzy, transkrypcje połączeń, konfiguracje botów, dane leadów, notatki wewnętrzne i logi operacyjne. Zakres zależy od modułów włączonych przez Administratora.

RODO oznacza Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679. Terminy takie jak „dane osobowe”, „naruszenie ochrony danych osobowych”, „podmiot przetwarzający”, „subprocesor”, „osoba, której dane dotyczą” i „szczególne kategorie danych” mają znaczenie nadane im w RODO.

2. Przedmiot i czas trwania przetwarzania

Przedmiotem powierzenia jest przetwarzanie danych osobowych niezbędne do świadczenia usług DarhimLabs, w szczególności obsługi Command Center, Inbox, AI Agents Studio, Voice Contact Center, Knowledge / RAG, AI Quality Lab, CRM, automatyzacji, integracji, API v2 i funkcji compliance. Przetwarzanie obejmuje operacje takie jak zapis, odczyt, przechowywanie, synchronizacja, analiza, klasyfikacja, indeksowanie, generowanie odpowiedzi AI, routing, eksport, usuwanie i archiwizacja.

Czas trwania przetwarzania odpowiada czasowi obowiązywania umowy o świadczenie usług DarhimLabs oraz okresom retencji skonfigurowanym przez Administratora. Po zakończeniu umowy dane są zwracane lub usuwane zgodnie z sekcją 11 DPA, chyba że dalsze przechowywanie jest wymagane przez prawo, niezbędne do rozliczeń, bezpieczeństwa, dochodzenia roszczeń lub wykonania obowiązków z audytu.

Charakter przetwarzania jest zasadniczo zautomatyzowany i elektroniczny. DarhimLabs może wykonywać ręczne operacje tylko w ograniczonym zakresie, na przykład przy obsłudze zgłoszenia wsparcia, incydentu bezpieczeństwa, audytu, migracji danych, usunięcia danych lub wykonania polecenia Administratora. Dostęp personelu DarhimLabs jest objęty zasadą least privilege, MFA, rejestrowaniem aktywności i obowiązkiem poufności.

3. Rodzaje danych i kategorie osób

Kategorie danych zależą od konfiguracji workspace’u oraz kanałów włączonych przez Administratora. Platforma może przetwarzać dane identyfikacyjne, kontaktowe, techniczne, operacyjne, komunikacyjne, transakcyjne, preferencyjne i jakościowe. Przykłady obejmują imię, nazwisko, adres e-mail, numer telefonu, treść rozmów, załączniki, transkrypcje, nagrania, adres IP w formie ograniczonej, identyfikatory sesji, lead score, tagi, statusy, intencje, sentyment, historię działań i metadane integracji.

Platforma może przetwarzać szczególne kategorie danych z art. 9 RODO tylko wtedy, gdy Administrator ma odpowiednią podstawę prawną i świadomie skonfiguruje proces, który takie dane przyjmuje. DarhimLabs udostępnia mechanizmy ograniczające ryzyko, takie jak maskowanie PII, blokady tematów, human approval, krótsza retencja, oznaczenia compliance, audit log i konfiguracje zakazujące botom udzielania porad medycznych, prawnych lub finansowych bez udziału człowieka.

Kategorie osób, których dane mogą dotyczyć, obejmują klientów końcowych Administratora, potencjalnych klientów, pacjentów, kandydatów, osoby kontaktujące się przez widget, telefon, e-mail, WhatsApp, Messenger, Instagram, SMS, Slack lub Teams, użytkowników aplikacji mobilnej, członków zespołu Administratora, osoby objęte procesem DSAR oraz osoby wymienione w dokumentach importowanych do Knowledge / RAG.

• Dane rozmów: wiadomości, notatki, załączniki, statusy, SLA, tagi i przypisania.
• Dane Voice: numer telefonu, transkrypt, czas trwania, nagranie, wynik ASR i TTS.
• Dane RAG: dokument, chunk, metadane źródła, freshness, citation coverage i embedding.
• Dane CRM: kontakt, firma, deal, aktywność, scoring i historia interakcji.
• Dane audytu: aktor, akcja, czas, IP, user-agent, target i metadata zmian.

4. Instrukcje Administratora

Administrator poleca DarhimLabs przetwarzanie danych wyłącznie w celu świadczenia usług objętych umową, utrzymania bezpieczeństwa, obsługi wsparcia, realizacji funkcji aktywowanych w panelu oraz wykonania uzgodnionych operacji technicznych. Instrukcje Administratora mogą wynikać z konfiguracji Platformy, ustawień retencji, integracji, API, umowy, zgłoszenia wsparcia, podpisanego zamówienia lub innego udokumentowanego kanału uzgodnionego przez strony.

Jeżeli DarhimLabs uzna, że instrukcja Administratora narusza RODO lub inne przepisy ochrony danych, poinformuje Administratora przed wykonaniem instrukcji, chyba że prawo zabrania takiego powiadomienia. DarhimLabs nie jest zobowiązany do oceny wszystkich podstaw prawnych Administratora, ale może odmówić wykonania instrukcji, która w oczywisty sposób naraża osoby na naruszenie praw lub jest sprzeczna z obowiązującymi przepisami.

Administrator odpowiada za konfigurację agentów AI, promptów, guardrails, polityk zatwierdzeń, kanałów, retencji, źródeł wiedzy i integracji. DarhimLabs zapewnia domyślne ustawienia bezpieczeństwa, ale nie zastępuje oceny prawnej Administratora, w szczególności w branżach regulowanych: medycznej, finansowej, prawnej, edukacyjnej, rekrutacyjnej i publicznej.

5. Obowiązki Procesora

DarhimLabs zobowiązuje się przetwarzać dane osobowe wyłącznie na udokumentowane polecenie Administratora, z wyjątkiem sytuacji, gdy obowiązek przetwarzania wynika z prawa Unii Europejskiej lub prawa państwa członkowskiego. W takim przypadku DarhimLabs informuje Administratora o tym obowiązku przed rozpoczęciem przetwarzania, chyba że prawo zakazuje ujawnienia takiej informacji z ważnych względów interesu publicznego.

DarhimLabs zapewnia, że osoby upoważnione do przetwarzania danych zobowiązały się do zachowania poufności lub podlegają ustawowemu obowiązkowi poufności. Dostęp do środowisk produkcyjnych jest ograniczony, wymaga MFA, jest logowany i podlega okresowym przeglądom. Dostęp do danych Klienta w ramach wsparcia technicznego jest udzielany tylko wtedy, gdy jest to potrzebne do rozwiązania zgłoszenia lub wykonania polecenia Administratora.

DarhimLabs wdraża środki techniczne i organizacyjne opisane w sekcji 10 DPA. Środki te obejmują szyfrowanie, pseudonimizację tam, gdzie jest to właściwe, kontrolę dostępu, segmentację workspace’ów, RLS w PostgreSQL, monitorowanie, backupy, testy odtworzeniowe, procedury incident response, szkolenia zespołu oraz regularne testowanie skuteczności zabezpieczeń zgodnie z art. 32 RODO.

DarhimLabs nie sprzedaje danych Klienta, nie wykorzystuje ich do trenowania własnych modeli AI ani modeli dostawców LLM, chyba że Administrator wyraźnie i odrębnie poleci inaczej w ramach funkcji eksperymentalnej. Domyślnie wywołania OpenAI i Anthropic są konfigurowane tak, aby dane nie były wykorzystywane do treningu modeli.

6. Pomoc, DSAR i naruszenia

DarhimLabs wspiera Administratora w realizacji praw osób, których dane dotyczą, w zakresie możliwym z uwzględnieniem charakteru przetwarzania. Obejmuje to wyszukanie danych, eksport, usunięcie, ograniczenie przetwarzania, korektę, przeniesienie danych i dostarczenie informacji wymaganych do odpowiedzi na wniosek DSAR. Wnioski publiczne można składać przez formularz DSAR, ale w relacji Procesor — Administrator finalna decyzja o realizacji należy do Administratora.

DarhimLabs pomaga Administratorowi w spełnieniu obowiązków z art. 32-36 RODO, w tym w zakresie bezpieczeństwa przetwarzania, naruszeń ochrony danych, oceny skutków dla ochrony danych (DPIA) oraz uprzednich konsultacji z organem nadzorczym, jeśli są wymagane. Pomoc może obejmować dokumentację TOM, listę subprocesorów, logi audytu, opis architektury, raporty SOC 2, executive summary testów penetracyjnych i informacje o retencji.

W przypadku naruszenia ochrony danych osobowych dotyczącego danych Klienta DarhimLabs informuje Administratora bez zbędnej zwłoki po potwierdzeniu zdarzenia. Dla klientów Enterprise celem operacyjnym jest pierwsze powiadomienie w ciągu 24 godzin od potwierdzenia. Powiadomienie zawiera znany zakres zdarzenia, typ danych, potencjalne skutki, podjęte działania ograniczające i punkt kontaktowy do dalszej koordynacji.

7. Lista subprocesorów

Administrator udziela DarhimLabs ogólnej zgody na korzystanie z subprocesorów wymienionych w tej sekcji. Każdy subprocesor jest objęty umową nakładającą obowiązki ochrony danych nie mniej restrykcyjne niż obowiązki DarhimLabs wynikające z niniejszej DPA, w zakresie wymaganym przez art. 28 ust. 4 RODO. DarhimLabs pozostaje odpowiedzialny wobec Administratora za wykonanie obowiązków subprocesora.

DarhimLabs prowadzi proces oceny subprocesorów obejmujący cel przetwarzania, lokalizację danych, certyfikacje, zabezpieczenia, transfer poza EOG, historię incydentów, warunki retencji, możliwości usunięcia danych i dostępność dokumentacji audytowej. Subprocesorzy są wybierani zgodnie z zasadą minimalizacji: korzystamy z nich tylko wtedy, gdy są potrzebni do dostarczenia konkretnej funkcji Platformy.

O planowanej zmianie subprocesora, która może mieć istotny wpływ na przetwarzanie danych Klienta, DarhimLabs informuje Administratora co najmniej 30 dni przed wprowadzeniem zmiany. Administrator może wnieść uzasadniony sprzeciw z przyczyn związanych z ochroną danych. Strony w dobrej wierze szukają rozwiązania, na przykład wyłączenia konkretnej integracji, zmiany regionu danych albo zakończenia korzystania z funkcji zależnej od danego subprocesora.

Aktualny eksport listy subprocesorów w formacie CSV jest dostępny dla klientów Enterprise na żądanie przez iodo@darhimlabs.pl. Publiczna wersja listy jest aktualizowana w tym dokumencie, a zmiany istotne są komunikowane także w panelu compliance lub changelogu.

8. Transfer danych poza EOG

DarhimLabs projektuje architekturę tak, aby podstawowe dane operacyjne klientów z EOG były przechowywane w regionie europejskim, w szczególności Frankfurt (EU). Niektóre usługi pomocnicze lub wywołania zewnętrznych modeli AI mogą jednak powodować transfer danych poza EOG, zwłaszcza do Stanów Zjednoczonych. Transfer odbywa się wyłącznie wtedy, gdy jest potrzebny do świadczenia usługi i objęty odpowiednimi zabezpieczeniami z rozdziału V RODO.

Podstawowym mechanizmem transferu są Standardowe Klauzule Umowne Komisji Europejskiej z 2021 r. (Decyzja 2021/914), w szczególności Module 2 Controller-to-Processor dla relacji Administrator — Procesor oraz odpowiednie moduły dla dalszych powierzeń. Dla dostawców certyfikowanych w EU-U.S. Data Privacy Framework DarhimLabs uwzględnia także certyfikację DPF jako dodatkową podstawę i środek oceny ryzyka.

Dla kluczowych transferów DarhimLabs prowadzi Transfer Impact Assessment. TIA ocenia rodzaj danych, charakter usługi, lokalizację, dostęp organów publicznych, dostępne środki prawne, szyfrowanie, pseudonimizację, retencję, zero data retention i możliwość ograniczenia payloadu. TIA jest dostępna dla klientów Enterprise pod NDA albo na uzasadnione żądanie Administratora.

• SCC Module 2 stanowi załącznik do DPA dla transferów Controller-to-Processor.
• TIA jest aktualizowana przy istotnej zmianie dostawcy, kraju, celu lub kategorii danych.
• Dane wrażliwe i szczególne kategorie danych wymagają dodatkowej oceny Administratora.
• W planach Enterprise można ograniczać dostawców i regiony przez data residency controls.

9. Audyty i certyfikacje

DarhimLabs udostępnia informacje niezbędne do wykazania zgodności z art. 28 RODO oraz umożliwia audyty w zakresie rozsądnie wymaganym przez Administratora. Standardowym sposobem realizacji prawa audytu jest przekazanie dokumentacji: DPA, TOM, listy subprocesorów, raportu SOC 2 Type II, executive summary testów penetracyjnych, opisu architektury, polityk retencji i informacji o incydentach dotyczących danych Klienta.

Administrator może przeprowadzić audyt bezpośredni nie częściej niż raz w roku, po 30-dniowym pisemnym wyprzedzeniu, w godzinach pracy DarhimLabs i w sposób niezakłócający bezpieczeństwa ani ciągłości usług. Koszty audytu ponosi Administrator, chyba że audyt jest wynikiem uzasadnionego podejrzenia istotnego naruszenia przez DarhimLabs. Zakres audytu musi być proporcjonalny, a audytor musi podlegać obowiązkowi poufności.

Raporty SOC 2 Type II i ISO 27001, jeśli są dostępne w danym roku audytowym, udostępniamy klientom Enterprise pod NDA. Executive summary testów penetracyjnych jest dostępne w podobnym trybie. Pełne raporty techniczne, zawierające szczegóły podatności i konfiguracji, udostępniamy wyłącznie w zakresie koniecznym i po dodatkowej ocenie bezpieczeństwa.

10. Środki techniczne i organizacyjne (Załącznik II)

DarhimLabs stosuje środki techniczne i organizacyjne zgodne z art. 32 RODO, dobierane do ryzyka, charakteru danych, zakresu przetwarzania i funkcji aktywowanych przez Administratora. Środki te są okresowo przeglądane, testowane i rozwijane. Poniższa lista stanowi Załącznik II do DPA i opisuje minimalny standard zabezpieczeń stosowany w Platformie.

Dane w tranzycie są chronione TLS 1.3, a dane w spoczynku szyfrowaniem dostawców infrastruktury oraz mechanizmami aplikacyjnymi dla szczególnie wrażliwych sekretów. Sekrety integracji, tokeny API i credentials są przechowywane w sposób ograniczający dostęp aplikacyjny i personelowy. Dostęp do systemów produkcyjnych wymaga MFA, jest objęty RBAC, przeglądami uprawnień i logami audytu.

Dane workspace’ów są izolowane przez kontrole aplikacyjne i Row-Level Security w PostgreSQL. Operacje zapisu generują audit log, a działania administracyjne są rejestrowane z metadanymi technicznymi. DarhimLabs prowadzi backupy, testy odtworzeniowe, monitorowanie dostępności, alerty bezpieczeństwa, procedury change management i proces bezpiecznego wdrażania zmian.

Administrator może włączyć dodatkowe środki, takie jak SSO/SAML, SCIM, wymuszenie MFA, ograniczenia IP, data residency controls, krótszą retencję, maskowanie PII, human approval dla akcji wysokiego ryzyka i eksport audit logów do SIEM. Dostępność poszczególnych środków może zależeć od planu.

11. Zwrot lub usunięcie danych po zakończeniu umowy

Po zakończeniu umowy Administrator może wybrać zwrot danych, usunięcie danych albo kombinację obu działań. Zwrot danych jest realizowany w formacie JSON, CSV lub przez API, zależnie od modułu i zakresu danych. Eksport może obejmować rozmowy, wiadomości, kontakty, leady, dokumenty, konfiguracje botów, logi audytu, webhooki, ustawienia integracji i metadane billingowe dostępne Administratorowi.

Usunięcie danych aktywnych następuje w terminie do 30 dni roboczych od potwierdzenia żądania, chyba że strony uzgodnią krótszy termin albo przepisy wymagają dalszej retencji. DarhimLabs może zachować dane w zakresie niezbędnym do fakturowania, podatków, bezpieczeństwa, logów audytowych, obrony roszczeń lub spełnienia obowiązków prawnych. Takie dane są objęte ograniczeniem celu i retencją prawną.

Backupy rotują zgodnie z harmonogramem retencji i nie są aktywnie używane po żądaniu usunięcia. Jeżeli backup zostanie odtworzony przed upływem retencji, DarhimLabs ponownie wykonuje procedurę usunięcia lub ograniczenia danych Administratora. Na żądanie Enterprise DarhimLabs może wystawić raport potwierdzający usunięcie danych, zawierający zakres, datę, systemy objęte operacją i wyjątki retencyjne.

• Eksport JSON/CSV jest dostępny przed usunięciem workspace’u.
• Delete confirmation report jest dostępny dla planów Enterprise na żądanie.
• Faktury i dane księgowe są przechowywane zgodnie z prawem przez wymagany okres.
• Audit log może być zachowany do 7 lat w celach SOC 2, ISO 27001 i roszczeń.

12. Postanowienia końcowe

W sprawach przetwarzania danych osobowych niniejsza DPA ma pierwszeństwo przed regulaminem, cennikiem, dokumentacją produktu i komunikacją marketingową. W zakresie nieuregulowanym DPA stosuje się umowę główną, Regulamin, Politykę prywatności oraz przepisy prawa właściwego. Jeżeli którekolwiek postanowienie DPA okaże się nieważne, pozostałe postanowienia pozostają w mocy, a strony zastąpią nieważne postanowienie skutecznym, możliwie najbliższym pierwotnemu celowi.

DPA wchodzi w życie z dniem akceptacji przez Administratora lub z dniem wskazanym w nagłówku dokumentu, w zależności od tego, co nastąpi później. Akceptacja może nastąpić elektronicznie: przez rejestrację konta, podpisanie zamówienia, kliknięcie akceptacji w panelu, podpis kwalifikowany, podpis elektroniczny lub wymianę dokumentów pomiędzy stronami. Cyfrowa kopia DPA jest traktowana jak skuteczny dokument umowny.

Prawem właściwym jest prawo polskie, a spory związane z DPA rozstrzygane są przez sąd właściwy dla siedziby DarhimLabs, chyba że bezwzględnie obowiązujące przepisy ochrony danych wskazują inaczej. Kontakt w sprawach DPA, subprocesorów, transferów i audytu: iodo@darhimlabs.pl.