Kompleksowe porównanie licencji usług i narzędzi AI do kodowania oraz budowania biznesu

Jesteś właścicielem biznesu i tworzysz oprogramowanie przy pomocy narzędzi AI? Czy zastanawiałeś się czy przekazując dane do modelu lub usługi AI nie przekazujesz wrażliwych danych biznesowych podmiotowi trzeciemu ze zgodą do ich dalszego przetwarzania? A może software house z którym współpracujesz korzysta z takich narzędzi – czy ten software house nie przekazuje bez Twojej zgody kodu do modeli AI które mogą się uczyć na tej podsatwie twojego biznesu?

To są tylko przykłady – istnieje wiele scenariuszy w których tworzysz oprogramowanie wspierające biznes lub będące wręcz podstawą Twojego biznesu, ale przy wykorzystaniu sztucznej inteligencji. Kwestie tempa rozwoju AI nie są obecnie na świecie rozwiązane. Tak samo istnieje sporo problemów nie tylko z prawami autorskimi dotyczącymi wygenerowanych treści (kodu, dźwięków, obrazów), ale też – o czym ostatnio świat wydaje się zapominać – o sposobie uczenia danych (kto pamięta o tym, że Meta uczyła swoje modele na nielegalnych książkach z torrentów?). Również ludzie zapominają o samym fakcie dostępu AI do danych, które jej udostępniasz (wystarczy wspomnieć choćby dążenie Google do tego, aby Gemini miała dostęp do Twojej poczty czy kalendarza). Temat jest bardzo szeroki, dlatego w tym artykule skupimy się wyłącznie na biznesowym aspekcie programowania, prawa autorskiego do kodu oraz przetwarzania danych (w tym wypadku: wszystkiego co jest podane w promptach) przez modele w celu uczenia się.

Problematyczne przypadki wykorzystania AI w biznesie

Przypadek 1 – autorstwo wygenerowanego kodu

Pierwszy problem na który chcę zwrócić uwagę, to kod wygenerowany przez AI. Spójrzmy na to z perspektywy developera, który może przesłać różne zestawy danych do modelu AI:

• Prompt zawierający słowny opis wymaganej funkcjonalności
• Prompt zawierający pseudokod do przepisania na funkcjonany kod
• Prompt zawierający część lub całe repozytorium (tak, aby AI miało dostęp do kontekstu i lepszego zrozumienia co ma napisać) z instrukcją dodania jakiejś funkcjonalności
• Prompt zawierający opis biznesu i jego strategiczne elementy (aby AI rozumiało kontekst) z prośbą o napisanie funkcji

Abstrachując od tego, że w każdym przypadku jakość odpowiedzi od AI będzie różna, w wyniku każdego z tych zapytań otrzymamy gotową funkcjonalność. Ale powstaje problem: kto jest autorem wygenerowanego kodu? Właściciel biznesu, programista czy AI? Pytanie jest o tyle istotne, że tylko autor kodu ma prawa przekazać je dalej komu innemu. Jeśli uznamy że programista nie jest autorem, to nie ma on prawa przekazać takiego kodu do zleceniobiorcy.

Przypadek 2 – co przekazujemy do AI

Poprzedni przypadek zawiera w sobie jeszcze jeden zaszyty aspekt – to znaczy co dzieje się z danymi, które zostają przesłane do modelu AI, czyli de facto do firmy trzeciej? I o ile niektóre z takich promptów nie będą budzić żadnych obaw, o tyle inne mogą okazać się bardzo zgubne. Rozważmy takie rodzaje zapytań:

• „Stwórz funkcję, która będzie obliczać potęgę liczby podanej w parametrze”
• „Tworzę oprogamowanie z integarcją z systemem zdrowia. Stwórz funkcję, która będzie przekierowywała użytkownika z panelu płatności, na panel uzupełniania recepty.”
• „Mam pomysł na produkt: [opis produktu]. Twoim zdadaniem jest stworzyć prototyp kodowy tego biznesu.”
• „Podsyłam ci mój obecny kod. Sprawdź go pod kątem bezpieczeńtwa.”
• „Podsyłam ci bazę danych moich użytkowników, która działa wolno. Zaproponuj optymalizacje które przyspieszą zapytania.”

Sądzę, że jako uważny czytelnik wiesz już do czego zmierzam. O ile w pierwszym przykładzie przekazuję ogólnie dostępną wiedzę, o tyle z każdym kolejnym przykładem przekazuję do modelu wiedzę coraz bardziej wrażliwą, a nawet dane użytkowników (w tym w domyśle tak zwane PID – Personal Identification Data – co podpada pod „złamanie” RODO/GDPR). Gdzie narysować granice tego, co można przekazać do modelu? Krótka odpowiedź będzie niesatysfakcjonująca: to zależy – i wymaga dalszej analizy, którą oczywiście przeprowadzam w dalszej części artykułu.

Przypadek 3 – kto odpowiada za błędy?

Przeskoczmy na chwilę do przodu i zastanówmy się nad trzecim elementem – odpowiedzialnością. Powiedzmy, że dwa pierwsze aspekty rozwiązaliśmy i kod został poprawnie pod kątem prawnym wdrożony na serwer produkcyjny. Ale wychodzi problem – błąd bezpieczeństwa – wyciekają dane, biznes ma sprawę w sądzie i powstaje problem:

• Biznes twierdzi, że winnym błędu jest software house
• Software house zrzuca odpowiedzialność na developera, który – być może w nieautoryzowany sposób – wykorzystał AI do stworzenia niebezpiecznego kodu
• Developer twierdzi, że nie on jest winien błędu, tylko albo tester który błędu nie wykrył, albo dostawca AI który „wyprodukował” kod na podstawie jego zapytania

Nie bacząc na to jaki będzie werdykt sądu – czy jesteśmy w stanie stwierdzić gdzie faktycznie leży odpowiedzialność? Dlatego tak ważne jest, aby software house miał przygotowane standardy i procedury współpracy z narzędziami AI, tak jak jest w Sailing Byte – gdzie developerzy wiedzą z czego i w jakim zakresie mogą korzystać.

Abstrachując od samej odpowiedzialności, istnieją jeszcze inne aspekty bezpieczeństwa. Model może odpowiadać korzystając ze starych (potencjalnie niebezpiecznych) wzorców projektowych. Model może też „produkować” kod niezgodny z bezpieczeństwem danej architektury, w której wykonany jest projekt.

Przypadek 4 – ryzyko licencjyne

Obecnie modele AI potrafią wyszukiwać informacje w internecie (jest to skrót myślowy, natomiast chodzi o sam skutek tego mechanizmu). W internecie są dostępne różne źródła informacji i źródła kodu pod różnymi licencjami:

• Repozytoria na licencjach GPL/AGPL – które wymagają otwartego kodu źródłowego dla pochodnych
• Repozytoria na licencjach Apache/MIT/BSD – które w większości przypadków można wykorzystać bez szkód w projektach komercyjnych
• Materiały na licencjach CreativeCommons – które wymagają na przykład atrybucji autora
• Wycieki kodów lub fragmenty kodów projektów komercyjnych, które podlegają pełnej ochronie praw autorskich

AI może wykorzystać „wewnętrzną” wiedzę oraz „zewnętrzne” źródła aby wytworzyć kod gotowy dla developera. Jednak developer może nawet nie wiedzieć, że przy niektórych fragmentach kodu może łamać postanowienia licencyjne. Długofalowe skutki dla biznesu można sobie bez problemu wyobrazić.

Podobne przykłady można mnożyć, jednak co jest kluczowe w tym momencie to przeanalizowanie co można z tym problemem zrobić.

Podsumowanie przypadków

Poniżej przedstawiam króktie podsumowanie tych czterech przypadków w formie tabelarycznej.

Jak widać z tego podsumowania – wyłaniają się dwa aspekty które właściciel biznesu oraz właścicel software houseu powinien rozważyć – jeden to aspekt co powinna zawierać umowa z klientem odnośnie wykorzystania AI w projekcie, a dwa – jakie zapisy licencyjne powinno zawierać AI tak, aby software house mógł z niego korzystać? I o ile pierwszy element leży mocno między software housem a biznesem i ciężko byłoby go tutaj przeanazliować, o tyle drugi przypadek możemy rozważyć i możemy porównać sobie licencje AI oraz co można faktycznie osiągnąć a co nie – w zależności od tego z jakiego dostawcy korzystamy.

Dostawcy modeli i narzędzi programistycznych

Rola HuggingFace w analizie licencji modeli

HuggingFace jest czołowym protalem, który daje dostęp i dostarcza możliwość hostowania wielu otwartoźródłowych modeli. Poza modelami bazowymi jest tam też ogrom modeli tak zwanych „fine tuningowanych” oraz ich kwantyzacje (które pozwalają przy niewielkiej stracie jakości na uruchamianie modeli na sprzętach nawet o połowę słabszych). Jednak pomijając inne aspekty HuggingFace, nas interesują licencje które występują na tym portalu – w kolejności od najbardziej popularnych są to:

• Apache2.0 (na przykład Flux2)
• MIT (na przykład GLM czy DeepSeek-OCR)
• OpenRail (na przykład Supertonic-2 TTS)
• CC-by-NC lub CC-BY-SA (na przykład NLLB-200)
• Llama (w różnych wersjach, oczywiście modele Llama i pochodne)
• Gemma (modele Gemma i pochodne)

Analizując już konkretny wybrany model, który wykorzystuje inne modele – przykład MoE (Mixture of Experts) lub jest modelem fine-tuningowanym, warto sprawdzić nie tylko licencję samego modelu ale też licencje modeli na których bazuje – może się okazać, że licencja modelu została źle dobrana.

Hugging Face ma tą przewagę, że udostępnia również modele tak zwane „uwolnione” – czyli bez cenzury – co może być istotne w niektórych zastosowaniach biznesowych.

Dostawcy ogólnego AI

Pierwszą kategorią do przeanalizowania są główni dostawcy AI, jakich znamy, czyli na przykład:

• ChatGPT od OpenAI
• Gemini od Google
• Claude od Anthropic

Należy tutaj jednak zwrócić uwagę, że warunki użytkownia modelu mogą się różnić w zależności od tego, czy korzystamy z modelu „bezpośrednio” (na przykład przez czat na stronie ChatGPT) czy też przez klucz API (gdzie mogą być dodatkowe ustawinia – na przykład dla rejonu europejskiego!). Jeśli różnice są znacące dla zakresu jaki tutaj sprawdzałem, to pojawi się osobni wpis w sekcji „Dostawcy AI API”.

Dostawcy AI API – model jako serwis

W tej kategorii znajdują się wszelkiego rodzaju dostawcy, którzy dostarczają API do wykorzystywania modeli, jednak tylko wtedy, gdy dla badanego zarkesu warunki się różniły. Czyli pojawi się tutaj na przykład wpis odnośnie OpenAI API, ale dla Perplexity – już nie, ponieważ warunki wykorzystania dostępnego API są praktycznie takie same, jak dla „zwykłego” klienta.

Wartu tu zwrócić uwagę, że choć większość dostawców stosuje branżowe standardy (jak MCP czy OpenAI API), o tyle zdarzają się wyjątki które nie zawsze są kompatybilne (jak np. Perplexity).

Asystenci AI dla programistów i analiza kodu

Oczywiście, poza modelami ogólnego zastosowania (które można wykorzystać nie tylko do kodowania, ale również do analiz biznesowych w firmie) istnieją też narzędzia dedykowane. Instykntownie można przeczuwać, że zapisy w warunkach użytkowania takich modeli mogą być dostosowane do przetwarzania i używania kodu – ale to sprawdzimy. Do tej grupy należą między innymi:

• Github Copilot
• Claude Code
• Cursor

Do tego istnieją narzędzia, które analizują kod, a nie są „asystentem” programisty, na przykład:

• Sourcegraph Cody
• Greptile

Ogólne zasady korzystania z „pobieralnych” modeli AI

Rozważmy metody korzystania modeli, które można pobrać – czyli wszystkich tych modeli, które można znaleźć na HuggingFace i „gdzieś” je zainstalować. Modele mają różne wielkości – ogólna zasada jest taka, że im większy model, tym lepszy, ale też potrzebuje lepszego sprzętu. Nie każdy model da się uruchomić na domowym sprzęcie, ale też nie zawsze chmura będzie odpowiednia dla biznesu. Więc:

• Stosunkowo niewielkie modele można uruchomić na domowym komputerze PC dużej mocy, więc technicznie programista może je mieć u siebie na komputerze. W takim wypadku nie istnieje większość problemów które poruszam w tym artykule.
  • „Domowe” narzędzia LLM opisywałem w tym artykule
• Dla większych modeli istnieją trzy główne opcje:
  • Albo wynajmowanie mocy przerobowych (na przykład kart graficznych) na godziny u usługodawcy (jak OVH) – co jednak wymaga umiejętności instalacji takich modeli
  • Albo usługi hostowania modeli (jaką na przykład udostępnia HuggingFace) – co jednak wymaga przeanalizowania warunków przetwarzania danych dla danej usługi
  • Albo skorzystanie z pośredników hostowania LLMów (jak na przykład OVH Public Cloud AI Endpoints czy LiteLLM).
• Istnieje również opcja zakupu sprzętu (na przykład obliczeniowych kart graficznych Nvidia) oraz hostowanie samemu – jednak jest to rozwiązanie skrajne dla specyficznych przypadków, których tu nie będę rozważał

Takie rozwiązania dają oczywiście najwięcej możliwej prywatności. Czy koszty utrzymania takich narzędzi będą pokrywać sens ich hostowania, utrzymywania i zarządzania samemu? To coś, co każdy biznes musi policzyć dla siebie sam bo mocno zależy to od skali i sposobu użycia.

Przeczytaj które z narzędzi najlepiej sprawdzi się w hostowaniu modeli lokalnych: https://sailingbyte.com/blog/the-ultimate-comparison-of-free-desktop-tools-for-running-local-llms/.

Ponieważ te modele są pobieralne, przeznaczyłem im osobny podpunkt odnośnie analizy licencji samych modeli. Natomiast alternatywą jest hostowanie takich modeli w chmurze – na przykład OVH AI Endpoints czy Google Vertex AI – i te usługi zostały porównane do innych wymienionych tu usług.

Krótka analiza licencji niektórych dostępnych modeli

Należy rozróżnić, że korzystając z narzędzia AI powinniśmy być zgodni na poziomie kilku „warstw” licencyjnych. Jedną warstwą jest dostawca (których porównujemy w dalszej części artykułu), a drugą warstwą jest sam model. I o ile nie ma za bardzo sensu analizować tych licencji pod kątem na przykład zgodności z GDPR, o tyle ma już sens analizowanie prawa do inputu i outputu. Taką analizę przeprowadziłem i tutaj są jej wyniki:

Przykładowe scenariusze dla tych licencji:

Jak więc widać – najbardziej otwartymi modelami do użytku komercyjnego są te oparte o licencje Apache, MIT i w niektórych przypadkach Llama oraz Gemma2. Natomiast w przypadkach wykorzystania „w pełni komercyjnych” modeli najlepszą opcją może się okazać korzystanie z pośrednika, który jest podpięty (lub udostępnia) API danego modelu.

Ocena dostawców pod kątem problematycznych aspektów

Dla wybranych dostawców zebrałem dane odnośnie miesjca przetwarzania danych, autorstwa i odpowiedzialności. Punkt na który praktycznie nie da się odpowiedzieć w prosty sposób to „ryzyko licencyjne” – każdy model i każde rozwiązanie korzystające z zasobów Internetu będzie obarczone tym ryzykiem. Moim zdaniem istnieje tu pewna luka biznesowa, którą możnaby wręcz wykorzystać do stworzenia narzędzia weryfikującego legalność kodu (jestem pewien że takie narzędzia też istnieją, ale nie jest to tematem niniejszego artykułu).

Ponadto każdego z dostawców należało rozważyć w kilku perspektywach: zwykłego użytkownika, użytkownika enterprise oraz dostępu przez API (oczywiście, tam gdzie to dostępne) – stąd tabela docelowa jest na tyle duża, że musiałem podzielić ją na sekcje aby była łatwiej czytelna.

Notatka ogólna odnośnie planów „Enterprise”

W zasadzie każdy z analizowanych dostawców ma w jakiejś formie opcję „enteprise” która jest „negocjowalna”, natomiast mało który dostawca ma sprecyzowane od samego początku czego się można spodziewać. Dlatego jeśli szukasz rozwiązania „enterprise” czy „team”, niestety, raczej niezbędne będzie skontaktowanie się z dostawcą bezpośrednio w celu przedstawienia konkretnej szczegółowej oferty. Osobiście uważam, że można traktować opcję płatną danego dostawcy jako punkt odniesienia w myśl zasady, że tak jak traktuje się „mniejszych”, to podobnego podejścia można spodziewać się przy „większych”. Natomiast wspominam o tym, ponieważ w takim układzie każdy punkt tabeli dotyczący „enterprise” trzeba przeanalizować faktycznie wynegocjowaną prywatną umowę, a nie bazować na reklamowych ogólnikach – dlatego że praktycznie każdy analizowany tu element jest na poziomie enterprise negocjowalny z dostawcą (wspominam o tym również, żeby nie wymieniać tego w każdym miejscu w tabelach w kontekście enterprise).

Miejsce przetwarzania danych i poziom zgodności z GDPR

O ile w przypadku modeli lokalnych lokalizacja jest oczywiście na własnym komputerze, o tyle różni dostawcy „chmurowi” mają różne lokalizacje. Do tego dochodzi deklaracja zgodności lub niezgodności z GDPR. Sytuacja może być bardziej skomplikowana przy dostawcach ogólnego AI, w przypadku których nie da się kontrolować regionu przetwarzania danych (tak jak jest to zazwyczaj możliwe przy API oraz przy hostingu LLMów.

Dostawcy ogólnego AI

Większość popularnych modeli (ChatGPT, Gemini, Claude) w planach konsumenckich przetwarza dane globalnie lub w USA, bez gwarancji rezydencji w UE, co wymusza poleganie jedynie na ogólnych politykach prywatności i standardowych klauzulach umownych w kwestii RODO. Sytuacja zmienia się diametralnie w planach Enterprise, gdzie giganci tacy jak OpenAI czy Google oferują wybór lokalizacji przetwarzania (w tym regiony europejskie) oraz podpisanie dedykowanych umów powierzenia danych (DPA). Wyjątkiem jest europejski Mistral, który domyślnie hostuje dane w UE zarówno dla konsumentów, jak i firm, zapewniając „native” zgodność z RODO bez konieczności skomplikowanej konfiguracji.

Dostawcy AI API

Dla usług API (OpenAI, Claude) standardem w planach podstawowych jest przetwarzanie danych na serwerach w USA, przy czym OpenAI API wyróżnia się możliwością wyboru rezydencji danych (USA lub Europa) dla kwalifikujących się klientów biznesowych, co jest kluczowe dla podmiotów z rygorystycznymi wymogami compliance. W kontekście RODO, obie firmy oferują klientom komercyjnym aneks o przetwarzaniu danych (DPA) z klauzulami SCC, jednak to OpenAI zapewnia bardziej elastyczne podejście do lokalizacji danych „at rest” w Europie w ramach swojej platformy API.

​Asystent Programisty

Rynek asystentów kodowania jest mocno spolaryzowany: rozwiązania chmurowe (GitHub Copilot, Codeium) w wersjach darmowych zazwyczaj transferują dane do USA, podczas gdy plany Enterprise wprowadzają możliwość wyboru regionu UE (np. GitHub Enterprise Cloud, Codeium we Frankfurcie). Z perspektywy RODO najbezpieczniejszą opcją są narzędzia umożliwiające działanie w trybie „local-first” lub „self-hosted” (Tabnine, Continue, OpenClaw), gdzie kod w ogóle nie opuszcza infrastruktury firmy, co eliminuje problem transferu danych. Biorąc jednak pod uwagę balans między użytecznością chmury a zgodnością, GitHub Copilot w wersji Enterprise oferuje najbardziej kompleksowe ramy prawne (EU Data Boundary) i techniczne.

​Infrastruktura AI

Dostawcy infrastruktury dzielą się na globalnych gigantów (Azure, Google Cloud), którzy oferują regiony w UE i zaawansowane mechanizmy rezydencji danych w planach Enterprise, oraz dostawców europejskich. W kwestii RODO wszyscy główni gracze zapewniają zgodność poprzez DPA, jednak OVHcloud wyróżnia się jako dostawca „suwerenny”, podlegający pod jurysdykcję francuską i oferujący standardy SecNumCloud, co czyni go bezkonkurencyjnym w kwestii prawnej ochrony danych przed dostępem zagranicznych jurysdykcji (np. US CLOUD Act).

​Analiza kodu AI

Narzędzia do analizy kodu w chmurze (np. Sourcegraph Cody) domyślnie przetwarzają dane w USA, oferując zgodność z RODO głównie poprzez polityki prywatności i DPA w planach wyższych. Dla firm wymagających ścisłej kontroli, kluczowa jest dostępność opcji „self-hosted” lub „VPC” (dostępna w Sourcegraph Enterprise czy Greptile), która pozwala zamknąć dane wewnątrz własnej infrastruktury, zapewniając pełną zgodność z wewnętrznymi regulacjami bezpieczeństwa i RODO.

Prawa do inputu i outputu oraz przenoszenie praw autorskich

Dostawcy ogólnego AI

W kategorii dostawców ogólnego AI, jak ChatGPT, Claude czy Gemini, użytkownicy konsumenccy zazwyczaj zachowują prawa do inputu, zyskując pełne lub częściowe prawa do outputu, choć dostawcy jak OpenAI i Anthropic oferują opt-out z licencji na ulepszanie usług; w planach enterprise prawa do outputu są w pełni przenoszone na klienta, z zachowaniem własności inputu. Polityka uczenia modeli w planach darmowych pozwala na wykorzystanie danych z opcją opt-out u większości (np. Claude, Perplexity), podczas gdy enterprise gwarantuje brak trenowania na danych klienta, z wyjątkiem feedbacku.

Dostawcy AI API

Usługi API jak OpenAI API i Claude API zapewniają zachowanie praw do inputu i outputu przez użytkownika w obu planach, z pełnym przeniesieniem własności outputu na klienta w enterprise, bez roszczeń dostawcy. W zakresie uczenia modeli dane API nie są domyślnie wykorzystywane do treningu w żadnym planie, chyba że explicit opt-in lub feedback, z opcjami Zero Data Retention dla kwalifikujących klientów.

Asystent Programisty

W kategorii asystentów programistów (np. GitHub Copilot, Tabnine, Cursor IDE) prawa do inputu pozostają u użytkownika, a output/sugestie są zazwyczaj własnością użytkownika po akceptacji, z minimalnymi roszczeniami dostawców w planach pro/enterprise. Uczenie modeli na inputach darmowych jest możliwe z opt-outem (np. Copilot Free), ale enterprise plany jak GitHub Copilot Business całkowicie zabraniają treningu na danych klienta. Tabnine – polityka no-train no-retain na kodzie użytkownika i pełne prawa do sugestii.

​Infrastruktura AI

Platformy infrastrukturalne jak Microsoft Azure AI, OVHcloud (absolutny brak uczenia i retencji danych) czy Together AI gwarantują pełne zachowanie praw do inputu i przeniesienie praw do outputu na użytkownika, często z dodatkową ochroną IP w enterprise (np. CCC w Azure). Polityka uczenia jest restrykcyjna: zero treningu na danych klienta bez zgody, z politykami Zero Retention w OVHcloud i Together AI, nawet w planach bazowych.

​Analiza kodu AI

Dla analizatorów kodu jak Sourcegraph Cody czy Greptile, użytkownik zachowuje pełne prawa do inputu i outputu we wszystkich planach, z jasnymi deklaracjami własności kodu i wyników. Uczenie modeli jest zabronione w enterprise (np. Cody Enterprise z ZDR), a w darmowych – ograniczone lub z opt-outem dla celów analitycznych. Sourcegraph Cody – explicit retain ownership wszystkich inputów i outputów z zerowym treningiem w enterprise.

Odpowiedzialność za błędy

Dostawcy ogólnego AI

Usługi jak ChatGPT OpenAI, Gemini Google czy Claude Anthropic dostarczane są „as is” bez gwarancji dokładności, z limitem odpowiedzialności do kwoty opłat z 6-12 miesięcy lub 100 USD; użytkownik ponosi ryzyko błędów i musi weryfikować output. W planach enterprise limity pozostają podobne, choć z wyjątkami na indemnifikację za IP (np. Anthropic bez limitu na odszkodowania), przerzucając większość ryzyka na klienta.

Dostawcy AI API

Dla API jak OpenAI API i Claude API obowiązują standardowe „as is” bez gwarancji, z limitami odpowiedzialności do opłat z 12 miesięcy i wyłączeniem szkód pośrednich; brak specjalnych gwarancji nawet dla enterprise. Użytkownik akceptuje ryzyko błędów outputu, z fokusem na weryfikację.

Asystent Programisty

Asystenci jak GitHub Copilot, Tabnine czy Amazon Q oferują output „as is”, z pełną odpowiedzialnością użytkownika za błędy, licencje i weryfikację; limity do 100 USD lub opłat 6-12 miesięcy. W enterprise dodawana jest często IP indemnity (np. Copilot Copyright Commitment, Amazon Q), ale bez gwarancji merytorycznej poprawności.

Infrastruktura AI

Platformy infrastrukturalne (HuggingFace, Vertex AI, Azure AI) stosują „as is” z limitami do opłat 12 miesięcy lub 50-100 USD, użytkownik weryfikuje output samodzielnie. Enterprise plany dodają SLA kredyty i negocjowalne indemnifikacje (np. Vertex AI dwuetapowa, Together AI do 1M USD).

Analiza kodu AI

W analizatorach jak Sourcegraph Cody czy Greptile pełna odpowiedzialność za błędy leży po stronie użytkownika, z „as is” i wyłączeniami gwarancji. Enterprise oferuje uncapped indemnity za IP w outputach (np. Sourcegraph).

Zestawienie – plik do pobrania

Źródłowa tabela jest stosunkowo duża oraz zawiera podział na enterprise i „zwykły” komercyjny, a także dodatkowe uwagi. Miejscami używane są skróty, które tutaj wypisuję. Link do pobrania pełnej wersję tabeli znajdziesz poniżej – jest ona po prostu za duża żeby umieścić ją bezpośrednio w artykule.

Słowniczek skrótów

• GDPR: Ogólne rozporządzenie o ochronie danych (General Data Protection Regulation), unijne prawo regulujące przetwarzanie danych osobowych, często wspominane w kontekście zgodności usług AI z RODO.
• RODO: Rozporządzenie o ochronie danych osobowych, polska nazwa GDPR, określające wymagania dla przetwarzania danych w usługach konsumenckich i enterprise.
• DPA: Data Processing Addendum (Dodatek Przetwarzania Danych), umowa regulująca role procesora i administratora danych w kontekście zgodności z GDPR dla planów enterprise.
• ZDR: Zero Data Retention (zero retencji danych), mechanizm zapewniający brak przechowywania danych wejściowych i wyjściowych po przetworzeniu, dostępny w niektórych planach enterprise API.
• SCC: Standard Contractual Clauses (Standardowe Klauzule Umowne), mechanizm prawny umożliwiający transfer danych poza EOG z zachowaniem zgodności z GDPR.
• SOC: System Organization Controls (np. SOC 2 Type II), standard certyfikacji bezpieczeństwa i kontroli wewnętrznych, potwierdzający zgodność usług AI z wymogami audytu.
• CCPA: California Consumer Privacy Act, amerykańskie prawo ochrony prywatności konsumenckiej, wspominane w kontekście zgodności usług dla klientów z USA.
• Input: Dane wejściowe wprowadzane przez użytkownika do modelu AI, takie jak prompty lub treści, do których odnoszą się prawa autorskie i zakazy trenowania.
• Output: Dane wyjściowe generowane przez model AI, np. odpowiedzi lub sugestie kodu, co do których usługodawcy często przenoszą prawa własności użytkownikowi.

Link do pliku Google Sheets: https://docs.google.com/spreadsheets/d/1AVLby5kZm6iFZANlvAt9Z20EqXo4msQJWrg76WoitLE/edit?usp=sharing

Używanie AI a koszt tworzenia oprogramowania

Obecnie istnieje bardzo duża rozbieżność zarówno w wynikach badań jak i w subiektywnych odczuciach odnośnie tego jak używanie AI wpływa na efektywność developerów. Kto ma w tym interes (bo albo jego narzędzie jest zbudowane wokół AI albo nawet sam prowadzi firmę mocno związaną z AI) zawsze zachwala rozwiązania, mówi o „końcu developmentu” i o „niepotrzebnych programistach”. Z drugiej strony znamy już przypadki, gdzie kody stworzone przez AI nadają się jedynie do wyrzucenia, lub programiści tracili więcej czasu na sprawdzanie i naprawianie bezsensownego kodu, niż jakby mieli go pisać sami. W ocenie Sailing Byte – dla mądrego, świadomego i znającego prompt engineering programisty efektywność wzrośnie, jednak jeśli inżynier zbyt polega na wygenerowanym kodzie, to spotka go srogie rozczarowanie. Jednocześnie wzrost efektywności przychodzi z ceną, bo za dobre narzędzia AI lub firmową infrastrukturę należy płacić, a nie jest to tanie narzędzie. Sumarycznie więc odbiorca biznesowy może albo próbować stworzyć „swój kod” samemu ryzykując stabilnością i bezpieczeństwem (co może mieć biznesowe uzasadnienie na przykład w tworzeniu prototypów), ale przy korzystaniu z usług śwadomego software houseu raczej nie powinien się spodziewać obniżki cen na tym etapie ze względu na „lepszą efektywność”.

Podsumowanie

Zacznę od bradzo ważnej uwagi – choć dołożyłem wszelkiej staranności aby informacje prezentowane tutaj były jak najbliższe prawdzie, jednak mogą zawierać błędy, a ja nie jestem prawnikiem. Ponadto regulacje i zasady przetwarzania danych u każdego dostawcy mogą się zmieniać. To zestawienie ma charakter orientacyjny. Zawsze pamiętaj, żeby sprawdzić aktualne zapisy w politykach prywatności i regulaminach danych usług przed pojęciem biznesowej decyzji i przed korzystaniem z jakiegokolwiek oprogramowania.