- 1Для каждого этапа нужен свой вопрос: допустим ли пилот, что проверить при закупке, по каким условиям принять продукт и как контролировать его после запуска.
- 2Объём проверки определяют по данным, действиям ИИ, пользователям и последствиям ошибки. Название модели не заменяет описание процесса.
- 3Результат юридической работы должен приводить к конкретному решению, изменению договора или настройки. Документы следует связывать с фактической версией продукта.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
На этапе идеи определите задачу и пределы автоматизации
Начните с описания результата, который нужен бизнесу. ИИ готовит черновик, рекомендует действие или сам выполняет операцию? Кто получает ответ и как его использует? Сравните задуманную роль системы с тем, что подразделение собирается передать ей на практике.
Условный пример: помощник должен искать условия в договоре для юриста, но в дальнейшем его ответы планируют автоматически отправлять контрагенту. Второй сценарий меняет адресата и последствия ошибки. Его стоит оценить до выбора архитектуры, а не после жалобы получателя.
Итог этого этапа — границы назначения, ключевые ограничения и вопросы, влияющие на запуск. Для небольшой внутренней функции он может быть коротким. Для чувствительного клиентского процесса потребуется более подробное исследование. Единый пакет документов для всех идей обычно скрывает эту разницу.
До пилота согласуйте данные и доступ
Определите материалы для испытаний и тех, кто получит к ним доступ. Работа на реальных клиентских документах может затрагивать больше вопросов, чем демонстрация на условных примерах. Возможность быстро провести тест не доказывает допустимость выбранного набора данных.
Если используются персональные данные, основания обработки проверяют по статье 6 Закона № 152-ФЗ, а цели и достаточность — по статье 5. Для иных материалов отдельно оценивают права и договорные ограничения. Эти вопросы не закрываются названием «пилот».
Зафиксируйте участников теста, допустимые действия и условия завершения. Если подключены внешние инструменты, проверьте их полномочия. Пилот с возможностью отправлять сообщения или менять записи требует контроля над такими действиями, даже когда его результаты пока не видны клиентам.
При закупке проверьте обещания и возможности поставщика
Сопоставьте коммерческое предложение с технической схемой и условиями договора. Кто оказывает услугу, какие компоненты привлекаются, что происходит с запросами, как меняется модель? Для важной функции полезно заранее выяснить, какие сведения поставщик предоставляет при сбое или претензии.
Согласуйте необходимый доступ к документации, уведомления об изменениях и возможность прекращения использования. Условия выбирают по проекту, а не по универсальному списку. Обещание в договоре должно быть выполнимым: например, исполнитель должен действительно иметь доступ к сведениям, которые обязуется предоставить.
Отдельно опишите распределение задач между поставщиком и заказчиком. Кто проверяет результат, настраивает ограничения и уведомляет пользователей? Договор может распределить работу и расходы, но не позволяет произвольно перенести установленные законом обязанности перед третьими лицами.
До приёмки определите, как подтвердить результат
Требование «ИИ работает корректно» оставляет сторонам разные представления о качестве. Свяжите назначение с проверяемыми сценариями, допустимыми отклонениями и условиями отказа от приёмки. Решение должно учитывать не только обычные ответы, но и последствия значимых ошибок.
ГОСТ Р 72664-2026 описывает модель качества ИИ-систем и может служить ориентиром для требований и оценки. Конкретный объём применения и способ испытаний определяют для проекта. Само упоминание стандарта не показывает, какие результаты были получены.
Проверьте, что именно передаёт исполнитель: работающую версию, настройки, документы и необходимые доступы. Если существенные условия остаются только у одного разработчика, заказчик может принять продукт, который не способен самостоятельно поддерживать или проверять.
При запуске свяжите документы с интерфейсом
Посмотрите на продукт глазами пользователя. Как объясняется назначение функции, куда поступает обращение, кто принимает спорное решение? Сопоставьте этот маршрут с офертой, инструкциями и распределением ролей. Текст документа должен описывать действительное поведение системы.
Проверьте и внутреннюю сторону запуска: доступы, проверку ответов сотрудником, действия при недоступности сервиса. Если предусмотрен резервный процесс, испытайте его. Указание на возможность отключить ИИ полезно, когда ответственный знает, где это сделать и что будет дальше.
Итоговое решение о запуске должно содержать границы, известные ограничения и незавершённые действия. Устранённый критический риск, принятый допустимый риск и вопрос, который ещё не исследован, нельзя обозначать одним словом «согласовано».
В эксплуатации контролируйте изменения
После запуска меняются модель, источники, интеграции и способ использования. Назначьте события, при которых проверка возобновляется: расширение категории данных, новый внешний исполнитель, добавление инструмента или выход на другую аудиторию. Не каждое изменение требует полного аудита, но значимые изменения нужно обнаруживать.
Сопоставляйте сообщения об ошибках с первоначальными ограничениями. Если сотрудники регулярно обходят проверку результата, возможно, фактический процесс отличается от согласованного. В таком случае обновить документ недостаточно: нужно решить, допустим ли новый сценарий и какие меры необходимы.
Закажите работу с понятным результатом
Для каждого этапа определите исходные сведения, вопросы проверки, ожидаемый документ и решение, которое он позволит принять. На ранней стадии это может быть карта пробелов; перед закупкой — условия договора; перед запуском — перечень исправлений и границы использования.
Юридическая оценка, техническое испытание и внедрение меры требуют разных компетенций. Укажите, кто выполняет каждую часть и как передаётся результат. Тогда заключение не останется списком рекомендаций без владельца, а разработка получит объяснимые требования.
Объём и сроки работы согласуют по конкретному процессу и доступности материалов. Правовая поддержка ИИ становится полезной, когда она помогает команде своевременно принять решение и проверить, как это решение реализовано в продукте.