Helyben futó MI egy titoktartásra épülő cégnek: esettanulmány

Egyes cégek nem tehetik az adataikat valaki más felhőjébe — nem azért, mert paranoiásak, hanem mert a titoktartás maga a termék, amit árulnak. Ez egy ilyen cég története, és annak, hogyan adtuk meg nekik egy modern MI-asszisztens gyorsaságát úgy, hogy egyetlen ügyfélakta se hagyja el valaha a saját négy faluk közét. Semmi marketingcsillogás. Csak az, amit kipróbáltunk, ami elromlott, és ami végül működött.

Évente néhányszor kapunk egy bizonyos fajta megkeresést. Általában egy ilyen mondattal kezdődik: „Szívesen használnánk MI-t, de jogilag nem küldhetjük sehová az adatainkat.” A vonal túlsó végén álló személy már látta, ahogy kollégái érzékeny anyagot illesztenek be egy nyilvános chatbotba, érezte, ahogy összeszorul a gyomra, és csendben betiltotta az egész kategóriát. Nem technológiaellenesek. Beszorultak egy valódi termelékenységi lehetőség és egy nem alkukérdés titoktartási kötelezettség közé.

Ez az esettanulmány pontosan egy ilyen cégről szól. Hogy tiszteletben tartsuk azt a titoktartást, amely a projektet meghatározta, mindent anonimizáltunk — a nevet, az embereket, az ügyfeleik konkrét adatait. A számok szemléltető jellegűek és kerekítettek, nem auditált adatok. De a probléma alakja és a mód, ahogy megoldottuk, pontosan olyan, ahogy megtörtént.

A helyzet: termelékenység a titoktartás fala mögé zárva

Az ügyfél egy közepes méretű tanácsadó cég volt egy olyan területen, ahol a diszkréció nem szép ráadás — ez az egész oka annak, hogy az ügyfelek felfogadják őket. Gondoljon egy irodára, amely érzékeny vállalati, jogi vagy biztonsághoz közeli munkát kezel, ahol egy szivárgás nemcsak kínos lenne; véget vetne az üzletnek. Nagyjából harminc ember, komoly ügyteher, és egy hegynyi hosszú, sűrű dokumentum, amelyet valakinek minden egyes héten el kell olvasnia, össze kell foglalnia és össze kell vetnie.

Csapatuk figyelte, ahogy a világ többi része felgyorsul az MI-asszisztensekkel, és érezte, ahogy a szakadék szélesedik. Egy junior fél napot tölthetett azzal, hogy egy 90 oldalas jelentésből kihúzza a lényeget. Egy akta első összefoglaló változatának megírása órákat evett meg, amelyeket senki sem számlázott. A munka pontosan az a sűrű, nyelvileg terhelt robot volt, amiben a modern MI valóban jó — és ők hozzá sem érhettek.

Az akadály egyszerű és abszolút volt. Az ügyfélszerződéseik és a saját belső szabályzatuk is tiltotta, hogy ügyfélanyagot bármilyen harmadik fél szolgáltatásának küldjenek. Se anonimizálva, se átvitel közben titkosítva, se „a szállító megígéri, hogy nem tanít rajta”. Az adat nem hagyhatta el a telephelyüket, pont. A piacon lévő minden felhős MI-eszköz definíció szerint szóba sem jöhetett, bármilyen jól nézett is ki papíron az adatvédelmi szabályzata.

Ez az utolsó megkülönböztetés az egész projekt egyetlen mondatban. Sok „privát MI” ajánlat valójában valaki más felhője szigorúbb szerződéssel. Ennek az ügyfélnek ez nem volt elég. Az egyetlen elfogadható válasz egy olyan rendszer volt, ahol az érzékeny adat fizikailag soha nem utazott — ahol elvben kihúzhatná a hálózati kábelt, és az asszisztens még mindig működne.

Miért nem illettek a kézenfekvő felhős válaszok

Mielőtt bármit építettünk volna, elvégeztük az átvilágítást a könnyebb utakon — mert a helyben futó megoldás több munka, és nem ajánljuk, ha egy egyszerűbb opció valóban megfelel. Ennél az ügyfélnél minden gyorsút ugyanabba a falba ütközött.

A nagy szolgáltatók mind kínálnak vállalati szinteket „nem tanítunk az adataidon” ígérettel és regionális tárhellyel. Megnyugtató, és sok cégnek teljesen elegendő. De ez még mindig azt jelenti, hogy az ügyfélakták elhagyják az épületet, és — akár röviden is — egy olyan infrastruktúrán ülnek, amelyet a cég nem irányít. Egy olyan iroda számára, amelynek szerződései ezt kifejezetten tiltják, egy erős ígéret is csak ígéret — és az ígéretek nem élik túl azt az auditkérdést, amely így kezdődik: „tudják garantálni, hogy…”.

Kizártuk a privát felhő példányt is — egy dedikált, elszigetelt környezetet, amelyet egy szolgáltató üzemeltet. Technikailag erősebb, és egyes cégeknek tökéletesen jó megoldás. De ez még mindig bérelt hardverre helyezte az adatot egy olyan épületben, amely nem az ügyfélé, és fenntartott egy külső szállítótól való függést valami olyasmiben, amit az ügyfél teljesen a saját fedele alatt akart. Hajlandók voltak feláldozni némi kényelmet ezért az irányításért. Így hát helyben futó lett.

Mit építettünk valójában

A megoldás, a lényegére csupaszítva, egy privát MI-asszisztens volt, amely egyetlen erős szerveren futott az ügyfél saját irodáján belül. A csapat egy hétköznapi weboldalon keresztül éri el a böngészőjében — úgy néz ki és úgy is érződik, mint a chateszközök, amelyeket már mindenki ismer. E mögött az ismerős ablak mögött soha semmi nem hagyja el a helyi hálózatot.

Az architektúrát szándékosan unalmasra vettük. Az unalmas megbízható, és a megbízhatóság az, amire egy adatvédelmi szempontból kritikus rendszernek szüksége van. Három mozgó alkatrészt érdemes megnevezni.

Egy nyílt súlyú modell helyben futtatva

Ahelyett, hogy egy üzemeltetett modellt hívtunk volna meg, egy erős nyílt súlyú nyelvi modellt futtattunk közvetlenül a szerver GPU-ján. A nyílt súlyok itt számítanak: a modellfájlok az ügyfél lemezén laknak, az ügyfél hardverén futnak, és internetes oda-vissza út nélkül válaszolnak a kérdésekre. A munkaterhelésükhöz — összefoglalás, kinyerés, fogalmazás, saját dokumentumaikról szóló kérdések megválaszolása — egy jól megválasztott közepes méretű modell több mint elég jó volt. Nem az abszolút élvonalra volt szükségük; egy hozzáértő és privát modellre.

Egy privát tudásréteg a saját fájljaik felett

Az igazi érték nem egy általános chatbot volt — hanem egy asszisztens, amely a saját aktáikról tudott kérdésekre válaszolni. Építettünk egy visszakereső réteget, amely helyben indexeli a dokumentumaikat, így amikor valaki azt kérdezi, „mire jutottunk az X-szel kapcsolatban a Müller-ügyben”, a rendszer megtalálja a releváns szakaszokat, és azokból válaszol. Ez az index, mint minden más, teljesen a helyi gépen ül. Egyetlen dokumentum, sem annak töredéke, nem kerül soha sehová feltöltésre.

Hozzáférés-kezelés, amely illeszkedett a meglévő szabályaikhoz

Egy ilyen cégnek már szigorú szabályai vannak arról, ki láthatja mely fájlokat. Az asszisztensnek tiszteletben kellett tartania ezeket, nem megkerülnie. Így a hozzáférés a meglévő jogosultságaikat tükrözte: csak olyan anyagról kérdezheted az MI-t, amelyet már megnyithatsz. Ez magától értetődőnek hangzik, de éppen ez az, ami egy okos demót olyasvalamivé alakít, amit egy megfelelőségi felelős valóban jóváhagy.

Hogyan vezettük be a munka megzavarása nélkül

Egy titoktartásra épülő cég érthető módon óvatos az új rendszerekkel. Nem szándékoztunk úgy elnyerni a bizalmat, hogy átbillentünk egy kapcsolót és győzelmet hirdetünk. Így a projektet apró, visszafordítható lépések sorozataként vezettük, mindegyiket bizonyítva, mielőtt a következő elkezdődött.

1. 1
   Először egy fájdalmas feladatot határoltunk körül

   Nem próbáltunk 'MI-t hozzáadni a céghez.' Kiválasztottunk egyetlen nagy volumenű munkát — a hosszú beérkező dokumentumok összefoglalását — és arra építettünk. Egy világos cél, könnyű sikerként vagy kudarcként megítélni.
2. 2
   Egy tesztgépen építettük, fiktív adatokkal

   Minden először egy elszigetelt gépen állt fel kitalált dokumentumokkal, így semmilyen valós ügyféladat nem szerepelt, amíg a rendszer nem bizonyult, és a biztonsági modellt át nem vizsgálták.
3. 3
   Zárt pilotot futtattunk néhány haladó felhasználóval

   Egy maroknyi tapasztalt munkatárs használta valós munkán több héten át, a szokásos folyamatuk mellett. Megtalálták a durva éleket — furcsa megfogalmazások, néhány dokumentum, amelyet az index rosszul kezelt — és mi kijavítottuk őket.
4. 4
   A saját szabályzatuk alapján felülvizsgáltuk

   Bármilyen szélesebb bevezetés előtt a megfelelőségi vezetőjük pontosan auditálta, hol lakik és mozog az adat. Mivel a válasz az volt, hogy 'sehol máshol, csak itt', ez a felülvizsgálat rövid volt — ami az egész tervezési cél volt.
5. 5
   Egyoldalas útmutatóval nyitottuk meg a csapatnak

   Csak amikor már megbíztak benne, vezettük be az egész cégnél egy közérthető jegyzettel arról, miben jó, miben nem, és azzal az emlékeztetővel, hogy soha nem talál ki — hivatkozik.

Az eredmény: órák vissza, és semmi sem hagyta el az épületet

A teljes bevezetéstől számított néhány hónapon belül az asszisztens csendben a napi rutin részévé vált. A fő eredmény az volt, amely a legjobban érdekelte őket: egyetlen bájtnyi ügyféladat sem hagyta el soha a telephelyüket, és ezt bárkinek be tudták bizonyítani, aki kérdezte. A rendszer az ő szerverükön, az ő irodájukban, az ő irányításuk alatt fut. Már ez önmagában igazolta számukra a projektet.

A termelékenységi oldal volt a ráadás, ami kifizetődővé tette. Egy hosszú dokumentum első összefoglaló változata — korábban egy juniornak több órás munka — percnyi átnézésre és szerkesztésre csökkent. A munkatársak abbahagyták az egész fájlok újraolvasását egyetlen ténykérdés megválaszolásához; megkérdezték az asszisztenst, kaptak egy hivatkozott szakaszt, és másodpercek alatt ellenőrizték. A csapaton belül a felszabadult idő minden hét jelentős részévé állt össze, a dokumentumok darálásáról átirányítva a nagyobb értékű elemzésre, amelyért az ügyfelek valóban fizetnek.

Ugyanolyan sokatmondó volt egy finomabb változás. Emberek, akik csendben idegeskedtek az MI miatt — attól tartva, hogy az egy alkalomra váró szivárgás — kényelmesen kezdték használni, éppen azért, mert megértették, miért biztonságos. A bizalom nem abból jött, hogy megnyugtattuk őket. Egy olyan architektúrából jött, amelyet egy ügyfélnek egy mondatban el tudtak magyarázni: soha nem hagyja el az épületet.

Mibe került, őszintén

A helyben futó MI nem az olcsó opció, és rossz szolgálatot tennénk önnek, ha az ellenkezőjét színlelnénk. Van egy valódi szerver egy valódi GPU-val megvenni, egy bevezetési projekt finanszírozni, és folyamatos karbantartás beütemezni — javítások, modellfrissítések, alkalmi finomhangolás. Egy cégnek, amelynek titoktartása szerződéses, ez a költség könnyen indokolható. Egy cégnek, amelynek csak tetszik a magánélet gondolata, gyakran nem, és ezt meg is mondjuk.

Az őszinte kompromisszum így néz ki: magasabb kezdeti költség és egy kicsit több felelősség cserébe a teljes irányításért és azért, hogy nincsenek üzenetenkénti felhődíjak, amelyek a használattal skálázódnak. Egy nagy használatú, érzékeny anyagot kezelő csapatnál a gazdaságosság valójában idővel javul — megvette a kapacitást ahelyett, hogy lekérdezésenként bérelné. Könnyű vagy alkalmi használatra egy felhős eszköz szinte biztosan olcsóbb lenne. Tudni, hogy a vonal melyik oldalán áll, a döntés nagy része.

• Egy erős szerver megfelelő GPU-val — egyszeri tőkeberuházás, nem előfizetés.
• Egy bevezetési projekt: a modell telepítése és finomhangolása, a dokumentumindex felépítése, a hozzáférés-kezelés bekötése.
• Folyamatos karbantartás: biztonsági javítások, modellfrissítések, alkalmi újrahangolás, ahogy az igények változnak.
• Belső gazda: egy megnevezett személy, aki szemmel tartja, pontosan úgy, ahogy bármely alaprendszert működtetne.
• Nincs lekérdezésenkénti felhőszámla — a használat, amely a felhőben drága lenne, lényegében ingyenes, ha a hardver egyszer ki van fizetve.

Illene ez az ön vállalkozásához?

Ez nem egyszeri eset volt. Ugyanez a minta illik bármely céghez, ahol a korlát az adatérzékenység, nem a költségvetés: ügyvédi irodák, egészségügyi és ahhoz közeli szolgáltatók, biztonsági és védelemhez közeli munka, pénzügyi tanácsadók, üzleti titkokon ülő K+F csapatok. Ha azon kapta magát, hogy vágyik az MI segítségére, de összerezzen a gondolatra, hová menne az adat, ön az a közönség, amelynek ez a megközelítés készült.

Ugyanígy, ha az adata nem különösebben érzékeny, és csak egy érzésért fizetne felárat, egy jó felhős opció felé irányítjuk, és megspóroljuk önnek a kiadást. A helyes válasz teljesen a kötelezettségeitől függ, nem attól, melyik technológia hangzik lenyűgözőbben. A leghasznosabb első lépés nem egy modell kiválasztása — hanem őszintének lenni azzal kapcsolatban, mit követel valójában a titoktartási kötelezettsége.

Gyakori kérdések