Gemini 3.6 Flash dokáže navrhnout pokladní obrazovku za pár sekund. Co všechno musí fungovat, než přijme skutečnou platbu?

Rychlost nikdy nebyla tím chybějícím dílkem. Než jakákoli AI vygenerovaná pokladna přijme ostrou platbu, musí správně fungovat pět věcí: skladové zásoby, které vydrží, když dvě pokladny prodávají současně, přehledy, které lze odsouhlasit (odpovídají penězům, které skutečně proběhly), daň odpovídající dané jurisdikci, zpracování plateb v souladu s PCI a certifikovaný hardware pro platby kartou na místě. Gemini 3.6 Flash dělá první návrh pokladní obrazovky rychlejším a levnějším než kdykoli předtím. Na zbylých pěti věcech ale nic nemění. Prototyp POS v Gemini 3.6 Flash je skvělý náskok; nasaditelné prodejní místo je ale úplně jiná cílová rovinka.

Názvy modelů, ceny a benchmarky se rychle mění. Níže uvedené podrobnosti jsou přesné k datu publikace; přistupujte k nim jako k aktuálnímu snímku.

Co Gemini 3.6 Flash vlastně mění?

Zlevnil a zpřesnil už tak rychlé a levné generování kódu. Google vydal Gemini 3.6 Flash 21. července 2026 společně s Gemini 3.5 Flash-Lite¹. Stojí 1,50 USD za milion vstupních tokenů a 7,50 USD za milion výstupních tokenů, spotřebovává přibližně o 17 procent méně výstupních tokenů než jeho předchůdce a vykazuje výrazný posun v přesnosti kódování – v benchmarku DeepSWE dosáhl 49 procent oproti 37 procentům u 3.5 Flash².

Pro obchodníka, který experimentuje s AI nástroji, to znamená něco velmi konkrétního: návrh pokladní obrazovky teď trvá několik sekund a stojí pár haléřů. Jejich úpravy a ladění stojí taky jen drobné. Úzké hrdlo při získávání vlastního prodejního systému se posunulo. Už nejde o to, zda model dokáže vygenerovat obrazovky. Jde o všechno, na čem tyto obrazovky stojí.

Proč pokladní obrazovka není kompletní POS?

Protože pokladní obrazovka je výstup, zatímco prodejní systém (POS) je autoritativním systémem záznamů (jediné místo, kde se vaše prodejní čísla považují za pravdivá). Obrazovka je viditelných deset procent. Pod ní leží stav, který musí zůstat správný napříč všemi pokladnami, každou vratkou i každým výpadkem sítě, a navíc tok peněz, který podléhá regulaci bez ohledu na to, zda byl kód napsán ručně, nebo vygenerován. Na stejný rozdíl jsme upozorňovali už při vydání GPT-5.6 a platí pro každý rychlý model i dnes.

Nabízí se námitka: tyto modely už dnes píší kód produkční kvality, tak proč nenechat Gemini 3.6 Flash napsat i logiku zásob a daní? Dokáže to. Problémem není napsání kódu. Problémem je dokázat, že je tento kód správný v podmínkách, které v demu nikdy neuvidíte, a všimnout si, když tomu tak nenápadně není. Špatně vykreslenou pokladní obrazovku odhalíte během několika sekund. Účetní knihu, která se rozchází, odhalí až účetní na konci měsíce – a do té doby vypadá každý přehled v pořádku.

Co musí fungovat před první reálnou platbou?

Pět věcí, z nichž ani jedna se neobjeví v okně náhledu.

Správa zásob, která zvládne souběžný prodej

Souběžný přístup (kdy dvě pokladny přistupují ke stejné skladové zásobě ve stejný okamžik) je místo, kde vygenerovaný kód pro správu zásob selhává nejdříve. Dvě stanice prodají poslední kus položky ve stejné sekundě. Naivní kód zkontroluje počet, vidí jeden dostupný kus a povolí oba prodeje. Právě jste prodali něco, co nemáte, a tato chyba se tichým způsobem násobí s každou rušnou hodinou. Správný systém tyto zápisy serializuje, takže jeden prodej uspěje a druhý uvidí prázdnou polici. To je chování infrastruktury, ne obrazovky, a žádný náhled vám to nikdy neukáže.

Přehledy, které lze odsouhlasit

Odsouhlasení (kdy vaše přehledy odpovídají penězům, které se skutečně přelily) se láme na hraničních případech: vrácení peněz provedené po uzavření směnky, storno po spočítání pokladní zásuvky, částečné vrácení peněz na zlevněnou položku, opakovaný pokus o platbu po výpadku sítě. Každý hraniční případ, který vygenerovaný přehled opomene, představuje malou mezeru mezi tím, co říká přehled, a tím, co banka připsala na účet. Obchodníci tyto mezery neobjeví při testování. Objeví je při daňovém přiznání.

Daň odpovídající dané jurisdikci

DPH a prodejní daně se vrství: celostátní sazba nad regionální, výjimky na úrovni jednotlivých produktů, sazby měnící se k datu určenému legislativou a nikoli vaším plánem vydávání softwaru. Udělat v tom chybu není jen chyba v kódování, ale právní a finanční riziko. Skutečný systém nakonfiguruje daně jednou a uplatňuje je všude konzistentně, stejně jako daňové skupiny v Merchant Hubu.

Zpracování plateb v souladu s PCI

Bezpečnostní standard kartového průmyslu PCI DSS existuje proto, aby s údaji o kartách manipulovaly pouze prověřené a auditované systémy. Vygenerovaný kód by nikdy neměl vidět číslo karty. V praxi to znamená, že platby probíhají přes certifikovaný vývojový zásobník zpracovatele plateb a údaje o kartě jsou tokenizovány (nahrazeny zástupným tokenem) ještě předtím, než se jich váš software dotkne. Toto je zcela nesmlouvatelný bod seznamu a leží zcela mimo rozsah toho, co jakýkoli AI model vygeneruje.

Certifikovaný hardware pro platby kartou na místě

Bezkontaktní platby a platby čipem fungují pouze na terminálech certifikovaných kartovými asociacemi a certifikace se získává pro každé zařízení zvlášť prostřednictvím laboratorního testování. Nelze ji vygenerovat, vytvořit promptem ani dodatečně doprogramovat. Pokud vaši zákazníci platí osobním kontaktem, musí mezi jejich kartou a vaším kódem stát certifikovaný terminál.

Kde rychlý model skutečně pomáhá?

Přesně tam, kam tato verze zaměřila svoje síly: v popisování, navrhování a iteracích. Levný a rychlý model je tím správným nástrojem pro utváření obrazovek a logiky průchodu, vyzkoušení pěti rozvržení před obědem a ladění pokladny, dokud neodpovídá reálnému provozu vašeho pultu. Funkční rozdělení spočívá v tom, že necháte model dělat tuto práci nad obchodní infrastrukturou, která už řídí zásoby, odsouhlasení, daně a platby.

Přesně tak přistupuje k modelům nástroj Build od společnosti Final: můžete připojit Gemini nebo jakéhokoli MCP klienta a nechat ho vytvořit váš pokladní proces s živým náhledem, zatímco Final Pay na pozadí zúčtovává platby prostřednictvím zpracovatele plateb a certifikovaného hardwaru terminálu. Postup krok za krokem najdete v článku jak stavět s Gemini 3.6 Flash nebo v porovnání jak si vedou tři hlavní modely při stavbě POS.

Co tedy musí fungovat, než Gemini 3.6 Flash přijme reálnou platbu?

Zásoby při souběžném prodeji, odsouhlasené přehledy, daň odpovídající jurisdikci, zpracování plateb v souladu s PCI a certifikovaný hardware. Gemini 3.6 Flash z pokladní obrazovky právě udělal nejlevnější část projektu a ničeho z tohoto seznamu se ani nedotkl. Zlaté pravidlo: pokud by se chyba projevila na vašem bankovním účtu místo na obrazovce, nenechávejte ji výhradně na vygenerovaném kódu. Navrhujte s nejrychlejším dostupným modelem a pak nasazujte na infrastruktuře vytvořené tak, aby prošla auditem. Pokud si chcete toto rozdělení vyzkoušet hned, začněte s nástrojem Build.