AI riešenie sa od klasického custom developmentu líši už v samotnom princípe fungovania. Kým pri tradičnej aplikácii firma definuje problém, pripraví zadanie a vývojový tím implementuje presne danú business logiku, pri AI už správanie systému neurčuje iba kód.
Výsledok ovplyvňuje aj použitý model, prompt, dostupný kontext, kvalita dát a spôsob, akým používateľ požiadavku zadá. To mení nielen technickú architektúru, ale aj spôsob, akým sa AI projekty plánujú, testujú a prevádzkujú.
Rozdiel je aj v predvídateľnosti. Klasická aplikácia funguje na princípe: ak nastane podmienka A, systém vykoná akciu B. Pri AI skôr definujeme cieľ, kontext a hranice, v ktorých sa má model pohybovať.
Pri AI nestačí definovať funkcionalitu
Pri bežnom custom developmente sa funkcionalita dá pomerne presne opísať cez user stories a acceptance criteria. Používateľ vyplní formulár, systém overí údaje, vykoná konkrétnu operáciu a zobrazí výsledok.
Pri AI zadanie typu „systém má odpovedať zákazníkom“ nestačí. Treba zároveň definovať, čo znamená kvalitná odpoveď a ako sa má systém správať v situáciách, ktoré nie sú úplne jednoznačné.
Už pri návrhu preto treba vyriešiť napríklad:
- z akých zdrojov môže AI čerpať,
- čo musí odpoveď obsahovať,
- čo naopak obsahovať nesmie,
- čo má systém urobiť pri neistote,
- kedy má požiadavku odovzdať človeku,
- aká miera chybovosti je ešte prijateľná.
Nestačí teda vedieť, čo má AI agent robiť. Potrebujeme tiež vedieť, ako budeme posudzovať, či to robí dobre.
AI nemá nahradiť klasickú business logiku
Pri AI riešeniach je lákavé presunúť čo najviac rozhodovania priamo do promptu. Pri prototype to môže fungovať veľmi dobre, pretože systém pôsobí flexibilne a „rozumne“. V produkcii však nie je dobré nechať dôležité pravidlá iba na modeli.
Predstavme si napríklad žiadosť o refundáciu na eshope. AI môže pochopiť, čo zákazník žiada, zhrnúť dôvod reklamácie a navrhnúť ďalší krok. Nemala by však sama rozhodovať o finančných limitoch, oprávneniach alebo o tom, či sa refundácia naozaj vykoná. Tieto pravidlá by mali zostať v klasickom backende, kde sú presne definované a dajú sa kontrolovať.
Ako má fungovať Al v biznis procese
Al pomáha s interpretáciou a návrhom ďalšieho kroku. Pravidlá a kritické akcie zostávajú pod kontrolou systému.
AI je teda dobré využiť tam, kde je silná – pri práci s textom, pochopení kontextu alebo spracovaní neštruktúrovaných informácií. Klasický software zostáva zodpovedný za pravidlá, kontroly a kritické operácie.
AI tak nenahrádza existujúcu business logiku. Skôr nad ňu pridáva inteligentnú vrstvu, ktorá dokáže lepšie pracovať s nejednoznačnými vstupmi a pripraviť ďalší krok.
Dáta priamo ovplyvňujú správanie systému
Pri tradičnej aplikácii sú dáta najmä vstupom, nad ktorým beží naprogramovaná logika. Pri AI sú zároveň súčasťou toho, ako sa systém bude správať.
Ak AI odpovedá na základe firemných dokumentov, výsledok závisí od toho, či nájde správny dokument, či je aktuálny, či si neprotirečí s iným zdrojom a či k nemu má používateľ vôbec mať prístup. Preto pri vývoji AI riešenia je prakticky nemožné vynechať témy ako:
- source of truth,
- data quality,
- access rights,
- metadata,
- retrieval,
- ownership dát.
Kvalita firemných dát je obzvlášť dôležitá pri RAG riešeniach. Aj veľmi kvalitný jazykový model bude podávať slabé výsledky, ak retrieval vracia nesprávne, neúplné alebo zastarané zdroje.
Pri AI neplatí, že problém vyriešime jednoducho výberom lepšieho modelu. Najskôr je potrebné vyriešiť dáta.
Testovanie už nie je len pass alebo fail
Klasický software sa veľmi dobre testuje cez presné očakávania. Pre konkrétny vstup očakávame konkrétny výstup. Pri AI môže byť viacero odpovedí správnych, aj keď sú formulované odlišne. Testovanie sa preto posúva od kontroly jednej hodnoty ku kontrole kvality celého správania.
V praxi sa môže sledovať napríklad:
- faktická správnosť,
- relevantnosť odpovede,
- použitie správneho zdroja,
- výskyt halucinácií,
- správnosť tool calls,
- úspešné dokončenie workflowu,
- správna eskalácia na človeka.
Na tento účel sa vytvárajú evaluation datasety s reálnymi alebo reprezentatívnymi scenármi. AI riešenie teda netestujeme len preto, aby sme zistili, či technicky funguje. Opäť potrebujeme vedieť aj to, ako dobre funguje.
Nasadením do produkcie vývoj nekončí
Pri klasickej aplikácii môže po nasadení nasledovať relatívne stabilné obdobie. Ak sa nemení kód ani business logika, správanie systému zostáva zväčša rovnaké.
Pri AI je prevádzka omnoho dynamickejšia. Môže sa zmeniť model, prompt, interná dokumentácia, retrieval vrstva alebo spôsob, akým používatelia systém používajú. Aj malá zmena môže ovplyvniť kvalitu výsledku. Preto pri AI nestačí sledovať iba dostupnosť služby, response time alebo počet chýb API. Dôležité sú aj metriky ako:
- accuracy,
- hallucination rate,
- tool success rate,
- escalation rate,
- latency,
- cost per request.
Inými slovami, popri technickej funkčnosti riešenia potrebujeme sledovať, či funguje správne, za akú cenu a či sa správa konzistentne aj pri scenároch, ktoré sa neobjavili počas pilotu.
Náklady sa správajú inak
Pri custom developmente sa náklady typicky odvíjajú od rozsahu vývoja, infraštruktúry a prevádzky. Pri AI pribúda ďalšia vrstva, ktorá je oveľa tesnejšie previazaná s reálnym používaním systému. Cena môže závisieť od:
- počtu requestov,
- množstva tokenov,
- veľkosti kontextu,
- použitého modelu,
- počtu tool calls,
- komplexnosti retrievalu.
Dobre pripravená AI architektúra sleduje a optimalizuje nielen kvalitu výsledku, ale aj ekonomiku jeho prevádzky. Nie každá úloha potrebuje najväčší (a najdrahší) model. Pri jednoduchších prípadoch môže byť efektívnejší menší model alebo klasický kód, zatiaľ čo zložitejšie scenáre môžu vyžadovať výkonnejší model.
Mení sa bezpečnostný model
Pri klasickej aplikácii používateľ vykonáva operácie, ktoré developer explicitne naprogramoval. AI systém však môže pracovať s neštruktúrovaným obsahom, interpretovať požiadavku a dynamicky rozhodovať, aký tool alebo API použije. To prináša nové riziká, akými sú prompt injection, únik citlivých dát alebo situácie, keď AI dostane príliš široké oprávnenia.
Bezpečnosť preto nemôže byť postavená iba na prompte. Kritické kontroly musia zostať v aplikačnej a infraštruktúrnej vrstve.
Bezpečnosť AI riešenia sa najčastejšie rieši kombináciou viacerých opatrení:
- Least privilege
AI má prístup iba k tým dátam a operáciám, ktoré skutočne potrebuje. Ak má iba čítať stav objednávky, nemá mať zároveň právo objednávku meniť alebo rušiť. - Oddelenie read a write operácií
Čítanie dát má nižšie riziko než zmena údajov, odoslanie platby alebo vytvorenie objednávky. Citlivé write operácie preto prechádzajú ďalšou kontrolou. - Autentifikácia a autorizácia
AI nesmie obísť pravidlá aplikácie. Používateľ cez AI môže vidieť iba tie dáta a vykonať iba tie akcie, na ktoré má oprávnenie aj v pôvodnom systéme. - Human-in-the-loop
Pri rizikových operáciách môže AI pripraviť návrh, ale finálne potvrdenie zostáva na človeku. Typicky ide o finančné operácie, zmeny zákazníckych údajov alebo právne citlivé rozhodnutia. - Validácia vstupov a výstupov
Systém kontroluje, čo vstupuje do modelu a čo z neho odchádza. To môže zahŕňať kontrolu formátu, filtrovanie citlivých údajov alebo blokovanie nebezpečných inštrukcií. - Tool allowlist a obmedzené API
Agent nedostáva voľný prístup ku všetkým systémom. Má k dispozícii len presne definované nástroje a operácie, ktoré môže použiť. - Audit logy a tracing
Pri dôležitých operáciách je potrebné vedieť spätne zistiť, aké dáta model použil, aké rozhodnutie navrhol, ktorý tool zavolal a čo systém následne vykonal. - Secrets management
API kľúče, heslá a tokeny by nikdy nemali byť súčasťou promptov alebo dostupné modelu v čitateľnej forme. Spravujú sa oddelene, cez bezpečné secret stores a aplikačnú vrstvu. - Izolácia a sandboxing
Ak AI spúšťa kód, pracuje so súbormi alebo externým obsahom, tieto operácie sa často vykonávajú v izolovanom prostredí s obmedzenými oprávneniami. - Ochrana proti prompt injection
Externý dokument, e-mail alebo webová stránka môžu obsahovať inštrukcie, ktoré sa pokúsia ovplyvniť správanie modelu. Preto sa nedá automaticky dôverovať všetkému obsahu, ktorý AI spracuje.
Dôležitý princíp je, že model nesmie byť bezpečnostnou autoritou systému.
Kým Proof of concept je jednoduchý, produkčné riešenie náročnejšie
Pri AI sa dá funkčný prototyp vytvoriť veľmi rýchlo. Model môže po krátkom nastavení odpovedať na otázky, pracovať s dokumentmi alebo navrhovať ďalšie kroky a na prvý pohľad môže pôsobiť, že riešenie je takmer hotové.
Rozdiel sa ukáže až pri reálnom používaní. Produkčné riešenie musí fungovať konzistentne pri rôznych typoch vstupov, pracovať so správnymi dátami, rešpektovať oprávnenia používateľov a zvládať aj situácie, s ktorými sa pri prototype nepočítalo.
Pri prechode do produkcie sa preto typicky rieši najmä:
- spoľahlivosť výstupov – ako často systém odpovedá správne a čo urobí pri neistote,
- práca s reálnymi dátami – ich aktuálnosť, kvalita a prístupové práva,
- integrácie – napojenie na interné systémy a bezpečné vykonávanie akcií,
- kontrola chýb a fallback scenáre – napríklad eskalácia človeku alebo zastavenie workflowu,
- monitoring a evals – priebežné meranie kvality po nasadení,
- náklady a výkon – latency, počet volaní modelu a cena jednotlivých operácií.
AI development má iný rytmus
Pri klasickom custom developmente je proces väčšinou lineárnejší. Začína sa analýzou, pokračuje návrhom, developmentom a testovaním a končí nasadením do produkcie. Samozrejme, aj tu sa tím môže vracať k predchádzajúcim krokom, ale cieľom je postupne sa dostať k stabilnému výsledku podľa vopred definovaných požiadaviek.
Pri AI developmente je proces prirodzene iteratívnejší. Začína sa konkrétnym use casom a dátami, nasleduje prototyp, ktorý sa priebežne vyhodnocuje pomocou evalov. Na základe výsledkov sa riešenie upravuje, testuje v pilote a po nasadení sa ďalej monitoruje a optimalizuje. Vývoj, testovanie a zlepšovanie sa tu prelínajú oveľa viac, pretože kvalitu AI riešenia ovplyvňuje nielen kód, ale aj model, prompt, dáta, retrieval a správanie používateľov.
Klasický custom development vs. Al development
Pri Al projektoch sa vývoj, testovanie a zlepšovanie prelínajú oveľa viac než pri klasickom custom developmente.
Na AI riešenie sa odlišne pozeráme aj z pohľadu nákladov. Neznamená to automaticky, že bude drahšie, ale časť nákladov sa presúva z jednorazového developmentu do priebežnej prevádzky a optimalizácie.
Pri AI preto sledujeme nielen cenu implementácie, ale aj nové premenné, ako cost per request, cost per task alebo cost per resolved case. Vďaka tomu vieme lepšie vyhodnotiť, či riešenie skutočne šetrí čas, znižuje množstvo manuálnej práce a prináša hodnotu v porovnaní s pôvodným procesom.
Uvažujete nad vlastným AI riešením?
Radi sa s Vami pozrieme na to, kde AI dáva reálny zmysel, ako ju prepojiť s existujúcimi systémami a ako navrhnúť riešenie, ktoré bude pripravené aj na produkčnú prevádzku.
Máte AI use case, ktorý chcete posunúť z nápadu do praxe?
Ozvite sa nám.
