Корпоративна політика використання ШІ: що має бути в документі для працівників

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

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

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

Призначення й межі політики

Перший розділ документа відповідає на питання «кого і що це стосується». Без нього працівник не зрозуміє, чи поширюються правила на його задачу.

Тут варто прямо записати:

• На кого поширюється. Штатні працівники, підрядники з доступом до робочих систем, стажисти. Якщо для різних груп правила різні, це треба сказати.
• Які дані охоплені. Будь-яка робоча інформація компанії, клієнтів і партнерів, незалежно від того, на якому пристрої працює людина.
• Які продукти охоплені. Чат-асистенти, ШІ-функції в офісних програмах, генератори зображень, помічники для коду, а також ШІ-функції всередині CRM чи сервісів підтримки.
• Які процеси. Підготовка текстів, аналіз даних, відповіді клієнтам, написання коду, переклад.
• Хто власник документа. Конкретна роль, яка відповідає за зміст, відповідає на питання і вносить зміни.
• Як часто переглядається. Наприклад, раз на квартал і позапланово після змін у сервісах чи інцидентів.

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

Перелік дозволених інструментів

Найкорисніший розділ політики для працівника: короткий реєстр сервісів, якими можна користуватися для роботи. Загальне «можна користуватися ChatGPT» або «можна Copilot» не працює, бо в одного бренду можуть бути різні продукти з різними умовами.

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

Для кожного сервісу в реєстрі варто вказати:

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

Матриця даних

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

Навчальний приклад матриці

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

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

Для генеративного ШІ важливі як ризик розкриття даних, так і ризик підставлених інструкцій у матеріалах, які читає система (prompt injection). Матриця визначає, які дані дозволено передавати сервісу, але сама не захищає від підставлених інструкцій. Для автоматизованих дій потрібні окремі перевірки вхідних матеріалів, обмеження доступу та підтвердження людини.

Правила перевірки результату

Друга частина ризику стосується не того, що передали в ШІ, а того, що з нього отримали. Один із ризиків генеративного ШІ — конфабуляція: впевнено подана, але хибна інформація. Модель може вигадати цифру, посилання, пункт договору чи функцію продукту і подати це переконливо.

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

• Факти й цифри. Звірити з первинними даними компанії або першоджерелом.
• Розрахунки. Повторити ключові обчислення в таблиці чи іншим способом.
• Код. Пройти звичайний процес рев'ю і тестування, як будь-який інший код.
• Посилання і цитати. Відкрити кожне посилання й переконатися, що воно існує і підтверджує сказане.
• Зовнішні обіцянки. Будь-які строки, ціни, знижки чи гарантії клієнту погоджуються так само, як без ШІ.

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

Дії та інциденти

Окремий розділ потрібен для ситуацій, коли ШІ не лише пише текст, а виконує дію: надсилає лист, змінює запис у CRM, публікує пост, створює рахунок. Тут ризик вищий, бо помилка одразу виходить назовні.

Запишіть у політиці:

• Які дії потребують підтвердження людини. Наприклад, надсилання листів клієнтам, зміна статусу угоди, будь-які знижки чи повернення коштів.
• Хто має право вмикати автоматичні дії. Не кожен працівник, а власник процесу разом з відповідальним за систему.
• Як зупинити процес. Хто може вимкнути автоматизацію і як це зробити швидко.

Порядок дій при інциденті має бути простим, щоб людина не вагалася:

1. Припинити дію: не надсилати, не публікувати, не продовжувати діалог із сервісом.
2. Повідомити призначену відповідальну особу через указаний канал.
3. Зафіксувати, що сталося: який сервіс, які дані, коли, хто міг отримати доступ.
4. Не намагатися самостійно «приховати» помилку, видаливши сліди.

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

Навчальний приклад: текст для адаптації

Фрагмент нижче можна вставити в політику як основу, але лише після заміни дужок реальними даними вашої компанії. Це не готовий юридичний акт.

> Робочі дані обробляються лише в схвалених сервісах через корпоративний доступ: [перелік сервісів і тарифів]. Паролі, ключі доступу та інші секрети не включаються в запити до жодного ШІ-сервісу. Результати, які впливають на клієнта або облік, перевіряє власник процесу: [роль]. Надсилання листів клієнтам і зміни в CRM з використанням ШІ виконуються лише після підтвердження людиною. У разі помилкового передавання даних працівник припиняє дію і повідомляє [відповідальна особа, канал зв'язку].

Навчання і перегляд політики

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

Короткі приклади замість лекції. Для кожного відділу підготуйте три-п'ять прикладів «можна / потрібно погодити / не можна» на їхніх реальних задачах. Менеджер з продажу має побачити свій сценарій, а не абстрактний.

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

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

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

Зворотний зв'язок. Якщо правило постійно обходять, причина може бути в самому правилі. Можливо, воно занадто суворе для реальної задачі або немає схваленого інструмента для поширеної потреби. Такі сигнали мають потрапляти до власника політики.

Що зробити на своєму процесі

Щоб перейти від статті до першої робочої версії:

1. Призначте власника політики та запишіть дату першого перегляду.
2. Зберіть, якими ШІ-сервісами працівники користуються вже зараз, без покарань за чесні відповіді.
3. Складіть реєстр схвалених сервісів із тарифом, способом доступу, адміністратором і датою перевірки умов.
4. Адаптуйте матрицю даних під ваші категорії та погодьте її з тим, хто відповідає за персональні дані й договори.
5. Визначте, які дії з ШІ потребують підтвердження людини, і хто приймає повідомлення про інциденти.
6. Підготуйте для кожного відділу три-п'ять прикладів на реальних задачах і проведіть коротке ознайомлення.
7. Передайте юристу питання, що стосуються вашої юрисдикції, договорів і дисциплінарних наслідків.

Часті запитання