Jak wybrać partnera do wdrożenia open source AI?

Open source AI to stos komponentów, a nie produkt jednego vendora, więc nie ma programu partnerskiego, w którym można sprawdzić poziom wykonawcy. Partnera trzeba ocenić po czterech rzeczach: jakie licencje mają użyte komponenty, kto będzie je utrzymywał i łatał, kto odpowiada za kod pochodzący ze społeczności oraz czy możliwe jest wsparcie komercyjne. Brak rankingu poziomów to nie wada, tylko zmiana pytań. Zamiast „jaki ma status?” pytacie „co dokładnie wdraża i kto za to odpowiada po wdrożeniu?”.

To uzupełnienie ogólnego poradnika o wyborze partnera do wdrożenia AI, gdzie są role, pytania i zasady umowy. Tu tylko to, co przy open source jest inne. Partner to firma wdrożeniowa albo freelancer. Vendora nie ma, a jeśli któryś komponent ma właściciela (jak model udostępniany przez firmę), jego warunki liczą się tak samo jak licencja.

Stan na 5 października 2026, według oficjalnych stron wymienionych w tekście. Całą serię według warstw porządkuje poradnik o suwerennym stosie AI.

Licencje komponentów: co dokładnie jest „otwarte”

Słowo „open source” bywa używane luźno. Organizacja OSI definiuje je w Open Source Definition (wersja 1.9, dziesięć kryteriów): swobodna redystrybucja, dostęp do kodu źródłowego, prace pochodne, brak dyskryminacji osób, grup i dziedzin zastosowań (definicja OSD). Licencje zgodne z tą definicją OSI zatwierdza i prowadzi ich listę (lista licencji).

Dla zarządu liczą się różnice w skutkach:

• Licencje permisywne (na przykład MIT, Apache-2.0) pozwalają na szerokie użycie. Apache License 2.0 zawiera ponadto wyraźną licencję patentową (tekst licencji).
• Licencje copyleft (na przykład GPL, AGPL) stawiają warunki wobec zmodyfikowanych wersji. AGPL-3.0 wymaga, by zmodyfikowana wersja udostępniana użytkownikom przez sieć oferowała im dostęp do kodu źródłowego (AGPL-3.0 w SPDX). To ważne, gdy partner dopisuje własne zmiany do komponentu, z którego korzystają klienci przez internet.
• Licencje „prawie otwarte”. Przykładem jest Llama 4 Community License Agreement od Meta (wersja z 5 kwietnia 2025). Firmy z ponad 700 milionami aktywnych użytkowników miesięcznie muszą uzyskać osobną licencję od Meta, dystrybucja wymaga oznaczenia „Built with Llama”, a obowiązuje też polityka dopuszczalnego użytku (licencja). OSI publicznie stwierdza, że ta licencja nie jest open source (stanowisko OSI). Dla firmy poniżej progu może to nie być problem, ale ocenia to prawnik, nie partner.

Pojęcie „otwarte wagi” to nie to samo co „Open Source AI”. Definicja OSI z 28 października 2024 (wersja 1.0) wymaga nie tylko wag modelu, ale też informacji o danych treningowych oraz kodu do trenowania i uruchamiania (definicja). Gdy partner mówi „użyjemy otwartego modelu”, poproście o nazwę licencji każdego komponentu. Agent AI zapytany o licencję odpowie pewnie i płynnie, a człowiek sprawdzi plik LICENSE.

Utrzymanie i aktualizacje bezpieczeństwa

W stosie komercyjnym o łatach decyduje vendor. W open source decyduje ktoś, kogo trzeba wskazać. Zapytajcie partnera o trzy rzeczy: kto śledzi nowe wersje i podatności komponentów, w jakim czasie wdraża poprawki i na czyj koszt. Bez odpowiedzi „wdrożyliśmy” znaczy „zadziała, dopóki nic się nie zmieni”.

Dobrym punktem odniesienia jest wspólnota OpenSSF, która zajmuje się bezpieczeństwem oprogramowania open source. Jej projekty dotyczą łańcucha dostaw: SLSA (integralność artefaktów), Sigstore (podpisywanie i weryfikacja), GUAC (wgląd w bezpieczeństwo łańcucha dostaw) (openssf.org). Nie musicie tego znać szczegółowo. Wystarczy, że partner umie powiedzieć, jak wie, że pobrany komponent jest tym, za co się podaje, i że ma spis komponentów, których używa.

Kto odpowiada za kod społeczności

Kod z repozytorium społeczności ma autorów, ale zwykle nie ma gwarancji ani zobowiązania do poprawek. Co licencja mówi o gwarancji i odpowiedzialności, sprawdźcie w jej tekście, na przykład w Apache License 2.0. Odpowiedzialność za jego wybór, konfigurację i integrację z Waszymi systemami spada więc na tego, kto go wdraża, czyli na partnera, a po wdrożeniu na Was. Ustalcie to w umowie: za co odpowiada partner (wybór, integracja, testy, poprawki w uzgodnionym okresie), a za co zostaje po Waszej stronie. To nie jest porada prawna: umowę ocenia prawnik.

Wsparcie komercyjne

Open source nie wyklucza wsparcia z umową i SLA. Rynek ma usługi subskrypcyjne, które obejmują aktualizacje bezpieczeństwa i pomoc techniczną. To przykłady rodzaju, nie rekomendacje: subskrypcje Red Hat Enterprise Linux obejmują wsparcie i aktualizacje bezpieczeństwa (Red Hat), a Ubuntu Pro deklaruje dziesięć lat poprawek podatności i w wariancie z pomocą wsparcie całodobowe (Ubuntu Pro). Pytanie do partnera: co z tego jest w jego ofercie, a co kupujecie sami u firmy, która wydaje system lub komponent.

Co ma zostać w firmie, żeby dało się zmienić partnera

Przy open source cena wyjścia jest zwykle niższa niż w stosie zamkniętym, ale tylko wtedy, gdy wszystko jest opisane. Poproście o:

• repozytorium z kodem i konfiguracją na Waszym koncie od pierwszego dnia,
• spis komponentów z wersjami i licencjami,
• pliki modelu, jego wersję i skąd został pobrany, wraz z opisem własnych dostrojeń,
• skrypty uruchamiania, konfiguracje środowiska i opis, jak odtworzyć system od zera,
• konta i klucze do infrastruktury zarejestrowane na firmę.

Szersze zasady własności są w poradniku głównym. Jak policzyć cenę wyjścia, opisuje wpis o zmianie vendora AI, umowie i danych. Cały temat modeli i licencji znajdziecie w sekcji Open Source AI.

Pytania do partnera przy open source AI

1. Jakie komponenty i jakie licencje (nazwy z pliku LICENSE) wchodzą do rozwiązania?
2. Czy któryś komponent ma warunki wykraczające poza licencję zatwierdzoną przez OSI, jak ograniczenia użycia lub progi liczby użytkowników?
3. Kto śledzi podatności i wydania komponentów i w jakim czasie wdrażacie poprawki?
4. Jak sprawdzacie pochodzenie pobieranych komponentów i modeli?
5. Za co odpowiadacie przy kodzie ze społeczności, a za co zostajemy my?
6. Czy macie lub polecacie wsparcie komercyjne dla kluczowych elementów stosu?
7. Czy inny wykonawca odtworzy środowisko z repozytorium i dokumentacji, bez Waszej pomocy?
8. Co dzieje się z rozwiązaniem, jeśli komponent przestanie być rozwijany albo zmieni licencję?

Co dalej

Jeśli zarząd chce wejść w open source z otwartymi oczami, pomagam po stronie firmy, niezależnie od vendora i partnera. Opisujemy problem i kryteria wyboru wykonawcy, a potem pilnuję, żeby powstało to, co zaprojektowane.