Ne každý firemní krok potřebuje dlouhou odpověď generativní AI. Když má systém pouze rozhodnout, zda poptávku poslat obchodu, podpoře nebo člověku ke kontrole, dává větší smysl ohraničená volba než volný text. OpenAI 22. října 2026 převedlo Decisions API do obecné dostupnosti právě pro takové situace: nad textem, obrázkem nebo strukturovanými daty vrací pravděpodobnost, jednu z povolených možností nebo skóre.
Pro malou a střední firmu je zajímavá hlavně změna architektury. AI nemusí pokaždé „psát“. Může být úzkou rozhodovací vrstvou uvnitř existujícího procesu, zatímco CRM, e-shop nebo helpdesk dál provádí jasně definované kroky. To může zrychlit třídění a snížit náklady, ale jen pokud firma změří chyby a nechá nejisté případy člověku.
Co bylo 22. října skutečně vydáno
OpenAI oznámilo obecnou dostupnost samostatného endpointu POST /v1/decisions s modelem GPT-6 Luna. Podle oficiálního oznámení má u ohraničených úloh vracet výsledek až desetkrát rychleji než stejný model přes Responses API. Jde o tvrzení výrobce, nikoli o záruku pro každý firemní případ; latenci i přesnost je potřeba změřit na vlastních datech.
Od veřejné bety přibyly nativní JSON vstupy, obrázky v instrukcích jednotlivých otázek, prompt caching pro opakovaný společný kontext, integrace s GPT-Live a až 400 otázek v jednom požadavku. Dokumentace uvádí tři typy odpovědi:
| Typ | Co vrací | Praktický příklad |
|---|---|---|
predicate | Pravděpodobnost od 0 do 1 | Je na fotografii viditelné poškození? |
choice | Jednu z předem povolených možností | Patří dotaz obchodu, podpoře, nebo fakturaci? |
score | Skóre podle uspořádané škály | Jak naléhavý je servisní požadavek? |
To je podstatný rozdíl oproti běžnému chatu. Vývojář předem určí možné výsledky a aplikace s nimi může přímo pracovat. Když ale potřebujete vytvořit dopis, shrnutí, vysvětlení nebo vlastní složitější JSON strukturu, patří úloha dál do Responses API se Structured Outputs.
Proč je ohraničené rozhodnutí pro firmu užitečné
V běžném provozu vznikají stovky malých rozhodnutí, která sama o sobě nejsou složitá. E-mail je třeba přiřadit správnému týmu, přílohu zařadit do typu dokumentu, produktovou fotografii označit ke kontrole nebo objednávku posunout do standardní či nestandardní fronty. Generovat u každého případu odstavec textu je zbytečné, pokud další systém potřebuje jen hodnotu z krátkého seznamu.
OpenAI uvádí cenu 0,10 USD za milion necachovaných vstupních tokenů a 0,01 USD za milion tokenů načtených z cache; výstupní tokeny se u tohoto endpointu neúčtují. Skutečný účet ale ovlivní délka vstupu, zápisy do cache, regionální zpracování a počet opakování. Cena API navíc není celková cena řešení. Patří k ní integrace, příprava dat, evaluace, monitoring a lidská kontrola.
Novinka proto není důvodem nahradit všechny podmínky v systému modelem. Pevné pravidlo typu „faktura po splatnosti delší než 30 dnů“ je levnější a spolehlivější napsat běžnou logikou. Decisions API dává smysl tam, kde vstup obsahuje jazyk, obraz nebo nejednoznačný kontext, který jednoduché if/else neumí dobře zachytit.
Čtyři realistické scénáře pro české SMB
1. Třídění příchozích poptávek
Systém může z textu formuláře zvolit obchodní kategorii, přiřadit region a odhadnout, zda chybí informace. Neměl by však sám slíbit cenu, termín nebo dostupnost. Nízká jistota patří do fronty „doplnit člověkem“, ne do automatického zamítnutí.
2. Směrování zákaznické podpory
Dotaz lze rozdělit mezi reklamace, logistiku, platby a technickou podporu. Přínos se dá měřit časem do prvního správného přiřazení a podílem případů, které musel tým přeposlat jinam. Samotná rychlost API nemá hodnotu, pokud klasifikace vytváří více práce.
3. Kontrola produktových fotografií
Obrazový vstup může pomoci označit snímky s pravděpodobným poškozením, chybějícím štítkem nebo špatným úhlem. Výsledek má být pomocný filtr. U reklamace, vratky nebo finančního nároku musí konečné rozhodnutí vycházet z pravidel firmy a ověřených podkladů.
4. Prioritizace interních front
Požadavky z provozu lze skórovat podle předem popsané naléhavosti. Model ale nesmí dostat neurčitou instrukci „urči, co je důležité“. Jednotlivé úrovně potřebují pozorovatelná kritéria: dopad na zákazníka, počet dotčených objednávek, bezpečnostní riziko nebo blížící se termín.
Jak postavit bezpečný pilot v šesti krocích
- Vyberte jedno opakované rozhodnutí. Začněte krokem s vysokým objemem, nízkým rizikem a jasnými možnostmi. Nepoužívejte první pilot pro úvěr, zaměstnání, zdravotní doporučení ani jiný zásadní dopad na člověka.
- Sepište správné odpovědi. Kategorie se nesmějí překrývat. Přidejte možnost „nelze rozhodnout“ nebo „lidská kontrola“, aby model nemusel za každou cenu vybrat chybnou větev.
- Připravte označený vzorek. Vezměte historické případy, u nichž tým zná správný výsledek. Oddělte vývojovou a testovací sadu a zahrňte i neobvyklé, krátké či chybné vstupy.
- Nastavte prahy podle ceny chyby. Jiný práh snese interní štítek a jiný automatický krok vůči zákazníkovi. Dokumentace výslovně doporučuje vycházet z ceny falešně pozitivních a falešně negativních výsledků.
- Spusťte režim bez zápisu. Nechte model několik dní rozhodovat paralelně s lidmi, ale nic automaticky neměňte. Porovnejte přesnost, rychlost, náklady a důvody neshod.
- Automatizujte jen bezpečný střed. Vysoce jisté, nízkorizikové případy mohou pokračovat; nejisté a citlivé zůstanou ve frontě. Sledujte změnu dat v čase a pravidelně znovu vyhodnocujte vzorek.
Takový postup navazuje na obecný princip AI automatizace: nejdřív popsat proces, vstupy, výstupy a odpovědnost, teprve potom přidat model. Pokud si nejste jistí, kde začít, pomůže AI audit najít úzký případ s měřitelným výsledkem.
Co sledovat po nasazení
Dashboard by neměl ukazovat jen počet požadavků. Sledujte přesnost po jednotlivých kategoriích, podíl případů poslaných člověku, falešně pozitivní a falešně negativní výsledky, p95 latenci, cenu na tisíc rozhodnutí a čas, který kontrolou stráví tým. Užitečné je navázat i na měření ROI z AI: zkrátil se celý proces, nebo jsme pouze přidali rychlý model před stejně pomalou ruční frontu?
Rozhodnutí ukládejte s verzí instrukce, použitým modelem a výslednou akcí, ale bez zbytečných osobních údajů. OpenAI uvádí podporu datové rezidence, regionálního zpracování v USA a Evropě a Zero Data Retention pro způsobilé zákazníky. To nejsou automaticky zapnuté vlastnosti pro každý účet; před produkcí ověřte smluvní podmínky, konfiguraci projektu a skutečný datový tok.
Omezení: pravděpodobnost není pravidlo ani důkaz
Hodnota 0,92 neznamená, že výsledek je objektivně správný v 92 % budoucích případů. Je to modelový odhad, který musíte kalibrovat na vlastních datech. Přesnost se může lišit podle jazyka, délky textu, kvality fotografie, změny sortimentu i chování zákazníků.
Decisions API také nevysvětluje automaticky celý obchodní kontext. Pokud rozhodnutí závisí na aktuálním stavu skladu, smlouvě nebo historii zákazníka, musí aplikace dodat správná data a hlídat jejich stáří. Model nemá dostat více oprávnění jen proto, že odpovídá rychle.
Závěr: nejdřív ohraničte volbu, potom automatizujte
Decisions API je praktická novinka pro firmy, které už vědí, jaké malé rozhodnutí chtějí zrychlit. Je vhodné pro třídění, routing a skórování nad jazykem, obrazem či JSON daty. Není to univerzální náhrada pravidel, generování textu ani lidského úsudku.
Nejlepší první pilot má tři až pět jasných výsledků, historický testovací vzorek a bezpečnou větev pro lidskou kontrolu. Pokud se po dvou týdnech sníží přeposílání, čekání a ruční třídění bez růstu závažných chyb, má smysl rozšířit automatizaci. Pokud ne, změňte kritéria nebo vraťte krok běžným pravidlům.
Přímé zdroje
- OpenAI: Build more responsive apps with the Decisions API — oficiální oznámení obecné dostupnosti, publikováno 22. října 2026.
- OpenAI API Docs: Decisions — oficiální dokumentace typů odpovědí, evaluace, cachingu, ceny a dostupnosti, ověřeno 26. října 2026.
- OpenAI API Changelog — záznam vydání Decisions API do obecné dostupnosti z 22. října 2026.
