Vývoj frameworků pro AI agenty: od Autogen k LangGraph

Frameworky pro AI agenty prošly dlouhou cestou – od vysoké jednoduchosti Autogenu po nástrojově orientovanou exekuci LangChainu. Nyní LangGraph nastavuje nový standard s větší flexibilitou, modularitou a kontrolou, čímž dává vývojářům sílu vytvářet sofistikovanější multi-agentní systémy.

The Evolution of AI Agents frameworks: From Autogen to LangGraph

In the past, severallibraries such as Autogen and Langchain Agent Executor were usedto create AI agents and the workflow of their tasks. These tools aimed tosimplify and automate processes by enabling multiple agents to work together inperforming more complex tasks. But for the past several months, we have beenworking with LangGraph and felt in love with it for the significantimprovements it offers to AI developers.

Autogen was oneof the first frameworks and provided a much needed higher level of abstraction,making it easier to set up AI agents. However, the interaction between agentsfelt often somewhat like "magic" — too opaque for developers whoneeded more granular control over how the processes were defined and executed.This lack of transparency could lead to challenges in debugging andfine-tuning.

Then came LangchainAgent Executor, which allowed developers to pass "tools" toagents, and the system would keep calling these tools until it produced a finalanswer. It even allowed agents to call other agents, and the decision on whichagent to use next was managed by AI.

However, the LangchainAgent Executor approach had its drawbacks. For instance:

  • It was difficult to track the individual steps of each agent. If one     agent was responsible for searching Google and retrieving results, it     wasn’t easy to display those results to the user in real-time.
  • It also posed     challenges in transferring information between agents. Imagine one agent     uses Google to find information and another is tasked with finding related     images. You might want the second agent to use a summary of the article as     input for image searches, but this kind of information handoff wasn’t     straightforward.
State of the art AI Agents framework? LangGraph!

LangGraphaddresses many of these limitations by providing a more modular and flexibleframework for managing agents. Here’s how it differs from its predecessors:

FlexibleGlobal State Management

LangGraph allowsdevelopers to define a global state. This means that agents can eitheraccess the entire state or just a portion of it, depending on their task. Thisflexibility is critical when coordinating multiple agents, as it allows forbetter communication and resource sharing. For instance, the agent responsiblefor finding images could be given a summary of the article, which it could useto refine its keyword searches.

 

ModularDesign with Graph Structure

At the core of LangGraphis a graph-based structure, where nodes represent either calls to alanguage model (LLM) or the use of other tools. Each node functions as a stepin the process, taking the current state as input and outputting an updatedstate.

The edges in thegraph define the flow of information between nodes. These edges can be:

  • Optional: allowing the process to branch     into different states based on logic or the decisions of the LLM.
  • Required: ensuring that     after a Google search, for example, the next step will always be for a     copywriting agent to process the search results.
Debuggingand Visualization

LangGraph also enhancesdebugging and visualization. Developers can render the graph, making it easierfor others to understand the workflow. Debugging is simplified throughintegration with tools like Langsmith, or open-source alternatives like Langfuse.These tools allow developers to monitor the execution in real-time, displayingactions such as which articles were selected, what’s currently happening, andeven statistics like token usage.


TheTrade-Off: Flexibility vs. Complexity

While LangGraph offerssubstantial improvements in flexibility and control, it does come with asteeper learning curve. The ability to define global states, manage complexagent interactions, and create sophisticated logic chains gives developerslow-level control but also requires a deeper understanding of the system.

LangGraph marks asignificant evolution in the design and management of AI agents, offering apowerful, modular solution for complex workflows. For developers who needgranular control and detailed oversight of agent operations, LangGraph presentsa promising option. However, with great flexibility comes complexity, meaningdevelopers must invest time in learning the framework to fully leverage itscapabilities. That’s what we have done, making LangGraph our tool of choice forall complex GenAI solutions that need multiple agents working together.

 

 

Shrnutí

LangGraph represents a major leap forward in the development and orchestration of AI agents. Its graph-based architecture and flexible state management offer unmatched control over complex agent workflows, making it an ideal choice for advanced GenAI applications. While it demands a steeper learning curve, the benefits in transparency, modularity, and debugging far outweigh the initial effort. For developers serious about building scalable, multi-agent systems, LangGraph is not just a tool — it’s the new standard.

Podobné články

Nejnovější zprávy, průzkumy, rozhovory, technologie a zdroje.

AI
0
min
read

Proč AI coding nástroje a nové knihovny nemají běžet přímo na vašem Macu

AI coding nástroje nevytvořily nový bezpečnostní problém. Jen udělaly starý problém mnohem viditelnější. Když vývojáři spouštějí agenty, dependencies a shell commandy přímo na svém Macu, často tím vystavují riziku SSH klíče, .env soubory, browser sessions, cloud credentials a někdy i produkční přístupy. Nedávné supply-chain incidenty kolem LiteLLM a axiosu ukazují, proč tenhle default přestává být přijatelný — a proč by se skutečná izolace na úrovni jednotlivých projektů měla stát běžnou součástí engineering praxe.

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.

AI
0
min
read

Jak vytvořit inteligentní vyhledávání: Od fulltextu k hybridnímu vyhledávání s optimalizací

Když jsme začali pracovat na pokročilém vyhledávacím systému, rychle jsme zjistili, že tradiční fulltextové vyhledávání má vážné limity. Uživatelé hledají zkratky, píší dotazy s překlepy, nebo používají synonyma, která tradiční vyhledávání nerozpozná. Navíc potřebujeme, aby systém vyhledával nejen v názvech entit, ale i v jejich popisech a souvisejících informacích. A co víc – uživatelé často hledají podle kontextu, například synonyma, nebo dokonce v různých jazycích. Tento článek popisuje, jak jsme vybudovali hybridní vyhledávací systém kombinující fulltextové vyhledávání (BM25) s vektorovými embeddingy, a jak jsme pomocí hyperparameter search optimalizovali scoring, abychom dosáhli nejlepších výsledků pro naše uživatele.
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ů.

AI
0
min
read

EU AI Act: Co to je, koho se týká a jak ho vaší firmě pomůžeme zvládnout bez stresu

V roce 2024 vstoupil v platnost tzv. AI Act, první komplexní zákon Evropské unie, který reguluje používání a vývoj umělé inteligence. Kterých firem se týká, jak se vyhnout drakonickým pokutám a jak to funguje, když chcete, aby za vás starosti se zaváděním legislativy AI Act vyřešil někdo jiný, například BigHub? Rozvoj umělé inteligence v posledních letech nabral takovou rychlost, že na něj musí stejně bleskově reagovat i legislativa. V BigHub věříme, že je to krok správným směrem.
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í.

Napište si o nezávaznou konzultaci zdarma

Chcete s námi probrat podrobnosti? Vyplňte krátký formulář níže a my se vám brzy ozveme, abychom si s vámi domluvili termín nezávazné online konzultace zdarma.

Ověřeno 100 + firmami
Thank you! Your submission has been received.
Oops! Something went wrong.