Роман Косов – Методические указания: интеграция искусственного интеллекта в деятельность государственного служащего (страница 6)

Гражданин, столкнувшийся с этой архитектурой, испытывает характерное чувство: ты приносишь в МФЦ справку из одного ведомства, чтобы получить услугу в другом, а сотрудник в окошке смотрит на эту справку и просит принести ещё одну — из третьего ведомства, которое, как позже выясняется, получает ту же информацию из первого, но по другому каналу. Данные не текут, они стоят затхлыми лужами в разрозненных базах, и каждый переход между ними требует от гражданина роли курьера, а от чиновника — роли ручного оператора сверки.

Концепция единой облачной архитектуры, реализуемая через платформу «ГосТех», призвана переломить эту ситуацию. Речь не просто о переносе баз данных на чьи-то серверы. Речь о смене самого принципа: вместо того чтобы каждое ведомство строило свой отдельный цифровой сарай с собственным фундаментом, стенами и крышей, мы переходим к модели многоквартирного дома, где есть общий фундамент — облачная инфраструктура, общие коммуникации — шины данных, общие правила безопасности и единые стандарты «отделки помещений» — пользовательских интерфейсов и протоколов обмена. Ведомства становятся не владельцами инфраструктуры, а арендаторами типовых решений, которые можно быстро развернуть, настроить под себя и, что критически важно, масштабировать на другие регионы без многомиллионных затрат на разработку с нуля.

С технической точки зрения облачная архитектура «ГосТех» опирается на несколько ключевых принципов. Первый — это мультиарендность (multi-tenancy): на одном физическом кластере серверов могут безопасно сосуществовать информационные системы разных ведомств и регионов, не имея доступа к данным друг друга. Второй — отказоустойчивость: централизованные дата-центры обеспечивают уровень доступности сервисов, который отдельно взятое региональное управление со своим сервером в подвале обеспечить не может физически. Третий — стандартизация: если все используют единые протоколы обмена данными, исчезает сама проблема «нестыковки форматов», на которую годами списывали задержки в межведомственном взаимодействии.

Но переход к единой платформе — это не только технологический, но и политико-управленческий вызов. Регионы и ведомства десятилетиями вкладывали бюджеты в собственные системы, нарабатывали уникальные конфигурации, привязывались к конкретным разработчикам, которые эти системы сопровождают. Предложение «отдать всё наверх» вызывает предсказуемое сопротивление, маскируемое под аргументы о специфике территории, уникальности задач и неготовности миграции. Отчасти эти аргументы даже обоснованны: специфика действительно существует, и просто «залить» региональную базу льготников в федеральный шаблон без потери данных и нарушения прав граждан — задача нетривиальная. Но принципиально важно понимать: единая платформа не означает единообразного решения для всех. Она означает общий фундамент, на котором можно строить разные конфигурации, используя типовые блоки — как конструктор, где из одних и тех же деталей собираются и легковая машина, и грузовик, и автобус.

Экономическая логика единой платформы железобетонна: по экспертным оценкам, до 70% функционала государственных информационных систем дублируется от региона к региону. Каждый субъект Федерации заказывает разработку личного кабинета, системы авторизации, модуля сбора отчётности, интерфейса для граждан — и всё это делается с нуля, разными подрядчиками, по разным стандартам. Когда эти типовые блоки предоставляются платформой централизованно, стоимость внедрения новой услуги падает радикально. Высвободившиеся ресурсы можно направить на содержательную часть — на ту самую специфику, которая действительно отличает один регион от другого.

Однако здесь же кроется и главный риск: монополизация. Если вся страна работает на одной платформе, разрабатываемой ограниченным кругом подрядчиков, любая системная ошибка или уязвимость приобретает национальный масштаб. Мы это проходили в 2022 году, когда уход зарубежных вендоров парализовал работу десятков ведомств, завязанных на SAP, Oracle, Microsoft и другие проприетарные решения. Ответом на этот риск является не отказ от централизации как таковой, а требование открытости архитектуры, модульности и отсутствия vendor lock-in — привязки к единственному разработчику, без которого систему невозможно ни изменить, ни поддержать. Платформа должна позволять подключать модули от разных поставщиков, соответствующих единым стандартам. Именно это закладывается в концепцию «Госмаркета» — своего рода магазина приложений для госорганов, где ведомство может выбрать готовое решение, уже проверенное на совместимость и безопасность.

Отдельный сюжет, который пока находится в тени публичных обсуждений, но неизбежно выйдет на первый план, — это судьба данных при переходе к единой платформе. Данные сегодня — это актив. Ведомство, владеющее уникальным массивом данных (пусть и собранных за государственный счёт), обладает аппаратным весом, возможностью влиять на решения, контролировать доступ. Централизация данных означает перераспределение этого веса. Неудивительно, что процесс идёт не быстро и не просто: никто не хочет отдавать то, что десятилетиями считал «своим». Но с точки зрения гражданина и государства в целом, данные, собранные на бюджетные средства, должны быть доступны для использования в любой точке системы, где они необходимы для оказания услуги или принятия решения, — разумеется, с соблюдением всех требований безопасности и конфиденциальности.

Подводя итог этому разделу: единая облачная платформа — это не красивая картинка из презентации Минцифры, а единственный способ избежать дальнейшего воспроизводства «лоскутного одеяла» государственных информационных систем. Сложности перехода неизбежны, но цена сохранения статус-кво выше: это цена постоянных сбоев, утечек данных, многолетних очередей на интеграцию и, в конечном счёте, недоверия граждан к способности государства управлять информацией. А доверие, как мы помним, — это фундамент, на котором стоит весь общественный договор.

3.2. Классификация служебной информации: где заканчиваются открытые данные и начинается государственная тайна

Один из самых опасных пробелов в сознании рядового чиновника, начинающего использовать ИИ-инструменты, — это отсутствие чёткой, доведённой до автоматизма классификации информации по уровням чувствительности. Человек, который ни секунды не колеблясь, отказался бы пересылать паспортные данные гражданина в общедоступный WhatsApp-чат, совершенно спокойно вставляет текст служебной записки с теми же данными в окно публичной нейросети — просто потому, что разница между мессенджером и облачным ИИ-сервисом для него неочевидна. И в этом нет его личной вины: система пока не дала ему внятной и простой классификации, применимой к новым цифровым инструментам.

Действующее законодательство выделяет несколько уровней конфиденциальности информации: общедоступные данные, служебная информация ограниченного распространения, персональные данные, различные грифы секретности вплоть до государственной тайны. Проблема в том, что эта классификация создавалась в эпоху, когда основным носителем информации была бумага, а основным каналом утечки — болтливый сотрудник или потерянная папка. В эпоху ИИ границы размываются: даже несекретный, но чувствительный массив данных, будучи скормлен публичной нейросети для «анализа», де-факто становится общедоступным, потому что мы не контролируем, как и где эти данные будут использованы провайдером сервиса.

Ключевой тезис этого раздела можно сформулировать так: любая информация, которая не была явно и уполномоченно признана общедоступной, по умолчанию не должна покидать защищённый контур. Это простое правило, если его последовательно придерживаться, предотвращает львиную долю потенциальных инцидентов. Но для его соблюдения чиновнику нужно не только знать гриф документа, но и понимать, где проходит граница защищённого контура применительно к каждому конкретному инструменту.

Публичные нейросети общего доступа — это, с точки зрения классификации, такой же открытый канал, как и социальные сети. Отправляя туда текст, вы делаете его достоянием третьих лиц, как бы ни уверял вас провайдер в обратном. Ведомственные системы, развёрнутые в аттестованном контуре «ГосТех», — совсем другое дело: здесь можно работать с персональными данными и служебной информацией, потому что инфраструктура прошла проверку регуляторов и соответствует требованиям к защите . А есть ещё промежуточный, самый сложный для понимания случай: ведомственный ИИ-сервис, развёрнутый на коммерческой облачной платформе, формально находящейся в российской юрисдикции, но не прошедшей полную аттестацию для работы с чувствительными данными. Здесь нужна осторожность и явное разрешение ответственного за безопасность подразделения.

Отдельная головная боль — это обезличенные данные. Часто можно услышать аргумент: «Мы же убрали фамилии и адреса, теперь это просто статистика, можно анализировать где угодно». Это опасное заблуждение. Современные методы деанонимизации позволяют восстановить личность по косвенным признакам с пугающей точностью. Набор данных о перемещениях граждан с указанием времени и координат, даже без имён, позволяет идентифицировать конкретного человека по точкам его дома и работы. Поэтому обезличивание — это не разовое действие, а сложная процедура, требующая оценки рисков деанонимизации для каждого конкретного массива и каждого конкретного способа его использования. И решение о достаточности обезличивания для вывода данных за пределы защищённого контура должен принимать не конкретный исполнитель, а уполномоченное лицо с соответствующими компетенциями.