Nejdřív definujte, co má být soukromé
Požadavek na „privátní AI“ může znamenat několik různých věcí. Někdo potřebuje, aby dokumenty neopustily vlastní síť. Jiný chce zákaz trénování na vstupních datech, kontrolu nad logy nebo možnost vypnout službu bez závislosti na poskytovateli. Tyto cíle se nedají zaměnit jedním štítkem. Sestavte mapu dat: odkud přichází otázka, jaké dokumenty se dohledávají, kam se ukládá historie a kdo vidí diagnostiku. Teprve potom lze srovnat konkrétní varianty.
Vlastní server automaticky neznamená bezpečný systém. Pokud aplikace předává modelu dokumenty bez kontroly přístupu, vznikne únik uvnitř organizace. Externí API může mít užitečné smluvní a technické kontroly, které je nutné ověřit u konkrétní služby; žádné obecné tvrzení o soukromí všech API neplatí. U každé varianty si vyžádejte odpověď na otázku, kdo zpracovává data, jak dlouho se uchovávají, jak se mažou a kdo může změnit nastavení. Rozhodnutí musí být doložené, ne založené na názvu produktu.
Zvolte práci, kterou má model vykonat
Srovnání modelů bez úlohy je podobné výběru databáze podle barvy konzole. Vytvořte reprezentativní sadu případů: otázky nad interními dokumenty, klasifikaci požadavků, návrh odpovědi nebo strukturování formuláře. Každý případ potřebuje očekávaný výsledek, toleranci k chybě a informaci, zda může zasáhnout člověk. U textu určeného pro zákazníka je riziko jiné než u interního pomocného návrhu. Zahrňte i případy, kdy správnou odpovědí je „nevím“.
Testovací sada má obsahovat skutečné jazyky produktu. Model, který přesvědčivě odpovídá v angličtině, může chybovat v české či španělské terminologii. Vyhněte se tajným datům v neověřených testovacích prostředích; použijte anonymizované příklady. Počet příkladů může být na začátku malý, ale musí pokrýt těžké a běžné situace. Oddělte sadu pro výběr a sadu pro závěrečné hodnocení, aby se systém neučil pouze odpovídat na otázky, podle nichž ho pak známkujete.
Porovnávejte varianty při stejné laťce
Připravte jednoduchou matici se třemi sloupci: vlastní infrastruktura, oddělený hosting a externí API. Pro všechny vyplňte datovou hranici, kvalitu na stejné testovací sadě, latenci při běžné i špičkové zátěži, provozní práci, možnosti aktualizace a celkové náklady. Nenechte jednu variantu vyniknout jen proto, že měla lepší instrukce nebo čerstvější dokumenty. Měňte vždy jednu důležitou proměnnou a ukládejte verzi modelu, promptu, zdrojů a výpočetního prostředí.
Matice nemusí vytvořit jediného vítěze pro všechny úlohy. Interní shrnutí citlivých dokumentů může vyžadovat přísnější hranici než veřejný marketingový text. Některé úlohy nepotřebují model vůbec: kvalitní vyhledávání či pravidlová automatizace mohou být levnější a předvídatelnější. Takový výsledek není neúspěch pilotu. Srovnání má pomoci rozhodnout, kde model přináší měřitelnou hodnotu, kde se vyplatí jiný postup a jaké předpoklady zůstávají otevřené.
Výkon není jedna ukázková odpověď
Vlastní inference vyžaduje dostatek paměti pro váhy modelu, pracovní data a paralelní požadavky. Délka vstupů i výstupů mění latenci a spotřebu. Kvantizace může snížit nároky na paměť, ale není to bezplatné zrychlení; konkrétní metoda může ovlivnit kvalitu nebo rychlost. Dokumentace Hugging Face popisuje více postupů a jejich odlišné chování. Ověřujte je na svých úlohách, ne podle velikosti modelu uvedené v názvu.
Měřte běžný provoz, špičku i dlouhé dokumenty. Sledujte čas k první části odpovědi, celkovou dobu, neúspěšné požadavky a náklady na jednu dokončenou úlohu. U interaktivního produktu může být pomalejší odpověď přijatelná, pokud je kvalitnější; jinde je čekání zásadní překážkou. Do výsledku zahrňte restart, nedostupný model server a plnou frontu. Laboratorní číslo pro jediný dotaz na prázdném stroji nepopisuje službu pro skutečné uživatele.
Cena zahrnuje nevyužitou kapacitu a lidi
Při vlastním hostingu započítejte hardware nebo pronájem, energii, úložiště, síť, zálohy, aktualizace, dohled a čas lidí. Výpočet provádějte pro očekávaný objem i realistickou špičku. Pokud je provoz nárazový, prázdný server může stát více než jednotlivá volání API. Naopak při stabilní vysoké zátěži může vlastní kapacita dávat ekonomický smysl. Bez konkrétního měření nelze tvrdit, že jedna varianta bude vždy levnější.
U API zahrňte cenu vstupních a výstupních tokenů, případné další služby, limity a náklady na integraci. Ceny se mění, proto je ověřujte v době rozhodnutí u poskytovatele a počítejte s rezervou. Porovnávejte cenu za úspěšně vyřešenou úlohu, nikoli jen cenu za tisíc tokenů. Model s dražším voláním může být ve výsledku levnější, pokud potřebuje méně oprav, a opačně. Rozpočet má zahrnout i lidskou kontrolu u úloh s větším dopadem.
Bezpečnost se nekončí umístěním modelu
OWASP upozorňuje na riziko zveřejnění citlivých informací ve výstupech modelu. Oprávnění proto musejí platit při získání dokumentů, předání kontextu i zobrazení odpovědi. Nezapisujte automaticky celé konverzace do logů, pokud pro to není důvod a řízený přístup. Ukládání diagnostiky, záloh a kopií testovacích dat může změnit skutečnou datovou hranici. Vlastní model server neochrání dokument, který aplikace zobrazí nesprávnému uživateli.
Dalším problémem jsou instrukce ukryté ve zdrojích. Nalezený dokument nebo příchozí e-mail může obsahovat pokyn, který se snaží ovlivnit model. OWASP popisuje prompt injection jako riziko, které nelze odstranit pouhým RAG. Pokud má AI přístup k nástrojům, musí aplikace ověřit oprávnění a parametry každé akce nezávisle na textu modelu. V pilotu testujte chybné i záměrně škodlivé vstupy. Návrh ochrany se vztahuje k celému workflow, ne k jedné systémové instrukci.
Změny modelu jsou změny produktu
Nová verze modelu může změnit styl, přesnost i způsob odmítání odpovědí. Totéž platí pro aktualizaci inference serveru, zdrojových dokumentů nebo instrukcí. Každou významnou změnu ověřte na stálé regresní sadě a sledujte rozdíl proti předchozí verzi. Zaznamenejte, kdo přepnutí schválil a jak se vrátit. U vlastního hostingu navíc hlídejte licence modelů a jejich původ. U API sledujte dostupnost konkrétní verze a pravidla změn poskytovatele.
Provozní monitoring má zahrnovat latenci, chyby, kapacitu i kvalitu skutečných výsledků. NIST AI Risk Management Framework pomáhá chápat řízení rizik jako průběžnou práci, nikoli jako jednorázový test před spuštěním. Zaveďte jednoduchou cestu pro nahlášení chybné odpovědi a její vyhodnocení. Pokud se opakuje stejný typ chyby, zjistěte, zda je příčinou špatný zdroj, model, oprávnění nebo návrh úlohy. Přepnutí na větší model není automatická oprava.
Připravte selhání a možnost návratu
Co se stane, když model neodpoví? Některá práce může počkat ve frontě, jiná potřebuje okamžitý ruční postup. Uživatelské rozhraní musí rozlišit rozpracovanou úlohu, neúspěšný pokus a výsledek vyžadující kontrolu. Vlastní hosting přidává obnovu serveru a modelových souborů; externí API zase závislost na síti a poskytovateli. V obou případech nastavte časový limit, omezené opakování a jasné pravidlo, kdy úlohu převezme člověk.
Před pilotem napište hranici pro ukončení nebo změnu varianty: například nepřijatelná chybovost, latence, provozní náklady nebo nedoložená datová kontrola. Jinak může tým donekonečna upravovat systém bez rozhodnutí. Pilot končí srovnáním skutečných výsledků, otevřených rizik a dalších kroků. Privátní AI má smysl, když konkrétní úloha získá požadovanou kontrolu a kvalitu za přiměřené celkové náklady. Není cílem sama o sobě.
Po rozhodnutí připravte krátký provozní záznam pro lidi, kteří budou službu přebírat. Má obsahovat schválené použití, hranici dat, použité verze, výsledky evaluace, známá omezení, kontakt při problému a postup vypnutí. Uveďte také, které úlohy jsou zakázané nebo vyžadují lidské potvrzení. Tento dokument není reklamní popis schopností modelu; je to praktický návod, jak nepoužít systém mimo ověřený rozsah. Při změně modelu nebo zdroje znalostí záznam aktualizujte spolu s testovací sadou. Pokud nevíte, kdo může rozhodnout o přepnutí zpět, pilot ještě není připraven na běžný provoz.
Stejná disciplína pomáhá porovnat i variantu bez generativního modelu. Uložte vedle výsledků AI také čas a přesnost současného ručního postupu nebo klasického vyhledávání. Teprve tento základ ukáže, zda nová služba opravdu zrychluje práci a neodsunuje chyby na jiné oddělení. Návrat k jednoduššímu postupu pak není selhání, ale rozhodnutí podložené stejnými kritérii.