CRA. Trzy literki, które dzisiaj może nie budzą niepokoju, ale sytuacja może się zmienić w 2027 roku. Dlaczego?

Jakimś cudem umknął mi fakt, że pod koniec lipca ’26 Komisja Europejska opublikowała wytyczne w sprawie stosowania CRA, w którym poruszono bardzo wiele wątków, w tym rozumienie centralnego zagadnienia, czyli znaczenia „produktu z elementami cyfrowymi”.

Na pozór jest to dość proste, bo według samego rozporządzenia jest to:

    „oprogramowanie komputerowe lub sprzęt komputerowy oraz powiązane z nimi rozwiązania w zakresie zdalnego przetwarzania danych, w tym komponenty oprogramowania lub sprzętu, które są oddzielnie wprowadzane do obrotu”

Ale jak się domyślacie sprawa tak oczywista nie jest. Zacząłem się zastanawiać nad konkretnymi przypadkami, które mogą pojawić się w zderzeniu z CRA. Co w sytuacji, gdy udostępniam swoim klientom rozwiązanie SaaS, np. poprzez aplikację webową i na jakiejś licencji. Czy to oznacza, że będę musiał zapewnić wszystko o czym mowa w załącznikach CRA (to główny trzon obowiązków)?

Postanowiłem zderzyć swoje wątpliwości z asystentem AI, z którego korzystam i „wspólnie” rozłożyliśmy to na kilka przypadków, o których będę chciał jeszcze opowiedzieć.

Zanim do tego przejdziemy, to musimy sobie odpowiedzieć na pytanie jakie przesłanki muszą być spełnione, aby w ogóle mówić o produkcie z elementem cyfrowym. No więc:

✅ musimy mieć produkt sprzętowy (hardware) lub oprogramowanie (software); co istotne, komponent (np. biblioteka) też jest oddzielnym produktem, jeżeli jest oddzielnie wprowadzany do obrotu. A jeżeli z produktem powiązane jest zdalne przetwarzanie danych, to wchodzi ono w granice tego produktu – ale z zastrzeżeniem – nie jest to warunek, bo produkt bez żadnego backendu podlega CRA tak samo;

✅ produkt ma bezpośrednie lub pośrednie, logiczne lub fizyczne połączenie danych z urządzeniem lub siecią; przesłanka jest bardzo pojemna i wystarczy port USB do wgrywania aktualizacji;

✅ rozwiązanie jest dostarczane użytkownikowi i wykonuje się po jego stronie (to kryterium pochodzi z wytycznych Komisji, nie wprost z rozporządzenia, ale w praktyce to ono najczęściej przesądzi, czy podlegamy CRA);

✅ produkt jest udostępniany na rynku UE w ramach naszej działalności komercyjnej i to zarówno odpłatnie, jak i nieodpłatnie; forma prawna i „bezpłatność” nie mają znaczenia, a niekomercyjny open source wypada z CRA właśnie na tej przesłance, a nie przez jakieś osobne wyłączenie;

❌ nie występuje żadne z wyłączeń (m.in. wyroby medyczne, homologacja pojazdów, lotnictwo, wyposażenie morskie).

Co więc może być CRA, a co niekoniecznie?

Oprogramowanie, które jest udostępniane użytkownikowi, np. w formie SDK (software development kit), biblioteki czy wtyczki do przeglądarki i wykonywane u niego – będzie podlegało CRA.

Mało tego, nasz backend też może „wpaść” w CRA, choć na szczęście nie każdy.

Wytyczne Komisji nakazują spełnić przesłanki z trzyelementowego testu, tj.:

✅ przetwarzanie odbywa się na odległość,

✅ bez tego przetwarzania produkt nie zrealizuje którejś ze swoich funkcji,

✅ oprogramowanie stworzyliśmy my jako producent lub powstało na naszą odpowiedzialność.

Dopiero wtedy backend wchodzi w granice produktu (jako tzw. RDPS – Remote Data Processing Solutions). Telemetria wysyłana w jedną stronę (tylko do producenta, np. na potrzeby poprawy jakości rozwiązania) czy systemy, z którymi produkt bezpośrednio się nie komunikuje – już nie.

Niekoniecznie będziemy stosować CRA, jeżeli mówimy o rozwiązaniu, które „wykonuje się u nas”, a więc np. strony internetowe, rozwiązania SaaS’owe i tym podobne. Ale i tutaj możemy zrobić pewne zastrzeżenia, bo chciałem Wam pokazać cztery warianty, które postanowiłem rozkminić z modelem Opus 5.

Rozważałem następujący wariant:

    mamy oprogramowanie, które sprzedajemy w formie licencji i w modelu SaaS, a więc klient z niego korzysta, ale – komplikując rozwiązanie – dodatkowo integruje się to rozwiązanie z jego systemami wewnątrz firmy, np. ERP.

Forma prawna akurat jest tutaj do zignorowania, bo nie wpływa ona na kwalifikację CRA, ważniejsze staje się pytanie czy w ramach integracji rozwiązania (naszego) cokolwiek trafia do infrastruktury klienta i kod jest tam wykonywany.

To zaś oznacza, że możemy rozważyć następujące warianty:

❌ Klient wywołuje żądania poprzez API (interfejsy dostępowe) własnym kodem, ale wszystko rozstrzyga się na serwerach dostawcy SaaS; ten dostawca nie dostarcza produktu z elementami cyfrowymi, ale klient też nie, bo swój kod integracyjny pisze na własny użytek, a więc niczego nie wprowadza do obrotu.

W tym wariancie CRA nie dotyczy nikogo. Chyba że klient wbuduje nasze rozwiązanie we własny produkt, który sam sprzedaje lub w inny sposób dystrybuuje – wtedy to on jest producentem i to on odpowiada, a my staniemy się jego dostawcą, od którego zażąda SBOM-u (Software Bill of Materials) i informacji o podatnościach.

✅ My dostarczamy SDK lub bibliotekę, ale to klient u siebie wykonuje całość; zgodnie z wytycznymi SDK czy biblioteka dostarczana klientom – to produkt z elementami cyfrowymi wprost, ze wszystkimi obowiązkami po naszej stronie. To najpewniejszy element całej tej układanki, który powoduje, że po prostu nie uciekniemy przed CRA.

✅ Jakiś rodzaj connector’a lub agent, to przypadek, gdy jakiś komponent instalujemy na infrastrukturze klienta, a on pośredniczy pomiędzy tym co udostępniamy my a tym co dostaje klient. To również wariant, w którym raczej będziemy stosować CRA, także w odniesieniu do naszego backendu.

✅ Jeżeli rozwiązanie udostępniamy klientowi do „ogarnięcia”, to nie ma wątpliwości, że jest to rozwiązanie podlegające CRA.

Mało tego, nie opowiedziałem o wszystkim!

Oczywiście warianty możemy mnożyć, ale te powyżej wydają się najbardziej powszechne. Jak widzicie wątpliwości może pojawić się sporo, a mając produkt z elementami cyfrowymi, możemy wpaść w CRA.

Te konkretne obowiązki, to nie tylko to, co nas czeka w grudniu 2027 roku, ale także raportowanie do ENISA i CSIRT w zakresie m.in. podatności i incydentów. To obowiązek już od września ‘26, choć nie ma jeszcze kanałów zgłaszania, więc można założyć, że będzie to obowiązek na razie martwy. Wrócę do tego jeszcze we właściwym czasie, a zainteresowanych odsyłam do art. 14. 

Na pocieszenie powiem, że przepisy o karach to też dopiero grudzień 2027 roku, więc to, na co się narażamy, to stan niezgodności, ale bez sankcji administracyjnych. Co wcale nie oznacza, że nic nie ryzykujemy.

Czytaj także: Zagrożenia nie znikną, dlatego musimy robić swoje

Michał Nowakowski – doktor nauk prawnych i radca prawny z 15-letnim doświadczeniem w obszarze innowacji finansowych oraz nowych technologii. Założyciel strony www.legalarchitect.pl oraz kanału Youtube: można.prościej. Specjalizuje się w zagadnieniach związanych z wdrażaniem przepisów i regulacji dotyczących danych, AI i cyberbezpieczeństwa oraz budowaniu w organizacjach rozwiązań data governance i data management.

Był prezesem zarządu PONIP w latach 2022-2026, a także Przewodniczącym Sekcji AI przy Polskim Towarzystwie Informatycznym (2023-2025). Pracował zarówno w sektorze publicznym, jak i prywatnym, gdzie zdobywał doświadczenie przy realizacji projektów uwzględniających szeroko rozumiane ryzyka ICT oraz outsourcing i ochronę prywatności. Był związany także z instytucjami finansowymi, w tym z bankami, gdzie doradzał m.in. zespołom R&D, bezpieczeństwa oraz IT. Odbył też staże w Międzynarodowym Funduszu Walutowym i Europejskim Banku Centralnym Autor książek, artykułów naukowych i prelegent na konferencjach i wydarzeniach branżowych.

Prywatnie miłośnik kodowania i ML. Współzałożyciel i prezes zarządu spółki GovernedAI, zajmującej się tworzeniem i wdrażaniem bezpiecznego oprogramowania wykorzystującego systemy uczenia maszynowego i głębokiego, w tym tzw. generatywną sztuczną inteligencję.