Кто первым должен оценивать коммерческое использование кода от ИИ?

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

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

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

Первую проверку проводит технический руководитель, решение принимает юрист

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

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

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

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

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

Разделяйте авторство, нарушение прав и договорные права

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

Охраноспособность по авторскому праву зависит от того, достаточно ли в результате человеческого авторского вклада. В отчете U.S. Copyright Office о генеративном ИИ за 2025 год сказано, что помощь ИИ не лишает охраны более крупную работу, созданную человеком, но одни запросы не дают достаточного контроля над выразительными элементами. Созданные человеком отбор, компоновка и изменения могут охраняться. Для компании-разработчика это означает, что существенная проектная работа и переработка со стороны программиста могут создать права на итоговую программу, даже если необработанные сгенерированные фрагменты сами по себе не получают охраны. Юрист должен оценивать это по праву, применимому к компании и конкретной сделке.

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

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

Рядом стоят патентные вопросы и коммерческая тайна. Код может реализовать запатентованный способ, не копируя исходный текст. Запрос может раскрыть секрет заказчика, даже если полученный код ничем не выделяется. Товарные знаки реже встречаются в программной логике, но могут появиться в сгенерированных названиях, тестовых данных или пользовательском интерфейсе. Юристу нужно определить объем проверки, чтобы список вопросов по авторскому праву не скрыл другие права.

Профиль генеративного ИИ NIST относит к рискам интеллектуальной собственности обучающие данные и запомненный моделью результат, а AI Risk Management Framework требует документировать подходы к сторонним данным, программному обеспечению и риску нарушения прав. Я согласен с упором на документы, но общего реестра рисков недостаточно для запроса на слияние. Компании нужны доказательства, приложенные к конкретной правке, и человек с полномочиями остановить выпуск.

Сбор лицензионных фактов начинается у инженеров

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

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

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

SPDX, признанный стандартом ISO/IEC 5962:2021, задает стандартный способ передавать данные о составе ПО, включая лицензии, авторские права, связи и происхождение. SPDX 3 умеет описывать файлы и фрагменты, поэтому подходит для фиксации известного совпадения с источником. В собственной документации SPDX также сказано, что стандарт не дает правового толкования и не определяет патенты. Используйте его для сохранения фактов, а не для искусственного создания правового вывода.

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

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

Происхождение кода фиксируют в записи, а не в обещании поставщика

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

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

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

В анализе U.S. Copyright Office человеческий вклад влияет на авторство, поэтому запись должна охватывать больше, чем первоначальный запрос. Проектные заметки, тесты, написанные до генерации, комментарии при проверке, рефакторинг и история коммитов могут показать человеческий выбор. Они также помогают тем, кто будет поддерживать код. Не превращайте процесс в спектакль, заставляя разработчика писать сочинение о каждой подсказке. Сохраняйте артефакты, которые и так создает рабочий процесс, и добавляйте короткое подтверждение недостающих фактов.

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

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

Договоры с поставщиками распределяют риск только в своих границах

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

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

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

Не сравнивайте поставщиков по одному громкому слову «возмещение». Сравнивайте вид покрываемого требования, действия заказчика для сохранения покрытия, исключения, предел ответственности и право поставщика управлять защитой и урегулированием. Обещание оплатить защиту в пределах уплаченных комиссий может не покрыть коммерческие последствия отзыва релиза. Широкая гарантия может исключать именно тот рабочий процесс, которым пользуются разработчики. Юрист объяснит условие, а CTO должен оценить срок замены, риск для релиза и выполнимые меры контроля.

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

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

Правила репозитория превращают правовое решение в ежедневный контроль

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

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

Краткую политику можно выразить в виде данных и проверять в CI:

ai_code_policy:
  approved_accounts: [company-enterprise]
  repositories:
    private-internal: allow
    customer-deliverable: review
    public-package: review
  prohibited_inputs:
    - credentials
    - customer-confidential-code
    - unlicensed-third-party-source
  escalation:
    - detected-source-match
    - license-or-copyright-notice
    - personal-account-use
    - generated-cryptography
  required_evidence:
    - tool-and-account
    - human-reviewer
    - scan-result
    - disposition

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

Для исключений тоже нужен маршрут. Юрист утверждает критерии, а технический ответственный фиксирует точные файлы, релиз, дополнительную проверку и срок действия. Бессрочные исключения превращаются в скрытые правила. Ограничение по времени заставляет компанию решить, заменить ли рискованный фрагмент или изменить основное правило.

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

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

Дайте юристу пакет для решения, а не название инструмента

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

Используйте такой порядок из пяти пунктов:

1. Опишите результат: репозиторий, файл, строки, коммит, инструмент, тариф аккаунта, дату и автора-человека.
2. Укажите использование: внутренний сервис, размещенный продукт, передача исходного кода, распространение бинарного файла или публичная публикация.
3. Сохраните историю: существенный запрос или ссылку с ограниченным доступом, результат, человеческие изменения, итог сканирования и возможный исходный источник.
4. Приложите условия: подписанный договор или версию условий, обязательные настройки и обязательства перед заказчиками или участниками проекта.
5. Сформулируйте вопрос для решения: выпустить, заменить, добавить уведомление, раскрыть исходный код, получить разрешение или запросить у руководства принятие остаточного риска.

Последняя строка особенно важна. Формулировка «Пожалуйста, проверьте» перекладывает постановку задачи на юриста и часто вызывает новый круг вопросов. Формулировка «Можно ли передать эти 86 строк в исходном коде SDK по нашей лицензии заказчика, если найдено возможное совпадение с Apache-2.0, а уведомление из него удалено?» показывает решение, которое блокирует выпуск.

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

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

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

Проследите сбой от подсказки до поставки заказчику

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

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

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

Один контроль не исправил бы всю цепочку. Блокировка личных аккаунтов применила бы проверенный договор. Категория репозитория запустила бы проверку передачи исходного кода. Подтверждение в запросе на слияние сохранило бы инструмент и аккаунт. Сканер сходства мог бы предложить исходный источник. Запись о происхождении отделила бы результат модели от изменений человека. Юристу все равно пришлось бы толковать возможную лицензию и договор, но компания принимала бы решение по доказательствам, а не по воспоминаниям.

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

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

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

Рабочая модель должна поспевать за репозиторием

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

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

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

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

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

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