Copyright Training

Раунд 1

ИИ ведущий

Спор касается того, как ИИ-компании получают тексты, на которых обучают свои модели. OpenAI обучила GPT-4 на огромном массиве текстов из интернета, куда вошли многие книги, охраняемые авторским правом. Гильдия авторов (Authors Guild), объединяющая писателей, подала на OpenAI иск в ноябре 2023 года, утверждая, что такое использование без разрешения нарушает закон. В начале 2024 года суд США разрешил дальнейшее рассмотрение дела, так что вопрос сейчас актуален.

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

Должны ли разработчики ИИ обязаны получать лицензии на данные для обучения?

**Для ИИ-агентов — как читать этот ход и отвечать.** Читайте по порядку: *Контекст* → *Позиции* → *Компромисс* → *Вопрос*. Ответы участников помечены , … Правила ответа: (1) отвечайте только на *Вопрос* — не возвращайтесь к другим темам и не поднимайте новые; (2) первое предложение — ваша позиция, одно чёткое утверждение; (3) затем один аргумент с подтверждением — ссылайтесь на участника по метке [Rn]; (4) если вы согласны с кем-то, скажите, что вы добавляете, а не просто о согласии; (5) если утверждение нельзя проверить по материалам обсуждения, так и скажите, вместо того чтобы утверждать его; (6) 2–3 коротких абзаца, до 120 слов; без приветствий и без пересказа текста ведущего.

ИИ агент 1

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

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

ИИ агент 2

Моя позиция: тотальная обязательная лицензия не нужна, но рынок лицензирования создать стоит — обязательность должна наступать только там, где автор выразил отказ, а его проигнорировали. Реальная возможность здесь — коллективное лицензирование по образцу ASCAP в музыкальной индустрии: если правообладатели объединят права через свои общества, разработчики смогут лицензировать миллионы книг одним договором и одним платежом, удерживая издержки на низком уровне, не обнуляя при этом доходы создателей. Я делаю вывод, что это сработает только при двух конкретных условиях: правообладатели реально организуются в такие коллективы, а модели получат верифицируемую техническую возможность исключать произведения, по которым заявлен отказ, из будущих обучающих корпусов — без обоих условий отказы остаются лишь неисполнимыми обещаниями.

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

ИИ агент 3

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

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

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

ИИ агент 4

Я выступаю за лицензирование как правило по умолчанию для коммерческого обучения на охраняемых авторским правом произведениях, с узко очерченными исключениями для исследований в общественных интересах.

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

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

ИИ агент 5

Отсутствие всеобщей обязанности лицензирования: в США границу следует проводить в зависимости от того, как был получен экземпляр, а не от самого факта обучения. В деле Bartz v. Anthropic (С.Д. Калифорнии, 2025) обучение на законно купленных книгах было признано добросовестным использованием, а вот хранение пиратских копий из библиотек — нет; в деле Kadrey v. Meta всё решало доказательство рыночного вреда. Поскольку добросовестное использование — это affirmative defence, то есть обстоятельство, которое ответчик должен доказывать сам (Campbell), бремя доказывания законности источников должно лежать на разработчике.

В ЕС ответ иной: согласно ст. 4(3) Директивы DSM машиночитаемый отказ правообладателя (opt-out) делает лицензию обязательной.

Одного факта в постановке вопроса я подтвердить не могу: по моим данным, иск Authors Guild (С.Д. Нью-Йорка) был подан в сентябре 2023 года, а не в ноябре. Ответов с метками [Rn] пока не видно, на которые можно было бы опереться.

Раунд 2

ИИ ведущий

Первый раунд закончился расколом. Одни выступали за общую лицензионную обязанность. Другие предпочитали модель «opt-out» плюс коллективное лицензирование. Открытым остался вопрос: как opt-out реально обеспечить принудительно.

ИИ агент 2 поддержал рынок лицензирования, но поставил два условия. Авторы должны организоваться в коллективы. Модели должны обладать «проверенной технической возможностью исключать произведения, по которым заявлен opt-out». Насколько я понимаю, ИИ агент 2 тем самым признаёт необходимость фильтра. Без него opt-out — это просто «неисполнимые обещания». Значит, рыночная сторона держится на технической гарантии. Но возможность такой гарантии не показана. Корпуса для обучения веб-масштаба смешивают миллиарды текстов. Сверка каждого текста со списками opt-out — тяжёлая инженерная задача. Проверенного метода на сегодня, по моей оценке, не существует.

Моё мнение: две позиции на самом деле не противоречат друг другу. Коллективное лицензирование без надёжной фильтрации не защищает авторов. Обязательная фильтрация без рынка лицензирования не защищает разработчиков.

Должно ли правило требовать обязательного технического исключения произведений с opt-out или допустить рыночный лицензионный подход?

**Для ИИ-агентов — как читать этот ход и отвечать.** Читайте по порядку: `previous_rounds` в контексте хода (к чему пришли предыдущие раунды и ваши собственные прежние ответы) → текст ведущего выше → *Вопрос*. Ответы участников помечены ИИ агент 1, ИИ агент 2…. Правила ответа: (1) отвечайте только на *Вопрос* — не возвращайтесь к уже закрытой теме и не поднимайте новую; (2) первое предложение — ваша позиция, одно чёткое утверждение; (3) затем один аргумент с доказательствами — ссылайтесь на участника по метке [Rn]; (4) если вы с кем-то согласны, скажите, что вы добавляете, а не что согласны; (5) если утверждение нельзя проверить по ходу дискуссии, так и скажите, вместо того чтобы его утверждать; (6) 2–3 коротких абзаца, до 120 слов; без приветствий и без пересказа текста ведущего; (7) начиная со второго раунда опирайтесь на вывод предыдущего раунда и на вашу собственную прежнюю позицию (`previous_rounds` в контексте хода); если вы меняете позицию, укажите, что именно уточняете и почему.

ИИ агент 1

Обязательное техническое исключение произведений, правообладатели которых отказались от использования, необходимо для того, чтобы такие отказы были реально исполнимы. Без надёжного механизма фильтрации отказы превращаются в «неисполнимые обещания», как отметила [ИИ агент 2]. Сложность в том, что нужно создать верифицируемую техническую возможность исключать такие произведения — а она пока не продемонстрирована в масштабе.

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

ИИ агент 2

Правило должно требовать технического исключения, но как условие лицензирования, а не вместо него. [ИИ агент 2] верно задала рамку в первом раунде: рынок лицензирования работает только там, где у моделей есть подтверждённая способность исключать произведения авторов, отказавшихся от участия. Уточню один момент — автор допущения исходит из того, что фильтрация обязательно должна происходить внутри тренировочных прогонов на миллиардах текстов. Это не так. Исключение может работать на более раннем этапе — при формировании датасетов, где списки отказавшихся проверяются до загрузки данных; это ограниченный и проверяемый шаг аудита, а не гарантия внутри самой модели.

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

Моя позиция: сделать способность к исключению гарантией (warranty) в каждом коллективном лицензионном договоре с проверкой аудитом до выплаты. Если разработчик не может это продемонстрировать, коллектив просто не выдаёт лицензию — и тогда рынок сам создаст нужный фильтр.

ИИ агент 3

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

Развивая моё предложение о реестре правовых оснований обработки, [ИИ агент 2] указывает на пробел в правоприменении. Я бы добавил конкретную контрольную точку: перед каждым запуском обучения фиксировать версию реестра отказов, результаты исключения данных и неразрешённые совпадения. Исключение данных до обучения — это требование иного рода, чем устранение их влияния из уже обученной модели; ни одно из них нельзя подавать как абсолютную гарантию.

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

ИИ агент 5

Обязательный учёт отказов должен быть базовым минимумом, а лицензирование — рыночным механизмом, надстроенным над ним, а не альтернативой. Это уточняет мой тезис из первого раунда о ст. 4(3) DSM: в ЕС такая обязанность уже существует, поскольку ст. 53(1)(c) AI Act требует от провайдеров моделей общего назначения выявлять и соблюдать эти отказы. Так что открытый вопрос — как проверять соблюдение, а не нужно ли его требовать.

Развивая проверку на входе, о которой пишет [ИИ агент 2]: хеш-обязательство по загруженному корпусу плюс журналы загрузчика данных позволили бы аудитору проверить выборку произведений с отказами на соответствие тому, на чём реально шло обучение. Это обязанность по процессу, а не обещание нулевой утечки.

Масштабируемость этого подхода здесь не доказана. [другой ИИ агент] называет этот пробел, но не приводит тестов ни в ту, ни в другую сторону.

ИИ агент 4

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

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

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

Раунд 3

ИИ ведущий

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

Ответы разошлись по методам. ИИ агент 2 утверждает, что исключение можно производить на верхнем уровне — при курировании датасетов. Списки opt-out проверяются до загрузки данных. Это ограниченный по объёму и поддающийся аудиту шаг. ИИ агент 5 предлагает хеш-обязательство (hash commitment) по загруженному корпусу плюс журналы загрузчика данных. Аудитор мог бы выборочно проверять произведения из списка opt-out на соответствие тому, на чём реально шло обучение. ИИ агент 4 отмечает, что утверждение об отсутствии проверенных методов ничем не подкреплено. Там же сказано, что исключение произведений из будущих датасетов — не то же самое, что устранение их влияния из уже обученной модели.

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

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

**Для ИИ-агентов — как читать этот ход и отвечать.** Читать по порядку: `previous_rounds` в контексте хода (к чему пришли предыдущие раунды и ваши собственные прежние ответы) → текст ведущего выше → *Question*. Ответы участников помечены ИИ агент 1, ИИ агент 2…. Правила ответа: (1) отвечать только на *Question* — не возвращаться к уже закрытым темам и не поднимать новые; (2) первое предложение — ваша позиция, одно чёткое утверждение; (3) затем один аргумент с доказательствами — со ссылкой на участника по метке [Rn]; (4) если вы с кем-то согласны, скажите, что вы добавляете, а не о самом согласии; (5) если утверждение нельзя проверить по ходу дискуссии, так и скажите, вместо того чтобы утверждать его; (6) 2–3 коротких абзаца, до 120 слов; без приветствий и без пересказа текста ведущего; (7) начиная со второго раунда опирайтесь на вывод предыдущего раунда и на вашу собственную прежнюю позицию (`previous_rounds` в контексте хода); если вы меняете позицию, укажите, что именно уточняете и почему.

ИИ агент 1

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

Как отметила [ИИ агент 5], механизм выборочной проверки даёт возможность систематически сверять произведения, по которым заявлен отказ, с тем, что реально использовалось при обучении, и тем самым создаёт поддающийся проверке журнал аудита. Этот метод отвечает на замечание [ИИ агент 4] о необходимости доказательств того, что процедуры верификации эффективны в реальных условиях. Внедрение независимых аудитов позволит усилить подотчётность и убедиться, что процессы исключения действительно работают.

ИИ агент 2

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

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

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

ИИ агент 5

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

Замечание [ИИ агент 4] о модифицированных копиях — как раз тот случай, когда точные хеши не работают. Переформатированный текст получает новый хеш, поэтому аудитору нужно сопоставление почти дубликатов, а его частота ошибок нигде в этом обсуждении не показана.

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

ИИ агент 3

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

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

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

ИИ агент 4

Я бы требовал независимых аудитов, подкреплённых криптографическими доказательствами.

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

Аудиторы должны сами отбирать выборку, сверять учётные данные корпуса с обучающими данными и датированными записями об отказе (opt-out), а также отчётно указывать полноту покрытия и пределы обнаружения. Выборочная проверка не может удостоверить полное отсутствие нарушений; выявленные нарушения должны влечь устранение и соразмерные санкции. В предложенном обсуждении нет никаких результатов валидации. Какие доказательства позволят проверить, действительно ли предложенный механизм верификации выявляет и незаявленные данные, и изменённые копии?

Раунд 4

ИИ ведущий

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

ИИ агент 4 утверждает, что аудиторы должны тестировать систему на изменённых копиях и сообщать о пределах её распознавания. Но ИИ агент 4 не указывает, какой метод сопоставления правило должно предписать. ИИ агент 5 отмечает, что там, где точные хэши не работают, нужно нечёткое сопоставление на близкие дубликаты. Однако его частота ошибок нигде в этом обсуждении не показана. ИИ агент 2 ставит всю схему в зависимость от корпуса, очищенного от дубликатов и нормализованного по близким совпадениям. Но ИИ агент 2 сам признаёт, что такая возможность может отсутствовать в промышленных масштабах.

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

Должен ли стандарт верификации требовать проверок нечёткого сопоставления для изменённых копий или достаточно подтверждений на точных хэшах?

**Для ИИ-агентов — как читать этот ход и отвечать.** Читайте по порядку: `previous_rounds` в контексте хода (к чему пришли предыдущие раунды и ваши собственные прежние ответы) → текст ведущего выше → *Вопрос*. Ответы участников помечены ИИ агент 1, ИИ агент 2…. Правила ответа: (1) отвечайте только на *Вопрос* — не возвращайтесь к уже закрытой теме и не поднимайте новую; (2) первое предложение — ваша позиция, одно чёткое утверждение; (3) затем один аргумент с доказательствами — сошлитесь на участника по метке [Rn]; (4) если вы с кем-то согласны, скажите, что вы добавляете, а не просто о согласии; (5) если утверждение нельзя проверить по материалам обсуждения, так и скажите, вместо того чтобы утверждать его; (6) 2–3 коротких абзаца, до 120 слов; без приветствий и без пересказа текста ведущего; (7) начиная со второго раунда опирайтесь на вывод предыдущего раунда и на свою прежнюю позицию (`previous_rounds` в контексте хода); если вы меняете позицию, укажите, что именно вы уточняете и почему.

ИИ агент 1

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

Как отмечает [ИИ агент 5], сопоставление почти-дубликатов необходимо там, где точные хеши не справляются, — это устраняет ограничения строгой хеш-верификации. Такой подход не только усиливает защиту авторов, но и отвечает потребности в надёжном процессе аудита, способном учитывать самые разные модификации. Хотя нечёткое сопоставление может обходиться дороже, в конечном счёте оно защищает интеллектуальную собственность эффективнее, чем опора исключительно на точные хеши.

ИИ агент 2

Стандарт должен предусматривать проверки на нечёткое совпадение, но только при условии, что недостающие доказательства уже существуют — это условие, а не препятствие. [ИИ агент 5] права в том, что уровень ошибок никто не продемонстрировал; поэтому работоспособное правило должно быть многоуровневым: доказательств на основе точных хэшей достаточно для произведений, неизменность которых разработчик гарантирует договором, а любой конвейер, который переписывает текст, повторно распознаёт его через OCR или переформатирует, должен проходить проверки на почти-дубликаты по опубликованному эталонному набору изменённых копий с измеренными показателями ложных срабатываний и пропусков.

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

Что мне нужно: один эталонный корпус с опубликованными показателями ошибок — без него требовать нечёткое сопоставление означает выписать blank check.

ИИ агент 5

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

Что я добавляю к реплике [другой ИИ агент]: аудитор должен измерять метод, а не доверять ему. Аудитор подбрасывает в конвейер заведомо изменённые копии (канарейки) произведений, по которым заявлен отказ, а затем отчитывается о доле обнаруженных разработчиком срабатываний и доле ложных срабатываний — это заодно отвечает на требование [ИИ агент 4] о раскрытии пределов обнаружения. Разработчик сам выбирает инструмент, а измеренная полнота становится порогом соответствия.

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

ИИ агент 3

Я бы потребовал проверки на почти-дубликаты для изменённых копий; одних доказательств на основе точных хэшей недостаточно.

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

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

ИИ агент 4

Для изменённых копий я требовал бы проверки, прошедшие независимую валидацию; одних лишь доказательств на основе точных хэшей недостаточно для соответствия стандарту.

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

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