Как да защитя данните си при AI?

Най-сигурният начин да защитиш данните си при AI е комбинация от три неща: (1) минимизация и редакт на това, което изпращаш, (2) контрол върху настройките и договора с доставчика, и (3) вътрешни правила за достъп, логване и ретенция. При AI поверителността (privacy) не е настройка, а дисциплина: какво споделяш, с кого и за колко време. Ако следваш процеса по-долу, ще можеш да използваш AI инструменти, без да превръщаш чат прозореца в „изтичане на данни“.

Въведение

AI инструменти (чатботи, генератори на текст/код, анализ на документи, LLM) често са „черна кутия“ за потребителя: копираш текст, получаваш отговор. Реалният риск обаче е по-широк от „някой да хакне“ доставчика. Риск е и:

  • изпращане на лични данни, които не са нужни за задачата
  • съхранение на история/логове по-дълго от очакваното
  • използване на данни за обучение/подобряване (ако няма ясна забрана)
  • неясен достъп (кой в компанията вижда какво)
  • трансфери на данни към трети страни/подизпълнители

В ЕС и България обикновено рамката е GDPR (принципи като минимизация, целево ограничение, сигурност на обработването). Паралелно се въвеждат и специфични правила за AI системи (напр. EU AI Act), които увеличават фокуса върху управление на риска, прозрачност и отговорност.

Ако не би изпратил данните по имейл на непознат, не ги изпращай и в промпт.

Стъпка 1: Класифицирай данните и „забранените“ категории

Преди да ползваш AI, отговори на два въпроса:

  1. Какъв тип данни ще обработваш?
  2. Какво е най-лошото, което може да стане, ако тези данни изтекат?

Практична класификация:

  • Публични: маркетинг текстове, публични статии.
  • Вътрешни: процедури, техническа документация без клиентски данни.
  • Чувствителни: договори, цени, финансови отчети, изходен код.
  • Лични данни: имена, телефони, адреси, идентификатори.
  • Специални категории: здравни данни, биометрия, данни за деца и др.

Правило за старт:

  • публични и вътрешни данни: позволени с минимални мерки
  • чувствителни и лични данни: само след редакт/контрол и при ясни настройки/договор
  • специални категории: избягвай външен SaaS, освен ако не е изрично оценено и договорено

Стъпка 2: Избери модел на използване (SaaS, enterprise или self-hosted)

Има три реалистични пътя:

  1. Публичен SaaS акаунт
  • най-бърз старт
  • най-слаб контрол (в зависимост от доставчика)
  • подходящ за нискорискови задачи
  1. Enterprise план/договор
  • SSO, админ политики, DPA, по-ясни условия за ретенция
  • често има опции за изключване на използване за обучение
  • подходящ за екипи и фирмени процеси
  1. 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 отива само минимален, редактнат контекст.

Какво да правиш при инцидент или съмнение за изтичане

  1. Спри/ограничи достъпа (изключи интеграции, смени ключове, отнеми права).
  2. Запази доказателства: кой, кога, какъв тип данни са засегнати.
  3. Оцени риска за засегнатите лица и бизнеса.
  4. Уведоми вътрешните роли (DPO, security, legal).
  5. Прегледай причината: липсваща политика, грешен промпт, слаби настройки, грешен доставчик.

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

Бърз чеклист: 10 правила за prompt хигиена

  • Не включвай идентификатори (ЕГН, номера на договори, серийни номера), освен ако не е абсолютно необходимо.
  • Не качвай оригинални файлове, когато можеш да изпратиш кратък, редактнат откъс.
  • Замествай имена/имейли/телефони с маркери.
  • Изрично указвай: „не повтаряй лични данни в отговора“.
  • Давай контекст само колкото е нужен за задачата.
  • Не питай AI да „пази“ информация за по-късно; третирай историята като лог.
  • Никога не споделяй ключове, пароли и токени.
  • За чувствителни теми използвай одобрен инструмент/акаунт (enterprise) и политика.
  • Преглеждай отговора преди да го препратиш към клиент/колега.
  • Ако не си сигурен, избери по-безопасния вариант: минимизация или вътрешна обработка.

Бележка: Ако работиш в регулиран сектор (здраве, финанси, образование) или обработваш данни на деца, приеми по-висок стандарт по подразбиране. Ползвай одобрени инструменти, прави оценка на риска и документирай решенията си. Когато се колебаеш дали даден текст съдържа лични данни, третирай го като лични данни и редактни преди изпращане. Това е по-бавно, но е значително по-безопасно в дългосрочен план.

Допълнително.