Azure Bot Service: co po końcu wsparcia Bot Framework

Dostajesz ofertę rozbudowy firmowego bota, a w opisie nadal widzisz Bot Framework, LUIS i QnA Maker. Czy to aktualny zestaw narzędzi? Koniec wsparcia Bot Framework wymaga przeglądu zależności bota; nie oznacza automatycznie wyłączenia każdego zasobu Azure Bot Service. Najpierw ustal, które elementy obsługują rozmowę, wiedzę i działania. Dopiero potem wybierz zakres migracji.

Azure Bot Service i Bot Framework to różne elementy

Azure Bot Service pomaga łączyć aplikację konwersacyjną z kanałami komunikacji. Bot Framework SDK był zestawem bibliotek używanym do tworzenia jej logiki. Kod bota, źródła wiedzy, model językowy, przechowywanie stanu i system obsługi zgłoszeń mogą być osobnymi składnikami.

Jeśli bot ma odbierać sprawy techniczne pracowników, migracja kanału nie kończy projektu. Osobno określ, kiedy odpowiedź powinna zamienić się w zgłoszenie i kto je obsłuży — przykład takiego procesu pokazuje agent IT w Copilot Studio.

Microsoft podaje, że Bot Framework SDK nie jest już rozwijany ani utrzymywany, a obsługę zgłoszeń wsparcia zakończono 31 grudnia 2025 r. Dla dalszego rozwoju wskazuje Microsoft 365 Agents SDK. Źródła: dokumentacja Bot Framework SDK, repozytorium Microsoft z komunikatem o wsparciu.

Na dzień aktualizacji, 15 września 2026 r., nie należy zatem przedstawiać starego SDK jako domyślnego wyboru do nowego projektu. Jednocześnie samo działanie strony czatu nie potwierdza, że wszystkie jego komponenty mają aktualne wsparcie.

Warstwa	Co sprawdzić w istniejącym rozwiązaniu
Kanał rozmowy	Gdzie klient pisze i jak wiadomość dociera do aplikacji
Kod bota	Biblioteki, wersje, sposób wdrożenia i właściciel utrzymania
Rozpoznawanie intencji	Usługa lub reguły kierujące rozmową
Wiedza	Źródła odpowiedzi, aktualność i uprawnienia
Działania	Integracje z CRM, ERP lub systemem zgłoszeń
Nadzór	Logi, obsługa błędu i przekazanie sprawy człowiekowi

Taką mapę powinien umieć przygotować zespół utrzymujący rozwiązanie. Jeśli oferta wymienia tylko nazwę platformy, poproś o brakujące zależności i ich status.

LUIS i QnA Maker również wymagają uwagi

W dawnych architekturach LUIS rozpoznawał intencje i informacje w wypowiedzi, a QnA Maker obsługiwał bazę pytań i odpowiedzi. Ich status trzeba sprawdzić osobno od bibliotek bota.

Dawny składnik	Potwierdzony status	Kierunek wskazywany przez Microsoft
LUIS	Pełne wycofanie 31 marca 2026 r.	Conversational Language Understanding
QnA Maker	Pełne wycofanie 31 października 2025 r.	Custom Question Answering
Bot Framework SDK	Brak dalszego utrzymania; koniec obsługi zgłoszeń w grudniu 2025 r.	Microsoft 365 Agents SDK

Daty usług językowych: dokumentacja LUIS, Azure Language — informacje o zakończeniu QnA Maker. W starszych materiałach spotkasz wcześniejszy termin QnA Maker, 31 marca 2025 r.; Microsoft przedłużył działanie części funkcji do końca października. Źródło: komunikat o przedłużeniu.

Nie planuj migracji na podstawie samego zastąpienia nazwy w dokumentacji. Sprawdź, czy masz dostępne eksporty, kod, przykłady wypowiedzi i testy. Brak archiwum może oznaczać konieczność odtworzenia części konfiguracji z posiadanych materiałów.

Co zmienia Microsoft 365 Agents SDK

Microsoft 365 Agents SDK jest następcą kierunku rozwoju Bot Framework, ale migracja nie sprowadza się do zmiany jednego pakietu. Dokumentacja wskazuje elementy, których nie przeniesiono, między innymi Adaptive Dialogs oraz artefakty Bot Framework Composer. Rozwiązanie oparte na tych mechanizmach potrzebuje alternatywnej implementacji. Źródło: oficjalny przewodnik migracji.

To dobry moment, żeby oddzielić funkcje nadal potrzebne od historycznych obejść. Nie oznacza to jednak, że każdą przewidywalną ścieżkę rozmowy trzeba zastąpić swobodnym generowaniem tekstu. Zmiana adresu dostawy czy przyjęcie zgłoszenia może nadal wymagać jednoznacznego formularza, walidacji i potwierdzenia.

Przed wyborem technologii zapisz kontrakt zadania: jakie dane bot przyjmuje, z czego może korzystać, jaki wynik zwraca i czego nie wykonuje bez zatwierdzenia. Ta zasada wiąże narzędzie z odpowiedzialnością opisaną w Inteligentnym Systemie Operacyjnym Firmy.

Zacznij od jednej ścieżki rozmowy

Załóżmy modelowy przypadek: bot odpowiada na pytania o status zamówienia i przekazuje reklamacje konsultantowi. Pierwszą próbą migracji może być samo sprawdzenie statusu, bez zmiany zamówienia i bez automatycznego rozstrzygania reklamacji.

Wybierz pytania, dla których znasz oczekiwany wynik. Poniższy zestaw 20 rozmów to propozycja testu, a nie branżowy standard:

Przypadek	Liczba	Oczekiwane zachowanie
Poprawny numer i uprawniony użytkownik	8	Status zgodny ze źródłem
Niepełne dane	4	Prośba o konkretną brakującą informację
Próba dostępu do cudzego zamówienia	4	Odmowa ujawnienia danych
Niedostępny system źródłowy	2	Jawny komunikat i dalsza ścieżka obsługi
Żądanie spoza zakresu	2	Przekazanie sprawy albo opis ograniczenia

Testuj również, co trafia do konsultanta: sam tekst ostatniej wiadomości może nie wystarczyć do kontynuowania sprawy. Jednocześnie przekazanie całej historii bez kontroli może ujawniać dane, których odbiorca nie potrzebuje.

Zaakceptuj migrację tej ścieżki dopiero wtedy, gdy wynik, uprawnienia i obsługa wyjątków są sprawdzone. Kolejne intencje przenoś według tego samego schematu.

Policz koszt całej obsługi

Dawne szacunki „kilkadziesiąt dolarów miesięcznie” nie mówią wiele bez liczby rozmów i architektury. W wycenie rozdziel uruchomienie aplikacji, usługi AI, przechowywanie, integracje, monitoring i pracę zespołu. Przy voicebocie uwzględnij także komponenty głosowe i telefoniczne, jeśli występują w projekcie.

Miara do pilotażu: koszt sprawy zakończonej poprawnie, razem z kontrolą i poprawkami. Liczba wiadomości obsłużonych przez bota sama nie pokazuje efektu biznesowego.

Nie zakładaj, że bot sam doskonali się po każdej rozmowie. Zmiany w wiedzy, instrukcjach i modelach powinny mieć właściciela, test i możliwość wycofania. Częstotliwość przeglądu dopasuj do zmian w ofercie oraz ryzyka błędnej odpowiedzi.

Sprawdź też obowiązki wobec odbiorcy rozmowy: poradnik AI Act dla firmy pomaga rozdzielić kwestie prawne od samej migracji technicznej.

Co przygotować na spotkanie z wykonawcą

Poproś o mapę zależności, listę komponentów bez wsparcia i propozycję pierwszej ścieżki do przeniesienia. Ustal, kto posiada kod, konfigurację i kopie wiedzy oraz kto odpowiada za niedostępność usługi. Dopisz warunek powrotu do obsługi ręcznej, gdy nowa wersja nie spełni kryteriów.

Dla nowego projektu wymagaj aktualnych komponentów i tego samego zestawu dowodów. Nie musisz odtwarzać starej architektury tylko dlatego, że poprzedni poradnik na niej bazował.

Możesz potraktować migrację jako wymianę nazw technologii. Możesz też wykorzystać ją do uzyskania jednej sprawdzonej ścieżki obsługi, której działanie zespół rozumie i potrafi utrzymać.