Data policy: kdo skutečně kontroluje data
Úplně první vrstva hodnocení AI vendora je datová politika. V praxi platí, že každá interakce s AI systémem je zároveň potenciálním vstupem pro další zpracování, logování nebo dokonce trénování modelu.
Klíčová otázka tedy není jen to, zda vendor „chrání data“, ale zda jasně definuje, co se s daty děje po jejich zpracování. V enterprise prostředí musí být jednoznačné, zda jsou data používána pro trénování modelu, jak dlouho jsou uchovávána a zda existuje reálná možnost jejich úplného smazání. Stejně důležité je porozumět geografii dat, protože ta často určuje právní režim jejich ochrany.
Pokud tato pravidla nejsou explicitní a auditovatelná, organizace fakticky ztrácí kontrolu nad svými datovými aktivy.
Auditability: černá skříňka nebo vysvětlitelný systém
Druhou kritickou oblastí je auditovatelnost. V tradičních softwarových systémech je možné zpětně rekonstruovat, jaká logika vedla k určitému výsledku. V AI systémech to již neplatí automaticky, protože výstup je výsledkem pravděpodobnostního modelu, nikoli pevně dané logiky.
Pro enterprise nasazení je proto zásadní, aby vendor dokázal poskytnout alespoň základní úroveň dohledatelnosti. To znamená možnost vidět vstupy, verzi modelu, použitý kontext a ideálně také mezikroky zpracování.
Bez této schopnosti se AI systém stává černou skříňkou, což výrazně komplikuje interní audit, compliance i řešení incidentů.
Modelová a vendor flexibilita: skrytý lock-in
Jedním z nejpodceňovanějších rizik AI řešení je vendor lock-in, který je výrazně silnější než u tradičního SaaS. Důvodem je, že hodnota AI systému není jen v samotné aplikaci, ale v kombinaci modelu, promptů, datové vrstvy a logiky workflow.
V praxi to znamená, že i když je systém technicky nahraditelný, migrace je extrémně obtížná. Prompt engineering není standardizovaný, workflowy jsou často navázané na konkrétní implementaci a embeddingy nebo paměťové vrstvy bývají nekompatibilní.
Proto je důležité včas ověřit, zda systém umí pracovat s více modely a zda umožňuje export konfigurace a logiky. Pokud ne, jde spíše o uzavřený ekosystém než o flexibilní enterprise řešení.
Onboarding a offboarding: test, který většina firem nedělá
U AI systémů se firmy často zaměřují na onboarding, tedy na to, jak rychle lze systém nasadit. Mnohem důležitější je ale otázka, co se stane, když ho organizace chce přestat používat.
Offboarding zahrnuje nejen export dat, ale také schopnost znovu vytvořit workflow jinde, vypnout systém bez ztráty informací a zajistit, aby žádná data nezůstala uzamčená u vendor systému.
Silným varovným signálem je situace, kdy vendor nedokáže jasně popsat nebo demonstrovat, jak vypadá odchod z platformy. V praxi to často znamená, že exit je buď velmi drahý, nebo technicky složitý.
Incident response: AI-specifické selhání
AI systémy mají typy incidentů, které v tradičním softwaru neexistují. Patří sem situace, kdy model začne generovat nesprávné nebo nebezpečné výstupy, kdy dochází k úniku citlivých dat přes vstupní prompty, nebo kdy je systém manipulován specifickými útoky na jazykové modely.
Proto nestačí obecný incident response plán. Vendor musí mít definované procesy specificky pro chování AI, včetně monitorování vstupů a výstupů, schopnosti rychlé deaktivace částí systému a mechanismů pro opětovné testování modelu po incidentu.
Pokud tyto procesy neexistují, organizace se spoléhá na reakci, která není přizpůsobena povaze rizika.
SLA: problém není dostupnost, ale kvalita
Tradiční SLA modely založené na uptime nejsou pro AI dostatečné. Samotná dostupnost API nic neříká o tom, zda systém poskytuje konzistentní nebo správné výstupy.
V AI kontextu musí být SLA rozšířena o metriky jako latence, stabilita odpovědí, chybovost a existence fallback mechanismů v případě degradace modelu.
Bez těchto parametrů se SLA stává formálním dokumentem, který neodráží reálnou kvalitu služby.
Integrace: kde se AI mění na hodnotu
Velký rozdíl mezi demo AI a produkčním systémem je úroveň integrace. Mnoho řešení funguje dobře jako samostatné chatboty, ale jejich hodnota se projeví až ve chvíli, kdy jsou integrována do existujících procesů organizace.
Skutečná enterprise hodnota vzniká pouze tehdy, když AI není izolovaný nástroj, ale součást CRM, ERP, support nebo operativních systémů.
Proto je důležité hodnotit nejen kvalitu modelu, ale také schopnost integrace do reálných workflow a existující infrastruktury.
Pricing: kde se skrývá komplexita
Cenotvorba AI služeb je často mnohem méně transparentní, než se na první pohled zdá. Kromě základní ceny za používání modelu mohou vznikat náklady na tokeny, storage, logging, fine-tuning nebo škálování.
Problém je, že tyto náklady se často projeví až při produkční zátěži, nikoli během pilotní fáze.
Proto je klíčové simulovat reálné použití ve velkém měřítku a pochopit, jak se cena mění s rostoucím provozem nebo dlouhodobým využíváním.
Závěr: AI vendor je rozhodovací systém, ne software
Zásadní posun v myšlení při AI procurementu spočívá v pochopení, že nekupujete nástroj, ale systém, který zpracovává data, generuje rozhodnutí a v čase se může měnit.
Proto nestačí hodnotit funkce nebo cenu. Je důležité porozumět kontrole nad daty, auditovatelnosti, flexibilitě systému a schopnosti organizace odejít bez ztráty hodnoty.
AI vendor, který tyto aspekty nedokáže transparentně vysvětlit, představuje v praxi vyšší riziko než přidanou hodnotu.
