Co to jest Microsoft Foundry? Poradnik dla firm

Microsoft Foundry to platforma Microsoftu do budowy aplikacji i agentów AI. W jednym miejscu masz katalog modeli, usługę agentów, narzędzia, ocenę jakości i nadzór nad działaniem. Wcześniej nazywała się Azure AI Studio, potem Azure AI Foundry. Sama platforma nie ma opłaty — płacisz za każdą usługę, którą w niej uruchomisz, według jej cennika. Moim zdaniem Foundry ma sens, gdy firma buduje własną aplikację albo agenta na Azure. Jak przygotować samo środowisko chmury, opisuje poradnik o Microsoft Azure dla firm. Zanim utworzysz pierwszy zasób, ustal jedno zadanie, osobę odpowiedzialną, zestaw testów i to, kto pilnuje danych, uprawnień i rachunku.

Czym jest Microsoft Foundry dziś

Foundry to jedno miejsce do budowy i nadzoru aplikacji oraz agentów AI na Azure. Przegląd Microsoft Foundry w dokumentacji wymienia agentów, katalog modeli, narzędzia i wiedzę, obserwowalność, zarządzanie i bezpieczeństwo. Szerszy obraz, gdzie Foundry mieści się w całej ofercie, daje przegląd Microsoft AI dla firm.

Skąd trzy nazwy

Kolejność: Azure AI Studio → Azure AI Foundry → Microsoft Foundry. Dokumentacja używa już tylko ostatniej nazwy. Azure AI Services to dziś Foundry Tools, a role Azure AI User i pokrewne to Foundry User, Foundry Owner, Foundry Account Owner i Foundry Project Manager, z tymi samymi uprawnieniami. Nowe nazwy dopiero wchodzą, więc w portalu trafisz jeszcze na stare (role w Foundry).

Wniosek praktyczny: instrukcja albo oferta ze starą nazwą może opisywać inny model zasobów. Zapytaj, którego dotyczy.

Co jest w środku

• Agenci. Prompt agents konfigurowane instrukcją, modelem i narzędziami, ich wersja głosowa oraz hosted agents, które uruchamiają Twój własny kod.
• Katalog modeli. Modele Microsoftu, OpenAI, Anthropic, Meta i innych vendorów. Dokumentacja mówi o ponad 10 000 modeli, strona cennika o 11 000+. Liczba rośnie szybciej, niż ktokolwiek zdąży je przetestować.
• Narzędzia i wiedza. Foundry Toolbox, pamięć, wyszukiwanie i Foundry IQ.
• Obserwowalność i zarządzanie. Tracing, ewaluacje, monitoring, guardrails i kontrola dostępu.

Model generuje wynik. Aplikacja dodaje sposób użycia: kontekst, prezentację odpowiedzi, obsługę błędów. Agent dodatkowo wybiera narzędzia w zakresie, który zaprojektujesz. Każdy poziom sprawdzasz osobno. Agent konfigurowany wymaga mniej kodu. Hosted agent daje więcej swobody, ale odpowiadasz za własny kod i jego zależności.

GA i preview: sprawdzaj element, nie platformę

Foundry Agent Service jest dostępny ogólnie (GA), ale nie wszystko w platformie ma ten status. Tabela poniżej pochodzi z listy gotowości funkcji Foundry, stan na 5.10.2026. Microsoft odświeża tę stronę mniej więcej co 90 dni, więc przed decyzją sprawdź ją ponownie.

Funkcja	Status
Agenci (rdzeń Agent Service)	GA
Modele z katalogu	GA
Ewaluacje	GA, część ewaluatorów w preview
Red teaming	GA
Tracing (agenci prompt i hosted)	GA
Toolboxes	GA
Fine-tuning	GA
Guardrails	dla modeli GA, dla agentów preview
Monitoring	preview
Pamięć (Memory)	preview
Foundry IQ	częściowo GA: API GA, dostęp z portalu w preview
Operate, AI Gateway	preview

Uwaga na Workflows. Są w preview, a Microsoft wycofuje je 1 grudnia 2026 i dla nowych projektów zaleca Microsoft Agent Framework.

Etykieta preview jest jak „prawie skończyłem” w raporcie agenta kodującego. Brzmi dobrze, ale nie podpisujesz na tej podstawie odbioru.

Projekt Foundry czy projekt na hubie

Projekt Foundry jest podzasobem zasobu Foundry. Projekt na hubie to starszy model z portalu Foundry (classic). Microsoft w większości przypadków zaleca projekt Foundry, bo tylko w nim są agenci GA i nowe możliwości modeli (architektura Foundry).

Nowy portal nie obsługuje projektów na hubie ani samodzielnych zasobów Azure OpenAI. Do nich służy portal classic. Prompt flow działa tylko w projektach na hubie, więc nie jest ścieżką dla nowego projektu.

Masz rozwiązanie w classic? Zmiana nazwy nie jest powodem do migracji. Najpierw zrób inwentaryzację: wdrożenia modeli, połączenia, indeksy, tożsamości, ustawienia guardrails (dawniej filtrów treści), Application Insights, sieci prywatne i kod oparty na konkretnych pakietach SDK. Dopiero potem oceń, co zyskasz.

Przy ofercie od wykonawcy poproś o wskazanie wariantu: projekt Foundry czy hub, i status każdej funkcji, na której opiera rozwiązanie.

Kiedy firma potrzebuje Foundry, a kiedy nie

To mój wniosek z zakresu platformy, nie zalecenie Microsoftu.

Potrzeba	Czy Foundry	Co zamiast albo obok
Własna aplikacja lub agent na firmowych danych	tak	—
Gotowa funkcja: rozpoznanie dokumentu, mowy, języka	raczej nie cała platforma	gotowe usługi Foundry Tools (dawniej Azure AI Services)
Sam wybór, jak udostępnić model	częściowo	porównanie MaaS z innymi sposobami wdrożenia modelu
Asystent do pracy biurowej bez własnego kodu	nie	to inna decyzja zakupowa, poza Foundry

Nie każde zadanie potrzebuje agenta. Jeśli pracownik wkleja krótki tekst i chce uporządkowanego streszczenia, prosty przebieg wystarczy. Samodzielny dobór narzędzi dodawaj wtedy, gdy rozwiązuje rozpoznaną potrzebę, a firma umie skontrolować wynik.

Jak zaplanować pierwszy projekt

Przykład przewodni: aplikacja pomaga handlowcom przygotować odpowiedź na zapytanie ofertowe. Wyszukuje zatwierdzone materiały i tworzy szkic. Handlowiec sprawdza warunki i zatwierdza wysłanie.

Zacznij od zadania, nie od katalogu modeli

Zapisz hipotezę w jednym zdaniu: „użytkownik podejmuje decyzję X na podstawie danych Y, a aplikacja ma poprawić miarę Z”. W przykładzie miarą będzie zgodność szkicu z aktualnymi warunkami i czas od otwarcia zapytania do zatwierdzenia odpowiedzi.

Potem zbuduj zestaw testowy. To nie jest zbiór treningowy. To kontrakt odbioru, na którym porównasz modele, instrukcje i kolejne wersje.

Przypadek testowy	Co powinien zrobić system	Co oznacza błąd
Odpowiedź jest w aktualnym materiale	przygotować zgodny szkic	zmiana warunku albo pominięcie wyjątku
Brak potrzebnej informacji	wskazać brak i drogę wyjaśnienia	wymyślona cena albo termin
Sprzeczne wersje dokumentu	ujawnić konflikt albo zastosować zatwierdzoną regułę	przypadkowy wybór starej wersji
Żądanie poza zakresem roli	odmówić	użycie szerszych uprawnień niż trzeba
Nieudane wywołanie narzędzia	podać rzeczywisty stan	potwierdzenie czynności, której nie było

Część przypadków odłóż do niezależnego odbioru. Model, który zna odpowiedzi na wszystkie pytania z zestawu testowego, mógł się po prostu nauczyć zestawu.

Model wybieraj dopiero na tym zestawie: jakość, region, opóźnienie, przepustowość, rozliczenie, warunki danych. Publiczny ranking nie zna Twoich zapytań ofertowych.

Minimum na start: jeden zasób, jeden projekt

Hierarchia wygląda tak. Zasób Foundry odpowiada za sieć, bezpieczeństwo i wdrożenia modeli. Projekty są granicą pracy zespołu: agenci, ewaluacje, pliki. Storage, Key Vault i AI Search to osobne zasoby Azure z własnym zarządzaniem. Dla jednego dewelopera Microsoft zaleca jeden zasób z jednym projektem (architektura Foundry).

Plan wdrożenia Foundry mówi: współdzielenie zasobu do eksploracji, osobny zasób na każdą granicę obciążenia w produkcji. Przed startem ustal subskrypcję i grupy zasobów, wymagania sieci i szyfrowania, plan regionów i listę funkcji, których użyjesz.

Pierwszy projekt sprawdza jedną hipotezę najmniejszym zestawem usług:

Warstwa	Pytanie właściciela	Minimum na start	Czego nie dodawać	Dowód gotowości
Wejście	kto i po co uruchamia zadanie?	uwierzytelnienie użytkownika	publicznych endpointów „na chwilę”	identyfikator każdego żądania
Dane	które materiały wolno użyć?	jedno kontrolowane źródło	wszystkich repozytoriów firmy	filtr uprawnień i rejestr źródeł
Model lub agent	czy jakość wystarcza?	jeden model, zestaw testowy	wielu agentów i rozbudowanej pamięci	wynik na wersjonowanym zestawie
Narzędzia	jakie skutki może wywołać?	jedno wąskie narzędzie	ogólnego dostępu do API	lista operacji, walidacja, limity
Monitoring i utrzymanie	kto zauważy pogorszenie?	ewaluacja, ślady, metryki	stosu analitycznego bez odbiorcy	próg, alarm, właściciel i zastępstwo

Jeśli agent pobiera dokument albo wywołuje narzędzie, warstwa wykonawcza musi znać uprawnienia użytkownika. Instrukcja „pokazuj tylko uprawnione dane” w prompcie nie jest autoryzacją. Jest prośbą.

Role i dostęp

Według opisu ról w Foundry:

• Foundry User na zasobie Foundry dla użytkownika i dla tożsamości zarządzanej projektu.
• Cognitive Services Usages Reader na subskrypcji, jeśli użytkownik ma widzieć limit (quota).
• Owner albo inna rola z prawem przypisywania ról, żeby nadawać role.
• Foundry Agent Consumer, jeśli ktoś ma tylko wywoływać agentów.

Owner albo Contributor na subskrypcji nie wystarcza do pracy z agentem. Właściciel wszystkiego, a agent i tak go nie słucha.

Region i miejsce przetwarzania danych

O miejscu przetwarzania promptów i odpowiedzi decyduje typ wdrożenia modelu (prywatność danych w Foundry):

• Standard — w geografii, którą wskażesz.
• Data Zone — w obrębie strefy; dla zasobu w UE w dowolnym kraju UE.
• Global — w dowolnej geografii, w której dany model działa.

Pliki, wektory i historia zostają w wyznaczonej geografii. Automatycznego przełączania regionów po awarii nie ma.

Z Polską dokumentacja sama sobie przeczy. Lista regionów dla projektów Foundry nie zawiera Poland Central. Tabela regionów Agent Service pokazuje Poland Central jako dostępny dla agentów. Microsoft sam zaleca, żeby przed wyborem regionu sprawdzić dostępność modelu, limit i usługi zależne, i potwierdzić to w portalu dla tej samej subskrypcji i tenanta. Zrób to, zanim komuś obiecasz „dane w Polsce”.

Dane i źródła wiedzy

Nie podłączaj na start całego SharePointa. Wybierz jedną kolekcję o znanym właścicielu i jednolitych zasadach dostępu. Każdy dokument potrzebuje właściciela, daty obowiązywania i zakresu dostępu. Archiwalną instrukcję bez statusu model użyje z tą samą pewnością co aktualnej. Metadane są tu logiką biznesową.

Wyszukiwanie oceniaj osobno od generowania: najpierw, czy właściwy fragment trafił do wyników, potem, czy model dobrze go użył. Inaczej zespół poprawia prompt, a winny jest indeks. Dostęp do źródła i poprawność odpowiedzi też odbierasz osobno. Gdy agent ma odpowiadać z wielu zatwierdzonych dokumentów, sprawdź Foundry IQ jako zarządzaną bazę wiedzy dla agentów.

Ocena jakości jako bramka

Ewaluacje w Foundry są GA, część ewaluatorów jest w preview. Bramka ma dwa poziomy. Pierwszy to miary platformy i bezpieczeństwo. Drugi to reguły Twojej dziedziny: czy są wymagane pola, czy termin zgadza się z umową, czy wyjątek trafił do człowieka.

Przykład syntetyczny, nie wynik projektu: na 50 pytaniach dostajesz 44 poprawne odpowiedzi, 4 uzasadnione odmowy i 2 błędy. To nie jest „96% skuteczności”. Rozdziel odpowiedzi, odmowy i błędy i sprawdź skutek każdego błędu. Jedna zmyślona gwarancja w ofercie może zatrzymać wdrożenie mimo dobrego wyniku reszty.

Automatyczny oceniający bez odpowiedzi wzorcowej bywa równie pewny siebie co błędny, więc próbkę wyników przegląda człowiek. Dodaj test wieloetapowej rozmowy: użytkownik zmienia zakres albo odwołuje decyzję, a system ma działać na aktualnym ustaleniu, nie na tym sprzed trzech wiadomości.

Cztery etapy pierwszego projektu

To moja metoda robocza, nie procedura Microsoftu.

Etap	Co robisz	Decyzja na końcu
1. Ustal	zadanie, właściciel, użytkownicy, dane, miara, karta ryzyka, zestaw testowy	rozwijać, poprawić dane, zmienić model albo zatrzymać
2. Zbuduj minimum	projekt, tożsamości, jeden model, jedno źródło, bez działań zapisujących	jw.
3. Sprawdź	ewaluacja, ślady z kontrolowaną treścią, testy regresji, porównanie dwóch wariantów na tym samym zestawie	jw.
4. Uruchom wąsko	jedno wąskie narzędzie z walidacją, zatwierdzenie człowieka przy skutku wysokiego ryzyka, ograniczona grupa użytkowników	jw.; szersze uruchomienie dopiero po liście przed produkcją

„Zatrzymać” to normalny wynik. Wartość pilotażu to także szybki dowód, że dane albo ekonomika zadania nie uzasadniają dalszej inwestycji.

Ile kosztuje Microsoft Foundry

Strona cennika Foundry (odczyt 5.10.2026) mówi wprost: za samo używanie i eksplorację platformy nie ma opłaty, a funkcje, z których korzystasz, są rozliczane według ich zwykłych stawek. Strona nie podaje ani jednej kwoty, tylko odsyła do cenników składników. Uczciwe do bólu: nic nie kosztuje, dopóki czegoś nie uruchomisz.

Foundry nie ma pozycji w kalkulatorze cen Azure, więc szacujesz usługi składowe, na przykład AI Search, Speech czy Language (zarządzanie kosztami Foundry).

Co trzeba wiedzieć o rozliczeniu modeli:

• Zależnie od typu wdrożenia płacisz za tokeny (pay-as-you-go), godzinowo za zarezerwowaną przepustowość (provisioned) albo za przetwarzanie wsadowe (batch).
• Typ Developer służy tylko do oceny modeli fine-tuned: 24 godziny, bez SLA.
• Model fine-tuned ma opłatę za hosting naliczaną także wtedy, gdy nikt go nie używa.
• Modele innych vendorów kupowane przez Azure Marketplace są rozliczane osobno i nie zapłacisz za nie środkami Azure Prepayment. Modele sprzedawane przez Azure — tak.
• Rozliczanie kosztów po projektach (tag project) działa dla modeli sprzedawanych przez Azure i jest w preview.

Na stronie cennika są też Foundry Local i plan przedpłaty dla agentów (Agent Commit Units). Warunki sprawdź bezpośrednio tam.

Koszt to więcej niż tokeny

Budżet obejmuje wywołania modeli, embeddingi, indeksy, przechowywanie, sieć, telemetrię i pracę zespołu. Ustaw budżet i alarmy przed szerokim testem, nie po pierwszej fakturze. W pilocie ogranicz liczbę kroków agenta i rozmiar kontekstu.

Najlepsza miara dla właściciela procesu to koszt sprawy zakończonej wynikiem, który spełnia wymagania. Umowny przykład: wywołanie wariantu A kosztuje połowę tego co B, ale szkic z A wymaga 8 minut kontroli, a z B 3 minut. Jeśli pięć minut pracy handlowca kosztuje więcej niż różnica w cenie wywołania, droższy wariant jest tańszy dla firmy. To model do policzenia na własnych danych, nie cennik Foundry.

Licz też ponowienia i porzucone próby, a koszt budowy i utrzymania zapisz osobno. Grupuj zadania według trudności i skutku błędu. Mierz czas do zatwierdzenia wyniku, nie czas generowania tekstu.

Kto za co odpowiada: Microsoft, firma, wykonawca

Microsoft nie ma jednego zdania o współodpowiedzialności dla Foundry. Podział niżej to mój wniosek z dokumentacji.

Microsoft daje platformę i narzędzia: guardrails, red teaming, Microsoft Entra, RBAC, sieć prywatną i Azure Policy. Zalecenia opiera na Microsoft Responsible AI Standard w trzech krokach: Discover, Protect, Govern (odpowiedzialne użycie AI w Foundry). Dla modeli sprzedawanych przez Azure prompty, odpowiedzi i dane treningowe nie są dostępne innym klientom ani vendorom modeli i nie trenują modeli bez Twojej zgody. Przetwarzanie obejmuje umowa DPA Microsoftu. Microsoft może przejrzeć próbkę promptów w ramach monitorowania nadużyć, a dla wdrożeń w EOG recenzenci są w EOG (prywatność danych w Foundry). Modele innych vendorów kupowane przez Azure Marketplace mają własne warunki danych. Sprawdź je dla każdego modelu przed wdrożeniem.

Firma odpowiada za konfigurację, uprawnienia, dane źródłowe, treść promptów oraz Storage, Key Vault i AI Search. Każdy obszar ma imiennego właściciela.

Wykonawca, czyli partner wdrożeniowy, odpowiada w zakresie umowy. Konto i zasoby są po stronie firmy, nie jednej osoby. Zastępstwo obejmuje też wiedzę potrzebną do zrozumienia błędu. To nie jest porada prawna — umowę i obowiązki z RODO i AI Act oceni prawnik.

Guardrails nie sprawdzą, czy odpowiedź jest prawdziwa

Guardrails (dawniej content filters) działają na wejściu, na wyjściu, a w preview także przy wywołaniach i odpowiedziach narzędzi (architektura Foundry). Filtrują szkodliwe treści. Przepuszczą za to uprzejmie sformułowaną, całkowicie zmyśloną gwarancję.

Trzymaj więc osobne próby dla ochrony, uprawnień i poprawności biznesowej. Przygotuj dokument z wstrzykniętym poleceniem sprzecznym z zadaniem aplikacji: system ma go potraktować jako treść, nie rozkaz. Testuj na sztucznych danych, wynik zapisz z wersją konfiguracji.

Nie dawaj wszystkim roli właściciela. Dev, test i produkcja mają osobne zasoby i tożsamości. Wyjątek z demonstracji dostaje właściciela i datę wygaśnięcia. Agent ma mniej praw niż aplikacja. Przy skutku finansowym, prawnym albo dla klienta człowiek zatwierdza przed skutkiem, nie po nim.

Ślady mogą zawierać dane klientów

Tracing jest GA dla agentów prompt i hosted. Ślad opisuje przebieg rozmowy, więc może zawierać to, co wpisał użytkownik, i to, co odpowiedział model. Obserwowalność ma przez to własny model zagrożeń.

Przed włączeniem ustal, co wolno logować, kto czyta ślady, jak długo je trzymasz i jak obsłużysz żądanie usunięcia. Maskuj sekrety. Alert musi mieć właściciela. Dashboard bez właściciela to tylko bardzo ładne archiwum.

Lista przed produkcją

Obszar	Ustalenie	Próba odbiorowa
Wersja	znany model, instrukcje i konfiguracja narzędzi	odtworzenie wyniku dla wskazanej wersji
Zmiana	test przed udostępnieniem	porównanie starego i nowego wariantu
Błąd	właściciel i sposób zgłoszenia	przekazanie złej odpowiedzi do analizy
Awaria	czytelny komunikat i droga zastępcza	dokończenie sprawy bez aplikacji
Dostęp	role i termin przeglądu	próba użytkownikiem z ograniczonym zakresem
Koszt	odbiorca sygnału i reguła reakcji	wyjaśnienie nagłego wzrostu użycia

W pilocie przećwicz wycofanie dokumentu ze źródeł i zmianę narzędzia. Poproś wykonawcę o pokazanie zmiany wymagania, na przykład nowego typu zapytania ofertowego, i powrotu do poprzedniej wersji. Taka próba powie o utrzymaniu więcej niż slajd z listą funkcji.

Mapa wpisów o Foundry

Wpisy są ułożone według decyzji, które podejmujesz w projekcie: jaka usługa, jaki model i skąd model weźmie wiedzę.

• Usługi i sposób wdrożenia — gotowe usługi, model przez API i migracja botów: Azure AI Services: jak wybrać usługę · MaaS: wybór wdrożenia modelu · Azure Bot Service po Bot Framework
• Modele w katalogu — wybór i migracja modeli, także małych modeli Microsoftu: Modele generatywne AI w Azure · GPT-4o: zastosowania i migracja · OpenAI o1: rozumowanie i migracja · Modele MAI Microsoftu · Fara 1.5: agent w przeglądarce · MagenticBrain 14B: dyspozytor agentów · OptiMind: plan produkcji · Narrow AI: wąska AI w firmie
• Wiedza i dostrajanie — wyszukiwanie w dokumentach, baza wiedzy dla agentów i trening modelu: Azure AI Search: klasyczny i agentowy RAG · Foundry IQ: baza wiedzy dla agentów · RAG w Azure: dane, chunking i ewaluacja · RAG, fine-tuning czy RAFT · RAFT: trening dla domenowego RAG · Fine-tuning: kiedy warto

Co zrobić w poniedziałek

Zapisz zdanie hipotezy: „użytkownik podejmuje decyzję X na podstawie danych Y, a aplikacja ma poprawić miarę Z”. Zbierz rzeczywiste, zanonimizowane przykłady z opisem oczekiwanego wyniku. Narysuj pięć warstw z tabeli minimum i przypisz każdej właściciela. Sprawdź w portalu region, model i limit dla swojej subskrypcji. Dopiero wtedy utwórz zasób.

Najtrudniejsza część nie dzieje się w portalu. To rozmowa z firmą o tym, co ma powstać, kto za to odpowiada i kiedy projekt zatrzymać.