Dane konkurenta w Twojej aplikacji — jak je oddzielić, żeby partner z branży zaufał?

Co partner naprawdę Ci powierza i kim wtedy jesteś w świetle prawa?

Partner, który wpuszcza dane do Twojej aplikacji, przestaje być zwykłym klientem. W rozumieniu RODO to on jest administratorem danych swoich klientów, a Ty podmiotem przetwarzającym, który działa na jego udokumentowane polecenie (art. 28 ust. 3 lit. a).

Powierza Ci trzy rzeczy naraz i tylko pierwsza jest oczywista: dane osobowe swoich klientów, swoje ceny i marże oraz swój kalendarz pracy. Dwie ostatnie nie są danymi osobowymi — i to właśnie przez nie konkurent zwleka z podpisem.

Jest jeszcze czwarta, o której mówi się rzadko: jego zegar. Art. 33 ust. 2 nakazuje podmiotowi przetwarzającemu zgłosić naruszenie administratorowi bez zbędnej zwłoki.

Administrator ma potem 72 godziny na zawiadomienie organu nadzorczego (art. 33 ust. 1). Twoja usterka uruchamia więc jego termin i jego rozmowę z urzędem.

Dlatego rozmowa o danych partnera nie jest rozmową o regulaminie, tylko o architekturze. Umowa powierzenia ma formę pisemną, w tym elektroniczną (art. 28 ust. 9), i wymienia, co robisz z danymi.

Zapisu nie da się jednak dotrzymać, jeśli aplikacja tego nie potrafi wykonać. Co musi się w takiej umowie znaleźć, rozstrzyga osobny tekst o tym, co zapisać w umowie z partnerem z branży.

Tutaj zostajemy przy tym, co musi umieć sama aplikacja — bo to ją partner sprawdzi, zanim przeczyta jakikolwiek dokument.

Siedem warstw oddzielenia danych — czego partner szuka w każdej?

Oddzielenie danych to nie jeden przełącznik, tylko siedem warstw — a partner może sprawdzić każdą z nich sam, z poziomu przeglądarki. Żadna nie wymaga od niego wiedzy technicznej ani dostępu do kodu.

Punkt wyjścia jest niewygodny. Dokumentacja PostgreSQL 18 mówi wprost: tabele domyślnie nie mają żadnych polityk, więc jeśli użytkownik ma uprawnienie do tabeli, wszystkie jej wiersze są dla niego jednakowo dostępne (odczyt 16 września 2026 r.).

Dokumentacja Supabase, dostawcy bazy, na której budujemy, dopowiada resztę. Tabela w schemacie wystawionym na zewnątrz bez włączonej ochrony wierszy jest do odczytu i zapisu dla każdej roli z nadanym uprawnieniem, a samo dodanie polityki tego uprawnienia nie cofa (odczyt 16 września 2026 r.).

Najważniejsze pytanie brzmi jednak inaczej: kto te polityki omija? Dokumentacja PostgreSQL 18 odpowiada, że superużytkownicy i role z atrybutem pomijania zawsze przechodzą obok ochrony wierszy, a właściciel tabeli robi to domyślnie, o ile jawnie nie każe stosować polityk także wobec siebie.

Dostawca bazy dokłada własny wariant: rola serwisowa ma pełny dostęp i omija polityki, więc jej klucz ma prawo istnieć wyłącznie po stronie serwera (odczyt 16 września 2026 r.). Partner, który zapyta o tę jedną rzecz, dowie się o Twojej aplikacji więcej niż z całej prezentacji.

Trzy lekcje z własnej praktyki, które kosztowały nas czas. Sam fakt zalogowania nie jest uprawnieniem administratora — rolę sprawdzamy po identyfikatorze użytkownika w osobnym miejscu. Identyfikator w adresie nie jest hasłem. Ograniczenie widocznych kolumn bez polityki na wiersze jest pozorne.

Czwarta lekcja jest najbardziej podstępna. Podmiana definicji widoku potrafi po cichu zgubić ustawienie, które każe widokowi działać z uprawnieniami pytającego. Po każdej zmianie widoku sprawdzamy więc, czy nie zaczął omijać polityk — z ekranu tego nie widać, widać dopiero w danych.

Test w pięć minut: co partner ma zrobić, zanim podpisze?

Sześć ruchów, w sumie około pięciu minut, bez programisty i bez dostępu do kodu. Partner wykonuje je na wersji pokazowej, zanim cokolwiek podpisze — i to samo powinieneś zrobić na własnej aplikacji, zanim go zaprosisz.

Ten test nie jest uprzejmością wobec partnera. Art. 32 ust. 1 lit. d wymaga regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych — a pięć minut raz na kwartał to najtańsza wersja tego obowiązku.

1. Dwa konta w dwóch firmach (90 sekund). Zakłada konto w firmie A, wpisuje klienta o wymyślonej nazwie, po czym szuka tej nazwy z konta firmy B — w wyszukiwarce, na listach i w raportach.
2. Podmiana identyfikatora w adresie (30 sekund). Otwiera dowolny swój rekord i zmienia w adresie jedną cyfrę. Cudzy rekord na ekranie kończy rozmowę; to zasada z tekstu o zasadach bezpieczeństwa od pierwszego dnia.
3. Konto pracownika i ekran z cenami (60 sekund). Zakłada w swojej firmie konto o najniższych uprawnieniach i próbuje wejść na widok marż, raportów i pełnej listy klientów.
4. Pytanie o dziennik (60 sekund). Pyta o dwie liczby: ile dni żyje zapis dostępu i czy da się pokazać wpis sprzed tygodnia. Odpowiedź „mamy logi” bez liczby dni nie jest odpowiedzią.
5. Eksport (30 sekund). Klika eksport swoich danych i otwiera plik w arkuszu. Sprawdza przy okazji, czy eksport obejmuje dane klientów, czy tylko ustawienia konta.
6. Najmniejsza kategoria benchmarku (30 sekund). Otwiera zestawienie branżowe i szuka kategorii, w której są dwie albo trzy firmy. Jeśli takie kategorie istnieją, benchmark ujawnia pojedyncze firmy.

Trzy odpowiedzi dyskwalifikują od razu: „filtrujemy to zapytaniem w aplikacji”, „dziennik mamy, ale nie da się go pokazać” oraz „eksport przygotujemy ręcznie, jak będzie trzeba”. Każda mówi to samo — ochrona siedzi w kodzie ekranu albo w dobrych chęciach.

Stąd próg, który przyjmujemy sami i który polecamy partnerom. Dziennik dostępu krótszy niż 30 dni jest bezużyteczny, bo art. 12 ust. 3 daje administratorowi miesiąc na odpowiedź na żądanie osoby, a skarga klienta partnera dotrze do Was po tygodniu albo dwóch.

Ten próg ma swoją cenę. W cenniku Supabase, dostawcy bazy, na której budujemy, retencja dzienników (API i baza) wynosi 1 dzień w planie darmowym, 7 dni w planie Pro, 28 dni w planie zespołowym i 90 dni w planie dla przedsiębiorstw (odczyt 16 września 2026 r.).

Zapis logowań ma własną skalę: 1 godzina w planie darmowym i 7 dni w planie Pro (odczyt 16 września 2026 r.). Rozszerzenie audytowe bazy pozwala zapisywać zdarzenia dla sesji, użytkownika, całej bazy albo wskazanego obiektu — ale zapisany dziennik i tak żyje tyle, ile pozwala plan.

Ile kosztuje miesięcznie utrzymanie aplikacji, z której korzysta pięćdziesiąt płacących firm, liczy tekst siostrzanego serwisu: rachunek utrzymania przy 50 klientach. Tutaj wystarczy jedna decyzja: plan dobierasz do długości dziennika, nie odwrotnie.

Konkurent jako partner: co zamienia obawę o dane w podpis?

Konkurent nie kupuje aplikacji dlatego, że jest ładna — kupuje wtedy, gdy zyskuje więcej, niż ryzykuje. Oddzielenie danych jest dokładnie tym miejscem, w którym ryzyko da się pokazać jako zamknięte.

W ponad 300 rozmowach o pomysłach na aplikację, które prowadziliśmy między czerwcem a wrześniem 2026 (ręczna klasyfikacja opisów pomysłu, stan 16.09.2026), 6 na 10 pomysłów to narzędzie dla firm z własnej branży, a 1 na 5 — platforma łącząca dwie strony branży.

W obu układach pierwszym użytkownikiem bywa ktoś, kto dziś walczy z Tobą o to samo zlecenie. Pięć rzeczy zamienia jego obawę w podpis i każda z nich jest zapisem, nie obietnicą.

• Cel przetwarzania na piśmie. Jego dane obsługujesz wyłącznie na jego udokumentowane polecenie (art. 28 ust. 3 lit. a). To zdanie wyklucza sięganie do jego bazy klientów na potrzeby własnej sprzedaży.
• Lista podwykonawców i uprzedzenie o zmianie. Art. 28 ust. 2 zabrania brać kolejnego podwykonawcy bez zgody administratora. Dostawca bazy publikuje taką listę — jej aktualizację odczytaliśmy z datą 1 czerwca 2026 r.
• Prawo do audytu. Art. 28 ust. 3 lit. h daje partnerowi prawo do audytów i inspekcji, także przez upoważnionego audytora. Test z tej strony jest jego pierwszą, darmową wersją.
• Wyjście z danymi. Po zakończeniu usług usuwasz albo zwracasz wszystkie dane i kasujesz kopie (art. 28 ust. 3 lit. g). Kopia dla partnera ma być w formacie do odczytu maszynowego (art. 20 ust. 1), a żądanie usunięcia od jego klienta wykonujesz bez zbędnej zwłoki (art. 17 ust. 1).
• Benchmark jako korzyść, nie jako ryzyko. Porównania do reszty branży konkurent nie kupi nigdzie indziej. Motyw 26 rozporządzenia stawia granicę: dane są anonimowe dopiero wtedy, gdy nie da się z nich wyodrębnić wpisów o jednej firmie.

Czego nie obiecywać: „nikt z nas nigdy nie zobaczy Twoich danych”. W aplikacji, która ma wsparcie i awarie, to nieprawda, a partner sprawdzi to pierwszego dnia po pierwszym zgłoszeniu.

Uczciwa wersja brzmi inaczej: wejście naszego zespołu jest imienne, odbywa się na Twoje zgłoszenie i zostawia wpis w dzienniku, który możesz obejrzeć. Obietnica, której da się dotrzymać, sprzedaje lepiej niż obietnica, która brzmi ładniej.

Czego konkretnie boi się konkurent i co pokazać mu na pierwszym spotkaniu, rozstrzyga osobny tekst: jak sprzedać oprogramowanie konkurentowi. Decyzję, czy pierwsza wersja ma od razu obsługiwać wiele firm, opisuje tekst o tym, czy budować najpierw dla siebie, czy od razu dla branży.

Co zostaje po Twojej stronie, a co robi zespół, który buduje

W tym temacie podział jest ostry. To, co jest chronione, definiuje praktyk — bo tylko on wie, która liczba w jego branży jest marżą, a która zwykłą stawką. To, jak jest chronione, wykonuje zespół techniczny.

Warstwy, na których to wszystko stoi — front, funkcje serwerowe, baza i usługi zewnętrzne — opisuje tekst o warstwach aplikacji dla firmy. Mechanizmy RODO w samym kodzie, w tym kaskadowe usuwanie, retencja i eksport, są w tekście o RODO wdrożonym w kodzie.

Minimalny zestaw obowiązków, od którego nie ucieknie nawet jednoosobowa firma, zebrał serwis siostrzany: minimalny zestaw obowiązków z RODO, DSA i AI Act. Ta strona nie zastępuje prawnika — ocena konkretnego przypadku należy do administratora danych.

Zostaje jedno zdanie do zapamiętania z całej tej roboty. Partner nie kupuje Twojego zapewnienia, że jego dane są oddzielone; kupuje możliwość sprawdzenia tego bez Ciebie, w pięć minut, kiedy tylko zechce.