Większość produktów z linii AI Suite instaluje się na własnym urządzeniu użytkownika. Nie ma najemcy. Nie ma logowania do chmury, które ogranicza dostęp do silnika inferencji. Aplikacje desktopowe komunikują się z lokalnym aisuite-server procesem, który z kolei komunikuje się albo z modelem na urządzeniu, albo z kontrolowanym przez klienta AI Server działającym w sieci klienta. Ten wybór — instalator desktopowy, a nie SaaS — jest świadomy i warto go opisać.

Powód 1: regulowani nabywcy nie mogą umieszczać produkcyjnych zapytań w chmurze innych podmiotów

Rozporządzenie UE o AI, obowiązujące od 2024 roku, klasyfikuje znaczną część procesów przedsiębiorstw jako „wysokiego ryzyka” i nakłada obowiązki prowadzenia rejestrów, nadzoru ludzkiego oraz zarządzania danymi na wdrażającego [1]. Równoważne lub podobne ramy istnieją w państwach członkowskich OECD [2], a agencje federalne USA działają zgodnie z NIST AI Risk Management Framework przy zamówieniach systemów AI [3]. Żadne z tych ram nie zakazuje AI w chmurze; wymagają one, aby wdrażający mógł na bieżąco i na żądanie wykazać, co zostało wysłane gdzie i co wróciło.

W praktyce ten wymóg koliduje z tym, jak działają dziś chmurowe API dużych modeli językowych. Kierownik ds. zgodności w farmacji nie może uzyskać śladu audytu zapytania z SaaS innej firmy dla procesu przetwarzającego identyfikatory pacjentów, nawet jeśli SaaS jest kontraktowo zgodny z RODO. Może być konieczne, aby zapytanie i odpowiedź nigdy nie opuściły sieci, którą posiada. Najczystszym sposobem zapewnienia takiej ścieżki jest dostarczenie AI jako pliku binarnego, który klient uruchamia we własnym obszarze — co właśnie robimy.

To nie jest hipotetyczny nabywca. Grupa klientów, do której dostarczamy od 2007 roku, obejmuje sześć organizacji z listy Fortune Global 500 z branży farmaceutycznej, finansowej, rządowej, prawnej, obronnej i energetycznej [4]. Każdy z tych sektorów ma co najmniej jeden proces, w którym odpowiedź na pytanie „gdzie odbywa się inferencja?” decyduje, czy rozmowa o zakupie w ogóle się rozpoczyna.

Powód 2: instalowalny plik binarny odpowiada rzeczywistemu sposobowi zakupu oprogramowania przez przedsiębiorstwa

Proces zakupu aplikacji desktopowej jest dobrze znany w dużych organizacjach IT. Aplikacja jest pakowana, dystrybuowana przez SCCM, Intune lub Jamf, zarządzana tymi samymi zasadami grupowymi co Microsoft Office, usuwana po wycofaniu laptopa z eksploatacji. Zakupy, przegląd bezpieczeństwa i obsługa użytkownika końcowego mają wieloletnie procedury dla tego procesu. AI Suite idealnie się w to wpisuje.

Chmurowe SaaS wymaga natomiast równoległego procesu: przeglądu ryzyka dostawcy dla każdego najemcy, rozmów o federacji tożsamości, ciągłych audytów postawy dostawcy oraz stałych negocjacji, kto i za co odpowiada, gdy coś się zepsuje. Przydatne dla niektórych rodzajów oprogramowania. Złe dopasowanie do typów procesów AI, które budują nasi klienci.

Dostarczając instalowalne aplikacje, które mogą uwierzytelniać się u własnego dostawcy tożsamości klienta — Microsoft Entra ID lub Google Workspace przez OpenID Connect — utrzymujemy zawartość inferencji poza płaszczyzną kontroli Software Tailor. Usługi organizacyjne nadal przetwarzają dane potrzebne do działania wdrożenia: listy i role, uprawnienia, polityki i stan serwera, zbiorcze użycie, audyt administracyjny, licencjonowanie i wsparcie. To są rzeczywiste dane po stronie dostawcy, ale są oddzielone od zapytań, odpowiedzi i dokumentów klienta na ścieżce lokalnego lub hostowanego przez klienta modelu.

Powód 3: zero niepowodzeń projektów od 2007 roku zależy od niezależności od dostępności usług innych firm

Dostarczamy oprogramowanie na zamówienie od dziewiętnastu lat, z rekordem zero niepowodzeń projektów od 2007 roku [4]. Ten rekord istnieje, ponieważ zespół kontroluje każdą warstwę dostawy: kod, kompilację, testy, artefakt wdrożeniowy. W momencie, gdy sprawiamy, że produkcyjny workflow klienta zależy od dostępności chmury innej firmy, ten rekord przestaje być naszym do obrony.

Dostawcy AI w chmurze mają awarie. Ograniczają przepustowość. Zmienią ceny. Wycofują modele. Wycofują całe API. Klienci, którym służymy w farmacji i obronności, nie mogą pozwolić, by ich roczna sprawa regulacyjna utknęła, ponieważ punkt końcowy modelu, którego nie posiadają, został przeniesiony. Dlatego nie umieszczamy ich lokalnej ścieżki modelu na takiej usłudze. Model znajduje się na urządzeniu klienta, a inferencja odbywa się na urządzeniu klienta. Nasza infrastruktura dostarcza usługi płaszczyzny kontrolnej potrzebne do tożsamości, uprawnień, polityk, stanu floty, zbiorczego użycia, administracji i wsparcia; nie jest to środowisko uruchomieniowe inferencji i nie otrzymuje treści zapytań ani odpowiedzi na tej ścieżce.

Co to oznacza dla oceny

Jeśli jesteś liderem ds. zgodności, CIO lub CTO oceniającym lokalne AI do wdrożenia w przedsiębiorstwie, odpowiednie pytania różnią się od oceny chmurowego SaaS:

  • Gdzie odbywa się inferencja? Na urządzeniu użytkownika lub na serwerze kontrolowanym przez klienta. Nie na naszym.
  • Co opuszcza obszar chroniony? Na lokalnej lub hostowanej przez klienta ścieżce inferencji żadne zapytania, odpowiedzi ani zawartość dokumentów nie trafiają do Software Tailor. Dane płaszczyzny kontrolnej, licencje, bezpieczeństwo, telemetria (jeśli włączona) i zapisy wsparcia mają oddzielne, udokumentowane ścieżki danych.
  • Jaki jest ślad audytu? JSONL bez treści, przechowywany lokalnie, możliwy do eksportu. Model nigdy nie widzi treści, na które nie ma polecenia reagować, a wiersz audytu w ogóle nie widzi treści.
  • Co się dzieje, gdy dostawca znika? Zainstalowane binaria i darmowe lokalne środowisko uruchomieniowe nie zależą od hostowanego najemcy inferencji. Subskrypcja, organizacja i centralnie zarządzane funkcje Pro mogą nadal wymagać ważnych uprawnień i usług płaszczyzny kontrolnej, więc plan wyjścia musi je uwzględniać.

To są cztery pytania, na które stworzyliśmy AI Admin Console oraz Local AI Suite aby na nie jasno odpowiedzieć. Artykuł o zgodności z EU AI Act i wdrożeniu lokalnym omawia stronę regulacyjną bardziej szczegółowo.

Bibliografia

  1. Komisja Europejska. „AI Act — Ramy regulacyjne dotyczące AI.” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Dostęp 2026-06-15.
  2. OECD AI Policy Observatory. „Krajowe polityki AI.” https://oecd.ai/. Dostęp 2026-06-15.
  3. NIST. „AI Risk Management Framework (AI RMF 1.0).” https://www.nist.gov/itl/ai-risk-management-framework. Dostęp 2026-06-15.
  4. Software Tailor. „Dotychczasowi klienci.” https://softwaretailor.com/past-clients.htm. Dostęp 2026-06-15.