Azure Poland Day to konferencja Microsoft Azure, która odbyła się 12 marca 2026 roku w Warszawie. Sesje podzielone były na 3 ścieżki tematyczne. Poniżej krótkie podsumowanie wykładów, które mnie najbardziej zainteresowały.

Unleashing the Forensics Skillset: Techniques for Extraction and Analysis of the Evidence - Paula Januszkiewicz Link to heading

Paula Januszkiewicz z CQURE omówiła techniki pozyskiwania i analizowania dowodów cyfrowych. Kluczowe zagadnienia:

  • Strategie ataku — skróty (pliki LNK) jako wektory ataku oraz techniki związane z NTLM (pass-the-hash, relay)
  • Threat hunting vs forensics — fundamentalna różnica między tymi podejściami: threat hunting jest proaktywny (szukamy zagrożeń zanim coś się stanie), natomiast forensics jest reaktywny (analizujemy ślady po incydencie)
  • CQURE App ID Resolver — narzędzie do identyfikowania aplikacji na podstawie ID, wraz z innymi narzędziami dostępnymi jako open source (renegade opensource)
  • Identity monitoring — monitorowanie tożsamości jako kluczowy element wykrywania zagrożeń

Linki:

Azure Local czyli Azure we własnej infrastrukturze - Marcin Reichman Link to heading

Marcin Reichman przedstawił Azure Local jako rozwiązanie pozwalające uruchamiać usługi Azure we własnej infrastrukturze. Kluczowe zagadnienia:

  • Azure Arc i serwery Dell AX — Azure Arc jako warstwa zarządzania dla serwerów on-premises, z certyfikowanym sprzętem Dell AX
  • Kategorie serwerów Azure Local:
    • Validated — sprzęt zwalidowany przez Microsoft
    • Integrated — sprzęt zintegrowany (gotowe rozwiązanie)
    • Premier — sprzęt najwyższej klasy
  • Azure Local OS — dedykowany system operacyjny dla węzłów klastra
  • Cennik — $10 za core klastra miesięcznie

Linki:

Microsoft Foundry: działa na demo, a w firmie? - Łukasz Kałużny Link to heading

Łukasz Kałużny omówił realia wdrażania Azure AI Foundry poza środowiskiem demo — w infrastrukturze produkcyjnej firm. Prezentacja skupiła się na ograniczeniach, które wychodzą dopiero przy rzeczywistym użyciu.

Typy wdrożeń modeli (Model Deployment) różnią się przede wszystkim tym, gdzie przetwarzane są dane:

  • Standard i Data zone — dane pozostają w określonym regionie lub strefie danych (np. UE), co jest kluczowe dla zgodności z RODO; dane nie opuszczają bloku geograficznego
  • Developer i Global — wdrożenia globalne z dostępem do szerszych możliwości modeli (w tym najnowszych), jednak dane mogą być przetwarzane w USA

Problemy przy wdrożeniu w VNet (sieci prywatnej):

  • klasyczny UI działa poprawnie, nowy UI nie działa
  • klasyczne tools dla agentów działają, nowi agenci nie działają

Chaos nazewniczy — na przestrzeni 1-2 lat produkt był wielokrotnie przemianowywany, co przełożyło się na niespójność w dokumentacji, API i SDK. Szukając materiałów online, warto weryfikować, czy odnoszą się do aktualnej wersji produktu.

Keep Architecture Simple, Sir: You Don’t Need Microservices Yet - Sebastian Nilsson Link to heading

Sebastian Nilsson przedstawił argumenty przeciwko przedwczesnemu przechodzeniu na mikroserwisy. Główne przesłanie nawiązywało do książki “Solving Imaginary Scaling Issues” — większość problemów ze skalowaniem, które próbujemy rozwiązać mikroserwisami, w rzeczywistości nie istnieje.

Local code vs code calling HTTP service through network — kluczowa różnica między wywołaniem lokalnym a wywołaniem przez sieć: sieć dodaje latencję, możliwość awarii i złożoność debugowania.

Ups & downs for microservices — mikroserwisy mają zarówno zalety, jak i poważne wady, które często są bagatelizowane na etapie decyzji architektonicznej.

Operational / deploy overhead — każdy mikroserwis wymaga osobnej infrastruktury:

  • app — osobna aplikacja do zarządzania
  • db — osobna baza danych
  • pipelines — osobne pipeline CI/CD
  • monitoring — osobny monitoring
  • infra — osobna infrastruktura

Start small and measure everything — zamiast od razu projektować pod skalę, zacznij od prostego rozwiązania i mierz wszystko, żeby podejmować decyzje na podstawie danych, nie założeń.

Modular monolith — rekomendowane podejście pośrednie: monolit podzielony na moduły z wyraźnymi granicami, który można łatwo rozłożyć na mikroserwisy w przyszłości, jeśli zajdzie taka potrzeba.

Linki:

One does not simply add AI to their apps: stop and Think 1st - Mike Martin Link to heading

Mike Martin omówił praktyczne aspekty wdrażania AI w aplikacjach, koncentrując się na odpowiedzialnym i przemyślanym podejściu.

APIM jako universal gateway — Azure API Management jako centralny punkt wejścia dla wszystkich żądań do modeli AI. Kluczowe możliwości APIM w kontekście AI:

  • Azure OpenAI token metric policy — śledzenie i kontrola zużycia tokenów bezpośrednio w APIM
  • Load balancer i circuit breaker — równoważenie obciążenia między endpointami i automatyczne wyłączanie niedostępnych backendów
  • Azure AI token limit policy — limitowanie liczby tokenów per użytkownik / aplikacja
  • Semantic caching — cache odpowiedzi oparty na podobieństwie semantycznym zapytań (z użyciem managed keys)

Fine tuning — dostrajanie modeli do konkretnych przypadków użycia.

NIST management — zarządzanie ryzykiem AI w oparciu o framework NIST.

Azure AI Foundry jako platforma do zarządzania bezpieczeństwem modeli:

  • ochrona przed prompt injection
  • Guardrail controls — mechanizmy ochronne
  • Evaluations — systematyczna ocena jakości i bezpieczeństwa modeli

Azure Landing Zone — właściwe fundamenty infrastruktury przed wdrożeniem AI.

AAA (Authentication, Authorization, Accounting) — podstawy bezpieczeństwa, które muszą być zapewnione.

Microsoft Entra Agent ID — tożsamość dla agentów AI w ekosystemie Microsoft.

Foundry Local ~ Windows AI Foundry — lokalne uruchamianie modeli AI na Windows.

Dev Proxy — narzędzie do testowania throttlingu i monitorowania podczas developmentu.

Azure AI Evaluators — narzędzia do oceny jakości odpowiedzi modeli AI.

Linki:

The Future of Deployments: AI-Powered Infrastructure Onboarding on Azure - Kamil Jakubik Link to heading

Kamil Jakubik przedstawił wizję przyszłości wdrożeń — IDP (Internal Developer Platform) zasilany przez AI, który automatyzuje onboarding infrastruktury na Azure.

Architektura IDP — platforma zbudowana z czterech warstw:

  • UI — interfejs dla deweloperów
  • AI Agent — warstwa inteligentna, która orchestruje całość
  • CI/CD — pipeline wdrożeniowy
  • Infra — warstwa infrastruktury

Agent AI komunikuje się ze wszystkimi komponentami:

  • Gen. AI platform (np. Azure AI Foundry) — model językowy jako mózg agenta
  • GitHub API — zarządzanie kodem i repozytoriami
  • SQL — dostęp do danych

N8N — narzędzie do automatyzacji workflow, użyte jako silnik orkiestracji przepływów między komponentami.

Linki:

Using of Microsoft AutoGen framework to build multiagent AI applications - Aleksandr Surkov Link to heading

Aleksandr Surkov omówił Microsoft AutoGen — Python framework do budowania aplikacji wieloagentowych.

Komponenty frameworka:

  • Agents — agenci realizujący zadania
  • Conversations — zarządzanie konwersacjami między agentami
  • Tools — narzędzia dostępne dla agentów
  • Code execution — możliwość wykonywania kodu przez agentów
  • Orchestration — koordynacja pracy wielu agentów

Wiele typów agentów — framework oferuje różne wyspecjalizowane typy agentów do różnych zadań.

Multi-agent systems — AutoGen jest zaprojektowany z myślą o systemach wieloagentowych, gdzie agenci współpracują ze sobą.

Pliki konfiguracyjne agentów:

  • AGENTS.md — definicje agentów
  • llms.txt — konfiguracja modeli językowych
  • SKILL.md — definicje umiejętności
  • .agent.md — konfiguracja konkretnego agenta
  • copilot-instructions.md — instrukcje dla Copilota

Agents need structured context — agenci wymagają dobrze ustrukturyzowanego kontekstu, żeby działać poprawnie.

Wzorce:

  • ReAct — Reasoning + Acting, naprzemienne rozumowanie i działanie
  • Plan and Execute — najpierw planowanie, potem wykonanie
  • Reflection — refleksja i samoocena agenta
  • Self-refine — iteracyjne doskonalenie odpowiedzi
  • LLM as judge — model językowy oceniający jakość odpowiedzi
  • Multi-agent debate — agenci dyskutują i weryfikują swoje odpowiedzi
  • Tree of thoughts — eksploracja drzewa możliwych rozumowań

Security:

  • OWASP LLM Top 10 — lista 10 największych zagrożeń bezpieczeństwa dla aplikacji LLM
  • MITRE ATLAS — framework do kategoryzacji ataków na systemy AI/ML
  • NIST AI RMF — framework zarządzania ryzykiem AI opracowany przez NIST

Linki:

Poemulujmy sobie Azure - Kamil Mrzygłód Link to heading

Na tej sesji nie byłem, jednak temat jest wart odnotowania. Kamil Mrzygłód opowiadał o emulowaniu usług Azure lokalnie — bez potrzeby łączenia się z chmurą podczas developmentu.

Głównym narzędziem prezentowanym na sesji był Topaz — emulator Azure do lokalnego developmentu.

Czym jest Topaz? Topaz to emulator środowiska Azure, który pozwala rozwijać aplikacje bez połączenia z rzeczywistymi usługami chmurowymi. Emuluje popularne komponenty Azure takie jak Azure Storage, Azure Key Vault czy Azure Service Bus.

Kluczowe możliwości:

  • wsparcie dla control plane i data plane emulowanych usług
  • pełna przenośność — pojedynczy plik wykonywalny lub kontener Docker
  • bezproblemowa integracja z Azure SDK
  • emulacja hierarchii zasobów Azure (subskrypcje, resource groups)
  • emulacja wdrożeń ARM (ARM Templates / Bicep)
  • emulacja Microsoft Entra ID tenant
  • emulacja Azure RBAC

Alternatywy: Azurite (Storage), Azure Cosmos DB Emulator, Azure Service Bus Emulator.

Linki: