AI Act pro webové agentury: jak bezpečně dodávat chatboty, AI obsah a integrace

Aktualizováno 8. srpna 2026. Webové agentury dnes nedodávají pouze stránky, formuláře a e-shopy. Do projektů přibývají chatboty, generování obsahu, vyhledávání v dokumentech, doporučování produktů, automatické třídění poptávek a napojení na CRM. S každou takovou funkcí vzniká vedle technického zadání také otázka, kdo odpovídá za data, výstupy, transparentnost a změny dodavatelské služby.

Pro webovou agenturu není praktické reagovat na AI Act větou „právní odpovědnost má klient“. Agentura navrhuje architekturu, volí nástroje, integruje API, připravuje prompty a často spravuje provoz. Klient zase určuje účel, publikum, proces a způsob použití. Bez rozdělení odpovědnosti se problém objeví až při chybě, kdy už není jasné, kdo měl co zkontrolovat.

Tento článek je praktický návod pro agentury, freelancery i firmy, které AI funkci objednávají. Ukazuje, jak vést projekt od prvního briefu po předání, jak se ptát na role podle AI Actu a jak připravit takovou dokumentaci, aby odpovídala skutečnému provozu. Nenahrazuje právní posouzení konkrétního systému, smlouvy ani zpracování osobních údajů.

Nejdůležitější princip: neposuzujte pouze nástroj

Klient se často zeptá, zda je „ChatGPT“, „AI chatbot“ nebo „generování obrázků“ podle AI Actu rizikové. Správná odpověď se bez kontextu nedá dát. Posuzuje se konkrétní systém a jeho použití: co dělá, s jakými daty, pro koho, pod čí kontrolou a s jakým dopadem.

Stejný model může být použit pro návrh interního titulku článku, odpověď zákazníkovi v e-shopu nebo předvýběr kandidátů na pracovní místo. Technologický základ může být stejný, ale riziko, role firmy i potřebná kontrola budou odlišné. V zadání proto popisujte především:

• účel a konkrétní rozhodnutí, které AI podporuje,
• osoby, které se mohou výstupem cítit dotčené,
• data vstupující do modelu a příjemce výsledku,
• míru automatizace a možnost lidského zásahu,
• to, zda výstup zůstává interní, nebo jde veřejně na web.

Agentura může klientovi pomoci s technickým a procesním posouzením. Neměla by ale bez znalosti klientova provozu prohlásit, že řešení je „v souladu s AI Actem“. Přesnější je popsat, jaké předpoklady, opatření, testy a otevřená rizika byly v rámci projektu ověřeny.

Kdo je v projektu kdo

AI Act pracuje s rolemi, které se mohou podle konkrétního řešení lišit. V projektu webové agentury se typicky potká klient, agentura a dodavatel modelu nebo platformy. Koncovým uživatelem může být zaměstnanec klienta, zákazník webu nebo veřejnost.

Klient jako provozovatel

Klient bývá subjektem, který AI funkci používá pod vlastní kontrolou. Určuje, proč chatbot odpovídá, jaké dokumenty smí vyhledávat, jak se zpracuje poptávka nebo kdo schvaluje výstup. U firmy je důležité, že zaměstnanec, externista nebo freelancer jednající podle jejích pokynů nebývá samostatným provozovatelem; odpovědnost za používání zůstává u právnické osoby v rozsahu daném konkrétním uspořádáním.

Agentura jako integrátor, dodavatel nebo také provozovatel

Agentura může pouze technicky integrovat cizí službu do klientova webu. Může ale také vytvořit vlastní AI aplikaci, dodat ji pod svou značkou, řídit její chování a zajišťovat její provoz. V takovém případě se její role a povinnosti mohou změnit. U vysoce rizikového systému může být za poskytovatele považován i subjekt, který jej uvede pod vlastním jménem nebo provede podstatnou změnu, která zachová jeho vysoce rizikovou povahu.

Nejde o to přidělit agentuře nejvyšší možnou odpovědnost ke každému projektu. Jde o to, aby smlouva a technický návrh odpovídaly skutečnosti. Agentura, která navrhuje, integruje a provozuje AI funkci, nemůže předstírat, že je pouze neutrálním dodavatelem grafiky.

Dodavatel modelu nebo platformy

Dodavatel poskytuje model, API, hosting, vektorovou databázi, nástroj pro rozpoznání hlasu nebo jinou službu. Agentura by měla znát jeho podmínky, verze, ukládání vstupů, použití dat pro trénování, dostupnost a postup při incidentu. Klientovi pak musí srozumitelně popsat, na čem jeho řešení závisí.

Uživatel webu nebo interního systému

Uživatel může být zákazník, návštěvník, zaměstnanec nebo pracovník podpory. Není automaticky odpovědnou osobou za celý systém. Je ale třeba navrhnout rozhraní tak, aby věděl, kdy komunikuje s AI, co může očekávat a jak se dostane k člověku.

Co změnit v prvním klientském briefu

AI funkce by neměla začínat větou „přidejte na web chytrého asistenta“. První brief doplňte o otázky, které pomohou odhalit dopad dříve, než vznikne architektura.

Pracovní otázky pro klienta

1. Jaký problém řešíme? Chceme zrychlit odpovědi, vyhledat dokument, vytvořit návrh, nebo automaticky rozhodnout?
2. Kdo bude výstup číst? Pracovník, zákazník, uchazeč, dodavatel, nebo veřejnost?
3. Co se stane při chybě? Opraví se text, odejde chybná nabídka, zamítne se požadavek, nebo někdo přijde o možnost?
4. Jaká data systém potřebuje? Veřejný obsah, interní dokumenty, osobní údaje, biometrické údaje, údaje dětí nebo obchodní tajemství?
5. Co smí systém sám provést? Pouze navrhnout výstup, nebo také odeslat e-mail, změnit CRM, vrátit platbu či upravit cenu?
6. Jak člověk výsledek přezkoumá? Kdo má pravomoc jej odmítnout a kolik času na kontrolu reálně má?
7. Jak se pozná AI komunikace nebo obsah? Jaký text uvidí návštěvník a kdo označení udržuje?
8. Co se stane při výpadku nebo změně modelu? Existuje ruční postup a odpovědná osoba?

Odpovědi uložte do rozhodnutí projektu, ne pouze do chatu mezi projektovým manažerem a klientem. Pokud se během implementace změní účel, publikum nebo typ dat, musí se změnit i posouzení.

Pět typických projektů a jejich rozdílná rizika

1. Chatbot pro veřejný web

Chatbot, který odpovídá z klientovy znalostní báze, bývá technicky zvládnutelný projekt. Agentura ale musí vyřešit, že návštěvník ví, že komunikuje s AI, a že se může obrátit na člověka. Oznámení musí být srozumitelné a viditelné v místě interakce, ne pouze v podmínkách.

Praktické minimum pro chatbot:

• úvodní zpráva uvádí, že jde o AI asistenta,
• je dostupná cesta k člověku nebo kontaktnímu formuláři,
• systém odpovídá pouze z povolených zdrojů nebo přizná nejistotu,
• nepřijímá citlivé údaje, pokud pro to není jasný právní a technický důvod,
• logování neuchovává více dat, než je potřebné pro bezpečnost a provoz,
• agentura s klientem otestuje nesprávné dotazy, pokusy o získání instrukcí a eskalaci.

2. AI generovaný text, obraz nebo video

AI vytvořená ilustrace pro běžnou produktovou stránku není automaticky deepfake. Deepfake je podle AI Actu syntetický nebo upravený obraz, zvuk či video, které připomíná existující osobu, objekt, místo, subjekt nebo událost a mohlo by působit jako autentické či pravdivé. Kontext a očekávání publika jsou důležité.

U agenturního projektu si zapište:

• čím byl obsah vytvořen nebo podstatně upraven,
• zda napodobuje konkrétní osobu, skutečnou událost nebo reálný záznam,
• kde a komu bude publikován,
• zda má být viditelně označen a zda je k dispozici strojově čitelné označení,
• kdo provedl lidskou kontrolu a kdo schválil zveřejnění,
• zda má agentura od dodavatele dostatečná práva a dokumentaci k použití výstupu.

U běžného marketingového textu není správné tvrdit, že AI Act automaticky vyžaduje označit úplně každý text vytvořený pomocí AI. Zvláštní transparentnost podle článku 50 se týká mimo jiné AI textu publikovaného za účelem informování veřejnosti o věci veřejného zájmu, pokud nebyl podroben lidské kontrole nebo redakčnímu dohledu. Jiná pravidla, smlouva s klientem, reputační politika nebo konkrétní platforma mohou ale vyžadovat širší označování.

3. Vyhledávání v klientských dokumentech

RAG vyhledávání nebo AI asistent nad interními dokumenty může být pro firmu užitečný, ale dokumenty se nestávají automaticky vhodným trénovacím materiálem. U každého zdroje určete, kdo jej smí číst, jak se řeší změna oprávnění a zda výstup nespojí informace z oddělení, která spolu nemají sdílet data.

Technicky nestačí schovat dokumenty do vektorové databáze. Musíte řešit oprávnění před vyhledáním i před zobrazením výsledku, izolaci klientů, mazání a aktualizaci indexu, logy dotazů a možnost okamžitě odebrat zdroj. Systém musí umět říct, že odpověď nemá dostatečnou oporu v dokumentech.

4. AI pro třídění poptávek nebo CRM

AI, která rozpozná typ poptávky a předá ji obchodníkovi, může být běžná automatizace. Pokud ale začne lidi hodnotit, prioritizovat je podle citlivých vlastností nebo automaticky zamítat požadavky, dopad se výrazně mění. Vždy definujte, zda je výstup pouze doporučení, nebo rozhodnutí, a kdo jej kontroluje.

U CRM integrace dodržujte zásadu nejmenších oprávnění. Model nemusí mít právo mazat kontakty, měnit stav zakázky a odesílat zprávy současně. Citlivé nebo nevratné akce opatřete potvrzením člověka a auditní stopou.

5. AI v náborovém nebo zaměstnaneckém webu

Funkce, která třídí životopisy, odhaduje vhodnost kandidáta, hodnotí výkon nebo doporučuje pracovní postup, patří mezi použití, u kterých je potřeba zvýšená opatrnost. Některé systémy v oblasti zaměstnání jsou v AI Actu uváděny mezi vysoce rizikovými použitími. Agentura by neměla takový projekt spustit pouze na základě marketingového popisu dodavatele.

V zadání musí být jasné, že klient odpovídá za účel náborového procesu, lidský dohled a zákonné posouzení. Agentura odpovídá za správnou implementaci, testy, řízení přístupů, dokumentaci a upozornění na technická omezení. Když klient požaduje „automatické vyřazení slabých kandidátů“, je to signál k zastavení návrhu a zapojení odborného posouzení.

Transparentnost není pouze text v patičce

Článek 50 AI Actu se od 2. srpna 2026 týká určitých interaktivních a generativních systémů. Evropská komise uvádí zejména povinnost poskytovatele navrhnout přímou interakci tak, aby člověk věděl, že komunikuje s AI, pokud to není zřejmé. U generativních systémů se řeší také strojově čitelné označení AI vytvořeného nebo upraveného obsahu. Provozovatel pak v relevantních případech označuje deepfake a určitý AI text ve veřejném zájmu.

Pro agenturu z toho plyne několik praktických úkolů:

1. U chatbotu navrhnout oznámení v první interakci a cestu k člověku.
2. U generování obsahu zjistit, zda dodavatel poskytuje strojově čitelné označení.
3. U deepfake navrhnout viditelné označení při prvním vystavení člověku.
4. U veřejně publikovaného AI textu zaznamenat, zda jde o informování o věci veřejného zájmu a zda proběhl lidský redakční dohled.
5. Do předávací dokumentace napsat, kdo označení udržuje při změně CMS, modelu nebo šablony.

Dobrovolný kodex Evropské komise může být praktickým podkladem, ne však náhradou za právní analýzu. Dodavatel, který kodex nepoužije, musí být schopný popsat jiný přiměřený způsob, jak povinnosti prokazuje.

Data, GDPR a důvěrnost v agenturním projektu

Projektová smlouva musí rozlišit, jaká data agentura potřebuje k vývoji, jaká data zpracovává v provozu a která by do AI služby vůbec neměla odejít. AI Act nenahrazuje GDPR ani povinnost chránit obchodní tajemství.

Datový checkpoint před vývojem

• Je nutné použít skutečná data, nebo lze testovat na anonymizovaném vzorku?
• Je dodavatel modelu zpracovatel, samostatný správce nebo další role?
• Existuje smlouva o zpracování osobních údajů a seznam subdodavatelů?
• Kde se zpracování a zálohy odehrávají?
• Ukládá služba vstupy a výstupy, a používá je pro trénování nebo zlepšování?
• Jak se řeší výmaz, export, oprava a omezení dat?
• Co zůstane agentuře po dokončení projektu a kdy se pracovní kopie smažou?
• Je nutné provést DPIA nebo jiné posouzení dopadu?

Do testovacího prostředí nevkládejte reálné osobní údaje jen proto, že jsou po ruce. Připravte bezpečný datový vzorek, označte jeho původ a před ostrým spuštěním ověřte, zda jsou zapnuté správné účty, oprávnění a retenční pravidla.

Technický základ, který by neměl chybět

Bezpečná AI funkce nemusí být složitá, ale musí mít hranice. V projektové specifikaci popište minimálně:

• zdroje pravdy: odkud systém smí čerpat,
• verzi modelu a prompty: co se mění a kdo změnu schvaluje,
• oprávnění: jaké API akce systém smí volat,
• limity: počet požadavků, velikost dokumentu, finanční částka nebo rozsah akce,
• eskalaci: kdy se výsledek předá člověku,
• logování: co se ukládá pro dohledatelnost a jak se chrání osobní údaje,
• ochranu proti zneužití: prompt injection, únik instrukcí, přístup k cizím datům a nadměrné oprávnění,
• fallback: co návštěvník nebo zaměstnanec uvidí při výpadku,
• monitoring: jak poznáme růst chybovosti, neobvyklé dotazy nebo změnu chování modelu,
• ukončení: jak se funkce vypne, aniž by se rozbil zbytek webu.

Agentní systém s možností odesílat e-maily nebo měnit záznamy testujte na konkrétních hranicích. Neověřujte jen, zda funguje šťastná cesta. Zkoušejte neúplné vstupy, nepravdivý dokument, dvojznačný požadavek, pokus získat tajný prompt, opakovaný dotaz, výpadek API a změnu oprávnění.

Jak připravit smlouvu a předávací dokumentaci

Smlouva nemá slibovat abstraktní „AI v souladu se zákonem“. Měla by vymezit konkrétní vlastnosti a odpovědnosti. Zvažte samostatnou přílohu k AI funkci, která obsahuje:

• účel, povolený rozsah a zakázané použití,
• role klienta, agentury a dodavatelů ve vztahu k systému,
• typy dat, prostředí a pravidla přístupu,
• použitý model, verzi, region zpracování a změnové oznámení,
• pravidla pro lidský dohled a schvalování akcí,
• odpovědnost za obsah, zdroje, licence a kontrolu faktů,
• pravidla označování AI interakce a generovaného obsahu,
• testovací protokol a známá omezení,
• incidentní kontakty, dobu reakce a postup při změně nebo výpadku,
• podmínky podpory, aktualizací, exportu a ukončení služby.

Při předání klientovi dejte kromě přístupů také stručný návod: co funkce umí, co neumí, jak ji vypnout, jak poznat chybu, kdo schvaluje výstup a jak se požádá o zásah agentury. Předání bez těchto informací vytváří závislost na člověku, který za půl roku nemusí být k dispozici.

Akceptační testy pro AI funkci

AI výstup nejde vždy ověřit stejně jako pixelově přesný design. Akceptace přesto musí být měřitelná. U každé funkce si určete testovací sadu, očekávané chování a hranici, po které se výsledek nepoužije automaticky.

Příklad testovacího protokolu pro chatbot

1. Správně odpoví na běžné otázky z aktuální znalostní báze.
2. U neznámé otázky přizná nejistotu a nabídne další kontakt.
3. Nevydá interní instrukce, systémové prompty ani cizí dokument.
4. Rozpozná žádost o osobní nebo citlivé údaje a nesbírá je bez důvodu.
5. U kontroverzního dotazu předá případ člověku podle dohodnutého pravidla.
6. Oznámí, že jde o AI, a zachová přístupnost na mobilu i desktopu.
7. Po změně zdrojového dokumentu se aktualizace projeví předvídatelně.
8. Při výpadku API se zobrazí náhradní kontakt a nevznikne falešná odpověď.

Testovací výsledek opatřete datem, verzí modelu a jménem schvalovatele. Pokud dodavatel model vymění bez upozornění, může se změnit i chování, které bylo při předání ověřené.

Podpora po spuštění je součást AI řešení

Webová agentura by měla s klientem dohodnout, kdo sleduje změny modelu, aktualizaci znalostní báze, přístupy, logy a incidenty. U běžného webu může aktualizace pluginu znamenat jiný typ práce než u AI funkce, která začne po změně modelu odpovídat jinak.

Do pravidelné správy zahrňte alespoň:

• kontrolu dostupnosti a chybových stavů,
• náhodný audit výstupů a zdrojů,
• kontrolu změn modelu, promptu a datové báze,
• revizi oprávnění a odchodů pracovníků,
• aktualizaci oznámení a dokumentace,
• opakování bezpečnostních a regresních testů,
• vyhodnocení incidentů a zpětné vazby uživatelů.

Pokud klient odmítne pravidelnou správu, předávejte mu alespoň jasný seznam jeho povinností a termínů kontrol. V opačném případě může staré řešení zůstat na webu bez vlastníka, přestože se změnily zdroje, podmínky služby i právní požadavky.

Praktický postup agentury od poptávky po spuštění

Fáze 1: Zadání

• Sepište účel, uživatele, data, automatické akce a dopad chyby.
• Označte, zda se dotýká zaměstnání, vzdělávání, úvěrů, biometrie, bezpečnosti nebo veřejného zájmu.
• Ujasněte, zda je agentura pouze integrátorem, nebo dodává vlastní produkt.

Fáze 2: Posouzení

• Proveďte předběžný test zakázaných praktik, vysokého rizika a transparentnosti.
• Proveďte datový a GDPR checkpoint.
• Vyžádejte dokumentaci dodavatele modelu a stanovte otevřené otázky.

Fáze 3: Návrh a integrace

• Navrhněte nejmenší oprávnění, limity, lidské potvrzení a fallback.
• Oddělte testovací a produkční data a účty.
• Zapište verze, zdroje, prompty a změnové řízení.

Fáze 4: Ověření

• Testujte běžnou, hraniční, škodlivou i neúplnou cestu.
• Ověřte transparentní texty, přístup k člověku a dostupnost.
• Nechte klienta schválit účel, datové zdroje, výstupy a provozní pravidla.

Fáze 5: Předání a provoz

• Předejte dokumentaci, přístupy, testovací protokol a známá omezení.
• Zaškolte uživatele i administrátora.
• Domluvte revize, kontakt pro incident a možnost vypnutí.

Krátký checklist pro webovou agenturu

• ☐ V zadání je popsán skutečný účel, ne pouze název nástroje.
• ☐ Je známé, kdo bude systém používat a koho může ovlivnit.
• ☐ Jsou zapsané role klienta, agentury a dodavatelů.
• ☐ Byly prověřeny zakázané praktiky a oblasti vysokého rizika.
• ☐ Jsou popsaná vstupní data, oprávnění a retenční doba.
• ☐ Je ověřeno zpracování osobních údajů a obchodního tajemství.
• ☐ Chatbot nebo jiná interakce obsahuje vhodné oznámení o AI.
• ☐ U generovaného obsahu je rozhodnuto o strojovém i viditelném označení.
• ☐ U textu ve veřejném zájmu je zaznamenán lidský redakční dohled.
• ☐ Automatické akce mají limity, potvrzení a možnost návratu.
• ☐ Proběhly testy prompt injection, úniku dat, výpadku a chybových odpovědí.
• ☐ Klient dostal dokumentaci, školení, kontakty a návod k vypnutí.
• ☐ Je domluvena pravidelná kontrola modelu, zdrojů a oprávnění.

Co říct klientovi jednoduše a přesně

Klient nemusí znát všechny pojmy z AI Actu. Potřebuje vědět, co jeho řešení dělá, jaké má hranice a kdo udělá další krok. Vhodná formulace může znít:

„Navrhneme AI funkci podle konkrétního procesu, ověříme práci s daty, nastavíme lidskou kontrolu, otestujeme chybové scénáře a předáme vám pravidla provozu. U citlivých použití společně ověříme, zda je potřeba právní nebo bezpečnostní posouzení. Nedeklarujeme obecný soulad bez znalosti vašeho provozu; doložíme konkrétní opatření a otevřené otázky.“

Takové vymezení je důvěryhodnější než slib, že AI „bezpečně vyřeší všechno“. Dobrý dodavatel nevytváří pouze obrazovku. Pomáhá klientovi pochopit, co bude systém dělat každý den po spuštění.

Na co navázat v sérii

Pro základní klasifikaci použijte Praktický checklist AI Actu pro českou firmu. Podrobnější pravidla pro webové chatboty, deepfaky a AI obsah najdete v článku Transparentnost AI podle AI Actu. Při práci s osobními údaji pokračujte článkem AI Act a GDPR v praxi. Pokud projekt míří do náboru nebo hodnocení lidí, přečtěte si také Vysoce rizikové systémy AI.

Řešíte chatbot, AI vyhledávání, automatizaci nebo bezpečné napojení webu na interní systém? Popište nám svůj projekt. Pomůžeme rozdělit zadání, zvolit přiměřený rozsah, nastavit kontrolu a připravit předání tak, aby funkce byla použitelná i po odchodu původního autora.

Zdroje a poznámka k aktuálnosti

Článek vychází z oficiálního přehledu AI Actu Evropské komise, pokynů Evropské komise k transparentnosti AI obsahu a interakcí, oficiálních otázek a odpovědí k článku 50, Kodexu k označování obsahu vytvořeného AI a nařízení (EU) 2024/1689, zejména pravidel o odpovědnostech v hodnotovém řetězci.

Právní předpisy, metodiky a výklady se vyvíjejí. U systémů, které ovlivňují zaměstnání, vzdělávání, přístup ke službám, základní práva, zdraví nebo bezpečnost, ověřte aktuální znění pravidel a zvažte individuální právní a bezpečnostní posouzení.