Bezpieczeństwo aplikacji z AI. Co mówią przepisy i kto odpowiada za dane klientów?

Czy aplikację, która usprawni pracę całego działu, da się zbudować w weekend? Jeszcze kilka lat temu każdy programista by się roześmiał, bo nowa aplikacja w firmie oznaczała specyfikację, wykonawcę, budżet i miesiące czekania. Dziś ktoś z zespołu opisuje narzędziu AI, czego potrzebuje, a w poniedziałek cały dział korzysta z działającego panelu zamówień albo systemu zgłoszeń. W jakich czasach przyszło nam żyć!

Jest jednak jeden haczyk. Aplikacja może działać bez zarzutu i jednocześnie mieć słabe punkty, nazywane lukami, których osoba spoza branży po prostu nie zauważy, bo na ekranie wszystko wygląda dokładnie tak, jak powinno. Programista zwykle wychwyciłby je bardzo szybko i zobaczyłby na przykład, że wystarczy zmienić jedną cyfrę w adresie strony, żeby obejrzeć dane cudzego klienta. Równie szybko wychwycą je ci, którzy celowo szukają w internecie źle zabezpieczonych aplikacji, a dziś pomaga im w tym ta sama sztuczna inteligencja. Twórca aplikacji prosi AI, żeby wszystko działało, a osoba szukająca luk prosi, żeby wskazało, którędy da się wejść do cudzych danych. Najciekawsze jest to, że narzędzie, które pomogło zbudować aplikację, często potrafiłoby wskazać jej słabe punkty. Wystarczyłoby zapytać. Tylko kto o to pyta?

I tu dochodzimy do sedna. Bezpieczeństwo aplikacji to nie tylko dobre praktyki programistów, ale też przepisy, które bardzo konkretnie określają, jak aplikacja ma działać, a więc gdzie mogą znajdować się dane klientów, kto może mieć do nich dostęp co trzeba udokumentować i zgłosić na wypadek incydentu i jak szybko reagować, gdy coś pójdzie nie tak. A prawo nie robi wyjątków dla kodu napisanego przez maszynę.

Czym jest vibe coding?

Vibe coding, czyli w wolnym tłumaczeniu programowanie na wyczucie, to tworzenie aplikacji bez samodzielnego pisania kodu. Zamiast wpisywać polecenia w języku programowania, rozmawia się z narzędziem AI zwykłym językiem, mniej więcej tak, jak rozmawiałoby się z programistą. Piszesz, czego potrzebujesz, na przykład „zrób mi formularz do przyjmowania zamówień, który zapisze dane klienta i wyśle mi powiadomienie”, oglądasz efekt, prosisz o poprawki i po kilku rundach masz działający program. Określenie wymyślił na początku 2025 roku Andrej Karpathy, jeden ze współtwórców OpenAI, a przyjęło się tak szybko, że pod koniec tego samego roku słownik Collins ogłosił je słowem roku. Do najpopularniejszych narzędzi należą dziś między innymi Lovable, Claude Code, Bolt, Replit i Cursor.

Co to zmienia? Bardzo dużo, bo po raz pierwszy aplikację może zbudować ktoś, kto nie zna żadnego języka programowania, za to doskonale wie, czego potrzebuje jego dział. W mniejszych firmach często robi to sam właściciel albo najbardziej zaradny pracownik, który ma już dość przepisywania zamówień z maili do arkusza. W większych organizacjach zespoły sprzedaży, marketingu czy kadr budują w ten sposób własne narzędzia i prototypy, a działy IT coraz częściej zastanawiają się, jak nad tym zapanować, zanim w firmie zacznie działać kilkadziesiąt aplikacji, o których istnieniu nikt nie wie.

A co o vibe codingu sądzą firmy informatyczne takie jak nasza? Sami korzystamy z narzędzi AI na co dzień, bo przyspieszają analizę, prototypowanie i samo programowanie, więc nie zamierzamy nikogo od nich odciągać. Aplikacja zbudowana z pomocą AI to świetny punkt wyjścia, który często lepiej pokazuje potrzeby firmy niż niejedna wielostronicowa specyfikacja, i coraz częściej właśnie od takiej aplikacji zaczyna się nasza współpraca z klientami. Zwykle słyszymy wtedy coś w rodzaju „zrobiłem to w dwa wieczory i działa, tylko nie wiem, czy mogę już wpuścić tam klientów”. I to jest bardzo dobre pytanie, bo działający program i program gotowy na dane klientów to dwie zupełnie różne rzeczy.

Dlaczego bezpieczeństwo to sedno pracy programisty?

Zdradzimy Wam sekret z kuluarów branży. Napisanie kodu, który działa, nigdy nie było najtrudniejszą częścią pracy programisty, a w dobrze prowadzonym projekcie zajmuje zaskakująco małą część całego czasu. Cała reszta to praca, której klient zwykle nie widzi i o którą rzadko pyta, choć właśnie ona decyduje, czy aplikacji można bezpiecznie powierzyć dane.

Jak to wygląda od środka? Zanim jakakolwiek zmiana trafi do aplikacji, z której korzystają prawdziwi użytkownicy, czyta ją drugi programista i szuka w niej błędów oraz słabych punktów. Ten rytuał nazywa się przeglądem kodu i w wielu zespołach obowiązuje bez wyjątków, także wtedy, gdy autorem zmiany jest najbardziej doświadczona osoba w firmie. Nowe funkcje sprawdza się najpierw w osobnej wersji testowej, wypełnionej fikcyjnymi danymi, a dopiero potem przenosi do wersji produkcyjnej, czyli tej, na której pracują klienci. Hasła i klucze dostępu trzyma się w specjalnie zabezpieczonych miejscach, a nie w kodzie, każdy użytkownik dostaje tylko te uprawnienia, których naprawdę potrzebuje, a gotowe biblioteki, czyli fragmenty cudzego kodu, z których składa się każda aplikacja, regularnie się aktualizuje, bo co chwilę wykrywa się w nich nowe luki.

Są jeszcze testerzy, czyli osoby, których praca polega na psuciu aplikacji, zanim zrobi to ktoś inny. Tester wpisuje w pole nazwiska rzeczy, których żaden klient by tam nie wpisał, loguje się na cudze konta, zmienia numery w adresach stron i sprawdza, co się stanie, gdy dwie osoby jednocześnie edytują ten sam rekord. Programista sprawdza, czy aplikacja robi to, co powinna, a tester, czy przypadkiem nie robi także tego, czego nie powinna. Do tego dochodzą rzeczy zupełnie niewidoczne, takie jak kopie zapasowe, z których ktoś przynajmniej raz próbował odtworzyć dane, oraz dziennik zdarzeń, który pozwala ustalić, kto i kiedy oglądał dane klientów. Brzmi jak dużo pracy? Bo to jest dużo pracy, i właśnie ona odróżnia aplikację, która działa, od aplikacji, której można zaufać.

Przy vibe codingu te etapy często wypadają, i to nie ze złej woli. Bezpieczeństwo aplikacji to po prostu osobny, bardzo obszerny temat, w którym jest co najmniej tyle samo do nauczenia, co w samym budowaniu aplikacji z pomocą AI. A luki mają to do siebie, że nie widać ich podczas codziennej pracy, więc aplikacja potrafi działać bez zarzutu przez wiele miesięcy, aż do dnia, w którym dane klientów trafią tam, gdzie nie powinny. A wtedy w grę wchodzą już nie tylko nerwy, ale też przepisy.

Kto odpowiada za aplikację zbudowaną za pomocą AI?

Wyobraźmy sobie rozmowę po wycieku danych. „Ale to nie my, to AI napisało ten kod.” Brzmi rozsądnie? Niestety, brzmi to po prostu słabo. Za aplikację odpowiada firma, która z niej korzysta, bo prawo co do zasady nie interesuje się tym, kto lub co napisało kod, tylko tym, jakie dane aplikacja przetwarza, do czego służy i kto decyduje o jej użyciu.

Model AI za nic nie odpowiada, bo nie jest osobą, przynajmniej na razie.😅 Nie odpowiada też dostawca narzędzia, w którym aplikację zbudowano, ponieważ w swoich regulaminach, no cóż… Wyraźnie ogranicza odpowiedzialność za to, co użytkownik z jego pomocą stworzy. Zostaje więc firma, a jeśli podlega ona ustawie o krajowym systemie cyberbezpieczeństwa, także jej zarząd. Tłumaczenie, że kod został napisany przez AI, raczej nie zrobi wrażenia ani na klientach, ani na urzędzie.

Cztery regulacje, które warto znać

Spokojnie, nie trzeba być magistrem prawa, żeby się w tym wszystkim odnaleźć. Chcemy pokazać Wam cztery regulacje, które warto znać, jeśli chodzi o bezpieczeństwo aplikacji. Jeśli w Waszej firmie działa aplikacja zbudowana z pomocą AI, sprawdźcie, o co w nich chodzi i czy któraś z nich dotyczy także Was.

• RODO, czyli unijne rozporządzenie o ochronie danych osobowych. To podstawa podstaw, bo dotyczy każdej aplikacji, która przetwarza informacje o konkretnych ludziach, takie jak imiona, nazwiska, adresy e-mail, czy numery telefonów, a więc w praktyce niemal każdej aplikacji używanej w firmie.
• Ustawa o krajowym systemie cyberbezpieczeństwa (KSC), która od 3 kwietnia 2026 roku wdraża w Polsce unijną dyrektywę NIS2 i nakłada obowiązki w zakresie cyberbezpieczeństwa na średnie i duże firmy z wybranych sektorów, a w niektórych przypadkach także na podmioty mniejsze, dla których przewidziano szczególne kryteria lub wyjątki od progów wielkości.
• Cyber Resilience Act (CRA), czyli unijne rozporządzenie o odporności cyfrowej, które określa wymagania bezpieczeństwa dla oprogramowania i urządzeń sprzedawanych na rynku Unii Europejskiej.
• AI Act, czyli unijne rozporządzenie o sztucznej inteligencji, które reguluje zasady bezpiecznego i odpowiedzialnego tworzenia oraz korzystania z systemów sztucznej inteligencji, szczególnie gdy ich działanie może wpływać na ludzi.

Aplikacja z AI a RODO

Dane w firmie są bardzo różne. Aplikacja zbudowana z pomocą AI może korzystać z danych pracowników, na przykład przy planowaniu urlopów czy rozliczaniu godzin pracy, z danych klientów w panelu sprzedażowym albo z danych zamówień, faktur i reklamacji, bo każdy proces, który chcemy usprawnić, opiera się na jakichś informacjach. Za wszystkie te dane, a także za sposób, w jaki są przetwarzane, odpowiada firma, a nie narzędzie AI, które pomogło napisać kod. Dlatego zanim cokolwiek trafi do aplikacji, trzeba mieć świadomość, że to Wy odpowiadacie za ochronę tych danych. Co to oznacza w praktyce według RODO?

Po pierwsze, z każdą firmą, do której trafiają dane, trzeba mieć umowę powierzenia przetwarzania danych, czyli dokument, w którym ta firma zobowiązuje się chronić dane i używać ich tylko w uzgodnionym celu. Dotyczy to zarówno narzędzia, w którym napisaliście aplikację, i narzędzia AI, z którego ona korzysta, o ile trafiają do nich dane, jak i usług innych firm, na przykład platformy, na której aplikacja działa, czy bazy danych, w której zapisują się informacje. Jeśli serwery którejś z tych firm stoją poza Europejskim Obszarem Gospodarczym (to Unia Europejska oraz Islandia, Liechtenstein i Norwegia), potrzebna jest jeszcze podstawa prawna do przekazywania tam danych oraz poinformowanie osób, których dane będą przetwarzane poza EOG, o tym fakcie w ramach realizowanych obowiązków informacyjnych przez firmę

Po drugie, dane trzeba chronić odpowiednio do ryzyka. Inne ryzyko wiąże się z przetwarzaniem danych ograniczonych do indywidualnego numeru pracownika i liczby przepracowanych godzin, a znacznie większe z przetwarzaniem imienia i nazwiska, numeru PESEL, numeru rachunku bankowego czy informacji o zdrowiu. Im bardziej szczegółowe i wrażliwe są dane oraz im poważniejsze mogą być skutki ich ujawnienia, tym wyższego poziomu ochrony wymagają. 

Po trzecie, należy zapewnić poufność danych, czyli dostęp do nich powinny mieć wyłącznie osoby, które potrzebują ich do wykonywania swoich obowiązków służbowych. Najprościej pokazać to na przykładzie działu handlowego, w którym klienci są podzieleni między handlowców. Każdy z nich powinien widzieć w aplikacji tylko swoich klientów, a nie całą bazę firmy, kierownik może widzieć więcej, bo tego wymaga jego praca, a stażysta, który pomaga przez dwa miesiące, nie powinien mieć dostępu do wszystkiego tylko dlatego, że tak było łatwiej ustawić.

Po czwarte, aplikacja powinna zbierać tylko te dane, które są naprawdę potrzebne. Zamiast zapisywać wszystko, co się da, „bo może kiedyś się przyda”, warto zastanowić się, jakie jest minimum, które musicie znać, żeby proces działał. Jeśli do realizacji zamówienia wystarczą nazwa firmy, adres dostawy i numer telefonu, to data urodzenia klienta czy numer jego dowodu osobistego są w tej aplikacji po prostu zbędne, a każde zbędne pole to dodatkowe dane, które w razie wycieku trzeba będzie komuś wytłumaczyć.

Po piąte, jeśli dane wyciekną, firma ma co do zasady 72 godziny na zgłoszenie tego Prezesowi Urzędu Ochrony Danych Osobowych, a jeśli wyciek może zaszkodzić klientom albo pracownikom, musi poinformować także ich. W skrajnych przypadkach kara może sięgnąć 20 milionów euro albo 4 procent rocznego obrotu firmy.

Ważna jest też higiena danych na etapie samego budowania aplikacji. Wklejanie prawdziwej listy klientów albo pracowników do narzędzia AI tylko po to, żeby sprawdzić, czy coś działa, to również przekazanie danych kolejnemu dostawcy, często na zasadach darmowego albo prywatnego konta, więc trudno nazwać to dobrą praktyką. Tym bardziej że przygotowanie przez AI bazy z fikcyjnymi danymi testowymi, które programiści nazywają „dummy data”, zajmuje dosłownie kilka sekund. Fikcyjny Jan Kowalski z ulicy Przykładowej sprawdzi się w testach równie dobrze, a do tego nikogo nie pozwie.

Aplikacja z AI a ustawa o krajowym systemie cyberbezpieczeństwa (NIS2)

Jeśli Waszą firmę obejmuje ustawa o krajowym systemie cyberbezpieczeństwa, to aplikacja zbudowana z pomocą AI nie jest już prywatnym projektem osoby, która ją stworzyła. Od chwili, w której zaczyna z niej korzystać zespół, staje się kolejnym systemem informatycznym firmy, a wobec takich systemów ustawa ma bardzo konkretne wymagania.

Najważniejszym z nich jest zarządzanie ryzykiem, a żeby zarządzać ryzykiem, trzeba najpierw wiedzieć, jakie systemy w ogóle działają w firmie. I tu zaczyna się kłopot, bo aplikacja zbudowana po cichu w jednym z działów zwykle nie figuruje w żadnym firmowym spisie, a trudno zarządzać ryzykiem czegoś, o czego istnieniu nikt poza autorem nie wie.

Kiedy już wiadomo, że aplikacja istnieje, trzeba ocenić, co może w niej pójść nie tak, biorąc pod uwagę także to, że kod napisała AI. Najczęściej chodzi o rzeczy, o których pisaliśmy już przy pracy programistów, czyli błędy i luki w wygenerowanym kodzie, nieaktualne biblioteki, zbyt szerokie uprawnienia użytkowników, hasła zapisane tam, gdzie każdy może je zobaczyć, słabo chronione dane, a także dane klientów wklejone do narzędzia AI w trakcie budowania aplikacji. Do każdego poważnego ryzyka trzeba potem dobrać sposób, w jaki się je ogranicza, na przykład przegląd kodu przez kogoś, kto zna się na bezpieczeństwie, testy, regularne aktualizacje, porządek w dostępach i hasłach oraz jasne zasady korzystania z narzędzi AI w firmie. Brzmi znajomo? To dokładnie ta praca, która przy vibe codingu najczęściej wypada.

Na tym jednak nie koniec. Ustawa wymaga też dbania o bezpieczeństwo systemu przez cały czas jego istnienia, czyli zarówno wtedy, gdy powstaje, jak i później, gdy jest rozwijany i utrzymywany, a także reagowania na wykryte w nim luki. Firma musi ponadto kontrolować łańcuch dostaw, czyli wszystkie zewnętrzne usługi, od których zależy działanie jej systemów, a w przypadku aplikacji z AI są to na przykład baza danych, serwer, na którym aplikacja działa, i samo narzędzie AI. A ponieważ ustawa przenosi odpowiedzialność za cyberbezpieczeństwo bezpośrednio na zarząd, lepiej, żeby zarząd poznał tę aplikację, zanim pozna ją audytor.

Aplikacja z AI a Cyber Resilience Act (CRA)

Teraz scenariusz, który łatwo sobie wyobrazić. Aplikacja świetnie sprawdza się w dziale handlowym, więc na jednym ze spotkań ktoś rzuca, że skoro u nas działa, to może zacznijmy ją sprzedawać innym firmom. I właśnie wtedy trzeba zacząć myśleć o Cyber Resilience Act. To unijne rozporządzenie dotyczy oprogramowania, które jest sprzedawane albo udostępniane innym i łączy się z siecią lub z innymi urządzeniami, czyli w praktyce niemal każdej współczesnej aplikacji. Aplikacji używanej wyłącznie wewnątrz firmy co do zasady jednak nie obejmuje.

Kiedy jednak aplikacja trafia poza firmę, Wy stajecie się w świetle przepisów jej producentem, a producent ma konkretne obowiązki. Co ciekawe, nie trzeba przy tym na aplikacji zarabiać, bo liczy się samo udostępnianie jej w ramach działalności firmy, także za darmo. Nawet przekazanie aplikacji zaprzyjaźnionemu kontrahentowi „żeby też miał” może więc oznaczać, że trzeba się tym przepisom przyjrzeć.

Jakie to obowiązki? Producent musi od początku projektować aplikację z myślą o cyberbezpieczeństwie i nie może wypuścić jej na rynek ze znanymi lukami. Musi wiedzieć, z jakich gotowych elementów się składa, reagować, gdy ktoś zgłosi w niej lukę, i przez kilka lat bezpłatnie udostępniać poprawki bezpieczeństwa. Od 11 września 2026 roku musi też zgłaszać luki, które ktoś już wykorzystuje do ataków, oraz poważne incydenty, a pełne wymagania rozporządzenia zaczną obowiązywać 11 grudnia 2027 roku.

Najbardziej zaskakujący bywa wymóg znajomości elementów, z których składa się aplikacja. Każda aplikacja jest zbudowana po części z gotowych fragmentów kodu przygotowanych przez innych programistów, nazywanych bibliotekami, a producent musi prowadzić ich spis. W branży nazywa się go SBOM (od angielskiego Software Bill of Materials). Jeśli więc narzędzie AI dodało do Waszej aplikacji kilkadziesiąt takich bibliotek, a nikt w firmie nie wie, jakich, bez porządnego przeglądu trudno będzie przygotować taki spis, a potem pilnować, żeby te biblioteki były aktualne.

Aplikacja z AI a AI Act

Czy każda aplikacja zrobiona z pomocą AI podlega AI Act? Na pierwszy rzut oka mogłoby się wydawać, że tak, skoro w obu nazwach pojawia się AI. Otóż nie. AI Act, czyli unijne rozporządzenie o sztucznej inteligencji, nie interesuje się tym, jakim narzędziem zbudowaliście aplikację. Jeśli Wasz panel zamówień powstał w Claude Code, ale na co dzień po prostu zapisuje zamówienia i wyświetla je na ekranie, to dla tych przepisów jest zwykłym programem. RODO oczywiście nadal obowiązuje, ale o tym pisaliśmy już wyżej.

Sprawa wygląda inaczej, kiedy sztuczna inteligencja pracuje w samej aplikacji. Weźmy na przykład czat na stronie internetowej, który w niedzielę wieczorem odpowiada klientom na pytania o status zamówienia. Świetna sprawa, tylko że od 2 sierpnia 2026 roku taki czat musi co do zasady jasno informować, że klient rozmawia z programem, a nie z człowiekiem.

A co, jeśli AI zaczyna decydować o ludziach? Wyobraźcie sobie, że dział kadr dostaje na jedno ogłoszenie trzysta CV i ktoś proponuje, żeby usprawnić ten proces aplikacją, która sama wybierze najlepszą dziesiątkę kandydatów. Brzmi kusząco, ale ocena kandydatów do pracy, podobnie jak ocena, czy komuś przyznać kredyt, należy według AI Act do zastosowań wysokiego ryzyka. Taka aplikacja nie może więc działać zupełnie sama. Przepisy wymagają, żeby jej pracę nadzorował człowiek, który rozumie, jak ona działa, i w razie potrzeby może zakwestionować, zmienić albo odrzucić wybór dokonany przez AI.

To jednak nie wszystko, bo aplikacja wysokiego ryzyka oznacza także sporo pracy organizacyjnej i dokumentacyjnej. Jeśli zbudowaliście ją sami, to na Was spoczywa obowiązek zadbania o to, żeby jej ryzyka były opisane i ograniczone, żeby korzystała z odpowiednio dobranych danych, zapisywała, co i kiedy zrobiła, była zrozumiała dla osób, które z niej korzystają, działała dokładnie i była odporna na ataki. Wszystko to trzeba opisać w dokumentacji technicznej, która ma pokazać, że aplikacja spełnia wymagania AI Act. Te przepisy mają zacząć obowiązywać w grudniu 2027 roku.

Do tego dochodzi RODO, bo aplikacja do selekcji CV przetwarza przecież dane osobowe kandydatów. Kandydaci powinni się więc dowiedzieć, że ich zgłoszenia ocenia AI, na jakiej zasadzie to robi i jakie może to mieć dla nich skutki, a jeśli decyzja zapada w pełni automatycznie, mają co do zasady prawo do tego, żeby ich sprawą zajął się człowiek.

Warto też wiedzieć, że niektóre zastosowania AI są po prostu zakazane, i to już od lutego 2025 roku. W dużym skrócie oznacza to, że w firmie nie wolno używać AI między innymi do manipulowania klientami, wykorzystywania ich wieku czy trudnej sytuacji finansowej, oceniania klientów i pracowników punktowo za ich zachowanie ani odczytywania emocji pracowników, poza sytuacjami związanymi ze zdrowiem i bezpieczeństwem.

I ostatnia sprawa, która wraca do scenariusza ze sprzedażą aplikacji. Dopóki korzystacie z czatu AI na własne potrzeby, obowiązków jest mniej. Jeśli jednak zaczniecie oferować aplikację z wbudowaną sztuczną inteligencją pod własną nazwą, możecie zostać uznani za jej dostawcę, a dostawca ma tych obowiązków znacznie więcej.

Audyt bezpieczeństwa aplikacji. Jak możemy pomóc?

Jeśli po lekturze tego tekstu zastanawiacie się, czy Wasza aplikacja spełnia te wymagania, ale nie bardzo wiecie, jak się do tego zabrać, odpowiedzią może być audyt bezpieczeństwa aplikacji, czyli metodyczne sprawdzenie jej kodu, ustawień i sposobu działania, zakończone listą wykrytych problemów i zaleceniami, co z nimi zrobić.

Uczciwie dodajemy, że ani audyt, ani spełnienie wszystkich przepisów nie sprawiają, że aplikacja staje się bezpieczna w stu procentach, bo każda zmiana może otworzyć nową lukę. Audyt pozwala jednak wyłapać problemy najczęstsze i najgroźniejsze, a przy okazji pokazuje, że firma potraktowała ochronę danych poważnie.

W GAMP możemy pomóc na trzy sposoby, w zależności od tego, na jakim etapie jesteście.

• Audyt bezpieczeństwa aplikacji. Przeprowadzimy audyt kodu i bezpieczeństwa aplikacji zbudowanej z pomocą AI i powiemy wprost, co trzeba poprawić, co warto rozwijać, a co można zostawić bez zmian.
• Przebudowa aplikacji z AI w solidny system. Jeśli aplikacja ma zostać w firmie na dłużej, przejmiemy ją, uporządkujemy albo zbudujemy od nowa na trwalszych fundamentach, zachowując sprawdzoną koncepcję. Możemy też uruchomić ją w naszym centrum danych.
• Konsultacja. Jeśli nie wiecie jeszcze, od czego zacząć, umówcie się z nami na konsultację, podczas której wspólnie ustalimy, które przepisy dotyczą Waszej aplikacji i co warto zrobić w pierwszej kolejności.

Całą tę pracę wykonujemy w ramach systemu zarządzania bezpieczeństwem informacji zgodnego z normą ISO/IEC 27001.

Macie w firmie aplikację z AI? Sprawdźmy ją razem.

+48 505 171 898 Piotr Gawara CEO & Board President