Smlouva o IT službách 2026: SLA, vzor a 12 chyb

Smlouva o IT službách je v roce 2026 paradoxně nejčastější nepojmenovaná smlouva v české ekonomice. Občanský zákoník 89/2012 Sb. (NOZ) ji jako samostatný typ neupravuje — místo toho si strany kombinují § 1746 (smlouvy inominátní), § 2586 (smlouva o dílo) a § 2430 (mandátní smlouva) podle toho, jestli jde o jednorázový vývoj, průběžnou údržbu nebo konzultace. A přesně tady začínají problémy: smlouva, kterou kdosi překopíroval z webu před pěti lety, dnes neřeší ani polovinu toho, co potřebujete pro reálný provoz.

Tento průvodce vás provede tím, co musí smlouva o IT službách v roce 2026 obsahovat: správnou právní bázi, SLA tabulku s prioritami P1-P4, sankce za nedodržení dostupnosti, převod autorských práv (a proč to není totéž jako u zaměstnance), GDPR DPA dodatek, exit plan a typické cenové modely. Na konci najdete vzor klíčových ustanovení, který si můžete použít jako kostru pro vlastní šablonu.

1. Právní báze: jaký typ smlouvy vlastně potřebujete

První rozhodnutí, které ovlivní celou smlouvu, je typ právního vztahu. IT služby nejsou homogenní kategorie — pod jeden název se schovávají čtyři velmi různé činnosti, každá s jiným režimem podle NOZ.

Vývoj software jako smlouva o dílo (§ 2586)

Jednorázový vývoj — eshop, mobilní aplikace, custom CRM, plugin do WordPress — spadá pod smlouvu o dílo podle § 2586 NOZ. Klíčové znaky: konkrétní výsledek (dílo), předem dohodnutá cena, akceptační proces, odpovědnost za vady díla po dobu dvou let (§ 2629 NOZ, pokud strany nedohodnou jinak). Vývojář se zavazuje k výsledku, ne k „nejlepší snaze\“.

Údržba a podpora jako inominátní smlouva (§ 1746)

Měsíční podpora hotového systému je nejčastěji smlouva inominátní s prvky smlouvy mandátní. § 1746 NOZ umožňuje stranám sjednat smlouvu, která neodpovídá žádnému pojmenovanému typu — ideální pro IT, kde se „služba\“ skládá z monitoringu, reakce na incidenty, drobných úprav a konzultací. Důležité je, že právě tady má SLA reálnou hodnotu, protože se měří kontinuálně, ne jen u akceptace díla.

SaaS a hosting

Pronájem hotové aplikace (SaaS) nebo serverové kapacity (hosting) se právně blíží nájmu věci (§ 2201 a násl.) nebo smlouvě o poskytování služeb. V praxi se používá inominátní smlouva s explicitními ujednáními o dostupnosti, datech klienta, vlastnictví dat a exit plánu. Klíčové je rozlišit, kdo vlastní data: data zákazníka zůstávají zákazníkovi, kód platformy poskytovateli.

Konzultace jako mandátní smlouva (§ 2430)

Pokud jen radíte (architektura, code review, security audit, výběr technologie), jde o mandátní smlouvu podle § 2430 NOZ. Tady je předmětem činnost, ne výsledek — konzultant odpovídá za odbornou péči, ne za to, že klient na základě rady zbohatne nebo se vyhne ztrátě.

2. Co je SLA a proč je dnes nepostradatelné

SLA (Service Level Agreement) je ta část smlouvy, která definuje měřitelnou kvalitu služby. Bez SLA má klient pocit, že platí za „dostupnost\", ale když dojde k výpadku, nemá vůči poskytovateli žádnou smluvní páku. Bez SLA má poskytovatel pocit, že dělá maximum, ale klient ho viní z každé hodiny zpoždění. SLA je společný měřič reality — čísla, na která se obě strany odvolávají, místo emocí.

V praxi má SLA tři vrstvy: dostupnost (uptime), reakční doba (response time) a doba vyřešení (resolution time). K nim se připojuje plán plánované údržby (maintenance window) a sankční mechanismus pro případ, že SLA poskytovatel nedodrží.

3. Klíčové metriky SLA: uptime, response, resolution

Uptime (% dostupnosti)

Uptime se vyjadřuje v procentech za zúčtovací období (typicky kalendářní měsíc). Standardní hodnoty:

Response time (doba reakce)

Reakční doba je interval od nahlášení incidentu klientem do okamžiku, kdy poskytovatel potvrdí, že na incidentu pracuje — není to ještě vyřešení. Typické hodnoty:

• P1 (kritický): 15 minut až 1 hodina
• P2 (vysoký): 2-4 hodiny
• P3 (střední): 4-8 hodin (v pracovní době)
• P4 (nízký): do následujícího pracovního dne

Resolution time (doba vyřešení)

Doba vyřešení je čas od nahlášení do okamžiku, kdy je služba zpět ve smluveném stavu. Pozor: ne každý problém má jednoznačné „vyřešení\“ — u komplexních bugů se často smlouvá o workaroundu(dočasné řešení) jako milník, ne o trvalé opravě. Smlouva by to měla rozlišovat.

MTTR (Mean Time To Recovery)

MTTR je průměrná doba zotavení napříč všemi incidenty v zúčtovacím období. Slouží jako agregovaná metrika kvality, ne jako ukazatel jednotlivého incidentu. Hodí se pro reporting na C-level — jeden outage je anekdota, MTTR za kvartál je trend.

4. Tabulka priorit P1-P4

Srdcem SLA je tabulka priorit. Definuje, jak rychle musí poskytovatel reagovat a vyřešit incident podle jeho dopadu. Tady je doporučená struktura pro středně velké provozy:

5. Maintenance window: plánovaná údržba

Plánovaná údržba se nezapočítává do výpadku, pokud je řádně oznámena. Standard:

• Časové okno: typicky 22:00-04:00 v pracovní dny, nebo víkendy 06:00-10:00
• Oznámení: minimálně 48-72 hodin předem (e-mail + statuspage)
• Maximální délka: typicky 4 hodiny / měsíc
• Emergency maintenance: u kritických bezpečnostních patchů možnost zkrátit oznámení na 2 hodiny — ale smlouva musí tento režim výslovně povolit

6. Cenové modely: paušál, hodina, per incident

Cenu lze v IT službách strukturovat třemi způsoby. Nejlepší smlouvy kombinují všechny tři — paušál na předvídatelnost, hodinovku na flexibilitu, per-incident sazbu na okrajové případy.

Fixní měsíční paušál

Klient platí dohodnutou částku každý měsíc bez ohledu na to, kolik incidentů nastane. Orientační rozsah 2026:

• Malé firmy / freelance klient:5 000 - 15 000 Kč/měs (webhosting, drobné úpravy, e-mail support)
• Střední firma s vlastním systémem:15 000 - 50 000 Kč/měs (SLA 99,5 %, response P1 do 1 h)
• Enterprise SaaS / e-shop:50 000 - 200 000 Kč/měs (24/7 on-call, vyšší SLA)

Hodinová sazba

Hodinová sazba se uplatňuje nad rámec paušálu nebo místo něj u nárazové práce. Aktuální tržní rozpětí v ČR (2026):

• Junior vývojář / IT support: 700-1 200 Kč/hod
• Mid-level vývojář: 1 200-1 800 Kč/hod
• Senior / specialista: 1 800-2 500 Kč/hod
• Konzultant / architekt / DevOps: 2 500-4 000 Kč/hod

Per-incident

Méně časté — vhodné pro low-volume kontrakty, kde se incident vyskytne jednou za měsíc. Cena za incident typicky 2 500-10 000 Kč + případně blokovaný čas (např. první 4 hodiny v ceně, dalších 4 hod účtováno hodinově).

7. Kapacitní limit a extra hodiny

Paušál téměř vždy obsahuje kapacitní limit — určitý objem práce zahrnutý v ceně. Mimo limit se účtuje hodinovou sazbou. Typická struktura:

• Paušál 20 000 Kč/měs = 10 hodin práce zahrnuto
• Extra hodiny: 1 500 Kč/hod
• On-call hodiny mimo pracovní dobu: 1,5× sazba (2 250 Kč/hod)
• Nepoužité hodiny: typicky nepřevoditelné do dalšího měsíce (jinak by paušál ztratil smysl)

8. Autorská práva: work for hire není česká kategorie

Tady udělá většina freelance smluv kritickou chybu. V USA existuje institut work for hire, kdy autorská práva přecházejí automaticky na objednatele. V Česku to tak nefunguje.

Zaměstnanec vs. OSVČ

Podle § 58 zákona č. 121/2000 Sb. (autorský zákon) má zaměstnavatel automaticky výhradní licenci k zaměstnaneckému dílu, které zaměstnanec vytvoří při plnění pracovních povinností. Tady je převod majetkových práv „vestavěný\“ a smlouva o IT službách to neřeší.

U OSVČ (freelancera) nebo dodavatelské firmy ale taková zákonná automatika neplatí. Autorská majetková práva zůstávají u tvůrce, dokud je výslovně nepostoupí nebo neudělí licenci. Pokud smlouva o IT službách mlčí, klient dostane kód bez práva ho upravovat, dál distribuovat ani převést na jiného dodavatele. To je recept na soudní spor při ukončení spolupráce.

Postoupení vs. licence

Podle § 2358 NOZ a autorského zákona má klient dvě možnosti:

• Výhradní licence: nejčastější varianta. Klient může kód používat, upravovat, předat jinému dodavateli. Tvůrce si ponechá autorství, ale nemůže kód licencovat někomu dalšímu.
• Postoupení (převod) majetkových práv: klient se stane „majitelem\“ majetkových práv. Vhodné u zakázkového vývoje, kde klient chce mít absolutní kontrolu (např. plánuje exit firmy).

9. NDA a GDPR DPA

IT služby téměř vždy zahrnují přístup k citlivým informacím a osobním údajům. Smlouva má proto dvě povinné vrstvy:

NDA (Non-Disclosure Agreement)

Mlčenlivost o obchodním tajemství, technologiích, klientech a interních procesech. Typicky doba trvání 3-5 let po skončení smlouvy. Smluvní pokuta za porušení by měla být přiměřená — soudy v ČR pravidelně snižují nepřiměřené pokuty podle § 2051 NOZ. Obvyklé rozpětí: 50 000-500 000 Kč za prokázané porušení, případně s víceúrovňovou pokutou.

GDPR DPA (Data Processing Agreement)

Pokud poskytovatel zpracovává osobní údaje klienta nebo jeho zákazníků (provozuje e-shop, CRM, e-mailing, databázi uživatelů…), je DPA podle čl. 28 GDPR povinný. Bez něj poskytovatel není legálně oprávněn osobní údaje zpracovávat. DPA pokrývá:

• Účel a rozsah zpracování
• Kategorie subjektů údajů a typy údajů
• Bezpečnostní opatření (šifrování, backup, přístupová práva)
• Sub-procesory (pokud poskytovatel používá AWS, Vercel, Stripe…)
• Notifikační povinnost při breachi (72 hodin)
• Postup po skončení smlouvy (smazání / vrácení dat)

10. Sankce za nedodržení SLA

SLA bez sankce je marketing. Standardní mechanismus „SLA credit\“:

Druhá vrstva sankcí: pokuta za nedodržení reakční doby u P1/P2 incidentů — typicky 1-5 % měsíčního paušálu za každou započatou hodinu nad limit, s celkovým stropem 25-30 % paušálu.

11. Ukončení a exit plan

Nejvíc bolestivá část každé IT smlouvy je její konec. Bez exit plánu zůstane klient držený v rukojmí přístupových údajů a tribal knowledge.

Výpovědní doba

Standard: 3 měsíce u běžné podpory, 6 měsíců u kritických systémů. Důvod: poskytovatel musí mít čas předat dokumentaci, klient musí najít a nasadit nového dodavatele. Příliš krátká výpovědní doba (1 měsíc) v praxi vede k chaosu.

Co musí být předáno

• Kompletní zdrojové kódy v dohodnutém repozitáři (typicky Git)
• Přístupové údaje (databáze, hosting, API klíče, doménový registrátor, e-mail)
• Technická dokumentace (architektura, deploy proces, CI/CD)
• Build instructions + lokální development setup
• Backup databáze (poslední čistý dump)
• Seznam externích služeb + sub-procesorů
• Otevřené tickety / known issues

Transition period

Často se přidává 30-60 denní „transition period\“ po skončení smlouvy, během kterého poskytovatel za hodinovou sazbu odpovídá na dotazy nového dodavatele. Hodinová sazba v transition period bývá vyšší (1,3-1,5× běžná) — motivuje obě strany dokončit přechod včas.

12. Vzor smlouvy o IT službách — klíčové části

Tady je kostra, kterou používají profesionální IT freelanceři a malé agentury. Není to kompletní smlouva — chybí standardní úvodní/závěrečná ustanovení, ale obsahuje jádrové paragrafy specifické pro IT služby:

Předmět smlouvy

„Poskytovatel se zavazuje pro Objednatele zajišťovat průběžnou podporu, správu a rozvoj informačního systému [název systému] v rozsahu a za podmínek stanovených touto smlouvou a její přílohou č. 1 (SLA). Smlouva se uzavírá jako smlouva inominátní podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník.\“

Rozsah služeb

„Rozsah služeb zahrnuje: (a) monitoring dostupnosti 24/7; (b) reakci na incidenty podle SLA tabulky v příloze č. 1; (c) drobné úpravy a customizace do limitu 10 člověkohodin měsíčně; (d) konzultace a e-mailovou podporu v pracovních dnech 9:00-17:00; (e) měsíční reporting plnění SLA.\“

Cena a platební podmínky

„Měsíční paušál činí 25 000 Kč bez DPH. Práce nad rámec kapacitního limitu jsou účtovány hodinovou sazbou 1 500 Kč/hod bez DPH. Fakturace měsíčně pozadu, splatnost 14 dní. Při prodlení platby vzniká nárok na zákonný úrok z prodlení podle nařízení vlády č. 351/2013 Sb.\“

Autorská práva

„Poskytovatel uděluje Objednateli výhradní, územně neomezenou, neodvolatelnou licenci ke všem dílům vytvořeným v rámci plnění této smlouvy, včetně práva na úpravy, rozšíření, sublicencování a převod práv na třetí osoby. Odměna za licenci je zahrnuta v ceně podle čl. X této smlouvy.\“

SLA a sankce

„Poskytovatel garantuje měsíční dostupnost služby 99,5 % (vyjma plánované údržby podle čl. Y). Při nedodržení garantovaného uptime vzniká Objednateli nárok na SLA kredit podle přílohy č. 1. Celkový SLA kredit za jeden kalendářní měsíc nepřesáhne 30 % měsíčního paušálu.\“

Ukončení smlouvy

„Smlouva se uzavírá na dobu neurčitou. Každá ze stran je oprávněna smlouvu vypovědět bez udání důvodu s tříměsíční výpovědní dobou, která začne běžet prvním dnem měsíce následujícího po doručení výpovědi. Po skončení smlouvy je Poskytovatel povinen do 14 dnů předat Objednateli kompletní zdrojové kódy, dokumentaci a přístupové údaje podle přílohy č. 2 (Exit plán).\“

13. Časté chyby v IT smlouvách

1. Vágně formulované SLA. „Reagujeme rychle\“ není měřitelné. Vždy uveďte konkrétní časy v hodinách + způsob měření.
2. Chybějící klasifikace incidentů. Bez P1-P4 končí každý ticket jako P1 podle klienta a P3 podle poskytovatele.
3. Žádný exit plan. Smlouva se nikdy neuzavírá s vědomím rozchodu — proto je exit plan tak často přehlédnutý a tak často kritický.
4. Neřešená autorská práva. U OSVČ kód patří OSVČ, dokud se nepostoupí. Klient si myslí, že platí za kód, ale platí za licenci — pokud to smlouva neřeší jinak.
5. Chybějící DPA k GDPR. Bez něj poskytovatel nesmí osobní údaje zpracovávat. ÚOOÚ to v kontrolách zjišťuje rutinně.
6. Nepřiměřené sankce.Pokuta 100 000 Kč za hodinu výpadku u paušálu 20 000 Kč/měs soud sníží.
7. Žádná moderation klauzule pro maintenance window. Pokud není výslovně řečeno, že maintenance window se nezapočítává do výpadku, klient si ji započte.
8. Chybějící definice „pracovní doby\“. 9-17 v pracovní dny, nebo 24/7? Liší se o řád ceny.
9. Žádné limity odpovědnosti. § 2898 NOZ umožňuje omezit odpovědnost u podnikatelských smluv. Bez cap na 1-3× měsíční paušál je každý velký výpadek existenčním rizikem freelancera.
10. Bez ujednání o sub-dodavatelích. Kdy smí poskytovatel delegovat práci? Komu? Co s GDPR sub-procesory?
11. Žádný change management. Jak se mění rozsah služeb v průběhu let? Bez procesu se z paušálu stane jednostranně rostoucí dluh.
12. Žádné review SLA jednou ročně. Po 3 letech jsou metriky zastaralé. Smlouva by měla obsahovat klauzuli „SLA review každých 12 měsíců\“.

14. Závěr: smlouva o IT službách je živý dokument

IT smlouva napsaná jednou a uzavřená do šuplíku stárne rychleji než kterákoli jiná. Technologie se mění, klient roste, regulatorní rámec (GDPR, NIS2, AI Act) se zpřísňuje. Profesionální freelance a malé agentury proto nepoužívají jednu „generic\“ smlouvu — mají vlastní šablonu, kterou ladí podle zkušeností z klientských sporů, a kterou aktualizují aspoň jednou za 12-18 měsíců.

Klíčových 80 % obsahu se opakuje pro každého klienta — SLA tabulka, autorská práva, DPA, exit plan. Zbylých 20 % jsou konkrétní jména, ceny a rozsah služeb. Pokud podepisujete novou smlouvu častěji než jednou za půl roku, vyplatí se mít šablonu v textovém procesoru a měnit jen variabilní pole.