NIS2 + AI nástroje: co musí mít český tým nastavené, aby neporušil interní pravidla

AI nástroje se v českých firmách šíří rychleji než interní pravidla. Typický scénář vypadá jednoduše: obchod si shrne schůzku v ChatGPT, vývoj přepíše kus kódu přes GitHub Copilot, personalista si nechá upravit inzerát a vedení očekává vyšší produktivitu. Jenže z pohledu bezpečnosti a souladu s interními směrnicemi je problém jinde: kdo smí jaký nástroj používat, jaká data do něj smí vložit, kde se uchovávají logy, kdo schvaluje nové integrace a jak firma doloží, že měla nad používáním AI reálnou kontrolu.

NIS2 sama o sobě neříká, že firma musí zakázat generativní AI. Tlačí však na řízení rizik, správu přístupů, evidenci aktiv, zvládání incidentů, kontinuitu a odpovědnost vedení. Jakmile zaměstnanci používají externí AI služby při práci s firemními daty, vzniká nová vrstva třetích stran, nových toků dat a nových chybových stavů. Minimální nastavení proto nemá být teoretická směrnice do šuplíku, ale sada provozních pravidel, která se dají zkontrolovat a vynutit.

Tento článek shrnuje praktické minimum pro české firmy, které chtějí AI používat bez improvizace: co nastavit v procesech, přístupech a logování, co delegovat na IT a compliance, co má schvalovat management a kdy je naopak lepší AI do konkrétního kroku vůbec nepustit. Pokud teprve mapujete, které nástroje se ve firmách skutečně používají, hodí se i přehled AI nástrojů na AIVýběr. Pro srovnání konkrétních kancelářských asistentů je užitečný také rozcestník článků o ChatGPT, protože právě chatové nástroje bývají v praxi nejčastějším zdrojem nekontrolovaného sdílení dat.

1. Nejprve si určete, které AI nástroje jsou ve firmě povolené a v jakém režimu

První chyba bývá organizační: firma řeší školení promptů, ale nemá seznam schválených nástrojů a jejich povolených režimů. Minimem není „můžete používat AI rozumně“, ale krátký katalog služeb, který pro každou službu říká čtyři věci: k čemu ji lze použít, jaká data do ní nesmějí, kdo ji smí aktivovat a kdo je vlastníkem rizika.

OpenAI

V praxi se vyplatí rozdělit nástroje alespoň do tří tříd:

Povolené pro běžnou práci – například Microsoft Copilot pro Microsoft 365 v tenantovi firmy, pokud je nasazen s firemní identitou a správou přístupů.
Povolené pod podmínkou – například ChatGPT Team nebo Enterprise jen pro konkrétní útvary a jen bez vkládání zvláštních kategorií osobních údajů, obchodního tajemství nebo neveřejných smluv.
Zakázané – veřejné AI chatboty používané bez firemního účtu, anonymní rozšíření do prohlížeče, generátory textu a obrázků bez smluvního vztahu nebo bez možnosti dohledat zpracování dat.

Co dělat konkrétně: vytvořte jednostránkový „AI service register“. U každé služby uveďte název, poskytovatele, typ dat, lokaci zpracování podle oficiální dokumentace, dostupné administrátorské funkce, logování, způsob přihlášení a vlastníka ve firmě. Bez zápisu v registru se nástroj nesmí používat pro firemní data.

Pro koho: pro CIO, CISO, DPO, vedoucí IT a vlastníky procesů v HR, obchodě, zákaznické podpoře a vývoji.

Kdy to nepoužívat: pokud někdo prosazuje plošný zákaz všech AI služeb bez rozlišení. To sice vypadá bezpečně, ale v praxi vede ke stínovému používání osobních účtů a ztrátě kontroly.

Ověřitelné detaily u běžných služeb: OpenAI nabízí pro firmy plány Team a Enterprise, Microsoft nabízí Copilot pro Microsoft 365 a GitHub nabízí placené verze Copilotu pro firmy. Funkce jako SSO, správa uživatelů, auditní záznamy či omezení pluginů se liší podle tarifu. Orientační ceny: ChatGPT Team od 25 USD za uživatele a měsíc při roční platbě, ChatGPT Enterprise individuálně, Microsoft Copilot pro Microsoft 365 30 USD za uživatele a měsíc, GitHub Copilot Business 19 USD za uživatele a měsíc, GitHub Copilot Enterprise 39 USD za uživatele a měsíc. Ceny se mohou měnit a je nutné ověřit je v oficiálních cenících.

Jak má vypadat minimální rozhodovací pravidlo

Každý zaměstnanec by měl zvládnout během půl minuty rozhodnout, zda smí AI použít. Praktické pravidlo může znít takto: „Pokud úkol obsahuje neveřejná data o zákazníkovi, zaměstnanci, smlouvě, cenotvorbě, zdrojovém kódu nebo bezpečnostní architektuře, používej jen nástroj ze schváleného registru a pouze ve firemním účtu.“ To je výrazně účinnější než obecné výzvy k opatrnosti.

2. Nastavte datové hranice: co do AI nikdy nevkládat a co jen po schválení

Nejdůležitější provozní pravidlo není volba modelu, ale klasifikace dat. Většina problémů vzniká při kopírování obsahu do promptu: smlouvy, nabídky, bug reporty se jmény zákazníků, mzdové podklady, interní bezpečnostní postupy nebo neveřejné roadmapy. Pokud firma neurčí jasné hranice, zaměstnanci budou předpokládat, že „když je to jen shrnutí“, je to v pořádku. Není.

Praktické minimum je rozdělit data alespoň takto:

Zakázáno vložit – zvláštní kategorie osobních údajů, rodná čísla, zdravotní údaje, neveřejné smlouvy bez anonymizace, tajné přístupové údaje, neveřejné bezpečnostní konfigurace, privátní klíče, produkční výpisy databází, zdrojový kód kritických systémů bez schválení.
Lze vložit po úpravě – texty po anonymizaci, obchodní dokumenty po odstranění identifikátorů, interní zápisy bez jmen a částek, ukázky kódu bez tajných klíčů a bez vazby na kritickou architekturu.
Běžně povoleno – veřejně publikované texty, marketingové návrhy bez interních dat, obecné formulace, šablony, veřejná dokumentace.

Co dělat konkrétně: zaveďte povinné předzpracování dat před vložením do AI. V praxi to znamená anonymizaci jmen, e-mailů, telefonů, čísel smluv, IČ zákazníků a všech unikátních identifikátorů. U technických týmů navíc odstraňte tokeny, klíče, interní URL, názvy serverů a IP adresy.

Pro koho: pro všechny útvary, které pracují s osobními údaji, obchodními informacemi nebo neveřejnou technickou dokumentací.

Kdy to nepoužívat: pokud je hodnota úkolu přímo v přesném kontextu a anonymizací by se zničil smysl práce. Typicky právní revize konkrétní smlouvy, analýza bezpečnostního incidentu nebo troubleshooting produkčního výpadku s reálnými identifikátory. Tam je vhodnější interní postup bez externího AI nástroje.

Smysl tohoto kroku je jednoduchý: i když poskytovatel uvádí, že data z podnikových plánů nepoužívá k trénování modelů, pořád řešíte přenos dat ke třetí straně, interní autorizaci, případné retention politiky a vlastní odpovědnost za to, kdo a proč data odeslal.

Nepleťte si „nepoužívá k tréninku“ s „mohu poslat cokoli“

Poskytovatel může deklarovat, že obsah z podnikových účtů standardně nepoužívá pro trénink modelu, ale to neřeší vše. Pořád je třeba zkontrolovat smluvní podmínky, zpracování osobních údajů, subprocesory, dobu uchování, možnosti logování, regionální dostupnost a to, zda firma zvládne doložit účel použití. Z hlediska interní politiky je to rozdíl mezi „nižší riziko“ a „bez omezení“.

3. Přístupy a identity: žádné osobní účty, povinné SSO a role podle práce

Jakmile zaměstnanci používají AI přes osobní účty, firma ztrácí možnost správně ukončit přístup, auditovat používání a vynucovat nastavení. Proto je minimální standard jasný: žádné firemní použití přes soukromé identity, pokud existuje schválená podniková varianta služby.

Co dělat konkrétně:

Zapněte SSO přes Microsoft Entra ID, Google Workspace nebo jiného firemního poskytovatele identity tam, kde to služba podporuje.
Vynucujte MFA pro všechny administrátory a pro všechny uživatele služeb, které pracují s interními daty.
Zakažte sdílené účty. Každý uživatel musí mít vlastní identitu.
Nastavte role: běžný uživatel, schvalovatel integrací, administrátor, bezpečnostní dohled.
Napojte AI služby na standardní proces joiner-mover-leaver, tedy nástup, změnu role a odchod zaměstnance.

Pro koho: pro IT administrátory, bezpečnostní tým a HR, které zajišťuje životní cyklus účtů.

Kdy to nepoužívat: pokud testujete jednorázově veřejný nástroj bez firemních dat v sandboxu. I tam ale musí být jasně uvedeno, že jde o experiment bez produkčního použití.

Praktický dopad je velký. Když zaměstnanec odejde, nestačí deaktivovat e-mail. Musíte mu ukončit i přístup do AI nástrojů, odebrat případné API klíče, exporty, pluginy a sdílené workspaces. U GitHub Copilot je navíc vhodné kontrolovat, kdo má přístup k organizacím a repozitářům. U Microsoft 365 Copilot řešíte oprávnění nad SharePointem, OneDrivem, Teams a Exchange, protože model čerpá z toho, k čemu má uživatel legálně přístup. Špatně nastavená oprávnění v M365 se tak mohou projevit i v AI výstupech.

Nejčastější slabina: přístupová práva v M365 nejsou připravena na Copilot

Copilot pro Microsoft 365 neobchází oprávnění, ale právě proto může odhalit dlouhodobý nepořádek v přístupech. Pokud má příliš mnoho lidí přístup k historickým složkám, zápisům ze schůzek nebo mzdovým podkladům, AI jen zrychlí nalezení obsahu, který tam už byl. Před nasazením Copilotu je proto nutné udělat revizi práv v SharePointu, Teams a OneDrivu, jinak si firma problém pouze zviditelní ve větším měřítku.

4. Logování a audit: bez záznamů neprokážete, že máte používání pod kontrolou

Mnoho firem řeší AI politiky, ale neuchovává téměř žádné provozní záznamy. Pak při interním auditu nebo incidentu nedokážou odpovědět na základní otázky: kdo nástroj použil, kdy, z jakého účtu, s jakou integrací, jaké oprávnění měl a zda byla aktivní příslušná bezpečnostní pravidla. Nemusíte logovat plné znění každého promptu, ale musíte mít auditní stopu pro dohledatelnost a reakci na incident.

Co dělat konkrétně: stanovte minimální sadu logovaných událostí:

přihlášení, neúspěšná přihlášení a změny MFA,
vytvoření, změna a smazání uživatelského účtu,
změna role, přidání administrátora,
aktivace nebo vypnutí konektorů, pluginů a API přístupů,
vytvoření a rotace API klíčů,
export dat, sdílení workspace nebo projektu,
změny retenční politiky a bezpečnostních nastavení,
pokud je to dostupné, metadata o použití modelu a aplikace.

Pro koho: pro bezpečnostní tým, SOC, interní audit a správce identit.

Kdy to nepoužívat: neukládejte plošně obsah promptů a výstupů tam, kde by tím vznikalo nové zbytečné riziko pro osobní údaje, obchodní tajemství nebo pracovněprávní spory. Logujte primárně metadata a administrátorské akce, obsah jen tam, kde máte jasný účel a oporu v interních pravidlech.

Větší podnikové služby typicky nabízejí auditní logy, administrátorské konzole a export do SIEM. Je však nutné ověřit konkrétní rozsah v dokumentaci a tarifu. Například Microsoft standardně staví na auditních možnostech Microsoft 365 Purview a Entra ID, GitHub má audit log pro organizace a enterprise účty a podnikové AI služby často nabízejí admin konzoli, řízení workspace a fakturační přehledy. Rozsah detailů se liší podle plánu.

Jak dlouho logy držet

Jedna univerzální lhůta neexistuje. Prakticky se ale vyplatí sladit uchování s interní politikou pro bezpečnostní logy a s dobou, po kterou reálně řešíte incidenty a interní šetření. Důležité je mít pravidlo napsané předem: kde jsou logy, kdo k nim má přístup, jak se chrání, jak dlouho se uchovávají a kdy se mažou.

5. Schvalování nových integrací a API: nejrizikovější část bývá mimo hlavní chatové okno

Firmy často řeší, zda zaměstnanci smějí používat ChatGPT nebo Copilot, ale přehlížejí rozšíření, pluginy, konektory a automatizace. Přitom právě tady vzniká největší provozní riziko: AI služba se propojí s CRM, helpdeskem, cloudovým úložištěm nebo Git repozitářem a začne pracovat s širší sadou dat, než si uživatel uvědomuje.

Co dělat konkrétně: zaveďte povinný lightweight schvalovací proces pro každou novou integraci. Nemá mít deset stran, ale musí odpovědět na tyto otázky:

Jaká data integrace čte a zapisuje?
Je přístup read-only, nebo umí měnit data?
Kdo je vlastníkem integrace?
Jak se přístup odebere při odchodu zaměstnance?
Jsou k dispozici logy a audit administrátorských změn?
Je možné omezit rozsah přístupu jen na konkrétní tým nebo prostor?

Pro koho: pro správce SaaS, enterprise architekty, bezpečnostní tým a vlastníky byznys aplikací.

Kdy to nepoužívat: pokud integrace vyžaduje plošný zápis do kritického systému bez jemné správy oprávnění nebo pokud není jasné, kde končí odpovědnost dodavatele a kde začíná odpovědnost firmy.

Právě zde se vyplatí princip „nejprve read-only, teprve potom write“. Když AI konektor umí nejprve jen číst dokumentaci, znalostní bázi nebo vybraný projekt, získáte užitečný pilot bez rizika nekontrolovaných změn. Zápis do CRM, ticketingu nebo interních wiki povolujte až po vyhodnocení kvality výstupů, odpovědnosti a logování.

6. Procesy pro incidenty: AI chyba není jen špatná odpověď, ale i bezpečnostní událost

Ve firmách se stále podceňuje, že incident spojený s AI nemusí vypadat dramaticky. Může jít o omyl zaměstnance, který vložil neveřejný dokument do neschváleného nástroje. Nebo o integraci, která získala širší oprávnění, než bylo potřeba. Nebo o chybný výstup, podle kterého tým provedl zásah do systému. Bez jasného postupu se tyto situace řeší ad hoc, což je přesně to, čemu má NIS2 předcházet.

Co dělat konkrétně: doplňte do interního incident response plánu i AI scénáře. Minimálně tyto:

vložená citlivá data do neschválené AI služby,
únik API klíče spojeného s AI aplikací,
neoprávněná aktivace konektoru nebo pluginu,
škodlivé nebo nesprávné doporučení AI, které vedlo k provozní změně,
podezření na přístup bývalého zaměstnance k firemní AI službě.

U každého scénáře napište odpovědnost, prvních 60 minut, eskalační kontakty, způsob důkazního zajištění a rozhodnutí, kdy informovat vedení, právní oddělení, DPO a případně zákazníka.

Pro koho: pro SOC, IT provoz, legal, DPO a liniové manažery, kteří schvalují používání nástrojů.

Kdy to nepoužívat: nepřebírejte mechanicky obecný incident playbook bez doplnění konkrétních AI služeb, administrátorských cest a kontaktů na dodavatele. Bez těchto detailů je plán při reálné události pomalý.

Praktické pravidlo pro první reakci

Jestliže někdo vloží citlivý obsah do neschválené služby, první krok není hledat viníka, ale zastavit další šíření: odpojit integraci, změnit klíče, zrušit sdílení, zdokumentovat čas, uživatele a rozsah dat a vyhodnotit, zda šlo o osobní údaje, obchodní tajemství nebo technickou dokumentaci s bezpečnostním dopadem.

7. Školení musí být krátké, povinné a vázané na konkrétní práci

Jednorázový webinář „jak psát lepší prompty“ je z hlediska interních pravidel téměř bezcenný. Zaměstnanec potřebuje hlavně rozlišit, kdy AI použít, kdy ji nepoužít, jak upravit vstupní data a kam nahlásit problém. To lze naučit během 20 až 30 minut, pokud školení vychází z reálné práce daného týmu.

Co dělat konkrétně: připravte tři varianty mikroškolení:

Kancelářské týmy – shrnutí textů, zápisy, překlady, e-maily; důraz na anonymizaci a práci s neveřejnými dokumenty.
Vývoj a IT – práce se zdrojovým kódem, logy, konfiguracemi, tajnými klíči a automatizacemi.
HR a legal – inzerce, interní komunikace, osobní údaje, smluvní texty, zákaz vkládání konkrétních podkladů bez schválení.

Každé školení zakončete krátkým testem se čtyřmi až šesti situacemi z praxe. Kdo neuspěje, nemá mít přístup k firemní AI službě, dokud test nesplní.

Pro koho: pro všechny uživatele schválených AI nástrojů, včetně managementu.

Kdy to nepoužívat: když firma nemá ani základní politiku a seznam schválených nástrojů. Školit bez provozních pravidel znamená nutit lidi improvizovat.

Dobré školení má ještě jednu vlastnost: neříká jen „nedělejte chyby“, ale dává povolené alternativy. Například: „Potřebuješ shrnout smlouvu? Použij interně schválený nástroj a nejprve odstraň jména, částky a identifikátory.“ Bez alternativy zaměstnanci obvykle sáhnou po nejrychlejší veřejné službě.

8. Praktické scénáře: co udělat v běžných firemních situacích

Scénář 1: Obchodník chce shrnout zápis z jednání se zákazníkem

Správný postup: použít schválený firemní nástroj, před vložením odstranit jméno zákazníka, e-maily, ceny, čísla zakázky a neveřejné přísliby. Výstup použít jako koncept, ne jako finální zápis bez kontroly.

Pro koho: obchod, account management, customer success.

Kdy to nepoužívat: pokud zápis obsahuje neveřejné cenové podmínky, sporné smluvní body nebo citlivé údaje fyzických osob a není k dispozici schválený podnikový nástroj.

Scénář 2: Vývojář chce použít AI pro refaktoring kódu

Správný postup: používat firemně spravovaný GitHub Copilot nebo jiný schválený nástroj, nevkládat tajné klíče, produkční konfigurace ani části systému s bezpečnostně kritickou logikou bez výslovného povolení. Každý návrh projde code review a bezpečnostní kontrolou jako běžný příspěvek.

Pro koho: vývoj, DevOps, QA.

Kdy to nepoužívat: u kódu pro autentizaci, kryptografii, správu oprávnění, bezpečnostní logiku a incident tooling, pokud tým nemá jasný proces kontroly a odpovědnost za výsledek.

Scénář 3: HR chce upravit pracovní inzerát a e-mail kandidátovi

Správný postup: použít AI jen pro stylistickou úpravu šablony bez osobních údajů kandidáta. Vstupem má být anonymní text, nikoli celé CV, hodnocení uchazeče nebo interní poznámky z pohovoru.

Pro koho: HR, nábor, interní komunikace.

Kdy to nepoužívat: při rozhodování o kandidátovi, třídění citlivých údajů nebo při práci s konkrétními personálními podklady bez interního schválení a právního posouzení.

Scénář 4: Podpora chce AI pro návrhy odpovědí z helpdesku

Správný postup: začít read-only režimem nad vybranou znalostní bází, bez přístupu k plným ticketům zákazníků. Teprve po ověření kvality a logování rozšířit použití na interní drafty odpovědí.

Pro koho: zákaznická podpora a service desk.

Kdy to nepoužívat: pokud ticket obsahuje osobní údaje, údaje o platbách, přístupy nebo technické detaily z incidentu a chybí anonymizace či schválená integrace.

9. Limity: co minimální nastavení neřeší a kde firmy dělají chybný závěr

Minimální procesy, přístupy a logování nejsou totéž co bezpečné nasazení bez dalších otázek. Řeší základní kontrolu, ne kvalitu výstupů, právní interpretaci každého použití nebo technické slabiny konkrétních modelů. Firmy proto často udělají jednu ze tří chyb.

Chyba 1: „Máme enterprise tarif, jsme v bezpečí.“ Ne. Tarif může snížit některá rizika, ale neřeší vaše přístupy, interní oprávnění, klasifikaci dat ani chybné používání zaměstnanci.
Chyba 2: „Budeme logovat vše.“ Ne. Přehnané logování obsahu může vytvořit nové právní i bezpečnostní problémy. Potřebujete přiměřené a účelové logování.
Chyba 3: „AI je jen další SaaS aplikace.“ Jen částečně. U generativní AI řešíte navíc prompty, kontext, možné halucinace, automatizované návrhy a tendenci lidí přeceňovat kvalitu odpovědí.

Co dělat konkrétně: doplňte minimální governance o pravidlo lidské kontroly. Každý výstup, který ovlivňuje zákazníka, smlouvu, bezpečnostní změnu, personální rozhodnutí nebo veřejné tvrzení firmy, musí před použitím ověřit člověk s odpovědností za daný proces.

Pro koho: pro management, vedoucí týmů a vlastníky procesů.

Kdy to nepoužívat: nepokoušejte se touto minimální sadou pravidel pokrýt vysoce regulované nebo vysoce rizikové použití bez hlubšího právního, bezpečnostního a architektonického posouzení.

FAQ

Spadá používání ChatGPT nebo Copilotu automaticky pod NIS2?

Ne automaticky. NIS2 řeší zejména řízení kybernetických rizik u dotčených organizací. Pokud ale firma pod NIS2 spadá a zaměstnanci používají AI při práci s firemními daty nebo systémy, je to relevantní součást řízení rizik, přístupů, třetích stran a incidentů.

Stačí vydat interní směrnici a problém je vyřešen?

Nestačí. Směrnice bez technického vynucení a bez logování má malou hodnotu. Potřebujete schválené nástroje, firemní identity, role, evidenci integrací, školení a základní auditní stopu.

Můžeme zaměstnancům povolit veřejné AI chatboty pro práci?

Ano, ale jen velmi omezeně a pouze pro veřejný nebo anonymizovaný obsah. Jakmile jde o neveřejná firemní data, osobní údaje, smlouvy, kód nebo technickou dokumentaci, dává smysl jen schválený podnikový režim nebo zákaz.

Musíme logovat obsah promptů?

Obvykle ne plošně. Důležitější jsou metadata, administrátorské změny, identity, integrace, exporty a přístupové události. Obsah promptů logujte jen tam, kde máte jasný účel, oporu v interních pravidlech a zvládáte právní i bezpečnostní dopady.

Je lepší ChatGPT, Microsoft Copilot, Gemini nebo jiný nástroj?

Pro účely governance to není hlavní otázka. Důležitější je, zda služba podporuje firemní identity, správu uživatelů, audit, smluvní režim pro podniky, kontrolu integrací a jasně popsané zpracování dat. Teprve potom řešte kvalitu modelu a cenu.

Jak začít, když firma zatím nemá nic?

Začněte ve třech týdnech třemi kroky: sepište schválené a zakázané nástroje, zaveďte zákaz osobních účtů pro firemní práci a spusťte krátké školení s pravidlem, jaká data se do AI nevkládají. Teprve potom rozšiřujte integrace a automatizace.

Závěr

Minimální nastavení pro AI ve firmě není složité, pokud se držíte správného pořadí. Nejprve určete, které služby jsou povolené a v jakém režimu. Pak jasně vymezte, jaká data do AI nesmějí a co je nutné anonymizovat. Následně zaveďte firemní identity, SSO, MFA a role podle práce. Bez toho nemá smysl mluvit o odpovědnosti. Teprve potom řešte logování, schvalování integrací a incident playbooky.

Firmy, které toto minimum přeskočí, obvykle nezískají vyšší efektivitu, ale pouze méně viditelný chaos. A právě to je z pohledu NIS2 nejhorší kombinace: nástroje se používají, data tečou ven, rozhodnutí nejsou dohledatelná a vedení formálně předpokládá, že je vše pod kontrolou. Pokud má být AI ve firmě skutečně provozní nástroj a ne improvizace na hraně interních pravidel, musí mít jasného vlastníka, omezené vstupy, firemní přístupy a auditní stopu. To je rozumné minimum, od kterého se dá bezpečně růst.

Oficiální zdroje k ověření detailů: OpenAI Business, OpenAI Enterprise Privacy, Microsoft Copilot for Microsoft 365, Microsoft Learn, GitHub Copilot Business, GitHub Copilot Enterprise.

Doporučený AI stack pro realizaci

Vyber si nástroje podle rozpočtu a úrovně automatizace. Níže je přímý přehled služeb pro realizaci projektu.

Služba	Popis služby	Nabídka
NordVPN	VPN služba pro ochranu soukromí a bezpečné připojení.	Otevřít nabídku
Semrush	SEO a marketingová platforma pro analýzu a růst návštěvnosti.	Otevřít nabídku
Make	Pokročilá vizuální automatizace workflow a integrací.	Otevřít nabídku
Hostinger	Webhosting a domény pro rychlé spuštění webu.	Otevřít nabídku
Fiverr	Marketplace pro freelancery a externí specialisty.	Otevřít nabídku
Adobe	Kreativní nástroje pro grafiku, video a digitální obsah.	Otevřít nabídku
Canva	Online design nástroj pro grafiku, prezentace a sociální sítě.	Otevřít nabídku
Jasper	AI nástroj pro marketingové texty a obsahové kampaně.	Otevřít nabídku