Masz już dwie, może trzy oferty na stole. Rozmowy się skończyły, zespół zadał swoje pytania, teraz zostaje tylko podpis. I właśnie w tym momencie większość firm popełnia błąd — czyta umowę pod kątem ceny i terminu, a pomija zapisy, które zdecydują, co się stanie za sześć miesięcy, gdy pilotaż się skończy albo gdy coś pójdzie nie tak.
Umowy na wdrożenie AI wyglądają do siebie podobne. Różnice ujawniają się dopiero wtedy, gdy trzeba z nich skorzystać — a wtedy jest już za późno na negocjacje.
Najważniejsze w skrócie
- Umowa na usprawnienie oparte o AI ma jedną cechę, której nie ma klasyczna umowa IT: niepewność wyniku. Nikt nie zagwarantuje z góry skuteczności na Twoich danych — i dobra umowa to uwzględnia zamiast udawać, że problemu nie ma.
- Platforma ≠ rozwiązanie. Płacisz za dostęp, który znika wraz z abonamentem, albo za coś, co zostaje Twoją własnością. To rozróżnienie decyduje o koszcie w skali lat.
- Trzy zapisy ważą najwięcej: własność kodu i danych, mierzalne kryterium sukcesu pilotażu i klauzula wyjścia.
- Milczenie umowy o własności kodu prawie zawsze oznacza, że własność zostaje po stronie dostawcy.
- Bez klauzuli wyjścia każdy pilotaż w praktyce zamienia się w zobowiązanie długoterminowe.
Dlaczego umowa na AI różni się od zwykłej umowy wdrożeniowej
Klasyczny projekt IT ma jasno opisany zakres: funkcje, terminy, akceptację. Projekt AI ma dodatkowo niepewność wyniku — nikt nie gwarantuje z góry, że model osiągnie założoną skuteczność na Twoich danych. To nie jest wada, to specyfika technologii. Ale oznacza, że dobra umowa musi odpowiadać na pytania, których w zwykłym wdrożeniu w ogóle by nie było: co się dzieje, jeśli pilotaż nie osiągnie progu sukcesu? Kto jest właścicielem tego, co powstanie? Czy po zakończeniu współpracy zostajesz z działającym narzędziem, czy z zależnością od dostawcy?
To właśnie tutaj przebiega granica między dostawcą, który sprzedaje dostęp do platformy, a partnerem, który buduje rozwiązanie działające na Twoich danych i zostające w Twojej firmie.
10 zapisów, które warto sprawdzić przed podpisem
1. Własność kodu i modelu po zakończeniu współpracy
Sprawdź wprost, kto jest właścicielem kodu, promptów, pipeline'ów i wytrenowanych komponentów po zakończeniu projektu. Jeśli umowa tego nie precyzuje, w praktyce zostajesz najemcą własnego narzędzia — dostawca może je wyłączyć, podnieść cenę abonamentu albo zablokować dalszy rozwój.
2. Dane klienta — gdzie są przetwarzane i kto ma do nich dostęp
Umowa powinna jasno określać, czy dane opuszczają Twoją infrastrukturę, na jakich zasadach są przetwarzane i co dzieje się z nimi po zakończeniu współpracy. To nie jest formalność prawna — to pytanie o to, czy konkurencja albo inny klient dostawcy korzysta pośrednio z wiedzy zbudowanej na Twoich procesach.
3. Mierzalne kryteria sukcesu pilotażu
Dobra umowa pilotażowa definiuje z góry, co oznacza „sukces" — konkretną liczbę, nie ogólnikowe „poprawę procesu". Skrócenie czasu wyceny z trzech dni do czterech godzin. Redukcja liczby błędów w zamówieniach o określony procent. Bez liczby z „przed" i liczby z „po" nie da się ocenić, czy pilotaż się udał, a to on decyduje, czy warto iść dalej.
4. Zakres integracji z istniejącymi systemami
Sprawdź, czy projekt zakłada wymianę ERP albo innego kluczowego systemu, czy raczej dedykowaną aplikację działającą obok, korzystającą z istniejących danych przez integrację. Wymiana systemu to inny poziom ryzyka, kosztu i czasu niż mikroaplikacja podłączona do tego, co już działa.
5. Harmonogram i kamienie milowe
Punktem odniesienia dla pilotażu AI powinno być 4–6 tygodni, nie pół roku. Umowa powinna wskazywać konkretne kamienie milowe w tym oknie — co dzieje się po tygodniu pierwszym, co po ostatnim. Brak kamieni milowych to sygnał, że dostawca sam nie wie, jak podzielić pracę na etapy możliwe do zweryfikowania.
6. Klauzula wyjścia
Co się dzieje, jeśli pilotaż nie osiągnie założonych progów? Dobra umowa opisuje wariant wyjścia bez dalszych zobowiązań finansowych i bez utraty tego, co już powstało. Brak takiej klauzuli oznacza, że każdy pilotaż w praktyce zamienia się w zobowiązanie długoterminowe.
7. Transfer kompetencji do zespołu
Sprawdź, czy umowa przewiduje przekazanie wiedzy Twojemu zespołowi — dokumentację, sesje robocze, możliwość samodzielnego utrzymania rozwiązania w podstawowym zakresie. Partner, który nie chce niczego przekazać, buduje sobie zależność, nie Twoją kompetencję.
8. Ścieżka po pilotażu
Umowa nie musi od razu wiązać Cię z pełnym wdrożeniem, ale powinna określać, jak wygląda przejście od pilotażu do rozwoju — na jakich zasadach, w jakim modelu rozliczeń, z jakim zespołem. Brak tej ścieżki oznacza renegocjację od zera w gorszej pozycji, bo pilotaż już Cię przekonał.
9. Model rozliczeń — za licencję czy za rozwiązanie
Zwróć uwagę, czy płacisz za dostęp do platformy (który znika, gdy przestajesz płacić), czy za zbudowane, należące do Ciebie rozwiązanie. To rozróżnienie decyduje, czy za trzy lata masz aktyw, czy koszt stały bez końca.
10. Referencje z mierzalnymi wynikami
Poproś o referencje z liczbami — nie „wdrożyliśmy u klienta X", tylko „skróciliśmy czas cyklu o Y w firmie o profilu podobnym do Twojego". Dostawca, który ma za sobą realne wdrożenia, potrafi podać takie liczby bez wahania.
