OC zawodowe w IT — dla freelancera i software house

Wyobraź sobie taką scenę: wdrażasz system, klient odpala go na produkcji i przez tydzień wszystko niby działa. A potem… okazuje się, że przez jeden brakujący warunek w kodzie zamówienia liczyły się błędnie i firma straciła kilkaset tysięcy złotych. No i nikt tu nie spłonął, nikt nie trafił do szpitala — pieniądze po prostu wyparowały z konta klienta. A klient teraz patrzy na ciebie. To nie jest jakiś horror dla programistów, tylko dokładnie ten rodzaj szkody, pod który powstało OC zawodowe w IT.

Forsal opisuje realny przypadek: „Błąd w kodzie uruchomił niekontrolowany przejazd maszyny i uderzenie w infrastrukturę” — rachunek wyszedł na 25 738 euro. W innej historii „w kodzie zabrakło jednego warunku bezpieczeństwa — tego, który blokuje obrót, gdy robot znajduje się” w strefie ryzyka, i to kosztowało 11 443 euro. I tu uwaga: wcale nie musisz pisać oprogramowania do fabryk, żeby narobić strat. Wystarczy źle policzony rabat w sklepie albo wyciek bazy mailingowej, i już.

Czym to się w ogóle różni od zwykłego OC działalności?

No bo tu jest pies pogrzebany. Ta tania polisa OC działalności gospodarczej, którą agent dorzuca do pakietu za stówę miesięcznie, chroni głównie przed szkodami w mieniu i na osobie — ktoś się poślizgnie w twoim biurze, zalejesz sąsiada, uszkodzisz sprzęt klienta. A w IT szkoda prawie nigdy tak nie wygląda. Tu dominuje coś, co ubezpieczyciele nazywają czystą stratą finansową: klient traci pieniądze, choć fizycznie nic się nie zepsuło.

I właśnie tę kategorię ogólne OC zwykle wyłącza, albo mocno przycina. Sednem polisy zawodowej dla IT (spotkasz ją też jako PI albo Errors & Omissions) jest to, że — cytując ujęcie branżowe — „ubezpieczyciel przejmuje na siebie finansowe konsekwencje błędów popełnionych przy świadczeniu usług informatycznych”. Błąd w kodzie, opóźnione wdrożenie, źle skonfigurowany system, naruszenie przepisów o ochronie danych — to akurat ten grunt, na którym żyje ten produkt.

A freelancer też? Przecież to klient jest ubezpieczony

To chyba najczęstszy błąd w myśleniu jednoosobowej działalności. „No przecież robię w software housie jako B2B, oni mają swoje polisy, mnie to nie dotyczy”. Otóż dotyczy, i to boleśnie. Jeśli zawalisz i to ty wprowadziłeś ten feralny commit, ubezpieczyciel klienta wypłaci odszkodowanie, a potem ma — jak to ładnie ujmują w branży — „prawo do regresu”, czyli po prostu przyjdzie po zwrot tych pieniędzy do ciebie. A bez polisy odpowiadasz wtedy majątkiem osobistym. Mieszkanie, oszczędności, samochód — wszystko w grze.

Dlatego coraz częściej posiadanie OC zawodowego nie jest twoim wyborem, tylko warunkiem w umowie. Klient korporacyjny każe ci pokazać polisę z konkretną sumą, zanim w ogóle dostaniesz dostęp do repo. To zresztą zgrywa się z tym, co mówi rynek ubezpieczeń. Bankier.pl, opisując dyskusję o obowiązkowym OC dla informatyków, cytuje przedstawiciela PZU: „Mechanizm obowiązkowego OC z jednolitym, ustawowym zakresem mógłby nie odpowiadać tej różnorodności”. Czyli odgórnego przymusu raczej nie będzie, ale — jak zauważają ubezpieczyciele — „rynek sam w naturalny sposób wymusza posiadanie OC poprzez wymagania kontraktowe”. Mniej ustawa, więcej dział prawny twojego klienta.

A software house — to co innego niż solo?

No tak, skala ryzyka rośnie razem z firmą. Im więcej projektów, kontraktów i ludzi dotykających kodu, tym większe prawdopodobieństwo, że gdzieś coś pójdzie nie tak. Software house, który robi wdrożenia za setki tysięcy złotych, potrzebuje sumy gwarancyjnej zupełnie z innej półki niż freelancer dorabiający przy landing page’ach. W branży mówi się wprost, że „sumy gwarancyjne w ubezpieczeniach OC mogą sięgać milionów złotych”, a w praktyce spotyka się polisy z ochroną rzędu 5 mln zł i wyżej.

Dochodzi tu jeszcze jedno: kto właściwie jest objęty polisą. W software house ochrona powinna rozciągać się na pracowników i podwykonawców, a nie tylko na spółkę jako podmiot. Bo jeśli błąd popełni junior na umowie zlecenie, a polisa go akurat nie obejmuje… no to robi się nieprzyjemnie. Przy większej firmie znaczenie ma także obrót i geografia przychodów — projekty dla klientów z USA czy Kanady potrafią windować składkę, bo tam pozwy i odszkodowania są w zupełnie innej lidze.

Na co realnie patrzeć w OWU?

I tu zaczyna się robota, którą większość po prostu pomija. Sama nazwa „OC dla IT” nic nie znaczy, dopóki nie sprawdzisz, co tak naprawdę siedzi w warunkach. Kilka rzeczy, na których warto się zatrzymać, a mianowicie:

• Suma gwarancyjna. Branżowo podkreśla się, że „odpowiedzialność do np. 200 000 zł może okazać się za mała”. Dopasuj ją do wartości największego kontraktu, nie do tego, co najtańsze.
• Czysta strata finansowa. Bez tego w zakresie polisa dla programisty jest w sumie głównie ozdobą — to przecież najczęstszy typ szkody w IT.
• Odpowiedzialność kontraktowa. Sprawdź, czy nie jest wyłączona. Gdy klient pozywa cię za nienależyte wykonanie umowy (system nie działa, jak miał), a polisa kryje tylko czyny niedozwolone, to zostajesz z roszczeniem sam.
• Trigger czasowy. Jedne polisy chronią błędy z okresu trwania umowy także po jej zakończeniu, inne sięgają wstecz, przed start ochrony. To bywa różnica między wypłatą a odmową.
• Zakres terytorialny. Standardowo Polska i Europa, często z wyłączeniem USA i Kanady; te dorzuca się za dopłatą.
• CYBER w pakiecie. Branża radzi, żeby polisa „miała zawarty w sobie zakres zarówno OC, jak i CYBER. Najlepiej, aby oba zakresy obejmowała jedna umowa” — wtedy nie kłócisz się przy szkodzie, z której polisy płacić.
• Udział własny. Im niższy, tym mniej dołożysz z własnej kieszeni przy szkodzie.

No dobra, ile to realnie kosztuje?

Bez OWU pod ręką podam ci raczej widełki, bo każda wycena to osobna historia. Dla pojedynczego freelancera punktem odniesienia bywa kwota, o której pisze branża: „za niespełna 2 tys. zł rocznie można otrzymać bardzo szeroki zakres z sumą gwarancyjną rzędu 1 mln zł”. Przy minimalnym zakresie składki potrafią startować niżej, gdzieś w okolicach tysiąca złotych rocznie. A software house z dużymi kontraktami i wysoką sumą gwarancyjną zapłaci kilka tysięcy — bywa, że 5–7 tys. zł i więcej.

Na cenę wpływa kilka rzeczy naraz: wielkość firmy i obrót, liczba kontrahentów, branża klientów, geografia przychodów oraz to, jak ogarnięte masz procedury zarządzania ryzykiem. No i firma z porządnym code review, testami i backupami zapłaci mniej niż taka, która wrzuca na produkcję w piątek o 17 bez review.

A dlaczego w ogóle gra jest warta świeczki? Dobrze pokazuje to skala potencjalnych strat. Forsal przywołuje Knight Capital Group, gdzie błąd w oprogramowaniu w 2012 roku wygenerował stratę rzędu 440–460 mln dolarów w 45 minut. To oczywiście ekstremum, ale logika jest dokładnie ta sama na każdym poziomie: kod produkuje skutki finansowe szybciej, niż zdążysz w ogóle zareagować.

To co z tym zrobić w praktyce?

Zacznij od najprostszego pytania: jaki jest twój największy realny kontrakt i jaką szkodę mógłbyś nim wyrządzić? To wyznacza minimalną sensowną sumę gwarancyjną. Potem przejrzyj umowy z klientami — jeśli wymagają polisy, mają tam zwykle wpisaną wartość, której musisz dotrzymać. A na końcu poproś o OWU, nie tylko o cenę, i sprawdź trzy rzeczy: czystą stratę finansową, odpowiedzialność kontraktową i trigger czasowy. Jeśli któregoś brakuje, to nie jest tańsza polisa, tylko po prostu gorsza.

I uczciwie na koniec: to tekst informacyjny, nie oferta ani porada ubezpieczeniowa. Zakresy i wyłączenia różnią się między ubezpieczycielami i to OWU konkretnej polisy jest wiążące — zanim podpiszesz, porównaj kilka ofert i dopytaj agenta o swoje przypadki. A ty — masz już polisę dopasowaną do tego, co realnie wdrażasz, czy raczej liczysz na to, że klient nigdy nie powie „sprawdzam”?