Copilot і політики збереження: що має знати кожен адміністратор M365

By Mirko Peters · 2026-03-17 · Updated 2026-03-24

Microsoft 365 Copilot: політики збереження. Дізнайтеся про політики збереження Microsoft 365 для чатів Copilot і Teams та взаємодій із Copilot.

Automatically translated with AI from the original post. Read the English original

Якщо ви адміністратор у світі Microsoft 365, ви вже знаєте, що ставки у сфері відповідності вимогам зараз вищі, ніж будь-коли. Коли Microsoft Copilot та інші інструменти на основі ШІ вже вбудовані безпосередньо в M365, управління політиками збереження — це не формальність, а основа того, щоб ваша організація була захищеною, відповідала вимогам і була готовою до аудиту.

Copilot працює не лише з документами чи електронними листами. Він взаємодіє з вашими даними по-новому, а це створює унікальні ризики, пов’язані з життєвим циклом даних, управлінням і юридичними аспектами. Що змінилося? Багато чого. Класичні засоби контролю збереження, які добре працювали для Exchange або SharePoint, мають еволюціонувати, щоб охоплювати те, як Copilot зберігає, повторно використовує та видаляє дані взаємодій. Ігнорування цього може призвести до юридичних ризиків, витоків даних або порушень регуляторних вимог.

Адміністраторам сьогодні потрібно узгоджувати політики збереження в Copilot не лише для захисту даних і аудитів відповідності, а й для того, щоб уникнути неприємних сюрпризів, зокрема «тіньових» даних і непомічених прогалин у політиках. Ефективні стратегії управління Copilot і безпечне технічне забезпечення дотримання політик можуть допомогти безпечно впровадити ШІ завдяки сильним договорам, засобам контролю доступу та вбудованій автоматизації відповідності вимогам. Давайте розберемо, що робить збереження в Copilot відмінним, і чому ви не можете залишити його на волю випадку.

1. Збереження може впливати на пропозиції моделі: Де і how довго зберігаються код або історія запитів, може змінювати контекст, який використовує Copilot, а отже, і його пропозиції, навіть для однакових запитів.
2. Корпоративне збереження може тривати довше, ніж ви очікуєте: Журнали організації та телеметрія, пов’язані з Copilot, можуть зберігатися з міркувань відповідності вимогам місяцями або роками, а не лише протягом короткого вікна налагодження.
3. Розділення персональних і корпоративних даних не є абсолютним: Навіть коли Copilot розділяє персональні та корпоративні дані, системи збереження і резервні копії можуть створювати накладні копії, які потребують політичних засобів контролю.
4. Політики збереження впливають на юридичне розслідування (discovery): Дані, які зберігає Copilot (фрагменти коду, запити, історія чатів), можуть бути доступні для пошуку в судових справах або аудитах, якщо політики збереження їх зберігають.
5. Коротке збереження зменшує видимість «навчання» моделі: Агресивні вікна видалення можуть обмежити можливість перевірити, чому Copilot зробив ті чи інші рекомендації, що ускладнює налагодження та розслідування питань безпеки.
6. Налаштування збереження можуть стати векторами атак: Неправильно налаштоване збереження (занадто довге або доступне) збільшує ризик витоку власницького коду, секретів або персональних даних, які Copilot міг побачити або записати в журнал.
7. Збереження взаємодіє з донавчанням і телеметрією: Дані, що зберігаються для телеметрії або конвеєрів донавчання, можуть впливати на майбутню поведінку моделі, якщо політика їх явно не виключає.
8. Різні функції Copilot мають різні правила збереження: Автодоповнення коду, стенограми чатів, відгуки і телеметрія часто мають окремі графіки збереження та різний юридичний режим.
9. Вибір політики збереження впливає на довіру користувачів і впровадження: Прозоре й суворе збереження значно підвищує готовність розробників використовувати Copilot у чутливих проєктах, тоді як м’яка політика знижує корпоративне впровадження.

Розуміння політик збереження в Microsoft Copilot

Політики збереження завжди були основою відповідності вимогам у Microsoft 365, але Copilot змінює правила гри. На відміну від звичайних файлів, які просто лежать без діла, Copilot створює, обробляє й зберігає нові дані взаємодій із кожним запитом користувача та кожною відповіддю, згенерованою ШІ. Дані вже не просто створюються і забуваються — вони стають активною частиною робочого процесу, постійно рухаючись новими шляхами.

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

З усіма цими змінами однієї загальної політики збереження вже недостатньо. Тепер потрібна стратегія, яка враховує міжплатформенний характер Copilot, різні типи даних і складність строків: коли починається збереження і коли потрібно примусово видаляти дані. Розглядайте це як новий шар управління Microsoft 365, який потребує постійної уваги та свідомого налаштування.

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

Основні поняття політик збереження даних Copilot

1. Визначення політик збереження для Copilot: Політики збереження визначають, як довго Copilot зберігає запити користувачів, результати, згенеровані ШІ, та метадані взаємодій. Вони створені для того, щоб дані не зберігалися довше, ніж необхідно з міркувань відповідності вимогам, безпеки або внутрішніх політик організації.
2. Типи даних Copilot, на які поширюються політики: До поширених типів даних належать запити користувачів, відповіді Copilot, згенеровані ШІ, базовий контекст, зібраний для обробки, а іноді й узагальнений або згаданий вміст документів. Збереження поширюється на всі ці типи, а не лише на журнали чатів.
3. Коли починаються політики збереження? Відлік строку збереження зазвичай починається з моменту створення, тобто коли відбувається взаємодія з Copilot або коли дані зберігаються в пов’язаній прихованій папці поштової скриньки чи в репозиторії даних застосунку. Цей момент має вирішальне значення для планування видалення.
4. Принципи визначення строків політики збереження: Строки збереження Copilot повторюють строки тієї служби Microsoft 365, з якою він інтегрований, наприклад Exchange, SharePoint або Teams. Проте унікальні артефакти Copilot можуть потребувати власних явних правил строків, щоб уникнути перетинів і плутанини.
5. Застосування політик і винятки: Політики збереження можна налаштувати як лише збереження, лише видалення або збереження з подальшим видаленням. Дані Copilot мають дотримуватися цих політик, але адміністратори можуть застосовувати винятки для юридичних утримань або ситуацій з дотриманням вимог, зазвичай через Purview або пов’язані засоби керування.
6. Приклад із практики: Припустимо, в організації діє 7-річне юридичне утримання для фінансової пошти. Резюме або рекомендації Copilot, засновані на цих листах, підпадають під таке саме збереження. Якщо Copilot взаємодіє з даними з кількох робочих навантажень, узгодженість між платформами є критично важливою, щоб уникнути прогалин.
7. Інтеграція з ширшим управлінням Microsoft 365: Політики збереження для Copilot не існують ізольовано: вони працюють разом із налаштуваннями SharePoint, OneDrive та Exchange. Невідповідність між ними може створювати ризики для відповідності вимогам, тому політики слід переглядати й тестувати разом із розвитком функцій Copilot.

Процес управління життєвим циклом даних для Copilot

1. Захоплення запиту: Життєвий цикл починається, коли користувач взаємодіє з Copilot: вводить запит, створює документ або просить підсумок. Цей ввід і весь вміст, який Copilot залучає, фіксуються як запис у відповідному робочому навантаженні (наприклад, Exchange або SharePoint).
2. Зберігання даних: Після фіксації дані взаємодії зберігаються, часто в прихованій папці поштової скриньки або зашифрованій базі даних, прив’язаній до користувача чи робочого навантаження. Місце зберігання впливає на те, як застосовуються й перевіряються політики збереження.
3. Строк збереження: Після збереження дані Copilot «відлежуються» протягом визначеного строку. Його можна задати в Purview, встановивши окремі тривалості для кожного типу вмісту. Протягом цього часу дані можуть бути доступні для розслідувань або аудитів, але захищені від передчасного видалення.
4. Поточне керування та моніторинг: Адміністратори можуть відстежувати стан життєвого циклу через панелі відповідності, журнали аудиту та таймер-завдання, які позначають майбутнє завершення строків збереження. Це дає час втрутитися, якщо потрібне юридичне утримання або ручне винятки.
5. Остаточне видалення: Коли строк збереження минає і немає жодних винятків чи утримань, фонове завдання (наприклад, таймер-завдання в Exchange або SharePoint) позначає дані Copilot для остаточного видалення. Це видалення незворотне, що сприяє мінімізації даних і відповідності вимогам щодо приватності.
6. Візуалізація життєвого циклу: Уявіть дані Copilot як «річку», якою керують політики: вони надходять під час збирання запиту, на мить зупиняються у «островах» зберігання, затримуються під час збереження і нарешті потрапляють до «водоспаду» видалення. Кожен етап контролюється з погляду відповідності вимогам.
7. Втручання в життєвий цикл: Адміністратори можуть перехопити або призупинити життєвий цикл у ключових точках: застосувати утримання (holds), виправити помилки в налаштуванні політик або сформувати звіти для контролю відповідності. Це дає і гнучкість, і впевненість, що критично для регульованих галузей. Ширший погляд на дисципліну управління Microsoft 365 ви знайдете в цій дискусії.

Зберігання даних Copilot і практики безпеки: пояснення

Мати дані — це одне, а зберегти їх у безпеці та належним чином керувати ними — зовсім інше. Коли ви впроваджуєте Microsoft Copilot у своє середовище, ви підключаєте не просто розумного ШІ-асистента, а й нові дані, нові місця зберігання та нові питання безпеки, з якими, імовірно, раніше не стикалися.

Дані Copilot зберігаються в місцях, які легко проґавити: у прихованих папках поштової скриньки, у вбудованому сховищі застосунків або в зашифрованих базах даних, пов’язаних із користувачами та робочими навантаженнями. Резидентність даних (географічне місце їх зберігання) — це не просто технічна деталь: від неї залежить відповідність вимогам, починаючи від законодавства США і закінчуючи GDPR.

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

У наступних розділах ви побачите, де фізично зберігаються дані Copilot, як Microsoft їх захищає та що варто знати про доступ співробітників, зовнішній обмін і захист від витоків. Оскільки архітектура Copilot відрізняється від класичних робочих навантажень Exchange чи SharePoint, розуміння цих змін сьогодні — не опція, а необхідність для кожного адміністратора, який відповідає за ризики та відповідність.

Місця зберігання даних Copilot і географічні аспекти

Куди потрапляють дані Copilot — питання не другорядне: від цього напряму залежать ризики відповідності та нормативним вимогам. Microsoft Copilot зберігає більшість даних взаємодії в репозиторіях, прив’язаних до користувача або робочого навантаження, які часто «приховані» від прямого доступу користувачів. Наприклад, коли Copilot працює з Outlook або Teams, журнали взаємодії та згенеровані результати зазвичай зберігаються в прихованих папках Exchange Online або в базах даних застосунків, пов’язаних з обліковими записами користувачів.

Тут важлива резидентність даних. Згідно з документацією Microsoft, дані Copilot зберігаються в тому самому регіональному центрі обробки даних, що й вихідне робоче навантаження M365. Тож якщо дані Exchange вашої організації розміщені в центрі обробки даних у США, то й дані Copilot, пов’язані з Exchange, теж будуть там. Недавній звіт Gartner показав, що 67 % підприємств назвали резидентність даних головним питанням відповідності у сфері ШІ на 2024 рік, особливо коли йдеться про чутливу інформацію про пацієнтів або фінанси в США.

Практика показує, що організації з суворими вимогами до зберігання даних лише в межах США можуть покластися на гарантії геофенсингу Microsoft для сервісів Copilot. Водночас адміністраторам варто ще раз перевірити налаштування резидентності для SharePoint, OneDrive чи Teams, щоб уникнути випадкового витоку даних між регіонами. Фізичне зберігання для Copilot може відрізнятися від класичних репозиторіїв SharePoint/OneDrive: дані конкретних застосунків можуть бути більш сегментованими, що допомагає мінімізувати обсяг даних, але може ускладнити eDiscovery.

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

Захист конфіденційних даних і контроль доступу співробітників

1. Мітки конфіденційності для вмісту Copilot: Microsoft поширює мітки конфіденційності з Purview на вміст, згенерований Copilot, і на вміст, до якого він звертається. Якщо запит користувача або відповідь Copilot стосується конфіденційних даних, мітки обмежують дії з ними: блокують пересилання, копіювання і навіть читання для всіх, окрім уповноважених співробітників.
2. Обмежений доступ співробітників Microsoft: Інженери бекенду та персонал центрів обробки даних у Microsoft не мають постійного доступу до даних Copilot у клієнті. Екстрений доступ підпорядковується суворим протоколам «break-the-glass», фіксується в журналах аудиту та потребує явного дозволу. Це знижує ризик витоку інсайдерами.
3. Керування доступом на основі ролей (RBAC) і Entra ID: Адміністратори можуть точно налаштувати, хто у вашій організації має доступ до даних Copilot, за допомогою Entra ID і RBAC. Це стосується не лише даних кінцевих користувачів, а й журналів аудиту адміністраторів та експортів eDiscovery, а також дозволяє обмежувати доступ під час онбордингу, зміни ролей або звільнення.
4. Шифрування даних Copilot: Усі дані Copilot, що зберігаються та передаються, шифруються алгоритмами корпоративного рівня. Навіть якби неуповноважена сторона спробувала перехопити вміст, його було б математично неможливо використати.
5. Автоматизований аудит і сповіщення: Microsoft фіксує кожен доступ до даних Copilot, будь то користувачі, адміністратори чи автоматизовані процеси, тож у разі розслідування у вас є журнал аудиту, який можна обґрунтувати. Більше про детальний захист даних і найкращі практики автоматизації читайте в матеріалі про стратегії безпеки Dataverse.
6. Запобігання неавторизованому розкриттю: Передбачено засоби контролю, що запобігають випадковому оприлюдненню чутливих результатів, згенерованих Copilot, зокрема обмеження за політиками, правила DLP і сповіщення про аномальні шаблони доступу. Так ваші чутливі дані не вийдуть через віртуальні двері.

Керування спільним доступом третіх сторін і обробкою даних застосунків

• Без спільного доступу третім сторонам за замовчуванням: За замовчуванням дані Copilot не надаються зовнішнім сторонам або застосункам поза Microsoft 365. Ця політика залишає запити користувачів і відповіді всередині організації, знижуючи ризик витоків.
• Суворе оброблення даних застосунків: Дані застосунків Copilot залишаються в межах відповідної служби M365 з чіткими межами застосунків, що гарантує їх ненавмисне розкриття через боти Teams, викликі API чи конектори.
• Аудит запитів зовнішнього доступу: Ви можете використовувати розширений аудит, щоб відстежувати та позначати будь-які спроби неавторизованого або ризикового спільного доступу третім сторонам, так само як у розширених засобах керування SharePoint/OneDrive, описаних тут.
• Обмеження, які задають адміністратори: Адміністратори мають інструменти для додаткового обмеження спільного доступу: створення нових політик, вимкнення ризикових конекторів і проактивний перегляд журналів аудиту спільного доступу для навантажень Copilot.

Відповідність вимогам і регуляторні вимоги до даних Copilot

Якщо ви прагнете повної відповідності в еру Microsoft Copilot, не варто сподіватися, що старі політики вас покриють. Регуляторні вимоги щодо ШІ та контенту, створеного користувачами, лише посилюються, особливо для державного сектору США, охорони здоров’я та фінансових організацій. Copilot додає до роботи зовсім новий клас даних, а отже, потрібно переглянути і застосування політик, і підхід до аудиту.

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

Ми також розглянемо, як такі інструменти, як Purview і Defender for Cloud, можуть об’єднати моніторинг відповідності та безперервну звітність, щоб ви не наздоганяли час, коли прийде аудит. Якщо хочете глибше розібратися в типових пастках утримання даних і дрейфу відповідності, перегляньте цей епізод про дрейф відповідності в Microsoft 365, він дуже корисний.

Читайте далі, щоб дізнатися, які великі регулювання важливі для Copilot, як Microsoft зіставляє засоби контролю для кожного з них і як посилити робочі процеси eDiscovery та аудиту, щоб ваша організація була захищена, коли до вас завітають юристи чи регулятори.

Відповідність вимогам США та глобальним регуляторним стандартам

• Відповідність GDPR: Copilot має гарантувати, що дані резидентів ЄС обробляються законно, зберігаються з чітко визначеною метою та можуть бути видалені або експортовані на запит. Місце зберігання даних і згода є критично важливими для відповідності GDPR.
• Захист медичних даних згідно з HIPAA: Для медичних установ у США взаємодії з Copilot, що містять захищену медичну інформацію (PHI), мають відповідати правилам HIPAA щодо безпеки та конфіденційності. Передавання даних шифрується, а контроль доступу застосовується для забезпечення безпеки PHI.
• Управління відповідністю в межах США: Федеральним, штатним і місцевим органам влади потрібна підтримка Copilot для FedRAMP, CJIS та інших специфічних для США рамок відповідності. Дані зберігаються всередині країни, а вимоги до журналів аудиту та звітності про інциденти виконуються за допомогою вбудованих засобів керування Microsoft.
• Транскордонні та багаторегіональні середовища: Міжнародні організації мають стежити, щоб Copilot не створював випадкової невідповідності політик між регіонами ЄС, США та APAC. Конфігурація клієнта та перегляд політик є ключовими для запобігання конфліктам щодо місця зберігання даних або доступу.
• Найкращі практики для узгодження з регуляторними вимогами: Поєднуйте Purview DLP, автоматичне маркування, RBAC і звітування з аудиту, щоб закрити прогалини між Copilot і такими робочими навантаженнями, як Exchange або SharePoint. Такий комплексний підхід є необхідним для цілісної відповідності. Для безперервного моніторингу та автоматичного усунення проблем ознайомтеся з управлінням відповідністю за допомогою Defender for Cloud.
• Документування політик і збирання доказів: Для аудитів ведіть повну документацію щодо проєктування політик Copilot, їх застосування та обробки інцидентів. Тестуйте політики проактивно та підтримуйте чітку карту відповідальності в усіх глобальних бізнес-підрозділах.

Увімкнення можливостей eDiscovery та аудиту для Copilot

• Інтеграція з eDiscovery: Контент, промпти та відповіді, згенеровані Copilot, індексуються для eDiscovery у сфері відповідності. Це дає юридичним, HR- або службам безпеки змогу виконувати пошук за взаємодіями користувачів так само, як за електронними листами чи чатами.
• Процес юридичного утримання: Коли вводиться юридичне утримання, дані Copilot, на які воно поширюється, позначаються та зберігаються незалежно від інших параметрів збереження. Вміст не видаляється, доки утримання не знято, що зменшує юридичні ризики.
• Управління журналом аудиту Purview: Кожну взаємодію з Copilot можна відстежити за допомогою журналів аудиту, які фіксують дії користувачів, зміни адміністраторів і фонові завдання зберігання та видалення. Команди, які використовують Purview Premium, мають розширені можливості зберігання та криміналістичного відстеження. Цікавитеся практиками розширеного аудиту? Перегляньте детальний огляд Purview Audit.
• Обґрунтована звітність для регуляторів: Засоби eDiscovery та аудиту допомагають юристам і адміністраторам відповідності створювати звіти з позначками часу та захистом від підробки. Це ключово для впевненого виконання вимог регуляторів або суду.
• Проактивний моніторинг відповідності: Автоматичні сповіщення та постійні перевірки політик виявляють відхилення від політик до того, як вони стануть бізнес-проблемою. Інтеграція з інструментами SIEM/SOAR підвищує готовність до криміналістичного аналізу та виявлення ризиків у реальному часі.
• Візуалізація аудиту життєвого циклу даних: Панелі й журнали дають адміністраторам змогу простежити життєвий цикл даних Copilot від промпту до видалення, а також наочно побачити тригери збереження, утримання та графіки видалення.

Видалення даних і відключення користувачів у Copilot

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

Найважливіше — розуміти, як видалення працює у світі Copilot. Це не лише очищення кошика. Перевизначення політик збереження, таймерні завдання та перегляд шляхів вмісту відіграють свою роль у тому, щоб вміст очищався без винятків. Час дії політики стає тактичним питанням: коли починає відлічуватися строк для артефактів Copilot і що можна зробити, якщо щось потрібно видалити раніше (або зберегти довше), ніж зазвичай?

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

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

Як налаштувати видалення даних і винятки зі сховища

1. Визначте шляхи даних Copilot: Перш ніж налаштовувати видалення, визначте, де зберігаються дані Copilot: приховані папки поштових скриньок, чати Teams, бази даних застосунків або файли, інтегровані з SharePoint. Використовуйте Purview та панелі відповідності, щоб переконатися, що жоден шлях до даних не пропущено.
2. Налаштуйте політики лише видалення: Для сценаріїв, де зберігання не потрібне, налаштуйте політики лише видалення в Purview або через PowerShell. Визначте чіткі тригери та терміни, наприклад видалення запитів Copilot через 30 днів, якщо вони не містять регульованих даних.
3. Застосуйте контроль «зберегти, а потім видалити»: У регульованих галузях поєднуйте зберігання та видалення: встановіть обов’язковий строк зберігання, а потім перелічіть конкретні умови, за яких дані Copilot мають бути безповоротно знищені. Переконайтеся, що таймер-завдання увімкнено і вони автоматично ініціюють видалення після завершення строку зберігання.
4. Використовуйте винятки зі збереження: Коли вимоги юристів або відповідності змінюються, застосовуйте винятки політик на рівні контейнера даних або користувача. Виняток може призупинити видалення (через юридичне утримання) або продовжити строк зберігання для окремих записів. Винятки видно в журналах аудиту, що забезпечує їхню обґрунтованість.
5. Відстежуйте робочі процеси видалення: Використовуйте журнали активності та звіти таймер-завдань, щоб бачити, коли дані Copilot заплановано до видалення, і перевіряти, що видалення справді відбувається. Тестуйте політики, запускаючи завдання перевірки та вибіркові аудити, щоб відповідність не існувала лише на папері.
6. Налаштування для унікальних сценаріїв Copilot: Для функцій Copilot, інтегрованих з кількома робочими навантаженнями, забезпечте узгодженість політик на всіх відповідних платформах (Exchange, Teams, SharePoint), щоб уникнути прогалин або конфліктів у зберіганні. Це ключовий крок міжплатформенного управління.
7. Приклад на практиці: Уявіть, що запити Copilot керівника, який іде, посилаються на конфіденційні документи відділу кадрів. Ви переглянете шляхи даних, застосуєте необхідні юридичні утримання та поставите запити в чергу на заплановане видалення, використовуючи політику «зберегти, а потім видалити», щоб завершити цикл і захистити організацію.

Стратегії видалення користувачів і зберігання даних Copilot

• Політика зберігання даних для співробітників, що звільняються: Застосовуйте політики зберігання (або видалення) до даних Copilot, пов’язаних з обліковими записами колишніх співробітників, і переконайтеся, що поштові скриньки колишніх співробітників (включно з прихованими папками) належним чином позначено.
• Автоматизоване відкликання доступу: Використовуйте Entra ID або PowerShell, щоб вимкнути й видалити доступ до робочих навантажень Copilot під час offboarding, закриваючи будь-які канали випадкового або зловмисного розкриття.
• Аудит і документування дій під час offboarding: Ведіть детальні журнали застосування політик, видалень і відкликання доступу, щоб захистити процес під час регуляторних перевірок. Щоб дізнатися, як захистити облікові записи гостей і колишніх співробітників, перегляньте цей посібник із роботи з обліковими записами гостей M365.
• Юридично обґрунтоване ведення записів: Переконайтеся, що всі кроки offboarding можна перевірити, підтвердити та відтворити як доказ відповідності у разі судового розгляду або запиту суб’єкта даних на доступ.

Обробка даних Copilot і використання для навчання ШІ

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

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

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

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

Технічні деталі обробки даних у Copilot

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

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

Політики щодо навчальних даних ШІ та обмежень використання даних

1. Виключення з навчання моделей ШІ за замовчуванням: За замовчуванням Copilot у Microsoft 365 не використовує дані організації — запити, відповіді або контекст — для навчання загальнодоступних або спільних моделей ШІ. Так захищається конфіденційна бізнес- та особиста інформація від повторного використання для покращення моделей ШІ поза вашим клієнтом.
2. Навчання ШІ лише за явною згодою: У спеціальних програмах або за винятком, встановленим адміністратором, певні дані Copilot можуть розглядатися для покращення ШІ, але лише після того, як надано явну згоду користувача або організації. Банери для добровільної участі та параметри політик роблять цей процес прозорим і таким, що піддається аудиту.
3. Механізми відповідального ШІ: Дані, позначені як чутливі або з високим рівнем конфіденційності, автоматично виключаються з будь-якого навчального масиву незалежно від індивідуальних налаштувань користувача. Microsoft забезпечує це поєднанням логіки політик, технічних засобів контролю та аудитів відповідності.
4. Аудит і нагляд за використанням даних: Адміністратори можуть переглядати журнали включення до навчання ШІ та статус відмови від участі для кожного користувача або робочого навантаження. Звіти допомагають фахівцям з відповідності довести, за потреби, що чутливі взаємодії з Copilot ніколи не виходили за межі організації. Щоб ознайомитися з реальним поглядом на відповідальний ШІ, перегляньте роль наглядових рад в управлінні ризиками ШІ.
5. Динамічні коригування політик: Мітки конфіденційності, аналітика ризиків і тригери життєвого циклу можуть автоматично визначати, чи розглядаються певні дані Copilot для навчання ШІ. Якщо роль користувача змінюється або дані перекласифіковано, політики збереження та включення до ШІ можуть адаптуватися на льоту, підтримуючи відповідність у мінливому середовищі.
6. Виключення з навчання сторонніх моделей: Дані Copilot ніколи не передаються стороннім платформам ШІ, як-от ChatGPT Enterprise або зовнішнім моделям Microsoft Foundry, якщо тільки не надано дуже чіткої договірної згоди з обов’язковим журналюванням. Більшість організацій за замовчуванням ніколи не побачать, як їхні дані Copilot виходять за межі безпечних хмар Microsoft.
7. Безперервний нагляд за політиками: Наглядові ради та політики площини керування є ключовими для моніторингу та забезпечення відповідального використання. Як детально обговорено в цьому посібнику з безпечного управління ШІ, йдеться не лише про технічну конфігурацію, а й про постійний перегляд, розмежування операційної та керуючої площин і проактивне зниження ризиків ШІ.

Поширені запитання: Microsoft 365 Copilot і політики збереження

Який зв'язок між Microsoft 365 Copilot і політиками збереження?

Microsoft 365 Copilot використовує контент, що зберігається в службах Microsoft 365, тому політики збереження та мітки збереження, налаштовані в Microsoft Purview, і далі застосовуються до контенту, доступного Copilot. Збереження для Copilot означає, що відповідні елементи (електронні листи, файли SharePoint, чати Teams і взаємодії з Copilot) і далі підпадають під правила збереження та видалення. Політику збереження налаштовують і застосовують через портал Microsoft Purview, щоб відповідати вимогам відповідності та запобігати небажаній втраті даних.

Як політики збереження для Copilot впливають на чати Teams і взаємодії з Copilot?

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

Як створити та налаштувати політику збереження для даних Copilot?

Щоб створити політику збереження, перейдіть на портал Microsoft Purview і створіть та налаштуйте політики збереження для розташувань, де містяться дані Microsoft 365 Copilot (Exchange, SharePoint, OneDrive, Teams). Для області дії використовуйте статичні політики збереження або додавайте конкретні групи Microsoft 365 і поштові скриньки. Налаштуйте дії політики (лише зберігати або зберігати з подальшим видаленням), задайте строки збереження та запустіть політику, коли будете готові. Покрокові інструкції дивіться в статті про збереження на Microsoft Learn.

Скільки часу потрібно, щоб збереження почало працювати після застосування політики?

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

Що станеться, якщо до того самого вмісту Copilot застосовано кілька політик збереження або міток?

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

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

Так, Copilot може отримувати доступ до вмісту для створення та узагальнення, якщо користувач має дозвіл на цей вміст. Утримання для збереження та юридичне утримання запобігають видаленню та зберігають вміст на місці. Утримання окремі від політик збереження й належать до засобів безпеки та відповідності Microsoft 365. Якщо вміст підпадає під збереження або юридичне утримання, він залишатиметься доступним для виконання вимог відповідності й не буде вилучений діями видалення за політиками збереження.

Як політики збереження та запобігання втраті даних (DLP) працюють разом із Copilot?

Політики збереження відповідають за збереження або видалення вмісту згідно з правилами відповідності, а засоби запобігання втраті даних (DLP) не дають розкривати конфіденційні дані. Для Copilot і ШІ-застосунків поєднуйте політики збереження даних Microsoft 365 Copilot із політиками DLP, щоб знизити ризики втрати даних: налаштовуйте правила DLP для чатів Teams і взаємодій із Copilot, обмежуйте спільний доступ і відстежуйте використання Copilot. Використовуйте Copilot Studio та засоби керування, щоб обмежити, які дані Copilot може обробляти, і забезпечити виконання вимог відповідності.

Де адміністратори можуть дізнатися про збереження для Copilot і перевірити конфігурацію політик?

Адміністраторам варто ознайомитися з документацією Microsoft Learn і порталом Microsoft Purview, щоб дізнатися про політики збереження, збереження та видалення даних, а також особливості розміщення політик збереження. На порталі Purview можна створити політику збереження, перевірити, чи правильно вона налаштована, переглянути, на які елементи поширюється збереження, і відстежувати розгортання політики. Щодо специфіки Copilot зверніться до довідкової документації для copilot for Microsoft 365 та copilot studio, щоб зрозуміти, як обробляються дані Microsoft 365 Copilot і як політики збереження для Copilot інтегруються з наявними процесами відповідності вимогам.