Лични данни без име: какво да проверите преди споделяне на файл

Правна информация, проверена към 2 ноември 2026 г.

Служител подготвя отчет за външен партньор. Изтрива колоните с имена и имейли, оставя клиентските номера, покупките и населените места и изпраща файла с пояснението: „Данните са анонимни“.

Преди да одобрите подобно изпращане, задайте още един въпрос: може ли получателят да разпознае, свърже с друга информация или индивидуално да проследи хората зад записите?

Лични данни могат да бъдат и данни без име. Значение има дали информацията се отнася до разпознаваем човек — пряко или чрез други сведения. Замяната на имената с кодове може да намали риска, но сама по себе си не доказва анонимност. Оценката зависи и от конкретния получател, достъпната му информация и ролята му. [1, 2]

Това е практически въпрос за всеки ръководител, който одобрява клиентски анализ, анкета сред служители, работа с външен доставчик или използване на изкуствен интелект.

Каква е разликата между псевдонимизация и анонимизация

При псевдонимизацията данните се преобразуват така, че да не могат да се отнесат към конкретен човек без допълнителна информация. Тази информация трябва да се пази отделно и да бъде защитена. Пример е клиентски код, чиято връзка с името се съхранява в отделна система с ограничен достъп.

При анонимизацията резултатът не позволява идентифициране чрез средства, които с разумна вероятност могат да бъдат използвани в съответния контекст. Оценяват се реалните възможности за разпознаване и свързване на информацията. [2, 3]

Подход	Какво прави	Какво да провери ръководителят
Премахване на имената	Заличава един вид идентификатор	Остават ли адреси, номера, редки характеристики или разпознаваеми истории
Псевдонимизация	Ограничава свързването с човек без отделна допълнителна информация	Кой държи тази информация и има ли други пътища за идентифициране
Анонимизация	Постига резултат, при който човекът не е идентифицируем в оценявания контекст	Има ли обоснована и документирана оценка на резултата

Криптирането има друга задача: ограничава прочитането на данните без подходящия ключ. То също е полезна мярка за сигурност, но не е доказателство, че информацията е анонимна. [1, 4]

За екипи, които избират и прилагат тези мерки, е подходящ курсът за технологичните аспекти на сигурността на личните данни. Програмата разглежда и управлението на достъпа, облачната сигурност и оценката на риска.

Шест ситуации, които заслужават допълнителна проверка

Следващите ситуации са илюстративни примери за решения в работна среда.

1. Един файл може да има различно значение за различни получатели

Компания предоставя записи с клиентски кодове за анализ. При нея има таблица, която свързва всеки код с конкретен клиент. За компанията данните остават лични.

Независим получател може да няма практически достъп до тази таблица. Въпреки това е нужно да се провери дали останалото съдържание, собствените му бази или достъпна външна информация позволяват идентификация. Отсъствието на ключ е само една част от оценката.

Решението на Съда на ЕС от 4 септември 2025 г. по C-413/23 P потвърждава, че псевдонимизираните данни не са непременно лични за всяко лице при всички обстоятелства. Делото е по Регламент 2018/1725 за институциите на ЕС; то има значение за тълкуването на съответните понятия и при GDPR. [5]

Отделете специално внимание на доставчик, който обработва данните от името на компанията. В проекта на Насоки 02/2026 EDPB разглежда тази ситуация през перспективата на администратора. Липсата на ключ при обработващия не е основание автоматично да отпаднат неговите задължения. [2]

Практическото решение е да опишете кой получава файла, в каква роля, за каква цел и с какъв достъп. Ако получателят ще го предава нататък, преценете и следващото предоставяне. Промяната на получателя може да промени възможностите за идентифициране. [5]

2. Анкетата е без имена, но екипът е малък

В анкета за работната среда няма поле за име. Има обаче отдел, длъжност, стаж и свободен коментар за конкретна среща.

В един отдел работи само един човек с посочената длъжност. Прекият му ръководител помни и описаната среща. За него отговорът може да бъде напълно разпознаваем.

Същият риск възниква при отчети за резултати от обучения, оценки на представянето, заплати и вътрешни сигнали. Понякога една уникална длъжност казва повече от инициали. Това следва от оценката на идентифицирането чрез съчетаване на сведения. [1]

Проверете какво вижда всеки получател. За управленския отчет може да са достатъчни резултати за по-големи групи, по-общи категории и преработени свободни коментари. Не определяйте анкетата като анонимна, преди да оцените и връзките през акаунти, индивидуални покани или други записи.

При анкети за работната среда темата се свързва и с оценката на психосоциалните рискове.

3. Търговският екип разполага само с телефонен номер

Списъкът за обаждания съдържа номера и отбелязани интереси, но няма имена. Ако номерът се отнася до разпознаваемо физическо лице, липсата на име не го изважда от обхвата на личните данни. Служебният контакт на конкретен човек също може да бъде лични данни. Общата фирмена централа или обща пощенска кутия не са непременно такива. [1, 6]

Следва и отделен въпрос: допустимо ли е да използвате контакта за конкретното обаждане или съобщение? Тук се проверяват произходът на списъка, правното основание, информирането, възраженията и правилата за използвания маркетингов канал. [7]

Съгласието е едно от възможните основания по GDPR. Според целта може да е приложимо друго основание, но то трябва да бъде определено и обосновано. Посочването на легитимен интерес не отменя специалните правила за директен маркетинг. [7, 8]

4. Маркетинговият профил няма име, но следва един и същ човек

Рекламна система разпознава един и същ потребител през постоянен идентификатор, свързва действията му и променя предложенията към него. Нейният оператор може никога да не научи гражданското му име.

Това не е достатъчно, за да се обяви профилът за анонимен. Когато човекът може да бъде разграничаван и третиран индивидуално в съответния контекст, е налице съществена възможност за идентифициране. Проектът на Насоки 02/2026 разглежда именно такъв рекламен сценарий. [2]

Подобна проверка е необходима и при хеширани имейли. Хешът е преобразувана стойност; ако тя служи за съпоставяне със съществуващи профили, преобразуването не доказва анонимност. За управленското решение е полезно да попитате какво прави системата с идентификатора: обобщава групи или проследява и оценява отделни хора. [3]

5. Служител качва клиентски казус в AI, след като е изтрил името

Представете си клиентска жалба, изпратена за автоматично обобщаване. Името е заменено с „Клиент 27“. Остават точната дата, обектът, номерът на поръчката и подробно описание на рядка ситуация.

Тези подробности могат да позволят разпознаване на клиента. Оценката трябва да обхване целия текст и приложенията, включително коментари, скрити листове и други сведения, които реално се предоставят.

Практичен подход е първо да се определи какво действително е нужно за задачата. За редактиране на тон може да е достатъчен измислен пример със същия комуникационен проблем. За анализ на тенденции може да са достатъчни обобщени категории. Това прилага принципа за свеждане на данните до необходимото. [9]

Когато са нужни реални лични данни, проверката включва одобрения инструмент, ролята и условията на доставчика, основанието за обработване, достъпа, срока на съхранение и евентуалното предаване извън ЕИП. Видът на абонамента сам по себе си не доказва допустимост. [4, 9]

За следващите стъпки вижте какво да проверите преди качване на клиентски данни в ChatGPT.

6. Медицински или семеен случай остава разпознаваем

Организация използва в презентация случай без имена. Описани са възрастова група, малко населено място, семейни отношения и необичайно събитие. За широката публика историята може да изглежда безименна, но хората от съответната общност да разпознаят семейството.

При медицинска информация рискът може да се усилва от рядка диагноза или характерна последователност от лечения. За здравните данни има и допълнителни условия за законосъобразно обработване по чл. 9 GDPR. При разкази за деца или семейни спорове преценете кого могат да засегнат разкритите подробности. [2, § 38; 3]

Наемането на външна организация, която заличава идентификаторите, може да помогне технически. То не замества оценката на резултата, целта и ролите на участниците.

За медицински изследвания и AI разработки е важен и Регламентът за Европейското пространство на здравни данни — EHDS. Основните правила за вторично използване започват да се прилагат поетапно от 2029 г. и предвиждат специални условия за достъп и защитена среда. Псевдонимизацията сама по себе си не дава общо разрешение за предоставяне на здравни данни на AI разработчици. [10, 11]

Какво се обсъжда в ЕС и какво важи сега

Към 2 ноември 2026 г. предложеният нов чл. 25а GDPR е част от преговорната позиция на Съвета на ЕС, приета на 21 октомври. Той още не е действащо изменение на регламента. [12]

Проектът уточнява оценката спрямо конкретна трета страна, която не може да идентифицира човека. Същевременно изрично разглежда последващото предаване към страна, способна да го идентифицира, и запазва режима за обработващите, действащи от името на администратор. Тези две уточнения са особено важни при работа с доставчици. [13]

Насоки 02/2026 на EDPB също разглеждат контекста и отделните участници. Публикуваната версия е приета за консултация; срокът за становища е приключил на 30 октомври 2026 г. [14]

Има и вече установен съдебен извод: в C-413/23 P задължението на администратора да информира за получателите се оценява към събирането на данните и от неговата гледна точка. Последващата псевдонимизация не заличава това задължение. [5]

За ръководителя практическата задача още днес е да изисква обоснована оценка преди споделянето, вместо да разчита на етикета „обезличено“.

Шест въпроса преди да разрешите споделянето

Следният списък е управленски ориентир за първоначална проверка:

1. Какви сведения остават? Прегледайте кодове, дати, местоположения, длъжности, свободен текст и съдържание в приложенията.
2. Кой ще получи данните и в каква роля? Изяснете дали действа от ваше име, използва ги за собствени цели или ги предоставя нататък.
3. С какво може да ги съпостави? Включете собствените му системи, достъпната външна информация и реалистичните пътища до допълнителни сведения.
4. Може ли задачата да се изпълни с по-малко данни? Разгледайте обобщаване, по-общи категории или изцяло измислени примери.
5. Уредено ли е обработването? Проверете целта, основанието, необходимата информация за хората, договорите, достъпа и съхранението.
6. Кой е направил и документирал оценката? При съмнение включете отговорния за процеса, IT и специалиста по защита на данните, преди файлът да напусне организацията.

Когато обработването вероятно поражда висок риск за правата и свободите на хората, се изисква предварителна оценка на въздействието върху защитата на данните — DPIA. Не всяко изпращане на файл изисква DPIA; общият списък по-горе също не я замества. [4]

По-широките организационни пропуски са разгледани в материала за честите грешки при прилагане на GDPR.

Кое обучение е подходящо за вашия екип

Полезно упражнение за ръководители е да дадат на екипа един и същ примерен файл и да попитат: има ли лични данни, кой може да разпознае хората и на кого може да се изпрати? Разминаването в отговорите показва какво трябва да се изясни в правилата и подготовката на служителите.

НИТ предлага обучения според задачите и подготовката на участниците:

Нужда на екипа	Подходящо обучение
Общи знания за понятията, основанията, правата и организацията на работата	GDPR регламент за защита на личните данни
Свързване на правилата с техническите мерки и управлението на достъпа	Пакет GDPR и Технологични аспекти при защитата на лични данни
Надграждане на вече придобити основи и по-сигурна работа с AI и външни платформи	GDPR за напреднали — Европейски промени и безопасна употреба на AI

Ако екипът ви вече работи с клиентски документи, външни доставчици и AI, разгледайте програмата на GDPR за напреднали. Пакетът включва два самостоятелни онлайн курса, насочени към практическите проблеми на защитата на данните и безопасната употреба на AI. Подходящ е и за мениджъри, HR, IT и маркетингови екипи.

За обучение на екип изпратете фирмено запитване до НИТ с броя участници и отделите, които работят с лични данни.

Често задавани въпроси

Телефонният номер лични данни ли е?

Да, когато се отнася до идентифицирано или идентифицируемо физическо лице. Не е необходимо да знаете името му. Общ фирмен номер не е непременно лични данни. Допустимостта на рекламно обаждане се оценява отделно. [1, 6, 7]

Достатъчно ли е да премахнем имената от Excel файл?

Не. Трябва да се проверят останалите колони, свободният текст, скритите листове и информацията, с която получателят може да съпостави записите. Изводът зависи от целия предоставян набор и конкретния контекст. [3]

Можем ли да качим псевдонимизирани данни в AI?

Псевдонимизацията може да намали риска, но сама по себе си не разрешава качването. Проверете възможността за идентификация, целта и основанието за обработване, ролята и условията на доставчика и вътрешните правила. [2, 4, 8]

Нужен ли е еднакъв GDPR курс за всички служители?

Общите понятия могат да бъдат споделена основа, а упражненията и надграждането да следват работата на екипа. HR работи с кандидати и служители, IT прилага техническите мерки, маркетингът използва контакти и идентификатори, а ръководителите одобряват процесите и доставчиците. Това е практична препоръка за планиране на подготовката.

Източници към статията

1. Европейска комисия — обяснение и примери за лични данни.
2. EDPB — Насоки 02/2026 за анонимизацията, версия за консултация от 7 юли 2026 г., по-специално § 15 и пример 6.
3. EDPB — кратко ръководство за оценка на анонимността, октомври 2026 г..
4. Европейска комисия — задължения при обработване на лични данни.
5. Съд на ЕС — C-413/23 P, решение от 4 септември 2025 г., т. 75–86 и 111–113.
6. EDPB — основни понятия за малкия бизнес.
7. Европейска комисия — използване за маркетинг на данни от трета страна.
8. Европейска комисия — правни основания за обработване.
9. Европейска комисия — принципи на обработването.
10. Европейска комисия — EHDS и срокове за прилагане.
11. Европейска комисия — вторично използване на здравни данни.
12. Съвет на ЕС — позиция по Digital Omnibus от 21 октомври 2026 г..
13. Съвет на ЕС — мандат ST 14756/26, печатни страници 140–141, предложен чл. 25а.
14. EDPB — срок и статус на консултацията по Насоки 02/2026.