K2 získává většinu v Blaze: AI vývoj aplikací mění roli dodavatele i zákazníka

Ostravská skupina K2 získala 51% podíl ve společnosti Blaze, která staví zakázkový vývoj na AI agentech. O transakci informovala Lupa 30. října. Zpráva je zajímavá i pro malé firmy: část prvního návrhu aplikace si dnes mohou připravit samy, zatímco od dodavatele potřebují pomoc s dokončením a provozem. Rychle vytvořený prototyp ale není totéž jako spolehlivý firemní systém.

Co se v Ostravě změnilo

K2 je česká IT skupina spojená s podnikovým softwarem. Blaze je rovněž ostravská firma zaměřená na vývoj aplikací s výrazným použitím AI nástrojů. Většinový podíl znamená obchodní propojení dvou odlišných zkušeností: dlouhodobého provozu firemních systémů a rychlé tvorby pomocí agentů. Sám o sobě však neříká nic o kvalitě každé budoucí zakázky.

Lupa cituje vedení Blaze, podle kterého si klienti vytvářejí velkou část aplikace sami a firmě platí za zbývající dokončení. Jde o vyjádření konkrétního dodavatele, ne obecnou statistiku trhu. Nelze z něj odvodit, že každá firma zvládne stejný podíl vývoje nebo že se cena všech projektů sníží o podobné procento.

Také formulaci „bez programování“ je potřeba číst přesně. AI může generovat programový kód, i když jej člověk nepíše ručně. Výsledná aplikace stále nějak funguje, pracuje s daty a potřebuje údržbu. Změna způsobu zadávání tedy neodstraňuje technické vlastnosti ani odpovědnost za provoz.

Proč si zákazník může připravit první návrh sám

Majitel firmy často dobře zná svůj problém, ale dříve jej musel popsat vývojáři abstraktně. S AI může rychle připravit ukázku obrazovky nebo jednoduchého postupu. Takový prototyp pomůže diskusi: místo dlouhého vysvětlování lze ukázat, jak by uživatel procházel konkrétní úlohou. Rozdíl mezi modelem, agentem a vývojovým prostředím vysvětluje průvodce AI pro programování.

To je skutečná změna spolupráce. Dodavatel nemusí začínat prázdným plátnem a zákazník lépe pozná, co vlastně potřebuje. Zároveň může první návrh odhalit, že původní představa neodpovídá provozu. Hodnota prototypu pak spočívá v levnějším učení, ne nutně v tom, že se jeho kód přímo použije.

Prototyp je podklad pro rozhodnutí. Může být vizuálně hotový a přesto neřešit přístupy, chybové stavy nebo návaznost na další systémy. Je důležité tuto hranici pojmenovat, aby zákazník nezaměnil několik funkčních ukázek za připravený produkt pro zaměstnance a klienty.

Co oddělit při objednávce AI aplikace Na mobilu lze tabulku posouvat do stran.

Modelový příklad servisní evidence

Představme si malou dílnu, která potřebuje evidovat zakázky. Pomocí AI si připraví formulář pro příjem zařízení a seznam stavů opravy. Na ukázkových datech vše působí přehledně. Tento scénář je vlastní ilustrace, nikoli popis konkrétní realizace Blaze nebo měřeného času dodání.

Při skutečném používání se objeví další otázky. Kdo smí měnit cenu? Co když dvě osoby otevřou stejnou zakázku? Jak se opraví chybně přiřazený zákazník? Kam se ukládá historie a jak se data vrátí po omylu? Právě tyto situace mohou představovat podstatnou část práce, která na první obrazovce není vidět.

Dodavatel může pomoci převést návrh do udržitelné podoby a rozhodnout, co se má předělat. Není automaticky výhodné zachovat každou část prototypu. Někdy je cennější jeho funkční představa a zkušenost uživatelů než původní technické řešení. To by mělo být součástí otevřené dohody o rozsahu zakázky.

Co potřebuje firma popsat před zadáním

Nejprve určete pracovní problém a výsledek. Například: pracovník má najít stav opravy bez obvolávání kolegů. Teprve potom řešte vzhled formuláře a výběr nástroje. Pokud začnete pouze seznamem obrazovek, může vzniknout aplikace, která vypadá správně, ale nezkrátí žádnou důležitou práci.

Zadání by mělo obsahovat také výjimky. Co se stane při neúplném záznamu, stornu nebo změně odpovědné osoby? Tyto situace často rozhodují o praktické použitelnosti. AI umí vytvořit ideální cestu rychle, ale bez podkladů nemusí vědět, jak vaše firma řeší skutečné komplikace.

Připravte si zejména:

• jeden konkrétní pracovní postup a jeho současný problém;
• role lidí a rozsah jejich přístupu;
• několik běžných i problematických případů;
• seznam navazujících systémů a potřebných dat;
• jasný způsob, jak bude firma výsledek přebírat.

Poslední část práce může být nejnáročnější

Podíl dokončených obrazovek není podíl vyřešeného rizika. Jedna chybějící funkce obnovy dat může být důležitější než deset již hotových formulářů. Proto se nevyplatí posuzovat stav projektu pouze podle toho, kolik prvků je vidět. Zbývající práce má různou náročnost a dopad.

Stejný problém znají i tradiční projekty. AI může zrychlit tvorbu návrhu, ale nezmění potřebu ověřit správnost a návaznost. Osmdesát procent návrhu nemusí znamenat osmdesát procent celkové práce. Konkrétní poměr závisí na aplikaci, kvalitě prototypu a požadavcích provozu, nikoli na obecném marketingovém čísle.

Při jednání s dodavatelem si proto nechte vysvětlit, co přesně zbývá. Integrace, bezpečnost, migrace a školení jsou různé položky. Rozpočet má odpovídat skutečnému rozsahu a podmínkám převzetí. Jedna souhrnná cena bez popisu výsledku může vytvářet spory, i když se první ukázka všem líbila.

Oprávnění nejsou jen přihlášení

Aplikace může vyžadovat účet a přesto umožnit nevhodné změny. Důležité je, co jednotlivý člověk po přihlášení smí vidět a provést. Ve firemním prostředí se často liší role obsluhy, vedoucího a správce. Tyto rozdíly je potřeba ověřit na konkrétních případech, ne pouze pohledem na úvodní obrazovku. Při návrhu rolí pomůže také postup pro omezení přístupu AI agentů k účtům.

Přístupy mají odpovídat potřebě práce. Zaměstnanec řešící servisní stav nemusí potřebovat všechna finanční nebo osobní data. Zároveň nemá být běžná úloha zbytečně blokovaná složitým postupem. Správné nastavení hledá přiměřenou rovnováhu mezi použitelností a omezením dopadu chyby.

Zákazník bez technické specializace může kontrolovat scénář: přihlásí se jako konkrétní role a zkusí povolený i nepovolený krok. Odbornou technickou kontrolu má provést příslušný člověk. Uživatelské ověření a bezpečnostní posouzení se doplňují; jedno samo nepokrývá všechny vlastnosti produktu.

Záloha bez obnovy je neúplná odpověď

Ptejte se nejen na to, zda se data zálohují, ale jak se vrátí do použitelného stavu. Obnova může být potřebná po omylu, chybě aktualizace nebo ztrátě přístupu. Firma má vědět, kdo postup provede a jaký rozsah nedávné práce může být dotčený. Neurčitý slib cloudu nestačí.

Praktický pilot může použít kopii neškodných dat a ověřit export i návrat. Tím se zjistí, zda záloha obsahuje potřebné souvislosti, ne jen jednotlivé tabulky. U složitější aplikace záleží i na souborech, vazbách a konfiguraci. Rozsah testu má odpovídat významu systému pro provoz.

Před přechodem z původní evidence je vhodné porovnat počty a důležité součty. Pokud import vytvoří duplicity nebo ztratí návaznosti, hezké nové rozhraní problém nevyřeší. Na tuto část navazuje náš průvodce přechodem na nový firemní software. Rychlá tvorba aplikace není důvod migraci přeskočit.

Celková cena zahrnuje i provoz po předání

Zakázka může mít náklady na vývoj, hostování, další služby a údržbu. Pokud aplikace volá AI model, přidává se jeho spotřeba. Někde je součástí nabídky, jinde se účtuje zvlášť. Před podpisem potřebujete vědět, které položky rostou s počtem uživatelů a které s objemem práce. Pro opakované propojení služeb porovnejte i automatizace v Make a n8n a jejich náklady.

Modelově může levnější začátek znamenat vyšší měsíční závislost na jedné platformě. To nemusí být špatná volba, pokud je služba vhodná a cena předvídatelná. Je ale potřeba porovnat stejný časový horizont. Samotná cena první verze neříká, kolik bude stát rok skutečného používání.

Cena aplikace má zahrnovat její život po spuštění. Kdo opraví chybu, když se změní externí rozhraní? Kdo hlídá aktualizace? Jak se řeší odchod původního autora? Tyto otázky zůstávají i tehdy, když podstatnou část souborů vytvořil AI agent místo člověka s editorem.

Vlastnictví a přenositelnost potřebují konkrétní podobu

Zákazník by měl vědět, k čemu získává přístup: ke zdrojovým souborům, účtu platformy, databázi nebo jen ke službě. Různé nabídky mohou být legitimní, ale nejsou zaměnitelné. Obecné ujištění, že aplikace je vaše, má být spojeno s konkrétními možnostmi exportu a dalšího provozu.

Při případné změně dodavatele budou důležité také dokumentace a přístupy. Nový tým potřebuje pochopit, jak systém funguje a jak se nasazuje. Dlouhá historie konverzací s původním agentem nemusí být dostatečná. Praktický předávací balíček má obsahovat skutečné soubory, postupy a známé závislosti.

Smluvní podmínky je třeba posuzovat podle konkrétní nabídky; tento článek není právním výkladem transakce ani doporučením jedné smlouvy. Pro zadavatele je podstatné klást přesné otázky předem. Pozdější spor o to, co bylo zahrnuto, může být nákladnější než pečlivé vymezení několika položek při zadání.

Jak poznat použitelný výsledek před spuštěním

Vyberte skutečné pracovní scénáře a nechte je projít lidmi, kteří budou systém používat. Neomezujte se na úspěšné vložení jednoho záznamu. Ověřte chybný vstup, opravu, přístup jiné role a dohledání staršího případu. Tak se ukáže chování aplikace tam, kde práce není ideální.

Převzetí by mělo potvrdit:

• hlavní úlohu i důležité výjimky;
• správná oprávnění a dohledatelnost změn;
• úplnost importovaných dat a možnost exportu;
• známý postup obnovy a řešení závad;
• odpovědnost za provoz, náklady a další údržbu.

Tento seznam není hodnocením konkrétního produktu Blaze. Je to obecný rámec pro zákazníka, který uvažuje o AI vývoji. Pomáhá využít rychlost návrhu bez záměny prototypu a hotového systému. Výběr dodavatele má následovat konkrétní potřebu a ověřené podmínky spolupráce.

Co akvizice naznačuje o trhu

Spojení zavedeného podnikového dodavatele s týmem orientovaným na AI ukazuje zájem propojovat rychlou tvorbu s provozní zkušeností. Zda se to podaří u konkrétních projektů, ukážou výsledky. Samotný nákup podílu není záruka nové obchodní nabídky ani důvod vyhlašovat konec tradičního vývoje.

Pro zákazníka je užitečnější jiný závěr: může se více zapojit do návrhu a přitom potřebovat odbornou pomoc s dokončením. Role dodavatele se může měnit, ale nezmizí potřeba znalosti problému, kontroly a údržby. Právě podle těchto vlastností má smysl posuzovat novou nabídku AI aplikací.

Přejímací příklad je užitečnější než obecné zadání

Firma může chtít aplikaci pro evidenci servisních požadavků. Věta „ať je přehledná a rychlá“ ale neříká, kdy je zakázka hotová. Přesnější modelový příklad popíše přijetí požadavku, přidělení technikovi a uzavření s datem a poznámkou. Potom lze každou část předvést a zkontrolovat. AI usnadňující vznik aplikace tuto potřebu konkrétních pravidel neodstraňuje.

Připravte také případ, kdy něco nevyjde. Dva lidé upraví stejný záznam, zákazník zadá neplatný kontakt nebo pracovník omylem uzavře cizí požadavek. Smyslem není hned požadovat složitý systém pro všechny možnosti. Potřebujete však vědět, zda se informace neztratí a zda lze stav napravit. Hezký seznam na úvodní obrazovce tyto vlastnosti neprokazuje.

Převzetí má ověřit skutečný pracovní průchod. Zákazník může přispět znalostí procesu, zatímco dodavatel vysvětlí vhodné technické řešení a jeho omezení. Právě zde může kombinace samostatného návrhu a odborného dopracování dávat smysl. Podíl práce nelze určit pouze počtem obrazovek, protože jediná vazba na důležitý systém může změnit náročnost celé zakázky.

Co má zůstat, když skončí spolupráce

Předem se dohodněte na předání, které umožní pokračovat v provozu. Zákazník má vědět, kde běží aplikace, kdo spravuje přístupy a jak získá vlastní data. U konkrétní smlouvy je potřeba vysvětlit i práva k výsledku a rozsah případných licencí. Nejde o tvrzení, jaké podmínky automaticky nabízí Blaze; to je předmět konkrétní nabídky.

Užitečné je předvést také obnovu z vhodné zálohy na neprodukčních datech. Samotná existence souboru nazvaného záloha neprokazuje, že se z něj podaří službu obnovit. Malá firma nemusí budovat velké provozní oddělení, ale měla by rozumět tomu, komu volat při závadě a jak dlouhý výpadek její proces unese.

Změna vlastníka dodavatelské firmy může přinést širší obchodní zázemí, sama však není popisem budoucí kvality každého projektu. Při rozhodování oddělte oznámenou transakci, ukázku technologie a závazky ve vlastní objednávce. Pro zákazníka je důležitý výsledek, který lze převzít, provozovat a případně změnit. Tomu má odpovídat také rozpočet a rozdělení odpovědnosti mezi obě strany.

Pro první objednávku může být užitečné oddělit průzkumnou fázi a závazek dodat provozní řešení. Výstupem průzkumu může být seznam požadavků, prototyp a přehled nejasností. Teprve potom lze přesněji určit rozsah další práce. Takové členění samo nezaručuje nižší cenu, ale pomáhá pojmenovat, za co zákazník skutečně platí. U dodatečných změn si zapisujte jejich důvod a dopad na původní dohodu. Nová obrazovka může být malá úprava, zatímco jiný způsob přihlašování může zasáhnout celý systém. Srozumitelné rozdělení těchto situací je důležité bez ohledu na to, jak velkou část návrhu vytvořila AI.

Časté otázky

Kolik v Blaze získala K2?

Podle zprávy Lupy z 30. října získala 51% podíl. Článek popisuje oznámenou transakci a její praktické souvislosti pro zákazníky. Nejde o náš audit firmy ani o hodnocení kvality jejích jednotlivých zakázek nebo finanční doporučení.

Znamená AI vývoj, že aplikace neobsahuje kód?

Ne. AI může kód vytvářet místo ručního psaní. Výsledný software stále potřebuje správné chování, zabezpečení a údržbu. Formulace bez programování obvykle popisuje způsob práce člověka, nikoli absenci technického řešení a odpovědnosti za jeho provoz.

Mohu si tedy celý firemní systém vytvořit sám?

Záleží na rozsahu a vašich schopnostech. Prototyp může vzniknout snadno, ale provozní systém má další požadavky. U důležitých dat a návazností potřebujete odpovídající odbornou kontrolu. První ukázka na testovacích údajích neprokazuje připravenost pro skutečný provoz.

Je osmdesát procent prototypu osmdesát procent práce?

Takový závěr neplatí obecně. Viditelné obrazovky nezachycují všechny nároky integrace, oprávnění a obnovy dat. Zbývající část může být velmi náročná. Podíl uváděný jedním dodavatelem nelze automaticky převést na cenu nebo čas jiné zakázky.

Co se ptát na cenu?

Na celkový rozsah dodání, hostování, spotřebu dalších služeb, údržbu a změny. Důležitý je srovnatelný časový horizont a známé limity. Levnější první verze nemusí znamenat levnější roční provoz, stejně jako vyšší vstupní cena sama nezaručuje kvalitu.

Co ověřit před spuštěním?

Skutečné pracovní scénáře, výjimky, role, import, export a obnovu. Určete odpovědnou osobu pro chyby a náklady po předání. Pokud tyto otázky zůstávají nejasné, je vhodné je doplnit před přechodem z původní evidence, i když prototyp působí hotově.