Чек-лист соответствия AI Act начинается с вашей роли

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

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

Этот чек-лист учитывает Регламент (EU) 2024/1689 с изменениями из Регламента (EU) 2026/1744, который вступил в силу 27 июля 2026 года. Это руководство для руководителей и инженерных команд, а не замена юридической консультации при спорной классификации или запуске, который может серьезно затронуть основные права людей.

Учитывайте способы применения, а не названия поставщиков

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

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

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

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

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

Определите, распространяется ли Акт на систему

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

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

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

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

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

Назначьте роль каждого участника для каждой системы

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

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

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

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

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

Для каждой строки проведите пять проверок:

1. Кто определяет целевое назначение и выпускает продукт под своим именем или товарным знаком?
2. Кто профессионально эксплуатирует систему и под чьим управлением?
3. Кто первым выводит на рынок EU систему поставщика из-за пределов EU?
4. Кто передает ее дальше, не принимая на себя другую роль?
5. Кто-нибудь сменил маркировку, существенно изменил систему или поменял ее назначение?

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

Классифицируйте применение до оценки риска

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

Сначала проверьте статью 5. К запрещенным практикам относятся определенные манипулятивные или вводящие в заблуждение методы, которые причиняют существенный вред, эксплуатация уязвимости людей, социальная оценка, некоторые виды прогнозирования преступлений, нецелевой сбор изображений лиц, отдельные способы распознавания эмоций на работе и в учебных заведениях, биометрическая категоризация по чувствительным признакам и большинство случаев удаленной биометрической идентификации в реальном времени для правоохранительных органов в общественных местах. У каждого запрета есть условия и исключения. Сопоставляйте факты с текстом закона, а не с коротким бытовым названием. Регламент (EU) 2026/1744 добавил запреты для систем, предназначенных для создания материалов о сексуальном насилии над детьми или откровенного и интимного контента сексуального характера без согласия, и эти дополнения применяются с 2 декабря 2026 года.

Затем отделите AI-модель общего назначения от построенной на ней AI-системы. Модель представляет технический компонент, который может выполнять широкий набор задач; приложение для конечного пользователя будет системой. Поставщики моделей общего назначения обязаны на уровне модели готовить документацию и информацию для следующих участников, соблюдать политику в области авторского права и публиковать сводку о содержании обучающих материалов по статье 53. Для моделей с системным риском действуют дополнительные требования к оценке, системным рискам, инцидентам и кибербезопасности. Компания, которая обращается к внешней модели через API, обычно не становится поставщиком модели, но может быть поставщиком своего приложения. Дополнительное обучение модели само по себе не дает окончательного ответа. В рекомендациях Комиссии по GPAI сказано, что обязанности поставщика измененной модели возникают у автора только существенных модификаций, а юридическая оценка зависит от характера изменений.

При классификации высокого риска проверьте оба пути. Статья 6(1) охватывает AI-систему, которая служит компонентом безопасности продукта либо сама считается продуктом по законодательству из Приложения I, если продукт требует оценки соответствия третьей стороной. Статья 6(2) и Приложение III охватывают перечисленные способы применения в таких областях, как биометрия, критическая инфраструктура, образование, трудовые отношения, доступ к основным услугам, правоохранительная деятельность, миграция и правосудие. Целевое назначение и роль системы в решении важнее отдела, который ее купил.

На применение из Приложения III может распространяться исключение из категории высокого риска по статье 6(3), если система не создает значительного риска вреда здоровью, безопасности или основным правам и существенно не влияет на решение. К исключениям могут относиться отдельные узкие процедурные и подготовительные задачи, поиск закономерностей и проверка. Профилирование физических лиц сохраняет высокий риск системы из Приложения III. Если вы ссылаетесь на исключение, статья 6(4) требует документированной оценки до вывода на рынок или ввода в эксплуатацию, а поставщик регистрирует систему, когда действует соответствующая обязанность. Считайте эту записку обязательным результатом классификации, а не комментарием в задаче.

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

Стройте пакет доказательств вокруг роли

Документ должен подтверждать утверждение, иметь владельца и оставаться привязанным к выпущенной версии. Папка с PDF-файлами поставщика не образует систему соответствия. Создайте реестр доказательств, который связывает каждое требование с артефактом, согласующим лицом, датой, версией продукта и условием повторной проверки.

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

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

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

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

Реестр доказательств можно хранить в репозитории в формате, который удобно проверять:

system_id: hr-screen-014
version: 3.2.1
intended_purpose: rank applicants for recruiter review
roles:
  company_a: provider
  customer: deployer
classification:
  route: Annex III employment
  result: high-risk
controls:
  human_oversight: docs/oversight-v3.md
  logging: specs/event-log-3.2.yaml
  instructions: releases/3.2/instructions.pdf
review_triggers:
  - intended purpose changes
  - model or threshold changes
  - new affected population
owner: product-compliance
approved_release: 2026-08-01

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

Размещайте информацию в самом продукте

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

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

Поставщики систем, создающих синтетические аудио, изображения, видео или текст, должны проектировать результаты так, чтобы они имели машиночитаемую маркировку и могли распознаваться как искусственные или измененные, с учетом технической осуществимости и исключений Акта. Это контроль со стороны поставщика, который отличается от видимого уведомления читателю. Регламент (EU) 2026/1744 дает поставщикам таких систем, уже выпущенных на рынок до 2 августа 2026 года, срок до 2 декабря 2026 года для соблюдения статьи 50(2). Новые продукты не получают этот конкретный переходный период.

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

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

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

В списке сроков должно учитываться действующее право. Регламент (EU) 2024/1689 вступил в силу 1 августа 2024 года и применяется поэтапно. Регламент (EU) 2026/1744 изменил несколько этапов в июле 2026 года, поэтому во многих обзорах 2024 и 2025 годов теперь указаны неверные сроки для систем высокого риска.

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

• 2 февраля 2025 года: начали применяться главы I и II, включая определения, меры AI-грамотности и первоначальные запрещенные практики.
• 2 августа 2025 года: начали применяться положения об управлении и обязанности поставщиков AI-моделей общего назначения; поставщики моделей, выпущенных на рынок после этой даты, вошли в новый режим.
• 2 августа 2026 года: общая дата применения Акта ввела в действие большинство остальных положений, включая требования статьи 50 к прозрачности; полномочия Комиссии по контролю поставщиков моделей общего назначения тоже начали действовать.
• 2 декабря 2026 года: начинают применяться новые положения о запрещенных практиках из Регламента (EU) 2026/1744, а для выпущенных до 2 августа 2026 года генеративных систем наступает срок маркировки по статье 50(2).
• 2 декабря 2027 года и 2 августа 2028 года: разделы 1-3 главы III начинают применяться соответственно к способам применения высокого риска из Приложения III и к связанным с продуктами системам высокого риска по статье 6(1) и Приложению I.

Есть и другие переходные даты. Поставщики моделей общего назначения, выпущенных на рынок до 2 августа 2025 года, должны выполнить требования к 2 августа 2027 года. На операторов некоторых систем высокого риска, впервые выпущенных на рынок или введенных в эксплуатацию до соответствующей даты применения правил высокого риска, режим обычно распространяется после существенного изменения конструкции системы, сделанного после этой даты. При этом для поставщиков и операторов систем высокого риска, предназначенных для государственных органов, статья 111 устанавливает предельную дату 2 августа 2030 года. Точный подход зависит от системы и истории изменений законодательства.

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

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

Превратите чек-лист в условия выпуска

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

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

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

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

Используйте эту запись как минимальное согласование выпуска:

SYSTEM ID AND VERSION:
INTENDED PURPOSE APPROVED BY:
EU SCOPE AND TERRITORIAL HOOK:
OUR ROLE OR ROLES:
PROHIBITED PRACTICE CHECK:
GPAI MODEL DUTIES CHECK:
HIGH-RISK ROUTE AND RESULT:
ARTICLE 50 DUTIES AND TEST EVIDENCE:
DOCUMENT INDEX AND VENDOR EVIDENCE:
NEXT REVIEW TRIGGER AND OWNER:
RELEASE DECISION, DATE, APPROVER:

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

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

Отдайте карту одному человеку, а контроль распределите

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

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

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