AI nápad: automatický tender digest z veřejných zakázek do e-mailu
Veřejné zakázky jsou pro mnoho firem zajímavý zdroj obchodních příležitostí, ale jejich ruční sledování je časově náročné. Problém nebývá jen v samotném vyhledání nových tendrů, ale hlavně v jejich průběžném třídění, odlišení relevantních případů od šumu a v rychlém předání informací obchodnímu týmu. Právě tady dává smysl malý, ale praktický AI projekt: automatický tender digest, který jednou denně stáhne nové zakázky, vytřídí je podle vašich pravidel, stručně je shrne a odešle e-mailem v čitelné podobě.
Výhodou takového řešení je, že nemusíte začínat složitou podnikovou integrací. Pro funkční MVP stačí kombinace veřejně dostupného zdroje dat, databázové tabulky, automatizační platformy, jednoduchého AI kroku a e-mailového odesílání. Pokud už máte zkušenost s automatizacemi, bude realizace rychlá. Pokud ne, i tak je tento projekt vhodný, protože se dá stavět po malých krocích a každý krok je snadno ověřitelný.
V tomto návodu postavíme konkrétní minimum viable product. Cílem nebude dokonalý procurement systém, ale spolehlivý denní digest relevantních zakázek pro konkrétní firmu nebo obchodní tým. Postup je záměrně navržen tak, aby byl realizovatelný bez vlastního backendu, s využitím reálných služeb a ověřitelných nastavení. Pokud se tématu AI automatizací věnujete hlouběji, může se vám hodit i náš přehled AI automatizací nebo související obsah k nástrojům na ChatGPT a praktické workflow.
Cíl projektu

Cílem projektu je vytvořit denní nebo pracovními dny spouštěný e-mailový přehled veřejných zakázek, který automaticky:
- načte nové záznamy z veřejného zdroje,
- odfiltruje zakázky podle oboru, regionu, hodnoty nebo klíčových slov,
- pomocí AI připraví krátké shrnutí a odhad relevance,
- seskupí výsledky do jednoho e-mailu,
- zabrání duplicitnímu zasílání stejné zakázky.
Typický uživatel takového MVP je obchodník, konzultant, agentura nebo dodavatel IT, stavebních, marketingových či servisních služeb, který chce každý den dostat jen to podstatné. Praktický výstup projektu je jasný: místo ručního pročítání desítek položek dorazí do schránky krátký digest s odkazy, termíny a důvodem, proč je zakázka relevantní.
Předpoklady

Než začnete, připravte si několik základních věcí. První je zdroj dat. Pro české prostředí je možné využít data o veřejných zakázkách z oficiálních zdrojů nebo jejich otevřených rozhraní, pokud jsou pro daný typ dat dostupná. Dostupnost konkrétních endpointů a jejich limity se mohou měnit, proto je nutné si před nasazením ověřit aktuální podmínky a dokumentaci. Pokud některý zdroj nenabízí jednoduché API, lze začít i exportem do CSV nebo RSS, pokud je k dispozici.
Dále budete potřebovat automatizační nástroj. V tomto návodu použijeme Make, protože dobře kombinuje HTTP požadavky, práci s tabulkami, OpenAI a e-mailem. Alternativou je Zapier, n8n nebo vlastní skript. Jako úložiště použijeme Airtable, protože usnadňuje filtrování, deduplikaci a ruční kontrolu. Pro AI shrnutí použijeme OpenAI API. E-mail odešleme přes Gmail nebo SMTP.
Připravte si také seznam obchodních pravidel. Konkrétně: jaká klíčová slova vás zajímají, jaké regiony, minimální hodnotu zakázky, které CPV kódy chcete sledovat a komu se má digest posílat. Bez těchto vstupů by AI sice uměla text shrnout, ale nepoznala by dobře obchodní relevanci.
Kroky realizace

Krok 1: Vymezte filtrovací pravidla a datový model
Co a proč: Než začnete cokoliv automatizovat, musíte přesně určit, co se má považovat za relevantní zakázku. Bez toho skončíte u e-mailu plného šumu. Cílem prvního kroku je převést obchodní zadání do konkrétních polí, která později použijete v automatizaci i v AI promptu.
Jak přesně: V Airtable vytvořte base s názvem Tender Digest a tabulku Tenders. Přidejte minimálně tato pole: tender_id, title, buyer, description, cpv_code, estimated_value, currency, region, deadline, source_url, matched_keywords, ai_summary, ai_relevance_score, sent_in_digest. Dále si vytvořte druhou tabulku Rules s poli keywords_include, keywords_exclude, min_value, regions, cpv_include, email_to.
Ukázka vstupu do tabulky Rules:
keywords_include: cloud, helpdesk, kybernetická bezpečnost, servis serverů
keywords_exclude: nábytek, potraviny
min_value: 500000
regions: Praha; Středočeský kraj
cpv_include: 72000000, 72250000, 48800000
email_to: obchod@firma.cz
Očekávaný výstup je jednoznačný datový model a sada pravidel, se kterou bude pracovat zbytek workflow. Metrika úspěšnosti: umíte vzít pět reálných zakázek a u každé bez váhání určit, zda má projít filtrem a proč.
Tento krok je důležitý i pro méně pokročilé uživatele. Když si pravidla nesepíšete dopředu, budete později ladit AI tam, kde je chyba ve vstupních kritériích. Nejprve proto rozhodněte, co hledáte, a až potom to automatizujte.
Krok 2: Připojte zdroj veřejných zakázek a načtěte první data
Co a proč: Teď potřebujete dostat skutečné záznamy do workflow. Smyslem tohoto kroku je ověřit, že umíte pravidelně načítat nové tendry a mapovat je do polí v Airtable. Zatím neřešte AI ani e-mail. Soustřeďte se jen na spolehlivé získání dat.
Jak přesně: V Make vytvořte nový scenario. Jako první modul přidejte Scheduler a nastavte spouštění například na Every day at 06:30 Europe/Prague. Poté přidejte modul HTTP > Make a request. V něm nastavte metodu GET, URL podle vybraného oficiálního zdroje a parametr časového filtru, pokud jej API podporuje. Typický vstup může vypadat takto:
Method: GET
URL: https://example-official-source.cz/api/tenders
Query string:
published_from=2026-03-11
limit=100
format=json
Pokud zdroj vrací JSON, přidejte JSON > Parse JSON. Namapujte pole jako id, title, description, buyer_name, estimated_value, deadline_date a url. Následně použijte Airtable > Create a record a uložte data do tabulky Tenders.
Ukázka jednoduchého mapování:
API vstup:
{
"id": "VZ-2026-001245",
"title": "Správa cloudové infrastruktury",
"buyer_name": "Městská část Praha 6",
"estimated_value": 2400000,
"deadline_date": "2026-03-28",
"url": "https://example-official-source.cz/tender/VZ-2026-001245"
}
Airtable výstup:
tender_id = VZ-2026-001245
title = Správa cloudové infrastruktury
buyer = Městská část Praha 6
estimated_value = 2400000
deadline = 2026-03-28
source_url = https://example-official-source.cz/tender/VZ-2026-001245
Výstup: tabulka v Airtable obsahuje první načtené zakázky. Metrika úspěšnosti: alespoň 95 % polí z API je správně namapováno a u minimálně 20 záznamů se neztratí klíčové informace jako název, termín a URL.
Jakmile data tečou do tabulky, můžete přejít od pouhého sběru k jejich třídění. To je důležité, protože bez filtru by digest rychle ztratil hodnotu.
Krok 3: Přidejte deduplikaci a základní obchodní filtr
Co a proč: Veřejná data často obsahují aktualizace stejné zakázky, opakované záznamy nebo položky, které se vás netýkají. Cílem tohoto kroku je zabránit duplicitám a propustit dál jen zakázky, které splňují základní obchodní podmínky.
Jak přesně: V Make za modul načtení dat vložte Airtable > Search records a hledejte podle tender_id. Použijte formula výraz:
{tender_id} = "{{id_z_API}}"
Pokud záznam existuje, workflow ukončete nebo aktualizujte jen vybraná pole. Pokud neexistuje, vytvořte nový záznam. Poté přidejte Filter v Make s konkrétními podmínkami. Například:
estimated_value >= 500000regionobsahuje Praha nebo Středočeský krajtitle + descriptionobsahuje jedno z klíčových slov z tabulky Rulestitle + descriptionneobsahuje vylučující slova jako nábytek
Pro jednodušší variantu můžete použít pole matched_keywords, do kterého uložíte nalezená slova. Například přes modul Text parser nebo přes jednoduchý JavaScript v modulu Code v Make.
Vstup:
title = Dodávka helpdesk systému a servisní podpora
description = Předmětem plnění je nový helpdesk a integrace na identity management
Výstup:
matched_keywords = helpdesk; servis
basic_filter_pass = true
Výstup: v tabulce zůstávají jen nové a základně relevantní zakázky. Metrika úspěšnosti: podíl duplicit po týdnu provozu je pod 2 % a alespoň 70 % zakázek, které projdou filtrem, je při ruční kontrole skutečně relevantních.
Tento mezikrok záměrně předchází AI. Je levnější odfiltrovat šum pravidly než posílat vše do jazykového modelu. Teprve na užší výběr dává smysl nasadit shrnutí a hodnocení relevance.
Krok 4: Vytvořte AI shrnutí a skóre relevance
Co a proč: Obchodník nepotřebuje číst celý text zakázky. Potřebuje rychle pochopit, co se poptává, jaký je termín, jaká je hodnota a proč je to zajímavé právě pro jeho firmu. Úkolem AI v tomto kroku není nahrazovat právní čtení zadávací dokumentace, ale vytvořit stručný a konzistentní přehled.
Jak přesně: Do Make přidejte modul OpenAI > Create a Chat Completion nebo odpovídající oficiální modul podle aktuální nabídky integrace. Jako model zvolte například gpt-4o-mini, pokud je ve vašem účtu dostupný. Do promptu pošlete název, popis, zadavatele, hodnotu, termín a vaše obchodní preference z tabulky Rules.
Ukázka systémové instrukce:
Jsi analytik veřejných zakázek. Vrať JSON se strukturou:
{
"summary_cz": "max 70 slov",
"relevance_score": 0-100,
"why_relevant": "max 30 slov",
"risk_note": "max 25 slov"
}
Skóre zvyšuj, pokud zakázka odpovídá klíčovým slovům, CPV kódům a regionu. Pokud si nejsi jistý, uveď nižší skóre.
Ukázka uživatelského vstupu:
Název: Správa cloudové infrastruktury
Zadavatel: Městská část Praha 6
Popis: Hledáme dodavatele pro správu virtualizace, backup řešení a dohled 24/7.
CPV: 72250000
Hodnota: 2400000 CZK
Region: Praha
Termín: 2026-03-28
Naše priority: cloud, helpdesk, kybernetická bezpečnost, servis serverů
Minimální hodnota: 500000 CZK
Očekávaný výstup z modelu:
{
"summary_cz": "Zakázka se týká správy cloudové a virtualizační infrastruktury včetně záloh a nepřetržitého dohledu. Pro IT dodavatele se servisním modelem jde o přímo relevantní příležitost.",
"relevance_score": 91,
"why_relevant": "Shoda s cloudem, servisem serverů i regionem Praha.",
"risk_note": "Je nutné ověřit detailní SLA a kvalifikační požadavky."
}
Výsledek uložte do polí ai_summary, ai_relevance_score, why_relevant a risk_note. Metrika úspěšnosti: alespoň 80 % AI shrnutí je při ruční kontrole věcně správných a skóre relevance pomáhá odlišit horních 20 % nejzajímavějších zakázek.
Pro méně pokročilé uživatele je důležité jedno pravidlo: po modelu chtějte strukturovaný výstup. JSON se lépe kontroluje, ukládá i zobrazuje v e-mailu než volný text.
Krok 5: Sestavte denní digest v HTML e-mailu
Co a proč: Jakmile máte relevantní zakázky a jejich shrnutí, je čas je převést do podoby, kterou někdo skutečně otevře a přečte. Cílem je vytvořit stručný digest s konzistentní strukturou, aby příjemce během dvou minut poznal, čemu má věnovat pozornost.
Jak přesně: V Make vytvořte druhé scenario nebo navazující větev, která se spustí jednou denně po načtení a zpracování dat. Pomocí Airtable > Search records vyfiltrujte záznamy, které mají sent_in_digest = false a třeba ai_relevance_score >= 70. Poté použijte Tools > Text aggregator nebo Array aggregator a složte HTML blok pro každou zakázku.
Ukázka HTML šablony jedné položky:
{{title}}
Zadavatel: {{buyer}}
Hodnota: {{estimated_value}} {{currency}}
Termín: {{deadline}}
Relevance: {{ai_relevance_score}}/100
{{ai_summary}}
Proč je relevantní: {{why_relevant}}
Poznámka: {{risk_note}}
Předmět e-mailu nastavte například na Denní tender digest | 6 relevantních zakázek | 12. 3. 2026. Pro odeslání použijte Gmail > Send an email. V poli To mapujte adresu z tabulky Rules, například obchod@firma.cz.
Výstup: příjemce dostane jeden přehledný e-mail se seznamem relevantních zakázek. Metrika úspěšnosti: open rate nad 50 % u interního týmu a průměrná délka digestu do 10 položek, aby byl stále čitelný.
Když e-mail funguje, zbývá vyřešit poslední praktický detail: aby se stejné zakázky neposílaly opakovaně a aby šlo snadno dohledat, co už odešlo.
Krok 6: Označte odeslané záznamy a přidejte auditní stopu
Co a proč: Bez zpětného označení odeslaných položek začne systém posílat duplicitní digesty nebo ztratíte přehled o tom, co kdy odešlo. Cílem je uzavřít smyčku a udělat z MVP provozně použitelný nástroj.
Jak přesně: Po úspěšném odeslání e-mailu přidejte v Make modul Airtable > Update a record a nastavte u všech zařazených zakázek sent_in_digest = true a digest_sent_at = now(). Doporučuji přidat i pole digest_batch_id, například ve formátu 2026-03-12-morning. V případě chyby odeslání změnu neprovádějte, aby se položky zkusily znovu při dalším běhu.
Ukázka vstupu a výstupu:
Vstup:
record_id = recA1B2C3
sent_in_digest = false
očekávaný výstup po odeslání:
sent_in_digest = true
digest_sent_at = 2026-03-12T06:35:22+01:00
digest_batch_id = 2026-03-12-morning
Volitelně si založte třetí tabulku Digest Log s poli batch_id, records_count, email_to, status, sent_at. To velmi pomůže při pozdějším ladění.
Výstup: systém umí spolehlivě rozlišit nové a už odeslané položky. Metrika úspěšnosti: nulový počet duplicitně odeslaných zakázek během pěti po sobě jdoucích dnů provozu.
Tím vzniká funkční MVP. Aby ale bylo opravdu použitelné, je potřeba ještě ověřit kvalitu výstupu na reálných datech, ne jen to, že workflow technicky doběhne.
Krok 7: Doladění relevance pomocí jednoduchého zpětnovazebního pole
Co a proč: Po několika dnech provozu zjistíte, že některé zakázky jsou sice textově podobné, ale obchodně neperspektivní. Proto se vyplatí přidat jednoduchou zpětnou vazbu od uživatele. Cílem není strojové učení v plném smyslu, ale praktické ladění pravidel i promptu podle reality.
Jak přesně: Do tabulky Tenders přidejte pole user_feedback s hodnotami relevantní, sporné, nerelevantní. Jednou za pár dní nechte obchodníka ohodnotit 20 až 30 doručených položek. V Make pak můžete přidat podmínku, která sníží prioritu zakázek s podobnými znaky jako dříve označené nerelevantní případy. Zároveň upravte prompt, například doplněním věty:
Pokud zakázka obsahuje jen obecné IT služby bez jasné vazby na cloud, bezpečnost nebo správu serverů, sniž relevance_score pod 60.
Ukázka vstupu:
title = Rámcová smlouva na kancelářské ICT vybavení
user_feedback = nerelevantní
Očekávaný výstup po úpravě pravidel:
u podobných budoucích zakázek se ai_relevance_score sníží například z 74 na 48
Výstup: relevance digestu se zlepšuje podle skutečných preferencí týmu. Metrika úspěšnosti: po dvou iteracích zpětné vazby vzroste podíl užitečných položek v digestu alespoň o 15 %.
Testování
Testování rozdělte na tři vrstvy. První je technické testování toku dat. Ověřte, že se korektně načtou záznamy, že se mapují správná pole a že nepadá parsování JSON. Druhá vrstva je obsahová. Vyberte alespoň 30 zakázek z posledních dnů a ručně porovnejte, zda filtr i AI skóre odpovídají očekávání. Třetí vrstva je provozní: sledujte, zda se e-mail doručuje ve správný čas a bez duplicit.
Praktický testovací checklist může vypadat takto:
- Zakázka s hodnotou 300 000 Kč se nesmí dostat do digestu, pokud je
min_value = 500000. - Zakázka s klíčovým slovem cloud a CPV
72250000musí projít do AI kroku. - Stejný
tender_idnesmí vytvořit druhý záznam. - Model musí vrátit validní JSON bez volného textu navíc.
- E-mail musí obsahovat funkční odkaz
source_url.
Dobrá minimální metrika kvality MVP je tato: z 20 položek v digestu je alespoň 14 vyhodnoceno uživatelem jako obchodně užitečných. Pokud jste výrazně pod touto hranicí, neřešte zatím další funkce a vraťte se k filtrům, klíčovým slovům a promptu.
Nasazení
Pro nasazení do běžného provozu nastavte v Make pevný čas běhu, ideálně před začátkem pracovního dne. Pro české týmy dává smysl například 06:30 nebo 07:00. Zároveň nastavte notifikaci při chybě scénáře. V Make to uděláte v nastavení scénáře přes upozornění na neúspěšný běh. Pokud používáte Gmail, ověřte si limity odesílání a reputaci odesílací adresy.
V Airtable doporučuji vytvořit pohledy New filtered, Sent today a Low confidence. Poslední pohled může filtrovat záznamy s ai_relevance_score mezi 50 a 69, které stojí za občasnou ruční kontrolu. Nasazení MVP tím získá praktickou obsluhu: víte, co přišlo, co odešlo a co si zaslouží doladění.
Pokud budete systém používat pro více týmů, nepřidávejte vše do jednoho digestu. Lepší je mít samostatnou tabulku pravidel a generovat digest pro každý segment zvlášť, například IT infrastruktura, marketingové služby nebo stavební projekty. Jinak relevance rychle klesne.
Limity
První limit je zdroj dat. U veřejných zakázek se mohou měnit formáty, dostupnost API, kvalita popisů i úplnost metadat. Pokud některý zdroj neposkytuje dobře strukturované pole pro CPV, region nebo hodnotu, bude filtrování méně přesné. To je potřeba brát jako omezení vstupu, ne jako selhání samotné AI.
Druhý limit je interpretace textu. Jazykový model umí dobře shrnovat, ale nemusí správně pochopit právní nuance, kvalifikační požadavky nebo skryté výluky. Proto nesmí digest nahrazovat finální lidské posouzení. Je to nástroj pro předvýběr, ne právní nebo obchodní verdikt.
Třetí limit je cena a rychlost. Pokud budete denně posílat do AI stovky dlouhých popisů, náklady porostou. V praxi se proto vyplatí nejprve použít jednoduchý pravidlový filtr a teprve poté AI. Přesně tak je navržen i tento postup.
Čtvrtý limit je relevance napříč obory. Jeden prompt nebude stejně dobře fungovat pro IT služby, stavebnictví i zdravotnickou techniku. Pokud sledujete více segmentů, je lepší mít pro každý z nich vlastní pravidla a lehce upravenou instrukci pro model.
FAQ
Je možné projekt postavit i bez Airtable?
Ano. Místo Airtable můžete použít Google Sheets, PostgreSQL, Notion nebo interní CRM. Pro MVP je ale Airtable praktický, protože kombinuje databázi, filtrování i ruční kontrolu bez programování.
Musím použít OpenAI?
Nemusíte. Můžete použít i jiný model dostupný přes API, pokud umí spolehlivě vracet strukturovaný výstup. V tomto návodu je OpenAI zvoleno kvůli jednoduché integraci a široké dostupnosti.
Jak často má digest chodit?
Nejčastěji jednou denně v pracovní dny. Pokud je zakázek hodně, lze přidat i polední běh. U menších segmentů může stačit souhrn třikrát týdně. Rozhodující je, aby e-mail nebyl příliš dlouhý a neztratil čitelnost.
Co když AI vrací nekonzistentní shrnutí?
Nejprve zpřesněte prompt a vyžadujte JSON s pevnou strukturou. Dále zkraťte vstup jen na důležitá pole. Pokud problém přetrvá, přidejte validaci výstupu a při chybě použijte záložní pravidlové shrnutí z polí v databázi.
Lze do digestu přidat i prioritu nebo doporučení další akce?
Ano. Přidejte pole next_action, například ověřit kvalifikaci, poslat obchodníkovi nebo ignorovat. V promptu ale jasně uveďte, že jde o orientační doporučení, ne o závazné rozhodnutí.
Je vhodné posílat do modelu celé zadávací dokumentace?
Pro MVP většinou ne. Je to dražší, pomalejší a často zbytečné. Nejprve pracujte s metadaty a krátkým popisem zakázky. Celé dokumenty dává smysl přidat až ve druhé fázi projektu pro detailnější analýzu shortlisted případů.
Doporučený AI stack pro realizaci
| 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 |
Poznámka: U uvedených služeb používáme affiliate odkazy. Pokud přes ně provedete nákup, můžeme získat provizi bez navýšení ceny pro vás.
Odkazy v článku
Zdroje ilustracnich obrazku
Vlastni ilustracni obrazek byl vytvoren pomoci OpenAI Images API.




