Як захистити дані користувачів у вашому застосунку на ШІ (без команди безпеки)

Знайома нам коуч зібрала застосунок для відстеження клієнтів за допомогою конструктора на ШІ за вихідні. Нотатки сесій, цілі, контрольні точки прогресу — усе, що вона раніше тримала в блокноті, тепер з пошуком і впорядковане. Воно спрацювало так добре, що двоє друзів-коучів попросили теж ним користуватися.

Ось коли її осяяло: вона більше не тримала власні нотатки. Вона тримала чужі нотатки про їхніх клієнтів — деталі здоров’я, особисті труднощі, імена. Якби ці дані витекли, це було б не її соромом. Це було б їхнім.

Вам не потрібна команда безпеки, щоб упоратися з цим відповідально. Вам потрібні три звички й готовність поставити своєму конструктору на ШІ кілька прямих запитань. Цей гайд охоплює, як захистити дані користувачів у вашому застосунку на ШІ на рівні, що справді важить для маленького продукту.

Почніть із помічання того, які дані користувачів ви насправді тримаєте

Більшість будівників це недооцінює. «У мене просто форма реєстрації» зазвичай означає, що у вас є:

Адреси e-mail — достатньо, щоб спамити чи фішити когось.
Імена, пов’язані з поведінкою — що вони купили, що написали, коли входять.
Усе, що ваші користувачі вводять у поля вільного тексту — а люди вводять будь-що в поле нотаток: номери телефонів, медичні деталі, зарплати, скарги на боса.

Витратьте десять хвилин і запишіть кожен фрагмент інформації, який ваш застосунок зберігає про людину. Не поля бази даних — людський сенс. «E-mail», «які добавки вони приймають», «нотатки, які тренер про них написав». Цей список — ваша поверхня відповідальності. Усе інше в цьому дописі — про те, як зробити її меншою й безпечнішою.

Звичка 1: Збирайте менше

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

Пройдіться списком, який ви щойно склали, і запитайте про кожен пункт: чи я цим користуюся? Застосунок коуча просив дату народження при реєстрації, бо шаблон реєстрації конструктора на ШІ її містив. Вона ніколи ніде її не використовувала. Одне речення її конструктору на ШІ — «прибери дату народження з реєстрації й видали колонку» — і ціла категорія чутливих даних зникла.

Поширені речі, які застосунки збирають і ніколи не використовують: дати народження, номери телефонів, фізичні адреси, стать, «звідки ви про нас дізналися». Якщо ви не користуєтеся цим цього місяця, ви завжди можете попросити це пізніше. Ви не можете «відвитекти» це.

Звичка 2: Контролюйте, хто що може бачити

Є дві версії цього запитання, і вам потрібні обидві.

Усередині застосунку: чи може один користувач бачити дані іншого? Якщо у вашого застосунку є клієнти й коучі, чи може клієнт A коли-небудь бачити нотатки клієнта B? Ми написали цілий гайд про дозволи користувачів у вашому застосунку на ШІ, але коротка версія: опишіть правило своєму конструктору на ШІ простими словами («коуч бачить лише своїх клієнтів; клієнти бачать лише себе»), а потім протестуйте це самі з двома акаунтами. Увійдіть як один користувач, спробуйте дотягнутися до даних іншого, клікаючи навколо. П’ять хвилин, два тестові акаунти. Цей єдиний тест ловить найпоширеніший витік у маленьких застосунках.

Поза застосунком: хто може бачити саму базу даних? Це ви, платформа вашого конструктора на ШІ й кожен, з ким ви ділилися логінами. Що приводить нас до запитань.

Звичка 3: Поставте своєму конструктору ці п’ять запитань

Вам не треба глибоко розуміти відповіді. Вам треба запитати, і відповіді мають бути впевненими «так». Вставте ці запитання у свій конструктор застосунків на ШІ по одному за раз:

«Чи зберігаються паролі користувачів хешованими, чи будь-хто може їх прочитати?» Єдина прийнятна відповідь містить слово «хешовані». Якщо ваш застосунок зберігає паролі, які будь-хто може прочитати, виправте це сьогодні — зазвичай це виправлення одним промптом, і більшість сучасних конструкторів роблять це правильно за замовчуванням.
«Чи з’єднання із застосунком зашифроване (HTTPS)?» Шукайте замочок у власному браузері. Якщо адреса вашого застосунку починається з https://, із цим ви закінчили.
«Якби хтось дістав файл бази даних, чи зміг би він прочитати чутливі поля?» Це про шифрування в стані спокою. Більшість хостинг-платформ роблять це автоматично — запитайте все одно й запишіть відповідь.
«Які сторонні сервіси отримують дані користувачів?» Поштові інструменти, аналітика, платіжні процесори. Ви їх не прибираєте — ви робите свій список повним, бо кожен сервіс, що тримає дані ваших користувачів, — частина вашої поверхні відповідальності.
«Чи є резервна копія і хто має до неї доступ?» Резервні копії — це копії ваших даних, а копії теж треба захищати. (Якщо ви взагалі не налаштували резервні копії, почніть тут.)

Збережіть відповіді в документі. Цей документ — початок вашої безпекової позиції, і ви будете раді, що він існує, коли клієнт — чи юрист клієнта — уперше запитає.

Коли хтось каже «видаліть мої дані»

Хтось зрештою скаже, і закон у більшості місць (GDPR у Європі, схожі правила деінде) каже, що ви маєте справді це зробити. Вирішіть зараз, якою буде ваша відповідь:

Чи можете ви видалити одного користувача й усе, пов’язане з ним? Попросіть свій конструктор на ШІ додати це — «зроби адмінську дію, що видаляє користувача й усі його дані» — перш ніж воно вам знадобиться під дедлайном.
Чи видалення його в застосунку також прибирає його з вашого поштового інструмента й аналітики? Перевірте свій список із запитання 4.
Резервні копії все одно деякий час міститимуть його. Це нормально й загалом гаразд — просто знайте це, щоб ви могли сказати це чесно.

Відповісти на запит про видалення за день, бо ви підготувалися, виглядає професійно. Метушитися два тижні виглядає саме як те, чим воно є.

Напишіть сторінку конфіденційності простою мовою

Пропустіть наразі згенеровану юридичну каламуть на 4000 слів. Напишіть п’ять чесних речень: що ви збираєте, навіщо, хто ще цього торкається (ваш поштовий інструмент, ваш платіжний процесор), як довго ви це зберігаєте і як попросити видалення. Поставте це на /privacy і пов’яжіть зі сторінки реєстрації.

Це не юридична консультація, і якщо ви маєте справу зі справді чутливими даними — здоров’я, діти, фінанси — витратьте гроші на годину з юристом. Але чітка, чесна сторінка б’є вражаючу на вигляд, яку ніхто не може прочитати, а написання її змушує вас справді знати власні відповіді.

Планка нижча, ніж ви боїтеся, і вища за нуль

Ви не захищаєтеся від держав-націй. Ви захищаєтеся від нудних, поширених збоїв: лишене поле даних, якого нікому не треба було, правило дозволів, яке ніхто не протестував, таблиця паролів, яку хтось забув захешувати. Захист даних користувачів на цьому рівні — не спеціалізована навичка; кожен із цих збоїв можна виправити промптом простою мовою й п’ятихвилинним тестом.

Коуч із початку зробила все це за один день: видалила два невикористовувані поля, провела тест із двома акаунтами (і зловила один витік — клієнти бачили імена одне одного у випадному меню), поставила п’ять запитань, написала сторінку конфіденційності. Її застосунок після цього не виглядав інакше. Але коли її подруга запитала «ця штука безпечна для моїх нотаток про клієнтів?», у неї була справжня відповідь.

Витратьте цей день. Ваші користувачі дали вам свої дані на довірі — ось як виглядає її збереження.