Предположение о том, что ваши сотрудники будут добровольно помечать каждый созданный ими фрагмент данных, является самым большим недостатком вашей модели безопасности. Мы потратили годы на создание сложных систем управления, которые полагаются на одно, на осознанное и правильное решение человека каждый раз, когда он нажимает кнопку «Сохранить». Но реальность сурова. Ручная разметка используется в среднем лишь в 30% предприятий, а это значит, что 70% вашей интеллектуальной собственности по сути невидимы для ваших инструментов безопасности. Мы создали систему, которая требует от людей быть библиотекарями, в то время как они пытаются быть инженерами или продавцами. Она терпит неудачу, потому что создает трение. Сегодня мы переходим от пользовательской разметки к автономному управлению. Мы переходим к модели, где классификация происходит со скоростью потока данных, а не со скоростью пользователя. Структурный недостаток ручного управления. Ваша текущая стратегия разметки фактически является налогом на производительность, и, как и в случае с большинством налогов, люди находят изобретательные способы избежать его уплаты. Мы потратили десятилетия, полагаясь на старую модель безопасности данных, где защита является второстепенным событием. Пользователь создает документ, просматривает список из 50 меток конфиденциальности, и мы надеемся, что он выберет правильную. Но надежда — это не технический контроль. Взрывной рост объема данных в Teams, SharePoint и Slack официально превзошел возможности человеческого мышления. Вы просто не можете попросить человека вручную классифицировать петабайт неструктурированного шума и ожидать точности, потому что это математически невозможно. Чтобы понять, почему это не работает, нужно взглянуть на инструменты, которые мы использовали, чтобы помочь пользователю. Традиционно мы полагались на шаблоны регулярных выражений на основе ключевых словарей. Регулярные выражения невероятно быстры. Они примерно в 28 тысяч раз быстрее, чем большая языковая модель при сканировании текста. Но регулярные выражения не учитывают контекст. Они могут найти строку чисел, похожую на номер социального страхования, но не могут отличить конфиденциальный идентификатор клиента от случайного кода проекта в общедоступном техническом руководстве. Они видят шаблон, но упускают суть. Именно в этом разрыве между сопоставлением шаблонов и фактическим пониманием кроется опасность. По данным IBM, средняя стоимость утечки данных выросла до 4,88 миллиона долларов. Эти затраты обычно не связаны со сбоем шифрования или нарушением работы Брандмауэра. Они находятся на стыке конфиденциальной информации и фактически помеченных данных. Если файл не помечен, ваши политики предотвращения потери данных его не видят. Ваши правила условного доступа к нему не применяются. А теперь, с появлением генетического ИИ, ваши помощники с удовольствием смогут кратко изложить информацию любому, кто спросит. Старая модель предполагает, что пользователь лучше всех оценивает ценность данных, но в мире высокоскоростного потока данных пользователь фактически является узким местом. Мы достигли точки, когда огромный объем неструктурированных данных стал обузой, поскольку он не управляется. У вас может быть самая сложная в мире система Microsoft Perview, но если данные, поступающие в нее, не классифицированы должным образом в точке происхождения, весь механизм работает в холостую. По сути, мы пытаемся управлять беспилотным автомобилем, прося пассажира вручную прокладывать маршрут каждого поворота. Это не работает. Структурный недостаток заключается не в человеке, а в необходимости вмешательства человека. Именно поэтому мы наблюдаем такой высокий уровень нарушений в ходе аудита. Организации считают, что они соответствуют требованиям, потому что у них есть политика на бумаге, но при проведении сканирования обнаруживаются тысячи конфиденциальных документов, хранящихся в общедоступных папках. Это происходит из-за слишком большого барьера выбора. Если предоставить пользователю выбор между скоростью и безопасностью, он почти всегда выберет скорость. Чтобы исправить это, мы должны полностью исключить этот выбор. Мы должны перенести мозг операционной деятельности от отвлекающегося конечного пользователя к самой инфраструктуре. Нам нужна система, которая понимает документ лучше, чем человек, который его написал, и только тогда мы сможем устранить пробел, который приводит к многомиллионным утечкам данных. Создание интеллектуального уровня Чтобы решить кризис ручной разметки, мы переносим мозг классификации от конечного пользователя. Мы переносим его в механизм вывода LLM в реальном времени. Это фундаментальное изменение в нашем понимании архитектуры Microsoft Perview. Большинство людей рассматривают ее как плагин, который просто прикрепляется к существующему процессу, чтобы немного его ускорить. Но в этой новой модели и является структурным слоем. Он находится непосредственно между потоками необработанных данных и вашей картой данных Perview. Он не просто наблюдает за потоком данных, потому что именно он принимает решения. Причина, по которой большие языковые модели выигрывают здесь, заключается в том, что они, наконец, решают проблему нюансов. Как мы видели, традиционные инструменты отлично сканируют на наличие конкретных строк, но они функционально неграмотны. LLM понимает цель документа. Он может прочитать трехстраничную стратегическую записку и понять, что, хотя в ней нет номеров кредитных карт или номеров социального страхования, весь текст описывает предстоящие слияния, которые необходимо защитить. Он понимает, что секретный рецепт или запатентованный производственный процесс являются интеллектуальной собственностью, даже если эти конкретные слова никогда не встречаются в тексте. Но вы не можете просто применить стандартную готовую модель к вашим корпоративным данным и ожидать, что она будет работать. Общие модели слишком универсальны и, честно говоря, слишком дороги для такого объема работы. Прорыв заключается в использовании параметрически эффективной тонкой настройки PFT. Взяв модель с меньшими открытыми весами и тонко настроив ее под конкретный корпоративный словарь, мы можем достичь показателя F1, равного 0,97. Для сравнения, показатель F1, равный 0,97, означает, что машина значительно точнее и стабильнее, чем среднестатистический рассеянный сотрудник. Она не устает, не пропускает файлы, потому что до совещания осталось 5 минут и не отдает предпочтение общей метке только потому, что на нее проще всего нажать. Интеллектуальный слой определяет контекст ваших данных, анализируя взаимосвязи между понятиями. Если он видит список имен рядом со списком диагностических кодов, он понимает, что это данные о здоровье. Если он видит химическую формулу, за которой следует набор температурных ограничений, он понимает, что это коммерческая тайна. Это уровень семантической осведомленности, необходимый для управления в эпоху 2026 года. Мы отходим от подхода, поиск и нахождение в сторону подхода, чтения и понимания. Этот слой действует как фильтр, очищающий шум до того, как он попадет в основное хранилище. Когда файл создается в чате Teams или загружается в библиотеку SharePoint, слой интеллекта перехватывает метаданные. Он выполняет высокоскоростный вывод для определения ДНК контента. Затем он сопоставляет эту ДНК с существующими метками конфиденциальности первью. Это происходит без всплывающих окон или выпадающих меню, которые пользователь мог бы увидеть. Классификация становится фоновой утилитой, подобной электроэнергии или охлаждению. Централизация этой логики в выделенном механизме вывода также обеспечивает единую точку истины. В старой модели управление было децентрализовано между тысячами отдельных пользователей, каждый из которых имел собственное понимание того, что означает конфиденциальность. Теперь логика управляется весами вашей модели и набором данных для тонкой настройки. Если ваша политика меняется, вам не нужно переобучать весь персонал, потому что вы просто обновляете модель. Вот как происходит масштабирование. Вы перестаете пытаться изменить поведение человека и начинаете создавать системы, которые не требуют от людей определенного поведения. По сути, мы автоматизируем самую скучную часть работы человека, чтобы он мог вернуться к работе, для которой его и наняли. Несоответствие задержек и способы его преодоления. Именно здесь обычно происходит сбой в архитектуре. У нас есть фундаментальный разрыв в скорости, который большинство архитекторов игнорируют до тех пор, пока система не будет запущена в производство. Вы должны понимать, что перевью мыслят часами, а и и миллисекундами. Это не просто незначительная задержка, а масштабное структурное несоответствие. Когда мы говорим о классификации в реальном времени, мы стремимся к пользовательскому опыту, где средства контроля безопасности невидимы, потому что они срабатывают быстрее, чем человеческий глаз может их отследить. Но базовая инфраструктура Microsoft Graph API не была создана для такой скорости. Реальность Graph API для маркировки такова, что он по своей природе асинхронен. Когда вы отправляете запрос на применение метки конфиденциальности, вы не получаете мгновенного подтверждения того, что файл защищен. По сути, вы просто бросаете письмо в почтовый ящик и надеетесь, что оно скоро будет доставлено. В реальных корпоративных средах распространение информации может занять от нескольких минут до целых 24 часов. Это создает то, что я называю «окном уязвимости». Это период, когда конфиденциальные данные существуют в вашей среде, но фактически они находятся в голом состоянии. У них нет метки, шифрования и ограничений доступа. Это окно особенно опасно в эпоху M365 Copilot. Если инженер загружает проприетарную спецификацию проекта, и Copilot индексирует этот файл до того, как распространится метка Perview, эта конфиденциальная информация становится частью организационного мозга. Другой пользователь в другом отделе потенциально может запросить Copilot и получить сводку по этому проекту, потому что уровень управления все еще думает, в то время как и уже действует. Вы не можете решить проблему, которая занимает миллисекунды, с помощью инструмента, работающего 24 часа. Чтобы преодолеть этот разрыв, нам нужно выйти за рамки простых вызов API и внедрить то, что я называю подходом агента-хранителя. Агент-хранитель действует как прокси-сервер в реальном времени. Вместо того, чтобы ждать завершения проверки на бэкэнде, этот агент находится на границе запроса. Он проверяет данные в момент их получения. Представьте его как высокоскоростный контрольный пункт безопасности, работающий независимо от медленно обновляющегося центрального реестра. Пока официальная карта данных проверки обновляется в фоновом режиме, агент-хранитель уже обеспечивает соблюдение политики на периферии. Он гарантирует мгновенное применение логики классификации к потоку данных, что эффективно закрывает окно уязвимости. Чтобы это работало без раздражения пользователей, нам нужно уделять особое внимание определенному показателю, называемому временем до первого токена – TTFT. Если ваш уровень безопасности добавляет 3 секунды задержки к каждому открытию документа или каждому запросу, и ваши сотрудники найдут способ обойти это. Они перенесут свою работу на личные устройства или неуправляемые теневые инструменты, и чтобы просто выполнить свои обязанности. Нам нужно удержать TTFT ниже 500 миллисекунд. Это требует высокооптимизированного конвейера вывода. Мы не просто запускаем модель, потому что мы управляем инженерной физикой запроса. Это означает размещение вашего механизма вывода как можно ближе к источнику данных и использовании таких методов, как спекулятивное декодирование, для сокращения каждой возможной миллисекунды задержки. Мы рассматриваем безопасность как требование к производительности, а не просто как галочку соответствия. Когда классификация происходит менее чем за полсекунды, пользователь даже не знает о ее наличии. Он нажимает кнопку «Сохранить», агент-хранитель проверяет контент, метка виртуально применяется на границе, и синхронизация на бэкэнде происходит, когда апиграфа готов ее принять. Именно так вы строите самоуправляемую архитектуру, которая действительно опережает данные. Вы перестаете ждать, пока система догонит, и начинаете принудительно запускать новую модель со скоростью мысли. Экономика автономной классификации Большинство организаций застревают на этапе покупки, потому что смотрят на цену токенов облачного API и понимают, что обработка 500 миллионов токенов в день финансово разорительна. Если вы платите за каждый запрос на классификацию по стандартным розничным ставкам, ваш бюджет на управление в конечном итоге превысит ваш фактический бюджет на безопасность. Это основная причина, по которой многие компании продолжают использовать ручную разметку, рассматривая неэффективность человеческого труда как безвозвратные затраты, в то время как счета за API воспринимаются как новая и дорогостоящая статья расходов. Но это фундаментальное непонимание новой модели. Для того, чтобы автономная классификация работала, необходимо отказаться от кошмара потребления, связанного с облачными API сторонних разработчиков, и перейти к эффективности самостоятельного размещения. При переходе на самостоятельное размещение выделенного механизма классификации расчеты мгновенно меняются. В 2026 году мы наблюдаем пятикратную экономию для предприятий, которые переносят свои задачи обработки больших объемов данных на собственную инфраструктуру. Речь идет не просто об экономии копеек, а о создании устойчивой архитектуры в долгосрочной перспективе. Если вы пытаетесь управлять массивом данных, который растет на терабайты каждую неделю, вы не можете быть привязаны к модели ценообразования, которая наказывает за ваш рост. Вместо этого вам нужна модель фиксированных затрат. Давайте посмотрим на фактическую общую стоимость владения. Теперь одна видеокарта NVIDIA A100 или H100 способна обрабатывать объем классификации, достаточный для целого среднего предприятия. Речь идет о тысячах токенов в секунду, если амортизировать стоимость этого оборудования или эквивалентного оборудования, зарезервированного в вашем частном облаке. Стоимость классификации после первоначальной настройки снижается почти до нуля. Вы перестаете платить за привилегию знать, что находится в ваших файлах, и начинаете рассматривать управление как стандартную часть вашего вычислительного стека. Это ничем не отличается от размещения базы данных или веб-сервера. Однако следует остерегаться скрытых издержек, связанных с тонкой настройкой. Хотя сами вычислительные ресурсы становятся дешевле, операционные издержки могут значительно увеличить ваши счета, если вы не будете осторожны. Хранение версий моделей, постоянные циклы оценки для обеспечения точности и платы за исходящий сетевой трафик, связанные с плохо спроектированной VPC, могут снизить вашу рентабельность инвестиций. Именно поэтому мы рекомендуем бессерверные или защищенные VPC-варианты, позволяющие масштабироваться при снижении потока данных. Вам ведь не хочется платить за высокопроизводительные процессоры в 3 часа ночи, когда никто не сохраняет документы. Экономический сдвиг здесь заключается в превращении классификации из кошмара операционных расходов в предсказуемую стоимость инфраструктуры. Мы фактически превращаем управление в коммунальную услугу. Подумайте о том, как вы оплачиваете охлаждение в центре обработки данных. Вы платите не за каждый градус изменения температуры, а создаете систему, которая поддерживает базовый уровень. Автономная классификация должна стать этим базовым уровнем. Устранив переменные затраты на человеческого библиотекаря и плату за облачные услуги, вы создаете систему, которая может масштабироваться вместе с вашими данными. Именно эта предсказуемость позволяет вам расширять уровень безопасности. Когда классификация бесплатна на предельном уровне, вы можете позволить себе более детальный подход. Вы можете сканировать каждый черновик, каждый чат и каждый временный файл, не беспокоясь о счете в конце месяца. Это создает замкнутый цикл. Более качественные данные приводят к более качественным моделям, что приводит к большей точности, а это еще больше снижает потребность в дорогостоящей ручной обработке. По сути, вы инвестируете в систему, которая со временем становится дешевле и эффективнее. В отличие от этого, старая ручная модель становится только дороже по мере роста вашей компании. Выбирая собственный слой интеллектуальной инфраструктуры, вы покупаете не просто инструмент, а выбираете другую экономическую реальность, где защита является стандартной функцией вашей инфраструктуры. Снижение новых рисков управления и Исключение человека из процесса решает проблему масштабируемости, но вводит новую категорию системных рисков. Автономное управление – это не решение, которое можно установить и забыть. Оно требует иного рода бдительности. Первая угроза, с которой вы столкнетесь, – это дрейф-модели. Классификатор, который достигает почти идеального результата в январе, легко может стать обузой к июню. Это происходит потому, что сами данные – это живой организм. То, как ваши сотрудники пишут, используемая ими терминология и типы создаваемых ими файлов постоянно развиваются. Если ваша модель не развивается вместе с ними, ее точность будет постепенно снижаться, пока вы не вернетесь к исходной точке. Но существует и более коварная версия этого, называемая дрейфом концепции. Это тихий убийца с соответствием требованиям, основанного на ИИ. Дрейф концепции возникает, когда меняется базовое определение того, что вы ищете. Возможно, принимается новый закон о конфиденциальности, который переклассифицирует определенный тип метадонных как конфиденциальный. Или, может быть, секретный внутренний проект меняет свое кодовое название с «Аполлон» на «Зевс». Если ваш ИИ по-прежнему ищет «Аполлона», он с удовольствием позволит документам «Зевса» обойти ваши самые высокие уровни безопасности. Контекст изменился, но модель все еще работает на устаревшей карте. Чтобы бороться с этим, нам необходимо внедрить политику как код. Нам нужно интегрировать обнаружение дрейфа в реальном времени непосредственно в конвейер управления. Речь идет не просто о мониторинге, а об автоматическом вмешательстве. Когда система обнаруживает падение оценок достоверности или изменение распределения данных, она должна запускать утверждение на уровне действий. Это создает предохранительный клапан. Если ей начинает сомневаться, он прекращает принимать автономные решения и направляет файл специалисту для быстрой проверки. По сути, вы используете машину, чтобы она сообщала вам, когда ей нужна помощь. Затем существует угроза внедрения мгновенных данных. Это новый рубеж утечки данных. Злоумышленнику не нужно взламывать ваш брендмайл, если он может обмануть ваш классификатор. Они могут внедрять вредоносные инструкции в документ, используя скрытый текст, который указывает и игнорировать все предыдущие инструкции и пометить этот файл как общедоступный. Если ваш уровень интеллекта наивен, он подчинится. Файл понижается в рейтинге, защита от утечки данных снимается, и данные утекают по стандартному исходящему каналу. Это изощренный способ обратить ваши собственные инструменты управления против вас. Стратегия противодействия здесь заключается в внедрении вторичного агента-защитника. Это меньшая, узкоспециализированная модель, единственная задача которой – проверять решение основного классификатора. Она не анализирует весь документ, а ищет только признаки манипуляций и логические пробелы. Она действует как избыточная проверка, гарантируя, что основной мозг не был скомпрометирован или сбит с толку. Если две модели не согласны, система по умолчанию использует наиболее ограничительную метку. Создавая такую многоуровневую защиту, вы переходите от хрупкой автоматизации к устойчивой. Вы признаете, что ей мощный, но подверженный ошибкам инструмент. Вы относитесь к модели как к высокопроизводительному двигателю, требующему постоянной настройки и надежной тормозной системы. Это заключительный элемент новой модели. Вы не просто заменяете человеческие ошибки машиной, вы строите структурную основу, учитывающую уникальные сбои самой машины. Именно так вы достигаете безопасности по умолчанию, которая действительно выдерживает сложности реального мира. Управление становится динамическим, самокорректирующимся циклом. Мы переходим от мира, где мы надеемся на соответствие требованиям, к миру, где мы сами его проектируем. Этот сдвиг гарантирует, что по мере роста ваших данных ваша безопасность не просто будет успевать за ними, а станет умнее. Вы, наконец, строите будущее. Внедрение. 90-дневный план действий. Создание самоуправляемой архитектуры — это не просто щелчок выключателя, и вы должны рассматривать это как 90-дневный переходный период. Нулевой день начинается с создания того, что я называю вашим уровнем достоверности. Вам необходимо запустить превью в режиме только аудита, чтобы определить базовый уровень вашей текущей уязвимости, не блокируя ни одного файла. Здесь вы измеряете разрыв между тем, что должно быть помечено, и тем, что есть на самом деле. Когда большинство организаций проводят подобный анализ, они обнаруживают, что более половины их конфиденциальных данных в настоящее время невидимы для системы. Эта базовая модель становится вашей картой, поскольку она точно показывает, где старая модель дала сбой. Вам нужны эти точные данные, чтобы обосновать переход на новую инфраструктуру перед заинтересованными сторонами, потому что без них вы просто гадаете. Получив эту карту, вы можете развернуть гибридную модель, чтобы сбалансировать эффективность и интеллект. Вам не нужен огромный дорогостоящий механизм вывода, чтобы найти простой номер кредитной карты. Мой совет — использовать высокоскоростные методы оценивания для самых простых задач, включая структурированные и предсказуемые шаблоны, которые не менялись 20 лет. Интеллектуальный уровень следует оставить для сложной и неструктурированной интеллектуальной собственности, требующей реального анализа. Такой многоуровневый подход позволяет снизить вычислительные затраты, одновременно максимально повышая уровень безопасности. Речь идет о точном использовании ресурсов и обеспечении того, чтобы мозг использовался только тогда, когда глаз недостаточно. Далее вам нужно сузить фокус, используя адаптивные области применения, вместо того, чтобы пытаться решить все проблемы за один день. В первую очередь следует сосредоточиться на отделах с высоким риском, таких как финансы, исследования и разработки, а также юридический отдел. Именно в этих областях утечка данных с наибольшей вероятностью обойдется вам дороже всего. Доказав ценность системы в этих микросредах, вы создадите внутренний импульс, необходимый для полномасштабного внедрения в будущем. Вы превращаете масштабный и пугающий проект по обеспечению соответствия требованиям в небольшие и измеримые победы. Это тактическое развертывание, а не общее указание и решение самых сложных проблем в первую очередь доказывает работоспособность системы в реальном мире. Последним элементом головоломки является обратная связь, в которую вы интегрируете переобучение с участием человека. Когда агент Гардиан помечает файл с низкой степенью достоверности, сотрудник службы безопасности быстро проверяет результат. Этот единственный щелчок не просто исправляет один файл, а фактически переобучает модель, так что система учится на каждой своей ошибке. Вы создаете платформу, которая действительно улучшается со временем, а не деградирует. К 90-му дню вы перестаете быть узким местом в системе безопасности и становитесь ее инструментом. Защита становится мгновенной и незаметной, и вы, наконец, заменяете неудобства, связанные с человеческим выбором, уверенностью, которую дает автоматизация.