Aplikace vytvořená pomocí AI funguje. Je připravená na zákazníky?
Prototyp už zvládne ukázku a první uživatelé se ptají, kdy dostanou přístup. Před spuštěním ověřte, zda aplikace ochrání jejich data, správně dokončí objednávku a půjde dál spravovat. Pomůže vám to rozhodnout, co ponechat a co ještě upravit.
01Nejdřív si ujasněte, co znamená „funguje“
Při ukázce založíte účet, vyplníte zakázku a zobrazí se přehled. Pro ověření nápadu je to užitečný výsledek. Před ostrým provozem ale potřebujete vědět také to, komu se data zobrazí, co se stane při chybě a kdo aplikaci opraví za půl roku.
V tomto článku řešíme aplikaci, jejíž kód vznikl s pomocí AI. Nemusí sama obsahovat chatbota ani jinou AI funkci. Samotný způsob vzniku kódu nerozhodne, zda ji lze používat. Rozhodují její vlastnosti a ověřitelné výsledky. Také GitHub u Copilot Chat upozorňuje, že vygenerovaný kód může být nesprávný nebo zranitelný a vyžaduje kontrolu a testování.
02Sepište jednu cestu zákazníka od začátku do konce
Vyberte hlavní úlohu, kvůli které aplikaci spouštíte. U modelového rezervačního systému to může být výběr termínu, vytvoření rezervace, zaplacení a potvrzení. Ke každému kroku napište, kde vzniknou data a kdo s nimi bude dál pracovat.
Pak změňte podmínky: zákazník zavře okno, odešle požadavek dvakrát nebo se pokusí rezervovat termín, který mezitím obsadil někdo jiný. Cílem není nasbírat co nejvíc zatržených políček. Potřebujete poznat, zda se rozpracovaná úloha dokončí správně, nebo skončí srozumitelnou chybou, kterou někdo vyřeší.
03Přihlášení a oprávnění kontrolujte odděleně
Založte testovací účty dvou různých zákazníků. S oprávněním k testu ověřte, zda jeden nemůže otevřít záznam či přílohu druhého. Totéž vyzkoušejte pro běžného pracovníka a správce. Výsledek zaznamenejte jako konkrétní scénář, který půjde zopakovat po další úpravě.
OWASP doporučuje ověřovat oprávnění u každého požadavku. Skrytí tlačítka v prohlížeči nenahrazuje kontrolu oprávnění na serveru. U klientského portálu proto nestačí ukázat, že přihlašovací obrazovka funguje; musí být ověřené i oddělení dat jednotlivých zákazníků.
04Zkontrolujte tajné klíče a služby, na kterých aplikace závisí
Nechte si sepsat databázi, úložiště souborů, e-mailovou službu, platby a další napojení. U každé položky potřebujete znát firemního správce, účel přístupu a místo, kde se mění konfigurace. Oddělte testovací a ostré prostředí.
Citlivé přihlašovací údaje nepatří do veřejného kódu ani do souborů posílaných uživatelovu prohlížeči. Doporučení OWASP pro správu tajných údajů zahrnuje řízení jejich přístupu a životního cyklu. Pokud klíč unikl, pouhé smazání z aktuálního souboru nestačí: je potřeba řešit jeho zneplatnění a bezpečnou náhradu.
Při kontrole se ptejte také na export vlastních dat a možnost pokračovat s jiným správcem. Vývojová platforma může mít vlastní omezení. Nechte si předvést právě ten způsob exportu a nasazení, který budete potřebovat, místo obecného ujištění „všechno jde stáhnout“.
05U plateb testujte obchodní výsledek
Otevřená děkovací stránka ještě není důkazem, že se objednávka správně zpracovala. Stripe ve své dokumentaci k vyřízení objednávek upozorňuje, že zákazník se na návratovou stránku nemusí dostat; zpracování nemá záviset jen na její návštěvě.
V testovacím prostředí proto projděte úspěšnou i zamítnutou platbu, přerušený návrat do aplikace a opakované oznámení výsledku. Zkontrolujte počet vytvořených objednávek, stav platby a to, co dostane zákazník i obsluha. Pokud rezervace nebo objednávka zůstane nejasná, musí existovat dohledatelný záznam a postup nápravy.
06Vyzkoušejte změnu, nasazení a obnovu
Požádejte člověka, který aplikaci převezme, o jednu malou úpravu. Měl by dokázat dohledat příslušnou část, změnu ověřit a nasadit bez ručního zásahu původního autora. Nejde o soutěž v rychlosti, ale o zkoušku, zda je projekt srozumitelný a opakovatelně sestavitelný.
Součástí přípravy je seznam použitých součástí a odpovědnost za jejich aktualizace. Zálohu vyzkoušejte obnovou mimo ostrý provoz. Předem určete, jak poznáte závadu, komu přijde upozornění a kdo smí zastavit problematickou funkci. Ověřte i návrat k předchozí verzi; změny databáze mohou vyžadovat vlastní postup.
07Ponechat, opravit, nebo přestavět?
| Co kontrola ukáže | Rozumný další krok |
|---|---|
| Klíčové scénáře procházejí, přístupy jsou pod kontrolou a aplikace jde spravovat. | Připravit omezené spuštění s určenou obsluhou a sledováním chyb. |
| Základ je použitelný, ale chybí testy, dohled nebo některé kontroly oprávnění. | Vymezit opravy a znovu ověřit dotčené scénáře před zpřístupněním. |
| Data různých zákazníků se míchají nebo zásadní omezení platformy brání požadovanému provozu. | Nejdřív navrhnout změnu základu; porovnat rozsah opravy s přestavbou. |
Rozhodnutí opřete o zjištěné problémy a další práci. Počet řádků kódu ani doba strávená generováním vám samy neřeknou, která cesta vyjde lépe. Do plánu zahrňte také přesun dat, ověřování, školení obsluhy a provoz.
08Časté otázky před spuštěním
Musí se aplikace napsaná s AI zahodit?
Ne. Užitečný prototyp může být základem dalšího vývoje. Nejdřív ověřte jeho konkrétní stav; přepis bez rozboru může zopakovat původní chyby.
Stačí, když kód zkontroluje další AI?
Berte ji jako pomoc při hledání problémů. Pro rozhodnutí o spuštění potřebujete ověřené chování, kontrolu nastavení a člověka odpovědného za výsledek.
Co si mám od kontroly odnést?
Seznam problémů s dopadem, návrh oprav, výsledky klíčových testů a podmínky spuštění. U každého nedostatku má být jasné, zda brání provozu, kdo ho řeší a jak se oprava ověří.
Máte funkční prototyp a chcete jej pustit k zákazníkům? Pošlete nám popis jeho účelu a použitých služeb. Bezpečnostní audit může ověřit bezpečnostní část; při převzetí projektu posoudíme i další vývoj a provoz.