Od czatu, który odpowiada, do Copilota, który pracuje
Interfejsów czatowych mamy dziś pod dostatkiem. Zespoły operacyjne korzystają z wyszukiwarek, portali z dokumentacją, dashboardów i coraz częściej właśnie z czatów opartych na modelach językowych. Mimo to codzienna praca wciąż wymaga przeskakiwania między systemami: procedury są w jednym miejscu, stan urządzeń w drugim, a zlecenia serwisowe w trzecim.
W tym artykule pokazujemy, czym różni się zwykły czat od operacyjnego Copilota, jakie warunki musi spełnić taki asystent, zanim trafi na produkcję, i jak zbudować go na platformie Microsoft Azure z użyciem Microsoft Foundry. Na koniec przechodzimy przez krótkie demo: od pytania o procedurę, przez diagnozę urządzenia, po automatycznie przygotowane zlecenie serwisowe.
Czat a operacyjny Copilot: na czym polega różnica
Czat jest po prostu interfejsem: zadajemy pytanie i dostajemy wygenerowaną odpowiedź. Operacyjny Copilot idzie dalej, bo pomaga wykonać pracę. Może być uruchamiany z okna czatu, ale równie dobrze może działać jako przepływ zupełnie niezależny od interfejsu, który tylko w kluczowych momentach wchodzi w interakcję z człowiekiem.- Rozumie kontekst operacyjny użytkownika, w imieniu którego pracuje.
- Opiera odpowiedzi na instrukcjach i procedurach organizacji, a nie na ogólnej wiedzy modelu.
- Odczytuje aktualny stan systemów i urządzeń, czyli pracuje na danych żywych, a nie na tym, co ktoś wkleił do okna czatu.
- Proponuje lub wykonuje dozwolone działania, zawsze w ramach, które mu wyznaczono.
- Zwraca wynik, który da się audytować: nie tylko informację o efekcie, ale też ślad kroków, które do niego doprowadziły.
Prawdziwy problem: rozproszenie
Wyzwaniem biznesowym nie jest brak czatów, tylko to, że informacje i działania są rozproszone po wielu systemach. Dobrze widać to na przykładzie firmy produkcyjnej, daleko od typowego IT. Gdy jakieś urządzenie ulega awarii, zwykły czat potrafi wyjaśnić, jak zareagować. Operacyjny Copilot w tej samej sytuacji:- pobiera właściwe procedury ze swojej bazy wiedzy,
- sprawdza aktualny stan urządzenia, np. przez API,
- wskazuje zalecane rozwiązanie problemu,
- a jeśli ma odpowiednie uprawnienia, tworzy zlecenie serwisowe.
Różnica jest więc taka jak między kimś, kto zna instrukcję, a kimś, kto potrafi z niej skorzystać, sprawdzić sytuację na miejscu i załatwić sprawę do końca.
Od demo do produkcji: zaufanie i kontrola
Zbudowanie działającego demo to jedno. Agent, który ma czytać i zmieniać dane w systemach firmy, musi jednak być godny zaufania. Zaufanie opiera się na pięciu filarach, od których warto zaczynać projektowanie, a nie dokładać je na końcu.1. Uwierzytelnianie: kto pyta? Pierwsza granica, jaką stawiamy Copilotowi, to ustalenie, kim jest użytkownik lub usługa, która go wywołuje. Na tej podstawie powstaje kontekst osoby, która zleca pracę.
2. Autoryzacja: co wolno agentowi? To, że Copilot działa w imieniu pracownika, nie oznacza, że dostaje te same uprawnienia co on. Działania agenta autoryzujemy tak granularnie, jak to możliwe, ale z zachowaniem zdrowego rozsądku. Pracownik z szerokimi uprawnieniami nie powinien automatycznie oznaczać agenta z szerokimi uprawnieniami.
3. Potwierdzenie: kiedy pytać człowieka? Trzeba z góry zdecydować, które akcje wymagają wyraźnej zgody pracownika, a które Copilot może wykonać sam. Nie chodzi o kreator, w którym użytkownik klika „dalej, dalej, dalej” przy każdym kroku. Chodzi o sensowny podział: część kontroli ma agent, a decyzje istotne zostają przy człowieku. Typowy przykład: odczyt danych bez pytania, zapis do systemu dopiero po akceptacji (tzw. human in the loop).
4. Obserwowalność: czy da się prześledzić każdą decyzję? Każde wywołanie narzędzia i każda decyzja modelu powinny zostawiać ślad. To punkt wyjścia każdego projektu asystenta, a nie dodatek. Bez tego nie wyjaśnimy, dlaczego agent zrobił to, co zrobił, ani nie poprawimy jego działania.
5. Niezawodność: co, jeśli coś zawiedzie? Model, narzędzie albo zależna usługa w końcu będą niedostępne. Copilot powinien mieć wplecione scenariusze znane z klasycznego wytwarzania oprogramowania, które pozwalają kontrolować proces także wtedy, gdy część narzędzi czy źródeł informacji nie odpowiada.
Architektura: zaskakująco prosta
„Budujemy własnego Copilota” brzmi poważnie, ale mechanizm jest w gruncie rzeczy prosty. Składa się z czterech elementów:- Interfejs lub wyzwalacz, przez który dajemy agentowi sygnał do pracy. Albo opisujemy mu zadanie, albo zadanie jest już wbudowane w agenta, a my tylko je uruchamiamy.
- Agent z modelem językowym i instrukcjami, które opisują, jak ma się zachowywać.
- Narzędzia, które definiujecie sami, zależnie od potrzeb organizacji, np. API systemów biznesowych.
- Baza wiedzy, opcjonalna, ale w praktyce bardzo przydatna, bo to ona sprawia, że odpowiedzi opierają się na waszych procedurach.
Jak to wygląda w praktyce: Copilot na Azure i Microsoft Foundry
Składniki rozwiązania
Demo zbudowano możliwie natywnie chmurowo. Składa się z następujących elementów:| Element | Rola | Usługa |
|---|---|---|
| Aplikacja czatowa | Interfejs użytkownika, z którego wywołujemy akcje agenta | Azure Container Apps (Python) |
| Aplikacja operacyjna | System typu ERP do zarządzania urządzeniami i zleceniami serwisowymi | Azure Container Apps (Python) |
| Agent | Model bazowy, instrukcje i narzędzia | Microsoft Foundry Agent Service |
| Baza wiedzy | Procedury i instrukcje utrzymania urządzeń | Azure AI Search (Foundry IQ) |
| Monitoring | Logi i śledzenie wywołań | Application Insights |
| Tożsamość | Uwierzytelnianie i autoryzacja | Microsoft Entra ID |
Fikcyjna organizacja z demo ma fizyczne urządzenia w różnych lokalizacjach. Zadaniem Copilota jest wspieranie ich utrzymania.
Aplikacja operacyjna i jej API
Aplikacja operacyjna to zwykły system, z którego firma korzysta na co dzień. Na starcie ma na liście trzy zlecenia serwisowe. Kluczowe jest jej API opisane w standardzie OpenAPI: cztery endpointy, trzy metody GET i jedna POST. Copilot nie dostaje żadnego specjalnego interfejsu, tylko korzysta z tych samych metod co reszta organizacji.Aplikacja czatowa działa w kontekście użytkownika
Czat otwiera się od razu zalogowany, bo działa w kontekście zalogowanego pracownika. W innej przeglądarce ta sama aplikacja wymaga uwierzytelnienia przez Entra ID. To pierwszy z filarów zaufania w praktyce.
Scenariusz w trzech krokach
Krok 1: Copilot jako źródło wiedzy
Użytkownik pyta, jak reagować na powtarzające się wyłączenia urządzenia z powodu podwyższonego ciśnienia. Prosi przy tym o korzystanie wyłącznie z wewnętrznych procedur i o cytowanie źródeł. Copilot przeszukuje bazę wiedzy i zwraca procedurę postępowania. Na tym etapie działa jak dobry czat firmowy.
Krok 2: diagnoza na żywych danych
Następnie użytkownik prosi o sprawdzenie aktualnego stanu urządzenia CH-17 i porównanie go z procedurami. Copilot pobiera wskazania urządzenia przez API i stwierdza, że przekroczone zostało krytyczne ciśnienie 16 barów, czyli wartość graniczna, przy której urządzenie się wyłącza. To moment, w którym czat zamienia się w Copilota operacyjnego.Krok 3: działanie z człowiekiem w pętli
Na koniec użytkownik prosi o przygotowanie zlecenia pracy (work order) na prace serwisowe usuwające przyczynę problemu. Copilot sprawdza, kiedy urządzenie ma okno serwisowe, i proponuje zlecenie w tym oknie. Poprzednie kroki były odczytami i nie wymagały zgody. Zapis do systemu już tak: Copilot czeka na potwierdzenie użytkownika.
Co jest pod spodem
Model. Agent korzysta z GPT-4.1 mini. To model tani i szybki, choć z mniejszymi możliwościami rozumowania niż większe modele. Dobór modelu do zadania to decyzja zespołu, który buduje agenta: kompromis między kosztem, szybkością i jakością decyzji.
Instrukcje. W sercu agenta leżą instrukcje opisujące, jak ma się zachowywać i jak wykonywać pracę.
Narzędzie 1: baza wiedzy. Indeks w Azure AI Search, od niedawna pod nazwą Foundry IQ, zawiera trzy dokumenty: politykę utrzymania, instrukcję obsługi i utrzymania chłodnic oraz runbook postępowania przy alarmach wysokiego ciśnienia. Dokumenty są krótkie, ale to tylko demo; zawartość bazy zależy wyłącznie od organizacji. Polecamy Foundry IQ ze względu na integrację, wektoryzację i wzbogacanie wiedzy modelami językowymi, choć rolę bazy wiedzy mogą pełnić też inne usługi, także spoza Azure.
Narzędzie 2: API aplikacji operacyjnej. W Foundry zdefiniowano połączenie z API przez specyfikację OpenAPI. Kluczowy szczegół: agent nie dostaje wszystkich czterech endpointów. Specyfikacja przekazana agentowi określa, co mu wolno. Czego w niej nie ma, tego agent w ogóle nie rozważa jako możliwej akcji. To programowa, twarda granica, a nie prośba zapisana w prompcie. Tak właśnie wygląda granularna autoryzacja z części teoretycznej.
Obserwowalność w praktyce
W Foundry widać każde uruchomienie agenta: czas trwania (w demo 5–10 sekund), liczbę tokenów wejściowych i wyjściowych oraz wersję agenta. Po wejściu głębiej widać podział na poszczególne kroki, wywołania narzędzi i to, co narzędzia zwróciły agentowi przed podjęciem decyzji.
Podsumowanie
Operacyjny Copilot to nie kolejny czat, tylko asystent, który łączy wiedzę, dane i działania rozproszone po różnych systemach. Technicznie nie jest skomplikowany: interfejs, agent z modelem i instrukcjami, kilka narzędzi i baza wiedzy. Trudność leży gdzie indziej: w zaprojektowaniu zaufania.
Najważniejsze wnioski:
- Zacznij od granic, nie od funkcji. Uwierzytelnianie, granularna autoryzacja, punkty potwierdzenia, obserwowalność i odporność na awarie to fundament, a nie dodatek przed wdrożeniem.
- Uprawnienia agenta to nie uprawnienia użytkownika. Najlepiej ograniczać je programowo, np. przez okrojoną specyfikację OpenAPI.
- Odczyt sam, zapis za zgodą. Prosty podział, który daje szybkość bez utraty kontroli.
- Wykorzystaj istniejące API. Copilot nie potrzebuje nowych systemów, tylko dostępu do tych, które już działają.
- Dobieraj model do zadania. Mniejszy i tańszy model często wystarcza, jeśli ma dobre instrukcje i narzędzia.
