Как да защитя данните си при AI?
Най-сигурният начин да защитиш данните си при AI е комбинация от три неща: (1) минимизация и редакт на това, което изпращаш, (2) контрол върху настройките и договора с доставчика, и (3) вътрешни правила за достъп, логване и ретенция. При AI поверителността (privacy) не е настройка, а дисциплина: какво споделяш, с кого и за колко време. Ако следваш процеса по-долу, ще можеш да използваш AI инструменти, без да превръщаш чат прозореца в „изтичане на данни“.
Въведение
AI инструменти (чатботи, генератори на текст/код, анализ на документи, LLM) често са „черна кутия“ за потребителя: копираш текст, получаваш отговор. Реалният риск обаче е по-широк от „някой да хакне“ доставчика. Риск е и:
- изпращане на лични данни, които не са нужни за задачата
- съхранение на история/логове по-дълго от очакваното
- използване на данни за обучение/подобряване (ако няма ясна забрана)
- неясен достъп (кой в компанията вижда какво)
- трансфери на данни към трети страни/подизпълнители
В ЕС и България обикновено рамката е GDPR (принципи като минимизация, целево ограничение, сигурност на обработването). Паралелно се въвеждат и специфични правила за AI системи (напр. EU AI Act), които увеличават фокуса върху управление на риска, прозрачност и отговорност.
Ако не би изпратил данните по имейл на непознат, не ги изпращай и в промпт.
Стъпка 1: Класифицирай данните и „забранените“ категории
Преди да ползваш AI, отговори на два въпроса:
- Какъв тип данни ще обработваш?
- Какво е най-лошото, което може да стане, ако тези данни изтекат?
Практична класификация:
- Публични: маркетинг текстове, публични статии.
- Вътрешни: процедури, техническа документация без клиентски данни.
- Чувствителни: договори, цени, финансови отчети, изходен код.
- Лични данни: имена, телефони, адреси, идентификатори.
- Специални категории: здравни данни, биометрия, данни за деца и др.
Правило за старт:
- публични и вътрешни данни: позволени с минимални мерки
- чувствителни и лични данни: само след редакт/контрол и при ясни настройки/договор
- специални категории: избягвай външен SaaS, освен ако не е изрично оценено и договорено
Стъпка 2: Избери модел на използване (SaaS, enterprise или self-hosted)
Има три реалистични пътя:
- Публичен SaaS акаунт
- най-бърз старт
- най-слаб контрол (в зависимост от доставчика)
- подходящ за нискорискови задачи
- Enterprise план/договор
- SSO, админ политики, DPA, по-ясни условия за ретенция
- често има опции за изключване на използване за обучение
- подходящ за екипи и фирмени процеси
- Self-hosted/частен модел
- най-висок контрол върху данните
- повече разходи и поддръжка
- подходящ при висок риск, регулаторни ограничения или строги клиентски договори
Не избирай архитектура по мода; избери по риск и регулации.
Стъпка 3: Провери настройките и условията (какво се пази, колко дълго, за какво се ползва)
Минимални точки за проверка:
- Ретенция: пази ли се история на чатове? може ли да се изтрие централизирано?
- Обучение/подобряване: използват ли се данните за training? има ли „opt-out“?
- Подизпълнители: има ли трети страни и къде са те?
- Регион: къде се обработват данните (ЕС/извън ЕС)?
- Достъп: кой от екипа има достъп до историята и файловете?
За организации:
- DPA (Data Processing Agreement) и ясни роли (controller/processor).
- Ако има трансфер извън ЕИП: правни механизми и оценка на риска.
- DPIA, ако обработването е високорисково (напр. масово, чувствителни данни, системно наблюдение).
Това не е юридически съвет; прави го с DPO/юрист.
Стъпка 4: Минимизирай и редактни входа (най-силната защита)
Най-ефективната защита е да не изпращаш чувствителни данни.
Техники (подреди ги по сила):
- Не изпращай: замени конкретни данни с описание.
- Редакт: премахни/маскирай PII и идентификатори.
- Псевдонимизация: замени със стабилни маркери (
CLIENT_001), а таблицата за съпоставяне дръж само вътрешно.
- Агрегиране: изпращай статистики, не сурови редове.
- Ограничен контекст: изпращай само релевантен откъс (50-200 реда), не целия документ.
Пример: вместо
„Ето договора на Иван Петров, ЕГН ..., адрес ..., анализирай.“
използвай
„Ето откъс от договор, редактнат. Намери неясни клаузи и предложи въпроси към юрист.“
Мини-шаблон за безопасен промпт:
- Контекст: кратко (без идентификатори)
- Цел: какво искаш
- Ограничения: „не изписвай лични данни“, „ако липсва информация, кажи“
Най-доброто DLP правило е: „AI вижда само това, което му трябва“.
Стъпка 5: Защити достъпа (акаунти, ключове, роли)
- Включи 2FA/SSO.
- Забрани споделяне на акаунти.
- Създай отделни работни пространства/проекти по екипи.
- Ако има API ключове: дръж ги в secret manager; никога в чат.
- Принцип на най-малката привилегия: хората виждат само това, което им трябва.
Практика за екипи: „prompt библиотека“ с одобрени шаблони. Така намаляваш вероятността някой да пусне чувствителни данни в импровизиран промпт.
Стъпка 6: Управлявай изхода и логовете (output governance)
Дори да пазиш входа, изходът може да бъде проблем:
- моделът може да „включи“ части от контекста в отговор
- може да създаде неверни твърдения (халюцинации)
- може да предложи опасни действия (особено при код/скриптове)
Мерки:
- Human review за важни решения (финанси, здраве, правни текстове).
- Филтри за PII в output (регекс/классификатор).
- Логване с минимизация: логвай метаданни (време, размер), не пълен текст, ако не е нужно.
- Ретенция: автоматично изтриване след определен период.
Стъпка 7: Направи политика и обучение (най-честият пробив е човек)
Създай 1 страница „AI правила“:
- какво е забранено да се качва/праща
- как се прави редакт
- как се докладва инцидент
Обучи хората с реални примери:
- „лош“ промпт с PII
- „добър“ промпт с placeholders
- типични social engineering атаки (вкл. AI-генерирани)
Съвети за по-добри резултати
- Започни с нискорискови случаи (общи текстове, публични данни).
- Ако трябва да анализираш документ, редактни го и изпрати само откъс.
- Пази историята на чатове като чувствителна информация.
- Прави периодичен преглед на настройките и договорите.
- За вътрешни знания ползвай RAG (достъп до база знания) вместо да копираш цели файлове.
Чести грешки, които да избягваш
- Копиране на цели договори/таблици с лични данни в промпт.
- Изпращане на пароли/API ключове „за да помогне AI да дебъгне“.
- Ползване на публични инструменти за клиентски данни без договор и политика.
- Липса на ретенция и контрол на историята.
- Вяра, че „анонимизация“ = махане на името (често не е достатъчно).
Източници и полезни линкове (проверени 2024–2026)
Практични сценарии: как да ползваш AI без да даваш лични данни
Ако си физическо лице
- За CV/мотивационно писмо: пращай структура и примерни изречения, но не пращай ЕГН, точен адрес, номера на документи.
- За здравни въпроси: описвай симптоми общо и търси насоки за въпроси към лекар, без да изпращаш медицински документи и изследвания, ако не е нужно.
- За финансови анализи: пращай агрегирани суми и категории, не пълни банкови извлечения и IBAN-и.
Ако си екип/компания
- Създай „вътрешен“ режим: AI се ползва първо за публични/вътрешни документи без клиентски данни.
- За клиентски казуси: използвай редактнати примери или синтетични данни за обучение на процеса.
- За код: никога не качвай
.env, ключове и сертификати; използвай placeholders и минимални репродукции на проблема.
Технически мерки, които дават най-много стойност
- DLP/редакт преди изпращане: автоматично търсене на имена, имейли, телефони, идентификатори и маскиране.
- Криптиране и сегментация: файловете с оригиналните данни стоят в отделно хранилище с строг достъп; към AI отива само редактнатият „payload“.
- Изолация на инструменти (tools): ако LLM има достъп до вътрешни системи, изпълнението трябва да е sandbox-нато и с allowlist; иначе рискът от prompt injection расте.
- Лимити и наблюдение: rate limits, размери на файлове, аларми при необичайно използване.
Добрият процес е: оригиналните данни стоят заключени, а към AI отива само минимален, редактнат контекст.
Какво да правиш при инцидент или съмнение за изтичане
- Спри/ограничи достъпа (изключи интеграции, смени ключове, отнеми права).
- Запази доказателства: кой, кога, какъв тип данни са засегнати.
- Оцени риска за засегнатите лица и бизнеса.
- Уведоми вътрешните роли (DPO, security, legal).
- Прегледай причината: липсваща политика, грешен промпт, слаби настройки, грешен доставчик.
Ако си организация, може да имаш и регулаторни задължения при определени типове инциденти. Не отлагай юридическата консултация, когато става дума за лични данни.
Бърз чеклист: 10 правила за prompt хигиена
- Не включвай идентификатори (ЕГН, номера на договори, серийни номера), освен ако не е абсолютно необходимо.
- Не качвай оригинални файлове, когато можеш да изпратиш кратък, редактнат откъс.
- Замествай имена/имейли/телефони с маркери.
- Изрично указвай: „не повтаряй лични данни в отговора“.
- Давай контекст само колкото е нужен за задачата.
- Не питай AI да „пази“ информация за по-късно; третирай историята като лог.
- Никога не споделяй ключове, пароли и токени.
- За чувствителни теми използвай одобрен инструмент/акаунт (enterprise) и политика.
- Преглеждай отговора преди да го препратиш към клиент/колега.
- Ако не си сигурен, избери по-безопасния вариант: минимизация или вътрешна обработка.
Бележка: Ако работиш в регулиран сектор (здраве, финанси, образование) или обработваш данни на деца, приеми по-висок стандарт по подразбиране. Ползвай одобрени инструменти, прави оценка на риска и документирай решенията си. Когато се колебаеш дали даден текст съдържа лични данни, третирай го като лични данни и редактни преди изпращане. Това е по-бавно, но е значително по-безопасно в дългосрочен план.
Допълнително.