WEBVTT

00:00:00.000 --> 00:00:04.340
Вы внедряете Капайлот в ожидании всплеска продуктивности, но вместо прорыва наблюдаете

00:00:04.340 --> 00:00:09.180
300% скачок инцидентов утечки данных. Мы полагали, что и проявит нашу гениальность,

00:00:09.420 --> 00:00:12.480
но на деле он в основном обнаруживает наши проблемы с правами доступа.

00:00:12.620 --> 00:00:16.920
Группа «Все пользователи» в вашем SharePoint – это сейчас самая большая дыра в безопасности,

00:00:17.100 --> 00:00:21.380
работающая как открытая дверь, которую никто не закрыл, так как данные были заперты в подвале.

00:00:21.540 --> 00:00:26.360
Теперь эти данные стали интерактивными. Ваша текущая стратегия меток конфиденциальности – это

00:00:26.360 --> 00:00:30.460
не щит. Это кладбище данных, которое скрывает информацию от тех, кому она нужна,

00:00:30.600 --> 00:00:34.220
и при этом не мешает ИИ выдавать неподобающие сведения неподобающим людям.

00:00:34.380 --> 00:00:39.180
Это кризис изолированности совместного ИИ. Сегодня мы переходим от сдерживания к контексту и

00:00:39.180 --> 00:00:43.800
собираемся спасти ваши инвестиции в ИИ, исправив структурную ложь в основе вашей модели управления

00:00:43.800 --> 00:00:48.360
данными. Парадокс наследования. Фундаментальный изъян большинства внедрений ИИ заключается в

00:00:48.360 --> 00:00:52.340
непонимании того, как мыслит машина. И хотя вы можете думать, что Капайлот сам решает,

00:00:52.340 --> 00:00:55.700
кому и что показывать, на самом деле это не так. Капайлот – это зеркало,

00:00:55.700 --> 00:00:59.620
отражающее вашу организационную энтропию, он не создает новых прав доступа. Он просто

00:00:59.620 --> 00:01:03.840
задействует тот доступ, который вы сами раздали много лет назад. Представьте это как эффект

00:01:03.840 --> 00:01:08.480
прожектора. До появления ИИ избыточный доступ был скрытым, как беспорядок в архивном шкафу в

00:01:08.480 --> 00:01:12.920
подвале, куда никто не заглядывал, но и делает эту скрытую проблему видимой на машинной скорости.

00:01:13.060 --> 00:01:17.280
Если младший аналитик запросит сводку недавних стратегических изменений, а ваша папка по слияниям

00:01:17.280 --> 00:01:21.380
и поглощениям открыта для сотрудников, ИИ выдаст резюме о сделке, которую вы еще не анонсировали.

00:01:21.380 --> 00:01:25.920
Это не взлом, это особенность вашей собственной архитектуры. Реальность такова, что охват

00:01:25.920 --> 00:01:30.920
ручной маркировки в среднем предприятии редко превышает 10%, потому что мы 10 лет просили

00:01:30.920 --> 00:01:35.780
пользователей тегеровать файлы, а они этого просто не делали. Мы полагались на принцип «настроил и

00:01:35.780 --> 00:01:40.040
забыл» для меток конфиденциальности, считая, что если файл помечен как общедоступный,

00:01:40.120 --> 00:01:44.860
он навсегда останется таким. Но данные изменчивы, документ, который вчера был открытым,

00:01:44.920 --> 00:01:49.180
сегодня может содержать конфиденциальный ответ на запрос. Полагаясь на статические метки,

00:01:49.180 --> 00:01:54.140
мы создаем невидимые барьеры для межотраслевого взаимодействия. Метка, строго конфиденциально,

00:01:54.320 --> 00:01:59.140
на плане проекта может помешать отделу маркетинга увидеть дату запуска, необходимую для работы.

00:01:59.320 --> 00:02:03.660
Это создает изолированность, и именно из-за таких барьеров ваш и кажется не помощником,

00:02:03.820 --> 00:02:07.780
а ограниченным в правах библиотекарем. Мы построили систему, основанную на предположении,

00:02:07.920 --> 00:02:11.700
что можно классифицировать мир один раз и забыть об этом, но в среде сотрудничества эта модель

00:02:11.700 --> 00:02:16.960
рушится. Если метки отсутствуют и видят слишком много, а если они есть, то часто слишком жесткие,

00:02:16.960 --> 00:02:22.360
что мешает И связывать данные между отделами. Сейчас мы видим огромный разрыв между ожиданиями

00:02:22.360 --> 00:02:27.820
руководства от ИИ и возможностями архитектуры данных. Нельзя создать эффективного И агента,

00:02:28.080 --> 00:02:33.160
если данные заперты в папках в стиле 90. Парадокс наследования прав означает,

00:02:33.360 --> 00:02:38.220
что безопасность вашего ИИ ограничена лишь ошибкой администратора SharePoint от 2014 года.

00:02:38.480 --> 00:02:42.860
Нужно признать, что нынешний подход к классификации провалился, так как он статичен,

00:02:42.860 --> 00:02:47.920
требует ручного труда и рассматривает данные как объект для хранения, а не актив для использования.

00:02:48.160 --> 00:02:51.920
Большинство организаций сейчас находятся в чистилище пилотных проектов, потому что через

00:02:51.920 --> 00:02:56.220
шесть недель обнаруживают, что их право доступа – это полный хаос. Они пытаются исправить это

00:02:56.220 --> 00:03:01.620
добавлением новых меток, но это лишь создает новые силосы и не решает фундаментальную проблему

00:03:01.620 --> 00:03:07.160
прозрачности. Нам нужен переход не к лучшим тягам, а к лучшей модели. Мы фокусировались на «что»,

00:03:07.160 --> 00:03:11.940
то есть на самом файле. Но нужно начать фокусироваться на «кто», «где» и «почему».

00:03:11.940 --> 00:03:16.360
Проблема не только в отсутствии меток, но и в том, что имеющиеся статичны и не учитывают

00:03:16.360 --> 00:03:21.040
реалии того, как сегодня происходит работа. Работа динамична, поэтому и наша безопасность

00:03:21.040 --> 00:03:25.980
должна быть такой же. Если мы это не исправим, ИИ продолжат галлюцинировать, глядя не на те данные,

00:03:26.140 --> 00:03:29.660
или, что еще хуже, будет выдавать правду о том, что должно было быть скрыто.

00:03:29.820 --> 00:03:34.380
Чтобы разорвать цикл переделок, мы должны пересмотреть базовую модель предоставления доступа.

00:03:34.380 --> 00:03:38.940
Высокая цена передела. Мы говорим о продуктивности и как о воловом показателе,

00:03:39.180 --> 00:03:44.580
радуясь 9 сэкономленным часам в месяц и считаем, что дело сделано. Но реальность гораздо сложнее,

00:03:44.820 --> 00:03:50.220
около 40% времени, которое сотрудники экономят с помощью ИИ, тут же тратится на исправление его

00:03:50.220 --> 00:03:54.920
ошибок. Это и есть скрытое трение разрозненных данных. Когда у Капайлот нет доступа к качественным

00:03:54.920 --> 00:03:59.720
данным, финальному контракту, реальному бюджету или утвержденному плану проекта, он не останавливается.

00:03:59.720 --> 00:04:04.420
Он начинает гадать. Он берет темные данные, которые доступны, например, старый черновик из общей

00:04:04.420 --> 00:04:08.560
папки или случайное сообщение в чате, и строит ответ на их основе. Результатом становится цикл

00:04:08.560 --> 00:04:11.980
переделок, который незаметно истощает ваш возврат инвестиций. Мы действительно можем

00:04:11.980 --> 00:04:16.000
количественно оценить этот цифровой долг. Для ваших лучших сотрудников, активных пользователей,

00:04:16.120 --> 00:04:19.940
которые чаще всего обращаются к этим инструментам, такие переделки означают потерю примерно

00:04:19.940 --> 00:04:24.040
полутора недель рабочего времени в год. Задумайтесь об этом. Вы платите за премиум лицензии,

00:04:24.180 --> 00:04:28.360
чтобы экономить время. Но из-за разрозненности данных ваши лучшие специалисты тратят почти две полные

00:04:28.360 --> 00:04:32.460
рабочие недели только на исправление ошибок машины. По сути, они работают высокооплачиваемыми

00:04:32.460 --> 00:04:36.100
корректорами для системы, которая должна была стать их вторым пилотом. Это происходит потому,

00:04:36.320 --> 00:04:40.640
что жесткая классификация создает информационный вакуум. Если ей закрыт доступ к основной системе

00:04:40.640 --> 00:04:44.740
из-за устаревшей метки конфиденциальности, он заполнит этот вакуум любым удобным источником,

00:04:44.860 --> 00:04:48.880
который сможет найти. В таких отделах, как финансы или кадры, это приводит к результатам,

00:04:48.980 --> 00:04:53.560
которые выглядят убедительно, но ошибочны. Финансовый менеджер может запросить сводку квартальных

00:04:53.560 --> 00:04:58.140
расходов. Если доступ к реальным отчетам и RP закрыт, а черновой вариант документа лежит в

00:04:58.140 --> 00:05:03.360
общем канале Teams и не будет использовать этот черновик для сводки. Затем менеджер тратит 20 минут,

00:05:03.580 --> 00:05:08.100
выискивая несоответствие. Это и есть конфликт между общей эффективностью и реальной ценностью.

00:05:08.220 --> 00:05:13.980
Если создание отчета занимает 2 минуты, а проверка цифр – 20 минут, потому что и не видел источник

00:05:13.980 --> 00:05:18.800
истины, вы ничего не выиграли. Вы просто перенесли трудозатраты с этапа создания на этап исправления.

00:05:18.800 --> 00:05:22.440
Эти переделки – не просто досадная помеха, это симптом структурной проблемы.

00:05:22.440 --> 00:05:26.960
Мы годами выстраивали хранилище данных для защиты информации, но в эпоху генеративного и эти

00:05:26.960 --> 00:05:31.360
силосы превратились в повязку на глазах. Когда и ослеплен, он начинает галлюцинировать.

00:05:31.480 --> 00:05:34.740
Он пытается угодить пользователю, связывая воедино то, что не следует связывать.

00:05:34.900 --> 00:05:38.940
Мы видим организации, где уровень переделок настолько высок, что сотрудники начинают терять

00:05:38.940 --> 00:05:43.240
доверие к инструменту. Они перестают просить и о сложном анализе и возвращаются к использованию

00:05:43.240 --> 00:05:47.520
его для написания простых писем. Как только это происходит, ваша и стратегия провалена.

00:05:47.520 --> 00:05:51.840
Вы платите за двигатель, но используете только фары. Чтобы исправить этот цикл переделок,

00:05:51.840 --> 00:05:54.680
нужно перестать смотреть на ИИ и начать разбираться в инфраструктуре.

00:05:54.800 --> 00:05:59.180
Качественные данные есть, блестящие идеи существуют, но они заперты за стеной устаревших

00:05:59.180 --> 00:06:03.200
прав доступа и статичных меток, созданных для мира, где весь поиск выполняли люди.

00:06:03.400 --> 00:06:08.240
Нам нужно перейти к модели, где и видят-то, что ему нужно, именно тогда, когда это нужно,

00:06:08.440 --> 00:06:13.060
без ущерба для безопасности. Нам нужно пересмотреть базовую модель предоставления доступа,

00:06:13.060 --> 00:06:18.140
ведь пока и работает с неполным контекстом, вам придется работать сверхурочно, исправляя результаты.

00:06:18.140 --> 00:06:21.620
Это расходы, которые не может позволить себе игнорировать ни одна организация.

00:06:21.780 --> 00:06:25.840
От изоляции к контексту нам пора перестать воспринимать безопасность как крепостную стену.

00:06:26.180 --> 00:06:30.200
Десятилетиями индустрия полагалась на модель жесткого периметра. Вы были либо внутри сети,

00:06:30.440 --> 00:06:34.300
либо снаружи, но этот мир остался в прошлом. Сегодня периметр стал проницаемым.

00:06:34.480 --> 00:06:38.900
Люди работают из дома, используют неуправляемые устройства и сотрудничают с внешними подрядчиками.

00:06:38.900 --> 00:06:44.280
В таких условиях старая модель изоляции, когда вы запираете данные в папке и считаете их защищенными,

00:06:44.280 --> 00:06:48.500
потому что папка приватна – опасная иллюзия. Это опасно, потому что предполагает,

00:06:48.700 --> 00:06:52.640
что угроза только извне. Но в эпоху Капайлот реальная угроза – это бесконтрольный рост

00:06:52.640 --> 00:06:57.080
внутренних прав, накопившийся за годы. Нам нужно перейти от стратегии изоляции к стратегии

00:06:57.080 --> 00:07:01.540
контекста. Старая модель была построена на структуре. Она исходила из того, что конфиденциальность

00:07:01.540 --> 00:07:05.440
файла – это неизменный атрибут. Вы помечали документ как конфиденциальный, и на этом все

00:07:05.440 --> 00:07:10.440
заканчивалось. Но в среде совместной работы с и такой метки недостаточно. Она не дает нам нужной информации.

00:07:10.440 --> 00:07:14.320
Она не учитывает, кто делает запрос, какое устройство использует и где находится.

00:07:14.560 --> 00:07:18.980
Вот почему мы наблюдаем массовый переход к управлению доступом – DAC. Это не просто

00:07:18.980 --> 00:07:24.160
техническое обновление, это смена философии. Процесс принятия решений переносится с момента

00:07:24.160 --> 00:07:29.680
создания файла на миллисекунду запроса данных. Это разница между статичным замком и умным датчиком.

00:07:29.840 --> 00:07:34.400
К 2026 году индустрия требует перехода на управление доступом на основе атрибутов,

00:07:34.520 --> 00:07:39.560
или ABC. Это фундамент современной системы идентификации. Вместо того, чтобы полагаться на одну статичную

00:07:39.560 --> 00:07:43.660
метку, ABC в реальном времени оценивает десятки различных сигналов риска. Система учитывает роль

00:07:43.660 --> 00:07:47.560
пользователя, конечно, но также и состояние его ноутбука. Она учитывает его физическое

00:07:47.560 --> 00:07:51.760
местоположение. Она даже анализирует его поведение. Если пользователь, который обычно работает

00:07:51.760 --> 00:07:55.500
только с маркетинговыми файлами, внезапно просит копайлот суммировать всю базу данных зарплат,

00:07:55.660 --> 00:07:59.440
находясь в кофейне в другой стране, система не должна смотреть только на метку конфиденциальности.

00:07:59.600 --> 00:08:03.560
Она должна проанализировать контекст и отказать. Так мы переходим от вопроса, есть ли у файла

00:08:03.560 --> 00:08:08.080
метка. К вопросу, должен ли этот пользователь видеть данные прямо сейчас. Это тонкий сдвиг с огромными

00:08:08.080 --> 00:08:12.440
последствиями. Это позволяет нам быть более лояльными при низком риске и более строгими при

00:08:12.440 --> 00:08:16.700
высоком. Это разрушает разрозненность данных, поскольку открывает доступ точно в срок.

00:08:16.860 --> 00:08:21.540
Если отделу маркетинга нужно увидеть строго конфиденциальную дату запуска, система может

00:08:21.540 --> 00:08:25.920
предоставить им временный доступ только для чтения на основе контекста текущего проекта,

00:08:26.100 --> 00:08:30.420
не нарушая при этом безопасность файла навсегда. Это единственный способ обеспечить

00:08:30.420 --> 00:08:35.720
межведомственную аналитику, которую обещает ИИ, не превращая ваш арендатор в зону бесконтрольного

00:08:35.720 --> 00:08:40.480
доступа к данным. Окупаемость таких динамических систем уже становится очевидной. Организации,

00:08:40.600 --> 00:08:43.660
которые отказываются от статических меток в пользу контекстно-зависимой модели,

00:08:43.800 --> 00:08:48.360
отмечают снижение страховых взносов от киберрисков на 15-30%. Почему? Потому что страховщики

00:08:48.360 --> 00:08:52.200
знают, что статические метки легко обойти или проигнорировать. Динамические системы,

00:08:52.300 --> 00:08:55.780
напротив, гораздо сложнее взломать. Они обеспечивают уровень непрерывной проверки,

00:08:55.900 --> 00:08:59.360
с которым статические модели просто не могут сравниться. Они уменьшают радиус поражения при

00:08:59.360 --> 00:09:02.240
компрометации учетной записи, поскольку злоумышленник не может просто унаследовать

00:09:02.240 --> 00:09:06.840
годы небрежно настроенных разрешений. Каждый запрос – это новая оценка. Каждое взаимодействие – это

00:09:06.840 --> 00:09:11.320
новая возможность подтвердить доверие. Это не просто теоретический сдвиг для IT-архитекторов.

00:09:11.420 --> 00:09:15.360
Это требование выживания для следующей волны агент новой ИИ. Переходя к агентам,

00:09:15.480 --> 00:09:19.220
которые могут действовать от нашего имени, планировать встречи, переводить деньги или обновлять

00:09:19.220 --> 00:09:23.380
записи, мы больше не можем полагаться на модель безопасности «настроил и забыл». Нам нужна система,

00:09:23.600 --> 00:09:27.520
которая понимает намерения, стоящие за действием. Нам нужна безопасность, которая также умна,

00:09:27.520 --> 00:09:32.020
как и защищаемый ею ИИ. Это подводит нас к технической дорожной карте. Ведь пока философия

00:09:32.020 --> 00:09:35.960
меняется, инструменты для ее реализации наконец-то появляются в экосистеме Perview.

00:09:36.120 --> 00:09:41.380
Дорожная карта Perview на 2026 год показывает, что переход к контекстно-зависимой аналитике

00:09:41.380 --> 00:09:45.640
наконец-то воплощается в архитектуре экосистемы Microsoft. Мы оставляем позади эпоху,

00:09:45.720 --> 00:09:50.720
когда Perview был лишь инструментом для отчетности о соответствии, и к 2026 году он превратился в движок

00:09:50.720 --> 00:09:54.820
диагностики в реальном времени. Одним из наиболее значительных изменений стал переход к постоянной

00:09:54.820 --> 00:09:59.400
диагностике для систем DLP на конечных точках. Раньше устранение сбоя политики означало неделю

00:09:59.400 --> 00:10:03.780
переписки между IT-отделом и пользователем, пытающимися воспроизвести ошибку, которая случилась

00:10:03.780 --> 00:10:08.220
лишь однажды. Теперь эти диагностические следы хранятся локально на устройстве в защищенном

00:10:08.220 --> 00:10:13.180
сжатом формате в течение 90 дней. Это позволяет системе точно анализировать, почему конкретный файл

00:10:13.180 --> 00:10:17.320
был заблокирован или почему метка не применилась, без передачи самого конфиденциального контента в

00:10:17.320 --> 00:10:21.840
облако. Это локальная видимость в сочетании с глобальным обеспечением политик. Эта диагностическая

00:10:21.840 --> 00:10:26.360
мощь усиливается инструментами интерпретации на базе ИИ. Мы достигли такого уровня сложности,

00:10:26.360 --> 00:10:30.600
что администраторы уже не могут вручную отслеживать различия между десятком разных политик DLP.

00:10:30.760 --> 00:10:34.660
При изменении политики система теперь создает краткое описание на естественном языке,

00:10:34.820 --> 00:10:39.180
объясняя, что именно было изменено и какие группы пользователей затронуты. Она также показывает

00:10:39.180 --> 00:10:43.740
потенциальное влияние на совместную работу, что снижает риск дрейфа. Политик. Это происходит,

00:10:43.920 --> 00:10:47.300
когда правила безопасности становятся настолько запутанными, что начинают блокировать легитимную

00:10:47.300 --> 00:10:51.400
деятельность. Эти инструменты позволяют отделу безопасности стать помощниками, а не

00:10:51.400 --> 00:10:56.560
сторожими, разъясняя правила работы на понятном для бизнеса языке. Важнейшей частью этой дорожной

00:10:56.560 --> 00:11:02.440
карты является роль ограниченного поиска SharePoint или RSS. Это StopCran для вашего внедрения ИИ.

00:11:02.580 --> 00:11:06.740
Он позволяет явно исключить сайты с высоким уровнем риска, такие как документы совета директоров,

00:11:06.900 --> 00:11:11.400
данные о зарплатах или юридическая стратегия из базы знаний Copilot. Еще до использования меток

00:11:11.400 --> 00:11:16.280
конфиденциальности вы можете задействовать RSS, чтобы гарантировать, что и не увидят самые уязвимые

00:11:16.280 --> 00:11:21.500
зоны вашего тенанта. Это базовый уровень защиты, который признает, что не все данные одинаково

00:11:21.500 --> 00:11:25.560
важны. Это дает вам передышку для исправления проблем с правами доступа без необходимости

00:11:25.560 --> 00:11:29.420
останавливать весь эксперимент с ИИ. Мы также наблюдаем масштабное расширение возможности

00:11:29.420 --> 00:11:34.260
автоматической классификации данных. Цель на 2026 год – обеспечение безопасности по умолчанию.

00:11:34.480 --> 00:11:38.200
Ваши библиотеки SharePoint больше не являются пассивными хранилищами, они становятся активными

00:11:38.200 --> 00:11:42.100
участниками вашей системы безопасности. Когда файл загружается в определенную библиотеку,

00:11:42.100 --> 00:11:45.940
к нему автоматически применяется стандартная метка этой библиотеки. Если файл

00:11:45.940 --> 00:11:49.420
содержит типы конфиденциальной информации, система теперь может переопределять вручную

00:11:49.420 --> 00:11:53.560
установленные метки с низким приоритетом. Это устраняет пробелы в покрытии, которые годами были

00:11:53.560 --> 00:11:57.840
проблемой ручных систем. Это гарантирует, что даже если пользователь забудет пометить документ,

00:11:57.980 --> 00:12:01.440
платформа его подстрахует. Это переход от добровольной системы к обязательной

00:12:01.440 --> 00:12:05.600
автоматизированной инфраструктуре. Для управления этим в масштабе мы все чаще полагаемся на

00:12:05.600 --> 00:12:09.500
графапе для пользовательской аналитики использования. Теперь мы можем заглянуть под капот,

00:12:09.500 --> 00:12:14.440
чтобы увидеть, какие именно отделы работают изолированно. Если у команды R и D 90% работы требуют

00:12:14.440 --> 00:12:18.020
переделки, потому что им закрыт доступ к инженерным спецификациям, данные это покажут.

00:12:18.160 --> 00:12:21.600
Мы можем выявить узкие места, где жесткая классификация снижает продуктивность,

00:12:21.780 --> 00:12:25.460
и корректировать политики в режиме реального времени. Так мы переходим от реактивной модели

00:12:25.460 --> 00:12:29.500
безопасности к проактивной стратегии управления. Мы используем данные, чтобы видеть,

00:12:29.660 --> 00:12:33.340
где система дает сбои, не дожидаясь жалоб пользователей или утечек информации.

00:12:33.500 --> 00:12:37.200
Но даже с лучшими инструментами стратегия не сработает без поддержки руководства.

00:12:37.200 --> 00:12:40.880
У вас может быть самая продвинутая настройка перью в мире, но если руководство по-прежнему

00:12:40.880 --> 00:12:44.820
рассматривает данные как нечто, что нужно накапливать, вы никогда не раскроете весь потенциал и

00:12:44.820 --> 00:12:49.440
это подводит нас к новому типу риска, который возникает снизу вверх. Это вызов, исходящий не от

00:12:49.440 --> 00:12:53.320
хакеров или внешних угроз, а от ваших собственных сотрудников, стремящихся к продуктивности.

00:12:53.480 --> 00:12:56.180
Нам нужно поговорить о дилемме гражданского разработчика.

00:12:56.360 --> 00:13:00.200
Дилемма гражданского разработчика. Мы являемся свидетелями крупнейшего

00:13:00.200 --> 00:13:03.480
взрыва нерегулируемого творчества в истории корпоративных вычислений.

00:13:03.480 --> 00:13:07.900
Сейчас в экосистеме Microsoft насчитывается более 1 миллиона лоу-код-решений.

00:13:07.900 --> 00:13:12.680
Мы дали сотрудникам возможность создавать собственные приложения, потоки, а теперь и собственные,

00:13:12.820 --> 00:13:16.820
и агенты. Но у этих расширенных возможностей есть и обратная сторона. Мы перешли от теневых

00:13:16.820 --> 00:13:20.700
и так к теневому, и где технически неподготовленные пользователи создают сложные агенты на основе

00:13:20.700 --> 00:13:24.280
неконтролируемых и разрозненных данных. Это риск неконтролируемого разрастания агентов.

00:13:24.440 --> 00:13:29.200
Это происходит, когда маркетинговый координатор создает кастомный GPT в Copilot Studio для ответов

00:13:29.200 --> 00:13:33.280
на запросы поставщиков, но непреднамеренно привязывает его к сайту SharePoint, содержащему

00:13:33.280 --> 00:13:37.900
все контракты компании с 2012 года. Дилемма заключается в том, что мы не можем просто

00:13:37.900 --> 00:13:41.840
все отключить. Если вы лишите людей возможности решать свои собственные проблемы, вы убьете

00:13:41.840 --> 00:13:46.000
саму гибкость, которую призван обеспечить, и вместо этого мы должны перейти к многоуровневой

00:13:46.000 --> 00:13:50.200
модели управления. Не все агенты одинаковы. Лоу-код-инструмент, который помогает человеку

00:13:50.200 --> 00:13:54.040
суммировать собственные электронные письма с помощью стандартных коннекторов Teams. Это малорисковый

00:13:54.040 --> 00:13:57.900
актив, который должен обходить сложный процесс проверки. Но если агент затрагивает систему

00:13:57.900 --> 00:14:02.960
учета, такую как Dataverse или конфиденциальную базу данных SQL, ему нужен привратник. Мы должны

00:14:02.960 --> 00:14:07.080
перестать рассматривать гражданскую разработку как единую категорию и начать воспринимать ее

00:14:07.080 --> 00:14:11.200
как спектр рисков. Отрасль отходит от старой концепции гражданской разработки в сторону того,

00:14:11.440 --> 00:14:15.880
что мы теперь называем персональной сборкой с помощью E. Разница едва заметна, но критически

00:14:15.880 --> 00:14:20.600
важна. В старом мире пользователь был разработчиком, а в новом мире пользователь — это оркестрата.

00:14:20.740 --> 00:14:26.200
Он направляет E, чтобы тот создал решение за него. Это делает ограничители в Copilot Studio важнее

00:14:26.200 --> 00:14:30.000
самого кода. Нам нужно внедрить уровни модерации контента, которые не дадут агентам

00:14:30.000 --> 00:14:33.280
галлюцинировать или допускать утечки данных из-за атак через инъекции промптов,

00:14:33.420 --> 00:14:37.000
о возможности которых пользователь даже не подозревал. Вы же не позволите летнему стажеру

00:14:37.000 --> 00:14:40.680
настраивать правила Брандмауэра, поэтому не стоит позволять им создавать агентов с доступом

00:14:40.680 --> 00:14:44.820
на чтение ко всей корпоративной Вики. Решение здесь структурное. Нам нужно автоматизировать

00:14:44.820 --> 00:14:49.560
соблюдение политик предотвращения утечки данных в рамках лоу-код-среды. Если пользователь попытается

00:14:49.560 --> 00:14:53.840
подключить и агента к внешне неуправляемой учетной записи Dropbox, система должна немедленно

00:14:53.840 --> 00:14:58.040
это заблокировать. Если они попытаются создать бота, который запрашивает библиотеку с грифом,

00:14:58.240 --> 00:15:02.160
строго конфиденциально, развертывание должно инициировать автоматическую ручную проверку

00:15:02.160 --> 00:15:06.460
и Т-командой. Это создает путь для инноваций, безопасный по своей архитектуре. Это позволяет

00:15:06.460 --> 00:15:10.300
разработчикам создавать продукты, гарантируя, что самые ценные активы организации остаются за

00:15:10.300 --> 00:15:14.320
контекстно-зависимыми барьерами, о которых мы говорили. Мы вступаем в эпоху, когда каждый сотрудник

00:15:14.320 --> 00:15:18.140
является потенциальным архитектором интеллектуального потенциала компании. При правильном управлении

00:15:18.140 --> 00:15:22.300
это дает огромное конкурентное преимущество, но на самотеке превращается в катастрофический риск.

00:15:22.420 --> 00:15:26.320
Цель состоит не в том, чтобы остановить разрастание, а в том, чтобы управлять потоком. Нам нужно

00:15:26.320 --> 00:15:29.940
предоставить пользователям-разработчикам готовые шаблоны и безопасные зоны, где они могут

00:15:29.940 --> 00:15:34.560
экспериментировать, не подвергая риску жемчужины компании. Это гарантирует, что создаваемые ими агенты

00:15:34.560 --> 00:15:38.840
будут продолжением нашей стратегии управления, а не исключением из нее. Это подводит нас к последнему

00:15:38.840 --> 00:15:42.380
препятствию – убедить руководство высшего звена относиться к доступу как к стратегическому активу.

00:15:42.380 --> 00:15:46.180
Невозможно управлять миллионом агентов из подвала. Вам необходимо согласование на уровне

00:15:46.180 --> 00:15:50.060
руководства. Пришло время перенести обсуждение из серверной в зал заседаний совета директоров.

00:15:50.180 --> 00:15:54.000
Стратегия привлечения поддержки руководства. Техническая битва за контекстно-зависимую

00:15:54.000 --> 00:15:57.940
безопасность выигрывается в коде, но стратегическая битва все еще проигрывается в залах совещаний.

00:15:58.140 --> 00:16:02.640
Многие годы управление идентификацией и доступом считалось чем-то вроде сантехники. Это было задачей

00:16:02.640 --> 00:16:08.940
для технических специалистов, пока бизнес фокусировался на росте. В 2026 году такой подход является обузой.

00:16:08.940 --> 00:16:13.360
Мы должны переосмыслить весь диалог, потому что идентификация – это больше не просто логин.

00:16:13.500 --> 00:16:17.900
Это ключевая плоскость управления цифровым доверием. Если ваше руководство этого не понимает,

00:16:18.080 --> 00:16:22.320
внедрение и останется лишь серией дорогостоящих и разрозненных экспериментов. Нам нужно перестать

00:16:22.320 --> 00:16:25.880
представлять безопасность как центр затрат. Вместо этого мы должны позиционировать ее как

00:16:25.880 --> 00:16:29.260
инструмент для ускорения принятия решений. Большинство руководителей воспринимают безопасность

00:16:29.260 --> 00:16:33.440
как череду отказов. Нет, вы не можете использовать этот инструмент. Нет, вы не можете делиться этим файлом.

00:16:33.560 --> 00:16:38.800
Но современная структура идентификации делает обратное. Она дает «да», которая позволяет бизнесу двигаться быстрее.

00:16:38.800 --> 00:16:43.300
Когда у вас есть постоянная контекстно-зависимая проверка, вы можете подключить нового партнера

00:16:43.300 --> 00:16:47.460
за часы, а не за недели. Вы можете предоставить консультанту доступ ровно к тому, что нужно для

00:16:47.460 --> 00:16:51.280
трехдневного проекта, а затем увидеть, как этот доступ автоматически исчезнет, как только он

00:16:51.280 --> 00:16:56.020
закончит работу. Речь не об ограничениях, а о гибкости. Речь идет о создании среды, где нужные люди

00:16:56.020 --> 00:16:59.640
могут действовать на основе нужной информации без проволочек, связанных с ручным согласованием.

00:16:59.780 --> 00:17:03.980
Мы видим, во что обходится игнорирование этого на рынке слияний и поглощений. Возникает огромный

00:17:03.980 --> 00:17:08.380
разрыв в зрелости между организациями, освоившими управление идентификацией, и теми, кто все еще

00:17:08.380 --> 00:17:12.620
полагается на устаревшие статические модели. Когда высокозрелая компания поглощает конкурента,

00:17:12.760 --> 00:17:16.460
она может интегрировать новый штат в свою и ее экосистему за считанные дни, тогда как для

00:17:16.460 --> 00:17:20.540
компаний с плохой гигиеной идентификации интеграция затягивается на месяцы, и эта задержка

00:17:20.540 --> 00:17:24.180
приводит к потере стоимости, блокируя синергию, ради которой затевалось слияние.

00:17:24.320 --> 00:17:28.200
Плохое управление идентификацией – это прямой удар по стоимости компании после слияния.

00:17:28.320 --> 00:17:32.140
Это бремя для баланса, которое большинство генеральных директоров еще даже не оценили.

00:17:32.140 --> 00:17:35.840
Вот почему предложение увеличить бюджет на инфраструктуру идентификации на 5-20%.

00:17:35.840 --> 00:17:39.460
Это не запрос на дополнительные расходы на безопасность. Это инвестиция в инфраструктуру

00:17:39.460 --> 00:17:42.760
роста. Это цифровой аналог создания сети скоростных железных дорог между вашими

00:17:42.760 --> 00:17:45.660
изолированными хранилищами данных. Вы переходите от жесткого периметра,

00:17:45.760 --> 00:17:49.860
который все пытаются обойти, к модели непрерывной проверки, которая действительно поддерживает

00:17:49.860 --> 00:17:53.820
так, как работают люди. Вы говорите руководству, что если они хотят пятикратного роста

00:17:53.820 --> 00:17:57.820
производительности, который обещает И, им нужно оплатить фундамент, который обеспечит

00:17:57.820 --> 00:18:01.960
его безопасность. Вам нужно сместить фокус защиты данных на управление потоками

00:18:01.960 --> 00:18:05.720
интеллектуальной информации. Переход к контекстно-зависимой модели – единственный

00:18:05.720 --> 00:18:09.940
способ построить устойчивое предприятие в эпоху агентного ИИ. Это позволяет организации

00:18:09.940 --> 00:18:12.740
масштабировать свой интеллект, не масштабируя при этом свои риски.

00:18:12.860 --> 00:18:15.960
Когда руководство компании начинает относиться к доступу как к стратегическому

00:18:15.960 --> 00:18:19.720
активу, вся культура компании меняется. Безопасность становится общей ответственностью,

00:18:19.820 --> 00:18:22.960
а данные – ликвидным ресурсом, а не секретом, который прячут под замком.

00:18:22.960 --> 00:18:26.600
Пора перестать смотреть на стоимость инструментов и начать оценивать стоимость трения,

00:18:26.760 --> 00:18:30.580
потому что в эпоху и побеждает самая быстрая компания, а вы не сможете быть быстрыми,

00:18:30.580 --> 00:18:35.860
если ваши данные заперты в силосах. Ваша задача на 2026 год ясна. Вы должны провести аудит

00:18:35.860 --> 00:18:38.820
долговых обязательств по правам доступа, прежде чем масштабировать лицензии на ИИ.

00:18:38.940 --> 00:18:43.720
Технологии готовы, но ваша архитектура, скорее всего, нет. Задача на следующий квартал – внедрить

00:18:43.720 --> 00:18:48.420
обязательную автомаркировку и провести 90-дневную очистку ресурсов, чтобы закрыть самые очевидные

00:18:48.420 --> 00:18:53.200
бреши. Хватит прятать данные. Начните ими управлять. Если вы хотите поделиться успехами в разрушении

00:18:53.200 --> 00:18:56.660
барьеров или обсудить, как ваша команда переходит к контекстно-зависимым правам доступа,

00:18:56.660 --> 00:18:59.820
свяжитесь с Мирко Питерсом в LinkedIn. Давайте построим модель интеллектуальной работы,

00:18:59.980 --> 00:19:03.140
которая действительно эффективна. Подписывайтесь, чтобы узнать больше о будущем сферы труда.

00:19:03.320 --> 00:19:05.440
Оставайтесь в безопасности. Оставайтесь продуктивными.