Copilot w Slacku i Teams: co z rozmowy trafia do GitHuba?

Wyobraź sobie zwykły wątek na Slacku: klient zgłasza błąd w SaaS, ktoś wrzuca screenshot, ktoś dokleja log z adresem e-mail użytkownika, a zespół ustala termin poprawki. Potem pada @GitHub, przygotuj PR, czyli propozycję zmian w kodzie. Brzmi jak sensowne skrócenie drogi od zgłoszenia do poprawki. Tylko co z tej rozmowy dostanie Copilot, a co może zostać w GitHubie?

25 września 2026 r. GitHub rozszerzył integracje Copilota ze Slackiem i Microsoft Teams. Agent może 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. Utworzone zadania mają też odsyłać do rozmowy, z której powstały. Integracje są w publicznym preview, a część funkcji pojawia się stopniowo. Zanim oddasz agentowi zgłoszenie klienta, sprawdź więc, co właściwie mu przekazujesz.

Czego dowiesz się z tego tekstu?

W skrócie

• W rozmowie grupowej w Slacku i Teams Copilot bierze cały wątek jako kontekst. GitHub zaznacza, że kontekst jest zapisywany w materiałach tworzonych przez agenta. To nie znaczy, że każda wiadomość zostanie skopiowana słowo w słowo.
• Zmianę w repozytorium może zlecić osoba z uprawnieniem write. Pozostali uczestnicy rozmowy mogą dostarczać kontekst; goście workspace’u i zewnętrzni współpracownicy repozytorium nie mogą rozpoczynać ani sterować sesją.
• Człowiek musi przejrzeć i połączyć PR agenta. Dane klienta mogą jednak pojawić się w issue lub opisie PR, zanim ktokolwiek zacznie review kodu.
• Przed uruchomieniem sprawdź wątek, docelowe repozytorium, dostęp do nowych materiałów i umowę z klientem.

Czy Copilot czyta tylko wiadomość z @GitHub?

W rozmowie grupowej Copilot korzysta z całego wątku, a nie tylko z wiadomości, w której go oznaczysz. Dokumentacja dla Slacka i instrukcja dla Teams mówią też, że ten kontekst zostaje w materiałach tworzonych przez agenta, na przykład w issue, czyli zgłoszeniu w GitHubie, lub PR. Nie wynika z tego, że dostaniesz stenogram całej rozmowy. Wcześniejsze wiadomości mogą jednak wpłynąć na treść zadania i trafić do dokumentu widocznego w repozytorium.

Wróćmy do błędu w naszym SaaS. Polecenie brzmi „napraw import”, ale kilka wiadomości wyżej jest log z adresem e-mail i ustalenie z klientem. Agent może wykorzystać obie informacje, choć nie wkleiłeś ich do polecenia. Po wrześniowej zmianie kontekst mogą uzupełnić również obsługiwane załączniki w Slacku oraz obrazy i przekazane wiadomości w Teams. Sprawdź formaty i dostępność w swoim workspace, bo preview nadal może się zmieniać.

Jeśli do naprawy 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. W Slacku agent tworzy też osobny kanał Slack Code dla zadania. Jego archiwizacja nie usuwa historii: pozostaje ona dostępna i wyszukiwalna.

Kto może zlecić zmianę, a kto wpływa na wynik?

Zmianę może zlecić osoba z uprawnieniem write, ale kontekst mogą uzupełniać inni uczestnicy rozmowy. Write oznacza możliwość wprowadzania zmian w repozytorium. Ktoś bez tego uprawnienia może dopisać w wątku informację, którą agent uwzględni. Goście workspace’u i zewnętrzni współpracownicy repozytorium nie mogą rozpoczynać ani sterować sesją. Zasady opisuje w instrukcjach dla Slacka i Teams.

Dla CTO oznacza to, że trzeba przejrzeć również to, co zespół dopisał przed wywołaniem agenta. Jedna osoba wrzuciła stare wymaganie klienta, druga prosi o implementację, a Copilot dostaje oba komunikaty. Nie licz na to, że sam odgadnie, które ustalenie jest aktualne. W poleceniu wskaż decyzję, repozytorium i granice zadania, a potem sprawdź, jakie założenia agent przyjął.

Sprawdź też, pod czyim kontem powstanie issue lub PR. W wiadomości prywatnej agent korzysta z uprawnień powiązanego konta GitHub użytkownika. W kanale albo grupowym wątku tworzy materiały jako aplikacja. Jeśli reguły repozytorium wymagają już co najmniej jednej akceptacji, GitHub domyślnie wymaga dodatkowej akceptacji dla PR utworzonego jako aplikacja. Ten sam agent może więc przejść inną ścieżkę review zależnie od tego, skąd go wywołasz.

Co, jeśli wątek zawiera dane klienta?

Zostaw agentowi to, czego potrzebuje do naprawy. Numer zgłoszenia, opis błędu i oczekiwany wynik mogą wystarczyć. Do poprawienia importu zwykle nie potrzebuje pełnego zrzutu z produkcji ani informacji, jaki rabat wynegocjował klient. Jeśli takie szczegóły zostaną w wątku, mogą wpłynąć na treść issue lub PR. Sprawdź, kto zobaczy je w docelowym repozytorium, a po utworzeniu zadania przejrzyj opis, komentarze i diff, czyli zestaw zmian w kodzie.

Przy danych osobowych trzeba ograniczyć je do tego, co niezbędne, i dobrać zabezpieczenia do ryzyka. To zasady minimalizacji i bezpieczeństwa RODO. Jeśli SaaS przetwarza dane w imieniu klienta, sprawdź też jego instrukcje, umowę i dostawców uczestniczących w tym przepływie. Czy takie użycie danych jest dozwolone? Czy dochodzi kolejny podmiot przetwarzający, czyli dostawca przetwarzający dane w imieniu klienta, którego udział wymaga wcześniejszej pisemnej zgody klienta? Sama nazwa „integracja” nie rozstrzyga ról stron. Przy poufnych informacjach sprawdź również NDA, czyli umowę o poufności, i zakres dopuszczonego ujawnienia.

W GitHubie może powstać kolejna kopia informacji z rozmowy, z własną historią i innym kręgiem odbiorców. Opis zadania albo PR nie musi być widoczny tylko dla osób z pierwotnego wątku. Link do rozmowy źródłowej też trzeba uwzględnić przy sprawdzaniu dostępu. Szerszą ocenę dostawcy opisuję w checkliście przed zakupem narzędzia AI. Tutaj sprawdzamy konkretny odcinek: co wychodzi ze Slacka lub Teams i gdzie zostaje w repo.

Czy przegląd PR wystarczy, żeby ochronić dane?

Review powinno objąć kod i treść materiałów utworzonych przez agenta. GitHub ogranicza cloud agenta: nie może sam połączyć PR ani wypchnąć zmian na domyślną gałąź. Przegląd i połączenie PR należą do człowieka. Masz więc moment na sprawdzenie kodu, testów i założeń, ale informacje w issue lub PR mogą być widoczne wcześniej.

Zespół sprawdza poprawkę importu, testy są zielone, a opis PR może już zawierać e-mail użytkownika albo poufne ustalenie z klientem. Dlatego zajrzyj również do opisów, komentarzy i ustawień dostępu. Samo zamknięcie PR nie gwarantuje usunięcia kopii z historii. Jeśli coś zostało ujawnione niepotrzebnie, ustal, gdzie informacja została zapisana, ogranicz dostęp i zastosuj procedurę obsługi incydentów, gdy okoliczności tego wymagają.

Jak przeprowadzić pilotaż w software house albo SaaS?

Zacznij od jednego zadania na danych testowych. Sprawdź pięć rzeczy:

1. Dostęp: czy cloud agent i sandboxy są włączone, które repozytoria może obsługiwać aplikacja i kto ma w nich write. Sprawdź wymagania dla Slacka albo Teams.
2. Kontekst: co jest w testowym wątku, razem z obsługiwanymi plikami i załącznikami w Slacku oraz obrazami i przekazanymi wiadomościami w Teams. Usuń wszystko, czego zadanie nie potrzebuje.
3. Cel: czy polecenie wskazuje właściwe repozytorium. Kanał może mieć wspólne repo domyślne, więc podaj docelowe repo wprost i sprawdź, gdzie agent tworzy zadanie. Oszczędzisz zespołowi wycieczki po repozytoriach w poszukiwaniu własnego PR.
4. Wynik: kto przegląda issue, opis PR i kod oraz kto może połączyć zmiany.
5. Umowy: czy w rzeczywistym wątku pojawią się 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 zgłoszenia można przekazywać agentowi, co trzeba usunąć z wątku, kto zatwierdza wynik i do jakiego repo może trafiać praca. Jeśli takie integracje pojawiają się oddolnie w kilku zespołach, przyda się też uporządkowanie korzystania z AI w firmie.

Pilotaż na danych testowych możesz zrobić sam, jeśli masz jasne uprawnienia i wiesz, co agent tworzy. Gdy dochodzą dane klientów, repozytoria współdzielone z kontrahentami albo zobowiązania do poufności, sprawdź przepływ danych i umowy przed uruchomieniem. Jeśli chcesz przejść to z nami, napisz do Lis.Legal: przyjrzymy się integracji, uprawnieniom i temu, co trafia do repo. Zobacz też nasze wsparcie dla firm SaaS.