Права на данные в проектах LLM: что согласовать до старта

Какая проблема возникает в LLM-проектах с данными

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

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

Потери здесь вполне приземленные: пилот могут приостановить или запретить к эксплуатации, правообладатели или регулятор предъявят претензии, чувствительная информация утечет через логи или промпты, а неверные ответы будут воспринимать как официальные. Почти всегда добавляется и чисто практический ущерб: затраты на переделку (чистка данных, переразметка, повторная настройка, пересборка индекса).

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

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

Какие данные и контент участвуют в проекте

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

Обычно выделяют четыре группы.

Во-первых, данные для обучения или дообучения: наборы текстов, таблицы, переписки, разметка, примеры «правильных» ответов.

Во-вторых, данные для поиска (RAG): базы знаний, инструкции, регламенты, тикеты и статьи, которые модель читает в момент запроса.

В-третьих, данные в промптах: то, что пользователь вставляет вручную (фрагменты договоров, письма, скриншоты текста), а также системные подсказки и шаблоны.

В-четвертых, выходы модели: ответы, сводки, проекты писем, отчеты, рекомендации, фрагменты кода. Это новый контент, но он может содержать цитаты или пересказ исходников.

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

И еще один слой - логи и телеметрия. Логи нужны для разбора инцидентов, улучшения качества и доказательства «кто что сделал». Телеметрия помогает видеть загрузку, ошибки, задержки. Здесь важно заранее решить, что именно фиксируется (запрос целиком или только технические признаки), где хранится и кто имеет доступ, как долго хранить и как удалять по запросу.

Если эту карту данных составить до старта, дальше проще обсуждать разрешения, сроки хранения и ответственность.

Роли и ответственность: кто за что отвечает

В LLM-проектах споры обычно начинаются не с модели, а с вопроса: кто имел право дать ей доступ к документам и на каких условиях. Чтобы это не стало сюрпризом после запуска, роли стоит закрепить письменно еще до первой загрузки файлов.

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

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

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

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

Источники документов: что можно подключать и на каких условиях

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

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

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

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

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

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

Разрешения и лицензии на использование контента

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

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

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

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

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

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

Персональные и конфиденциальные данные: границы и меры

В проектах с LLM почти всегда возникает вопрос: что именно модель может увидеть, а что должно быть скрыто при любых условиях. Это важно и для соблюдения закона и внутренних правил, и для снижения риска утечек через ответы, логи или историю чатов.

Сначала зафиксируйте категории данных, которые в вашей организации считаются персональными и чувствительными. Обычно это ФИО, ИИН, телефоны, адреса, e-mail, данные сотрудников и клиентов, медицинские сведения, зарплаты. К конфиденциальным коммерческим данным часто относят цены по контрактам, условия тендеров, внутренние финансовые отчеты, схемы безопасности, пароли и ключи.

Дальше нужен принцип минимизации: модели не должно быть видно то, что не требуется для ответа. Сразу определите, какие данные запрещены к передаче в LLM всегда, даже если пользователь намеренно пытается их вставить. Обычно в запретный список попадают учетные данные (пароли, токены, ключи API), полные идентификаторы (ИИН, номера документов, банковские реквизиты), содержимое писем и переписок без явного разрешения, данные о здоровье и дисциплинарные записи, закрытые условия договоров и закупок без согласованного режима доступа.

Там, где без данных не обойтись, используйте обезличивание и маскирование. Заранее решите два вопроса: где именно это делается (до отправки запроса в модель, при индексации документов, при выдаче ответа) и кто подтверждает качество маскирования. На практике это должен утверждать владелец данных вместе с ИБ или комплаенсом, потому что «частично замазали» часто означает «все равно можно восстановить из контекста».

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

Правила для пользователей лучше писать простыми запретами с примерами. Например: «Нельзя вставлять в запрос ИИН, номера паспортов, реквизиты, пароли». И рядом: «Можно описать проблему без идентификаторов или использовать внутренний номер заявки». Это снижает риск случайной передачи лишнего и помогает быстрее объяснить, почему модель иногда отказывается отвечать.

Логи, хранение и доступ: что фиксируем и как долго

Логи в LLM-проекте часто становятся главным источником споров: что именно записывали, где это лежит, кто видел, можно ли удалить. Если заранее не договориться, легко нарушить требования безопасности или, наоборот, лишиться данных, которые нужны для расследования инцидентов и улучшения качества.

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

Дальше зафиксируйте сроки хранения: минимум и максимум. Минимум нужен, чтобы расследовать инцидент и подтвердить, что произошло. Максимум диктуют внутренние правила, договоры и требования регуляторов. Частая практика - короткий срок для содержательных логов (где есть текст) и более длинный для обезличенной статистики.

Где храним

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

Кто видит и как удаляем

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

Также пропишите процесс удаления: кто инициирует (пользователь, ИБ, юристы), кто подтверждает, какие сроки, и как доказывается факт удаления (акт, запись в системе, номер заявки).

Как согласовать вопросы заранее: пошаговый порядок

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

Порядок согласования

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

Дальше удобно идти по шагам:

• Описать сценарии и список пользователей: роли, доступы, запреты (например, нельзя вводить персональные данные в свободное поле).
• Составить реестр данных и источников: базы знаний, файлы, почта, тикеты. Для каждого указать владельца и контакт для согласования.
• Проверить права и лицензии на контент: что можно индексировать для поиска, что можно цитировать, что можно использовать для обучения, а что нельзя сохранять.
• Согласовать политику логирования и хранения: что пишем в логи, сроки хранения, кто имеет доступ, как удаляем по запросу.
• Определить ответственность за ошибки и порядок эскалации: кто блокирует источник, кто правит промпты и правила, кто отвечает пользователям.

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

Небольшой пример

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

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

Пример сценария: помощник по внутренней базе знаний

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

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

Как это выглядит на практике

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

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

Что обычно помогает

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

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

Такой набор пунктов часто экономит недели споров, когда пилот уже готов, а юридически и по безопасности он «не взлетает».

Типичные ошибки и ловушки

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

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

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

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

Сигналы, что проект идет по опасному пути:

• «Договорились устно» вместо формулировок в документах.
• Нет сроков хранения логов и ответственного за доступ.
• Один и тот же контент идет и в тест, и в прод без разделения.
• Не определено, кто утверждает подключение нового источника.
• Нет правил, что делать при ошибочном или вредном ответе.

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

Короткий чек-лист перед запуском

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

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

Перед запуском согласуйте минимальный набор организационных правил:

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

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

Следующие шаги: как перейти от обсуждения к внедрению

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

Практичный набор шагов выглядит так:

• Собрать рабочую группу: бизнес, ИБ, юристы, ИТ и владельцы данных.
• Зафиксировать цель пилота и границы: какие задачи решаем, какие нет.
• Утвердить 1-2 источника документов для старта и проверить их права и лицензии.
• Настроить логи и доступ так, чтобы не собирать лишнее, и определить сроки хранения.
• Запустить пилот на ограниченной аудитории и договориться, кто принимает результаты.

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

Если проект нужно развернуть в строгом контуре (государственном или финансовом), инфраструктуру лучше планировать заранее под требования хранения и контроля доступа. В таких случаях удобно привлекать системного интегратора, который может собрать решение «под правила» - например, GSE.kz (gse.kz) работает как производитель и интегратор, поставляет серверы и оказывает поддержку 24/7, что бывает важно для соблюдения режима доступа и эксплуатации в реальных процессах.