За даними Microsoft, з листопада ШІ в Teams перевірятиме чати з невідомими зовнішніми контактами на фішинг: виключно з метою безпеки і без зберігання вмісту повідомлень. Таке виявлення фішингу в Teams залишає відкритими питання про відмову (opt-out), місце аналізу та використання результатів аналізу. Це потребує з’ясування для реєстру обробки, оцінки впливу та ради працівників (Betriebsrat).
Новий ШІ в Teams: оголошення Microsoft
За даними BleepingComputer від 23.10.2026, Microsoft оголосила в Message Center (MC1519866) для Teams виявлення фішингу та соціальної інженерії на основі ШІ. Функція з’явиться автоматично; за наявною інформацією, адміністраторам не потрібно її вмикати. Саме в цьому і полягає напруга: втручається функція безпеки, яка аналізує контекст розмови, і робить це в інструменті, де працівники щодня спілкуються.
У будь-якому разі за останні роки Microsoft не вирізнялася ні прозорістю, ні особливо доброю культурою безпеки – див. численні інциденти та сумнівні дії Microsoft.
Для класифікації використовуються три позначки: підтверджено – те, що спирається на назване джерело, не підтверджено – те, на що Microsoft не відповіла, а оцінка – це судження, яке не є юридичною консультацією.
Коротко наперед: виграш у захисті правдоподібний. Проте питання захисту даних і права співучасті працівників автоматика не знімає. Хто документує до розгортання, зберігає свободу дій. Схожий випадок описано в статті про виявлення шахрайства в Chrome за допомогою Gemini.
Виявлення фішингу в Teams за допомогою ШІ: що робить функція і коли вона з’явиться
Джерелом для цього розділу є повідомлення BleepingComputer від 23.10.2026. Саме повідомлення в Message Center видно лише у власному тенанті, тому тут його не вдалося переглянути в оригіналі. Публічне дзеркало та дзеркало запису дорожньої карти 575288 лише полегшують доступ і не вважаються першоджерелом.
Підтверджено за даними BleepingComputer: функція аналізує контекст розмови, щоб розпізнати фішинг, соціальну інженерію, видавання себе за іншу особу та оманливі наміри. Це має працювати й без класичних ознак, як-от шкідливих посилань чи файлів. Основну увагу приділено ситуаціям із високим ризиком, наприклад чатам із зовнішніми контактами, які пишуть уперше. Якщо переписку класифіковано як підозрілу, користувачі отримують попередження.
Щодо графіка повідомлення наводить такі дані, які прямо названо попередніми:
- Початок впровадження: початок листопада 2026 року.
- Targeted Release: орієнтовно до середини листопада 2026 року.
- Загальна доступність у всьому світі: орієнтовно з початку до середини грудня 2026 року.
Натомість запис дорожньої карти, судячи з дзеркал, називає датою загальної доступності «листопад 2026» і статус «У розробці». Обидві дати подано зі звичайним застереженням, що терміни можуть змінитися. Тим, хто планує, варто брати за основу ранішу дату. За даними дзеркала, функція діє для Android, Desktop, iOS, Mac і Web у стандартній мультитенантній хмарі. Це також не перевірено за оригіналом.
За словами Microsoft, адміністраторам не потрібно нічого робити, щоб активувати захист. Повідомлення не згадує жодної можливості відмовитися від функції чи вимкнути її. Тому не підтверджено, чи існує перемикач. Не доведено ні його наявність, ні відсутність. Так само відкритим є питання, чи потребує функція певних ліцензій, як-от Defender for Office 365. Повідомлення жодних не називає.
Для контексту: Teams уже має функції захисту. Сторінка Microsoft Learn про Defender for Office 365 у Teams називає, зокрема, попередження про небезпечні URL-адреси, Safe Links, Safe Attachments, подальше видалення шкідливих повідомлень (ZAP) і надсилання скарг користувачами. За словами Microsoft, нова функція є додатковим рівнем, що діє там, де трапляються суто текстові атаки без посилань. Сторінка Learn її не згадує. Раніше Microsoft уже оголошувала виявлення імітації брендів під час першого контакту (MC910976). Нинішня функція йде далі, аналізуючи контекст розмови.
Виграш у захисті під час першого контакту із зовнішніми особами
Оцінка: зосередженість на першому контакті із зовнішніми особами зрозуміла. Чат у Teams здається довірчішим за електронний лист. Хто отримує повідомлення в месенджері, рідше очікує спроби шахрайства. Зловмисники цим користуються, видаючи себе за постачальників послуг, керівників або ІТ-підтримку. Класичні фільтри погано розпізнають такі атаки, якщо повідомлення складається лише з тексту. Тут може допомогти аналіз контексту.
Межі також мають бути зрозумілими. За наявними джерелами, Microsoft не називає ні рівня виявлення, ні частки хибних тривог. Обидва показники не підтверджено. Хибні тривоги при аналізі контексту не виключені. Легітимних партнерів, які пишуть уперше, можуть позначити. Можливе й протилежне: вміла атака залишиться непоміченою. Тому функція не замінює ні навчання, ні чітких правил.
Заходи, доцільні незалежно від нового ШІ:
- Керувати зовнішньою комунікацією в Teams, наприклад через дозволені або заблоковані домени.
- Заохочувати працівників повідомляти про підозрілі чати, а не просто закривати їх.
- Показувати типові схеми на навчаннях з обізнаності, зокрема атаки в чаті без посилань.
- Перевіряти власну поверхню атаки, наприклад за допомогою технічних перевірок безпеки.
Отже, виграш у захисті реальний, але це не карт-бланш. Він виправдовує серйозне ставлення до функції. Проте не замінює перевірки того, як вона працює.
Захист даних у Microsoft Teams: що обіцяє Microsoft і що залишається відкритим
Підтверджено як заяви Microsoft (за даними BleepingComputer, за змістом): функція використовується лише з метою безпеки. Вона не слугує ні продуктивності, ні підсумовуванню, ні рекламі, ні стеженню за користувачами. Система виявлення не зберігає вміст повідомлень. Його не використовують для навчання моделей чи іншого вторинного використання. Сам запис дорожньої карти, за даними дзеркала, називає лише використання «виключно з метою безпеки» і залишає відкритими подробиці обробки, строку зберігання та надання даних.
Ці обіцянки – добрий початок. Однак, схоже, наразі вони містяться лише в оголошенні; чи є вони частиною договірної документації, потрібно перевірити. Для перевірки важливо, чи їх можна простежити в Product Terms, у Data Protection Addendum або в документації продукту.
Відсутність зберігання не означає, що нічого не аналізується.
Це розрізнення – суть відкритих питань. «Вміст повідомлень не зберігається» та «жодного навчання на повідомленнях клієнтів» – це твердження про зберігання й навчання моделей. Вони не кажуть, що аналізу не відбувається. Аналіз і є самою функцією. Так само вони не кажуть, що відбувається з результатами аналізу. Чи потрапляють вердикт виявлення, похідні метадані або зворотний зв’язок зі скарг користувачів у вдосконалення сервісів Microsoft, оголошення не відповідає. Це не твердження, що так відбувається. Це відкрите питання, яке потрібно з’ясувати до оцінювання.
Інші пункти, що не підтверджені і мають бути адресовані Microsoft або документації:
- Відмова (opt-out): Чи є перемикач на рівні тенанта, для груп або окремих користувачів? Повідомлення та дорожня карта про це мовчать.
- Місце аналізу: Чи відбувається він у межах EU Data Boundary? Запис дорожньої карти називає лише «Worldwide». Чи охоплює цю функцію межа даних ЄС, має показати документація.
- Використання результатів аналізу: Чи потрапляють похідні результати у вдосконалення сервісів? Обіцяно лише, що повідомлення не використовуються для навчання.
- Роль Microsoft: Чи діє Microsoft як обробник, чи з метою безпеки частково як самостійний контролер? Це визначається Data Protection Addendum до Product Terms у чинній редакції. Цю редакцію тут не вдалося отримати, тому висновків щодо нової функції не робимо.
- Події попереджень: Чи з’являються спрацювання в журналах, звітах або в порталі Defender, і хто в компанії може їх бачити? Від цього залежить питання співучасті, розглянуте в розділі після наступного.
Щодо того, як загалом класифікувати такі функції ШІ, більше контексту дає стаття про незручну правду за обіцянками Microsoft щодо ШІ. Там ідеться про Copilot, але логіка переноситься: обіцянки на сторінках продукту слід відрізняти від договірної документації.
Обіцянки не ставлять під сумнів. Вирішальною є можливість їх перевірити: перевірка захисту даних потребує документів, які можна цитувати й архівувати, а не лише повідомлення.
Правова підстава, реєстр і оцінка впливу на захист даних для виявлення фішингу
Оцінка: правовою підставою для аналізу найімовірніше є законний інтерес роботодавця в ІТ-безпеці (ст. 6 ч. 1 п. f GDPR). Необхідність можна обґрунтувати безпекою обробки. У контексті трудових відносин додається § 26 BDSG (Федеральний закон Німеччини про захист даних), а також угода з радою працівників (Betriebsvereinbarung) як колективна угода. Наскільки § 26 ч. 1 речення 1 BDSG ще діє після рішення Суду ЄС щодо паралельної норми землі Гессен (C-34/21, 2023), є дискусійним. Тут це лишається вказівкою на правову невизначеність. Детальніший розгляд вийшов би за межі статті, а саме рішення для цієї статті не перевірялося в оригіналі.
Зачеплені не лише працівники. Обробляються також дані зовнішніх відправників під час першого контакту. Їхні повідомлення і є предметом аналізу. Тому зважування інтересів і прозорість щодо зовнішніх осіб входять до перевірки, наприклад через повідомлення компанії про захист даних.
Реєстр операцій з обробки – перший практичний крок. Функцію, імовірно, можна внести як доповнення до наявної обробки в Teams або до ІТ-безпеки. Слід перевірити мету, категорії суб’єктів даних (працівники та зовнішні співрозмовники), категорії даних (вміст чатів як предмет аналізу, події попереджень), одержувачів, можливу передачу до третіх країн і строки видалення.
Щодо оцінки впливу на захист даних діє таке правило: спочатку перевірити наявну оцінку впливу для Microsoft 365 і Teams на предмет змін. Новий аналіз вмісту комунікації на основі ШІ може змінити ризик. Чи потрібна нова або доповнена оцінка впливу, залежить від відкритих пунктів, передусім від відмови (opt-out), місця аналізу та використання результатів. Як допомога в ухваленні рішення слугують порогова оцінка та звірка зі списками наглядових органів. Тому висновок звучить «перевірити й задокументувати», а не «обов’язково створити заново». Основи викладено у статті про статтю 35 GDPR і у статті про оцінку впливу для ШІ та інших цифрових сервісів.
Ще один момент: функція генерує попередження, а не рішення щодо людей. Але якщо система автоматично вилучатиме повідомлення чи блокуватиме контакти, може постати питання про автоматизовані рішення. Станом на зараз цього не очікується; проте за цим варто стежити, якщо Microsoft розширить функцію.
Чи потрібно перед розгортанням перевірити виявлення фішингу в Teams за допомогою ШІ з погляду захисту даних і погодити його з радою працівників?
На практиці це означає: доповнити запис у реєстрі, перевірити оцінку впливу, створити нотатку «Стан оцінки та відкриті пункти» і призначити повторний розгляд, щойно Microsoft надасть документацію.
Співучасть ради працівників щодо функції Teams
Відповідно до § 87 ч. 1 п. 6 BetrVG (німецький Закон про організацію підприємств) рада працівників має право співучасті у запровадженні та застосуванні технічних засобів, призначених для контролю поведінки або продуктивності працівників. Це текст закону. За загальним розумінням судової практики, достатньо, щоб засіб об’єктивно був придатний для контролю. Намір роботодавця значення не має. Окремі рішення тут свідомо не цитуються, оскільки їхні оригінали не перевірялися.
Оцінка: функція слугує захисту від атак, а не контролю продуктивності чи поведінки. Проте вирішальним є те, чи виникають дані, які можна пов’язати з окремими працівниками й аналізувати. Це можуть бути попередження, журнали, звіти Defender або скарги. Якщо так, багато що свідчить на користь права співучасті. Якщо ні, інформувати раду працівників однаково доцільно. Судове рішення щодо цієї функції невідоме.
Для практики: спершу перевірити наявну угоду з радою працівників щодо Microsoft 365 або Teams. Чи охоплює вона функції безпеки та автоматичні зміни через оновлення? Якщо так, обов’язок інформувати раду працівників зберігається. Якщо ні, потрібно погодити доповнення. Teams – це evergreen-сервіс, нові функції з’являються без участі компанії. Тому рекомендується положення про «зміни з боку постачальника», яке передбачає процедуру, замість окремих переговорів щодо кожної функції.
Питання, які може поставити рада працівників:
- Чи журналюються попередження або спрацювання, і хто має до них доступ?
- Чи можна пов’язати спрацювання з окремими працівниками?
- Як довго зберігаються такі дані?
- Чи виключено їх використання для контролю продуктивності або поведінки?
- Як обробляються хибні тривоги, і чи виникають через них негативні наслідки?
З погляду керівництва: інтерес безпеки легітимний, графік щільний. Багато що свідчить на користь того, щоб залучати раду рано й вести переговори до розгортання, а не після, коли функція вже активна. Це оцінка. Для рад персоналу в державному секторі діють земельні закони про представництво персоналу з власними правилами. Менші підприємства без ради працівників не підпадають під право співучасті, але документація їм потрібна так само.
Інформування працівників: прозорість і попередження в повсякденній роботі
Повідомлення про захист даних для працівників слід доповнити, щойно функція стане активною. До цього додається коротка інформація, наприклад в інтранеті. Вона пояснює, що означає попередження в Teams, що функція слугує захисту і що попередження не є оцінкою поведінки, якщо це так урегульовано. Сюди ж належить і порядок повідомлення про хибні тривоги.
З погляду адміністрування доцільно спостерігати за розгортанням у Targeted Release і регулярно перевіряти Message Center та дорожню карту. Служба підтримки має знати відповідь на питання, що робити в разі попередження. Також слід з’ясувати, як діяти з легітимними зовнішніми партнерами, яких помилково позначено. Коротке повідомлення частим контактам може запобігти подальшим запитанням.
Наведений нижче огляд підсумовує, що має бути з’ясовано до розгортання. Розподіл відповідальності – це пропозиція, яка залежить від організації.
| Завдання | Відповідальні |
|---|---|
| Опрацювати документацію Microsoft, з’ясувати opt-out, прив’язку до ліцензій і місце аналізу | Адміністрування |
| Доповнити реєстр операцій з обробки, перевірити оцінку впливу | Уповноважений із захисту даних |
| Поінформувати раду працівників, перевірити наявне положення | Керівництво, відділ кадрів |
| Поінформувати працівників, визначити порядок повідомлення про хибні тривоги | Захист даних, ІТ |
| Повторний розгляд у разі нової документації Microsoft | Захист даних, адміністрування |
Висновок: використовувати захист, доопрацювати документацію
Виявлення фішингу в Teams за допомогою ШІ закриває реальну прогалину: текстові атаки в чаті, яким не потрібні ні посилання, ні файли. Виграш у захисті правдоподібний, але цифрами не підтверджений. Обіцянки Microsoft щодо обмеження мети, зберігання та навчання – це початок. Проте вони відповідають не на всі питання, передусім не на питання про відмову (opt-out), місце аналізу та використання результатів аналізу.
До розгортання слід з’ясувати питання реєстру операцій з обробки, оцінки впливу та ради працівників. Після цього потрібен повторний розгляд, щойно Microsoft опублікує документацію, повідомлення про захист даних і налаштування для адміністраторів. Правові оцінки в цій статті є судженнями без відповідного рішення чи позиції органу влади щодо цієї функції і не замінюють консультації в конкретному випадку.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
