Zespół SaaS omawia na Slacku błąd zgłoszony przez klienta. W wątku są zrzut ekranu, fragment logu z adresem e-mail użytkownika i ustalenie, jak szybko trzeba dostarczyć poprawkę. Ktoś oznacza @GitHub i prosi Copilota o przygotowanie zadania albo PR, czyli propozycji zmian w kodzie. Co z tej rozmowy zobaczy agent, a co może później znaleźć się w GitHubie?
To przykład modelowy, nie opis sprawy klienta Lis.Legal. 25 września 2026 r. GitHub rozszerzył integracje Copilota ze Slackiem i Microsoft Teams. Agent może teraz korzystać z obsługiwanych plików, załączników i linków do wiadomości w Slacku, a w Teams z obrazów, przekazanych wiadomości oraz historii kanału i wątku. GitHub łączy też utworzone zadania z rozmową, z której powstały. Funkcje są w publicznym preview i część z nich pojawia się stopniowo. Zanim zespół włączy agenta do pracy, musi więc wiedzieć, jaki kontekst dostaje i gdzie utrwala wynik.
Czego dowiesz się z tego tekstu?
- jaki fragment rozmowy dostaje Copilot po oznaczeniu
@GitHub; - kto może zlecić zmianę w repozytorium, a kto może wpłynąć na jej treść;
- dlaczego dane klienta mogą zostać w issue lub PR nawet po zakończeniu rozmowy;
- jak ustawić prosty proces dla zespołu, zanim włączy integrację.
W skrócie
- W Slacku i Teams agent używa całego wątku jako kontekstu. GitHub ostrzega, że ten kontekst jest zapisywany w wytworzonych przez agenta materiałach. Nie należy jednak zakładać, że każda wiadomość pojawi się w nich dosłownie.
- Zadanie prowadzące do zmian w repozytorium może uruchomić osoba z uprawnieniem
write. Inni uczestnicy rozmowy mogą dostarczać kontekst; GitHub wyklucza gości workspace’u i zewnętrznych współpracowników repozytorium z rozpoczynania i sterowania sesją. - PR przygotowany przez agenta wymaga przeglądu człowieka przed połączeniem zmian. Sam przegląd kodu nie rozwiązuje jednak problemu, jeśli dane klienta trafiły już do opisu issue lub PR.
- Przed uruchomieniem sprawdź zakres rozmowy, docelowe repozytorium, dostęp do nowych materiałów i zobowiązania wobec klienta.
Czy Copilot czyta tylko wiadomość z @GitHub?
Nie. W rozmowie grupowej punktem wyjścia jest cały wątek. Dokumentacja GitHuba dla Slacka i osobna instrukcja dla Teams mówią wprost, że agent bierze cały wątek jako kontekst i że ten kontekst pozostaje w wytworzonych materiałach, na przykład w issue lub PR. Nie wynika z tego, że każda wiadomość zostanie przepisana słowo w słowo. Przed uruchomieniem trzeba jednak przeczytać wątek z myślą o tym, że jego treść może wpłynąć na dokument widoczny w repozytorium.
W naszym modelowym SaaS polecenie brzmi: „napraw błąd przy imporcie”. Wcześniej w tym samym wątku ktoś wkleił log z adresem e-mail i fragment uzgodnień z klientem. Agent może wykorzystać te informacje do zrozumienia zadania, choć osoba wywołująca go nie powtórzyła ich w poleceniu. Po wrześniowej zmianie dochodzą też obsługiwane załączniki w Slacku oraz obrazy i przekazane wiadomości w Teams. Zakres obsługiwanych formatów i dostępność funkcji warto potwierdzić w swoim workspace, bo GitHub nadal oznacza integracje jako preview.
Jeśli do zadania wystarczy opis błędu, zacznij nowy wątek z oczyszczonym opisem albo napisz do aplikacji w wiadomości prywatnej. Obie instrukcje GitHuba wskazują wiadomość prywatną jako sposób na ograniczenie kontekstu. Przy Slacku warto też pamiętać, że agent tworzy osobny kanał Slack Code dla zadania, a po archiwizacji historia kanału pozostaje dostępna i wyszukiwalna.
Kto może zlecić zmianę, a kto wpływa na wynik?
Do uruchomienia pracy agenta na repozytorium trzeba mieć w nim uprawnienie write, czyli możliwość wprowadzania zmian. Współuczestnik zwykłego wątku bez tego uprawnienia może jednak dopisać informacje, które agent uwzględni. GitHub wyłącza z możliwości rozpoczęcia i sterowania sesją gości workspace’u oraz zewnętrznych współpracowników repozytorium. Te zasady są opisane osobno dla Slacka i dla Teams.
To praktyczna różnica dla CTO. Prawo do kliknięcia @GitHub nie oznacza, że tylko ta osoba ukształtuje zadanie. W modelowym wątku jedna osoba może wkleić nieaktualne wymaganie klienta, a druga poprosić o implementację. Agent dostaje oba komunikaty. Przed wydaniem polecenia wskaż więc aktualną decyzję, repozytorium i granice zadania; po odpowiedzi sprawdź, co agent rzeczywiście przyjął za założenie.
Wiadomość prywatna i rozmowa grupowa różnią się też tożsamością, z jaką powstają materiały. W prywatnej rozmowie agent działa z uprawnieniami powiązanego konta GitHub użytkownika. W kanale lub grupowym wątku tworzy issue i PR jako aplikacja. Jeżeli repozytorium ma regułę wymagającą co najmniej jednej akceptacji, PR utworzony jako aplikacja może wymagać dodatkowej akceptacji. Przed wdrożeniem sprawdź więc również reguły przeglądu w repozytorium.
Co, jeśli wątek zawiera dane klienta?
Najpierw ustal, co jest potrzebne do naprawy. Identyfikator zgłoszenia, opis błędu i oczekiwany wynik mogą wystarczyć. Adres e-mail użytkownika, pełny zrzut z produkcji albo warunki handlowe klienta często nie są potrzebne agentowi do przygotowania poprawki. Jeżeli zostaną w wątku, mogą wpłynąć na treść materiałów utworzonych w GitHubie. Trzeba sprawdzić, kto ma dostęp do docelowego repozytorium oraz do issue i PR, a po ich utworzeniu przejrzeć opisy, komentarze i diff pod kątem zbędnych informacji.
Gdy pojawiają się dane osobowe, dochodzi obowiązek ograniczenia ich do tego, co niezbędne, oraz dobrania zabezpieczeń do ryzyka. Wynika to z zasad minimalizacji i bezpieczeństwa RODO. Jeżeli firma SaaS przetwarza dane w imieniu klienta, trzeba też sprawdzić umowę z klientem i łańcuch dostawców: czy takie użycie jest objęte ustalonymi instrukcjami oraz czy w konkretnym przepływie pojawia się dalszy podmiot przetwarzający wymagający autoryzacji. Sam fakt użycia integracji nie rozstrzyga automatycznie ról stron. Przy tajemnicy przedsiębiorstwa i NDA sprawdź zakres dopuszczonego ujawnienia oraz dostęp do wytworzonych materiałów.
Poza samym przetwarzaniem przez agenta trzeba ocenić drugą kopię informacji, która może powstać w GitHubie. Opis zadania, PR i link do rozmowy źródłowej mają własny krąg odbiorców oraz historię. Zasady oceny dostawcy i jego warunków omawiam szerzej w checkliście przed zakupem narzędzia AI. Tutaj szczególnej uwagi wymaga przejście z komunikatora do repozytorium.
Czy przegląd PR wystarczy, żeby ochronić dane?
Nie, jeśli sprawdzacie wyłącznie kod. GitHub ogranicza cloud agenta: nie może sam połączyć PR ani wypchnąć zmian na domyślną gałąź. PR agenta wymaga przeglądu i połączenia przez człowieka. To daje zespołowi moment na ocenę kodu, testów i założeń, ale informacje w issue lub PR mogą być widoczne wcześniej.
Wróćmy jednak do naszego wątku. Jeśli w opisie issue pojawi się e-mail użytkownika albo poufne ustalenie z klientem, szkoda może powstać wcześniej niż przy mergu. Przegląd powinien zatem objąć również treść issue, PR i widoczność tych materiałów. Gdy coś zostało tam niepotrzebnie ujawnione, samo zamknięcie PR nie musi usunąć kopii z historii. Zespół powinien sprawdzić, gdzie informacja została utrwalona, ograniczyć dostęp i zastosować własną procedurę obsługi incydentów, jeżeli okoliczności tego wymagają.
Jak przeprowadzić pilotaż w software house albo SaaS?
Zacznij od jednego zadania na danych testowych. Sprawdź pięć rzeczy:
- Dostęp: czy administrator włączył cloud agenta i sandboxy, które repozytoria są dostępne dla aplikacji oraz kto ma w nich
write. GitHub opisuje te warunki dla Slacka i Teams. - Kontekst: czy testowy wątek zawiera tylko informacje potrzebne do zadania; w Teams także obrazy i przekazane wiadomości, a w Slacku obsługiwane pliki i załączniki.
- Cel: czy wskazano właściwe repozytorium. W kanale może działać wspólne repozytorium domyślne, więc lepiej podać je w poleceniu i sprawdzić przed utworzeniem materiałów.
- Wynik: kto przegląda treść issue, PR i kod oraz kto ma uprawnienie do połączenia zmian.
- Umowy: czy wątek może zawierać dane klienta lub poufne informacje i czy umowy oraz polityka firmy pozwalają użyć ich w tym procesie.
Po teście zapisz krótką regułę dla zespołu: które typy zgłoszeń można przekazywać agentowi, co trzeba usunąć z wątku, kto zatwierdza wynik i do jakiego repozytorium może trafiać praca. Jeśli podobne integracje pojawiają się oddolnie w kilku zespołach, przyda się również porządek w korzystaniu z AI w firmie.
Możesz uruchomić taki pilotaż samodzielnie, jeśli używasz danych testowych, masz jasne uprawnienia i wiesz, co agent tworzy. Przy danych klientów, repozytoriach współdzielonych z kontrahentami albo zapisach o poufności warto najpierw przejrzeć przepływ i umowy. Jeśli chcesz to uporządkować, napisz do Lis.Legal albo zobacz, jak pracujemy z firmami SaaS.