Кратко

  • RFC 9969 — информационный отчёт IAB о workshop, а не стандарт управления ИИ и не консенсусное правило о позициях участников.
  • Предпочтение, способ привязки, получение, хранение, решение о модели, доказательство соблюдения и решение о возмещении должны остаться раздельными записями.

Публикация предпочтения легко создаёт впечатление, будто контроль уже состоялся. RFC 9969 этого впечатления не подтверждает. Документ фиксирует обсуждения workshop AI-CONTROL, посвящённого способам выразить предпочтения владельцев контента относительно применения ИИ. Одновременно он ограничивает собственный статус: изложенные позиции не обязательно являются позициями IAB, материал следует презентациям и заметкам без проверки или интерпретации и не пытается сформировать консенсус. Это карта вопросов, а не готовое правило для чужих систем.

Наиболее существенный разрыв лежит между временем сбора и временем последующего использования. Предпочтение может быть видно crawler при обращении к ресурсу. Затем данные могут идти в поисковый продукт, быть получены третьей стороной, перенесены в другую копию или использоваться моделью при inference. RFC 9969 отмечает, что универсальная foundation-модель обычно не способна во время inference выделить часть входных данных конкретного источника и избирательно применить его предпочтение. Поэтому наблюдение сигнала при crawl доказывает выражение в конкретный момент, но не решение о последующем обучении, исключении или использовании.

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

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

RFC 9309, Robots Exclusion Protocol, следует читать в том же узком объёме. Наличие robots.txt подтверждает доступность декларативного ресурса по адресу. Оно не подтверждает личность crawler’а, получение инструкции, цепочку хранения, исключение из набора данных, применение в модели или результат генерации. Превращать это локальное наблюдение в вывод о соблюдении означает заменить видимый факт рядом ненаблюдаемых решений.

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