GDPR և գաղտնիություն ինժեներների համար

01Ինչն է համարվում անձնական տվյալ

Անձնական տվյալը ցանկացած տեղեկություն է, որը վերաբերում է նույնականացված կամ նույնականացվող կենդանի անձի։ Անուններն ու email-ները ակնհայտ են։ Պակաս ակնհայտ են՝ IP հասցեները, սարքերի ID-ները, cookie ID-ները, պատվերների պատմությունը, տեղորոշման կետերը, ձայնագրությունները և աջակցության չատերի լոգերը։ Եթե տվյալը կարելի է կապել որևէ մարդու հետ՝ ինքնուրույն կամ այլ տվյալների հետ միասին, որոնք դուք իրատեսորեն կարող եք ստանալ, այն համարվում է անձնական։ Որոշ կատեգորիաներ «հատուկ» են և ավելի ուժեղ հիմնավորում են պահանջում՝ առողջություն, նույնականացման համար օգտագործվող կենսաչափական տվյալներ, կրոն, քաղաքական հայացքներ, սեռական կողմնորոշում, արհմիության անդամակցություն, ռասայական կամ էթնիկ ծագում, գենետիկ տվյալներ։ Կեղծանվանացված (pseudonymised) տվյալները, օրինակ՝ օգտատիրոջ ID-ն անալիտիկայի աղյուսակում, դեռ անձնական տվյալներ են, քանի որ դրանք կարելի է վերանույնականացնել։ Օրենքից դուրս են միայն իսկապես անանունացված տվյալները, որտեղ վերանույնականացումն իրատեսորեն հնարավոր չէ, իսկ իրական անանունացումն ավելի բարդ է, քան թվում է։

• Վերահսկող (controller)՝ որոշում է, թե ինչու և ինչպես են մշակվում տվյալները (սովորաբար ձեր հաճախորդը կամ ընկերությունը)։
• Մշակող (processor)՝ մշակում է տվյալները վերահսկողի անունից (ձեր հոսթինգը, email-ի կամ անալիտիկայի մատակարարը)։
• Տվյալների սուբյեկտ (data subject)՝ այն մարդը, ում մասին են տվյալները։

02Սկզբունքները՝ թարգմանված ինժեներիայի լեզվով

5-րդ հոդվածը թվարկում է այն սկզբունքները, որոնց պետք է հետևի ցանկացած համակարգ, և դրանցից յուրաքանչյուրը վերածվում է դիզայնի կոնկրետ որոշումների։ Օրինականություն, արդարություն և թափանցիկություն՝ յուրաքանչյուր օգտագործման համար վավեր պատճառ, որը բացատրված է գաղտնիության քաղաքականությունում։ Նպատակի սահմանափակում՝ առաքման համար հավաքված տվյալները լուռ չեն վերաօգտագործվում անկապ պրոֆայլինգի համար։ Տվյալների նվազեցում՝ մի հավաքեք ծննդյան ամսաթիվ, եթե ձեզ պետք է իմանալ միայն, որ օգտատերը չափահաս է։ Ճշգրտություն՝ թույլ տվեք օգտատերերին ուղղել իրենց տվյալները։ Պահպանման սահմանափակում՝ ջնջեք կամ անանունացրեք տվյալները, երբ դրանց նպատակն ավարտվում է, պահպանման ավտոմատ ջոբերով։ Ամբողջականություն և գաղտնիություն՝ գաղտնագրում, մուտքի վերահսկում, լոգավորում։ Հաշվետվողականություն՝ կարողացեք ցույց տալ, թե ինչ եք անում, փաստաթղթերի, ռեեստրների և աուդիտի հետքերի միջոցով։ 25-րդ հոդվածն ավելացնում է «տվյալների պաշտպանություն նախագծմամբ և լռելյայն» (by design and by default)․ ամենագաղտնի տարբերակը պետք է լինի լռելյայն կարգավորումը։

03Իրավական հիմքեր և ճիշտ արված համաձայնություն

Յուրաքանչյուր մշակման գործողության համար անհրաժեշտ է վեց իրավական հիմքերից մեկը՝ համաձայնություն, պայմանագիր, իրավական պարտավորություն, կենսական շահեր, հանրային խնդիր կամ օրինական շահեր։ Ինժեներները հաճախ կարծում են, որ համաձայնությունը միշտ է պետք․ դա այդպես չէ։ Պատվերի մշակումն օգտագործում է «պայմանագիր»։ Հաշիվ-ապրանքագրերի պահումը՝ «իրավական պարտավորություն»։ Խարդախության կանխարգելումը հաճախ օգտագործում է «օրինական շահեր»՝ շահերի հավասարակշռման թեստից հետո։ Համաձայնությունը ճիշտ է ոչ պարտադիր բաների համար, ինչպիսիք են մարքեթինգային նամակները կամ ոչ էական թրեքինգը, և այն պետք է լինի ազատ տրված, կոնկրետ, տեղեկացված և միանշանակ՝ ոչ մի նախապես նշված վանդակ, ոչ մի «օգտվելով այս կայքից՝ դուք համաձայնում եք»։ Այն հետ վերցնելը պետք է լինի նույնքան հեշտ, որքան տալը։ Cookie-ների և սարքում նմանատիպ պահման համար առանձին ePrivacy կանոնները համաձայնություն են պահանջում այն ամենի համար, ինչը խիստ անհրաժեշտ չէ, ուստի անալիտիկայի և գովազդի cookie-ները սպասում են, մինչև օգտատերը համաձայնի։

1-- Store consent as an auditable event, never as a single boolean
2CREATE TABLE consent_events (
3  id           BIGSERIAL PRIMARY KEY,
4  user_id      BIGINT NOT NULL REFERENCES users(id),
5  purpose      TEXT NOT NULL,          -- 'marketing_email', 'analytics'
6  granted      BOOLEAN NOT NULL,       -- true = given, false = withdrawn
7  notice_version TEXT NOT NULL,        -- which privacy text the user saw
8  source       TEXT NOT NULL,          -- 'signup_form', 'settings_page'
9  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
10);
11-- Current state = latest event per (user_id, purpose)

04Տվյալների սուբյեկտի իրավունքները պրոդուկտի ներսում

Մարդիկ ունեն իրավունքներ, որոնք դուք պետք է կարողանաք կատարել, սովորաբար մեկ ամսվա ընթացքում (բարդ հարցումների համար՝ ևս երկու ամսով երկարաձգելի)։ Մուտք՝ տալ նրանց տվյալների պատճենը և տեղեկություն, թե ինչպես են դրանք օգտագործվում։ Ուղղում՝ թույլ տալ ուղղել ոչ ճշգրիտ տվյալները։ Ջնջում («մոռացվելու իրավունք»)՝ ջնջել տվյալները, երբ դրանք պահելու վավեր պատճառ այլևս չկա, պահպանելով այն, ինչ պահանջում է օրենքը, օրինակ՝ հաշիվ-ապրանքագրերը։ Տեղափոխելիություն՝ տրամադրել մարդու կողմից ձեզ տրված տվյալները կառուցվածքային, մեքենայաընթեռնելի ֆորմատով, օրինակ՝ JSON կամ CSV։ Առարկություն և սահմանափակում՝ հարցման դեպքում դադարեցնել որոշակի մշակում, օրինակ՝ ուղիղ մարքեթինգը։ Ինժեներական տեսանկյունից սա նշանակում է տվյալների քարտեզ, որը գիտի յուրաքանչյուր աղյուսակ, բաքեթ, լոգ և երրորդ կողմ, որտեղ կան օգտատիրոջ տվյալները, գումարած թեստավորված արտահանման և ջնջման ջոբեր։ Նախ ստուգեք հարցում անողի ինքնությունը, որպեսզի մուտքի ֆունկցիան չդառնա տվյալների արտահոսք։

• Ակաունթի կարգավորումներում ինքնասպասարկման արտահանումն ու ջնջումը նվազեցնում են աջակցության ծանրաբեռնվածությունը։
• Ջնջումը պետք է հասնի բեքափներին, որոնման ինդեքսներին, քեշերին և մշակողներին՝ հայտնի ժամանակացույցով։
• Լոգավորեք յուրաքանչյուր հարցում և դրա կատարումը՝ հաշվետվողականության համար։

05Անվտանգություն, արտահոսքեր և 72 ժամը

GDPR-ը պահանջում է անվտանգության «համապատասխան տեխնիկական և կազմակերպչական միջոցներ»՝ գնահատված ըստ ռիսկի։ Տիպիկ ակնկալիքներն են՝ գաղտնագրում փոխանցման ժամանակ (TLS) և պահման ժամանակ, նվազագույն արտոնությունների սկզբունքով մուտք, բազմագործոն նույնականացում աշխատակիցների համար, անձնական տվյալներին մուտքի աուդիտի լոգեր, անվտանգ մշակման պրակտիկաներ և ստուգված բեքափներ։ Անձնական տվյալների արտահոսքը ցանկացած անվտանգության միջադեպ է, որը հանգեցնում է անձնական տվյալների պատահական կամ անօրինական ոչնչացման, կորստի, փոփոխման, բացահայտման կամ դրանց մուտքի, և ոչ միայն հաքեր․ սխալ հասցեատիրոջն ուղարկված email-ը նույնպես հաշվվում է։ Վերահսկողը պետք է տեղեկացնի վերահսկող մարմնին դրա մասին իմանալուց հետո 72 ժամվա ընթացքում, եթե միայն այն քիչ հավանական է, որ ռիսկ կստեղծի մարդկանց համար, և պետք է ուղղակիորեն տեղեկացնի տուժած մարդկանց, երբ ռիսկը բարձր է։ Մշակողները պետք է տեղեկացնեն վերահսկողին առանց անհարկի ուշացման։ Յուրաքանչյուր արտահոսք, նույնիսկ չզեկուցվածը, պետք է ներքին կարգով փաստաթղթավորվի։

06Մատակարարներ, փոխանցումներ և կարևոր փաստաթղթեր

Յուրաքանչյուր մատակարար, որը ձեզ համար անձնական տվյալներ է մշակում, օրինակ՝ հոսթինգ, email-ի առաքում, անալիտիկա կամ սխալների թրեքինգ, մշակող է, և նրա հետ անհրաժեշտ է տվյալների մշակման պայմանագիր (DPA, 28-րդ հոդված)։ Պահեք դրանց ցուցակը․ այն միաժամանակ ծառայում է որպես ձեր հաճախորդների համար ենթամշակողների ցուցակ։ Անձնական տվյալները Եվրոպական տնտեսական տարածքից (EEA) դուրս ուղարկելու համար պետք է փոխանցման մեխանիզմ՝ համարժեքության որոշում (ներառյալ EU-US Data Privacy Framework-ը հավաստագրված ամերիկյան ընկերությունների համար), ստանդարտ պայմանագրային դրույթներ (SCC) կամ V գլխի այլ գործիք։ Կազմակերպությունները պետք է վարեն մշակման գործողությունների ռեեստր (30-րդ հոդված), իսկ բարձր ռիսկով մշակումը, օրինակ՝ լայնածավալ մոնիտորինգը կամ զգայուն տվյալները, գործարկումից առաջ պահանջում է տվյալների պաշտպանության ազդեցության գնահատում (DPIA, 35-րդ հոդված)։ Ինժեներները հազվադեպ են գրում այս փաստաթղթերը, բայց հենց նրանք են տրամադրում փաստերը՝ ինչ է հավաքվում, որտեղ է պահվում, ով ունի մուտք և որքան ժամանակով։

07Privacy by design տվյալների մոդելում

Նախագծեք սխեման այնպես, որ գաղտնիությունը հեշտ լինի։ Առանձնացրեք ինքնության տվյալները (անուն, email, հեռախոս, հասցե) վարքային տվյալներից (պատվերներ, իրադարձություններ)՝ կապելով դրանք ներքին ID-ով, որպեսզի անալիտիկան և արտահանումները կարողանան աշխատել վարքային մասի հետ՝ առանց ինքնության դաշտերի։ Նշեք անձնական սյունակները կոդում կամ սխեմայի մեկնաբանություններում, որպեսզի գործիքները կարողանան գտնել դրանք։ Ավելացրեք պահպանման մետատվյալներ՝ ստեղծման ամսաթիվ, նպատակ և ժամկետի լրանալու կանոն յուրաքանչյուր աղյուսակի համար։ Խիստ զգայուն արժեքների համար օգտագործեք դաշտային մակարդակի գաղտնագրում՝ բազայից դուրս կառավարվող բանալիներով։ Պահեք աուդիտի աղյուսակներ այն մասին, թե ով է մուտք գործել անձնական տվյալներին կամ փոխել դրանք, հատկապես ադմին վահանակներից։ Երբ օգտատերը ջնջվում է, դիզայնը պետք է դա դարձնի մի քանի հստակ սահմանված գործողություն, ոչ թե որոնում ամբողջ կոդաբազայով։

1// Retention job: anonymise inactive guest orders after the retention period
2await db.order.updateMany({
3  where: {
4    userId: null,
5    createdAt: { lt: subMonths(new Date(), RETENTION_MONTHS) },
6    anonymisedAt: null,
7  },
8  data: {
9    guestEmail: null,
10    guestPhone: null,
11    shippingAddress: null,
12    anonymisedAt: new Date(),
13  },
14});

08Լոգեր, observability և AI գործիքներ

Լոգերը անձնական տվյալների ամենատարածված թաքնված պահոցն են։ Հարցումների լոգերը որսում են email-ներ, թոքեններ և IP հասցեներ, սխալների թրեքերները՝ ֆորմաների պարունակությունը, իսկ session replay գործիքները կարող են գրանցել այն ամենը, ինչ մուտքագրվում է։ Կարգավորեք մաքրումն աղբյուրում՝ դաշտերի allow-list՝ block-list-ի փոխարեն, քողարկեք query string-երը և սահմանեք կարճ պահպանման ժամկետ հում լոգերի համար։ Observability մատակարարներին վերաբերվեք որպես մշակողների՝ պայմանագրերով և ձեր ընտրած ռեգիոններով։ Նույնը վերաբերում է AI ծառայություններին․ աջակցության տիկետներ կամ օգտատերերի փաստաթղթեր մեծ լեզվական մոդելի API ուղարկելը փոխանցում է մշակողին, ուստի ստուգեք մատակարարի տվյալների մշակման պայմանները, պահպանման ժամկետը, ուսուցման համար օգտագործումը և ռեգիոնը, և հեռացրեք նույնացուցիչները, երբ խնդրին դրանք պետք չեն։

09Միջազգային փոխանցումները գործնականում

V գլուխը սահմանափակում է անձնական տվյալների փոխանցումը EEA-ից դուրս։ Ամենամաքուր ճանապարհը համարժեքության որոշումն է՝ ԵՄ-ն ճանաչել է այնպիսի երկրներ, ինչպիսիք են Մեծ Բրիտանիան, Շվեյցարիան, Ճապոնիան և Հարավային Կորեան, իսկ EU-US Data Privacy Framework-ը ծածկում է ինքնահավաստագրված ամերիկյան ընկերություններին․ 2025 թվականին այն դիմակայեց առաջին դատական վիճարկմանը ԵՄ Ընդհանուր դատարանում, թեև հետագա բողոքարկումները հնարավոր են։ Հակառակ դեպքում սովորական գործիքը ստանդարտ պայմանագրային դրույթներն են՝ գումարած փոխանցման ազդեցության գնահատում (TIA)։ Ինժեներական որոշումները փոքրացնում են խնդիրը՝ հիմնական պահման համար ընտրեք ԵՄ ռեգիոններ, ստուգեք, թե որտեղից են աջակցությունն ու ենթամշակողները մուտք գործում տվյալներին, և հում անձնական տվյալներ մի ուղարկեք այն գործիքներին, որոնց դրանք պետք չեն։ Մատակարարների և ռեգիոնների ցուցակը թարմ պահեք, քանի որ հաճախորդները կհարցնեն։

10Փոփոխություններ են գալիս․ հետևեք բարեփոխումներին

Գաղտնիության օրենսդրությունը ստատիկ չէ։ 2025 թվականի նոյեմբերին Եվրոպական հանձնաժողովն առաջարկեց «Digital Omnibus» փաթեթը, որը կփոխեր GDPR-ի և cookie-ների կանոնների մասեր․ գրելու պահին (2026 թվականի նոյեմբեր) տվյալների պաշտպանության մասը դեռ քննարկվում է Խորհրդարանի և Խորհրդի կողմից, ուստի GDPR-ի գործող տեքստը կիրառվում է առանց փոփոխության։ Ազգային կարգավորողները նույնպես հրապարակում են պարզաբանումներ, որոնք փոխում են պրակտիկան, օրինակ՝ cookie բանների, կեղծանվանացման և օրինական շահերի վերաբերյալ։ Որպես ինժեներ՝ կառուցեք համակարգեր, որոնք հեշտ է հարմարեցնել՝ կարգավորելի պահպանման ժամկետներ, նպատակներով պիտակավորված համաձայնություններ, տվյալների կենտրոնական քարտեզ և feature flag-եր թրեքերների շուրջ։ Այդ դեպքում, երբ կանոնները փոխվեն, դուք կփոխեք կարգավորումները, ոչ թե կվերակառուցեք համակարգը։