Claude és a GDPR: mit lát az Anthropic az adataidból

Üzleti csomagban — Team, Enterprise, API — az Anthropic nem használja a tartalmatokat modell tanítására, hacsak külön be nem jelentkeztek egy erre szolgáló programba. Ez a saját dokumentációjukban van kimondva, nem marketingállítás.

Egyéni csomagoknál más a helyzet: ott van egy beállítás, ami eldönti, felhasználhatják-e a beszélgetéseidet. Alapból nincs bekapcsolva, de bekapcsolható — és ha be van, akkor a megőrzési idő is jóval hosszabb.

Ez a különbség önmagában elég ok arra, hogy céges munka ne magánfiókban menjen.

A megőrzési idő nem egyetlen szám, és ezt szokás félreérteni.

A Claude Code-ból származó adatnál üzleti csomagban 30 nap az alap. A beszélgetéseknél viszont más a helyzet: szervezeti szinten alapértelmezetten határozatlan ideig maradnak, hacsak nem állítotok be egyedi megőrzési időt. Ezt Enterprise csomagban lehet, minimum 30 napra.

Ha nálatok van megőrzési szabály — mert szabályozott iparágban vagytok, vagy mert az ügyfélszerződés előírja —, akkor ez az a beállítás, amit meg kell nézni, mielőtt bárki éles adattal dolgozik. Nem attól lesz rendben, hogy üzleti csomagot vettetek.

Ti vagytok az adatkezelő, az Anthropic az adatfeldolgozó. A dokumentációjuk szerint adatfeldolgozóként járnak el, és csak a szolgáltatás nyújtásához, a ti utasításotok szerint kezelik az adatot.

Az adatfeldolgozói szerződés — a szabványos szerződéses klauzulákkal együtt — az üzleti feltételek része, tehát a feltételek elfogadásával létrejön. Nem kell külön aláírni. Érdemes viszont letölteni és eltenni, mert egy adatvédelmi kérdésnél vagy egy ügyfél-auditnál ezt fogják kérni.

Amit ez nem visz el rólatok: azért, hogy mi kerül be a rendszerbe, ti feleltek.

Előrebocsátom: nem vagyok jogász, és ez nem jogi tanácsadás. Ezek azok a pontok, amik a bevezetéseknél rendszeresen előjönnek, és amiket érdemes a jogászotokkal egyszer végigvenni.

Az adatkezelési tájékoztató. Ha ügyféladat is átmegy a rendszeren, akkor az Anthropic bekerül azok közé, akiket a tájékoztatótokban fel kell sorolni. Ez nem nagy munka, de kimarad, mert senkinek nem jut eszébe egy szoftverbevezetésnél.

A munkavállalók tájékoztatása. Ha a csapat munkája is átmegy rajta, arról tudniuk kell. Egy bekezdés a belső szabályzatban, ami leírja, mi mehet be és mi nem.

Az ügyfélszerződéseitek. Ez a leggyakrabban kihagyott. Sok magyar szerződésben van titoktartási vagy alvállalkozó-bevonási klauzula, ami erre is vonatkozhat. Ha van olyan ügyfeletek, akinél ez éles kérdés, azt előre érdemes tisztázni, nem utólag.

Az adatlokáció. Van EU/EGT-n belüli feldolgozási lehetőség, és a nagy felhőplatformokon keresztül régióhoz köthető végpontok is. De ez nem minden esetben az alapértelmezés. Ha nálatok adatlokációs elvárás van, ezt konkrétan nézzétek meg, ne feltételezzétek.

Egy: céges fiók, nem magánfiók. Ez az egyetlen legfontosabb tétel az egész oldalon. Aki a saját fiókjából dolgozik céges adaton, ott más feltételek érvényesek, nincs mögötte a céges szerződés, és kilépéskor senki nem tudja visszavenni.

Kettő: ki engedhet bekötést. A bekötések adják a tényleges hozzáférést a rendszereitekhez. Ha ezt bárki hozzáadhatja, akkor fél év múlva senki nem tudja, mi mihez fér hozzá.

Három: kiléptetés. A hozzáférés magától nem szűnik meg. Írjátok bele a kilépési folyamatba, ugyanoda, ahol a céges email megszüntetése van.

Négy: egy oldal leírva. Mi mehet be és mi nem. Nem szabályzat harminc oldalon — egy oldal, amit el is olvasnak. Ennyi többet ér, mint a legtöbb megfelelőségi projekt.