Представим ситуацию: после внедрения ИИ-системы на заводе произошла незапланированная остановка оборудования. Разработчик утверждает, что программа работала корректно, но получила недостоверные данные. Предприятие возражает: система должна была распознать сомнительные показания и отказаться от действия. Интегратор указывает, что подключение выполнено по согласованной схеме. У каждой стороны есть объяснение, но остаётся главный вопрос: кто и на каком этапе должен был предотвратить происшествие?
Это условный пример, однако он показывает, почему распределение обязанностей нельзя откладывать до первого серьёзного сбоя. Пока ИИ только помогает искать документы и готовить отчёты, границы его применения сравнительно легко увидеть. Когда агент получает право организовывать работы, передавать задания и влиять на режим оборудования, необходимо отдельно определить, кто разрешает каждое действие и кто проверяет его результат. Различие между рекомендацией и правом на исполнение принципиально для промышленного применения таких систем.
При этом договорная формулировка «за работу программы отвечает поставщик, за эксплуатацию - заказчик» оставляет слишком много вопросов. Кто проверяет пригодность исходных данных? Кто устанавливает технологические ограничения и реализует их в программном обеспечении? Кто разрешает обновление, если оно меняет поведение агента? Именно между этими решениями может возникнуть разрыв: разработчик считает условие обеспеченным на объекте, а завод полагает, что оно проверяется внутри системы.
Поэтому предмет договорённости - не только возможное возмещение ущерба, но прежде всего ответственность за конкретную работу до его возникновения. Необходимо связать технические требования, испытания, предоставляемые права и порядок эксплуатации так, чтобы у каждой существенной проверки был исполнитель, а у каждого разрешения - понятное основание. Тогда обсуждение ответственности становится не поиском стороны, на которую можно переложить риск, а способом заранее закрыть опасные пробелы между продуктом и производством.
Ответственность между разработчиком ИИ-системы и заводом разумно распределять по принципу контроля: каждая сторона отвечает за те решения, свойства системы и условия эксплуатации, которые она определяет и способна проверять. Разработчик - за соответствие продукта согласованным требованиям, раскрытие ограничений и устранение дефектов. Завод - за корректность производственного задания, условия применения, предоставленные права и организацию эксплуатации. На границе между ними нужны совместные испытания и документированный порядок изменений.
Это предлагаемая инженерно-договорная модель, а не универсальная юридическая формула. Правовую ответственность за конкретный ущерб необходимо оценивать с учётом страны, отрасли, договора и обстоятельств происшествия. NIST AI RMF помогает организовать управление рисками и распределение ролей, но сам по себе не устанавливает, кто обязан возмещать убытки.
Сначала разделить обязанности, затем обсуждать возмещение ущерба
В договоре на промышленную ИИ-систему полезно различать три вопроса.
Первый - кто должен выполнить определённую работу: проверить данные, разработать блокировку, обучить персонал, испытать отказ связи.
Второй - кто принимает решение: разрешает ввод в эксплуатацию, расширяет автономность, утверждает обновление или останавливает систему.
Третий - кто и при каких обстоятельствах возмещает последствия нарушения обязательств.
Если начать сразу с последнего вопроса, легко получить договор с большим разделом о штрафах, но без ясного ответа, кто должен был проверить опасный сценарий.
Практическое руководство NIST рекомендует документировать роли, делегированные полномочия, условия применения, ограничения, результаты испытаний и управление изменениями. Отдельное внимание уделяется проверке сторонних систем и возможности их аудита.
За что следует отвечать разработчику
Разработчик не должен обещать безошибочность искусственного интеллекта. Но он должен предоставить продукт с определённым назначением, проверяемыми характеристиками и явно указанными ограничениями.
Для промышленного проекта формулировка «система помогает оптимизировать производство» слишком широка. Необходимо установить, какие именно задачи она решает, с какими источниками работает и какие действия ей разрешены.
Например: система анализирует архив компрессорной, выявляет определённые отклонения и готовит рекомендации. Самостоятельное изменение уставок в состав поставки не входит. Либо входит, но только для перечисленных параметров, в установленном диапазоне и после проверки заданных условий.
В предлагаемом распределении разработчику следует закрепить обязанности по соответствию программы этому описанию, достоверности документации, реализации согласованных защитных механизмов и поддержке продукта.
Ограничения должны быть пригодны для работы
Предупреждение «ИИ может ошибаться» почти ничего не даёт инженеру.
Полезное описание ограничения выглядит конкретнее: система не предназначена для диагностики при отсутствии измерения расхода; результаты не проверены для определённого режима; после изменения схемы оборудования требуется повторная настройка; при недостоверных исходных данных выдача исполнительной команды блокируется.
Разработчик должен объяснить, какие условия необходимы для корректной работы и как система обнаруживает их нарушение. NIST рекомендует требовать от поставщиков ясных инструкций, раскрытия предположений и ограничений, а также результатов испытаний.
Непредсказуемость модели не отменяет определённости программных ограничений
Следует различать качество аналитического вывода и выполнение жёсткого ограничения.
Система может ошибиться в гипотезе о причине перерасхода. Но если по требованиям она не должна выдавать команду выше установленного предела, проверка этого предела не должна зависеть от убедительности её рассуждений.
Поэтому в договоре желательно отдельно описывать вероятностные характеристики аналитики и обязательные свойства исполнительного контура. Для последних нужны свои испытания: попытка выйти за диапазон, выполнить запрещённую операцию, повторить команду или обойти согласование.
Оговорка о вероятностной природе ИИ не должна подменять описание того, как реализованы согласованные ограничения.
За что следует отвечать заводу
Завод лучше разработчика знает технологический процесс, фактическую конфигурацию оборудования и последствия изменения режима. Поэтому именно предприятие должно определить, чего требуется достичь и какие условия нарушать нельзя.
Если поставщику поручили «снизить энергопотребление», но не сообщили минимально допустимое давление на удалённом потребителе, задача поставлена неполно. Если в базе указано одно исполнение агрегата, а фактически установлено другое, это необходимо выявить до автоматического применения рекомендаций.
В модели NIST участники внедрения отвечают за контекст применения: пилотирование, проверку совместимости с действующими системами, организационные изменения и оценку использования в производственной среде.
В предлагаемом распределении завод должен обеспечить актуальные сведения об объекте, назначить владельца системы, определить разрешённые режимы и организовать работу персонала. Предоставление исполнительных прав также должно быть осознанным решением предприятия, а не побочным результатом подключения.
Завод не должен отвечать за то, что ему невозможно проверить
Нельзя возлагать на предприятие обязанность контролировать внутренние свойства модели, если поставщик не предоставляет ни методики, ни необходимых сведений.
Равным образом нельзя требовать от оператора обнаруживать скрытый дефект, который не проявляется в доступных ему данных.
Поэтому каждую обязанность полезно сопровождать вопросом: какие средства, сведения и полномочия получает сторона для её выполнения?
Если завод должен контролировать качество рекомендаций, поставщик должен обеспечить доступ к основаниям выводов. Если завод должен разрешать обновления, ему нужны сведения об изменениях и результаты испытаний. Если предприятие обязано сохранять доказательства инцидента, необходимо заранее определить состав и доступность журналов.
Такой подход согласуется с рекомендациями NIST обеспечивать прослеживаемость, документирование и возможность независимой проверки сторонних ИИ-систем.
Границу удобнее зафиксировать в матрице
Ниже приведена рабочая схема для договора и технического задания. Она описывает предлагаемые обязанности, а не устанавливает заранее виновника любого будущего происшествия.
| Область | Обязанность разработчика | Обязанность завода | Совместный результат |
|---|---|---|---|
| Назначение системы | Описать поддерживаемые функции и ограничения | Определить производственную задачу и запреты | Согласованная область применения |
| Исходные данные | Указать требования и реализовать согласованные проверки | Предоставить актуальные сведения и обеспечить измерения | Подтверждённая пригодность данных |
| Управляющие действия | Реализовать разрешения и ограничения | Утвердить объекты, диапазоны и условия воздействия | Перечень разрешённых операций |
| Интеграция | Обеспечить корректность поставляемых интерфейсов | Подтвердить конфигурацию действующих систем | Проверенная схема обмена |
| Испытания | Подготовить доказательства соответствия продукта | Обеспечить представительные сценарии объекта | Протокол приёмки с перечнем ограничений |
| Обновления | Раскрывать изменения и выполнять предусмотренные проверки | Разрешать применение на объекте | Управляемый выпуск новой конфигурации |
| Инциденты | Анализировать дефекты своего компонента и устранять их | Обеспечить безопасные действия на объекте и сохранение данных | Согласованный разбор причин |
| Прекращение сервиса | Выполнить предусмотренные обязательства по передаче и поддержке | Подготовить эксплуатационный переход | Проверенный режим работы без сервиса |
Особенно важно не оставлять «совместную ответственность» без владельца действия. Совместно можно оценивать риск, но у конкретной проверки должны быть исполнитель, срок и лицо, принимающее результат.
Интегратор не должен исчезать между двумя сторонами
На практике систему часто создают не только разработчик и завод. Отдельная компания подключает архивы, настраивает права, связывает обозначения оборудования и организует передачу команд.
Если ошибка возникла при сопоставлении тегов или настройке интерфейса, рассматривать её только как спор между моделью и эксплуатацией неверно.
В договорной схеме нужно установить, кто отвечает за сквозную работоспособность решения. Если завод покупает готовую систему у одного поставщика, целесообразно закрепить за ним координацию привлечённых исполнителей и единую процедуру обращения по дефектам. Если предприятие заключает отдельные договоры, потребуется отдельно определить владельца интеграции.
NIST рекомендует учитывать риски всей цепочки поставки, включая стороннее программное обеспечение, данные и другие компоненты, а также предусматривать действия при отказах внешних систем.
Как разбирать спорные случаи
Распределение обязанностей становится понятнее на примерах. Все ситуации ниже условные; окончательная юридическая оценка потребовала бы исследования обстоятельств.
Агент нарушил согласованный предел
В требованиях указано, что давление нельзя снижать ниже определённого значения. Завод предоставил корректные сведения, конфигурация соответствует принятой, но система сформировала и пропустила запрещённую команду.
Здесь прежде всего следует проверять исполнение требований к программной защите. Для разработчика или интегратора возникает вопрос: почему предусмотренное ограничение не сработало?
Ссылка на то, что «модель решила иначе», не объясняет отказ механизма, который должен был блокировать такую команду.
Завод расширил права после приёмки
Систему испытали как рекомендательную. Позднее предприятие подключило автоматическую передачу команд или отключило предусмотренное согласование.
Это существенное изменение конфигурации применения. При расследовании нужно установить, кто его выполнил и разрешил, сообщали ли об этом поставщику и проводились ли повторные испытания.
При этом сам факт изменения не доказывает, что оно вызвало происшествие. Причинную связь всё равно необходимо установить.
Данные были ошибочными, но система должна была это обнаружить
Завод передал неисправный сигнал. Разработчик может указать на качество входных данных. Но если по требованиям система обязана выявлять соответствующий тип недостоверности, необходимо проверить и её поведение.
Возможны два отдельных нарушения: предприятие не обеспечило оговорённое качество измерений, а программа не выполнила предусмотренную проверку.
Поэтому формулировка «за все исходные данные отвечает заказчик» не заменяет требований к контролю данных внутри продукта.
Обновление изменило поведение
Поставщик обновил модель или инструмент, после чего изменился выбор действий. В этом случае решающими становятся согласованный порядок обновлений, состав проведённых испытаний и разрешение на применение новой версии.
Необходимо заранее определить, какие изменения допускаются автоматически, а какие требуют повторной приёмки. NIST рекомендует учитывать обновления, исправления и совместимость сторонних компонентов в управлении рисками.
Что закрепить в договоре, кроме общих обещаний
Наиболее полезен договор, который ссылается на проверяемые приложения: техническое задание, описание разрешённых действий, требования к данным, программу испытаний, порядок обновлений и регламент инцидентов.
Приёмка должна подтверждать конкретные свойства
Фраза «система работает удовлетворительно» слишком неопределённа.
Для аналитики нужны согласованные показатели качества и представительная выборка. Для исполнительных функций - проверка ограничений, отказов и повторных команд. Для эксплуатации - понятные уведомления, журналы и переход в предусмотренный режим при недоступности сервиса.
Приёмка должна фиксировать не только то, что получилось, но и то, что не испытывалось или осталось запрещённым.
Поддержка должна описывать действия и сроки
Одного обещания «оперативно устранять неисправности» недостаточно. Следует различать время подтверждения обращения, начало диагностики, предоставление временного решения и выпуск исправления.
Для критичного случая желательно определить отдельный канал связи, право временного отключения автономных функций и порядок сохранения данных до изменений.
NIST рекомендует включать сторонние системы в планы реагирования и восстановления, а также предусматривать резервирование жизненно важных внешних функций.
Финансовые условия нужно связать с реальными последствиями
В предлагаемом договоре следует отдельно обсудить стоимость исправления дефекта, восстановительных работ, простоя, повреждения оборудования, брака и привлечения экспертов. Пределы ответственности, исключения, страхование и порядок предъявления требований требуют проверки юристом применительно к выбранному праву.
Важно не смешивать гарантию экономического эффекта и гарантию соответствия требованиям. Поставщик может не гарантировать конкретную экономию из-за изменения выпуска, но при этом должен выполнить согласованные требования к функциям и ограничениям системы.
NIST рекомендует рассматривать договоры, гарантии и страхование как часть управления рисками сторонних ИИ-компонентов, а не как замену техническим мерам.
Главный документ - описание разрешённой автономности
Для практической работы полезно подготовить отдельный документ, где зафиксированы объекты, функции, права, ограничения, условия остановки и порядок расширения возможностей агента.
Он должен отвечать на конкретные вопросы: может ли система только читать данные или также изменять их; вправе ли регистрировать заявку; какие команды может передавать; кто разрешает новую функцию; при каких изменениях требуется повторная проверка.
Такой документ связывает договор с реальной конфигурацией оборудования. Без него стороны могут подписать одни условия, а эксплуатировать систему с другими правами.
Хорошее распределение ответственности начинается не с поиска будущего виновника. Оно начинается с возможности открыть документы и однозначно установить: кто задал ограничение, кто его реализовал, кто проверил, кто разрешил эксплуатацию и кто изменил систему после приёмки.
Андрей Повный