AI в компаниях уже используют. Где-то официально, через корпоративные инструменты. Где-то сотрудник открывает привычный чат и решает рабочую задачу без формальных правил. Запретить этот процесс на бумаге можно. Сделать вид, что после запрета он исчез, — нельзя.

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

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

Почему одного запрета недостаточно

Сотрудник приходит в AI не ради эксперимента. Ему нужно разобрать документ, собрать структуру презентации, проверить текст или быстрее найти ответ. Если компания не даёт разрешённого маршрута, задача никуда не исчезает.

Тотальный запрет создаёт простое противоречие: инструмент уже полезен, но пользоваться им официально нельзя. Чем больше AI входит в обычную работу, тем труднее удерживать такое положение одной инструкцией.

Но и разрешение без границ не работает. В одном запросе легко смешать общую методологию, имя заказчика, параметры изделия и условия договора. Для модели это один текст. Для компании — данные с разным режимом доступа.

Поэтому первый управленческий шаг — признать реальное использование AI. Второй — не выбирать одну «корпоративную нейросеть», а определить маршруты для разных данных.

Четыре категории чувствительности

Категория отвечает на вопрос: что именно сотрудник передаёт модели? Маршрут — в какой среде это допустимо обрабатывать? Эти решения связаны: сначала определяется чувствительность, затем доступный инструмент.

Публичные данные

Открытые стандарты, нормативные документы, публикации, материалы с официальных сайтов, собственный текст для внешнего размещения.

Маршрут: публичный внешний AI-сервис допустим с учётом общей политики компании.

Даже здесь нужен короткий контроль. Публичный документ может содержать внутренние комментарии, историю правок, закрытое приложение или добавленный сотрудником контекст. Открытый источник не делает автоматически открытым весь запрос.

Внутренние данные

Рабочая методология без специфики заказчика, шаблоны процессов, черновая структура презентации, нейтральные заметки и тексты.

Маршрут: одобренный корпоративный cloud/API или внутренний контролируемый контур.

Публичные и внутренние данные могут идти во внешнюю модель, но режим у них разный. Для внутреннего материала важны конкретный продукт, учётная запись, условия хранения и использования запросов. Случайный бесплатный чат и утверждённый корпоративный сервис — не один маршрут только потому, что под ними может работать похожая модель.

Конфиденциальные данные

Технические задания заказчиков, аналитика по конкретным проектам, внутренние разработки, документы с персональными или коммерчески чувствительными сведениями.

Маршрут: среда, допущенная к конкретному классу данных. Это может быть локальное развёртывание, корпоративная платформа или одобренный cloud/API-сервис с подходящими договорными и техническими условиями. Передача разрешённой части во внешний сервис возможна только как отдельно спроектированный и согласованный процесс.

Удалить название компании недостаточно. Заказчика могут раскрыть сочетание отрасли, города, параметров и сроков. Обезличивание — не замена слов, а проверка того, можно ли восстановить исходный контекст.

Данные с особо строгим режимом

Данные, для которых конкретный закон, условие договора или установленный режим защиты требует особенно строгой обработки: ключи доступа, сведения, составляющие коммерческую или государственную тайну, данные под конкретным ограничением NDA и другие материалы, где закрытая специфика составляет сам смысл задачи.

Маршрут: только изолированный контур, разрешённый для такого режима данных. Если подходящего контура нет — без AI.

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

Здесь анонимизация часто уничтожает сам предмет анализа. Убрать из технических характеристик уникальные параметры означает убрать то, ради чего документ обрабатывается.

Четыре категории чувствительности и связанные с ними маршруты обработки

Схема показывает базовые маршруты, а не жёсткое соответствие «один класс — одна модель». Публичный внешний сервис и одобренный корпоративный cloud/API оба находятся вне внутренней инфраструктуры, но дают разные договорные и технические гарантии. Внутренний контролируемый контур описывает среду on-prem или private cloud; локальная LLM может быть одним из её компонентов. Пунктирная ветка для конфиденциальных данных допустима только после подготовки, проверки остаточного риска и отдельного решения политики.

Четыре категории — не догма и не готовая политика информационной безопасности. В конкретной организации уровней может быть больше, а названия — другими. Важен сам переход: каждый класс данных должен иметь явный допустимый маршрут, а не абстрактное предупреждение «будьте осторожны».

Персональные данные проходят отдельную проверку

Персональные данные нельзя надёжно поместить в одну строку таблицы. Они пересекают разные рабочие сценарии и требуют отдельной проверки. Перечень зависит от ситуации, но обычно включает цель и минимизацию обработки, роли оператора и обработчика, правовое основание, поручение обработки, трансграничную передачу, сроки удаления, меры защиты и возможность привлечения конкретного AI-провайдера.

Файл без ФИО может остаться персональным. Должность, город, даты, редкая комбинация характеристик и контекст проекта иногда идентифицируют человека точнее фамилии.

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

Смешанный документ — нормальный случай, а не исключение

Многие рабочие документы не укладываются в одну категорию целиком. В презентации для заказчика структура и общая методология могут быть внутренними, а примеры из проекта — конфиденциальными. В техническом задании вводная часть бывает нейтральной, а параметры объекта — закрытыми.

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

Смешанный документ: сегменты разной чувствительности направляются по разным маршрутам

Новая схема намеренно не назначает персональным данным, техническим параметрам или данным заказчика безусловный маршрут. Все фрагменты сначала проходят одну проверку: режим данных, права субъекта, цель обработки и свойства конкретного endpoint. Только после неё выбирается разрешённый внешний маршрут, внутренний контролируемый контур либо изолированная обработка — а при отсутствии допустимой среды AI не используется.

Если каждый раз перекладывать это решение целиком на сотрудника, политика создаст дополнительную работу и начнёт проигрывать реальному процессу. Человек должен понимать границы, но система обязана ему помогать.

Политика должна стать частью инфраструктуры

На верхнем уровне достаточно карты категорий и маршрутов. Ниже начинается техническая система, которая применяет эту карту к реальным запросам.

Подсказка о чувствительности может приходить из метаданных документа, атрибута в карточке, типа директории, информационной системы или автоматически найденных признаков. На одном маршруте достаточно предупреждения. На другом система должна предложить разрешённый инструмент. Для отдельных данных передача во внешний сервис должна блокироваться.

Ни один из этих механизмов не снимает ответственность с человека. Но и человек не должен в одиночку воспроизводить всю политику безопасности перед каждым промтом.

Хорошая система действует в три слоя:

  • сотрудник понимает базовые категории и замечает очевидный риск;
  • интерфейс подсказывает допустимый маршрут и предупреждает о чувствительных данных;
  • технические ограничения блокируют действия, цена ошибки в которых слишком высока.

Обучение здесь идёт параллельно с инфраструктурой, а не вместо неё. Нельзя научить сотрудников правильному маршруту, пока сама компания его не определила и не предоставила.

Классификация должна существовать как данные

Пока категория живёт только в регламенте, автоматическая маршрутизация не будет устойчивой, проверяемой и масштабируемой. Системе нужны машинно-читаемые признаки чувствительности и ограничений.

Минимальная карточка документа или запроса может выглядеть так:

data_class: confidential
contains_personal_data: unknown
contractual_restrictions:
  - customer-confidential
authorization_scope:
  - project-team
allowed_routes:
  - local-corporate
classification_source: inherited
classification_confidence: 0.82
owner: project-team

Это не универсальная схема. Она показывает принцип: решение о маршруте должно опираться не на название файла и не на догадку модели, а на набор проверяемых признаков.

Метка может появиться несколькими способами:

  • назначаться человеком при создании или загрузке документа;
  • наследоваться от проекта, директории, информационной системы или рабочего пространства;
  • определяться правилами по типам данных, реквизитам, шаблонам и словарям;
  • предлагаться классификатором, который оценивает текст и контекст;
  • повышаться автоматически, если система нашла более чувствительный фрагмент.

Понижать класс автоматически опаснее, чем повышать. Если классификатор не уверен, безопасный вариант — выбрать более строгий маршрут или отправить решение человеку. Значение unknown должно означать «нужна проверка», а не «ограничений не найдено».

Чувствительность и право доступа — разные оси

Метка чувствительности отвечает на вопрос, где допустима обработка. Право доступа — кто вообще может получить документ или его фрагмент. Эти признаки нельзя сводить в одно поле.

Публичный по содержанию документ может лежать в закрытом проекте, а внутренний материал — быть доступным только конкретной команде. Низкая чувствительность не расширяет полномочия пользователя. И наоборот, право читать конфиденциальный документ не означает право отправлять его во внешний AI-сервис.

Это особенно важно для RAG и агентов. Фильтрация по пользователю, роли, проекту и источнику должна выполняться до извлечения фрагментов и до вызова модели. Нельзя сначала положить чужой документ в контекст, а потом попросить модель «не показывать лишнее».

Классификатор сам должен находиться в доверенном контуре

Здесь возникает архитектурная ловушка. Чтобы определить чувствительность текста, классификатор должен этот текст прочитать. Если сначала отправить документ внешней модели «для проверки», данные уже пересекли периметр до принятия решения.

Поэтому первичная классификация и подготовка должны выполняться внутри доверенной зоны:

  • локальными правилами и словарями;
  • DLP-механизмами;
  • локальной моделью классификации;
  • сервисом, который уже допущен к исходному классу данных.

Публичный или одобренный внешний сервис может участвовать только после того, как маршрут разрешён. Проверка не должна сама становиться утечкой.

AI-шлюз: технический маршрут запроса

Когда инструментов и пользователей становится много, правила удобнее применять не в каждом клиенте отдельно, а в общей точке — AI-шлюзе. Это не обязательно один физический сервер. Это логический слой между рабочим интерфейсом и моделями.

Запрос проходит несколько этапов.

1. Сбор контекста

Шлюз получает не только текст промта, но и контекст происхождения: пользователя, проект, источник документа, метку чувствительности, тип операции и запрошенные инструменты.

Фраза «сделай краткое резюме» ничего не говорит о риске. Тот же запрос к публичной статье и к закрытому ТЗ должен получить разные маршруты.

2. Классификация

Система объединяет унаследованные метки, правила, результаты локального анализа и решение пользователя. На выходе получается класс данных, дополнительные признаки и уровень уверенности.

Для простой внутренней шкалы безопасный default — использовать наиболее строгий маршрут: если в запросе соединены внутренний шаблон и конфиденциальный фрагмент, весь запрос получает конфиденциальный маршрут, пока система явно не разделила его на части. Но правовые и договорные ограничения многомерны и не всегда складываются в одну линейную шкалу. Policy engine должен объединять независимые признаки, а не только выбирать максимальное число.

3. Решение политики

Policy engine сопоставляет признаки запроса с правилами. Он отвечает не «какая модель умнее», а «какие действия допустимы»:

  • можно ли использовать внешний endpoint;
  • нужен ли корпоративный аккаунт;
  • разрешено ли сохранить историю;
  • требуется ли обезличивание;
  • какие инструменты и источники можно подключить;
  • нужен ли ручной approval;
  • должен ли запрос быть заблокирован.

Для этого ему нужен не только список моделей, но и реестр конкретных endpoints. Одна и та же модель в публичном чате, корпоративном SaaS и API-продукте может иметь разные условия хранения, обучения, доступа администраторов, географии обработки, субподрядчиков и журналирования. Маршрут разрешает не абстрактную модель, а определённый сервис в определённой конфигурации.

Решение policy engine должно быть единым и обязательным для анонимайзера, маршрутизатора и fallback-механизма. Если компоненты независимо получили разные маршруты, запрос блокируется, а не продолжает движение по наиболее удобной ветке.

4. Преобразование данных

Если политика допускает подготовку документа, преобразование происходит до выхода из доверенного контура. Возможны разные операции:

  • удаление полей, которые не нужны для задачи;
  • маскирование или токенизация идентификаторов;
  • замена точных значений диапазонами;
  • разделение документа на фрагменты;
  • извлечение только разрешённой структуры;
  • создание синтетического примера вместо исходного случая.

Редакция, псевдонимизация и обезличивание — не одно и то же. Если таблица соответствия «токен → реальное имя» сохраняется, данные остаются восстановимыми и требуют защиты. Если уникальный технический параметр оставлен без названия заказчика, контекст всё равно может раскрыться.

Практический вариант — стабильные плейсхолдеры внутри одного запроса и короткоживущая карта обратной замены в доверенном контуре. После преобразования нужен повторный поиск остаточных сущностей. Если сохранились стоп-категории — например, ключи доступа или банковские реквизиты, — внешний вызов должен блокироваться, а не уходить «с предупреждением».

Текстовый фильтр не покрывает автоматически изображения, сканы, архивы, таблицы и структурированные payloads инструментов. Вложения требуют собственного pre-processing gate: разбор формата, OCR при необходимости, проверку скрытых слоёв и повторную классификацию извлечённого содержимого.

5. Выбор модели и контура

Только после решения политики model router выбирает endpoint:

  • внешний общедоступный сервис для публичных данных;
  • одобренный корпоративный cloud/API для внутренних данных;
  • внутренний контролируемый контур для конфиденциальных данных;
  • изолированный режимный контур для данных с особо строгим режимом;
  • отказ от AI, если допустимого маршрута нет.

Качество модели учитывается внутри уже разрешённого множества. Нельзя сначала выбрать лучший endpoint, а затем пытаться приспособить к нему данные.

Fallback-цепочка тоже является частью политики. Отказ локальной модели не должен автоматически переключать конфиденциальный запрос на внешний endpoint. Резерв выбирается только из разрешённого для этого класса множества; если такого варианта нет, запрос завершается ошибкой или уходит на ручное решение.

6. Контроль ответа

Маршрут не заканчивается вызовом модели. Ответ может повторить исходные данные, объединить сведения из нескольких источников или создать новый чувствительный вывод.

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

Есть и вторая проверка: ответ модели не становится доверенным только потому, что прошёл через разрешённый endpoint. Перед вставкой в HTML, SQL, shell-команду или вызов инструмента результат нужно разобрать и проверить по правилам целевой системы. Модель предлагает действие, но не выдаёт себе полномочия на его выполнение.

Ответ, tool call и созданный файл получают производную метку от использованных источников. До отправки в чат, почту, файловое хранилище или внешний API система проверяет допустимость канала. Обратная подстановка плейсхолдеров восстанавливает текст, но сама по себе не контролирует его дальнейшую утечку.

7. Аудит

Системе нужен журнал решений: кто отправил запрос, какой класс был назначен, какое правило сработало, какой endpoint выбран, какие преобразования выполнены и почему операция разрешена или заблокирована.

Это не означает хранить полный текст каждого промта. Для чувствительных данных сам журнал может стать новой копией секрета. Политика должна отдельно определять, какие метаданные сохраняются, где лежат трассировки и когда они удаляются.

Технические метрики и security-аудит — разные артефакты. Для доказуемого решения нужен связанный decision record: субъект, входные метки, версия политики, операция, разрешённые источники и инструменты, выбранная граница доверия, fallback, преобразования и итоговая метка результата. Потеря метрик может быть допустима; потеря обязательного security-решения — нет.

Архитектура AI-шлюза: классификация, политика, подготовка данных, маршрутизация и аудит

Рамка на схеме обозначает доверенную зону AI-шлюза. Среды обработки вынесены за неё и имеют собственные границы доверия: публичный внешний сервис, одобренный корпоративный cloud/API, внутренний контролируемый контур и изолированный режимный контур. Локальная LLM не показана отдельной альтернативой «корпоративному AI»: она может работать внутри внутреннего контура. Ответ из любой среды возвращается через контроль результата внутри шлюза и только затем — пользователю или подключённой системе.

Маршрут охватывает не только модель

Фраза «данные не покидают наш сервер» ничего не гарантирует, если остальные компоненты живут в других местах. Проверять нужно весь путь.

Копии исходных данных могут появиться в:

  • временных файлах OCR и парсинга;
  • истории чата;
  • логах и трассировках;
  • кэше;
  • embeddings и векторной базе RAG;
  • резервных копиях;
  • системах мониторинга;
  • подключённых инструментах и внешних API.

Embeddings не стоит считать автоматически обезличенными. Это производные от исходных данных, которые остаются частью поискового контура. Безопасный default организации — заставить индекс, векторную базу и извлечённые фрагменты наследовать режим и ACL источника. Поиск обязан учитывать права пользователя до формирования контекста, а не фильтровать уже готовый ответ модели; для жёстких границ доверия надёжнее разделять индексы, чем полагаться на необязательный фильтр общей коллекции.

То же относится к агентам. Если модель имеет доступ к почте, файловому хранилищу и CRM, политика должна контролировать не только входной промт, но и список разрешённых действий. Прямое чтение, семантический поиск, память, вложения и результаты инструментов проходят одинаковую авторизацию. Каждый инструмент получает отдельные минимальные полномочия. Для необратимого действия недостаточно булевого approved: подтверждение связывается с субъектом, объектом, точной операцией или diff и ограниченным сроком действия. Открытый документ из интернета может содержать prompt injection — инструкцию, которая пытается заставить агента обратиться к закрытому источнику или выполнить нежелательное действие. Retrieved-текст остаётся данными и не может сам расширять полномочия агента. Классификация данных и доверие к инструкциям — две разные проверки.

Целевая архитектура — гибридная

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

Поэтому вопрос «облако или локально» слишком грубый. Компании нужен гибридный контур:

  • внешние модели — для публичных и допустимых внутренних данных;
  • корпоративные или локальные модели — для чувствительных сценариев;
  • правила маршрутизации — между ними;
  • ручной процесс без AI — там, где безопасного маршрута пока нет.

Такая архитектура становится рабочим ориентиром для организаций, которые уже используют несколько AI-сервисов и обрабатывают данные с разными режимами. Не потому, что локальные модели скоро заменят внешние. Наоборот: гибрид нужен именно потому, что разные модели и среды решают разные задачи.

Локальный endpoint при этом не равен безопасному endpoint. Для него всё равно нужны управление доступом, сетевые границы, защита секретов, контроль логов, резервных копий, обновлений моделей и подключённых инструментов. «Запустили модель у себя» — начало архитектуры, а не её завершение.

Что показал практический прототип

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

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

Самая трудная часть оказалась не в переключении моделей, а в сквозном enforcement. Метка должна без потерь пройти от источника через чтение документа, RAG, шлюз, инструменты и журналирование. В моём прототипе автоматический классификатор пока остаётся точкой расширения, а не надёжным механизмом защиты. Неизвестная метка обрабатывается мягче, чем требует описанный здесь fail-safe принцип, часть защитных гейтов зависит от конфигурации, а блокировка по остаточному риску ещё требует проверки на реальных документах.

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

Как внедрять без большого взрыва

Не нужно сначала строить идеальный AI-шлюз на всю компанию. Начинать лучше с нескольких реальных сценариев и данных, которые в них проходят.

Шаг 1. Инвентаризация

Собрать не только перечень официальных AI-сервисов, но и задачи, для которых сотрудники уже используют модели: документы, код, поиск, аналитика, презентации, переписка.

Цель — увидеть фактическое использование, а не составить список нарушителей.

Шаг 2. Карта данных и маршрутов

Для каждого сценария определить входные данные, владельца, ограничения и допустимые endpoints. На этом этапе четыре категории проверяются на реальных смешанных документах.

Шаг 3. Разрешённый минимальный контур

Дать сотрудникам хотя бы один официальный внешний инструмент для безопасных задач и один контролируемый маршрут для чувствительных. Если разрешённого пути нет, политика снова толкает работу в тень.

Шаг 4. Pilot AI-шлюза

Вынести в общий слой аутентификацию, журнал решений, model routing и несколько самых надёжных правил. Не пытаться сразу автоматически распознавать все виды информации.

Шаг 5. Автоматизация классификации

Добавлять метки, наследование, DLP-правила и локальные классификаторы там, где ручное решение создаёт больше всего трения. Оценивать нужно не только полноту обнаружения, но и ложные блокировки: система, которая мешает каждой второй безопасной операции, быстро теряет доверие.

Шаг 6. Обучение на работающих маршрутах

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

Что пока не решает эта модель

Даже технический pipeline не превращает классификацию в точную науку.

Открыты как минимум четыре сложных вопроса:

  • как надёжно определять чувствительность смешанного документа;
  • как проверять качество обезличивания и риск восстановления контекста;
  • как компенсировать разницу между возможностями локальных и внешних моделей;
  • где поставить границу автоматической блокировки, чтобы защита не остановила работу.

Ответы будут отличаться по отраслям и организациям. Где-то достаточно атрибутов и выделенных директорий. Где-то потребуется AI-шлюз, DLP-контроль, локальный классификатор и отдельный сервис подготовки данных.

Здесь важен fail-safe принцип: неопределённость не должна молча превращаться в разрешение. Но и постоянный отказ — плохая архитектура. Система должна уметь выбрать более строгий маршрут, запросить подтверждение или передать решение владельцу данных.

Где здесь законодательство

Авторскую модель категорий не нужно выдавать за универсальное требование закона. Обязанности организации зависят от режима информации, типа информационной системы, договоров и статуса самой организации.

Но нормативные документы задают важные границы. Требования ФСТЭК, утверждённые приказом №117, относятся к государственным ИС, ИС государственных органов, ГУПов и госучреждений. В числе требований пунктов 60–61 предусмотрены ограничения на передачу разработчику AI-модели информации ограниченного доступа из таких систем и необходимость определить допустимые тематики запросов и контролировать их соблюдение. Точные обязанности нужно читать в контексте области применения приказа и конкретного сценария использования AI.

Приказ нельзя автоматически распространять на любую компанию. Но за ним виден общий архитектурный принцип: недостаточно защитить сервер с моделью. Нужно управлять тем, какие запросы, данные и ответы проходят через AI-систему.

Для остальных сценариев маршрут сверяется с законодательством о персональных данных и информации, договорами, NDA и внутренними политиками. Таблица чувствительности помогает организовать это решение, но не заменяет его юридическую проверку.

Что должно сделать руководство

Не начинать с запрета и не заканчивать покупкой одной модели.

  1. Признать, какие AI-инструменты и сценарии уже используются.
  2. Определить категории чувствительности на понятных сотрудникам примерах.
  3. Назначить разрешённый маршрут и инструмент для каждой категории.
  4. Дать людям официальный путь хотя бы для самых частых безопасных задач.
  5. Проверить модель на смешанных документах и пограничных случаях.
  6. Вынести повторяемые решения в метки, policy engine и технические ограничения.
  7. Параллельно обучать сотрудников на уже работающей системе.

AI становится официальной корпоративной практикой не после приказа «разрешить». Он становится ею, когда сотрудник знает границы, компания предоставляет рабочий маршрут, а система помогает не ошибиться.

Источники

Короткие апдейты и разборы — в Telegram-канале Mind & Mesh: @takeshi_ku.