Bezpieczeństwo i zgodność
Jak system jest zbudowany, co przechowujemy, a czego nie, i który mechanizm odpowiada któremu wymogowi.
Ścieżka żądania
Sejf mapowań
Podmiana jest odwracalna, więc sejf mapowań to najbardziej wrażliwy element systemu. Dlatego:
- działa wewnątrz Waszej infrastruktury i nie ma ścieżki wyjścia na zewnątrz;
- klucze pochodzą z Waszego HSM albo KMS — nie generujemy ich i nie przechowujemy;
- mapowania są szyfrowane i wiązane z sesją, a nie trzymane bezterminowo;
- dostęp do sejfu jest rozdzielony od dostępu administracyjnego;
- każde odczytanie mapowania jest zdarzeniem w rejestrze.
Retencja
| Element | Domyślnie | Uwagi |
|---|---|---|
| Metadane żądania | Przechowywane | Użytkownik, czas, dostawca, klasy danych, decyzja |
| Treść promptu | Nieprzechowywana | Do włączenia dla wybranych zespołów |
| Wykryte wartości | Wyłącznie w sejfie | Powiązane z sesją, usuwane po skonfigurowanym okresie |
| Odpowiedź modelu | Nieprzechowywana | Przechodzi przez system, nie zostaje w nim |
| Rejestr zdarzeń | Przechowywany | Eksport do Waszego SIEM na bieżąco |
Model zagrożeń
Adresuje
- wysłanie danych osobowych lub objętych tajemnicą bankową do zewnętrznego modelu;
- brak widoczności i dowodu, jakie dane opuszczały organizację;
- korzystanie z dostawców spoza zatwierdzonej listy;
- ryzyko koncentracji na jednym dostawcy ICT w rozumieniu DORA.
Nie adresuje
- świadomej eksfiltracji przez osobę z dostępem do danych źródłowych — to zadanie dla DLP i kontroli dostępu;
- jakości i prawdziwości odpowiedzi modelu;
- danych wyniesionych zdjęciem ekranu na telefonie prywatnym.
Pseudonimizacja, nie anonimizacja
Skoro mapowanie jest odwracalne, mamy do czynienia z pseudonimizacją w rozumieniu art. 4 pkt 5 RODO — dane pseudonimizowane pozostają danymi osobowymi. Zmienia się natomiast to, co realnie wychodzi: zbiór, którego bez sejfu nie da się przypisać osobie. Pseudonimizacja jest przy tym wskazana wprost w art. 32 ust. 1 lit. a RODO.
Mapowanie na wymogi
Zestawienie robocze do rozmowy z Waszym zespołem compliance — nie opinia prawna i nie deklaracja zgodności.
| Wymóg | Czego dotyczy | Mechanizm w Bramkarzu |
|---|---|---|
| RODO art. 32 | Bezpieczeństwo przetwarzania, pseudonimizacja | Podmiana wartości przed opuszczeniem organizacji, szyfrowanie sejfu, rozdzielenie ról |
| RODO art. 28 | Powierzenie przetwarzania | Lista dozwolonych dostawców — tylko ci, z którymi macie umowę |
| RODO rozdz. V | Transfer do państw trzecich | Wartości identyfikujące nie opuszczają EOG; routing wg klasy danych |
| Prawo bankowe art. 104 | Tajemnica bankowa | Tokenizacja albo zatrzymanie zależnie od polityki, z rejestrem decyzji |
| DORA | Ryzyko dostawców ICT, plan wyjścia, rejestr umów | Jedna warstwa nad wieloma dostawcami, eksport konfiguracji i rejestru |
| Rekomendacja D (KNF) | Zarządzanie przepływem informacji | Kontrolowany kanał zamiast niewidocznego, rejestr, rozdzielenie obowiązków |
| NIS2 / ustawa o KSC | Zarządzanie ryzykiem i incydentami | Zdarzenia w Waszym SIEM, alerty o próbach naruszenia polityki |
| AI Act | Przejrzystość korzystania z AI | Widoczność, kto i do czego używa modeli |
AI Act — aktualne terminy
Harmonogram zmienił się po wejściu w życie omnibusa cyfrowego (27 lipca 2026), a w obiegu wciąż są nieaktualne daty:
- obowiązki przejrzystości z art. 50 — bez zmian, od 2 sierpnia 2026;
- systemy wysokiego ryzyka z załącznika III — 2 grudnia 2027;
- systemy wysokiego ryzyka wbudowane w produkty — 2 sierpnia 2028.
Bramkarz nie jest systemem wysokiego ryzyka — jest środkiem bezpieczeństwa. Przesunięcie terminu nie przesuwa obowiązków z RODO i DORA, które obowiązują już teraz.
Kontakt
Pytania o architekturę albo konkretny wymóg nadzorczy — odpowiadamy na piśmie.