Jak náš systém AI bojuje proti podvodům v mezinárodní přepravě

Když se dnes řeší bezpečnost kolem vibe coding toolů, často to zní, jako by šlo o úplně nový problém. Ve skutečnosti nejde o nic nového. Jen jsme si poslední roky zvykli spouštět cizí kód, cizí dependencies a čím dál častěji i cizí shell commandy přímo na svém lokálním stroji, kde máme SSH klíče, .env soubory, přihlášený browser, přístupy do cloudu a často i produkci.

AI tooling ten problém nevymyslel. Jen ho dost zesílil a udělal viditelnější.

Na macOS je to podle mě vidět asi nejlíp. Spousta lidí nechce vyvíjet v Dockeru, protože DX jde rychle dolů a kontejnery na Macu pořád nejsou bez overheadu. Takže reálný default je pořád stejný: všechno běží na host machine a doufá se, že se nic nestane.

Tohle funguje přesně do chvíle, než to nefunguje.

LiteLLM jen připomněl starý problém

24. března 2026 se na PyPI objevily kompromitované verze litellm 1.82.7 a 1.82.8. Nešlo o žádný exotický exploit. Stačilo udělat pip install a do prostředí se dostal škodlivý .pth soubor, který se spouštěl při startu Pythonu.

Ten pak sahal po věcech, které na vývojářském stroji typicky najde snadno:

• SSH klíče
• .env soubory
• cloud credentials
• další secrets a konfigurační soubory

Pak je odesílal na remote server.

Na tomhle incidentu je důležité hlavně to, jak banální ten attack path byl. Nepotřeboval rozbít Python, obejít kernel ani přesvědčit člověka, aby spustil něco extra. Stačilo, že vývojář udělal to, co dělá běžně každý den: nainstaloval si dependency.

Paradoxně se na celou věc přišlo rychleji i proto, že malware nebyl úplně dobře napsaný a na některých strojích odpálil fork bombu. Kdyby se držel při zemi a jen tiše exfiltroval data, je dost možné, že by to déle unikalo pozornosti.

Podle mě by tomuhle podlehla velká část běžných developerů, ne jen lidi, kteří experimentují s vibe codingem. Důvod je jednoduchý: málokdo má lokální Python prostředí opravdu izolované.

A ani JavaScript svět na tom nebyl líp

Tohle mimochodem není jen Python story.

30. a 31. března 2026 se kompromitoval i axios, jedna z nejpoužívanějších knihoven v JavaScript světě. Útočník převzal maintainer účet na npm a publikoval škodlivé verze axios@1.14.1 a axios@0.30.4.

Zajímavé je, že škodlivý payload nebyl přímo v samotném axiosu. Ty verze jen přidaly novou transitive dependency plain-crypto-js, která se spouštěla přes postinstall hook. Jinými slovy: i tady stačilo udělat obyčejný install a z dependency chainu se stal execution chain.

To je přesně důvod, proč mi přijde nebezpečné tvářit se, že supply-chain riziko je jen problém nějakých pochybných balíčků z okraje ekosystému. Není. Minulý týden se to ukázalo i v jednom z nejběžnějších HTTP clientů pro Node.js.

exclude-newer je rozumný default

Jeden z mála levných guardrailů, které dávají smysl skoro každému, je neinstalovat úplně čerstvé releasy balíčků.

V uv jde použít exclude-newer, takže si dependency resolution omezíte jen na balíčky publikované před zvoleným datem:

‍

[tool.uv]
exclude-newer = "2026-03-24"

‍

Tohle není magická obrana. Jen si tím kupujete čas. Když budete držet třeba 14denní odstup, je slušná šance, že se během té doby na kompromitovaný release přijde a někdo ho stáhne nebo alespoň rozjede warningy napříč komunitou.

Úplně stejná logika platí pro AI coding tools

Stejně jako nechcete bezmyšlenkovitě pouštět čerstvé dependencies na hostu, nechcete na hostu pouštět ani code generátor s plným přístupem ke všemu okolo.

Tohle není argument proti Codexu, Claude Code ani jakémukoliv jinému nástroji. Je to argument proti tomu, jak velký trust těm nástrojům dáváme by default.

Lehké sandboxy jsou dobrý začátek. Codex CLI na macOS historicky používal sandbox-exec a umí tím dost omezit, kam proces smí sáhnout. V Claude Code jde sandbox zapnout přes /sandbox. V obou případech je to výrazně lepší než režim, kde agent vidí celý disk a může bez omezení pouštět shell.

Tohle má dvě praktické výhody:

• agent typicky vidí jen repozitář nebo explicitně povolené cesty
• nemusíte potvrzovat každou drobnost jen proto, abyste měli aspoň nějaký control surface

Pro běžné čtení, editaci souborů a část shell práce je to fakt příjemný middle ground.

Kde tenhle model naráží

Problém je, že lehký sandbox není totéž co skutečná izolace.

Jakmile nástroj potřebuje dělat něco trochu praktičtějšího, začnou vylézat hrany:

• instalace balíčků přes uv, pip, npm nebo podobné nástroje často sahá do globálních cache
• browser tooling nemusí uvnitř sandboxu fungovat dobře nebo vůbec
• některé MCP servery potřebují přístup mimo boundary repa
• dřív nebo později narazíte na command, který prostě musíte pustit mimo sandbox

A v ten moment se stejně vyhodí otázka na vibecodera jestli může systém sandbox odejít a většina klikne prostě na "Yes".

Proto mi přijde důležité neplést si "má nějaký sandbox mode" s "je to bezpečně izolované".

Co podle mě dává smysl víc

Pokud chceme agenty nebo code generátory používat vážně, potřebujeme reálný sandbox. Ideálně separátní VM nebo microVM pro každý projekt. Na Macu to může být něco ve stylu Lima nebo obdobné VM-based řešení. Docker sandboxy jsou v principu podobný směr, i když na macOS často naráží na performance a DX.

Pointa ale není konkrétní produkt. Pointa je trust boundary.

Do takového prostředí přesunete jen to, co ten konkrétní projekt opravdu potřebuje:

• checkout repa
• project-scoped credentials
• lokální cache jen pro ten projekt
• případně browser session nebo MCP servery, ale zase jen tam, kde to dává smysl

Tím snížíte blast radius hned dvakrát.

Za prvé: když agent spustí destruktivní command typu rm -rf /, tak zničí maximálně svůj sandbox.

Za druhé: když nainstalujete kompromitovanou dependency typu infikovaného litellm, tak z ní neodtečou všechny credentials z celého laptopu, ale maximálně to, co jste do toho konkrétního prostředí dali. Ideálně jen dev secrets pro jeden projekt.

To pořád není příjemný incident. Ale je to o řád lepší incident.

Classifier je fajn, ale není to sandbox

Claude Code teď přidal i auto mode, kde nad citlivějšími akcemi běží další classifier. Ten vyhodnocuje transcript a jednotlivé tool calls, hlavně Bash commandy a další akce mimo repo, a snaží se blokovat věci jako data exfiltration, credential hunting nebo destruktivní zásahy mimo scope úkolu.

To je rozumný posun. Approval fatigue je reálná a ruční odklikávání všeho není moc udržitelný model.

Ale i tady je podle mě důležité držet si správné očekávání: classifier je guardrail, ne izolace.

Stejně tak to neřeší supply-chain problém. Pokud si uvnitř důvěryhodného prostředí nainstalujete škodlivý balíček, classifier nad Bash commandy vám nepomůže proti tomu, co ten balíček provede při importu nebo startu interpreteru.

Co bych z toho bral jako praktický default

Můj aktuální take je jednoduchý:

• nepouštět úplně čerstvé dependencies bez odstupu
• neprovozovat AI coding tools přímo na host machine s plným přístupem
• když už používám lehký sandbox, nebrat ho jako finální řešení
• pro důležitější práci mít per-project izolované prostředí s omezeným blast radiusem

Tohle všechno platilo už dávno předtím, než někdo vymyslel termín vibe coding.

Jen teď už není moc kam uhýbat. Když dáte agentovi shell, filesystem, browser a credentials, dáváte mu v praxi velmi silné pravomoci. A jak ukázal LiteLLM incident, podobně silné pravomoci dostává i obyčejný package manager ve chvíli, kdy mu bez izolace dovolíte instalovat cizí kód přímo na svůj laptop.

To není niche security debata. To je docela obyčejný engineering default, který jsme měli mít už dávno.

Apple právě pracuje na novém container enginu který tohle všechno bude mít doufám built in. Do té doby se snažím opravdu koukat kdykoliv se spouští příkazy mimo sandbox.

Problém: Limity tradičního vyhledávání

Tradiční fulltextové vyhledávání, založené na algoritmech jako BM25, má několik zásadních omezení:

1. Překlepy a variace

• Uživatelé často píší dotazy s překlepy nebo používají různé varianty názvů
• Tradiční vyhledávání vyžaduje přesnou shodu nebo velmi podobný text

2. Vyhledávání pouze v názvech

• Fulltextové vyhledávání typicky hledá pouze v konkrétních polích (například název produktu nebo entity)
• Pokud je relevantní informace v popisu nebo v souvisejících entitách, systém ji nenajde

3. Chybějící sémantické porozumění

• Systém nerozpozná synonyma nebo související koncepty
• Například dotaz "auto" nenajde výsledky obsahující "automobil" nebo "vůz", i když jde o stejný koncept
• Mezijazyčné vyhledávání je téměř nemožné – český dotaz nenajde anglické výsledky

4. Kontextové vyhledávání

• Uživatelé často hledají podle kontextu, ne přesných názvů
• Například dotaz "produkty od výrobce X" by měl najít všechny relevantní produkty, i když název výrobce není explicitně uveden v dotazu

‍

Řešení: Hybridní vyhledávání s embeddingy

Řešením je kombinace dvou přístupů: tradičního fulltextového vyhledávání (BM25) a vektorových embeddingů pro sémantické vyhledávání.

Vektorové embeddingy pro sémantické porozumění

Vektorové embeddingy převádějí text do vícerozměrného prostoru, kde podobné významy jsou blízko sebe. To umožňuje:

• Vyhledávání podle významu: Dotaz "notebook" najde výsledky obsahující "laptop", "přenosný počítač" nebo dokonce související koncepty
• Mezijazyčné vyhledávání: Český dotaz může najít anglické výsledky, pokud mají podobný význam
• Kontextové vyhledávání: Systém rozumí vztahům mezi entitami a koncepty
• Vyhledávání v celém obsahu: Embeddingy mohou být vytvořeny z celého dokumentu, nejen z názvu

Proč embeddingy samotné nestačí

I když jsou embeddingy mocným nástrojem, samy o sobě nejsou dostatečné:

• Překlepy: Vektorové embeddingy mohou mít problém s překlepy, protože malá změna v textu může vést k odlišnému embeddingu
• Přesné shody: Někdy chceme najít přesnou shodu názvu, což fulltextové vyhledávání dělá lépe
• Výkon: Vektorové vyhledávání může být pomalejší než optimalizované fulltextové indexy

Hybridní přístup: BM25 + HNSW

Ideální řešení kombinuje oba přístupy:

• BM25 (Best Matching 25): Tradiční fulltextový algoritmus, který exceluje v přesných shodách a zpracování překlepů
• HNSW (Hierarchical Navigable Small World): Efektivní algoritmus pro vyhledávání v prostoru vektorů, který umožňuje rychlé nalezení nejbližších sousedů v embedding prostoru

Kombinací těchto dvou přístupů získáme to nejlepší z obou světů: přesnost fulltextového vyhledávání pro přesné shody a sémantické porozumění embeddingů pro kontextové dotazy.

‍

Výzva: Správné seřazení výsledků

Najít relevantní výsledky je jen první krok. Stejně důležité je je správně seřadit. Uživatelé typicky klikají na první několik výsledků, takže špatné seřazení může výrazně snížit užitečnost vyhledávání.

Proč samotné seřazení (sort by) nestačí

Jednoduché seřazení podle jednoho kritéria (například data) není dostatečné, protože potřebujeme zohlednit více faktorů současně:

• Relevance: Jak dobře výsledek odpovídá dotazu (z fulltextového i vektorového vyhledávání)
• Obchodní hodnota: Výsledky s vyšší marží by měly být výše
• Čerstvost: Novější položky jsou často relevantnější než staré
• Popularita: Populárnější položky mohou být pro uživatele zajímavější

Scoring funkce: Kombinace více faktorů

Místo jednoduchého "sort by" potřebujeme komplexní scoring systém, který kombinuje:

1. Fulltextové skóre: Jak dobře výsledek odpovídá dotazu podle BM25
2. Vektorové distance: Sémantická podobnost podle embeddingů
3. Scoring funkce:
   • Magnitude funkce pro marži/popularitu (vyšší hodnoty = vyšší skóre)
   • Freshness funkce pro čas (novější = vyšší skóre)
   • Další obchodní metriky podle potřeby

Výsledné skóre je pak vážená kombinace všech těchto faktorů. Problém je, že správné váhy nejsou zřejmé a musíme je najít experimentálně.

‍

Hyperparameter search: Hledání optimálních vah

Správné nastavení vah pro fulltextové vyhledávání, vektorové embeddingy a scoring funkce je kritické pro kvalitu výsledků. Tento proces se nazývá hyperparameter search.

Vytvoření testovacího datasetu

Základem úspěšného hyperparameter search je kvalitní testovací dataset. Vytvoříme dataset dotazů, u kterých přesně víme, jak by měly vypadat ideální výsledky:

• Referenční výsledky: Pro každý testovací dotaz máme seznam očekávaných výsledků v správném pořadí
• Anotace: Každý výsledek je označen jako relevantní nebo nerelevantní, případně s prioritou
• Reprezentativní vzorky: Dataset by měl pokrývat různé typy dotazů (přesné shody, synonyma, překlepy, kontextové dotazy)

Metriky pro hodnocení kvality

Abychom mohli objektivně posoudit, zda jsou výsledky dobré, potřebujeme metriky, které porovnávají skutečné výsledky s referenčními:

1. Kontrola úplnosti (Recall)

• Obsahují výsledky vše, co by měly obsahovat?
• Jsou všechny relevantní položky přítomny v seznamu výsledků?

2. Kontrola pořadí (Ranking Quality)

• Jsou výsledky ve správném pořadí?
• Jsou nejrelevantnější výsledky na prvních místech?

Mezi konkrétní metriky patří například NDCG (Normalized Discounted Cumulative Gain), která hodnotí jak úplnost, tak správné pořadí výsledků. Další užitečné metriky zahrnují Precision@K (kolik relevantních výsledků je v prvních K pozicích) nebo MRR (Mean Reciprocal Rank), která měří pozici prvního relevantního výsledku.

Iterativní optimalizace

Proces hyperparameter search probíhá iterativně:

1. Nastavení počátečních vah: Začneme s rozumnými výchozími hodnotami
2. Testování kombinací: Systematicky testujeme různé kombinace vah pro:
   • Váhy fulltextových polí (například název produktu vs. popis)
   • Váhy vektorových polí (embeddingy pro různé části dokumentu)
   • Boost hodnoty pro scoring funkce (marže, čas, popularita)
   • Agregační funkce (jak kombinovat různé scoring funkce)
3. Hodnocení výsledků: Pro každou kombinaci spustíme vyhledávání na testovacím datasetu a vypočítáme metriky
4. Výběr nejlepších parametrů: Vybereme kombinaci s nejlepšími metrikami
5. Refinování: Pokud je to potřeba, zúžíme rozsah testování kolem nejlepších hodnot a opakujeme proces

Tento proces může být časově náročný, ale je nezbytný pro dosažení optimálních výsledků. Automatizace tohoto procesu umožňuje testovat stovky nebo tisíce kombinací parametrů a najít ty nejlepší.

‍

Sledování a iterativní zlepšování

I po optimalizaci parametrů je důležité systém kontinuálně sledovat a zlepšovat.

Sledování chování uživatelů

Klíčovou metrikou je, zda uživatelé klikají na výsledky, které jim systém nabízí. Pokud uživatel neklikne na první výsledek, ale až na třetí nebo čtvrtý, je to signál, že seřazení není optimální.

Co sledovat:

• Click-through rate (CTR): Kolik uživatelů klikne na výsledky
• Pozice kliknutí: Na které pozici uživatelé klikají (ideálně by měli klikat na první výsledky)
• Dotazy bez kliknutí: Dotazy, na které uživatelé vůbec nekliknou, mohou indikovat špatné výsledky

Analýza problémových případů

Když identifikujeme dotazy, kde uživatelé neklikají na první výsledky, měli bychom:

1. Zaznamenat tyto případy: Uložit dotaz, vrácené výsledky a pozici, na kterou uživatel klikl
2. Analyzovat: Proč systém vrátil špatné pořadí? Chybí relevantní výsledky? Jsou na špatných pozicích?
3. Přidat do testovacího datasetu: Tyto případy by měly být součástí našeho testovacího datasetu pro budoucí optimalizace
4. Upravit váhy: Na základě analýzy můžeme upravit váhy nebo přidat nová pravidla

Tento iterativní proces zajišťuje, že systém se neustále zlepšuje a přizpůsobuje se skutečnému chování uživatelů.

‍

Implementace na Azure: AI Search a OpenAI Embeddings

Všechny tyto komponenty můžeme efektivně implementovat pomocí služeb Microsoft Azure.

Azure AI Search

Azure AI Search (dříve Azure Cognitive Search) poskytuje:

• Hybridní vyhledávání: Nativní podpora pro kombinaci fulltextového (BM25) a vektorového vyhledávání
• HNSW indexy: Efektivní implementace HNSW algoritmu pro vektorové vyhledávání
• Scoring profiles: Flexibilní systém pro definování vlastních scoring funkcí
• Text weights: Možnost nastavit váhy pro různá fulltextová pole
• Vector weights: Možnost nastavit váhy pro různá vektorová pole

Azure AI Search umožňuje definovat scoring profiles, které kombinují:

• Magnitude scoring funkce pro numerické hodnoty (marže, popularita)
• Freshness scoring funkce pro časové hodnoty (datum vytvoření, datum aktualizace)
• Text weights pro fulltextová pole
• Vector weights pro vektorová pole
• Agregační funkce pro kombinování různých scoring funkcí

OpenAI Embeddings

Pro vytváření embeddingů používáme OpenAI Embeddings, konkrétně modely jako text-embedding-3-large:

• Kvalitní embeddingy: OpenAI modely poskytují vysoce kvalitní embeddingy, které dobře fungují i pro češtinu
• Konzistentní API: Jednoduchá integrace s Azure AI Search
• Škálovatelnost: OpenAI API zvládne velké objemy požadavků

OpenAI embeddingy jsou zvlášť vhodné pro češtinu, protože byly trénovány na vícejazyčných datech a poskytují dobré výsledky i pro menší jazyky.

Integrace

Azure AI Search umožňuje přímo použít OpenAI embeddingy jako vectorizer, což zjednodušuje integraci. Můžeme definovat vektorová pole v indexu, která automaticky používají OpenAI pro vytváření embeddingů při indexování dokumentů.

‍

Co je AI Act a proč vznikl

AI Act je první ucelený zákon Evropské unie, který stanovuje pravidla pro vývoj a používání umělé inteligence. Myšlenka za vznikem této legislativy je zřejmá: jen díky jasným pravidlům může být AI pro firmy i jejich zákazníky bezpečná, transparentní a etická.

Umělá inteligence dnes proniká do stále více oblastí života i podnikání, a proto EU chce, aby její používání i rozvoj probíhal zodpovědně a bez rizika zneužití, diskriminace či jiných negativních dopadů. AI Act má chránit spotřebitele, posilovat férovou konkurenci a nastavit jednotná pravidla pro všechny členské státy Evropské unie.

‍

Koho se AI Act týká

Ďábel se často skrývá v detailu, což trochu platí také o AI Actu. Tato legislativa totiž nedopadá jen na firmy vyvíjející umělou inteligenci, ale i na ty, které ji jakkoliv používají ve svých produktech, službách nebo interních procesech. Typicky se tak souborem zákonů AI Act musí řídit podniky, které například: 

• vyvíjí AI
• používají AI pro rozhodování o lidech (např. nábor nebo hodnocení výkonu zaměstnanců)
• automatizují zákaznické služby (např. chatboti nebo hlasoví asistenti)
• zpracovávají pomocí AI citlivá data 
• integrují AI do produktů a služeb
• provozují AI systémy třetích stran (např. nasazení hotových AI řešení od externích dodavatelů ve vlastním podnikání)

AI Act samozřejmě rozlišuje běžný software od AI systému, takže je vždy potřeba zjistit, jestli dané řešení pracuje autonomně a adaptivně (tzn. učí se z dat a optimalizuje své výsledky), nebo pouze vykonává předem definované instrukce a nesplňuje tak definici AI řešení. 

Mimochodem: legislativa se vztahuje nejen na nové, ale i na již existující aplikace využívající AI (včetně machine learningu).

Abyste s těmito starostmi nemuseli trávit desítky hodin času a strachovat se, jestli vše splňujete, jak máte, v BigHub implementaci AI Act rádi vyřešíme za vás.

‍

Co konkrétně AI Act reguluje

Legislativa AI Act definuje spoustu detailních požadavků, těmi vás teď ale nechceme zatěžovat. Pro firmu využívající AI je důležité vědět, že se AI Act zabývá několika hlavními kategoriemi.

1. Klasifikace rizik 

Legislativa používá stupnici rizikovosti AI řešení, od minimálně rizikových až po velmi rizikové, nebo dokonce zakázané.

2. Povinnosti vývojářů i provozovatelů AI 

Například dodržování bezpečnostních norem, pravidelná dokumentace nebo zajištění přísného dohledu.

3. Transparentnost a vysvětlitelnost 

Uživatelé AI nástrojů musí vědět, že komunikují s umělou inteligencí. 

4. Zakázané aplikace AI

Například systémy, které manipulují lidským chováním či cíleně diskriminují určité skupiny.

5. Monitorování a hlášení incidentů

Udává firmám povinnost hlásit nežádoucí události a nesprávné fungování AI systémů.

6. Zpracování citlivých dat

AI Act reguluje používání osobních, biometrických či zdravotních údajů všech lidí, kteří s nástroji umělé inteligence pracují.

‍

Vyhněte se obrovským pokutám 

Sankce za nedodržování pravidel stanovených AI Act jsou vysoké, konkrétně vás mohou stát až 7 % z celosvětového obratu firmy, což v případě některých firem činí i miliony eur. 

Proto doporučujeme nad novými AI regulacemi nemávnout rukou a včas je implementovat na všech místech ve firmě, kde využíváte umělou inteligenci.

‍

Přehoďte starosti se zaváděním regulace AI Act na nás

Nemáte desítky hodin času studovat složité zákony a nechcete riskovat, že vaše firma dostane vysokou pokutu? Přehoďte starosti se záváděním regulace AI Act na nás.

Ve spolupráci s největší česko-slovenskou (s mezinárodní působností) advokátní kanceláři HAVEL & PARTNERS, zákazníkům po celém světě dlouhodobě pomáháme zavádět osvědčené postupy a frameworky, zrychlovat inovace a optimalizovat procesy, takže rádi budeme k ruce i vám.

• AI pro vás vyřešíme „na klíč“, kromě vývoje AI řešení se postaráme také o zapracování regulace AI Act. Celým procesem vás postupně provedeme.
• Vytvoříme vaší firmě interní směrnice na využívání AI. 
• Provedeme audit AI aplikací, které již používáte.
• Vaše současné i nově implementované AI aplikace nastavíme tak, aby byly v souladu s AI Act.
• Posoudíme za vás rizika, abyste věděli, která AI řešení a jak můžete používat.
• Pomůžeme vám se zmapováním současné situace i s tvorbou nezbytné dokumentace či procesních povinností.