Power BI Embedded dla SaaS MŚP 2026 — Publish to Web vs paid embed

Power BI Embedded dla SaaS MŚP 2026: Publish to Web vs paid embed

Dla polskiego dostawcy SaaS pytanie nie brzmi już „czy da się pokazać raport Power BI w aplikacji?”, lecz „czy da się zrobić to bez ujawniania danych klientów, bez licencji Pro dla każdego odbiorcy i z kosztami przewidywalnymi przy wzroście do tysięcy użytkowników?”. W 2026 roku wybór sprowadza się do trzech modeli: Publish to Web, Embed for Customers oraz Embed for Your Organization.

Ten tekst dotyczy customer-facing SaaS, czyli aplikacji B2B z raportami klienta po zalogowaniu. To inny problem niż klasyczne porównanie licencji Microsoft Power BI, Pro, PPU czy Premium. Tu liczy się architektura osadzenia, RLS, region danych, koszt pojemności i to, czy odbiorca musi mieć konto Microsoft.

Trzy modele osadzania Power BI w aplikacji

Publish to Web jest dla publicznych raportów, Embed for Customers dla SaaS i klientów zewnętrznych, a Embed for Your Organization dla portali wewnętrznych z użytkownikami Microsoft Entra ID.

Microsoft rozdziela scenariusz osadzania dla klientów od scenariusza wewnętrznego. W dokumentacji Embed for your customers aplikacja używa tożsamości technicznej, generuje token po stronie serwera i pokazuje raport w iframe. Użytkownik aplikacji nie musi mieć konta Power BI ani licencji Pro.

Publish to Web: darmowe, wygodne i publiczne

Publish to Web działa szybko: w Power BI Service wybierasz raport, generujesz link lub kod iframe i wklejasz go na stronę. To dobre rozwiązanie dla raportu marketingowego, publicznego benchmarku albo dashboardu z danymi, które i tak mogą być jawne.

Problem: Publish to Web nie jest kontrolą dostępu. Microsoft ostrzega w dokumentacji Publish to web, że raport jest dostępny dla użytkowników Internetu, a odbiorcy nie muszą się uwierzytelniać. Ten tryb nie działa też dla raportów zabezpieczonych RLS.

• Używaj Publish to Web wyłącznie dla danych publicznych, demonstracyjnych lub marketingowych.
• Nie publikuj tą metodą danych klientów, spraw, faktur, leadów, dokumentów, wyników sprzedaży ani informacji operacyjnych.
• Nie traktuj „trudnego do odgadnięcia linku” jako zabezpieczenia.
• Regularnie przeglądaj aktywne kody osadzenia i usuwaj niepotrzebne linki.

Dla SaaS MŚP Publish to Web ma sens jako publiczna witryna demo. Nie ma sensu jako dashboard po zalogowaniu, jeżeli raport zawiera dane konkretnej firmy, kancelarii, klienta lub użytkownika.

Embed for Customers: właściwy model dla SaaS B2B

Embed for Customers, znany też jako customer embed, app owns data, Power BI Embedded albo osadzanie na pojemności Microsoft Fabric, jest projektowany dla dostawców aplikacji. Klient loguje się do SaaS własnym kontem, a backend decyduje, jaki raport i zakres danych może zobaczyć.

W praktyce płacisz za pojemność, a nie za licencję Power BI Pro dla każdego klienta końcowego. Zespół deweloperski i analityczny nadal potrzebuje licencji do tworzenia i publikowania raportów, ale odbiorcy w portalu SaaS nie kupują osobnych licencji Power BI.

Azure A SKU czy Microsoft Fabric F SKU?

Historycznie Power BI Embedded kojarzył się z Azure A SKU, na przykład A1 za około 735 USD miesięcznie przy pracy 24/7. W 2026 roku strategicznym wyborem dla nowych wdrożeń jest jednak Microsoft Fabric Embedded na pojemnościach F SKU. Microsoft opisuje Fabric jako wspólną pulę Capacity Units dla BI, data engineering, data warehousing i AI; na stronie Microsoft Fabric pricing wskazuje też pay-as-you-go oraz rezerwacje 1- i 3-letnie.

W dokumentacji Power BI Microsoft zaznacza, że opcje pojemności są konsolidowane i nowi oraz obecni klienci powinni rozważać Fabric F SKU zamiast starszych pojemności Premium. Dla SaaS oznacza to prostą zasadę: jeżeli startujesz dziś, planuj na F SKU, nawet jeśli w starszych materiałach nadal widzisz Azure Power BI Embedded A SKU.

To nie jest gwarancja wydajności dla każdego modelu danych. DirectQuery do wolnej bazy i ciężkie miary DAX zużyją pojemność szybciej niż dobrze zoptymalizowany model importowany. Liczby pokazują jednak rząd wielkości dla decyzji budżetowej.

RLS: warunek konieczny w multi-tenant SaaS

Row-Level Security jest jednym z najważniejszych elementów architektury. RLS pozwala zdefiniować role na modelu semantycznym Power BI, zwykle przez reguły DAX filtrujące dane po identyfikatorze klienta, kancelarii lub użytkownika. W customer embed backend przekazuje effective identity w tokenie, a Power BI stosuje właściwy filtr.

Przykład: tabela Cases ma kolumnę TenantId. Użytkownik z kancelarii A loguje się do SaaS, backend generuje token z tożsamością przypisaną do TenantId = A, więc raport pokazuje tylko sprawy tej kancelarii. Kancelaria B korzysta z tego samego raportu, ale widzi wyłącznie własne sprawy.

Microsoft opisuje ten model w dokumentacji RLS dla Power BI Embedded, wskazując dynamic RLS dla małych i średnich ISV oraz izolację workspace dla większych wdrożeń z tysiącami klientów.

• Dynamic RLS jest zwykle najlepszy na start: jeden raport, jeden model, filtr po tenant ID.
• Workspace per tenant daje silniejszą izolację i elastyczność dla dużych klientów, ale zwiększa automatyzację i administrację.
• OLS może ukrywać wybrane tabele lub kolumny, gdy sam fakt istnienia atrybutu jest wrażliwy.
• Testy RLS muszą być częścią procesu wydawniczego, nie jednorazową konfiguracją w Power BI Desktop.

Jak wygląda wdrożenie techniczne

Minimalna architektura składa się z workspace Power BI/Fabric, raportu, modelu semantycznego, backendu oraz komponentu frontendowego. Część krytyczna dzieje się po stronie serwera: tam aplikacja uwierzytelnia się w Microsoft Entra ID, wywołuje REST API i generuje embed token.

1. Utwórz workspace w Power BI Service i przypisz go do pojemności Fabric F SKU lub Power BI Embedded.
2. Opublikuj raport oraz model semantyczny, najlepiej z parametrem tenant ID i rolami RLS.
3. Skonfiguruj service principal w Microsoft Entra ID i nadaj mu dostęp do workspace.
4. W backendzie SaaS pobierz Microsoft Entra access token, a następnie wywołaj Power BI REST API do pobrania metadanych raportu.
5. Wygeneruj embed token z właściwą effective identity, rolą RLS i zakresem dostępu tylko do odczytu.
6. Przekaż frontendowi krótko żyjący embed token, embed URL i report ID.
7. Osadź raport w iframe lub przez Power BI JavaScript API, z obsługą odświeżania tokenu i błędów po stronie UI.

W środowisku Microsoftowym ten model dobrze łączy się z bazą SQL, hurtownią Fabric, integracją z Microsoft 365 oraz kontrolą dostępu w Entra ID. Przy większych wdrożeniach trzeba osobno zaplanować backup i utrzymanie serwerów, szczególnie gdy źródłem raportów jest Windows Server 2025 z lokalnym SQL Serverem.

RODO i lokalizacja danych: co sprawdzić przed produkcją

Dane klientów SaaS często są danymi osobowymi albo tajemnicą przedsiębiorstwa. Microsoft wskazuje w Power BI security white paper, że dane klienta Power BI są przechowywane w przypisanej geografii Azure, z wyjątkami dla konfiguracji multi-geo. Dla polskich firm oznacza to konieczność sprawdzenia, czy tenant i pojemność są w regionie zgodnym z wymaganiami RODO.

W praktyce lista kontrolna powinna obejmować: region tenant home geo, region pojemności Fabric, lokalizację źródłowej bazy danych, bramę danych, umowę powierzenia, retencję logów oraz transfery poza EOG. PARP w materiale o transferze danych poza EOG przypomina, że przekazywanie danych osobowych poza Europejski Obszar Gospodarczy wymaga właściwej podstawy i zabezpieczeń.

Sam Power BI Embedded nie zwalnia dostawcy SaaS z obowiązków administratora lub podmiotu przetwarzającego. Trzeba mieć politykę dostępu, rejestrowanie operacji, procedurę usunięcia danych klienta i monitoring anomalii. W praktyce warto połączyć projekt BI z ochroną endpointów, np. antywirus dla firm, oraz zarządzaniem tożsamością w Microsoft 365 E5.

Przykład: SaaS dla kancelarii prawnych

Załóżmy polski SaaS dla kancelarii prawnych, obsługujący około 200 organizacji. Aplikacja pokazuje analizę spraw, obciążenie prawników, czas reakcji, statusy dokumentów i terminy. Publish to Web odpada natychmiast, bo raport zawiera dane klientów, spraw i pracowników. Embed for Your Organization też nie pasuje, bo kancelarie są klientami zewnętrznymi, a nie pracownikami dostawcy.

Rozsądny start to Fabric F4 za około 526 USD miesięcznie, jeden wspólny model danych z dynamic RLS per kancelaria oraz raport osadzony w portalu. Jeżeli kilka dużych kancelarii wymaga mocniejszej separacji, można wydzielić im osobne workspace. Przy wzroście do 1000 klientów plan finansowy powinien zakładać przejście na F8.

Czego brakuje w wielu poradnikach konkurencji

W SERP dla „power bi embedded saas” i „publish to web power bi” często brakuje ostrzeżenia o publiczności Publish to Web, kalkulatora PLN oraz połączenia RLS z RODO.

Alternatywy: Looker, Tableau, Qlik

Looker Embedded, Tableau Embedded i Qlik Embedded są dojrzałymi rozwiązaniami, ale dla polskich firm M365-first koszt wejścia i integracja bywają mniej atrakcyjne. Looker często pojawia się w budżetach rzędu dziesiątek tysięcy dolarów rocznie, Tableau łączy koszt platformy i licencji, a Qlik wymaga osobnego ekosystemu kompetencji.

Jeżeli firma już używa Microsoft 365, Teams, Entra ID, SQL Server i Power BI Desktop, customer embed na Fabric zwykle daje krótszą ścieżkę wdrożenia. Osobno trzeba policzyć narzędzia biurowe i raportowe, np. przy standardowych stanowiskach z Office 2024, ale sam odbiorca raportu w SaaS nie potrzebuje licencji Power BI Pro.

Rekomendacja dla SaaS MŚP

Dla raportów publicznych wybierz Publish to Web tylko przy pełnej jawności danych. Dla portalu klienta wybierz Embed for Customers na Fabric F SKU, z RLS od pierwszego sprintu. Dla raportów wewnętrznych licz koszt Pro albo Microsoft 365 E5.

Pragmatyczna ścieżka w 2026 roku: F4 na start, pomiar obciążenia, dynamic RLS, optymalizacja modelu, a potem skalowanie do F8 lub F32. To tańsze niż zbyt duża pojemność i bezpieczniejsze niż publiczny link.