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

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

В US-DATA отмечают, что заказчики часто начинают разговор с метрик будущей модели: точности, полноты, скорости обработки, процента ошибок. Это логично. Но юридическая часть проекта при этом нередко уходит на второй план. А зря: ошибки в согласиях, целях обработки или условиях передачи данных могут создать для бизнеса не меньше проблем, чем технические недочёты в алгоритме.

Почему датасет — это не только «технический материал»

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

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

откуда получены данные;

на каком основании их можно использовать;

есть ли в них чувствительная информация;

кто будет иметь доступ к массиву;

как данные будут передаваться и храниться;

что произойдёт с ними после завершения проекта.

В российской практике ключевым остаётся закон №152-ФЗ «О персональных данных». При этом персональные данные — это не только ФИО, телефон или адрес электронной почты. Фото, голос, ID пользователя, номер автомобиля, поведенческий паттерн или комбинация косвенных признаков тоже могут позволить идентифицировать человека.

Что учитывать бизнесу в российской практике

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

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

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

какие операции с данными допустимы;

для какой цели они выполняются;

какие требования к безопасности применяются;

можно ли привлекать субподрядчиков;

как данные возвращаются или удаляются после завершения работ.

Отдельно стоит проверить вопрос инфраструктуры. При сборе персональных данных граждан РФ нужно учитывать требования к использованию баз данных на территории России. Если в проекте задействованы зарубежные сервисы, облака или иностранные исполнители, появляется ещё один блок — трансграничная передача и уведомление регулятора.

Обезличивание: сложнее, чем кажется

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

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

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

что нужно удалить или скрыть;

что можно оставить без ущерба для правовой безопасности;

какие признаки нужны модели для качества обучения;

какие данные лучше вынести в отдельный защищённый контур.

В US-DATA отмечают, что именно на этом этапе часто возникают практические вопросы. Например, если скрыть слишком много признаков, модель может потерять точность. Если оставить слишком много — возрастает риск идентификации. Поэтому решение должно приниматься не абстрактно, а с учётом задачи: что именно модель должна распознавать, какие признаки для неё критичны и где проходит граница между полезными данными и лишним риском.

Что фиксировать в договоре

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

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

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

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

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

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

Шестой блок — качество разметки. Для ИИ-проекта это не второстепенная деталь. Нужно заранее определить критерии качества, допустимый процент ошибок, порядок проверки, правила приёмки и механизм разбора спорных случаев.

В этом смысле разметка данных — не просто операционная задача. Это часть инфраструктуры ИИ-проекта, где одновременно важны методология, безопасность, контроль доступа и качество результата.

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

Мировая практика показывает общий тренд: данные для ИИ всё чаще становятся объектом отдельного контроля. В ЕС принят AI Act — первый комплексный регламент об искусственном интеллекте. Для высокорисковых ИИ-систем он связывает требования к разработке не только с самой моделью, но и с качеством обучающих, валидационных и тестовых данных.

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

В США регулирование устроено иначе: оно более гибкое и во многом риск-ориентированное. Один из ключевых ориентиров — NIST AI Risk Management Framework. Он предлагает управлять рисками на всём жизненном цикле ИИ-системы: от проектирования и сбора данных до внедрения, мониторинга и последующей оценки.

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

Почему это влияет на бизнес напрямую

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

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

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

В своём исследовании рынка Computer Vision и Data Annotation US-DATA отмечает, что спрос на компьютерное зрение растёт вместе с требованиями к датасетам. Чем шире бизнес использует ИИ, тем меньше ему подходят случайно собранные массивы. Нужны данные, с которыми можно работать предсказуемо: понятно, законно и с контролируемым качеством.

Итог

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

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

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