Agent z Microsoft Foundry w Microsoft 365 Copilot: co zmienia bezpośrednia publikacja

Microsoft Foundry, wcześniej rozwijany jako Azure AI Foundry, pozwala obecnie publikować przygotowanego agenta bezpośrednio do Microsoft 365 Copilot i Microsoft Teams. Portal automatyzuje utworzenie warstwy komunikacyjnej, przygotowanie manifestu aplikacji oraz zgłoszenie agenta do katalogu Microsoft 365. Dzięki temu firma może udostępnić własną logikę AI w narzędziach, w których pracownicy już wykonują codzienne zadania.

Nie oznacza to jednak wdrożenia produkcyjnego bez konfiguracji. Nadal trzeba zaprojektować dostęp do danych, uprawnienia, zakres użytkowników, monitoring, zasady aktualizacji i proces zatwierdzania przez administratora. Największa zmiana polega na tym, że zespół nie musi od początku budować własnej aplikacji pośredniczącej tylko po to, aby agent pojawił się w Copilot i Teams.

Co dokładnie zmienił Microsoft

Do tej pory zespoły tworzące bardziej zaawansowanych agentów w Foundry często musiały budować dodatkową aplikację lub warstwę proxy, przygotowywać manifest Teams, rejestrować usługę, konfigurować kanały i samodzielnie składać proces dystrybucji. Nadal można użyć Microsoft 365 Agents Toolkit, gdy potrzebna jest pełna kontrola, własne SSO, rozbudowane debugowanie albo wiele środowisk. Dla prostszego wdrożenia portal Foundry wykonuje jednak dużą część tej pracy automatycznie.

Podczas publikowania portal:

1. sprawdza nazwę, opis, wersję i inne właściwości agenta,
2. tworzy lub wykorzystuje zasób Azure Bot Service,
3. przygotowuje pakiet manifestu aplikacji dla Teams i Microsoft 365,
4. włącza protokół potrzebny do wymiany wiadomości,
5. ustawia sposób autoryzacji zgodny z wybranym zakresem,
6. przesyła agenta do katalogów Microsoft 365 Copilot i Teams.

Efektem nie jest kopia całego agenta uruchomiona wewnątrz aplikacji Office. Microsoft 365 otrzymuje kontrolowany kanał dostępu do stabilnego punktu końcowego działającego w Foundry. To ważne, ponieważ logika, modele i narzędzia nadal pozostają po stronie środowiska, w którym agent został zbudowany.

Gdzie pracownik znajdzie opublikowanego agenta

Agent może pojawić się w Microsoft 365 Copilot i Microsoft Teams. Przy dystrybucji organizacyjnej, po zatwierdzeniu przez administratora, trafia do kolekcji „Built by your org” w Agent Store. Sam Agent Store jest dostępny w środowisku Microsoft 365, między innymi z poziomu Teams oraz aplikacji takich jak Outlook, Word, Excel i PowerPoint.

Widoczność zależy od wybranego zakresu:

Publikacja dla organizacji nie omija kontroli IT. Żądanie trafia do centrum administracyjnego Microsoft 365, gdzie administrator może sprawdzić informacje o agencie, jego możliwościach i dostępie do danych. Dopiero po akceptacji agent staje się dostępny zgodnie z politykami aplikacji obowiązującymi w tenancie.

Co oznacza stabilny punkt końcowy

Jedną z praktycznych korzyści jest oddzielenie dystrybucji od wersji logiki. Użytkownik otwiera ten sam agent w Copilot lub Teams, ale właściciel może zmienić aktywną wersję w Foundry. Adres punktu końcowego pozostaje taki sam.

Można ustawić:

• automatyczne używanie najnowszej wersji,
• przypięcie ruchu do konkretnej wersji,
• kontrolowane przełączenie po testach,
• szybki powrót do poprzedniej wersji bez ponownej instalacji aplikacji.

To upraszcza utrzymanie, ale wymaga dyscypliny. Ustawienie „zawsze używaj najnowszej wersji” jest wygodne w środowisku testowym, natomiast w produkcji może niepotrzebnie wystawić użytkowników na niezweryfikowaną zmianę. Bezpieczniejszy model to jawne wskazanie wersji, test akceptacyjny i dopiero później przełączenie ruchu.

Czego bezpośrednia publikacja nie rozwiązuje

Najczęstszy błąd polega na założeniu, że po kliknięciu „Publish” agent automatycznie otrzyma bezpieczny dostęp do poczty, kalendarzy, SharePointa i danych firmowych. Publikacja zapewnia kanał komunikacyjny i dystrybucję. Nie projektuje procesu biznesowego ani modelu uprawnień.

Osobno trzeba rozwiązać:

• źródła wiedzy i sposób odświeżania danych,
• dostęp do Microsoft Graph, SharePoint, systemów zewnętrznych i baz danych,
• działanie w kontekście użytkownika albo tożsamości aplikacyjnej,
• ograniczenie dostępu do konkretnych witryn, skrzynek i rekordów,
• rejestrowanie działań oraz obsługę błędów,
• kontrolę operacji zmieniających dane,
• retencję rozmów i informacji przetwarzanych przez agenta,
• koszty modeli, narzędzi i wykorzystania danych Microsoft 365.

W bardziej wymagających scenariuszach nadal potrzebna będzie własna warstwa zbudowana przy użyciu Agents Toolkit. Microsoft wskazuje ten wariant dla rozwiązań wymagających niestandardowej logiki, SSO, kontrolowanej infrastruktury, wielu środowisk lub zaawansowanego debugowania.

Wymagania przed pierwszą publikacją

Jeżeli projekt wyłącza publiczny dostęp sieciowy, przycisk publikacji w portalu nie jest dostępny w standardowym trybie. Microsoft udostępnia wtedy przepływ REST API i dodatkowe kroki sieciowe dla agenta działającego za prywatnym punktem końcowym. To dobry przykład różnicy między szybkim pilotem a wdrożeniem w środowisku z restrykcyjną architekturą bezpieczeństwa.

Praktyczne scenariusze dla Microsoft 365

Agent do obsługi skrzynki procesowej

Agent może analizować wiadomości przychodzące do skrzynki współdzielonej, rozpoznawać temat, pobierać dane z załączników i przygotowywać propozycję dalszego działania. Operacje takie jak wysłanie odpowiedzi, zmiana rekordu lub uruchomienie procesu powinny mieć określony poziom kontroli człowieka.

Przykładowy przepływ:

Outlook → klasyfikacja AI → zapis do SharePoint → powiadomienie w Teams → akceptacja operatora

Ten sam szablon można dostosować do reklamacji, zamówień, zapytań ofertowych, obsługi dostawców albo zgłoszeń IT.

Asystent wiedzy dla SharePoint

Agent odpowiada na pytania na podstawie zatwierdzonych procedur, instrukcji i dokumentów. Wdrożenie powinno uwzględniać uprawnienia użytkownika, datę aktualizacji źródeł oraz wskazywanie dokumentu, na którym oparto odpowiedź. Samo podłączenie dużej biblioteki bez porządku informacyjnego zwykle pogarsza jakość.

Agent operacyjny dla Exchange Online i Microsoft 365

Zespół IT może używać agenta do zebrania danych diagnostycznych, wskazania właściwej procedury i przygotowania komend do zatwierdzenia. Agent nie powinien samodzielnie wykonywać ryzykownych zmian administracyjnych bez kontroli, zwłaszcza w sprawach retencji, transportu poczty, uprawnień i usuwania danych.

Agent do dokumentów

Połączenie Foundry z procesem ekstrakcji dokumentów pozwala przyjmować pliki, rozpoznawać typ dokumentu, wydobywać pola, sprawdzać reguły i kierować wyjątki do operatora. Microsoft 365 może być wtedy interfejsem użytkownika, a właściwy proces działa jako kontrolowany backend.

Minimalny plan pilotażu

1. Wybierz jeden proces

Najlepszy pilot ma jasne wejście i mierzalny wynik. Dobry przykład to klasyfikacja wiadomości z jednej skrzynki, wyszukiwanie odpowiedzi w jednej bibliotece SharePoint albo przygotowanie podsumowania zgłoszenia.

2. Ogranicz dane i użytkowników

Na początku użyj małej grupy testowej, osobnego źródła danych i minimalnych uprawnień. Nie publikuj pierwszej wersji całej organizacji tylko dlatego, że portal to umożliwia.

3. Ustal granice działania

Zapisz, co agent może wykonać sam, co może jedynie zasugerować, a co zawsze wymaga potwierdzenia człowieka. Szczególnie ważne są działania wysyłające wiadomości, modyfikujące pliki, tworzące rekordy i uruchamiające procesy finansowe.

4. Przygotuj testy

Sprawdź poprawne pytania, niepełne dane, brak dostępu, błędne załączniki, sprzeczne źródła, awarię narzędzia, przekroczenie limitu i próbę wykonania niedozwolonej operacji.

5. Opublikuj tylko dla autora

Najpierw zweryfikuj działanie w Microsoft 365 Copilot i Teams bez uruchamiania procesu zatwierdzania dla całej organizacji. Sprawdź różnice między zachowaniem w portalu Foundry a zachowaniem w docelowym kanale.

6. Przeprowadź kontrolowany pilot

Dodaj małą grupę użytkowników, zbieraj błędne odpowiedzi i mierz efekt procesu. Minimum to czas obsługi, udział spraw zakończonych bez ręcznej pracy, liczba wyjątków i koszt na zadanie.

7. Dopiero potem zgłoś wdrożenie organizacyjne

Do wniosku dla administratora dołącz opis celu, właściciela, źródeł danych, uprawnień, monitoringu, retencji, procedury wyłączenia i planu aktualizacji. To skraca ocenę i zmniejsza ryzyko odrzucenia.

Bezpieczeństwo i governance

Microsoft ostrzega, że część danych związanych z publikacją oraz korzystaniem z agenta jest przetwarzana przez Microsoft 365 i Teams zgodnie z zasadami tych usług. Organizacja musi ocenić, czy taki przepływ odpowiada jej wymaganiom dotyczącym zgodności i rezydencji danych.

Przed wdrożeniem produkcyjnym sprawdź:

• kto jest właścicielem biznesowym i technicznym,
• gdzie agent zapisuje dane i logi,
• które systemy oraz rekordy może odczytywać,
• jakie działania może wykonywać,
• jak wygląda nadawanie i odbieranie dostępu,
• jak długo są przechowywane rozmowy i dane pomocnicze,
• jak wykrywane są nietypowe działania,
• jak wyłączyć agenta i odciąć jego uprawnienia,
• kto zatwierdza nową wersję.

Od 1 lipca 2026 Microsoft przeniósł część zaawansowanych funkcji bezpieczeństwa agentów Foundry i Copilot Studio do modelu Microsoft Agent 365. Organizacje korzystające z agent-level discovery, posture management i threat detection powinny sprawdzić wymagania licencyjne oraz aktualne miejsce konfiguracji polityk. Sama możliwość opublikowania agenta nie zastępuje narzędzi potrzebnych do jego późniejszego nadzoru.

Foundry, Copilot Studio czy Agents Toolkit

Bezpośrednia publikacja z Foundry wypełnia lukę między prototypem a dostępnością dla użytkowników. Nie usuwa potrzeby architektury, ale wyraźnie skraca techniczny etap przygotowania kanału Microsoft 365.

Co to zmienia dla firm i dostawców usług

Największą wartością nie jest sam przycisk publikacji. Jest nią możliwość przygotowania powtarzalnej usługi obejmującej cały cykl życia agenta:

1. wybór procesu i policzenie oczekiwanego efektu,
2. budowę lub dostosowanie agenta w Foundry,
3. integrację z Microsoft 365 i systemami biznesowymi,
4. przegląd uprawnień i zgodności,
5. publikację oraz zatwierdzenie administracyjne,
6. szkolenie użytkowników,
7. dokumentację operacyjną, monitoring i aktualizacje.

Dla organizacji korzystających już z Exchange Online, SharePoint i Teams naturalnym punktem startowym są procesy, które dziś opierają się na ręcznym przenoszeniu informacji między pocztą, dokumentami i kanałami zespołów.

Podsumowanie

Microsoft Foundry pozwala szybciej przenieść własnego agenta do Microsoft 365 Copilot i Teams. Portal przygotowuje warstwę komunikacyjną, manifest i proces dystrybucji, a stabilny punkt końcowy ułatwia późniejsze aktualizowanie logiki.

Nie jest to jednak skrót omijający bezpieczeństwo i administrację. Dostęp do danych, uprawnienia, kontrola działań, monitoring i zatwierdzenie organizacyjne nadal wymagają projektu. Najlepsze wdrożenie zaczyna się od małego procesu, ograniczonego pilota i jasnych kryteriów przejścia do produkcji.

Jeżeli chcesz sprawdzić, który proces w Outlooku, SharePoint lub Teams nadaje się na pierwszego agenta, zacznij od krótkiego audytu przepływu pracy. Zakres techniczny i plan pilotażu można przygotować w ramach automatyzacji Microsoft 365.

FAQ

Czy publikacja z Foundry naprawdę nie wymaga kodowania?

Może nie wymagać tworzenia własnej aplikacji pośredniczącej, manifestu i podstawowej integracji kanału. Sam agent, jego narzędzia, dostęp do danych i logika procesu nadal mogą wymagać pracy programistycznej.

Czy agent od razu pojawi się wszystkim pracownikom?

Nie. Publikacja tylko dla autora jest dostępna bez zatwierdzenia. Udostępnienie organizacyjne wymaga akceptacji administratora Microsoft 365 i podlega politykom aplikacji w tenancie.

Czy agent automatycznie uzyska dostęp do SharePoint i Outlooka?

Nie. Trzeba osobno skonfigurować źródła danych, integracje i uprawnienia. Dostęp powinien być ograniczony do minimum potrzebnego dla konkretnego procesu.

Czy nową wersję trzeba ponownie publikować do Teams?

Nie zawsze. Microsoft używa stabilnego punktu końcowego, dlatego można zmienić aktywną wersję w Foundry bez ponownego publikowania aplikacji. Zmiany nazwy, opisu i innych danych widocznych dla użytkownika wymagają aktualizacji właściwości publikacji.

Czy funkcja działa z prywatnym endpointem?

Tak, ale nie przez standardowy przycisk w portalu. Dla projektu z wyłączonym publicznym dostępem sieciowym Microsoft opisuje publikowanie przez REST API oraz dodatkową konfigurację ruchu sieciowego.

Źródła

• Microsoft Learn: Publish agents to Microsoft 365 Copilot and Microsoft Teams
• Microsoft Learn: Custom engine agents for Microsoft 365
• Microsoft Learn: Agent Store in Microsoft 365 Copilot
• Microsoft Learn: Publish agents by using the REST API and VNet guidance
• Microsoft Learn: Transition agent security capabilities to Microsoft Agent 365

Chcesz sprawdzić pierwszy proces?

Wybierz jeden przepływ w Outlooku, SharePoint lub Teams. Przygotujemy zakres pilota, model uprawnień, kryteria sukcesu i dokumentację operacyjną.

Sprawdź automatyzacje Microsoft 365

Powiązane materiały

Microsoft MAI i Copilot: nowe KPI wdrożeń AI w M365Microsoft rozwija strategię multi-model AI w Copilot Researcher. Sprawdzamy, jak połączyć MAI, Critique Council i benchmark DRACO w praktyczny model KPI jakości, kosztu i ryzyka dla firm pracujących w Microsoft 365.Agent-to-agent w enterprise: kontrola, skala i zgodnośćAgent-to-agent przestało być futurystycznym hasłem. To teraz temat operacyjny dla firm, które chcą skrócić czas realizacji procesów, ale nie chcą oddawać kontroli nad danymi, zgodnością i kosztami. W praktyce pytanie nie brzmi już „czy”, tylko „jak”: jak połączyć Copilota, Joule, workflow w Power Platform i własne narzędzia tak, żeby automatyzacja działała stabilnie pod obciążeniem, była …System operacyjny firmy w Microsoft 365: workflow i AIJak zbudować system operacyjny firmy w Microsoft 365 i połączyć workflow z AI bez dokładania chaosu. Praktyczny przewodnik dla firm, które chcą uporządkować procesy, dokumenty i decyzje.