Політика використання ШІ для малого бізнесу: готова структура

У невеликій компанії ШІ часто з’являється раніше за правила: хтось підсумовує зустріч, хтось завантажує договір у чат, а хтось підключає генератор відповідей до пошти. Повна заборона зазвичай штовхає це в тінь. Безумовний дозвіл залишає працівників сам на сам із ризиком.

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

1. Мета й сфера дії

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

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

Не копіюйте довге визначення «штучного інтелекту», яке ніхто не зможе застосувати. Додайте приклади: чат-асистент, транскриптор, генератор зображень, функція в офісному пакеті, AI-плагін у редакторі коду.

2. Класифікація даних

Простий поділ допомагає більше, ніж загальне «не завантажуйте чутливе»:

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

Налаштуйте категорії під власні договори. Наведіть приклади назв файлів і полів, а не лише абстрактні слова. Дані треба мінімізувати: навіть у дозволений сервіс передавайте лише те, що потрібне для задачі.

3. Дозволені інструменти й акаунти

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

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

4. Людська відповідальність і перевірка

Вихід AI вважається чернеткою, доки відповідальна людина його не перевірила. Політика має назвати мінімальну перевірку для різних результатів:

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

Автор або виконавець відповідає за фінальний результат. Фраза «так сказала модель» не є поясненням рішення.

5. Заборонені сценарії

До базового списку варто включити:

• введення паролів, токенів і секретних ключів;
• маскування використання AI там, де договір вимагає розкриття;
• створення фальшивих відгуків, доказів, особистостей або цитат;
• імітацію голосу чи обличчя без чіткої згоди й законної мети;
• автоматичну публікацію, оплату або видалення без затверджених обмежень;
• використання результату з явними ознаками порушення авторських чи інших прав;
• обхід безпекових налаштувань заради зручності.

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

6. Прозорість перед клієнтом і читачем

Розкриття потрібне, коли AI суттєво вплинув на результат, коли це передбачено договором або коли мовчання може ввести людину в оману. Формулювання має бути конкретним: яку частину створювала система і що перевіряла людина.

Не обов’язково додавати банер до кожного виправлення граматики. Важливі контекст і очікування аудиторії. Синтетичне зображення реальної події, автоматична порада клієнту або AI-аналіз персональних даних потребують значно більшої уваги.

7. Інциденти й повідомлення

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

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

8. Навчання й регулярний перегляд

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

Переглядайте реєстр і політику щонайменше раз на пів року, а також після нового важливого сервісу, зміни договору чи інциденту. Орієнтуйтеся на ризик конкретного використання, як радять NIST AI RMF та принципи OECD, а для роботи в ЄС окремо перевіряйте застосовність AI Act.

Хороша політика може вміститися на кількох сторінках. Її сила не в юридично складній мові, а в тому, що працівник справді знайде відповідь до завантаження файлу, а не після інциденту.