PailotС 8 по 11 октября 2026 года беспилотники атаковали три дата-центра Яндекса — в Сасове, Калуге и Владимире. Площадки в Сасове и Владимире остановились. Часть клиентов Yandex Cloud временно потеряла доступ к своим данным. К 23 октября Яндекс сообщил, что восстановил доступ к 90,47% данных облачной платформы. Для компаний, чьи сотрудники в это время не могли открыть рабочие документы или воспользоваться сервисом, значение имел каждый день. Хронология Яндекса · Отчёт о восстановлении доступа
В ночь с 1 на 2 ноября другой удар пришёлся по хостинг-провайдеру Beget. Злоумышленники получили доступ к управляющим серверам и запустили программу удаления данных. Компания сообщила об утрате всех данных в трёх облачных сервисах — на виртуальных серверах VPS, в хранилище S3 и в Kubernetes. При этом файловые резервные копии VPS сохранились. В такой ситуации сроки возвращения к работе зависят уже от того, насколько свежая копия есть у компании и как быстро из неё можно восстановить сервис. Хронология Beget · Подробности по затронутым сервисам
Интерес к собственному ИИ рос ещё до атак
С января по сентябрь 2026 года Яндекс Вордстат зафиксировал в России 1 215 поисковых запросов по формулировке «ИИ на своем сервере» против 552 за те же месяцы 2025 года. За девять месяцев интерес к теме вырос в 2,2 раза. Причём в каждом месяце показатель 2026 года был выше прошлогоднего. Самый заметный разрыв к концу периода пришёлся на сентябрь — 199 запросов против 90 годом ранее. Это сравнительно небольшие числа для одной формулировки, но они показывают, что вопрос о собственном сервере возник у пользователей задолго до октябрьских событий. Динамика в Яндекс Вордстате
В октябре в этом ряду появился пробел. При проверке 4 ноября Вордстат показывал дневные значения только по 7 октября включительно. В ночь на 8-е произошла первая атака. Сервис предупредил о временной недоступности части данных и дал ссылку на сообщение Яндекса об атаках. Определить по этому отчёту, как изменился спрос после 7 октября, пока невозможно. Яндекс Вордстат
Google Trends позволяет увидеть, что происходило в дни самих событий. 11 октября, когда остановился дата-центр во Владимире, запрос «сбой Яндекса» достиг максимума за период с 15 сентября по 3 ноября. У запроса «локальный ИИ» заметные значения появились позднее, с 21 октября. Шкала Google показывает относительный интерес. По ней можно датировать всплеск внимания к сбою, но нельзя установить, сколько компаний решили перенести ИИ на свои серверы. Сравнение в Google Trends
О реакции бизнеса больше говорит наблюдение поставщика. По словам главы «Ультиматек» Павла Растопшина, после атак на дата-центры Яндекса компания стала получать как минимум втрое больше обращений по поводу контейнерных дата-центров, чем летом. Это готовые модули для размещения оборудования на собственной или резервной площадке. Цифра относится к обращениям в одну компанию. Она показывает, что часть заказчиков уже обсуждает с поставщиками, где разместить инфраструктуру и как сохранить доступ к ней при сбое. Материал РБК
Почему запасной нейросети может оказаться мало
Представим обычное обращение в техподдержку. После обновления кассовый терминал перестал печатать чеки. Магазин ждёт ответа. В общей инструкции описан стандартный перезапуск, но неделю назад производитель выпустил исправление для одной версии терминала. Старший инженер помнит об этом и первым делом уточнит модель. Сотрудник, который недавно вышел на смену, обращается к ИИ-помощнику.
Хороший ИИ по базе знаний найдёт действующий документ, покажет нужный пункт и даст ссылку, по которой инженер сможет проверить рекомендацию. Такой способ работы называют RAG — модель получает подходящие фрагменты документов компании и использует их при подготовке ответа.
Теперь допустим, что основная облачная модель недоступна. ИТ-служба переключает чат на запасную, и тот снова отвечает. Но последнее исправление осталось в недоступном хранилище. Помощник может дать вполне убедительный совет по старой инструкции. Новичку снова придётся искать старшего инженера, а магазин всё это время будет ждать у неработающей кассы.
У этой зависимости есть измеримая цена. В исследовании, опубликованном в The Quarterly Journal of Economics, учёные проследили за работой 5 172 специалистов клиентской поддержки одной компании. С ИИ-помощником сотрудники решали в среднем на 15% больше обращений в час. Наибольшую пользу получили менее опытные коллеги. Когда такой помощник замолкает, часть вопросов новичков возвращается к тем же нескольким людям, которые и раньше знали ответ. Исследование Generative AI at Work
Как устроен ИИ для техподдержки внутри компании
Клиент и инженер могут задать один вопрос и получить разные ответы. Управляющему магазином доступна инструкция пользователя, инженеру — ещё и внутренний бюллетень с диагностикой. При RAG-поиске с учётом ролей модель получает только те фрагменты, которые разрешены конкретному человеку. Роль сотрудника можно брать из корпоративного каталога Active Directory (AD), где уже заведены рабочие учётные записи. В открытом разборе Pailot показана схема для четырёх ролей. В демонстрации роль меняют прямо в чате, чтобы сравнить ответы. В рабочей системе её подтверждает корпоративная учётная запись. Разбор RAG-поиска по документам с ролями
Для решения технического вопроса не всегда нужны персональные данные. В заявке могут оказаться имя, почта и телефон управляющего, хотя для разбора неисправности достаточно модели терминала и версии программы. Если сотрудник использует такую заявку для настройки процесса с помощью облачного копилота, можно контролировать, что уйдёт наружу. В Pailot для этого предусмотрен дополнительный шлюз защиты персональных данных (PII). Он может заблокировать отправку или заменить найденные личные сведения условными обозначениями. Защита действует на обращения копилота к облачной модели. Описание защиты персональных данных
Работа смены и настройка помощника могут зависеть от разных моделей. На вопросы по инструкциям отвечает рабочая модель. Когда меняется порядок обслуживания, специалист использует копилот — например, просит его добавить проверку версии терминала и просматривает предложенные изменения. Модели для этих задач выбираются отдельно, а в копилоте их можно переключать. Если рабочая модель, вход сотрудников, документы и поиск находятся внутри компании, недоступность внешнего копилота задержит изменение сценария. Дежурная смена при этом сможет продолжить работу по уже настроенному процессу. Модели и возможности копилота · Как устроен локальный контур
Что оставить внутри компании
Инциденты у Яндекса и Beget показали, что у бизнеса есть две разные задачи. Первая — продолжать помогать клиентам, пока внешняя площадка недоступна. Вторая — восстановить работу после потери данных. Для первой нужен доступ к актуальным знаниям во время сбоя. Для второй — независимая копия, из которой можно восстановить документы и сам сервис.
Если ИИ уже стал частью ежедневной работы техподдержки, разумный шаг — оставить внутри компании весь путь от вопроса сотрудника до проверенного ответа. Сотрудник входит под своей учётной записью, поиск находит актуальную инструкцию с учётом его прав, локальная модель готовит ответ, а инженер открывает первоисточник. Облачные нейросети можно использовать там, где допустима пауза, — например, при доработке сценариев с помощью копилота.
Такая миграция из облака может начаться с одного процесса. Если без помощника первая линия вынуждена передавать обращения старшим инженерам, а клиенты ждут, пока восстановится внешний сервис, техподдержка — обоснованный первый выбор для собственного ИИ. Компания сохраняет доступ к знаниям, от которых зависит работа смены, и может принять это решение без полного отказа от облака.