Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Мультиагентні системи в Azure AI Foundry: планування, співпраця та інструменти без шкоди для продакшену (ШІ-дубляж)

Transcript

Мультиагентні системи в Azure AI Foundry: планування, співпраця та інструменти без шкоди для продакшену (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Знаєте, чат-боти розмовляють, агенти діють, а мультиагентні системи дійсно виконують роботу.
• 0:04
  Якщо ви благали бота виправити Intune, а він відповів віршем, це для вас.
• 0:08
  Отже, формат «Дивіться, як на Netflix».
• 0:10
  Ви дивитесь, ви їсті снеки.
• 0:11
  Я беру на себе небезпечні сервісні принципи, щоб ніхто не знищив продакшній.
• 0:15
  Ми створюємо міні-систему з мультиагентами, що самовідновлюється за допомогою Azure AI Foundry та Semantic Kernel.
• 0:20
  Реальні точки дотику.
• 0:22
  Intune, Entra, Graph, Azure Automation, Log Analytics.
• 0:25
  Один агент проти мультиагентної системи – 12 хвилин проти трьох.
• 0:29
  І єдина втрата – це кредит моєї підписки.
• 0:31
  По-перше, чому один агент гальмує, а команди літають?
• 0:34
  Чому одного агента недостатньо?
• 0:36
  Одиночні агенти – це як швейцарський, ніж із заправки.
• 0:38
  Технічно інструменти є, а на практиці він гнеться на першому ж гвинті.
• 0:42
  Ви втискаєте план, міркування, виконання, узгодження та звіти в один промп,
• 0:45
  і тепер він голодує за контекстом, повільний і дивно впевнений у помилкових речах.
• 0:49
  Більшість людей думають, більша модель, більший мозок, і бум, проблему вирішено.
• 0:53
  Але справжня помилка – це плутанина з ролями.
• 0:55
  Один агент намагається спланувати зміни, викликати граф, написати скрипт виправлення,
• 1:00
  запитати схвалення, перевірити результат і задокументувати це.
• 1:03
  Це ніби доручити техпідтримці, комітету з питань змін та розбору інцидентів одному втомленому стажеру.
• 1:07
  Ось що відбувається насправді.
• 1:09
  Одиночний агент намагається втримати забагато станів.
• 1:11
  Ваш промп перетворюється на цілу повість.
• 1:13
  Контекстне вікно заповнюється логами, політиками та половиною словника MDM,
• 1:16
  тому він або обрізає важливі частини, або галюцинує відсутні деталі.
• 1:19
  Затримки зростають, токи не спалюються, а повторні спроби відчуваються як «день бабака» з рахунком до оплати.
• 1:24
  Час мультиагентів – ролі, межі, паралелізм.
• 1:27
  Планувальник фокусується на намірах та обмеженнях.
• 1:30
  Оператор фокусується на інструментах та виконанні.
• 1:33
  Рецензент фокусується на запобіжниках, узгодженнях і перевірці, чи спираємося ми на факти.
• 1:37
  Кожен агент має чіткий, короткий набір інструкцій та мінімально необхідну пам'ять.
• 1:41
  Вони передають повідомлення, результати роботи інструментів або стислі підсумки, а не весь інтернет.
• 1:46
  Чому це важливо для бізнесу?
• 1:47
  Вам потрібні наскрізні робочі процеси з участю людини, діями з обмеженим доступом, повторними спробами та аудиторськими слідами.
• 1:53
  Це не однопотоковий чат.
• 1:54
  Це командна гра.
• 1:55
  Модель «Планувальник-виконавець-рецензент» зменшує ризики та переробки,
• 1:58
  бо кожен крок має другу пару очей автоматизованих, які не зависають на 11-й хвилині короткої наради в Teams.
• 2:04
  Виграш у вартості та затримках також є.
• 2:06
  Використовуйте малімовні моделі для вилучення та класифікації даних.
• 2:09
  Використовуйте преміальні моделі міркування лише там, де планування справді допомагає.
• 2:12
  Запускайте пакетні завдання для звітів, поки користувачі сплять.
• 2:15
  Ви отримаєте менше галюцинацій, швидші результати та менші рахунки.
• 2:18
  Коротка історія.
• 2:19
  Планувальник розуміє мету, обмеження та середовище.
• 2:45
  Створює план із викликами інструментів, які може виконати оператор.
• 2:50
  Оператор викликає інструменти Graph, Logic Apps, функції Azure Automation Runbooks та повертає структуровані результати.
• 2:57
  Рецензент перевіряє обґрунтованість, відповідність вимогам, погодження та безпеку результатів перед будь-якими ризикованими діями.
• 3:04
  Консьєрж повідомлень обробляє сповіщення для людей, погодження та підсумки для аудиту.
• 3:09
  Вони спілкуються через повідомлення та спільний контекст, як дорослі, коротко, чітко та тільки те, що потрібно.
• 3:15
  Послідовно, коли дії залежать від попередніх результатів, паралельно, коли підзавдання можна безпечно розподілити.
• 3:21
  Ви не надсилаєте 50-сторінкову політику, ви надсилаєте відповідний фрагмент, ID пристроїв і заплановану зміну.
• 3:26
  Інструменти – це руки.
• 3:27
  REST-ARI для Microsoft Graph, RIG через Azure AI Search для перевірених знань, інтерпретатор коду для фрагментів,
• 3:33
  Logic Apps для оркестрації, функції для зв'язку, Azure Automation для повторюваних завдань.
• 3:38
  Тримайте вхідні дані інструментів структурованими за допомогою схем, щоб оператор не зміг креативно видалити ваш тенант.
• 3:43
  Пам'ять – це не магія, це бюджет.
• 3:45
  Мінімізуйте пам'ять для кожного агента.
• 3:47
  Використовуйте зовнішній стан, індекси пошуку, векторні сховища або невелике сховище мета даних потоку.
• 3:51
  Тримайте вікна контекстолаконічними.
• 3:53
  Якщо це не потрібно для наступного рішення, воно не передається далі.
• 3:55
  Планування проти виконання – це те, де саментик Кернел проявляє себе найкраще.
• 3:58
  Планувальник делегує, оператор обирає правильний інструмент із каталогів функцій.
• 4:02
  Рецензент критикує результати за допомогою оціночних промптів та перевірки безпеки контенту.
• 4:06
  Якщо рецензент вказує на ризик виходу за межі повноважень, планувальник вносить зміни.
• 4:09
  Коли ви зрозумієте цей цикл, ви перестанете писати 800-слівні промпти і почнете визначати чіткі ролі.
• 4:14
  Межі безпеки не підлягають обговоренню.
• 4:16
  Виклики інструментів із розмежуванням доступу через керовані ідентичності.
• 4:19
  Права доступу агентів розділені між читанням і керуванням.
• 4:22
  PIM для підвищення прав при деструктивних діях.
• 4:25
  Усі виклики інструментів записуються в Log Analytics.
• 4:27
  Перевірка безпеки контенту як на вході, так і на вигоді.
• 4:29
  Захист промптів від джейлбрейків та непрямих ін'єкцій із джерел знань.
• 4:33
  Час для аналогій.
• 4:34
  Дослідник, аналітик, оператор, QA.
• 4:37
  Кожен несе відповідальність за свою частину роботи.
• 4:39
  Оператор не схвалює власні зміни.
• 4:41
  Аналітик не втручається в роботу продакшні середовища.
• 4:43
  QA не пише код, який він тестує.
• 4:45
  Просто, буденно, безпечно.
• 4:47
  Чому Azure AI Foundry разом із Symantec Kernel?
• 4:50
  Foundry надає оркестрацію агентів, вибір моделей обґрунтування знань,
• 4:53
  підключення інструментів, безпеку контенту, відстеження, оцінювання та управління в одному місці.
• 4:58
  Symantec Kernel надає вам планувальники, навички, конвейери, повторні спроби та скасування в коді.
• 5:03
  Разом ви комбінуєте моделі за ролями SLM для вилучення, GPT-4 класу для планування,
• 5:09
  пакетну обробку для резюме, при цьому зберігаючи промпти короткими, ризики мінімальними, а вихідні – вільними.
• 5:14
  Тепер давайте це створимо, як Azure AI Foundry забезпечує роботу агентних робочих процесів.
• 5:19
  Ось де Azure AI Foundry перестає бути просто глянцевим порталом і починає діяти як виробничий майданчик.
• 5:24
  Foundry дає вам простір для визначення агентів, підключення моделей, додавання знань,
• 5:28
  налаштування дій і спостереження за всім цим без блукання між шістьма різними вкладками навмання.
• 5:31
  Це оркестрація без синьої ізоляційної стрічки.
• 5:34
  Почніть із визначення агентів.
• 5:36
  У Foundry кожен агент отримує інструкції та чіткі вказівки щодо ролі, а не маніфест.
• 5:41
  Розгортання – фактична модель, що стоїть за цим.
• 5:43
  Поєднуйте моделі класу GPT-4 для планування з SLM класу FI для вилучення даних.
• 5:48
  Знання, індекси Azure AI Search, завантажені файли або BIN для контексту з інтернету.
• 5:52
  Дії, інструменти OpenARIE, Logic Apps, функції, граф, Azure Automation або інтерпретатор коду для швидких обчислень і парсингу.
• 6:00
  Підключені агенти.
• 6:01
  Так, агент може сприймати іншого агента як інструмент, якщо це дозволяє чітко розмежувати ролі.
• 6:06
  Це важливо, оскільки Semantic Kernel підключається до того самого Всесвіту.
• 6:09
  У коді ви будуєте планувальники, визначаєте навички та реєструєте інструменти в каталогах функцій.
• 6:14
  Ви координуєте цикл, планувальник, оператор, рецензент, а Foundry бере на себе потоки, історію та обмеження безпеки.
• 6:20
  Ви тримаєте промпти короткими, а основну роботу перекладаєте на інструменти зі схемами.
• 6:24
  Переклад – менше галюцинацій, менше помилок, більше вільного часу.
• 6:27
  Вибір моделей має значення.
• 6:29
  Foundry абстрагує висновок через модельну кінцеву точку, тому ви можете змінювати моделі без переписування всього застосунку.
• 6:34
  Два основні шляхи – безсерверні кінцеві точки для преміум-моделей і швидкої ітерації.
• 6:37
  Ви платите за токен, масштабуєтеся за запитом і не доглядаєте за GPU, як у 2018 році.
• 6:42
  Керовані обчислення для конкретних відкритих моделей, які ви хочете закріпити у межах свого тенента.
• 6:46
  Ви платите за час роботи та контролюєте конфігурацію, але Microsoft бере на себе клопоти з розгортання.
• 6:50
  Комбінуйте моделі за ролями.
• 6:52
  Планувальник на базі GPT-4 або 4, один міні для логічних міркувань.
• 6:55
  Оператор на невеликій моделі, що ефективна у вилученні та структурованні параметрів.
• 6:59
  Пакетна обробка довгих звітів вночі, щоб люди отримували готові результати вранці.
• 7:02
  І якщо модель застаріє або ви захочете спробувати варіанти DeepSeek,
• 7:06
  чи лама АРІ висновку Foundry дозволить зберегти стабільність коду під час експериментів.
• 7:09
  Інструменти та дії – це те, де оператор здобуває свій авторитет.
• 7:13
  Саме тут ви надаєте реальну силу, не віддаючи агенту ключі від вашого королівства.
• 7:16
  Відкривайте АРІ інструментів для внутрішніх сервісів через Svega.
• 7:19
  Дотримуйтесь суворих контрактів.
• 7:21
  Якщо в схемі для пристрою вказано рядок, це має бути ідентифікатор пристрою.
• 7:24
  Logic Apps для потоків затвердження та контролю з боку людини.
• 7:27
  Нехай перевіряльник спрямовує зміни до особи, що їх погоджує,
• 7:29
  а потім відновлює виконання після схвалення.
• 7:31
  Azure Functions для сполучного коду та коректних перетворень.
• 7:34
  Невеликий версійний граф АРІ, що легко тестується для завдань Intune,
• 7:37
  Entra та умовного доступу користувачів до пристрою.
• 7:39
  Надавайте права на читання агентам моніторингу,
• 7:42
  а права на керування – лише агентам виправлення.
• 7:44
  Azure Automation для скриптів пристроїв та посібників з експлуатації.
• 7:47
  Поведьтеся з цим, як і з гострими предметами, в замкненій шухляді.
• 7:50
  Лише агент виправлення може її відкрити.
• 7:52
  Як і з граундингом, підтримуйте вміст у впорядкованому стані.
• 7:54
  Використовуйте Azure AI Search із гібридним ранжуванням та семантичним переранжуванням.
• 7:58
  Розподіляйте знання за доменами.
• 7:59
  Політики Intune окремо від інструкцій з онбордингу.
• 8:02
  Щоб не завантажувати зайвого.
• 8:04
  Оператор має передавати фрагмент, а не всю енциклопедію.
• 8:07
  Визначайте розміри блоків, зберігайте посилання
• 8:09
  та доручіть перевіряльнику оцінити обґрунтованість перед виходом у продуктивне середовище.
• 8:12
  Безпека – це не опція.
• 8:14
  Foundry містить вбудовані фільтри безпеки в місту для вводу та виводу,
• 8:17
  захист від зламу та непрямих ін'єкцій, а також перевірку захищених матеріалів.
• 8:20
  Виконуйте перевірку безпеки до та після моделі,
• 8:22
  щоб не платити за погані дані або піар-катастрофи на вигоді.
• 8:25
  Поєднуйте це з керованою ідентичністю для кожного агента,
• 8:28
  принципом найменших привілеїв та тимчасовим підвищенням прав для деструктивних інструментів.
• 8:31
  Кожен виклик інструменту відстежується.
• 8:33
  Кожне затвердження реєструється.
• 8:35
  Якщо хтось запитає, хто що запустив, ви не відкриваєте Outlook.
• 8:38
  Log Analytics уже все знає.
• 8:40
  Спостережуваність – це ознака дорослого підходу.
• 8:42
  Увімкніть трасування, щоб бачити історію запусків,
• 8:44
  який агент, який інструмент, з якими параметрами,
• 8:47
  з якою затримкою викликав і що отримав у відповідь.
• 8:49
  Налаштуйте Application Insights для аналізу продуктивності,
• 8:51
  логи додатків для аудиту та впроваджуйте оцінки в CI,
• 8:54
  щоб виявляти відхилення в релевантності, обґрунтованості та зв'язності до того,
• 8:57
  як це зробить користувач.
• 8:58
  Якщо обґрунтованість падає, перевіряльник позначає це,
• 9:00
  планувальник звужує запит на отримання даних,
• 9:02
  і оператор робить ще одну спробу.
• 9:03
  Жодної паніки з боку людини не потрібно.
• 9:05
  Примітиве розгортання допомагають підтримувати порядок.
• 9:07
  Використовуйте проєкти Foundry для квот, команд та базових політик.
• 9:10
  Розмістіть Azure Arie Management перед сервісом інструментів для керування версіями,
• 9:13
  обмеження швидкості, впровадження запобіжників та маршрутизації
• 9:15
  між пітію та моделью оплати за фактом використання.
• 9:17
  Приватні кінцеві точки там, де вимагається відповідність вимогам або резиденція даних.
• 9:21
  Регіони, що відповідають вашим користувачам, а не лише вашим амбіціям.
• 9:24
  І так, Сементик Кернел завершує цю картину.
• 9:26
  Ви описуєте робочий процес у коді.
• 9:28
  Планувальник декомпозує завдання.
• 9:30
  Оператор обирає інструменти на основі каталогів функцій та їх доступності.
• 9:33
  Рецензент виконує перевірки за допомогою оцінювальних підказок
• 9:36
  і результатів перевірки безпеки в місту,
• 9:38
  а ви отримуєте повторні спроби з очікуванням та маркерами скасування,
• 9:41
  Це нудно в найкращому розумінні цього слова.
• 10:05
  Як паски безпеки або відмова від надання прав глобального адміністратора-стажеру
• 10:09
  на ім'я Default Key.
• 10:11
  Демо сценарій 1 – очищення пристроїв, підрозділ привидів CSI Intune.
• 10:15
  Знаєте ці пристрої, які відображаються як керовані, списані та живі мерці одночасно?
• 10:20
  Ласкаво просимо до CSI Intune.
• 10:22
  Наша робота – знайти застаріле, дублюване або незареєстроване обладнання
• 10:26
  та безпечно виправити ситуацію після схвалення,
• 10:28
  щоб ніхто не нацилав гнівні листи юристам.
• 10:29
  Команда агентів – монітор, запити, Microsoft Graph та Log Analytics,
• 10:34
  класифікація станів пристроїв, позначення аномалій.
• 10:37
  Засіб виправлення викликає Intune та Azure Automation для карантину або списання пристроїв.
• 10:42
  Аудитор записує все, сповіщає людей і пише звіт про виконані дії для відповідності вимогам.
• 10:48
  Процес виглядає так.
• 10:49
  Монітор отримує з графа записи про пристрої останню реєстрацію,
• 10:52
  стан відповідності, тип реєстрації, основного користувача та пропорції списання.
• 10:56
  Він також збирає сигнали Log Analytics, серцебиття Defenda, відповідність оновлень
• 11:00
  та події розширення керування Intune.
• 11:02
  Він об'єднує їх у короткий структурований запис для кожного пристрою.
• 11:06
  Останній сеанс UTC зареєстрований, сумісний, кандидати на дублювання, сигнали ризику.
• 11:10
  Жодних романів, лише поля.
• 11:11
  Тепер передача від мозку до м'язів.
• 11:13
  Монітор надсилає запропоновану класифікацію за старілий, дублікат, немає серцебиття або в нормі.
• 11:17
  Рецензент перевіряє обґрунтованість.
• 11:19
  Чи справді ці дані надійшли з графа та Log Analytics?
• 11:22
  Перевірка безпеки в місту працює перед моделью, щоб заблокувати ін'єкції підказок із будь-яких завантажених файлів або веб-джерел.
• 11:36
  Ди дата на списання, видаляємо прив'язки до динамічних груп, що спричиняють розростання політик і, за потреби, переміщуємо пристрій у групу карантину Azure ID, яка блокує доступ.
• 11:45
  Поки що ніякого видалення.
• 11:47
  Запити на схвалення потрапляють у Logic App.
• 11:49
  Рецензент додає компактний план, ID пристроїв, причини, запропоновані дії та відкат.
• 11:54
  Особа, що схвалює, бачить зведення в Teams із посиланнями на запити графа та KQL з Log Analytics.
• 12:00
  Схвалення повертає маркер, засіб виправлення виконує списання, очищення, якщо обґрунтовано, або видаляє дублікати, залишаючи пристрій із найсвіжішим серцебиттям і розриваючи зв'язки з привидами.
• 12:09
  Керована ідентичність тримає наші руки чистими.
• 12:12
  Монітор працює з правами на читання всіх пристроїв.
• 12:14
  Ремедіатор використовує окрему ідентичність із правами читання та запису пристроїв та рівно тими дозволами Intune, які йому потрібні.
• 12:20
  Видалення захищене через PIM.
• 12:21
  Агент-ремедіатор не може підвищувати власні права.
• 12:24
  Коли запитується підвищення прав, логічний додаток потребує участі людини і запускається таймер тимчасового доступу.
• 12:29
  Спостережуваність – це доросла частина системи.
• 12:31
  Кожен виклик інструменту відстежується.
• 12:33
  Хто викликав – параметри, затримка, відповідь.
• 12:36
  Аудитор записує події в Log Analytics з ідентифікаторами кореляції, щоб ви могли відтворити послідовність дій без археології в слег.
• 12:42
  Ми також проводимо етап оцінки після внесення змін – обґрунтованість, релевантність, плинність.
• 12:51
  Уточнення пошуку або звуження обсягу.
• 12:53
  Моделі змішуються цілеспрямовано.
• 12:55
  Класифікація використовує невелику модель для зниження вартості та затримки.
• 12:59
  Виняткові випадки, як-от два пристрої, де OtoPilot перейменував один, а Azure ID вважає їх ідентичними, отримують шлях міркування з GPT-4 Mini.
• 13:06
  Підсумки пакетуються.
• 13:07
  Нікому не потрібен шекспірівський звіт о 14.00, лише стисла історія.
• 13:10
  Минулого тижня тест з одним агентом спробував виправити застарілий пристрій, видаливши все у тій же динамічній групі.
• 13:15
  Рецензент у нашому мультиагентному потоці виявив невідповідність обсягу, запитав підтвердження на рівні пристрою та зупинив це.
• 13:21
  Ось чому ми розділяємо планування, дію та перевірку.
• 13:23
  Кінцевий результат – пристрої привиди перестають заважати комплеєнсу.
• 13:26
  Ви зменшуєте марну витрату ліцензій, кількість хибних спрацювань і припиняєте пояснювати керівництво, чому помилки видалення стали нормою життя.
• 13:33
  І так, журнал аудиту читабельний, що більше, ніж я можу сказати про половину ваших тікетів на зміни.
• 13:37
  Демо сценарій 2. Адаптація без дотиків. Zero-touch onboarding.
• 13:41
  Насправді без жодного дотику.
• 13:42
  0 дотиків для користувача, 500 дотиків для інженерії до появи агентів.
• 13:46
  Ціль – відкадрової події до готового користувача та пристрою без зайвих рухів.
• 13:50
  Плавно, керовано та оборотно, коли HR пише прізвище трьома різними способами.
• 13:55
  Склад команди.
• 13:56
  Інтейк слухає HR-вебхук, нормалізує корисні дані та перевіряє обов'язкові поля.
• 14:01
  Провіженер створює користувача Ventra, призначає групи та ліцензії, реєструє профілі AutoPilot.
• 14:07
  Веледий та перевіряє відповідність політикам та стан умовного доступу, перш ніж ми віддамо новий ноутбук.
• 14:13
  Консьєрж надсилає вітальний пакет, посилання на SharePoint та чек-лист для першого дня.
• 14:18
  Час потоку.
• 14:19
  Інтейк отримує кадрові дані, ім'я, дату виходу, роль, відділ, керівника, регіон.
• 14:23
  Невелика модель вилучає та нормалізує їх.
• 14:26
  Вона зіставляє дані з канонічними полями та виловлює дурниці, як от дата початку у 2099 році.
• 14:30
  Якщо обов'язкові поля відсутні, система надсилає HR-структуровану помилку через Logic Apps без вільної поезії.
• 14:35
  Провіженер викликає граф із керованою ідентичністю, обмеженою правами користувача.
• 14:38
  Вона створює користувача Ventra, встановлює місцеве користання та застосовує базову групу.
• 14:42
  Далі він формує призначення ліцензій на основі ролі та регіону.
• 14:45
  Тут допомагає логічне мислення.
• 14:47
  Чи потрібна цій особі і 5 Security або Business Premium?
• 14:50
  Ми кодуємо політику в даних і дозволяємо моделі обирати з дозволених пакетів.
• 14:53
  Жодна модель не може вигадувати ліцензії, є лише суворе меню.
• 14:56
  Далі йде AutoPilot.
• 14:58
  Засіб надання доступу або реєструє апаратний хеш, який ми вже маємо, або готує профіль, точно в строк, прив'язаний до групи користувача.
• 15:04
  Він позначає групи пристроїв для базових політик, після чого вмикається валідатор.
• 15:08
  Він запитує граф і дафенда щодо сигналів відповідності, перевіряє, чи не завадить умовний доступ першому входу і перевіряє застосування правильних політик конфігурації.
• 15:16
  Якщо умовний доступ блокує новачка в перший день, валідатор створює запит на схвалення з часовим виключенням та обґрунтуванням.
• 15:23
  Консьєрж займається людськими справами. Він надсилає повідомлення в тім з менеджеру з UPN новачка статусом призначення пристрою та посиланням на стартовий набір SharePoint.
• 15:32
  Він надсилає електронний лист новачку з інструкціями на перший день, налаштуванням МФА та інформацією про ІТ-портал.
• 15:37
  Він не вставляє ваші внутрішні IP-діапазони в електронний лист.
• 15:40
  Безпека контенту перевіряє результати на предмет витоку даних і тону.
• 15:43
  Управління дотримується тієї ж концепції ременів безпеки.
• 15:46
  Керована ідентичність провіженер має права на ліцензії, але не на видалення.
• 15:49
  Модуль прийому даних не надає доступ, він лише перевіряє.
• 15:51
  PM контролює будь-які ризиковані дії, наприклад, додавання користувачів до чутливих груп.
• 15:55
  Усі дії відстежуються WebInsights та Log Analytics.
• 15:58
  Якщо HR надсилає виправлені дані, планувальник перераховує різницю, а оператор оновлює лише те, що змінилося.
• 16:03
  Жодних безглуздих змін у членстві груп.
• 16:05
  Можливість спостереження забезпечує контрольні точки.
• 16:08
  HR-інтеграція, створення Entra, призначення ліцензії, профіль AutoPilot, відправка результатів перевірки відповідності.
• 16:14
  Ви отримуєте показники SLA та автоматичні повторні спроби при тимчасових помилках граф із затримкою.
• 16:18
  Якщо в системі HR стається збій, потік не зупиняється.
• 16:21
  Він призупиняється, записується в журнал і відновлюється після усунення проблеми.
• 16:24
  Оцінки виконуються в CI на синтетичних даних, щоб виявити регресії в релевантності до того, як постраждає реальний працівник.
• 16:30
  Комбінація моделей дозволяє оптимізувати витрати.
• 16:33
  SLM для вилучення та нормалізації даних.
• 16:35
  Логічний прохід лише для рішень щодо вибору політики.
• 16:38
  Підсумки та привітальні листи групуються, коли це можливо.
• 16:41
  Мета – надання доступу з низькою затримкою та чіткістю аудиторського сліду на людському рівні.
• 16:45
  Коротка історія.
• 16:46
  Онбординг через одного агента намагався додати користувача до всіх співробітників і підрядників, бо в посади було вказано «підрядний персонал».
• 16:52
  Мультиагентний підхід виявив правило взаємного виключення у валідаторі, запитав рішення людини й уникнув миттєвої проблеми з доступом.
• 16:59
  Результат – справжнє нульове втручання для користувача.
• 17:02
  Один потік, чотири агенти, чисті схвалення та звіт, який можна показати CISO без благань до «Богів демо-версій».
• 17:08
  І так, коли відділ кадрів неминуче змінює дату початку, система перераховує в себе шкоди для бюджету ліцензій.
• 17:14
  Демонстраційний сценарій 3 – автоматизоване зміцнення безпеки.
• 17:17
  Будь ласка, нехай бітлока буде увімкнено.
• 17:19
  Дрейв безпеки, як бур'яни.
• 17:21
  Висмикнеш три – з'являться п'ять, і один із них назло вимкне бітлока.
• 17:25
  Наша мета – постійно виявляти дрейв конфігурації та безпечно його усувати за допомогою засобів контролю, які схвалив би навіть юрист.
• 17:31
  Детектор дрейву каст запитує граф та дафенда.
• 17:33
  Сак'юрсько отримує дані про відповідність Інтюн та базові конфігурації пристроїв, формуючи дельту дрейву.
• 17:39
  Фікса впроваджує зміни політик Інтюн, налаштування бітлока та кільця оновлення Віндовс.
• 17:45
  Запускає сценарії для пристроїв через Azure Automation, коли політик недостатньо.
• 17:49
  Рав'юа забезпечує дотримання правил, обмежує зміни, перевіряє обґрунтованість і вимагає схвалення людиною для ризикованих кроків.
• 17:56
  Месенджа сповіщає людей у Teams або електронною поштою з короткими планами та звітами.
• 18:02
  Процес «Детектор дрейфу» запускається за розкладом і на вимогу.
• 18:05
  Він отримує дані про відповідність пристроїв, статус бітлока, стан TPM, версію ОС, кільце оновлень та призначення політик через граф.
• 18:14
  Він порівнює кожен пристрій із золотим профілем як структуровані дані, а не як абстрактний документ.
• 18:19
  Він позначає виявлені проблеми, відсутність бітлока, слабкий метод шифрування, незастосована політика, вимкнений безпечний завантажувач, кільце оновлень поза межами.
• 18:26
  Вступає в дію плена, пропонуючи мінімальний план для кожної групи пристроїв.
• 18:30
  Для бітлока використовується політика Intune, якщо пристрій підтримує її.
• 18:34
  Якщо політика призначена, але статус вимкнено, пропонується сценарій автоматизації для повторного запуску захисту та депонування ключа вежу RayD.
• 18:41
  Для дрейфу оновлень пропонується переміщення пристрою до поетапного кільця оновлень, а не підхід оновлюй і сподівайся.
• 18:46
  Для проблем із умовним доступом пропонується часове виключення з обов'язковим обґрунтуванням.
• 18:51
  Рав'юа оцінює обґрунтованість.
• 18:54
  Чи справді детектор дрейфу посилався на поля з графта до фенда?
• 18:58
  Він перевіряє область дії, ідентифікатори пристроїв, ідентифікатори політик та тип змін.
• 19:02
  Якщо щось нагадує масові зміни на всіх пристроях, це негайно блокується.
• 19:05
  Безпека в місту перевіряється на вході та вигоді, щоб запобігти ін'єкціям у запити з будь-яких зовнішніх джерел або вставлених логів.
• 19:11
  Високоризикові дії, як от видалення конфліктуючої локальної політики, потребують підтвердження менеджером.
• 19:15
  Ідентифікатор фікса не може самостійно підвищувати свої права.
• 19:18
  Схвалення відбувається в логічній програмі з наочною карткою.
• 19:20
  Що не так? Що зміниться?
• 19:22
  Кроки для відкату та посилання на джерела.
• 19:24
  Ви підтверджуєте, фікса виконує.
• 19:25
  Оновлення політик Intune є і демпотентними, та цілеспрямованими.
• 19:28
  Виправлення бітлока використовує ранбук з явними параметрами та перевіркою коректності.
• 19:32
  Перевірено наявність TPM, підтримку OS X TSS 256 та шлях депонування.
• 19:37
  Якщо попередня перевірка не проходить, виводиться зрозуміла користувачеві помилка безпобічних ефектів.
• 19:42
  Месенджер закриває цикл.
• 19:43
  Пристрій виправлено.
• 19:45
  Звіт надходить у Teams із підрахунками, посиланнями на трасування AppInsights та CSV файлом для того,
• 19:49
  хто досі любить Excel більше за власну родину.
• 19:51
  Якщо пристрій не відповідає вимогам, перевіряльник відкриває гілку виключення з таймером і запланованими повторними спробами.
• 19:57
  Можливість спостереження.
• 19:58
  Кожен виклик інструменту відстежується і пов'язується з потоком.
• 20:01
  Ми фіксуємо зміни до та після, щоб аудит бачив невідповідності без постійного моніторингу в KQL.
• 20:06
  Ми також запускаємо агент оцінки для резюме після змін, щоб перевірити обґрунтованість і чіткість.
• 20:11
  Якщо рівень обґрунтованості падає або зростає кількість помилок,
• 20:14
  планувальник звужує пошук, зменшує розмір пакету або зупиняє деструктивні дії.
• 20:18
  Поєднання моделей SLM для вилучення та класифікації, модель міркувань для синтезу плану лише за потреби.
• 20:23
  Пакетна обробка нічного звіту.
• 20:25
  Жодних сонетів про щі.
• 20:26
  Кінцевий результат.
• 20:27
  Бітлока дійсно увімкнено.
• 20:28
  Кільця оновлень менше відхиляються від норми.
• 20:30
  Виключення задокументовані, обмежені в часі та підлягають перевірці.
• 20:32
  І ніхто не лагодить пристрій шляхом перевстановлення ОС на ноутбуках фінансового відділу під час закриття кварталу.
• 20:36
  Структура архітектури Foundry плюс SK плюс інструменти та ідентифікація.
• 20:41
  Давайте відкриємо капот, не розливши мастило на вашу квоту.
• 20:44
  Уявіть чотири рівні, які зберігають систему в нормі Foundry, Semantic, Kernel, Інструменти, Ідентифікація.
• 20:50
  Foundry – це база.
• 20:52
  Ви визначаєте агентів із суворими інструкціями, обираєте розгортання для кожної ролі, додаєте знання через Azure AI Search і реєструєте дії.
• 20:59
  Інструменти OpenARIE, Logic Apps, функції, Graph, Azure Automation, Інтерпретатор коду.
• 21:05
  Тут живуть загрози, історія запусків, трасування, оцінки та безпека.
• 21:09
  Захист вмісту, екрани запитів і перевірки захищених матеріалів працюють до і після моделей,
• 21:13
  щоб погані вхідні дані не витрачали токени, а результати не псували роботу.
• 21:16
  Semantic Kernel – це диригент.
• 21:18
  У коді ви налаштовуєте цикл планувальника, оператора та рецензента.
• 21:22
  Ви реєструєте каталоги функцій для інструментів, налаштовуєте затримку повторних спроб і додаєте токени з касування.
• 21:26
  Ви робите запити короткими, перекладаєте складність на схеми та дозволяєте SK вирішувати, який інструмент викликати, залежно від доступності та політики.
• 21:33
  Якщо Graph видає тайм-аут, SK обробляє це з джітером.
• 21:36
  Якщо обґрунтованість знижується, планувальник повертається до оточнення.
• 21:39
  Інструменти – це руки системи.
• 21:40
  Підтримуйте суворі контракти з OpenARIE.
• 21:43
  Помістіть ARIE Management попереду для регулювання версій і захисту від збою.
• 21:46
  Logic Apps обробляють схвалення та тривалі робочі процеси.
• 21:48
  Функції виконують роль клею та перетворення даних.
• 21:51
  Azure Automation виконує скрипти з обмеженнями та подальшими перевірками.
• 21:54
  Graph – це ваше джерело істини для Intune, Entra, комплеєнсу та показників безпеки.
• 21:58
  Azure AI Search надає структуровані знання за доменами.
• 22:01
  Жодної каші зізнань.
• 22:02
  Ідентифікація – це ремінь безпеки.
• 22:04
  Кожен агент має власну керовану ідентичність.
• 22:06
  Агенти моніторингу отримують права лише на читання.
• 22:08
  Агенти виправлення отримують права на запис, але ніколи права адміністратора.
• 22:10
  PM блокує будь-які деструктивні дії.
• 22:12
  Підвищення прав вимагає участі людини та має термін дії.
• 22:15
  Приватні кінцеві точки там, де важливі межі даних.
• 22:17
  Базові політики в проєктах Foundry забезпечують використання дозволених моделей, регіонів і квот.
• 22:22
  App Insights та Log Analytics збирають трасування, метрики та аудити,
• 22:25
  щоб ви могли відповісти, хто і що зробив без археології в слеп.
• 22:29
  Моделі підключаються через Endpoint висновку Foundry.
• 22:31
  Використовуйте серверлес для складних міркувань, керуйте обчисленнями для закріплених відкритих моделей.
• 22:36
  Міняйте моделі без переписування коду, але оцінюйте релевантність, обґрунтованість і пленність у CI перед впровадженням.
• 22:42
  Регіони відповідають вашим користувачам, зони даних – вашим регуляторам.
• 22:45
  Разом це нудна, надійна машина.
• 22:47
  Агенти, визначені у Foundry, оркестровані SK, живляться суворими інструментами, захищені ідентифікацією,
• 22:53
  вимірюються спостережуваністю та охороняються безпекою.
• 23:01
  Зрозуміло. Вибудовуйте мудрість завчасно, щоб не витрачати неділю на виправлення суботи.
• 23:06
  Дайте кожному агенту одну роботу.
• 23:08
  Планувальник планує, оператор оперує, рецензент рецензує.
• 23:11
  Якщо агент починає писати душевний роман, скоротіть його промп і віддайте прозу інструменту.
• 23:15
  Тримайте інструкції короткими, обмеженими та нудними.
• 23:17
  Ви отримаєте менше сюрпризів.
• 23:19
  Надавайте перевагу викликам інструментів, а не довгій прозі.
• 23:21
  Вкладайте контракти у відкритий арі, схеми у вхідні дані, а бар'єри у вихідні.
• 23:25
  Якщо інструмент очікує пристрій, надійшліть пристрій, а не може цей пристрій у фінансах.
• 23:29
  Моделі креативні, інструменти – ні.
• 23:31
  У цьому суть.
• 23:32
  Забезпечуйте мінімальні привілеї так, ніби від цього залежить ваша робота, бо так воно і є.
• 23:35
  Розділяйте ідентичності.
• 23:37
  Тільки читання для монітора, тільки запис для ремедіатора, і жодна ідентичність не має права видалення без ПМ.
• 23:41
  Підвищення прав має бути тимчасовим, обґрунтованим і зафіксованим у логах.
• 23:44
  Якщо хтось просить постійного глобального адміна, дайте йому антистрес-м'ячик і документ із політикою.
• 23:47
  Починайте з малого – два агенти, виконавець і перевіряльник.
• 23:50
  Додайте плановальника, коли цикл стане стабільним.
• 23:52
  Потім, якщо потрібно масштабуватися, не починайте з цифрової схрам команди з 12 осіб.
• 23:55
  Ось як ви відтворюєте свою оргструктуру в IAML і плачете.
• 23:57
  Змішуйте моделі, щоб скоротити витрати.
• 23:59
  SLM для вилучення, GPT-4 клас лише для міркувань там, де це важливо.
• 24:03
  Пакетні підсумки робіть вночі.
• 24:04
  Ви не платите преміальні тарифи за форматування рядка дати.
• 24:07
  Збережіть важку модель для рішень, а не для розповіді.
• 24:10
  Пам'ять додавайте в останню чергу.
• 24:12
  Використовуйте зовнішній стан як ваш AI-пошук або невелике сховище,
• 24:15
  перш ніж набивати контекстні вікна, як ручну поклажу.
• 24:17
  Метадані потоку мають бути крихітними.
• 24:19
  Якщо це не потрібно для наступного кроку, воно не передається.
• 24:21
  Логуйте все.
• 24:22
  Увімкніть трасування, ID потоків, параметри інструментів, результати затримки.
• 24:26
  Впроведжуйте оцінки в CI, щоб виявляти падіння релевантності
• 24:29
  та обґрунтованості до того, як вони потраплять у продакшні.
• 24:31
  Сповіщайте, коли падає обґрунтованість, а не твітер.
• 24:34
  Бар'єри безпеки перед швидкістю, схвалення для деструктивних інструментів.
• 24:36
  Режим тестового запуску безпобічних ефектів.
• 24:39
  Поступове розгортання за групами пристроїв або регіонами.
• 24:41
  Якщо ваш план розгортання, все одразу, сподіваюся, ваше резюме оновлене.
• 24:44
  Будуйте з розрахунком на відмову.
• 24:45
  Повторюйте спроби з джітером.
• 24:47
  Послабте обмеження в графі.
• 24:48
  Використовуйте запобіжники в управлінні АРІ.
• 24:50
  І демпотентні плани дій.
• 24:51
  Якщо крок можна безпечно повторити, ви спите спокійніше.
• 24:54
  Нарешті, документуйте свої політики як дані.
• 24:56
  Правила взаємовиключення пакети ліцензій, базові налаштування пристроїв, переведіть їх у структуровану форму.
• 25:01
  Моделі можуть обирати, але не повинні вигадувати.
• 25:03
  Ось як зберегти корисність агентів та обмежити зону можливих збоїв.
• 25:06
  Якщо запам'ятаєте одне, знайте, окремі агенти допомагають, але команди агентів сплановані, керовані інструментами та з обмеженими правами тихо змінюють ваше середовище, поки ви вдаєте, що спите.
• 25:15
  Якщо це вам близько, підпишіться та дивіться продовження, де я викладу репозиторій Semantic Kernel та шаблон BICEP, щоб ви могли безсоромно їх запозичити.
• 25:22
  Хочете епізод про агентів оцінювання, які підтверджують виконання ваших обіцянок?
• 25:25
  Він у черзі на наступний тиждень.