Суть системы ИИ, соответствующей KVKK, в том, чтобы заранее, на уровне архитектуры, определить, куда уходят персональные данные, кто их видит и как долго они хранятся. В системах RAG и ИИ-агентах ответы на эти три вопроса даются не в одном месте, а на каждой остановке, через которую проходят данные: при разбиении документа и построении векторов, при отправке результатов поиска в модель, при записи ответа в журнал и при выполнении агентом действия в другой системе. Если граница данных не зафиксирована письменно на каждой из этих остановок, даже проект с самыми добрыми намерениями приходит к потоку данных, который трудно объяснить на проверке.
Статья предназначена для технических руководителей, владельцев продуктов и команд по соответствию, которые планируют внутреннего RAG-ассистента или ИИ-агента, работающего с корпоративными системами в Турции. KVKK означает турецкий Закон о защите персональных данных (Закон № 6698); схожие принципы действуют и в рамках GDPR, хотя эти режимы не идентичны. Это не юридическая консультация. Здесь описано, какие инженерные решения нужно принять и каких понятий KVKK они касаются. Обязательства, относящиеся к вашей ситуации, обязательно уточните у своего юриста.
Почему KVKK требует отдельного проектирования в ИИ-проектах?
В классическом веб-приложении персональные данные обычно лежат в известных таблицах и известных полях. В системах ИИ данные меняют форму и размножаются. PDF делится на фрагменты, каждый фрагмент превращается в вектор, отобранные поиском фрагменты вставляются в промпт, промпт уходит к поставщику модели, а ответ, часто вместе с самим промптом, записывается в журнал. За несколько секунд одни и те же персональные данные могут оказаться в четырёх местах и в четырёх формах.
Поэтому базовые вопросы KVKK остаются прежними, но найти ответы на них сложнее:
- Какие персональные данные обрабатываются? В документах могут быть имена клиентов, номера удостоверений личности, сведения о здоровье или оценки сотрудников. Большинство компаний замечают это не при загрузке документов, а при первом неверном ответе.
- Куда передаются данные? Если серверы поставщика модели находятся за рубежом, персональные данные внутри промпта передаются за границу.
- Кто имеет доступ? Если сотрудник без прав в системе документооборота может получить то же содержание через ассистента, контроль доступа нарушен.
- Как долго хранятся данные? У векторной базы, журналов промптов и журналов самого поставщика разные сроки хранения, и редко кто рассматривает их вместе.
Через какие остановки проходят данные в системе RAG?
Безопасность корпоративного RAG начинается с того, чтобы прорисовать путь данных по остановкам. В типичном потоке RAG пять остановок, и у каждой свой риск.
- Исходная система: место, где хранятся документы (файловый сервер, система документооборота, CRM, почтовый архив). Риск: массовая загрузка документов вне согласованного объёма.
- Подготовка и разбиение: документы переводятся в текст и делятся на части. Риск: обработка персональных данных без маскирования.
- Векторизация и векторная база: фрагменты превращаются в векторы и сохраняются. Риск: модель эмбеддингов работает как внешний API, а фрагменты хранятся без сведений о правах доступа.
- Поиск и сборка промпта: фрагменты отбираются под вопрос пользователя и отправляются в модель. Риск: в ответ попадают фрагменты, к которым у пользователя нет доступа.
- Модель и журналирование: генерируется ответ, промпт и ответ записываются в журнал. Риск: бессрочное хранение журналов и использование данных поставщиком в собственных целях.
Нарисовать этот список как схему потоков данных и рядом с каждой остановкой указать «какие персональные данные, в какой стране, кто имеет доступ, как долго» означает получить самый ценный документ проекта и для технической стороны, и для команды по соответствию.
Считается ли отправка данных поставщику модели трансграничной передачей?
Если промпт с персональными данными отправляется поставщику модели, чьи серверы находятся за пределами Турции, это, как правило, рассматривается как передача персональных данных за границу. Статья 9 KVKK была переработана поправками 2024 года. По новым правилам сначала проверяется наличие решения об адекватности; если его нет, требуется надлежащая гарантия: стандартный договор, обязательные корпоративные правила или письменное обязательство с разрешения Совета. При использовании стандартного договора к обязанностям относится и уведомление Управления по защите персональных данных в установленный срок после подписания.
Для инженерной команды это означает, что в начале проекта нужно ответить на следующие вопросы:
- Что сказано в соглашении об обработке данных (DPA) поставщика модели? Используются ли переданные данные для обучения модели, и если нет, закреплено ли это письменно?
- В каком регионе поставщик обрабатывает и хранит данные? Можно ли выбрать регион?
- Как долго поставщик хранит промпты для контроля злоупотреблений? Можно ли сократить этот срок до нуля?
- Какая гарантия будет использована для передачи и кто займётся необходимым уведомлением или получением разрешения?
Юридический ответ на эти вопросы зависит от вашей собственной оценки как оператора данных. Задача технической команды состоит в том, чтобы собрать всю информацию для такой оценки и построить архитектуру, которую можно изменить в соответствии с принятым решением. Не исходите из допущения «поставщик крупный, значит, всё в порядке», не уточнив это у своего юриста.
Как удалить персональные данные до векторизации?
Самые безопасные персональные данные те, что вообще не попадают в систему. Чтобы RAG-ассистент мог ответить, ему редко нужны имя клиента или номер удостоверения; обычно достаточно самой процедуры, пункта договора или технического пояснения. Поэтому на этапе подготовки вместе применяются три техники:
- Фильтр объёма: письменно определяется, какие папки, типы документов и периоды попадают в систему. Подход «загрузим весь общий диск» является самой частой ошибкой границы данных.
- Анонимизация: персональные данные, не нужные для ответа, удаляются из текста до векторизации. Действительно необратимая анонимизация может лишить данные статуса персональных, но в её необратимости нужно быть уверенным.
- Псевдонимизация: если связь с человеком нужна, но модели видеть её не обязательно, поля вроде имени и номера удостоверения заменяются ключом. Таблица соответствия хранится отдельно с ограниченным доступом. Псевдонимизированные данные остаются персональными, но к модели и поставщику попадает меньше.
Правил маскирования на одних регулярных выражениях недостаточно: имена, адреса и сведения о здоровье в свободном тексте не подчиняются шаблонам. На практике сочетают правила с моделью распознавания сущностей и измеряют результат на выборке документов. Фраза «мы маскируем данные» без тестового набора, показывающего долю пропущенных персональных данных, гарантией не является.
Как применять контроль доступа в момент поиска?
Самая коварная брешь в безопасности корпоративного RAG возникает, когда ассистент показывает всем одни и те же документы. Если сотрудник без доступа к папке отдела кадров спрашивает «какая у нас шкала зарплат» и получает ответ от ассистента, система фактически отключила модель прав документооборота.
Правильный подход в том, чтобы применять права во время поиска, а не после генерации ответа:
- Каждый фрагмент несёт список доступа исходного документа (пользователь, группа или роль) в виде метаданных.
- Поисковый запрос фильтруется по личности и группам спрашивающего; фрагменты, на которые у него нет прав, вообще не попадают в список кандидатов.
- При изменении прав в исходной системе метаданные в векторной базе тоже обновляются. Задержка этой синхронизации измеряется и привязывается к письменной цели.
- Вместе с ответом показывается исходный документ; если пользователь не может открыть этот документ, ответ не должен содержать сведений из него.
Инструкция модели «не раскрывай информацию, на которую у пользователя нет прав» контролем доступа не является. Если модель увидела фрагмент, она так или иначе может допустить утечку в ответ. Права должны применяться на том уровне, который определяет, какие данные доходят до модели.
Как провести границу данных в агентных системах?
Система RAG читает, а агент действует. Если агент может обновлять записи в CRM, отправлять письма или выполнять запросы к базе данных, риск с точки зрения KVKK выходит за рамки чтения: отправка данных не тому адресату, несанкционированные изменения и действия без записи. Мы подробно разобрали эту тему в статье о выводе ИИ-агентов в продакшен; с точки зрения границы данных главные правила такие:
- Минимальные привилегии: агент работает с самыми узкими правами, нужными для задачи. Если достаточно чтения, права на запись не выдаются; если достаточно одной таблицы, вся база не открывается.
- Действие от имени пользователя: агент работает с правами пользователя, инициировавшего действие, а не со своей широкой сервисной учётной записью. Так агент не сможет сделать то, чего не может сам пользователь.
- Шлюзы подтверждения человеком: действия, которые отправляют данные наружу, удаляют записи или вносят массовые изменения, не выполняются без одобрения человека.
- Границы на уровне инструментов: каждый инструмент агента описывает, что он может делать и какие поля возвращает. В протоколах вроде MCP главная ценность в том, что эти описания и слой авторизации над ними можно управлять централизованно.
Как определить журналирование и сроки хранения?
Журналирование в системах ИИ находится между двумя противоположными потребностями. С одной стороны, запись того, какой пользователь что спросил, какие документы использовались и какое действие выполнил агент, нужна и для отладки, и для подотчётности. С другой стороны, если полные тексты промптов хранятся бессрочно вместе с персональными данными, хранилище журналов становится самым чувствительным набором данных компании.
Сбалансированный подход выглядит так:
- Журнал аудита (кто, когда, какой документ, какое действие) хранится отдельно от журнала содержимого (полный текст промпта и ответа).
- Персональные данные в журнале содержимого маскируются, срок хранения короткий; по его истечении записи удаляются автоматически.
- Сроки хранения прописываются отдельно для векторной базы, журналов приложения, инструментов мониторинга и журналов поставщика модели и сверяются с политикой хранения и уничтожения персональных данных компании.
- Для запросов субъектов данных (например, об удалении) заранее проектируется, как найти и удалить данные одного человека из векторной базы и журналов. Эту функцию сложнее всего добавить задним числом.
Когда имеет смысл запускать модели с открытыми весами на своих серверах?
Самый ясный способ провести границу данных состоит в том, чтобы данные вообще не покидали инфраструктуру под контролем компании. Недавно выпущенные модели с открытыми весами достигли достаточного качества для многих корпоративных задач и могут работать на ваших серверах или в облачной среде под вашим контролем. Этот вариант особенно стоит рассмотреть, если:
- Документы содержат особые категории персональных данных, например сведения о здоровье.
- Отраслевое регулирование или договоры с клиентами требуют хранить данные в определённой стране.
- Объём использования высокий и предсказуемый, и собственная инфраструктура обходится дешевле API.
Цена тоже очевидна: эксплуатация, обновление, мониторинг и защита модели становятся вашей задачей, и часть возможностей самых сильных закрытых моделей может оказаться недоступна. Распространённый компромисс таков: шаги, работающие с чувствительными данными (векторизация, классификация, маскирование), выполняются на своей инфраструктуре, а генерация по маскированному содержимому передаётся внешней модели. Архитектура, не привязанная к конкретной модели, является условием того, чтобы это решение можно было изменить позже.
Как оценить риски до начала проекта?
Для обработки с высоким риском хорошей практикой считается письменная оценка воздействия до начала работ. Подход, похожий на оценку воздействия на защиту данных (DPIA) из GDPR, можно использовать и в рамках KVKK, чтобы сделать риски видимыми. Для ИИ-проекта такая оценка должна охватывать как минимум:
- Цель обработки и категории данных, действительно нужные для неё.
- Схему потоков данных со страной, поставщиком и сроком хранения на каждой остановке.
- Правовое основание и, при необходимости, обновлённое уведомление о конфиденциальности.
- Гарантию, используемую при трансграничной передаче.
- Модель контроля доступа и то, как она применяется в момент поиска.
- Права агентов и действия, требующие подтверждения человеком.
- Остаточные риски и того, кто их принял.
Этот документ ценен не только для соответствия требованиям, но и для уточнения объёма проекта. Вопрос о том, какие данные действительно нужны, часто делает проект одновременно безопаснее и дешевле.
Чек-лист ИИ, соответствующего KVKK
- Есть схема потоков данных, на каждой остановке указаны страна, поставщик и срок хранения.
- Объём документов, попадающих в систему, определён письменно.
- Персональные данные маскируются до векторизации, доля пропусков измеряется тестовым набором.
- DPA поставщика модели изучено; использование для обучения и срок хранения ясны.
- Для трансграничной передачи тип гарантии и порядок уведомления согласованы с юристом.
- Контроль доступа применяется в момент поиска по личности пользователя.
- Изменения прав в исходных системах синхронизируются с векторной базой.
- Агенты работают с минимальными правами от имени пользователя; рискованные действия требуют подтверждения человеком.
- Журнал аудита и журнал содержимого разделены; срок хранения содержимого короткий и автоматический.
- Путь удаления данных одного человека из всех слоёв спроектирован и проверен.
- При наличии данных особых категорий рассмотрен вариант модели на собственной инфраструктуре.
- Оценка рисков записана, остаточные риски подтверждены их владельцем.
Часто задаваемые вопросы
Нарушает ли KVKK отправка персональных данных в ChatGPT или похожий API? Сама по себе нет, но обычно это считается трансграничной передачей и требует выполнения одного из условий статьи 9 KVKK. Кроме того, то, как поставщик обрабатывает и хранит данные, должно быть закреплено договором. Уточните свою ситуацию у юриста.
Считаются ли векторы персональными данными? Векторы эмбеддингов представляют текст в числовом виде, и некоторые техники позволяют восстановить сведения об исходном тексте. Кроме того, векторные базы часто хранят и сам фрагмент. Поэтому правильно защищать векторное хранилище так же тщательно, как исходные документы.
Выводит ли анонимизация из-под действия KVKK? Данные, прошедшие действительно необратимую анонимизацию, могут утратить статус персональных. Псевдонимизация такого результата не даёт: данные остаются персональными. Нужно уметь показать, что именно было сделано, и измерить, необратим ли результат.
Решает ли модель с открытым исходным кодом все проблемы? Вопрос трансграничной передачи в основном снимается, но контроль доступа, журналирование, сроки хранения и права агентов остаются в силе. Где бы ни работала модель, границу данных определяет архитектура.
Если вы планируете RAG-ассистента или агентную систему, мы можем вместе составить схему потоков данных и модель прав. О нашем подходе рассказано на странице ИИ-решений, а вопросы для поставщика собраны в руководстве о выборе компании для интеграции ИИ. Чтобы обсудить проект, достаточно заполнить форму быстрого запроса.
