Политика хранения данных отвечает на практический вопрос: где остаётся каждый фрагмент после использования ИИ-сервиса и когда он перестаёт существовать во всех управляемых копиях. Одной настройки «не использовать для обучения» недостаточно. Запрос может не участвовать в улучшении модели, но сохраняться в истории, журналах безопасности, резервных копиях, интеграционной очереди и локальной выгрузке сотрудника.
Документ нужен до подключения рабочих данных. Он не должен пересказывать рекламные обещания поставщика. Его задача — связать внутренние категории сведений, конкретный сценарий, технические настройки и официальные условия выбранного тарифа. Для обязательных правовых требований привлеките специалиста по вашей юрисдикции и отрасли: универсальная статья не определяет законное основание и сроки за конкретную организацию.
Опишите контур, а не только чат#
Нарисуйте путь данных от источника до удаления. В простом сценарии участвуют: устройство сотрудника, браузер, ИИ-сервис, модель поставщика, журнал администратора и экспорт результата. В интеграции добавятся CRM, промежуточный сервер, очередь, хранилище файлов, система наблюдения и подрядчики каждого звена.
Для каждого узла заполните карточку:
- какие поля поступают;
- зачем они нужны;
- кто имеет доступ;
- где физически или логически хранятся;
- создаются ли производные данные;
- срок активного хранения;
- срок в резервных копиях;
- способ удаления;
- как подтверждается удаление;
- кто отвечает за настройку.
Если часть цепочки неизвестна, это не повод написать «по политике поставщика». Найдите официальный документ или запросите разъяснение. Неизвестное отмечается как открытый риск и не допускается к чувствительному сценарию до решения.
Разделите виды данных#
Запрос и ответ — только видимая часть. Полный реестр обычно включает:
| Вид | Примеры | Особенность хранения |
|---|---|---|
| вход пользователя | текст, файл, изображение, аудио | может содержать больше сведений, чем нужно задаче |
| ответ модели | текст, сводка, извлечённые поля | способен повторять фрагменты входа |
| история диалога | цепочка запросов и контекст | накапливает сведения из разных задач |
| база знаний | документы и индексы | требует версий и отзыва устаревшего |
| журналы | время, аккаунт, технические события | срок может отличаться от истории чата |
| обратная связь | оценки, исправления, жалобы | иногда используется отдельным процессом улучшения |
| резервные копии | снимки систем и файлов | удаление часто отложено до ротации |
| экспорт | таблицы, отчёты, архивы | выходит из контроля исходного сервиса |
| кэш и очередь | временные копии интеграции | легко забываются в архитектурной схеме |
Отдельно учитывайте производные представления: фрагменты документов, поисковые индексы, векторные представления, сводки и извлечённые атрибуты. Удаление исходного файла не обязательно автоматически отзывает каждую производную копию. Это поведение нужно проверить и протестировать.
Классифицируйте сведения по внутренним правилам#
Используйте уже принятую классификацию компании. Если её нет, создайте минимальные зоны: публичные, внутренние, конфиденциальные и запрещённые для внешнего ИИ-контура. Перечень категорий должен быть конкретным: не «важная информация», а клиентские контакты, реквизиты, пароли, условия конкретного договора, внутренние цены, медицинские или иные специальные сведения, если они встречаются в вашем процессе.
Для каждой категории решите:
- разрешена ли она в выбранном сервисе;
- требуется ли обезличивание;
- может ли сохраняться история;
- кто согласует исключение;
- какой максимальный срок допустим;
- можно ли выгружать результат;
- что происходит при ошибочной загрузке.
Базовый регламент допустимых данных разобран в материале что нельзя отправлять в нейросеть. Политика хранения решает соседнюю задачу: что происходит с разрешённым материалом после передачи.
Свяжите срок с целью#
Фраза «храним столько, сколько необходимо» не помогает администратору настроить систему. Для каждой категории и копии нужна либо конкретная длительность, либо проверяемое событие: до завершения задачи, до закрытия проекта, до отзыва документа, до окончания установленного периода резервного хранения.
Матрица срока:
| Данные | Цель | Активный срок | Резервный срок | Владелец удаления | Подтверждение |
|---|---|---|---|---|---|
| история рабочих чатов | продолжение задачи | значение по внутреннему решению | отдельное значение | администратор | отчёт или тестовый запрос |
| загруженные файлы | обработка документа | до результата или проекта | по циклу резервов | владелец проекта | файл и производные не находятся |
| база знаний | ответы по правилам | пока версия действует | архив по регламенту | владелец знания | старая версия исключена из выдачи |
| технический журнал | безопасность и разбор сбоев | утверждённый период | если резервируется | ИТ | запись недоступна после срока |
Не копируйте числа из чужого шаблона. Срок зависит от цели, договоров, отраслевых и правовых требований, возможностей системы. Задача политики — зафиксировать обоснованное внутреннее решение и реализовать его технически.
Минимизация важнее точной длительности. Если задача решается без сохранения истории или без полного документа, не храните их. Отправляйте только нужный фрагмент, выключайте ненужную историю, разделяйте проекты и удаляйте временные выгрузки.
Проверьте официальные условия поставщика#
На дату 14 августа 2026 года сохраните ссылки или копии официальных документов именно по используемому продукту и тарифу. Условия личного чата, корпоративного рабочего пространства и программного интерфейса могут различаться. Проверяйте не общий бренд, а фактический маршрут данных.
Вопросник поставщику:
- используются ли входы, ответы и обратная связь для обучения или улучшения;
- какие настройки меняют это поведение и кто может их включить;
- сколько хранится видимая история;
- есть ли отдельный обязательный срок технического или защитного хранения;
- как работает временный режим;
- что происходит после удаления пользователем и администратором;
- когда исчезают резервные копии;
- как удалить аккаунт, проект и загруженную базу;
- удаляются ли индексы и другие производные данные;
- какие подрядчики участвуют и для каких функций;
- где доступны журналы администратора;
- как сообщают об инцидентах и изменениях условий;
- можно ли экспортировать данные до прекращения договора.
Ответы переносите в реестр с цитатой положения, адресом и датой проверки. Обзор или ответ продавца в переписке может помочь найти документ, но для изменяемой характеристики опирайтесь на официальное условие или согласованное приложение к договору.
Управляйте доступом и историей#
Рабочие задачи ведутся в корпоративных учётных записях. Назначьте роли администратора, владельца проекта, пользователя и проверяющего. Увольнение или перевод сотрудника должны приводить к отзыву доступа без сохранения рабочей истории в личном аккаунте.
Настройте:
- единый вход и многофакторную защиту, если они доступны и требуются;
- минимальные роли;
- запрет публичных ссылок по умолчанию;
- отдельные проекты для разных команд и уровней сведений;
- журнал административных изменений;
- периодический пересмотр участников;
- ограничение интеграционных ключей;
- ротацию и отзыв ключей;
- удаление временных файлов на устройствах.
История чата удобна, но объединяет контекст. Пользователь может продолжить старый разговор новыми данными и невольно смешать проекты. Укажите, когда создаётся новый диалог, когда история очищается и можно ли копировать результат в другие системы.
Опишите удаление как процедуру#
«Удалить данные» — не одно действие. В процедуру входят: закрыть доступ, удалить видимый объект, отозвать его из поиска и базы знаний, очистить интеграционные копии, дождаться ротации резервов, проверить экспорт и сохранить допустимое подтверждение операции.
Сценарии удаления:
- штатное окончание срока;
- отзыв ошибочного документа;
- удаление проекта;
- увольнение сотрудника;
- ошибочная загрузка запрещённых сведений;
- прекращение договора с поставщиком;
- запрос, который организация обязана обработать по применимым правилам.
Назначьте исполнителя и резервного исполнителя. Для срочного инцидента установите канал сообщения и запрет на наказание за добросовестное уведомление: скрытая ошибка опаснее самой ошибки. Не обещайте немедленное уничтожение резервов, если архитектура этого не позволяет; точно опишите изоляцию и срок ротации.
Проверьте фактическое исполнение#
Политика не считается внедрённой после подписи. Раз в установленный период выполняйте контрольный тест. Создайте тестовый документ с уникальной меткой, загрузите разрешённым способом, найдите его через все интерфейсы, затем запустите удаление. После заявленного этапа проверьте историю, поиск, базу, экспорт и интеграционные журналы.
Аудит включает:
- совпадают ли настройки с документом;
- не появились ли новые интеграции и расширения;
- действуют ли сроки автоматического удаления;
- есть ли просроченные проекты и аккаунты;
- исключаются ли отозванные документы из ответов;
- обновились ли условия поставщика;
- способны ли сотрудники описать порядок ошибки;
- выполнялся ли тест восстановления и удаления.
Любое существенное изменение сервиса запускает внеплановую проверку: новый тариф, функция памяти, подключение диска, смена подрядчиков, новая база знаний или другой регион обработки. Дата «обновлено» без содержательной сверки не считается проверкой.
Каркас внутренней политики#
Итоговый документ может состоять из десяти разделов:
- цель и область применения;
- разрешённые сервисы и сценарии;
- категории данных и запреты;
- карта потоков и подрядчиков;
- сроки по видам копий;
- доступы и журналирование;
- удаление и прекращение договора;
- действия при ошибке или инциденте;
- обучение сотрудников;
- периодичность проверки и владелец.
Приложите реестр официальных условий с датой 14 августа 2026 года, матрицу сроков, перечень администраторов и форму проверки удаления. Секрет документа не в объёме, а в связи каждой строки с настройкой и ответственным.
Главный критерий готовности звучит так: для любого рабочего запроса команда может показать все места, где он сохраняется, основание и срок каждой копии, способ удаления и человека, который это проверяет. Если хотя бы одно звено описано словом «обычно», контур ещё не управляется и чувствительные данные в него передавать рано.
Роли и журнал решений#
У политики должен быть владелец, но решения распределены. Владелец процесса определяет необходимость данных, специалист по данным и праву — допустимые условия в применимом контексте, ИТ реализует настройки и удаление, безопасность проверяет доступы и инциденты, закупки сохраняют договорные подтверждения, пользователи соблюдают разрешённый сценарий.
Создайте журнал исключений. В нём указывают категорию данных, цель, сервис и тариф, запрошенное отклонение, обоснование, компенсирующие меры, согласующих, срок действия и дату пересмотра. Бессрочное устное исключение разрушает политику быстрее, чем отсутствие документа.
Журнал изменений поставщика храните отдельно: дата обнаружения, ссылка на официальный документ, что изменилось, какие сценарии затронуты, решение и ответственный. Если публичные условия и договорное приложение расходятся, ситуацию разрешают до продолжения передачи соответствующих данных.
Прекращение использования сервиса#
План выхода составляют при подключении. Сначала инвентаризируйте проекты, базы, аккаунты, ключи, интеграции и выгрузки. Экспортируйте только то, что действительно нужно сохранить и разрешено перенести. Затем остановите новые записи, отзовите ключи, удалите рабочие объекты, проверьте производные индексы и получите предусмотренное подтверждение.
Отдельно контролируйте локальные копии: файлы в загрузках, таблицы администраторов, резервные выгрузки проекта. Удаление облачного рабочего пространства не затрагивает их. Обновите реестр разрешённых сервисов и инструкции сотрудников, чтобы старый контур не продолжил жить через личные аккаунты.
После заявленного срока повторите поиск тестовой метки и проверку административных интерфейсов. Если поставщик хранит изолированные резервные копии до ротации, зафиксируйте дату окончания этого периода и ограничения доступа. Закрытие считается завершённым после прохождения всего чек-листа, а не после нажатия кнопки удаления аккаунта.