Положение 1

Право на алгоритмический аудит

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

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

Положение 2

Уведомление об изменении модели

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

Почему это важно: Среднее время обнаружения изменения модели составляет 60 дней - по данным MIT Sloan Management Review. За это время организация принимает тысячи решений на основе модели, которую она считает стабильной.

Положение 3

Стандарт объяснимости

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

Почему это важно: GDPR статья 22 и аналогичные законы штатов США дают субъектам данных право на объяснение автоматизированных решений. Без этого положения ваша организация не сможет выполнить это требование без помощи вендора - который может отказаться сотрудничать.

Положение 4

Распределение ответственности и покрытие ущерба

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

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

Положение 5

Право на приостановку и прекращение работы

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

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