Bezpieczeństwo danych w instalacjach interaktywnych: co sprawdzić przed startem

Wszystko zależy od tego, jakie informacje system zbiera, czy je zapisuje, czy pozwala powiązać je z konkretną osobą i co dzieje się z nimi po zakończeniu interakcji.

To rozróżnienie ma znaczenie zarówno artystyczne, jak i prawne. Prosty czujnik odległości może uruchamiać projekcję bez rejestrowania wizerunku. Podłoga reagująca na nacisk może działać bez wiedzy o tym, kto po niej chodzi. Z kolei kamera zapisująca obraz, mikrofon archiwizujący rozmowy albo algorytm porównujący twarz z zapisanym wzorcem wchodzą już w zupełnie inny obszar ryzyka.

RODO nie tworzy osobnej, pobłażliwej kategorii dla sztuki. Jeżeli w konkretnym scenariuszu instalacja przetwarza dane osobowe, organizator wystawy, właściciel systemu albo inny wskazany podmiot musi ustalić swoją rolę i spełnić odpowiednie obowiązki. Nie każda instalacja będzie jednak administratorem danych i nie każde użycie kamery oznacza przetwarzanie danych biometrycznych.

Do tego dochodzą regulacje dotyczące sztucznej inteligencji i cyberbezpieczeństwa. AI Act może mieć znaczenie, jeśli instalacja korzysta z systemu AI w określonym zastosowaniu, natomiast zakres NIS2 zależy przede wszystkim od rodzaju podmiotu, sektora i spełnienia konkretnych kryteriów. Sama obecność ekranu, kamery albo połączenia z systemem biletowym nie przesądza jeszcze o podleganiu tym przepisom.

Przed otwarciem wystawy warto więc przejść przez cały łańcuch: od sensora i kodu, przez sposób przechowywania danych, aż po dostęp serwisanta i demontaż urządzenia.

Privacy by Design jako fundament projektowania instalacji

Najczęstszy błąd polega na traktowaniu prywatności jako dodatku, który można dopisać po zakończeniu prac artystycznych. Wtedy architektura jest już ustalona, biblioteki wybrane, urządzenia kupione, a scenariusz interakcji zależy od danych, których nie da się łatwo usunąć bez przebudowy całego projektu.

Privacy by Design wymaga odwrotnej kolejności. Najpierw trzeba ustalić, jaka informacja jest rzeczywiście potrzebna do uzyskania efektu artystycznego, a dopiero potem dobrać urządzenie i oprogramowanie. Jeżeli instalacja ma reagować na obecność, identyfikacja osoby może być zbędna. Jeżeli ma zmieniać kolor w zależności od odległości widza od obiektu, sensor odległości może okazać się lepszym wyborem niż kamera.

Na etapie briefu warto odpowiedzieć na kilka pytań:

• Czy system musi rozpoznawać konkretną osobę, czy wystarczy wykrywanie obecności, ruchu, nacisku albo odległości?
• Czy dane muszą być zapisywane, czy można przetwarzać je wyłącznie w pamięci operacyjnej?
• Czy potrzebny jest obraz w pełnej rozdzielczości, czy wystarczy uproszczony sygnał wejściowy?
• Czy dźwięk ma być analizowany na żywo, czy instalacja naprawdę potrzebuje nagrania?
• Czy przetwarzanie może odbywać się lokalnie, bez wysyłania materiału do zewnętrznej usługi?
• Kto będzie miał dostęp do konfiguracji, logów i plików tymczasowych?
• Jak długo system będzie działał po zakończeniu wystawy i kto usunie dane?
• Co stanie się z urządzeniami po transporcie do kolejnej instytucji?

Minimalizacja danych nie oznacza automatycznie rezygnacji z ambicji artystycznych. Często prowadzi do ciekawszego projektu, bo zmusza zespół do precyzyjnego określenia, co właściwie ma być częścią interakcji. Jeśli wystarczy informacja, że w polu widzenia znajduje się obiekt o określonych parametrach, nie ma powodu, by przechowywać pełny obraz sceny.

Najbezpieczniejszy sensor to nie ten, który ma najwięcej funkcji, lecz ten, który dostarcza dokładnie taką informację, jakiej potrzebuje dzieło — i ani jednej więcej.

Wbudowanie zabezpieczeń na początku zwykle ogranicza późniejsze przeróbki, ale nie ma sensu przypisywać temu uniwersalnego mnożnika kosztów. Cena zmian zależy od architektury, skali projektu, użytych urządzeń, umowy z dostawcą i momentu, w którym wykryto problem. Pewne jest natomiast to, że decyzja o zapisywaniu obrazu lub dźwięku wpływa później na dokumentację, retencję, dostęp, obsługę incydentów i sposób informowania publiczności.

Warto także ustawić bezpieczne wartości domyślne. Instalacja nie powinna po ponownym uruchomieniu samoczynnie włączać nagrywania, otwierać panelu serwisowego ani przywracać konta z szerokimi uprawnieniami. Domyślny tryb powinien ograniczać zakres zbieranych danych, a funkcje diagnostyczne powinny wymagać świadomego włączenia i mieć określony czas działania.

RODO, dane biometryczne i ocena skutków DPIA

RODO obejmuje dane osobowe, czyli informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby. W instalacji może to być nie tylko imię i nazwisko. W zależności od konfiguracji znaczenie mogą mieć wizerunek, nagranie głosu, identyfikator urządzenia, nagranie z kasy biletowej, konto użytkownika albo zestaw informacji pozwalający połączyć zachowanie zwiedzającego z konkretną osobą.

Nie każdy obraz z kamery jest jednak automatycznie danymi biometrycznymi. Sam fakt zarejestrowania twarzy nie oznacza jeszcze, że zastosowano biometryczne przetwarzanie w rozumieniu RODO. Znaczenie ma to, czy obraz poddano specjalistycznemu przetwarzaniu technicznemu w celu jednoznacznej identyfikacji osoby albo uwierzytelnienia jej tożsamości. Podobnie analiza postawy czy ruchu może być zwykłym wykrywaniem gestu, ale może też stać się elementem profilu pozwalającego rozpoznać konkretną osobę.

Przed uruchomieniem trzeba więc opisać rzeczywisty przepływ danych, a nie tylko nazwać urządzenie. Kamera może:

1. przesyłać obraz bezpośrednio do aplikacji i natychmiast odrzucać klatki;

2. wyliczać lokalnie uproszczone parametry ruchu bez zapisywania obrazu;

3. zapisywać materiał na dysku urządzenia;

4. wysyłać obraz do zewnętrznego dostawcy;

5. porównywać cechy twarzy lub głosu z wcześniej przygotowanym wzorcem.

Każdy z tych wariantów rodzi inne pytania. W pierwszym przypadku kluczowe będzie sprawdzenie, czy dane rzeczywiście nie trafiają do logów ani pamięci podręcznej. W czwartym trzeba dodatkowo przeanalizować umowę, lokalizację przetwarzania, role stron i zasady usuwania materiału. W piątym dochodzą wymogi związane z identyfikacją biometryczną oraz podwyższonym ryzykiem dla praw i wolności osób.

Kiedy potrzebna jest DPIA

Ocena skutków dla ochrony danych, czyli DPIA, nie jest uniwersalnym załącznikiem do każdej instalacji wyposażonej w kamerę. Jest narzędziem do oceny operacji, które ze względu na charakter, zakres, kontekst lub cele mogą powodować wysokie ryzyko dla osób. Obowiązek trzeba ustalić na podstawie konkretnego scenariusza, a nie samej nazwy technologii.

DPIA może być szczególnie istotna przy systematycznym monitorowaniu przestrzeni dostępnej publicznie na dużą skalę, przy przetwarzaniu szczególnych kategorii danych oraz przy rozwiązaniach wykorzystujących identyfikację biometryczną lub profilowanie. Jeżeli analiza wykaże wysokie ryzyko, którego nie da się odpowiednio ograniczyć, mogą pojawić się dalsze obowiązki konsultacyjne.

Sformułowanie „brak identyfikacji” nie wystarcza, by nazwać dane anonimowymi. Anonimizacja oznacza taki sposób przekształcenia informacji, po którym nie można rozsądnie zidentyfikować osoby, także przy wykorzystaniu innych dostępnych danych. Samo usunięcie twarzy z obrazu może nie wystarczyć, jeśli pozostają charakterystyczny głos, identyfikator sesji, czas wejścia i inne elementy pozwalające połączyć zapis z konkretnym zwiedzającym.

Jeśli instalacja działa bez zapisu i nie pozwala na identyfikację, może nie przetwarzać danych osobowych albo przetwarzać je w bardzo ograniczonym zakresie. Trzeba to jednak potwierdzić testem konfiguracji. Warto sprawdzić między innymi pamięć podręczną, pliki tymczasowe, logi aplikacji, kopie zapasowe i dane telemetryczne wysyłane przez gotowe biblioteki.

DPIA nie powinna być dokumentem napisanym raz i odłożonym do archiwum. Aktualizacji może wymagać zmiana modelu, dostawcy chmurowego, celu instalacji, miejsca ekspozycji, sposobu rejestrowania obrazu albo czasu przechowywania. Inne ryzyko występuje w małej galerii, a inne w instalacji prezentowanej codziennie w ruchliwej przestrzeni publicznej.

Techniczne zabezpieczenia: od szyfrowania po tryb kiosk

Gdy zakres danych jest już opisany, można dobrać środki techniczne. Artykuł 32 RODO nie narzuca jednej listy urządzeń ani algorytmów, lecz wymaga zastosowania środków adekwatnych do ryzyka. W praktyce oznacza to połączenie ochrony transmisji, kontroli dostępu, bezpiecznej konfiguracji, kopii zapasowych, monitorowania i procedur reagowania.

Szyfrowanie i dostęp

Dane przesyłane między komponentami powinny być chronione przed przechwyceniem i modyfikacją. Dotyczy to zarówno komunikacji z serwerem lokalnym, jak i połączeń z usługami zewnętrznymi. Należy sprawdzić certyfikaty, sposób uwierzytelniania urządzeń i to, czy aplikacja nie korzysta z niezaszyfrowanych kanałów pomocniczych, na przykład do przesyłania logów.

Szyfrowanie nośnika ma znaczenie wtedy, gdy urządzenie można wynieść z galerii albo wyjąć z niego dysk. Nie zastępuje ono kontroli dostępu do działającej aplikacji. Osoba, która ma dostęp do odblokowanego systemu i uprawnień administratora, może bowiem odczytać dane niezależnie od tego, jak dobrze zabezpieczony jest nośnik w stanie wyłączenia.

Konta serwisowe powinny być imienne, a ich uprawnienia ograniczone do potrzebnej funkcji. Wspólne hasło zapisane w dokumentacji technicznej utrudnia ustalenie, kto zmienił konfigurację i kiedy. Klucze API nie powinny znajdować się w publicznym repozytorium, w pliku dostępnym z poziomu aplikacji ani w materiałach przekazywanych bez kontroli kolejnemu wykonawcy.

Tryb kiosk i urządzenia dostępne dla publiczności

Tryb kiosk ogranicza urządzenie do jednej aplikacji lub określonego zestawu funkcji. Jest szczególnie ważny przy tabletach, ekranach dotykowych i komputerach ustawionych w zasięgu zwiedzających. Samo uruchomienie aplikacji na pełnym ekranie nie jest jeszcze zabezpieczeniem: użytkownik może nadal otworzyć menu systemowe, przełączyć aplikację, podłączyć pamięć USB albo wejść do ustawień.

Konfiguracja powinna obejmować co najmniej:

• wyłączenie niepotrzebnych portów i interfejsów;
• blokadę instalowania oprogramowania przez konto publiczne;
• ograniczenie dostępu do ustawień systemowych;
• wyłączenie automatycznego logowania do konta administracyjnego;
• kontrolę urządzeń USB i nośników wymiennych;
• osobny tryb serwisowy, dostępny tylko dla uprawnionych osób;
• automatyczny powrót do bezpiecznego stanu po restarcie.

Jeżeli instalacja przetwarza obraz lub dźwięk, trzeba sprawdzić, czy aplikacja albo system operacyjny nie tworzy kopii tymczasowych. „Przetwarzanie na żywo” opisuje sposób działania, a nie gwarantuje anonimizacji. Anonimizacja wymaga zaprojektowania procesu, określenia, jakie cechy są usuwane lub przekształcane, oraz zweryfikowania, czy z pozostałych danych nie da się odtworzyć tożsamości.

Najprostszą ochroną bywa rezygnacja z przechowywania surowych danych. Jeśli instalacja potrzebuje tylko informacji o kierunku ruchu, można zapisywać zdarzenie sterujące, a nie nagranie. Jeśli algorytm wymaga tymczasowego obrazu, trzeba określić, kiedy dokładnie jest on usuwany i czy nie zostaje w pamięci podręcznej, logach lub kopii zapasowej.

Segmentacja sieci

Instalacja nie powinna znajdować się w tej samej sieci co komputery administracji, system kasowy i urządzenia używane przez personel. Najczęściej oznacza to osobną podsieć, ograniczenie ruchu między komponentami oraz reguły zapory dopuszczające tylko wymagane połączenia.

Segmentacja nie jest magiczną tarczą. Jeżeli hasło administratora jest wspólne dla wielu urządzeń, aktualizacje nie są instalowane, a panel serwisowy jest wystawiony bez ochrony, osobna podsieć tylko ogranicza część skutków incydentu. Nadal trzeba kontrolować połączenia wychodzące, usuwać nieużywane usługi i sprawdzać, czy urządzenie nie komunikuje się z nieznanymi serwerami.

AI Act i NIS2 w kontekście sztuki cyfrowej

Sztuczna inteligencja: kto za co odpowiada

Korzystanie z gotowego modelu albo komercyjnego interfejsu AI nie oznacza automatycznie, że organizator wystawy musi dokumentować sposób wytrenowania modelu. Obowiązki zależą od roli podmiotu w łańcuchu dostaw, rodzaju systemu i jego zastosowania. Inne zadania może mieć dostawca systemu, inne podmiot wdrażający go w swojej działalności, a jeszcze inne dystrybutor lub integrator.

Przy planowaniu instalacji trzeba ustalić:

• czy dane narzędzie rzeczywiście jest systemem AI w rozumieniu AI Act;
• do czego jest używane w konkretnej instalacji;
• czy system został zaklasyfikowany do określonej kategorii ryzyka;
• czy zastosowanie nie wchodzi w obszar praktyk zakazanych;
• jakie informacje, instrukcje i ograniczenia przekazuje dostawca;
• kto odpowiada za konfigurację, nadzór człowieka i obsługę błędów.

To, że algorytm działa lokalnie, nie przesądza o braku obowiązków. Tak samo użycie zewnętrznego API nie przenosi automatycznie całej odpowiedzialności na instytucję kultury. Potrzebna jest analiza konkretnego modelu i konkretnego zastosowania. Jeśli instalacja wykorzystuje system do rozpoznawania emocji, identyfikacji osób, kategoryzowania publiczności albo podejmowania decyzji wywołujących skutki wobec ludzi, ryzyko prawne i organizacyjne będzie inne niż przy prostym sterowaniu światłem na podstawie wykrytego ruchu.

Dokumentacja po stronie użytkownika powinna koncentrować się na tym, co instytucja faktycznie robi: celu użycia, źródle danych wejściowych, konfiguracji, nadzorze, ograniczeniach i procedurze reagowania na błędne działanie. Nie ma podstaw, by przypisywać jej automatycznie obowiązek odtworzenia całego procesu trenowania komercyjnego modelu, jeśli nie jest jego dostawcą ani twórcą.

NIS2 nie obejmuje każdej instytucji kultury

NIS2 dotyczy określonych podmiotów działających w sektorach uznanych za istotne lub ważne oraz spełniających warunki wskazane w przepisach krajowych i unijnych. To, czy muzeum, galeria lub organizator festiwalu znajdzie się w zakresie regulacji, zależy od jego statusu, sektora, wielkości, rodzaju świadczonych usług i ewentualnych szczególnych podstaw objęcia przepisami.

Integracja instalacji z systemem biletowym, kontrolą dostępu albo siecią administracyjną sama w sobie nie nadaje instytucji statusu podmiotu objętego NIS2. Może jednak zwiększać znaczenie instalacji dla bezpieczeństwa organizacji i sprawiać, że trzeba potraktować ją jako element większego środowiska informatycznego.

W praktyce przed wdrożeniem warto ustalić:

1. Czy właściciel instalacji należy do sektora i kategorii podmiotów objętych NIS2?

2. Czy system jest częścią usług, procesów lub infrastruktury, które instytucja musi chronić w ramach własnych obowiązków?

3. Czy dostawca technologii ma umowne obowiązki dotyczące incydentów, aktualizacji, podatności i dostępu serwisowego?

4. Czy istnieje procedura odłączenia instalacji od sieci bez utraty danych potrzebnych do wyjaśnienia incydentu?

5. Kto podejmuje decyzję o zgłoszeniu naruszenia i kto kontaktuje się z dostawcą?

Nawet jeśli NIS2 formalnie nie ma zastosowania, dobre praktyki z obszaru zarządzania incydentami, kontroli dostawców i aktualizacji oprogramowania nadal są użyteczne. Bezpieczeństwo instalacji nie powinno zależeć od tego, czy jej właściciel mieści się dokładnie po właściwej stronie definicji prawnej.

Pułapki fizyczne i sieciowe: dlaczego tryb offline nie oznacza bezpieczeństwa

Odłączenie instalacji od internetu zmniejsza część ryzyk, ale nie usuwa problemu. System offline nadal może przetwarzać dane lokalnie, zapisywać je na dysku, udostępniać port serwisowy albo zostać zainfekowany podczas aktualizacji.

Pierwsza grupa zagrożeń jest fizyczna. Urządzenie wystawione w galerii znajduje się w zasięgu publiczności. Porty USB, przyciski resetowania, przewody sieciowe, gniazda HDMI i obudowa z łatwo dostępnym dyskiem tworzą powierzchnię ataku. Nie każdy zwiedzający będzie próbował ingerować w instalację, ale projekt nie powinien zakładać, że nikt tego nie zrobi.

Dostęp serwisowy warto umieścić za zamykanym panelem, a nieużywane porty wyłączyć w konfiguracji i, jeśli to możliwe, zabezpieczyć fizycznie. Obudowa powinna utrudniać wyjęcie nośnika bez pozostawienia śladu, a przewody nie powinny być prowadzone tak, by można je było łatwo przepiąć do innego urządzenia.

Druga grupa to łańcuch dostaw. Instalacja korzysta zwykle z bibliotek, sterowników, systemu operacyjnego, modeli AI i narzędzi do komunikacji z urządzeniami. Każdy element może mieć własny cykl aktualizacji i własne podatności. Nie chodzi o to, by unikać całego oprogramowania open source, lecz by wiedzieć, jakie komponenty są używane i skąd pochodzą.

Przed przekazaniem projektu do eksploatacji warto przygotować listę zależności oraz procedurę ich aktualizacji. Należy pobierać pakiety z zaufanych źródeł, ograniczać uprawnienia aplikacji i nie pozostawiać kont debugowania aktywnych po zakończeniu prac. Aktualizacja powinna być testowana w środowisku, które pozwala odtworzyć instalację, a nie wykonywana bezpośrednio na jedynym działającym egzemplarzu tuż przed otwarciem wystawy.

Trzecia grupa to błędy organizacyjne:

• hasło administratora zapisane na obudowie urządzenia;
• jeden wspólny klucz API używany przez wszystkich wykonawców;
• brak informacji o tym, kto może wejść do trybu serwisowego;
• plik konfiguracyjny zawierający dane dostępowe;
• brak rejestru zmian i aktualizacji;
• pozostawione logi zawierające obraz, dźwięk lub identyfikatory sesji;
• brak procedury na wypadek zagubienia urządzenia podczas transportu.

Tryb kiosk, szyfrowanie i segmentacja sieci tworzą podstawę, ale nie zastępują opieki nad instalacją. Bez aktualizacji, kontroli dostępu i zabezpieczenia fizycznego każda z tych warstw pozostaje niepełna.

Szczególnej uwagi wymaga transport. Instalacja opuszczająca galerię może trafić do firmy przewozowej, magazynu, kolejnej instytucji albo pracowni zewnętrznego wykonawcy. Przed przekazaniem trzeba ustalić, czy na urządzeniu pozostają dane, klucze, tokeny, kopie zapasowe i konta serwisowe. Jeżeli nie są potrzebne, powinny zostać usunięte. Jeżeli muszą pozostać, należy zabezpieczyć je zgodnie z rolą nowego użytkownika i udokumentować przekazanie.

Od briefu do demontażu

Bezpieczeństwo najlepiej prowadzić przez cały cykl życia projektu, a nie tylko w dniu odbioru technicznego. Praktyczny porządek prac może wyglądać następująco:

1. Brief i koncepcja — opisać interakcję bez nazw urządzeń i sprawdzić, jaka informacja jest naprawdę potrzebna. Jeśli wystarczy obecność albo odległość, nie projektować od razu systemu identyfikującego osoby.

2. Prototyp — zmapować przepływ danych: sensor, aplikacja, pamięć, sieć, usługa zewnętrzna, logi i kopie zapasowe. Na tym etapie łatwiej wykryć, że biblioteka zapisuje więcej, niż zakładano.

3. Ocena ryzyka — ustalić, czy instalacja przetwarza dane osobowe, czy potrzebna jest DPIA, jaka jest podstawa prawna i kto pełni rolę administratora lub podmiotu przetwarzającego.

4. Wdrożenie — skonfigurować szyfrowanie, konta, tryb kiosk, segmentację sieci, reguły zapory, retencję i usuwanie danych przed pierwszym publicznym uruchomieniem.

5. Odbiór — przeprowadzić testy nie tylko efektu artystycznego, ale też restartu, utraty sieci, próby wejścia do ustawień, podłączenia nośnika, awarii zasilania i odtworzenia systemu.

6. Eksploatacja — prowadzić rejestr aktualizacji, zmian konfiguracji, incydentów i dostępu serwisowego. Wyznaczyć osobę, która wie, jak odłączyć instalację i gdzie szukać informacji potrzebnych do analizy problemu.

7. Transport i demontaż — usunąć zbędne dane, zresetować konta, unieważnić klucze dostępu, zabezpieczyć nośniki i przekazać dokumentację następnej instytucji.

Nie każda instalacja wymaga takiego samego poziomu formalizacji. Mały obiekt reagujący na nacisk bez zapisu danych nie potrzebuje tej samej dokumentacji co system zapisujący obraz i wysyłający go do chmury. Zakres pracy powinien odpowiadać ryzyku, ale uproszczenie nie może polegać na przyjęciu, że cała technologia jest poza prawem tylko dlatego, że znajduje się w galerii.

Najważniejsza decyzja często zapada jeszcze przed wyborem kamery. Trzeba ustalić, czy identyfikacja osoby jest częścią dzieła, czy jedynie wygodnym skrótem technicznym. W wielu przypadkach można osiągnąć podobny efekt za pomocą danych mniej wrażliwych: nacisku, odległości, kierunku ruchu, natężenia światła, obecności obiektu albo anonimowego sygnału z kontrolera.

Instalacja interaktywna nie jest z definicji systemem przetwarzającym dane osobowe. Może działać całkowicie bez identyfikowania ludzi, a nawet bez rejestrowania informacji, które pozwalają ich rozpoznać. Jeżeli jednak pojawia się obraz, głos, identyfikator, zapis zachowania lub integracja z kontem zwiedzającego, trzeba przeanalizować konkretny przepływ danych, a nie zasłaniać się artystycznym charakterem projektu.

RODO, AI Act i NIS2 nie tworzą jednego uniwersalnego formularza dla sztuki cyfrowej. Każdy z tych aktów uruchamia inne pytania: o dane osobowe, rolę w łańcuchu dostaw AI, zastosowanie systemu, status instytucji, cyberbezpieczeństwo i odpowiedzialność za incydent. Dobrze zaprojektowana instalacja nie odpowiada na nie deklaracją, lecz architekturą: zbiera mniej, przechowuje krócej, ogranicza dostęp i pozwala sprawdzić, co wydarzyło się z danymi.

Bezpieczeństwo nie jest przeciwieństwem interaktywności. Jest warunkiem, by kontakt człowieka z technologią nie kończył się przejęciem urządzenia, niekontrolowanym nagraniem albo problemem, którego zespół artystyczny nie przewidział. Najlepsze zabezpieczenia pozostają niewidoczne dla publiczności. Dla twórców powinny być widoczne od pierwszego szkicu.