SugarAI w sektorze publicznym: jak spełnić wymogi KRI, NIS2 i RODO przy wdrożeniu CRM

Instytucja publiczna kupuje CRM inaczej niż firma prywatna — nie tylko przez procedurę zamówień publicznych, ale przez dodatkowy filtr wymagań: Krajowe Ramy Interoperacyjności, znowelizowaną ustawę o krajowym systemie cyberbezpieczeństwa i RODO. W praktyce to właśnie ten filtr, a nie funkcjonalność systemu, najczęściej decyduje, czy wdrożenie SugarAI w urzędzie, spółce Skarbu Państwa czy instytucji sektora publicznego przejdzie audyt bez poprawek.

Jakie wymagania prawne obowiązują systemy CRM w administracji publicznej w Polsce?

Systemy CRM wdrażane w podmiotach realizujących zadania publiczne w Polsce podlegają trzem nakładającym się reżimom: Krajowym Ramom Interoperacyjności (KRI), znowelizowanej ustawie o krajowym systemie cyberbezpieczeństwa (uKSC) wdrażającej dyrektywę NIS2 oraz RODO. Rozporządzenie Rady Ministrów w sprawie KRI z 21 maja 2024 r. (Dz.U. 2024 poz. 773) nakłada obowiązek wdrożenia Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) oraz audytu wewnętrznego bezpieczeństwa nie rzadziej niż co 24 miesiące.

Znowelizowana ustawa o KSC weszła w życie 3 kwietnia 2026 r. i wprowadza własny harmonogram: podmioty kluczowe i ważne mają czas do 3 października 2026 r. na rejestrację w wykazie, a do 3 kwietnia 2027 r. — na pełne wdrożenie obowiązków SZBI wynikających z ustawy (gov.pl, 2026). RODO pozostaje wymogiem równoległym i obowiązuje niezależnie od tego, czy dany podmiot podlega KRI czy uKSC — każdy system CRM przetwarzający dane osób fizycznych musi je spełniać z osobna.

Nie każda instytucja podlega wszystkim trzem reżimom jednocześnie. KRI dotyczy podmiotów realizujących zadania publiczne — administracji rządowej i samorządowej oraz jednostek im podległych. Podmioty prywatne co do zasady nie podlegają KRI, ale mogą zostać do tego zobowiązane, jeśli realizują zadania publiczne na podstawie umowy z administracją (IKMJ, 2026). Zakres uKSC jest szerszy — obejmuje podmioty kluczowe i ważne z kilkudziesięciu sektorów gospodarki, nie tylko administrację.

Czym różni się wdrożenie CRM dla instytucji publicznej od wdrożenia komercyjnego?

Wdrożenie CRM w instytucji publicznej różni się od projektu komercyjnego przede wszystkim zakresem dokumentacji i audytowalności, nie samą technologią. Zamiast jednorazowej akceptacji systemu przez sponsora biznesowego, projekt musi przejść przez analizę ryzyka w rozumieniu SZBI, opisać sposób przetwarzania danych osobowych zgodnie z RODO i wykazać zgodność konfiguracji z wymaganiami technicznymi KRI — formatami wymiany danych, protokołami szyfrującymi, zasadami dostępu.

Dochodzi do tego proces zamówień publicznych (PZP), który wydłuża harmonogram wdrożenia i wymusza precyzyjne definiowanie wymagań bezpieczeństwa już na etapie dokumentacji przetargowej, a nie po podpisaniu umowy z dostawcą. Odpowiedzialność za brak zgodności spoczywa formalnie na kierowniku podmiotu — co w praktyce oznacza, że dział IT i partner wdrożeniowy muszą dostarczyć dokumentację, którą kierownik może obronić przed kontrolą NIK lub audytem KRI, przeprowadzanym nie rzadziej niż co 24 miesiące.

Jak SugarAI spełnia wymogi bezpieczeństwa i rezydencji danych?

SugarAI oferuje dwa modele wdrożenia o różnym profilu zgodności — SugarCloud (SaaS) oraz edycję Enterprise, którą można wdrożyć on-premise lub w chmurze prywatnej przez partnera wdrożeniowego. SugarCloud działa na infrastrukturze AWS i posiada certyfikaty ISO/IEC 27001:2022 oraz SOC 2 Type II, a dane są szyfrowane zarówno w tranzycie, jak i w spoczynku (SugarAI, 2026). System udostępnia kontrolę dostępu opartą na rolach (RBAC), wieloskładnikowe uwierzytelnianie (MFA) na wszystkich punktach dostępu oraz logowanie i monitorowanie każdego dostępu do danych.

Klient SugarCloud wybiera jeden z czterech regionów AWS, w których fizycznie przechowywane są dane: Australia, Niemcy, Wielka Brytania lub Stany Zjednoczone — SugarAI nie oferuje obecnie dedykowanego regionu w Polsce (SugarAI, 2026). Dla podmiotów, dla których KRI lub uKSC narzucają twarde wymagania co do lokalizacji danych, alternatywą jest wdrożenie Sugar Enterprise on-premise lub w chmurze prywatnej hostowanej na infrastrukturze w UE — np. przez partnera wdrożeniowego dysponującego własną serwerownią w regionie.

Taki model daje pełną kontrolę nad lokalizacją serwerów i harmonogramem audytów bezpieczeństwa, kosztem większej odpowiedzialności organizacji za utrzymanie infrastruktury. Wybór między SugarCloud a wdrożeniem on-premise powinien wynikać z analizy ryzyka przeprowadzonej w ramach SZBI, nie z domyślnej preferencji technologicznej — to jedna z pierwszych decyzji do podjęcia przed startem projektu, nie w jego trakcie.

Jak wygląda praktyka wdrożenia CRM w instytucji publicznej?

eVolpe Consulting Group ma w portfolio wdrożenia SugarCRM (obecnie SugarAI) dla instytucji z sektora badawczo-technicznego, w tym dla NASK — Naukowej i Akademickiej Sieci Komputerowej. Szczegóły konfiguracji poszczególnych wdrożeń objęte są standardową poufnością projektową, typową dla projektów realizowanych dla podmiotów publicznych, natomiast sama obecność eVolpe w tym segmencie pokazuje, że wymagania KRI i uKSC nie wykluczają systemów klasy SugarAI z projektów administracji i instytucji badawczych.

Aby zobrazować przebieg takiego projektu, warto posłużyć się scenariuszem ilustracyjnym — hipotetycznym, nieopartym na konkretnym wdrożeniu. Duży operator o charakterze zbliżonym do instytucji infrastruktury krytycznej — na przykład podmiot działający w skali porównywalnej do Poczty Polskiej — obsługuje setki tysięcy relacji z klientami biznesowymi i musi rejestrować historię kontaktu, zgody marketingowe oraz reklamacje w jednym systemie. Projekt zaczyna się od analizy ryzyka SZBI i mapowania tego, które moduły CRM przetwarzają dane osobowe podlegające RODO.

Kolejny krok w takim scenariuszu to konfiguracja modelu dostępu — w SugarAI realizowanego przez mechanizm ról i zespołów (RBAC/Teams) — tak, by odzwierciedlał strukturę organizacyjną i ograniczał widoczność danych do zespołów, które faktycznie ich potrzebują. To wymóg wynikający zarówno z KRI, jak i z wewnętrznych polityk bezpieczeństwa większości dużych instytucji, niezależnie od tego, czy formalnie podlegają one KRI, czy nie.

Na co uważać przy wdrażaniu CRM w administracji — najczęstsze błędy

Największym błędem przy wdrażaniu CRM w administracji jest traktowanie zgodności z KRI i RODO jako formalności do uzupełnienia po zakończeniu wdrożenia, a nie jako wymogu projektowego od pierwszego dnia prac. Dokumentacja SZBI napisana po fakcie rzadko odzwierciedla rzeczywistą konfigurację systemu — a to właśnie rozbieżność między dokumentacją a stanem faktycznym najczęściej wychodzi na audycie KRI.

Kolejny częsty problem to brak jednej, wyznaczonej osoby odpowiedzialnej za SZBI po stronie klienta. Bez niej dostawca CRM nie ma z kim uzgadniać wymagań technicznych na bieżąco, a decyzje dotyczące bezpieczeństwa zapadają fragmentarycznie, u różnych osób, w różnym czasie. Trzeci powtarzalny błąd to integracja z systemami dziedzinowymi administracji — na przykład z ePUAP lub systemami resortowymi — zaplanowana bez wcześniejszego ustalenia formatów wymiany danych zgodnych z KRI. Prowadzi to do kosztownych przeróbek integracji już po starcie produkcyjnym systemu, gdy zmiana staje się znacznie droższa niż na etapie projektowania.

Jak zaplanować harmonogram wdrożenia CRM zgodny z terminami KRI i NIS2?

Harmonogram wdrożenia CRM w instytucji objętej uKSC powinien być powiązany z ustawowymi terminami, a nie planowany niezależnie od nich. Podmioty kluczowe i ważne mają czas do 3 października 2026 r. na złożenie wniosku o wpis do wykazu, a do 3 kwietnia 2027 r. — na wdrożenie pełnego systemu zarządzania bezpieczeństwem informacji (gov.pl, 2026). Jeśli projekt CRM wystartuje bez uwzględnienia tych dat, dokumentacja bezpieczeństwa systemu może powstać już po terminie ustawowym, co komplikuje kontrolę i naraża kierownika podmiotu na odpowiedzialność.

W praktyce sensowną kolejnością jest: najpierw analiza ryzyka i klasyfikacja danych, które trafią do CRM, następnie wybór modelu wdrożenia (SugarCloud vs. on-premise) na podstawie wyników tej analizy, dopiero potem konfiguracja funkcjonalna systemu. Odwrócenie tej kolejności — czyli wybór systemu i dostawcy przed ustaleniem wymagań bezpieczeństwa — jest jedną z głównych przyczyn, dla których projekty CRM w administracji wracają do etapu projektowania już po podpisaniu umowy wdrożeniowej.

Audyt KRI, wymagany nie rzadziej niż co 24 miesiące, warto też zaplanować jako punkt kontrolny w harmonogramie utrzymania systemu, nie jako wydarzenie jednorazowe powiązane wyłącznie z wdrożeniem. System CRM, który przeszedł audyt w momencie startu, może przestać spełniać wymagania po kolejnej aktualizacji, integracji lub zmianie modelu dostępu — dlatego dokumentacja SZBI powinna być żywym dokumentem aktualizowanym po każdej istotnej zmianie w konfiguracji.

SugarCloud czy wdrożenie on-premise — porównanie dla instytucji publicznej

Podsumowanie

Przed uruchomieniem przetargu na CRM warto zadać sobie jedno pytanie: czy dział IT ma już zmapowane, które wymogi KRI i uKSC dotyczą planowanego systemu — czy dopiero ustali to po podpisaniu umowy z dostawcą?

Najczęściej zadawane pytania

Czy SugarAI może być wdrożony on-premise? Tak. Poza SugarCloud (SaaS) dostępna jest edycja Enterprise, którą można wdrożyć on-premise lub w chmurze prywatnej — to opcja dla instytucji, dla których lokalizacja danych w Polsce lub UE jest wymogiem regulacyjnym.

Czy SugarCloud spełnia wymogi KRI? SugarCloud posiada certyfikaty ISO/IEC 27001:2022 i SOC 2 Type II oraz szyfrowanie danych, ale nie oferuje regionu AWS w Polsce. Zgodność z KRI wymaga indywidualnej analizy ryzyka i może wskazywać na model on-premise.

Od kiedy obowiązuje znowelizowana ustawa o KSC wdrażająca NIS2? Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r. Podmioty kluczowe i ważne mają czas do 3 października 2026 r. na rejestrację w wykazie.

Czy każda instytucja publiczna podlega KRI? Nie każda. KRI dotyczy podmiotów realizujących zadania publiczne, w tym administracji rządowej i samorządowej. Podmioty prywatne mogą podlegać KRI, jeśli świadczą usługi na rzecz administracji na podstawie umowy.

Kto odpowiada za brak zgodności systemu CRM z KRI w urzędzie? Formalnie odpowiada kierownik podmiotu, np. dyrektor urzędu, który może zostać pociągnięty do odpowiedzialności za brak wdrożenia SZBI lub niezgodność systemów teleinformatycznych z wymaganiami KRI.

Czy SugarAI obsługuje RODO natywnie? SugarAI wspiera rejestrowanie podstaw prawnych przetwarzania danych, zarządzanie zgodami i kontrolę okresów retencji, co ułatwia zgodność z RODO — ostateczny zakres zależy jednak od konfiguracji wdrożenia.

Ile trwa audyt bezpieczeństwa wymagany przez KRI? Rozporządzenie o KRI nie narzuca długości pojedynczego audytu, ale wymaga jego przeprowadzania nie rzadziej niż co 24 miesiące — w praktyce czas trwania zależy od skali systemu i liczby integracji.

Planujesz wdrożenie SugarAI w instytucji objętej KRI, uKSC lub RODO i chcesz sprawdzić, jak dopasować model wdrożenia do wymagań compliance? Skontaktuj się z naszym zespołem — pomożemy przeanalizować wymagania bezpieczeństwa (KRI, uKSC, RODO) i zaplanować projekt CRM od analizy ryzyka po go-live.

Źródła:

• Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773)
• gov.pl — Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa
• SugarAI — Security and Trust ( sugarai.com/legal/security-trust )
• IKMJ — Krajowe Ramy Interoperacyjności: wymagania, audyt, wdrożenie i SZBI