7 funkcji, które zniszczą Twoją firmę, jeśli zbudujesz je z AI bez wiedzy technicznej
Doradca IT to artykuły i kanał YouTube, w których wyjaśniam IT w biznesowy sposób.
Kategorie:
AITen obrazek jest wygenerowany z AI. Tekst w 100% napisał Tomasz Oszkiel.
Ostatnio pod moim postem na LinkedIn zawrzało. Jedni pisali, że nikt już nie potrzebuje programisty ani software house'u, bo dziś każdy może sam zrobić aplikację z AI. Inni odpowiadali, że osoba bez wiedzy technicznej zrobi w ten sposób co najwyżej prototyp.
Moim zdaniem obie strony mają rację. Nietechniczny CEO może zrobić aplikację z AI i to nie jest kłamstwo - pytanie "jaką" aplikację. Jestem zdania, że bez wiedzy i doświadczenia technicznego możesz zrobić jedynie prototyp aplikacji, klikalny, działający pod publicznym adresem, gotowy do testowania, dający informację czy Twoje założenia biznesowe mają sens. Jednak są funkcje ryzykowne, których bez wiedzy technicznej nie powinieneś publikować nawet jeśli AI pomogło Ci je zaprogramować i wydaje Ci się, że działają poprawnie.
PS. AI rozwija się bardzo szybko. Zaznaczę w tym miejscu, że jest to moja opinia aktualna na dzień 27.07.2026.
Poniżej lista funkcji, których moim zdaniem na pewno nie powinieneś robić samodzielnie bez wiedzy technicznej.
1. Przetwarzanie danych osobowych
Twoje AI (ChatGPT, ClaudeAI) wygenerowało formularz zakładania konta, ale czy dodałeś tam checkbox z linkiem do regulaminu i polityki prywatności? Czy wymieniłeś tam wszystkie dane osobowe, które przetwarzasz, i wszystkie nazwy dostawców usług - serwer, SMS, wysyłka maili, płatności online? Czy zadbałeś o podwójne uwierzytelnianie przed logowaniem do panelu administracyjnego i do bazy danych, żeby nikt poza Tobą nie mógł podejrzeć danych, skopiować ich i opublikować w internecie? Czy wiesz, że np. zapisywanie wersji przeglądarki użytkownika, jego płeć, stanowisko to dane osobowe, które jeśli przetwarzasz w aplikacji to musisz je wymienić w Polityce Prywatności?
Jeśli nie znasz odpowiedzi na te pytania, ryzykujesz wyciek danych osobowych klientów, kary RODO liczone w tysiącach, czasem milionach złotych, oraz brak umów powierzenia danych z dostawcami, których prawo od Ciebie wymaga.
Około miesiąca temu (maj-czerwiec 2026) miała miejsce awaria dużego dostawcy usług ecommerce (nazwa zaczynająca się na literę A - jeśli jesteś z branży ecommerce na pewno wiesz o kogo chodzi, nie chcę tu robić czarnego PR). Zamówienia sprzedawców zostały pomieszane i wielu sprzedawców widziało w swoich panelach zamówienia innych sklepów oraz dane klientów, którzy złożyli zamówienia. Zdecydowanie nie chcesz być na miejscu właściciela tego systemu - wierz mi.
Tak na pewno przyczyną był prosty błąd programistyczny w kodzie. Wiesz jak wyglądają kolumny i wiersze Excela, prawda? W Excelu można tworzyć wiele arkuszy (tabel) i w komórce można dodać "odniesienie" do komórki z innego arkusza, np. Arkusz 1 to lista zamówień a arkusz 2 to lista sprzedawców. Każdy sprzedawca ma wiele zamówień a więc w tablicy "zamówienia" można dodać odniesienie do sprzedawcy np. tworząc kolumnę "sprzedawca ID" i wstawiając do niej ID sprzedawcy. Teraz wystarczy pomylić ID sprzedawców i problem gotowy. Podobnie jest w bazie danych w aplikacji. Niedoświadczony programista może bardzo łatwo popełnić podobny błąd - nietechniczna osoba z AI również.
2. Płatności online
Czy obsłużyłeś wszystkie błędy płatności? Na przykład, co się dzieje, gdy ktoś odświeży przeglądarkę w trakcie płatności? Czy zbudowałeś zabezpieczenie po stronie backendu na wypadek, gdyby ktoś próbował przesłać niższą kwotę bezpośrednio do bramki płatności przez zapytanie do API? Bez tych zabezpieczeń ryzykujesz stratę finansową dla firmy, stratę wizerunku, jeśli klient straci pieniądze przez Twoją aplikację, oraz mnóstwo dodatkowej pracy, gdy klient zapłaci za mało, za dużo albo wcale, a Ty musisz to ręcznie wyjaśniać i naprawiać.
Zauważyłeś jak działają płatności online kiedy sam coś kupujesz? Przechodzisz do swojego banku, wykonujesz przelew, potwierdzasz płatności i wracasz do sklepu/platformy. W czasie powrotu do platformy bank przesyła informację do platformy o statusie płatności, platforma ją odbiera i jeśli odebrała poprawnie wtedy ponownie wysyła informację do banku - dopiero wtedy przelew faktycznie zostaje wykonany. To trudna funkcja nawet dla programisty z 8-10 letnim doświadczeniem, więc wydaje mi się abstrakcją wykonanie jej w 100% poprawnie przez osobę nietechniczną.
Podałem przykład jedynie mało skomplikowanej płatności - jednorazowej. Teraz wyobraź sobie poziom skomplikowania przy płatnościach cyklicznych kiedy użytkownik podaje numer karty. Dodatkowo wyobraź sobie sytuację, że użytkownik po opłacie 3 miesięcy chce przejść na opłatę roczną - to wszystko musisz zaprogramować i obsłużyć oraz zrobić zabezpieczenia na każdą sytuację.
Bardzo mocno Ci odradzam samodzielne dodawanie płatności online do swojej aplikacji bez konultacji i pomocy doświadczonego programisty.
3. Obliczenia finansowe
Czy Twoje obliczenia finansowe są liczone na frontendzie, czy na backendzie? To pytanie brzmi technicznie, ale ma bardzo praktyczne konsekwencje. Jeśli liczysz na frontendzie, każdy, kto zna się na rzeczy, może wysłać przez Postmana lub podobne narzędzie własne dane bezpośrednio do Twojego API i zapisać zupełnie inne wartości. Frontend może się też po prostu pomylić - bez złej woli nikogo. Błąd oznacza wtedy dużo pracy naprawczej, bo trzeba znaleźć wszystkie miejsca, gdzie się powielił, i stratę wizerunku, gdy klient lub pracownik zauważy, że coś się nie zgadza.
Mieliśmy taką sytuację w systemie Franchix (nasz SaaS system dla sieci franczyzowych). Rozwijaliśmy MVP, mieliśmy użytkowników, którzy testowali system (byli to pracownicy jednej z dużych sieci masaży). Początkowo w module "Finanse", w których były tworzone raporty miesięczne i dzienne mieliśmy wyświetlanie i dodawanie danych finansowych - bez obliczeń, dodawania ich do siebie. Z tygodnia na tydzień coraz częściej pojawiały się potrzeby sumowania danych. Jak to w MVP gdzie optymalizuje się ilość dodawania nowych funkcji dodaliśmy kilka obliczeń w warstwie frontendu jedynie do przetestowania założeń biznesowych. Bardzo szybko się okazało, że dane, które są pobierane z bazy danych ładują się zbyt wolno i system nie jest w stanie ich przeliczać w odpowiednim czasie. Nie ma szans, aby osoba nie będąca programistą potrafiła zidentyfikować źródło problemu i go poprawić przenosząc obliczenia z frontendu na backend.
4. Zapewnienie dostępności aplikacji
Czy masz wdrożony proces na wypadek, gdyby aplikacja przestała działać, a użytkownicy nie mogli z niej korzystać? Jeśli coś się zepsuje w środku nocy, a jedyną osobą, która rozumie kod, jest ChatGPT lub Claude Code AI - nikt tego szybko nie naprawi.
W standardowych umowach utrzymania czyli jeśli zawierasz taką umowę z software house masz zapisy, które gwarantują, że dostawca zareaguje na awarię w określonym czasie np. 3h na reakcję od momentu zgłoszenia awarii w godz. 9:00-17:00 w dni robocze.
Pamiętaj także o zawarciu warunków w regulaminie (czyli umowa między Tobą a użytkownikami) aby ograniczyć Twoją odpowiedzialność za brak dostępności aplikacji w razie awarii.
5. Logowanie i zarządzanie dostępem użytkowników
Czy masz zabezpieczenia, które oddzielają dane różnych użytkowników - ich dane osobowe, zamówienia, raporty? Czy to oddzielenie jest zrobione tylko na frontendzie, czy także na backendzie? Słabo zabezpieczone hasło albo źle poukładane uprawnienia to prosta droga do włamania albo do sytuacji, w której jeden klient zobaczy dane innego.
O konsekwencjach tego błędu napisałem już w punkcie 1.
6. Integracje z innymi systemami firmy
Czy masz zabezpieczenie na wypadek, gdyby system, z którym się integrujesz - księgowość, magazyn, CRM - przestał działać? Czy wtedy Twoja aplikacja też przestaje działać, czy w jakiś sposób nadal obsłuży użytkownika? Błąd integracji oznacza dużo pracy naprawczej, bo trzeba przywracać dane z kopii zapasowych i ręcznie odnajdywać, które dane są poprawne, a które zostały zaburzone.
Trudno mi sobie wyobrazić, że zrobi to AI.
7. Automatyczna komunikacja z klientami
Czy masz zabezpieczenia gwarantujące poprawną wysyłkę informacji do klientów? Maile i SMS-y wysyłane automatycznie, gdy trafią do złej osoby albo z błędną treścią, nie da się cofnąć. Klient już to przeczytał, a strata wizerunku zostaje.
Podsumowanie
Jeśli z jakiegoś powodu chcesz zbudować prototyp samodzielnie bez wsparcia programisty - zrób to, ale przed jego publikacją kiedy wydaje Ci się, że wszystko działa zapytaj doświadczonego programistę chociaż o audyt i konsultację.
Najczęstsze pytania
Czy możesz bez wiedzy technicznej zbudować aplikację z AI?
Tak, ale niech to będzie prototyp bez ryzykownych funkcji obejmujących dane osobowe, płatności online, obliczenia finansowe ani integracje z innymi systemami firmy.
Jakie funkcje aplikacji możesz zbudować samodzielnie z AI?
Wyświetlanie i zapisywanie danych testowych, pobieranie i wczytywanie testowych plików, generowanie testowych raportów, testowe dodawanie produktów do koszyka.
Co Ci grozi za nieprawidłowe przetwarzanie danych osobowych w aplikacji zbudowanej z AI?
Kary RODO liczone w tysiącach, a w poważniejszych przypadkach milionach złotych, a także utrata zaufania klientów po ewentualnym wycieku danych.
Kiedy warto oddać budowę aplikacji software house'owi zamiast robić to samemu z AI?
Warto to zrobić, gdy aplikacja ma obsługiwać płatności, dane osobowe, integracje z innymi systemami firmy lub gdy ma być dostępna dla realnych, płacących klientów, a nie tylko do wewnętrznych testów.
Czy jeśli zbuduję prototyp z AI to później software house lub programista będą mogli go rozwijać?
Nie, każdy dostawca IT, który przejmie projekt będzie musiał rozpocząć budowę od podstaw. Twój prototyp jednak bardzo się przyda, aby łatwiej i szybciej zaplanować pracę.
