Безпека даних при впровадженні ШІ: що можна передавати моделям, а що ні

«А куди підуть наші дані?» Це питання ми чуємо на кожній першій зустрічі. І правильно. Бо найгірше, що можна зробити, — це скопіювати договір з клієнтом у публічний чат-бот «просто щоб він зробив короткий зміст».

Розберемося, як це робиться нормально.

1. Почніть з класифікації даних

Не всі дані однакові. Перш ніж щось автоматизувати, розкладіть їх по полицях:

• Публічні: каталог, ціни на сайті, відкриті статті. Тут ризиків майже немає.
• Внутрішні: регламенти, інструкції, листування. Неприємно, якщо витечуть, але не катастрофа.
• Персональні дані: імена, телефони, адреси клієнтів і працівників. Тут діє закон, і поводитися з ними треба відповідно.
• Комерційна таємниця: ціни для ключових клієнтів, фінансові звіти, умови договорів. Найчутливіша категорія.

Для кожної категорії — свої правила. І ці правила треба зафіксувати до старту, а не після.

2. Три варіанти розміщення

Хмарні API великих постачальників. Найпотужніші моделі, мінімум інфраструктури. Важливий нюанс: умови використання даних у бізнес-API і в безкоштовному публічному чаті — різні. Перш ніж передавати щось чутливе, треба уважно прочитати умови конкретного постачальника і обрати відповідний тариф.

Локальні моделі на вашому сервері. Дані взагалі не виходять за ваш контур. Відкриті моделі сьогодні цілком годяться для багатьох задач: класифікація, витягування полів, пошук по документах. Платите за це залізом і підтримкою.

Гібрид. Найчастіше найрозумніший варіант. Чутливе обробляється локально або знеособлюється, а складні задачі з нечутливими даними йдуть у потужнішу хмарну модель.

3. Практичні правила, які працюють

• Знеособлення. Перш ніж відправити текст у зовнішню модель, замініть імена, телефони і номери рахунків на мітки. Модель отримає суть, а не персональні дані.
• Права доступу. Корпоративний помічник показує співробітнику тільки ті документи, до яких у нього і так є доступ.
• RAG замість донавчання. Ваші документи лежать у вашій базі, а модель отримує лише потрібний фрагмент для конкретної відповіді. Детально — у статті що таке RAG.
• Журнал дій. Кожен запит, відповідь і виклик інструменту записуються. Якщо щось пішло не так, видно, що саме і коли.
• Ключі тільки на сервері. API-ключі ніколи не потрапляють у браузер чи мобільний застосунок.
• NDA. Перш ніж заглиблюватися у ваші бази, підписуємо угоду про нерозголошення, а тестуємо на синтетичних або знеособлених даних.

4. Чого точно не робити

• Не копіювати чутливі документи в безкоштовні публічні чати.
• Не давати ШІ-агенту права, ширші за ті, що реально потрібні для задачі.
• Не підключати модель напряму до продуктивної бази без проміжного шару перевірок.

Безпека — це не окрема опція, яку додають наприкінці. Її закладають в архітектуру з першого дня. Розберемо ваші дані й підберемо варіант розміщення під час аудиту бізнес-процесів. Як усе це влаштовано в корпоративній базі знань, читайте на сторінці Корпоративна база знань та RAG.