Начните с документа, а не с названия сервиса

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

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

FIPS 199 предлагает смотреть на последствия потери конфиденциальности, целостности и доступности. Это полезнее ярлыка «PDF»: договор, публичная инструкция и база клиентов могут иметь одинаковое расширение, но разный ущерб. Для AI добавьте вопрос о последствиях ложного вывода и автоматического действия.

Классификация данных и чек-лист перед отправкой

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

Класс

Примеры

Допустимое действие

Что обязательно проверить

PUBLIC

Опубликованная статья, открытая инструкция

Можно в одобренном рабочем продукте

Лицензия, целостность, внешние инструкции

INTERNAL

Черновик без секретов, внутренняя памятка

Минимальный фрагмент в business-контуре

Договор, роли, history, retention

CONFIDENTIAL

Клиентский кейс, непубличные показатели, договор

Только явно согласованный защищённый workflow

Регион, logs, subprocessors, deletion, аудит

RESTRICTED

Пароли, ключи, особые категории данных, критический секрет

Не отправлять без специального письменного разрешения

Изолированный контур и отдельная risk assessment

У класса есть три измерения. Confidentiality отвечает за раскрытие, integrity — за опасность незаметной подмены, availability — за зависимость процесса от доступа. Таблица зарплат чувствительна по раскрытию; утверждённая инструкция по безопасности — по целостности; единственная копия плана восстановления — по доступности. AI-задача не должна ухудшать ни одно из них.

Проверьте точный путь данных

Нарисуйте одну строку движения: рабочее место → приложение → gateway → model endpoint → storage → logs → connectors → ответ. Добавьте людей и организации, имеющих административный доступ. Если звено неизвестно, оно не становится безопасным. Запрос через браузерное расширение и запрос к корпоративному API могут попасть к разным сторонам.

Не переносите условия с одного продукта на другой. Consumer chat, business workspace, API, облачный marketplace и независимый wrapper могут иметь разные training defaults, retention, регионы и механизмы удаления. Проверяйте актуальный документ, договор и настройки именно того endpoint, который реально используется.

Фраза «не обучаем на business data» важна, но недостаточна. Уточните журналы abuse monitoring, human review, chat history, загруженные файлы, vector stores, cache и backups. Выясните, какие артефакты удаляются автоматически, какие — отдельным API, и что остаётся по security или legal obligations.

Сведите вход к минимально нужному

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

Замените прямые идентификаторы стабильными псевдонимами: «Клиент A», «Проект B». Удалите телефоны, адреса, реквизиты, подписи, hidden sheets, comments, tracked changes, EXIF и свойства документа, если они не нужны. Сохраните mapping отдельно в разрешённом хранилище, а не рядом с prompt.

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

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

Считайте документ недоверенным входом

Файл может содержать скрытую инструкцию: белый текст, комментарий, строку в таблице или фразу на странице, найденной retrieval. Для человека это содержание документа, для агента — возможная команда. OWASP называет такой сценарий indirect prompt injection. Авторитет источника данных не доказывает безопасность его инструкций.

Разделяйте data и instructions в архитектуре, но не считайте это абсолютной защитой. Ограничьте доступные инструменты, запретите произвольные URL и команды, валидируйте аргументы, требуйте подтверждение перед внешним действием. Для чтения договора агенту не нужен доступ к почте, файловой системе и публикации сообщений.

Если документ пришёл извне, проверьте тип, размер, активное содержимое и malware штатным pipeline. Конвертация в безопасный текстовый слой может уменьшить поверхность, но сохраняйте связь с оригиналом для проверки цитат. Парсер и OCR тоже ошибаются; извлечённый текст нельзя считать безусловной истиной.

Ограничьте доступ внутри команды

Используйте отдельный организационный workspace, SSO, роли и короткий список администраторов, если платформа это поддерживает. Запретите личные аккаунты для рабочих материалов. Выдавайте connectors только нужным группам и scopes. Полный доступ ко всему диску ради одного резюме противоречит least privilege.

Секреты не должны попадать в prompt, системные инструкции, screenshots или логи. Храните credentials в secret manager и выдавайте инструменту ограниченный token. Настройте audit log для загрузок, tool calls, изменений политики и удаления. Лог также классифицируется: он может содержать исходный текст или ответ.

Локальная модель не освобождает от этих мер. Проверьте endpoint authentication, сетевую сегментацию, telemetry, crash dumps, embeddings, snapshots и backups. Если интерфейс доступен всей сети без ролей, локальное размещение лишь меняет место утечки.

Проверьте ответ до использования

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

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

Проверяйте output на данные, которые не должны попасть к следующему получателю. Модель может воспроизвести фрагмент документа в резюме, имени файла, telemetry или downstream ticket. Минимизация нужна и на выходе, а доступ к результату не должен быть шире исходного доступа.

Чек-лист перед каждой отправкой

  • Определены владелец, рабочая цель и минимально достаточный результат.

  • Документ отнесён к PUBLIC, INTERNAL, CONFIDENTIAL или RESTRICTED; спорный случай остановлен.

  • Проверены точный продукт, endpoint, тариф, договор, регион, training, retention и monitoring.

  • Перечислены приложение, gateway, storage, logs, connectors, subprocessors и администраторы.

  • Удалены ненужные страницы, поля, прямые и косвенные идентификаторы, metadata и секреты.

  • Для внешнего файла учтены malware и indirect prompt injection; инструменты ограничены.

  • Настроены роли, scopes, audit log и отдельное хранение mapping либо ключей.

  • Задан способ сверки критичных выводов с исходником и ответственный за приёмку.

  • Понятно, как удалить chat, uploaded file, store, cache и локальные временные копии.

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

Если хотя бы один обязательный пункт неизвестен, не загружайте документ и ищите меньший безопасный вариант: локальное извлечение, ручной redaction, approved API, синтетический пример или обработка без AI. Это не отказ от автоматизации, а управление границей данных.

Практический следующий шаг

Возьмите один низкорисковый процесс и заполните таблицу для реального файла. Пройдите путь данных вместе с владельцем безопасности, зафиксируйте endpoint и настройки, создайте redaction template и тест prompt injection. После пилота проверьте logs и удаление, а не только качество ответа.

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

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

Что читать дальше