Co zapisują logi systemów AI i jak uzgodnić je z radą zakładową

Dlaczego o współdecydowaniu rozstrzygają logi

Rada zakładowa ma tu głos ze względu na to, co system potrafi zapisać, a nie na to, co zamierzasz z tymi danymi zrobić. § 87 ust. 1 pkt 6 BetrVG daje jej prawo współdecydowania przy „Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen”, czyli przy wprowadzaniu i stosowaniu urządzeń technicznych przeznaczonych do nadzorowania zachowania lub wydajności pracowników. Federalny Sąd Pracy (BAG) rozumie słowo „przeznaczone” szeroko. W postanowieniu z 8 marca 2022 r. w sprawie Microsoft Office 365 (1 ABR 20/21) uznał, że wystarczy, by urządzenie obiektywnie nadawało się do zbierania i zapisywania informacji o zachowaniu lub wydajności pracowników, a subiektywny zamiar pracodawcy nie ma znaczenia. Log bramy z identyfikatorem użytkownika i znacznikiem czasu dokładnie pasuje do tego opisu.

Często przywoływane orzeczenie w sprawie ChatGPT wskazuje ten sam kierunek, jeśli przeczytasz stan faktyczny. Sąd pracy w Hamburgu (postanowienie z 16 stycznia 2024 r., 24 BVGa 1/24) oddalił wnioski rady, bo pracownicy korzystali z ChatGPT w przeglądarce, na własnych prywatnych kontach, a pracodawca nie dostawał od dostawców żadnych danych. Tak streszcza sprawę kancelaria Gleiss Lutz, która jednocześnie przestrzega przed uogólnianiem tego rozstrzygnięcia i zauważa, że prawo współdecydowania może powstać, gdy pracodawca używa własnych systemów AI albo ma dostęp do zbieranych przez nie danych. Firmowa platforma AI to właśnie taki przypadek: pracodawca obsługuje bramę i trzyma logi.

Rozmowę kształtują jeszcze dwie reguły. Jeśli strony się nie porozumieją, zgodnie z § 87 ust. 2 BetrVG rozstrzyga komisja rozjemcza (Einigungsstelle). A według § 80 ust. 3 BetrVG skorzystanie z eksperta uważa się za niezbędne, gdy rada musi ocenić wprowadzenie lub stosowanie sztucznej inteligencji, więc spodziewaj się pytań technicznych od kogoś, kto czyta pliki konfiguracyjne. Tu zajmujemy się stroną techniczną. To, czy i jak współdecydowanie działa w twojej firmie, ustal z prawnikiem od prawa pracy. Nic tutaj nie jest poradą prawną.

Co zapisują asystent, brama i agenci kodujący

Każda warstwa zapisuje coś innego, a najpełniejszy obraz ma zwykle brama, bo przechodzi przez nią każde zapytanie. Tabela zbiera to, co według dokumentacji producentów potrafi zapisać każdy komponent, stan na 7 listopada 2026. Sprawdź własne wersje i ustawienia, bo wartości domyślne i nazwy pól zmieniają się między wydaniami.

Telemetria w Claude Code pozostaje wyłączona, dopóki ktoś nie ustawi CLAUDE_CODE_ENABLE_TELEMETRY, a administratorzy mogą włączyć ją wszystkim przez plik managed settings. Jej włączenie to więc decyzja, o której rada powinna wiedzieć z wyprzedzeniem. Nie powinien jej podejmować na własną rękę jeden programista.

Które pola technicznie umożliwiają monitorowanie

Monitorowanie staje się możliwe, gdy pole identyfikujące osobę jest zapisane obok pola opisującego, co ta osoba zrobiła. Nazwa modelu, liczba tokenów czy opóźnienie same w sobie nic nie mówią o pracowniku. Połączone z identyfikatorem użytkownika i znacznikiem czasu stają się zapisem czasu i intensywności pracy. Przejrzyj schemat logów właśnie pod kątem tego połączenia:

• Identyfikatory: ID użytkownika, adres e-mail, UUID konta, klucz API wydany jednej osobie, adres IP
• Czas: znaczniki czasu zapytań, początek i koniec sesji, aktywny czas, które razem pokazują, kiedy ktoś pracował
• Ilość i koszt na osobę, które zachęcają do porównywania współpracowników
• Wskaźniki wyników, takie jak zmienione linie, commity i pull requesty, które czyta się jak dane o wydajności
• Treść: prompty, odpowiedzi i argumenty narzędzi, które pokazują, nad czym i jak ktoś pracował

Jest też drugi powód, by trzymać te pola osobno. Wytyczne Komisji Europejskiej dotyczące zastosowań wysokiego ryzyka w zatrudnieniu zaliczają systemy AI, które oceniają wydajność i zachowanie pracowników i na tej podstawie przydzielają zadania, do punktu 4 lit. b załącznika III do AI Act. Sam log użycia takim systemem nie jest, ale potok danych, który na jego podstawie układa ranking osób i zasila decyzje kadrowe, zmierza w tę stronę. Naszym zdaniem najprostszą ochroną jest w ogóle nie budować widoku na poziomie pojedynczej osoby.

Jak skonfigurować logi, żeby porozumienia dało się dotrzymać

Porozumienie zakładowe jest warte tyle, ile konfiguracja, która za nim stoi, więc każdą obietnicę zapisz jako ustawienie, które ktoś może sprawdzić. Kroki opierają się na LiteLLM i Claude Code, bo ich dokumentacja nazywa odpowiednie ustawienia. Inne bramy i agenci mogą mieć podobne opcje pod innymi nazwami, więc sprawdź je, zanim cokolwiek obiecasz.

1. 1

   Wydawaj klucze na zespół, gdzie pozwala na to przypadek użycia

   W LiteLLM klucz konta serwisowego wymaga identyfikatora zespołu i zawsze ma pusty identyfikator użytkownika, a budżety i limity zapytań działają na poziomie zespołu. Dział finansów widzi koszt na zespół bez osobistego identyfikatora w logu. Sprawdź, czy twój interfejs czatu i tak nie przesyła z każdym zapytaniem osobistego identyfikatora, bo brama zapisuje też pole użytkownika końcowego. Jeśli jakiś przypadek użycia wymaga przypisania do osoby, wpisz go do porozumienia razem z celem.

2. 2

   Domyślnie trzymaj prompty i odpowiedzi poza logami

   Gdy store_prompts_in_spend_logs jest wyłączone, LiteLLM trzyma w spend logs metadane, takie jak tokeny, koszt i model, a nie treść wiadomości, a turn_off_message_logging sprawia, że wiadomości i odpowiedzi nie trafiają do callbacków logowania, choć koszty są nadal liczone. Wartości ustawione w panelu administracyjnym nadpisują plik konfiguracyjny, więc ogranicz, kto może je zmieniać. W Claude Code zostaw OTEL_LOG_USER_PROMPTS i OTEL_LOG_TOOL_DETAILS przy domyślnym wyłączeniu.

3. 3

   Usuwaj lub zastępuj identyfikatory przed zapisem

   Claude Code dołącza adres e-mail użytkownika zawsze, gdy jest dostępny, więc usuń go lub zastąp w OpenTelemetry Collector, zanim dane trafią do magazynu. Procesor attributes w Collectorze potrafi usunąć atrybut albo zahashować go algorytmem SHA-256. Dla nowych wdrożeń projekt wskazuje teraz procesor transform. Zwykły hash adresu e-mail to w najlepszym razie pseudonim, bo każdy, kto ma listę pracowników, może zahashować wszystkie adresy i je dopasować. Jeśli w udokumentowanych przypadkach musisz przywrócić tożsamość, trzymaj mapowanie w osobnym magazynie, którym zarządza inna rola.

4. 4

   Ustaw retencję także w systemie

   maximum_spend_logs_retention_period w LiteLLM automatycznie usuwa spend logs po określonym czasie, na przykład 30d. Ustaw tu okres z porozumienia zakładowego i dopilnuj, żeby ten sam okres obejmował eksporty, backend obserwowalności i kopie zapasowe.

5. 5

   Rozdziel role dostępu i raportuj tylko zbiorczo

   Inżynierowie platformy widzą logi techniczne potrzebne do utrzymania, dział finansów widzi koszt na zespół, a przełożeni nie widzą żadnych danych o pojedynczych osobach. Raporty wychodzą na zespół i miesiąc, z minimalną wielkością grupy zapisaną w porozumieniu, żeby dwuosobowego zespołu nie dało się odczytać jako dwóch konkretnych ludzi. W Copilocie ogranicz, kto ma uprawnienie do przeglądania metryk użycia, bo te raporty pokazują dane poszczególnych użytkowników.

6. 6

   Udokumentuj wyjątki, zwłaszcza dochodzenia bezpieczeństwa

   Będą sytuacje, w których dane o konkretnej osobie są potrzebne, na przykład wyciek klucza albo podejrzenie, że przez asystenta wypływają dane. Zapisz, kto może wnioskować o przywrócenie tożsamości lub czasowe przechwytywanie treści, kto to zatwierdza, jak informuje się radę, jak długo to trwa i kiedy zebrane dane są usuwane. Wyjątek z procedurą łatwiej uzgodnić niż mglistą obietnicę, że nikt nigdy nie zajrzy.

Co dokładają inspektor ochrony danych i AI Act

Dla inspektora ochrony danych logi, które da się powiązać z pracownikami, są danymi osobowymi, a zasady RODO obowiązują je tak samo jak każdy inny zapis. Art. 5 ust. 1 wymaga określonego celu, danych ograniczonych do tego, co dla celu niezbędne, i przechowywania nie dłużej, niż to konieczne, co wprost odpowiada krokom powyżej. Art. 88 pozwala państwom członkowskim wprowadzić w przepisach prawa lub w porozumieniach zbiorowych bardziej szczegółowe zasady dla danych pracowniczych i wymienia systemy monitorowania w miejscu pracy jako kwestię, którą te zasady muszą uwzględnić. Gdy przetwarzanie może powodować wysokie ryzyko, art. 35 wymaga oceny skutków dla ochrony danych przed jego rozpoczęciem. Czy dotyczy to twojego przypadku, ustal z inspektorem.

Każdy dostawca, który przetwarza logi lub prompty w twoim imieniu, czy to API modelu, hosting, czy zarządzana brama, potrzebuje umowy powierzenia na podstawie art. 28 ust. 3 RODO, określającej przedmiot, czas trwania, charakter i cel przetwarzania oraz rodzaj danych i zobowiązującej do usunięcia lub zwrotu danych po zakończeniu usługi. Zapytaj każdego dostawcę, co i jak długo loguje po swojej stronie, bo te logi leżą poza twoją konfiguracją i poza tym, co możesz pokazać radzie.

AI Act dotyka logowania głównie przez art. 26 o podmiotach stosujących systemy AI wysokiego ryzyka. Art. 26 ust. 6 wymaga od nich przechowywania automatycznie generowanych logów przez okres odpowiedni do przeznaczenia systemu, nie krótszy niż sześć miesięcy, o ile prawo unijne lub krajowe nie stanowi inaczej. Art. 26 ust. 7 zobowiązuje pracodawców do poinformowania przedstawicieli pracowników i pracowników, których to dotyczy, zanim system wysokiego ryzyka zostanie oddany do użytku lub użyty w miejscu pracy. Według harmonogramu AI Act Service Desk Komisji Europejskiej, uwzględniającego zmiany z pakietu Digital Omnibus, przepisy o systemach wysokiego ryzyka z załącznika III obowiązują od 2 grudnia 2027 (stan na 7 listopada 2026). Naszym zdaniem wewnętrzny asystent czy agent kodujący zwykle nie jest systemem wysokiego ryzyka, ale jeśli używasz AI do decyzji dotyczących pracowników, sześciomiesięczne minimum może kolidować z krótką retencją z porozumienia zakładowego, więc planuj jedno i drugie razem.

Lista kontrolna do rozmowy z radą zakładową

Przynieś dowody. Rada i ekspert, którego ewentualnie zaprosi, będą chcieli zobaczyć, co jest skonfigurowane w działającym systemie. Z naszego doświadczenia rozmowa idzie lepiej, gdy te elementy są gotowe przed pierwszym spotkaniem:

• Diagram przepływu danych od ekranu użytkownika do dostawcy modelu z zaznaczonym każdym miejscem, w którym powstają logi
• Spis każdego logu pole po polu, z celem, listą osób z dostępem i okresem przechowywania
• Rzeczywistą konfigurację: ustawienia bramy, ustawienia telemetrii w pliku managed settings, reguły collectora i wszystkie wartości z paneli administracyjnych, które je nadpisują
• Testowe zapytanie wysłane w trakcie spotkania, a potem wspólne sprawdzenie, co dokładnie trafiło do każdego logu
• Przykładowe raporty w docelowej formie, zagregowane na zespoły, żeby nikt nie musiał ich sobie wyobrażać
• Macierz ról i uprawnień, w tym informację, kto ma prawa administratora bramy i kto widzi metryki Copilota
• Procedurę wyjątków dla dochodzeń bezpieczeństwa z krokami zatwierdzania i usuwania danych
• Listę logów po stronie dostawców i umów powierzenia, które ich dotyczą
• Proces zmian: które zmiany konfiguracji wymagają zgody rady, oraz kontrolę po każdej aktualizacji bramy lub agenta, bo nowe wersje mogą dodawać pola

Jeśli chcesz pomocy po stronie technicznej, budujemy i utrzymujemy takie platformy na twoich serwerach albo na twoim koncie w chmurze i możemy przygotować dowody konfiguracji na tę rozmowę.

AI on-premise na własnych serwerachBrama LiteLLM: wdrożenie i utrzymanieInżynieria platformy LLM