19.05.2026
Finanse

AI zmienia SaaS: co to oznacza dla zespołów Salesforce

  • redakcja
  • 18 kwietnia 2026
AI zmienia SaaS: co to oznacza dla zespołów Salesforce

Akcje spółek software’owych spadły w tym roku mocno: Microsoft o ponad 21%, Salesforce o 26%, Workday o 36%, a Asana o 51% (Business Insider). Dla praktyków Salesforce to nie jest wyłącznie temat giełdowy, tylko sygnał zmiany logiki całego rynku enterprise software. Jeśli AI przejmuje część pracy użytkownika, pod presją znajdzie się nie tylko roadmapa produktów, ale też model licencjonowania, architektura integracji i sposób uzasadniania kosztu platformy. To dlatego dyskusja o tym, czy firmy nadal będą kupować gotowe systemy, bezpośrednio dotyczy adminów, architektów i liderów delivery.

AI nie zabija SaaS, ale odbiera mu dawny interfejs

Najmocniejsze napięcie na rynku nie dotyczy dziś tego, czy AI umie wygenerować fragment kodu. Chodzi o to, czy klient nadal będzie potrzebował rozbudowanej aplikacji biznesowej, skoro coraz więcej zadań może wykonać agent AI działający ponad istniejącymi systemami. W praktyce oznacza to przesunięcie z modelu „użytkownik klika w ekran” do modelu „agent realizuje zadanie w tle”.

To właśnie tłumaczy, dlaczego Microsoft rozwija agentów w pakiecie biurowym, a Salesforce stawia na Agentforce i Slackbot jako nowy interfejs pracy. Nie chodzi już tylko o dodanie czatu do CRM. Stawką jest utrzymanie pozycji platformy jako warstwy zaufania, danych i procesów, nawet jeśli sam kontakt użytkownika z systemem będzie rzadszy. Ten kierunek dobrze uzupełnia analiza, jak Slack staje się nowym UI Salesforce i przejmuje rolę punktu wejścia do działań wykonywanych przez AI.

Dla zespołów Salesforce to ważna zmiana projektowa. W klasycznym wdrożeniu dużo energii szło w układ ekranów, formularzy i ścieżek użytkownika. W modelu agentowym rośnie znaczenie jakości danych, uprawnień, deterministycznych reguł i integracji. Agent nie naprawi bałaganu w modelu danych – raczej szybciej ujawni jego skutki. Jeśli org ma niespójne ownership rekordów, słabe reguły walidacji albo nieczytelne procesy approval, AI tylko zautomatyzuje chaos.

Właśnie dlatego warto patrzeć na AI nie jako substytut aplikacji, lecz jako nową warstwę orkiestracji nad aplikacjami. To zbliża Salesforce do roli systemu wykonawczego i kontrolnego jednocześnie. Z perspektywy architekta oznacza to mniej pytań o sam interfejs, a więcej o to, gdzie leży prawda biznesowa, jak przebiega audyt decyzji i które akcje agent może wykonać autonomicznie.

Największa zmiana dotyczy pricingu, nie promptów

Przez lata software enterprise opierał się na seat-based pricing, czyli opłacie za użytkownika. AI podcina ten model z dwóch stron. Po pierwsze, jeśli agent przejmuje część pracy człowieka, firma może potrzebować mniej licencji przypisanych do pracowników. Po drugie, obsługa AI zwiększa koszty dostawcy, bo wymaga droższej infrastruktury obliczeniowej. To prowadzi rynek w stronę rozliczeń za użycie albo za wynik.

Dla ekosystemu Salesforce to temat bardziej praktyczny, niż może się wydawać. Gdy organizacja planuje wdrożenie agentów do service, sales ops czy back office, sama liczba użytkowników przestaje wystarczać do estymacji budżetu. Trzeba policzyć wolumen akcji, częstotliwość uruchomień, liczbę scenariuszy i poziom nadzoru człowieka. W tym kontekście szczególnie istotna jest analiza, dlaczego w Agentforce pojawiają się równoległe modele cenowe i jak wpływają one na planowanie architektury.

Microsoft nadal utrzymuje wysokie pakiety per user, ale równolegle testuje modele konsumpcyjne. To pokazuje, że rynek nie ma jeszcze jednego stabilnego wzorca. Dla partnerów wdrożeniowych i klientów oznacza to konieczność zmiany sposobu przygotowywania business case’ów. Zamiast prostego przelicznika „licencja razy liczba osób” potrzebna będzie mapa procesów i odpowiedź na pytanie, gdzie AI generuje realną oszczędność lub wzrost produktywności.

W praktyce polskich orgów Salesforce oznacza to jeszcze jedno: backlog automatyzacji trzeba zacząć priorytetyzować pod kątem kosztu wykonania przez agenta. Nie każdy use case nadaje się do modelu usage-based. Procesy częste, przewidywalne i dobrze opisane będą zwykle lepszym kandydatem niż zadania rzadkie, niejednoznaczne i pełne wyjątków.

Bezpieczeństwo i dane stają się główną obroną Salesforce

Najbardziej radykalna narracja mówi, że firmy po prostu zbudują własne aplikacje z pomocą AI i przestaną potrzebować dużych dostawców. Problem w tym, że samo wygenerowanie aplikacji to najmniejsza część zadania. Trudniejsze są dane, zgodność, bezpieczeństwo, utrzymanie i integracja z procesami operacyjnymi. Przykład Klarny pokazuje, że ograniczanie liczby narzędzi jest możliwe, ale wymaga rozbudowanego zaplecza do przechowywania i obsługi danych. To nie jest szybka zamiana SaaS na pojedynczy model językowy.

Dla Salesforce właśnie tu leży najważniejsza linia obrony. Duże orgi nie kupują już tylko ekranów CRM, ale kontrolę nad danymi klientów, stabilność procesów i przewidywalność działania. To także powód, dla którego niestandardowe aplikacje tworzone w modelu vibe coding budzą ryzyko – mogą szybciej powstawać, ale równocześnie otwierają nowe powierzchnie ataku i błędy w obsłudze danych. Ten problem warto zestawić z analizą, jak AI przyspiesza development, ale zwiększa dług techniczny.

Z perspektywy praktyka wniosek jest prosty: przewaga Salesforce w erze AI nie będzie wynikać z samej obecności modelu generatywnego. Zadecyduje jakość governance. Trzeba więc wzmacniać kontrolę dostępu, klasyfikację danych, zasady użycia agentów i monitoring działań wykonywanych automatycznie. Im więcej organizacja buduje z pomocą AI, tym bardziej potrzebuje platformy, która potrafi ograniczać ryzyko, a nie tylko przyspieszać wdrożenie.

AI nie kończy rynku SaaS – zmienia natomiast to, za co klient będzie gotów płacić. Dla Salesforce oznacza to przesunięcie z obietnicy „systemu dla użytkowników” do obietnicy „bezpiecznej warstwy wykonawczej dla ludzi i agentów”. Najbliższe lata rozstrzygną, które orgi potraktują tę zmianę jako korektę interfejsu, a które jako pełną przebudowę modelu danych, pricingu i governance. Pytanie brzmi nie czy AI wejdzie do twojego orga, ale czy zrobi to pod kontrolą architektury, czy obok niej.