Własny asystent AI w firmie: od wyboru modelu po integrację z Slackiem i Google Workspace

Po co firmie własny asystent AI, a nie „po prostu ChatGPT”?

Różnica między ogólnym chatbotem a asystentem opartym na danych firmy

Ogólny chatbot typu ChatGPT zna świat, ale nie zna Twojej firmy. Nie wie, jakie masz procedury, jak wyglądają procesy sprzedaży, jaki jest Wasz cennik, kto jest odpowiedzialny za dany etap projektu ani jakie macie wewnętrzne standardy. Własny asystent AI w firmie działa na tym samym silniku (LLM), ale ma podpiętą wewnętrzną wiedzę i funkcje dopasowane do realnych zadań zespołu.

Różnice widać już po jednym prostym pytaniu. Ogólny chatbot: „Jakie są obowiązki project managera?”. Asystent firmowy: „Jakie są obowiązki project managera w naszej firmie X?” – odwoła się do Twojej wewnętrznej dokumentacji, opisu ról, może nawet do konkretnych checklist ze środka Confluence czy Google Drive. To jest dokładnie ta różnica, która przesądza o tym, czy AI realnie odciąża zespół, czy tylko „ładnie pisze”.

Własny asystent AI dodatkowo respektuje wewnętrzne reguły: nie pokazuje dokumentów spoza uprawnień użytkownika, trzyma się aktualnych polityk firmy, umie cytować konkretne paragrafy regulaminu i procedur. Może też wykonywać akcje: tworzyć zadania w Asanie, wpisywać wydarzenia w kalendarz Google, aktualizować rekordy w CRM. Ogólny chatbot tego nie zrobi bez specjalnej otoczki technicznej i integracji.

Typowe zastosowania asystenta AI w firmie

Największą wartość własny asystent AI daje wtedy, gdy dotyka powtarzalnych zadań, które do tej pory zabierały ludziom czas, ale nie wymagały kreatywności. Klasyczne obszary:

• Obsługa wiedzy wewnętrznej: Q&A z regulaminów, procedur, instrukcji narzędzi, polityk HR. Zamiast pytać „kto wie?”, piszesz do asystenta na Slacku.
• Wsparcie sprzedaży: generowanie odpowiedzi na typowe pytania klientów na bazie ofert, cenników i case studies; podpowiedzi do maili handlowych; przygotowanie draftów prezentacji w Google Slides.
• Administracja i operacje: podsumowania spotkań z Google Meet, generowanie notatek i zadań, pomoc w wypełnianiu wzorów umów, szukanie informacji w gąszczu folderów na Dysku Google.
• HR i onboarding: odpowiadanie na pytania o urlopy, benefity, zasady pracy zdalnej, programy szkoleniowe; prowadzenie nowego pracownika przez checklistę startową.
• IT i wsparcie techniczne: pierwsza linia wsparcia w Slacku, która korzysta z bazy ticketów, dokumentacji i tutoriali; sugerowanie rozwiązań na podstawie poprzednich incydentów.

W tych obszarach asystent nie tylko odpowiada na pytania, ale też zmniejsza liczbę „przerywników” w pracy seniorów. Mniej mikro-pytań na Slacku, mniej konieczności tłumaczenia tego samego nowym osobom, mniej ręcznego przeklejania informacji między narzędziami.

Kiedy wystarczy gotowy chatbot, a kiedy opłaca się własny?

Gotowy asystent typu ChatGPT, Gemini czy Copilot w zupełności wystarczy na samym początku, gdy:

• nie masz jeszcze poukładanej wiedzy firmowej,
• zespół dopiero uczy się pracy z AI,
• chcesz głównie generowania tekstów, podsumowań, pomysłów – bez głębokiej integracji z systemami.

Własny asystent AI ma sens, gdy:

• ludzie tracą czas na szukanie informacji w intranecie, dyskach, Confluence,
• masz powtarzalne procesy (oferty, onboardingi, raporty), które da się zautomatyzować,
• potrzebujesz kontroli nad danymi (RODO, NDA, tajemnica przedsiębiorstwa),
• ważne jest logowanie, audyt, zarządzanie uprawnieniami oraz dopasowanie do narzędzi firmy (Slack, Google Workspace).

Dobrym testem jest pytanie: czy 30–40% pytań na Slacku / mailach wewnętrznych dotyczy wiedzy, która już istnieje w dokumentach? Jeśli tak – własny asystent AI zacznie się zwracać bardzo szybko.

Minimalny próg dojrzałości organizacyjnej

Wdrożenie asystenta AI w firmie to nie jest wyłącznie projekt IT. Potrzeba kilku warunków startowych:

• Właściciel inicjatywy biznesowej: osoba, która odpowiada za use case’y, priorytety i późniejsze adopcje – często COO, Head of Operations, czasem CTO lub szef HR.
• Minimalnie uporządkowane dane: nie muszą być idealne, ale kluczowe dokumenty powinny być w jednym miejscu (np. Dysk Google, Confluence) zamiast w prywatnych folderach.
• Chęć testowania i poprawiania: pierwsza wersja asystenta nie będzie idealna – trzeba kilka tygodni, by dopieścić prompt, RAG, integracje i polityki użycia.
• Decyzje o bezpieczeństwie: czy można używać chmury zewnętrznej? Jakie dane są wyłączone? Kto ma dostęp?

Bez tych elementów powstaje efekt „gadżetu”: fajna zabawka demonstracyjna, z której po tygodniu nikt nie korzysta, bo nie rozwiązuje żadnego realnego bólu zespołu.

Zdefiniowanie celu i zakresu: co asystent ma realnie robić

Jak przełożyć „chcemy AI” na konkretne scenariusze

Większość projektów AI zaczyna się od ogólnego hasła „chcemy AI w firmie”. Żeby to przełożyć na działającego asystenta, trzeba sprowadzić temat do kilku jasnych zadań. Najlepiej zastosować prostą mini-warsztatową metodę:

• Zbierz 3–5 osób z różnych działów (sprzedaż, obsługa klienta, HR, operacje).
• Poproś, żeby każdy wypisał 10 zadań, które:
  – powtarzają się co tydzień,
  – są męczące lub nudne,
  – polegają głównie na szukaniu informacji, kopiowaniu, przepisywaniu.
• Z każdego działu wybierz 2–3 zadania z największym „bólem” (czas, irytacja, przestoje).

Z takiej listy da się wybrać 2–3 pierwsze use case’y, wokół których zbudujesz pilotaż asystenta. To mogą być bardzo przyziemne rzeczy: podsumowania spotkań, generowanie odpowiedzi mailowych na powtarzalne pytania, wyszukiwanie w procedurach czy politykach.

Kryteria wyboru pierwszych zadań dla asystenta

Żeby pierwsze wdrożenie miało sens biznesowy, zadania dla asystenta AI powinny spełniać kilka warunków:

• Częstotliwość: zadanie występuje regularnie (codziennie, kilka razy w tygodniu) – np. odpowiadanie na pytania o urlopy, tworzenie ofert, przygotowanie raportów.
• Powtarzalność: struktura zadania jest podobna, choć szczegóły się zmieniają – np. „przygotuj ofertę na podstawie szablonu i danych klienta”.
• Wyraźny ból zespołu: ludzie narzekają, że to zabiera czas, jest nudne, wymaga przeklikiwania się przez 10 dokumentów.
• Prostota pod kątem ryzyka: na start lepiej wybrać zadania, w których błędna odpowiedź nie generuje dużego ryzyka prawnego lub finansowego (np. wewnętrzne Q&A zamiast automatycznych odpowiedzi na skomplikowane zapytania ofertowe).

Takie podejście pozwala zbudować sensowny pilotaż: nie potrzebujesz od razu „superasystenta”, który odpowie na każde pytanie. Wystarczy, że dobrze rozwiąże 2–3 dobrze opisane problemy. Resztę można dobudować później.

Przykłady pierwszych use case’ów w realnych firmach

Poniżej kilka typowych scenariuszy, które często pojawiają się jako pierwszy krok:

• Podsumowania spotkań: integracja z Google Meet / Kalendarzem Google. Asystent generuje notatki po spotkaniu, listę decyzji, listę zadań z przypisaniem do osób i terminów. Notatka ląduje w wątku Slacka i w Google Docs.
• Q&A z dokumentacji: pracownicy zadają pytania na Slacku (np. „Jak zgłosić home office na 2 dni?”), asystent odpowiada na podstawie procedur HR zapisanych na Dysku Google lub w Confluence.
• Wsparcie tworzenia ofert: handlowiec pisze na Slacku: „Przygotuj szkic oferty dla klienta X, branża Y, zakres Z”, a asystent generuje draft w Google Docs na bazie szablonu i biblioteki case studies.
• Wsparcie HR: kandydaci zadają często te same pytania. Asystent pomaga HR-owcom przygotować odpowiedzi, aktualizuje szablony wiadomości, podpowiada treści ogłoszeń na bazie wewnętrznych standardów.

Takie proste, powtarzalne scenariusze pokazują zespołowi, że asystent AI to nie „magiczna kulka”, tylko realne narzędzie pracy w Slacku i Google Workspace.

Opis person: kto korzysta z asystenta i jak

Dobry asystent jest projektowany pod konkretnych użytkowników, a nie pod „wszystkich”. Warto określić 2–3 persony:

• Handlowiec: pracuje głównie w Gmailu, Kalendarzu i CRM; oczekuje szybkich szkiców odpowiedzi, streszczeń załączników od klienta, propozycji kolejnych kroków w procesie sprzedaży.
• Specjalista HR: siedzi w Google Sheets, Dokumentach i Slacku; potrzebuje wsparcia w odpowiadaniu na pytania pracowników, przygotowywaniu opisów stanowisk i materiałów onboardingowych.
• Manager operacyjny: dużo spotkań, dużo dokumentów; oczekuje automatycznych notatek, agregacji danych z różnych źródeł, szybkiego dostępu do procedur i wskaźników.

Dla każdej osoby można rozpisać krótki scenariusz dnia: gdzie naturalnie asystent może „wejść w środek” ich pracy. Czy to będzie boczny panel w Gmailu? Komenda w Slacku? Przycisk w Google Docs? Ta analiza pomaga dobrać sensowne integracje i uniknąć sytuacji, w której asystent „żyje” w osobnej aplikacji, do której nikt nie zagląda.

Wybór modelu: gotowy LLM, własny model czy hybryda?

Przegląd głównych opcji technologicznych

Na wysokim poziomie masz trzy główne ścieżki:

• Usługi chmurowe (SaaS / API): OpenAI (GPT‑4.x, GPT‑4o mini), Anthropic (Claude), Google (Gemini), Azure OpenAI, AWS Bedrock. Model jest hostowany przez dostawcę, Ty wysyłasz zapytania przez API.
• Modele open‑source hostowane samodzielnie: Llama, Mistral i inne uruchomione na własnych serwerach lub w Twojej chmurze (GCP, AWS, Azure) – pełna kontrola nad danymi i konfiguracją, ale większa odpowiedzialność techniczna.
• Hybryda: część zadań idzie przez model chmurowy (np. złożone generowanie tekstu), część przez tańszy / lokalny model (np. prosty klasyfikator, ekstrakcja danych, anonimowanie).

W praktyce większość firm zaczyna od chmurowego API, bo to najszybszy sposób na pilotaż. Dopiero gdy skala użycia rośnie, a wymagania prawne są bardziej rygorystyczne, pojawia się temat własnego hostingu lub hybryd.

Kryteria wyboru modelu LLM pod kątem biznesu

Przy wyborze modelu nie chodzi tylko o „jakość generowania tekstu”, ale o kilka kluczowych parametrów:

• Jakość odpowiedzi w PL/EN: sprawdź, jak model radzi sobie z polskim językiem i żargonem Twojej branży. Przyda się krótki benchmark – kilka typowych pytań biznesowych zadanych różnym modelom.
• Koszt: koszt za 1K tokenów lub za jednostkę rozliczeniową, w zależności od dostawcy. Zrób prostą symulację: ile zapytań dziennie x ile tokenów x cena. Na początek pilotażu zwykle to nie są wysokie kwoty, ale przy skali warto policzyć.
• Latency (opóźnienie): czy odpowiedzi przychodzą w 1–2 sekundy, czy w 10? Przy integracji ze Slackiem i Google Workspace liczy się odczucie „czatu w czasie rzeczywistym”.
• Limity: maksymalna długość kontekstu (context window), limity zapytań na minutę dla firmy, dostępne regiony danych.
• Zgodność prawna i RODO: lokalizacja data center, zapis w umowie, że dane klientów nie są używane do trenowania modeli publicznych, możliwość zawarcia DPA (Data Processing Agreement).
• Wsparcie enterprise: SLA, support techniczny, możliwość whitelistowania IP, kontrola nad logami i metadanymi.

Warto przygotować krótką tabelę porównawczą dla 2–3 kandydatów, żeby decyzja nie opierała się wyłącznie na „wrażeniu”, ale na konkretnych parametrach.

Dobór konkretnego modelu do użycia w Slacku i Google Workspace

Po ogólnym wyborze dostawcy przychodzi moment na decyzję, który wariant modelu faktycznie będzie zasilał asystenta. Zwykle masz do wyboru kilka klas:

• modele „flagowe” (najmocniejsze, najdroższe) – do złożonych zadań,
• modele „economy/mini” – do prostych, częstych zapytań,
• specjalizowane modele narzędziowe (np. do klasyfikacji, ekstrakcji, tłumaczeń).

Dobrze jest przypisać klasę modelu do rodzaju zadań. Prosty schemat:

• Model topowy: generowanie ofert, raportów, złożone podsumowania spotkań, tworzenie materiałów dla klientów.
• Model tańszy/mini: krótkie odpowiedzi Q&A, wyszukiwanie w dokumentach, klasyfikacja zgłoszeń, proste przekształcenia tekstu.
• Model wyspecjalizowany: tłumaczenia między PL/EN, ekstrakcja pól z dokumentów (np. faktury, umowy), anonimizacja danych.

Technicznie oznacza to, że backend asystenta powinien umieć:

• na podstawie typu zadania wybrać odpowiedni endpoint/model,
• przekazać do modelu kontekst (np. wybrane dokumenty z Dysku Google, transcript ze spotkania),
• uwzględnić priorytet – interakcje w Slacku wymagają niższego opóźnienia niż np. generowanie dużego raportu w tle.

Architektura asystenta: warstwy i odpowiedzialności

Logika „pomiędzy” modelem a Slackiem / Google Workspace

Sam LLM to tylko silnik. Żeby powstał asystent używalny na co dzień, potrzebujesz kilku warstw pośrednich. Dobrze jest od razu rozrysować prostą architekturę logiczną:

• Warstwa interfejsów: Slack, Gmail, Google Chat, Google Docs (add‑ony / sidebar), ewentualnie przeglądarka (extension).
• Warstwa backendu asystenta: serwis, który odbiera eventy (np. wiadomości ze Slacka), rozpoznaje typ zadania, zarządza sesją użytkownika i dba o autoryzację.
• Warstwa integracji: moduły mówiące do API Slacka, Google Workspace, CRM, systemów HR, bazy wiedzy.
• Warstwa AI: klienci do LLM (1–2 dostawców), wektory (RAG), ewentualne mniejsze modele pomocnicze.
• Warstwa danych i logów: przechowywanie historii interakcji, statystyk użycia, metadanych o użytych dokumentach (bez pełnych treści, jeśli nie trzeba).

Przy pierwszym wdrożeniu nie trzeba budować wszystkiego w wersji „enterprise”. Wystarczy:

• jeden backend (np. mały serwis w Node.js / Pythonie),
• integracja ze Slackiem (Events API + Slash commands lub bot),
• podstawowe połączenie z Google Drive / Docs i jednym LLM.

RAG (Retrieval‑Augmented Generation): jak bezpiecznie podłączyć dokumenty firmowe

Żeby asystent odpowiadał z uwzględnieniem wewnętrznej wiedzy firmy, potrzebuje dostępu do dokumentów. Najczęściej robi się to przez RAG, czyli wyszukiwanie wektorowe + generowanie odpowiedzi. Minimalny schemat wygląda tak:

1. Indeksowanie: wybrane dokumenty (np. regulaminy, procedury, szablony) są dzielone na fragmenty (chunki), transformowane na wektory i zapisane w wektorowej bazie danych.
2. Zapytanie użytkownika: z pytania tworzony jest wektor, porównywany z indeksem.
3. Retrieval: pobieranych jest kilka najbardziej podobnych fragmentów dokumentów.
4. Generowanie: do modelu LLM wysyłany jest prompt z pytaniem + znalezione fragmenty, z instrukcją, by opierał się wyłącznie na nich.

Przy integracji z Google Workspace trzeba rozwiązać dwa dodatkowe tematy:

• Uprawnienia: asystent nie może „przeskakiwać” over permission. Jeśli użytkownik nie ma dostępu do dokumentu na Dysku, to nie powinien widzieć fragmentów z tego dokumentu w odpowiedzi.
• Aktualizacja indeksu: procedury i szablony zmieniają się. Potrzebny jest mechanizm ponownego indeksowania (np. co noc) albo eventowe odświeżanie po zmianie dokumentu.

Prosta praktyczna decyzja na początek: indeksuj tylko ograniczoną przestrzeń, np. folder „Baza wiedzy HR” + folder „Procedury operacyjne”. Resztę dodawaj sukcesywnie, gdy zespół zacznie korzystać.

Bezpieczeństwo i rozdział środowisk

Nawet w małej firmie przydaje się elementarny podział na środowiska, żeby eksperymenty nie mieszały się z produkcją:

• Dev / sandbox: testy nowego promptu, nowych integracji, eksperymenty z modelami. Dostęp ograniczony do kilku osób, najczęściej z mockowanymi danymi lub minimalnym zakresem prawdziwych danych.
• Staging: konfiguracja zbliżona do produkcji, ale z mniejszą liczbą użytkowników (np. wybrana grupa pilotażowa). Tu można mierzyć realne metryki jakości i obciążenia.
• Produkcja: środowisko dla reszty firmy, z wyraźnie ustalonym zakresem funkcji i monitorowaniem.

W praktyce oznacza to trzy osobne aplikacje Slack (lub trzy konfiguracje w obrębie jednej aplikacji) i osobne projekty w chmurze (GCP/AWS/Azure) dla backendu i bazy wektorowej.

Integracja ze Slackiem: od prostego bota do asystenta w wątkach

Model interakcji w Slacku

Slack oferuje kilka sposobów, by użytkownik porozumiewał się z asystentem. Najprostsze scenariusze:

• Dedykowany kanał #asystent-ai: użytkownicy piszą jak do zwykłego chatbota; dobre na start i do ogólnych pytań.
• Wzmianka w kanale: @asystent w wątku pod wiadomością – przydatne przy streszczeniach dyskusji, generowaniu follow‑upów, tworzeniu szkiców odpowiedzi.
• Slash commands: np. /podsumuj, /oferta, /wyszukaj-procedure; wygodne do konkretnych use case’ów.
• Message actions: kliknięcie prawym przyciskiem na wiadomość i wybranie akcji typu „Przekaż do asystenta” – szczególnie użyteczne przy przetwarzaniu treści (tłumaczenie, streszczenie, klasyfikacja).

Warto wybrać jeden „główny” tryb na start (najczęściej kanał + slash command) i dopiero po kilku tygodniach dodać kolejne formy interakcji.

Podstawowa integracja bota Slackowego krok po kroku

Minimalny plan techniczny dla zespołu developerskiego może wyglądać następująco:

1. Utwórz aplikację Slack: w Slack API Dashboard, nadaj jej nazwę i podłącz do przestrzeni roboczej.
2. Skonfiguruj zakresy uprawnień (scopes): odczyt wiadomości z kanałów, publikowanie odpowiedzi, obsługa wzmianki i komend. Nie dodawaj od razu pełnego zestawu uprawnień – tylko te, które są niezbędne.
3. Aktywuj Events API: skonfiguruj URL endpointu w backendzie, który będzie przyjmował eventy (np. nowe wiadomości w kanale #asystent‑ai, wzmianki @asystent).
4. Zaimplementuj prosty router eventów: na początku wystarczy:
   • odebrać wiadomość użytkownika,
   • wyczyścić treść (usunąć wzmianki, zbędne prefiksy),
   • wywołać funkcję handleMessage(),
   • odesłać wygenerowaną odpowiedź do Slacka.
5. Podłącz LLM: w handleMessage() zbuduj prosty prompt systemowy z kontekstem typu: „Jesteś asystentem firmy X, odpowiadasz krótko, po polsku…” i dołącz wiadomość użytkownika.
6. Dodaj logowanie: zapisuj do logów: identyfikator użytkownika, kanał, długość promptu, typ modelu, czas odpowiedzi, koszt (oszacowany na podstawie tokenów).

Po wdrożeniu takiego MVP w jednym kanale można zaprosić tam kilku ambasadorów z różnych działów, żeby „przepalili” asystenta realnymi pytaniami i scenariuszami.

Funkcje specyficzne dla Slacka: wątki, kontekst i szablony

Żeby asystent był użyteczny w codziennych rozmowach, powinien wykorzystywać to, co Slack już oferuje:

• Wątki: odpowiedzi asystenta zawsze w wątku do konkretnej wiadomości, nie na głównym kanale. Pozwala to zachować porządek i kontekst.
• Kontekst z historii: przy dłuższej rozmowie w wątku można pobrać kilka ostatnich wiadomości i zbudować z nich kontekst dla LLM, zamiast wysyłać tylko pojedyncze pytanie.
• Przyciski i menu: Slack Block Kit umożliwia dodanie np. przycisku „Rozwiń odpowiedź”, „Utwórz dokument w Google Docs”, „Dodaj zadanie do Asany”. To dobry sposób, by łączyć AI z konkretnymi działaniami.
• Szablony komend: opisane w /help lub przypięte do kanału, np.:
  • /podsumuj – streszcz ostatnie 50 wiadomości z kanału,
  • /spotkanie – wygeneruj agendę na podstawie krótkiego opisu,
  • /procedura <temat> – znajdź fragment regulaminu lub procesu.

Integracja z Google Workspace: praktyczne ścieżki

Autoryzacja i dostęp do zasobów Google

Połączenie z Google Workspace wymaga dobrego ogarnięcia autoryzacji. Kluczowe elementy:

• Projekt w Google Cloud: utworzenie projektu, włączenie API (Drive, Docs, Calendar, Gmail, Meet, Admin SDK).
• Typ aplikacji: zwykle „Web application” z OAuth 2.0 dla użytkowników oraz ewentualnie „Service account” do zadań serwerowych.
• OAuth i zgoda admina: konfiguracja ekranu zgody, uzyskanie zatwierdzenia przez administratora domeny dla wymaganych zakresów (scopes).
• Delegacja w imieniu użytkownika: w przypadku konta serwisowego – skonfigurowanie domain‑wide delegation, by backend mógł wykonywać operacje w imieniu użytkowników (np. odczyt kalendarza).

Na start rozsądnie jest ograniczyć zakresy do trzech obszarów: Dysk (do czytania dokumentów z określonych folderów), Kalendarz (do odczytu wydarzeń) i Meet (dostęp do nagrań / transkrypcji, jeśli są dostępne).

Asystent a Google Docs: generowanie i edycja dokumentów

Jednym z najbardziej widocznych efektów pracy asystenta są wygenerowane dokumenty – oferty, notatki, raporty. Prosta ścieżka integracji wygląda tak:

1. Użytkownik na Slacku wpisuje polecenie, np. „Przygotuj szkic oferty dla klienta X, branża Y, zakres Z”.
2. Asystent buduje prompt dla modelu, zaciąga potrzebne szablony i case studies przez RAG.
3. LLM generuje treść oferty (w czystym tekście lub w prostym formacie Markdown).
4. Backend tworzy nowy dokument Google Docs na podstawie szablonu:
   • określa folder, nazwę pliku,