Dlaczego dostarczamy AI w postaci instalowalnych plików binarnych, a nie chmurowego SaaS
Lokalne wnioskowanie, audyt kontrolowany przez klienta i model zakupowy, który już istnieje. Trzy strukturalne powody, dla których produkty AI firmy Software Tailor mają postać instalatorów desktopowych, a nie tenanta w naszej chmurze.
Większość linii AI Suite instaluje się na własnym komputerze użytkownika. Nie ma tenanta. Nie ma logowania w chmurze, które warunkowałoby dostęp do silnika wnioskowania. Aplikacje desktopowe komunikują się z lokalnym procesem aisuite-server, który z kolei łączy się z modelem na urządzeniu lub z AI Server kontrolowanym przez klienta, działającym w sieci klienta. Wybór ten — instalator desktopowy, nie SaaS — jest zamierzony, a jego powody warto utrwalić na piśmie.
Powód 1: regulowani nabywcy nie mogą umieszczać produkcyjnych promptów w cudzej chmurze
EU AI Act, obowiązujący od 2024 r., klasyfikuje istotny zbiór procesów biznesowych w przedsiębiorstwach jako „wysokiego ryzyka” i nakłada na podmiot stosujący obowiązki w zakresie rejestrowania, nadzoru ludzkiego oraz postępowania z danymi [1]. Równoważne lub równoległe ramy istnieją w państwach członkowskich OECD [2], a federalne agencje USA przy zamawianiu systemów AI kierują się NIST AI Risk Management Framework [3]. Żadne z tych ram nie zakazuje chmurowej AI; wymagają one, aby podmiot stosujący był w stanie wykazać, w sposób bieżący i dla każdego zapytania, co zostało wysłane, dokąd i co wróciło w odpowiedzi.
W praktyce wymóg ten zderza się ze sposobem, w jaki dziś działają chmurowe API LLM. Kierownik ds. zgodności w branży farmaceutycznej nie może pobrać ścieżki audytu na poziomie pojedynczego promptu z zewnętrznego SaaS dla procesu, który przetwarza identyfikatory pacjentów, nawet jeśli umownie SaaS jest zgodny z RODO. Potrzebuje, by prompt i odpowiedź nigdy nie opuszczały sieci, której jest właścicielem. Najczystszym sposobem, aby mu to zapewnić, jest dostarczenie AI w postaci pliku binarnego, który klient uruchamia wewnątrz własnego perymetru — co właśnie robimy.
Nie jest to nabywca hipotetyczny. Grupa klientów, dla których pracujemy od 2007 r., obejmuje sześć organizacji z listy Fortune Global 500 z branż farmaceutycznej, finansowej, rządowej, prawniczej, obronnej i energetycznej [4]. W każdej z tych branż istnieje co najmniej jeden proces, w którym odpowiedź na pytanie „gdzie odbywa się wnioskowanie?” decyduje, czy rozmowa zakupowa w ogóle się rozpocznie.
Powód 2: instalowalny plik binarny pasuje do tego, jak przedsiębiorstwa rzeczywiście kupują oprogramowanie
Ścieżka zakupowa dla aplikacji desktopowej jest dobrze rozumiana w dużych organizacjach IT. Aplikacja jest pakowana, dystrybuowana przez SCCM, Intune lub Jamf, regulowana tymi samymi politykami grupowymi co Microsoft Office, usuwana w chwili wycofania laptopa z eksploatacji. Zakupy, przegląd bezpieczeństwa i end-user computing mają dla tego procesy wypracowywane od dekad. AI Suite wpasowuje się w nie wprost.
Chmurowy SaaS, przeciwnie, wymaga równoległej ścieżki: oceny ryzyka dostawcy na poziomie pojedynczego tenanta, rozmowy o federacji tożsamości, bieżących audytów postury dostawcy oraz nieustannych negocjacji, czyje obowiązki obejmują co w razie awarii. Bywa to przydatne dla niektórych rodzajów oprogramowania. Jest złym dopasowaniem do rodzaju procesów AI, które budują nasi klienci.
Dostarczając instalowalne aplikacje uwierzytelniające się wobec własnego dostawcy tożsamości klienta — Microsoft Entra ID lub Google Workspace poprzez OpenID Connect — i niezachowujące niczego na naszych serwerach poza listą członków organizacji i logiem audytowym działań administracyjnych, umieszczamy rozmowę zakupową w ramie, którą organizacja już potrafi obsłużyć.
Powód 3: zero nieudanych projektów od 2007 r. zależy od nieuzależniania się od cudzego SLA
Dostarczamy oprogramowanie tworzone na zamówienie od dziewiętnastu lat, z bilansem zero nieudanych projektów od 2007 r. [4]. Bilans ten istnieje, ponieważ zespół kontroluje każdą warstwę dostawy: kod, build, testy, artefakt wdrożeniowy. W chwili, gdy uzależnimy produkcyjny proces klienta od dostępności cudzej chmury, bilans ten przestaje być nasz do obrony.
Dostawcy chmurowej AI doświadczają przerw w działaniu. Stosują throttling. Zmieniają cennik. Wycofują modele. Wycofują całe API. Nasi klienci w farmacji i obronności nie mogą sobie pozwolić, by ich roczne postępowanie regulacyjne stanęło w miejscu, ponieważ endpoint modelu, którego nie są właścicielami, został przeniesiony. Dlatego ich na takim endpointe nie umieszczamy. Model żyje na maszynie klienta, wnioskowanie odbywa się na maszynie klienta, a jedyne, co znajduje się w naszej infrastrukturze, to lekka powierzchnia administracyjna, której używa do zarządzania własnym wdrożeniem.
Co to oznacza dla ewaluacji
Jeśli jest Pan/Pani kierownikiem ds. zgodności, CIO lub CTO oceniającym lokalną AI pod kątem wdrożenia w przedsiębiorstwie, istotne pytania wyglądają inaczej niż w przypadku ewaluacji chmurowego SaaS:
- Gdzie odbywa się wnioskowanie? Na urządzeniu użytkownika lub na serwerze kontrolowanym przez klienta. Nie na naszym.
- Co opuszcza perymetr? Wyłącznie lista członków organizacji i działania administracyjne. Żadnych promptów, żadnych odpowiedzi, żadnych treści dokumentów.
- Jak wygląda ścieżka audytu? JSONL bez treści, przechowywany lokalnie, możliwy do eksportu. Model nigdy nie widzi treści, na której nie polecono mu działać, a wiersz audytu nigdy nie widzi treści w ogóle.
- Co się stanie, jeśli dostawca zniknie? Pliki binarne, które klient zainstalował, działają nadal. Lokalny AI Server, który włączył w środowisko, nadal obsługuje żądania. Bez konieczności przeniesienia na inną platformę.
To są cztery pytania, na które zbudowaliśmy AI Admin Console oraz Local AI Suite, aby udzielić odpowiedzi w sposób klarowny. Artykuł EU AI Act a zgodność oraz wdrożenie on-prem obejmuje stronę regulacyjną głębiej.
Źródła
- European Commission. „AI Act — Regulatory framework on AI.” digital-strategy.ec.europa.eu. Dostęp: 2026-06-15.
- OECD AI Policy Observatory. „National AI policies.” oecd.ai. Dostęp: 2026-06-15.
- NIST. „AI Risk Management Framework (AI RMF 1.0).” nist.gov/itl/ai-risk-management-framework. Dostęp: 2026-06-15.
- Software Tailor. „Past clients.” softwaretailor.com/past-clients.htm. Dostęp: 2026-06-15.
Powiązane artykuły
Oceń to samo podejście na rzeczywistym obciążeniu.
Bezpłatny tygodniowy pilotaż przeprowadza realny fragment pracy klienta — lokalne wnioskowanie, tożsamość kontrolowana przez klienta, audyt kontrolowany przez klienta.