Хроники связи СВО

ИИ предложил исправление. Кто разрешил его применить? Представьте: сервис начал тормозить. ИИ посмотрел журналы, нашёл ошибки и предложил перезапуск. Инженер согласился. А после перезапуска сервис не поднялся. Пример условный, но вопрос вполне практический: что именно проверил человек перед нажатием кнопки и почему система вообще предложила это действие? На Kazan Digital Week обсуждали применение ИИ в управлении инфраструктурой. Анализ событий, поиск вероятных причин сбоев, рекомендации инженеру. Тема напрямую связана с тем локальным ИИ, о котором я уже писал. Помощник, способный разобрать накопившиеся сообщения и показать подозрительные изменения, мне нужен. Но между «обрати внимание на этот сервер» и «я уже всё перезапустил» лежит вполне конкретная разница в полномочиях. Я бы начинал с анализа без права менять систему. Пусть собирает сводку, показывает исходные события, предлагает версии. Причём отдельно указывает, что известно из измерений, а что он предполагает. Если данных не хватает, это тоже должно быть видно. Например, рост числа ошибок после обновления — основание проверить обновление. Но одного совпадения по времени недостаточно, чтобы объявить причину установленной и немедленно откатывать всё назад. Следующий этап — подготовка изменения на проверку. Здесь мне мало фразы «рекомендуется скорректировать конфигурацию». Нужно видеть, что именно предлагается изменить, какие сервисы это затронет, какого результата ожидаем и как будем возвращаться к исходному состоянию, если станет хуже. И только после проверки на ограниченных задачах можно обсуждать самостоятельные действия. С заранее определёнными границами и условиями остановки. Такие границы должны обеспечиваться правами доступа и самой системой исполнения: просьба в инструкции «пожалуйста, ничего лишнего не меняй» для этого недостаточна. При этом кнопка «Подтвердить» сама по себе проблему не решает. Если дежурному выдали длинный ответ модели, торопят с восстановлением и предлагают просто нажать «ОК», полноценной проверки может не получиться. Формально человек участвовал. Фактически у него могли отсутствовать и время, и необходимые сведения. Поэтому ответственность нельзя целиком свалить на последнего, кто нажал кнопку. Кто выбрал систему? Кто определил её права? Кто проверял качество рекомендаций? Кто решил, что теперь одному сотруднику можно поручить больше работы, потому что у него появился ИИ? Эти решения тоже должны учитываться при разборе аварии. Разделение ролей и ответственности, кстати, прямо предусмотрено в NIST AI RMF. Ещё одна вещь, которую легко перепутать: локальность и правильность. Модель может работать на собственном сервере, не отправляя данные наружу, и при этом ошибаться. Изоляция решает вопрос доступа к данным. Качество выводов всё равно придётся проверять. Пользу такого помощника я бы оценивал по времени разбора инцидентов, числу полезных предупреждений и ошибочных рекомендаций. Отдельно — сколько времени инженер тратит на проверку его ответов. Хочется, чтобы ИИ действительно разгружал людей. Если после внедрения приходится ещё и круглосуточно присматривать за самим помощником, дополнительную смену мы себе уже организовали. Communicatio est victoria. — Душнила t.me/zas_svo vk.com/zas_svo #СВО #связь #ИИ #мониторинг