1. Определите решение об эксплуатации на дату закрытия сделки
Комитет по приобретению должен утвердить документированную основу для эксплуатации систем ИИ, которые объединенный бизнес намерен использовать. В решении должны быть указаны разрешенные цели, ответственные лица, существенные ограничения и лицо, уполномоченное приостановить каждую услугу. Для приложения, критически важного для дохода, комитету также необходимы доказательства того, что услуга будет доступна в случае отзыва модели. В этом документе предлагается структура после закрытия сделки для сбора этой информации и принятия решения о том, какую интеграцию можно продолжить.
Транзакция может объединить приложения, использующие одну и ту же базовую модель, посредством разных контрактов, источников данных и клиентских интерфейсов. Общее имя поставщика обеспечивает начальную точку сравнения. Команде интеграции по-прежнему необходимо изучить развернутую конфигурацию и ее фактическое использование в каждой компании. Сюда входят традиционные модели прогнозирования, сторонние функции ИИ в рамках бизнес-программного обеспечения и генеративные системы, которые извлекают информацию или выполняют действия. Предлагаемый объем соответствует эксплуатационному риску и полномочиям принятия решений.
Выражение «единая система контроля» означает общие записи управления и решения с установленной ответственностью. Такая система допускает отдельные рабочие среды, если это обосновано договорными условиями, техническими зависимостями или результатами оценки. Общий реестр связывает эти среды с единой политикой утверждения и процедурой реагирования на инциденты. Техническая консолидация становится отдельно утверждаемым изменением со своими результатами испытаний, бюджетом и механизмами восстановления. Продолжение эксплуатации зависит от условий, применимых к конкретной услуге.
Структура управления рисками ИИ NIST предоставляет добровольный межотраслевой справочник по организации управления, картированию контекста, измерению и обработке рисков. Результаты его инвентаризации, мониторинга и подотчетности имеют отношение к предлагаемому проекту интеграции. Структура не устанавливает, что приобретение соответствует требованиям или что унаследованная система безопасна. В этом документе опубликованные результаты используются для формулирования вопросов комплексной проверки и ведения операционной документации. Инвестиционный комитет продолжает нести ответственность за получение профессиональных рекомендаций и доказательств, необходимых для принятия фактического решения. [1]
2. Установите периметр перед изменением доступа
Начните с юридических лиц, бизнес-процессов и сред, включенных в транзакцию. Запишите, что передается при закрытии сделки, а что остается в зависимости от продавца или третьей стороны. Определите предполагаемого оператора каждой услуги, клиентов, получающих ее результаты, и сотрудников, которые могут изменить ее конфигурацию. До закрытия сделки любой обмен информацией или подготовка к интеграции должны соответствовать утвержденным соглашениям о конфиденциальности и законодательству о конкуренции. В документе не предполагается никаких полномочий на объединение систем до юридического закрытия сделки.
Область применения должна распространяться на функциональные возможности ИИ, встроенные в приобретенное программное обеспечение. Попросите каждого владельца процесса определить, где рекомендации или автоматизированные действия влияют на ценообразование, общение с клиентами, производственные графики, найм или доступ к услугам. Сверьте эти заявления с утвержденными техническими записями и записями о закупках. Сохраняйте методы обнаружения пропорциональными и одобренными. Целью является прослеживаемый перечень соответствующих видов использования; личные учетные записи сотрудников и несвязанные с ними конфиденциальные материалы остаются за пределами санкционированной проверки, если только это не включает законный специальный процесс.
Для каждого развертывания определите подсчитываемую единицу учета эксплуатации. Полезная предлагаемая единица — это приложение с версией в определенной среде, используемое указанной организацией для утвержденной цели. Два приложения, использующие одно и то же семейство моделей, могут оставаться двумя развертываниями, поскольку их данные, разрешения и последствия различаются. Несколько записей реестра могут описывать одно развертывание, если они являются повторяющимися административными записями. Сохраняйте доказательства, подтверждающие каждое решение о сверке, чтобы можно было воспроизвести последующие подсчеты.
Включите зависимости, находящиеся за пределами приобретенного периметра. Примеры для исследования включают службу идентификации, управляемую продавцом, общий набор оценочных данных и поддержку поставщика, предоставляемую в рамках контракта с продавцом. Запишите владельца зависимости, порядок доступа, запланированную продолжительность и условия принятия замены. Соглашение о переходном процессе следует пересмотреть на предмет действительно необходимой помощи. Затем план интеграции может связать срок действия зависимости с датой, когда альтернатива должна быть протестирована и одобрена.
Отделяйте уверенность в полноте выявления систем от разрешения на их эксплуатацию. Запись реестра, подтвержденная ответственным лицом, может еще не содержать проверенного порога мониторинга или пригодного процесса восстановления. При этом хорошо контролируемая услуга может отсутствовать в первоначальном реестре сделки. Явно отслеживайте оба аспекта. Комитет получает представление о выявленных системах и отдельное представление о доказательствах, подтверждающих возможность их дальнейшего использования.
3. Согласуйте инвентаризацию модели без потери развертываний.
Сохраните исходные идентификаторы обеих компаний и добавьте связанный с ними групповой идентификатор. Запись должна содержать версию модели или услуги, назначение приложения, операционную организацию, место размещения рабочей среды и ответственного за эксплуатацию со стороны бизнеса. Свяжите подтверждающие документы посредством контролируемых ссылок. Сохраняйте исторические версии, чтобы более поздний инцидент можно было связать с конфигурацией, действовавшей на тот момент. Изменения в описи должны указывать редактора, причину и дату вступления в силу.
Следующая сверка полностью гипотетическая. Компания A предоставляет 100 записей, а компания B — 80. При проверке выявляются 15 повторяющихся административных записей, описывающих уже подсчитанные развертывания. В рамках этого примера подтверждающие материалы показывают, что 25 из оставшихся развертываний были выведены из эксплуатации. Утвержденная проверка выявила отсутствие 12 дополнительных активных развертываний в первоначальных реестрах. В результате получается число активных развертываний: 180 минус 15, минус 25, плюс 12 или 152. Каждое число является иллюстративным предположением.
Авторская наглядная инвентаризационная арифметика. Общие семейства моделей не удаляются только потому, что у них один и тот же поставщик.
Вывод из эксплуатации требует установленного стандарта подтверждающих материалов. Предлагаемая запись должна показывать, что производственный маршрут отключен, соответствующие учетные данные обработаны и что любое обязательство по дальнейшему хранению закреплено за ответственным лицом. Даже после отметки о закрытии проекта в инструменте разработки связанный с ним процесс по расписанию может оставаться активным. Ответственный за реестр должен сверить административный статус с утвержденными данными об эксплуатации. Исторические активы, требующие хранения, могут оставаться в категории архива, отдельной от активных развертываний.
После сверки классифицируйте 152 показательных развертывания по данным об эксплуатации. Предположим, что 82 имеют полные доказательства их нынешнего одобренного использования, 50 имеют ограниченное по времени условное одобрение и по 20 решение об эксплуатации еще не принято. Первые две категории составляют 132, или 86,8% развертываний в реестре. Этот процент описывает зарегистрированный статус утверждения в соответствии с предполагаемыми критериями. Сам по себе он ничего не говорит о серьезности остающихся рисков или адекватности используемых критериев.
4. Подключите каждое развертывание к разрешенному использованию.
Напишите предполагаемую цель в терминах эксплуатации. Служба, которая готовит ответ для обученного сотрудника, имеет другой рабочий процесс, чем служба, уполномоченная выдавать этот ответ непосредственно клиентам. Запишите результат, получателя, разрешенное действие и требуемую проверку. Опишите запрещенные расширения и способ запроса изменения. Утвержденное заявление об использовании должно быть достаточно конкретным, чтобы владелец процесса мог определить, когда реальная практика отклоняется от него.
Прикрепите к этому заявлению карту доступа к данным. Определите исходные системы, категории данных, разрешения на получение и места назначения журналов или выходных данных. На карте должно быть указано соответствующее юридическое лицо и среда для каждого подключения. Адвокаты и специалисты по конфиденциальности должны оценить применимые права и ограничения. Технический персонал должен продемонстрировать, что утвержденный доступ может быть реализован. Смена владельца на уровне группы не дает никаких доказательств того, что каждый набор данных может быть доступен каждому приложению.
Просмотрите разрешения систем, способных выполнять действия. Приложение, которое может выполнять поиск в хранилище документов, обновлять записи о клиентах и инициировать рабочий процесс, связанный с платежами, требует отдельного описания каждой возможности. Спросите, какие разрешения необходимы для утвержденной цели и кто может предоставить дополнительный доступ. Протестируйте отклоненные действия и пути эскалации, а также успешные запросы. Предлагаемый протокол приемки должен указывать, какие действия остаются предметом одобрения человека.
Для генеративных систем запишите источники поиска, подсказки или инструкции по настройке, подключенные инструменты и соответствующую версию модели вместе с кодом приложения. Генеративный профиль ИИ NIST учитывает сторонние зависимости и рекомендует проводить инвентаризацию объектов, имеющих доступ к содержимому организации. Обсуждение цепочки создания стоимости и интеграции компонентов поддерживает анализ зависимостей, выходящий за рамки поставщика модели. Предлагаемая инвентаризация транзакций использует это руководство для запроса данных конкретной версии о зависимостях доступа и услуг. [2]
Обеспечьте отдельную проверку каждого изменения доступа в ходе интеграции. Для предлагаемой общей группы идентификации перечислите людей и приложения, получающих доступ, деловую цель и ожидаемый срок действия временных разрешений. Сохраните результаты проверки этих границ. Если вопрос доступа остается нерешенным, задокументируйте разрешенную на текущий момент конфигурацию услуги и работы, необходимые для согласования более широкого режима эксплуатации.
5. Распределите полномочия принятия решений по объединенному бизнесу.
Совет директоров или уполномоченный руководитель должен определить допустимый уровень риска и назначить ответственного куратора интеграции. Куратору необходимы полномочия для разрешения конфликтов по поводу ресурсов, сроков и деловых приоритетов. Назначенное ответственное лицо со стороны бизнеса должно отвечать за разрешенное использование каждой услуги и его последствия. Инженерная команда должна поддерживать реализацию и технические подтверждающие материалы. Независимую критическую оценку следует поручить компетентным специалистам, достаточно независимым от решения о внедрении.
Приведенная матрица предлагает распределение обязанностей, которое необходимо адаптировать к конкретной организации. R обозначает исполнителя работы; A обозначает лицо, несущее конечную ответственность за указанное решение; C обозначает консультируемую сторону; I обозначает информируемую сторону. В каждой строке конечная ответственность закрепляется за одной ролью. Обязанности по профессиональной проверке остаются в рамках правовых и регуляторных требований к организации. Матрица не переносит установленные законом обязанности с лица или организации, на которых они возложены.
| Решение или рабочий элемент | Куратор интеграции | Ответственный со стороны бизнеса | Технический руководитель | Независимый рецензент |
|---|---|---|---|---|
| Инвентаризация и запись назначения | I | A | R | C |
| Материалы оценки и независимый критический анализ | I | C | R | A |
| Обычный выпуск в пределах утвержденных пределов | I | A | R | C |
| Существенное исключение при интеграции | A | R | C | C |
| Аварийное техническое сдерживание | I | A | R | C |
| Возобновление после существенного инцидента | A | R | R | C |
Иллюстративное распределение. Перед использованием необходимо поименно указать куратора, ответственное лицо со стороны бизнеса, технического руководителя и независимого проверяющего. По применимым требованиям консультируются со специалистами по правовым вопросам и комплаенсу.
Матрица должна сопровождаться четким делегированием полномочий и механизмом реагирования. Назначьте заместителей на время отсутствия ответственных лиц и определите, как до них доводятся срочные вопросы для принятия решений. Ежемесячное заседание комитета по управлению не может служить единственным механизмом для службы, требующей немедленного сдерживания. Заранее санкционируйте конкретные экстренные действия в установленных условиях, ведите журнал аудита и требуйте последующего анализа. Ответственное лицо должно знать эксплуатационные последствия каждого санкционированного действия.
Независимая проверка должна дать заключение, которым может воспользоваться лицо, принимающее решение. В нем должно быть указано, что было протестировано, важные ограничения и изменения, требующие повторного рассмотрения. Неразрешенное разногласие должно оставаться в протоколе утверждения вместе с решением и обоснованием. Сотрудникам, которые оценивают систему, необходим доступ к соответствующим доказательствам и канал эскалации, если эти доказательства отсутствуют. NIST четко определяет роли и ответственность руководителей в рамках результатов своего управления. [1]
Не делайте одного человека постоянным ответственным за каждое развертывание только для того, чтобы заполнить реестр. Закрепите ответственность за функцией, способной понимать работу услуги и действовать с учетом ее последствий. Управление группой может определять общие требования и критически оценивать исключения, сохраняя при этом операционную подотчетность. Пересмотрите распределение, когда организационная реструктуризация меняет линии отчетности или удаляет роль.
6. Гармонизировать пороги одобрения с помощью доказательств
Сравните существующие правила утверждения двух компаний, используя фактические изменения, которые претерпевают их системы. Соответствующие примеры включают введение нового источника данных, изменение версии модели, распространение использования на новую группу клиентов или предоставление приложению новых возможностей действий. Запишите доказательства, которые в настоящее время требуются каждой компании, и орган, подписывающий решение. Это сравнение должно выявить пробелы и определить полезные меры контроля, которые необходимо сохранить в ходе интеграции.
Создайте общую таксономию изменений с пороговыми значениями, привязанными к последствиям и неопределенности. Плановое техническое обслуживание может соответствовать установленной процедуре технического выпуска, если оно остается в пределах оцененного рабочего диапазона. Изменение цели, затронутых групп лиц, автономии или юридической роли должно повлечь за собой дополнительный пересмотр. Определите доказательства, необходимые для установления того, что изменение подпадает под существующее одобрение. Описание разработчиком изменения как незначительного должно быть подтверждено записанной оценкой.
В протоколе утверждения должны быть указаны измеримые условия приемки, в которых измерения уместны. Включите соответствующие показатели производительности, тестовые группы, периоды наблюдения и ограничения на интерпретацию. Отдельно документируйте качественные, нечисловые требования, такие как подтвержденное договорное разрешение или специально обученный рецензент. Составной балл может скрыть отсутствие обязательного условия. Предлагаемый процесс фиксирует каждое необходимое условие и доказательства, подтверждающие его выполнение, прежде чем будет принято решение о выпуске.
Используйте ограниченные по времени исключения для определенного режима работы, если уполномоченное лицо, принимающее решения, считает такое соглашение допустимым. Укажите нерешенную проблему, временный контроль, ответственное лицо и условия истечения срока действия. Выявляйте события, которые досрочно прекращают действие исключения, например смену версии поставщика или нарушение мониторинга. Продолжение эксплуатации после истечения срока действия требует нового решения с учетом актуальных подтверждающих материалов. В документе не содержится оснований для использования исключения для отмены применимого запрета или обязательного требования.
Сохраняйте историю изменений во время перехода. Если два календаря выпуска совпадают, запишите, какая версия была оценена, а какая — развернута. Установите согласованную точку, после которой одобрение должно быть пересмотрено, поскольку произошедшие изменения повлияли на его обоснованность. Общий идентификатор заявки может связывать инженерные записи, бизнес-утверждение и независимую проверку. Приемочное испытание должно подтвердить, что эти ссылки ведут к реальным документам и развернутой конфигурации.
7. Оцените производительность в комбинированном операционном контексте.
План оценки должен отражать предполагаемое использование после закрытия сделки. Определите пользователей, языки, источники данных, объемы транзакций и последствия решений в объеме. Тестирование, проведенное для исходного рабочего процесса продавца, может потребовать расширения, если покупатель вводит другую совокупность клиентов или действие. Сохраните исходные результаты и задокументируйте то, что остается применимым. Рецензент должен указать, какие дополнительные наблюдения необходимы, прежде чем утвердить измененное использование.
Используйте набор оценочных данных, происхождение и разрешенное использование которого были проверены. Отделите материалы разработки от доказательств, используемых для независимого оспаривания, если схема оценки требует такого различия. Запишите методы выборки, соответствующие подгруппы и известные ограничения. Количественные результаты должны включать знаменатель и условия испытаний. Процентное соотношение без описания оцененных случаев не может обеспечить надежное сравнение записей оценок двух компаний.
Проверьте весь путь приложения. Правильный ответ модели может быть неправильно преобразован последующим рабочим процессом, доставлен неавторизованному получателю или принят без запланированной проверки. Включите в дизайн теста обработку ввода, извлечение, пользовательский интерфейс, утверждения и заключительные действия. Для систем, использующих инструменты, оцените, соблюдает ли приложение границы разрешений при неблагоприятных входных данных. Разрешенный уровень тестирования должен быть разрешен и изолирован от производственных действий, где это необходимо.
Документируйте случаи сбоев, которые имеют значение для бизнес-решения. Приложение поддержки клиентов может потребовать отдельной оценки необоснованных обязательств, раскрытия ограниченной информации и неправильной маршрутизации жалоб. Приложение для планирования производства может потребовать оценки невыполнимых графиков и последствий позднего вмешательства человека. Это предлагаемые примеры проектирования вариантов использования. Фактический набор тестов должен соответствовать цели услуги, договорным обязательствам и соответствующим профессиональным требованиям.
Функция измерения NIST включает тестирование перед развертыванием и во время эксплуатации с вниманием к неопределенности и пригодности методов. Интеграционный комитет должен получить сведения об ограничениях оценщика вместе с результатами. Успешный тест подтверждает конкретный вывод, сделанный в результате этого теста. Для более широкого утверждения эксплуатации необходимы оставшиеся доказательства, указанные в плане оценки. Частота проверок должна отражать приложение и изменения, которые могут повлиять на его производительность. [1]
8. Установите мониторинг, который приведет к принятию решения
Каждая мера мониторинга должна иметь определенный ответ. Запишите источник данных, расчеты, частоту отчетности и человека, который расследует нарушение. Определите, как обнаруживаются пропущенные наблюдения и что происходит, когда сам мониторинг становится недоступным. Ответственный со стороны бизнеса должен понимать, описывает ли эта мера доступность услуг, качество результатов, поведение при доступе или результат, влияющий на клиентов. Эти измерения требуют отдельной интерпретации, даже если они появляются на одной информационной панели.
Сохраняйте меры, специфичные для компании, до тех пор, пока команда не продемонстрирует правильное общее определение. Два приложения могут сообщать о точности, используя разные выборки, метки или методы проверки. Объединение этих процентов может привести к неинтерпретируемому результату. Запись о гармонизации должна разъяснять старое определение, предлагаемое определение и любой период параллельных измерений. Сохраняйте информацию, необходимую для интерпретации исторических результатов после изменения показателя отчетности.
Выбирайте пороговые значения с учетом утвержденной цели, доказательств оценки и применимых обязательств. В документе не предлагается универсального порога точности или приемлемой частоты ошибок. Некоторые условия требуют немедленного ограничения, даже если совокупная производительность остается в пределах числового предела. Примеры оценки включают несанкционированный доступ, существенное изменение цели и потерю обязательного этапа проверки человеком. Документируйте эти условия вместе со статистическими оповещениями, чтобы группа по работе с инцидентами могла действовать в любом случае.
Оценивайте человеческий надзор как оперативную деятельность. Установите, кто проверяет результаты, возложенную на них рабочую нагрузку и доказательства, сохраняемые при их вмешательстве. Проверьте, получают ли рецензенты достаточный контекст, чтобы распознать проблемный результат. Проверьте, могут ли они приостановить рабочий процесс и получить помощь. Требование о проверке должно сопровождаться предположениями о кадровом обеспечении и возможностях обслуживания, которые можно проверить на соответствие фактическому графику работы.
Анализируйте инциденты, жалобы и ситуации, едва не приведшие к инциденту, вместе с количественными показателями. Отчет клиента может выявить проблему за пределами текущего набора тестов. Свяжите отчет с соответствующим развертыванием и версией, изучите его и запишите все изменения в план оценки. Обеспечьте контроль доступа к деталям жалоб и доказательствам инцидентов. Мониторинг должен поддерживать документированное решение о продолжении эксплуатации, дополнительных мерах контроля, повторной оценке или приостановке.
9. Интегрируйте поставщиков и контракты в управление
В реестре поставщиков должно быть указано, какая организация заключает контракт на каждую услугу и какая организация использует ее после закрытия сделки. Изучите положения об уступке прав и передаче обязательств, смене контроля, авторизованном пользователе и обработке с соответствующими консультантами. Запишите доказательства, подтверждающие продолжение доступа, включая любое необходимое согласие или пересмотренную форму заказа. Техническую возможность поставщика предоставить доступ следует рассматривать отдельно от договорного разрешения на использование такого доступа.
Задокументируйте изменения, которые поставщик может внести без выпуска, контролируемого клиентом. Они могут касаться модели, организации хостинга, настроек хранения или функций приложения, в зависимости от фактической услуги. Получите применимые уведомления и условия управления версиями. Технический ответственный должен объяснить, как обнаруживаются изменения со стороны поставщика и как оценивается их влияние на разрешенное использование. Сохраняйте альтернативный план работы для зависимостей, чья соответствующая конфигурация не может оставаться постоянной.
Согласуйте, как информация об инцидентах доходит как до поставщика, так и до всего предприятия. Определите каналы поддержки, авторизованные контакты и информацию, которой каждая сторона может поделиться. Ознакомьтесь с доступной помощью для расследования, сдерживания и восстановления. Руководство NIST по реагированию на инциденты рассматривает третьи стороны как участников модели общей ответственности и включает их в планирование и учения. Предлагаемый процесс интеграции предполагает совместную проверку механизмов, описанных в реальном контракте. [3]
Оценивайте концентрацию зависимостей и ее последствия. Несколько бизнес-приложений могут зависеть от одной конечной точки сервиса или поставщика идентификации, даже если названия моделей различаются. Карта зависимостей должна показывать, какие клиентские процессы пострадают при сбое или прекращении предоставления такого сервиса. Проверяйте альтернативы с учетом разрешений на работу с данными, производительности и требований к качеству. Непроверенный второй поставщик остается лишь возможным резервным вариантом; необходимые приемочные проверки еще не завершены.
Экономия на закупках будет зависеть от проверенного объема и затрат на выход из действующих договоров. Консолидация контрактов может изменить минимальные обязательства, права использования и механизмы поддержки. Попросите финансистов согласовать предлагаемую экономию со стоимостью миграции, оставшимися обязательствами и дополнительной оценкой. В отчете об управлении должно быть указано, какое решение поставщика было одобрено, а также доказательства, необходимые для признания его влияния в бюджете интеграции.
10. Определите последовательность унификации контроля через условия приемки
Предлагаемая последовательность интеграции начинается с устойчивой системы эксплуатационных записей на дату закрытия сделки. Установите ответственных лиц, сохраните существующие утвержденные конфигурации и определите срочные решения. Прежде чем приступать к широкой технической миграции, внедрите общие контакты по инцидентам и контролируемый журнал изменений. Любая известная проблема, требующая немедленных действий, должна быть включена в соответствующий процесс реагирования. Последовательность обеспечивает организационную структуру; обязательства, связанные с конкретной транзакцией, и условия инцидента могут потребовать более раннего вмешательства.
На следующем этапе происходит сверка инвентарных описей и сравнение контрольных данных. Подтвердите цель и зависимости существенных развертываний, проверьте пробелы и назначьте исправления с указанием сроков. Введите общие определения записей и маршруты утверждения. Эта работа может выполняться, пока отдельные производственные среды продолжают работать в соответствии с утвержденными договоренностями. Фаза считается завершенной, когда имеются необходимые доказательства и решения, независимо от даты, первоначально указанной в плане интеграции.
Иллюстративная последовательность с условиями приемки, подкрепленными подтверждающими материалами. Никакого фиксированного времени завершения не предполагается.
Миграция должна следовать проверенному проекту с явным решением о восстановлении. Сравните результаты и поведение рабочего процесса в предлагаемой среде в утвержденных условиях тестирования. Определите, какие различия ожидаются, а какие требуют исследования. Определите, кто вправе остановить миграцию, последнюю точку, в которой откат остается возможным, и доказательства, необходимые для возобновления. Технический откат должен учитывать записанные данные или действия, предпринятые во время попытки переключения.
Передавайте ответственность постоянной эксплуатирующей организации только после того, как ее сотрудники примут на себя ответственность за документацию, доступ и поддержку. Запишите открытые исключения, оставшиеся зависимости от поставщиков и даты проверки. Выводите временные учетные записи и переходные механизмы из использования в рамках утвержденной процедуры. Сохраняйте доказательства в соответствии с применимыми требованиями к хранению. Спонсор интеграции должен получить заключительное заявление, в котором будет указано, что было принято, а что остается рабочим обязательством.
11. Составьте карту инцидентов от обнаружения до санкционированного восстановления.
Используйте общий маршрут инцидентов, который может принимать отчеты от любой компании, клиентов и соответствующих поставщиков. Первоначальная запись должна идентифицировать затронутую услугу, наблюдаемое поведение, время и источник отчета. Сохраняйте доказательства с помощью разрешенных процедур. Лицу, осуществляющему реагирование, следует оценить потенциальное воздействие и решить, требуется ли немедленное сдерживание. Классификацию следует пересматривать по мере улучшения информации; раннее описание может упустить важные последствия.
Назначьте руководителя инцидента с доступом к ответственному со стороны бизнеса, технической команде и соответствующим юристам. Руководитель координирует реагирование и записывает решения. Предлагаемая карта отделяет техническое сдерживание от решений о внешнем оповещении и возобновлении. Требования к уведомлению определяются действующим законодательством, контрактами и профессиональными обязательствами. Документ не устанавливает универсальных сроков отчетности и не предполагает разрешения на раскрытие личной или конфиденциальной информации каждому участнику.
Требования к уведомлению и полномочия на восстановление должны быть определены для фактической услуги и юрисдикции. Стрелки показывают координацию с одновременной проверкой специалистами, где это необходимо.
Рассмотрим иллюстративный случай, когда вновь подключенный источник извлечения данных раскрывает информацию приложению за пределами утвержденной области доступа. Предлагаемый немедленный ответ состоит в том, чтобы ограничить затронутое соединение с помощью уполномоченных средств контроля, сохранить соответствующие доказательства и определить масштаб воздействия. В ходе расследования необходимо изучить разрешения, изменения конфигурации и последующих получателей. Ответственный со стороны бизнеса должен определить, какая услуга может продолжаться в рамках проверенных ограничений, пока оценивается более широкая проблема.
Для восстановления необходимы доказательства того, что утвержденная услуга может работать в пересмотренных условиях. Протестируйте способы устранения и соответствующий путь отказа, подтвердите мониторинг и запишите остаточные проблемы. Прежде чем возобновить затронутую функциональность, получите необходимое разрешение. Возвращение к технической доступности дает одно наблюдение в этом решении. Анализ инцидента также должен учитывать последствия для клиентов, сохранение доказательств и изменения, необходимые для процесса интеграции. Рекомендации NIST по реагированию включают восстановление и уроки, которые можно использовать для управления рисками. [3]
12. Применять требования юрисдикции и отрасли к конкретным видам использования.
Создайте запись о юридической применимости для каждого существенного развертывания. Определите операционные организации, затронутых людей, обслуживаемые рынки, цель и роль в цепочке поставок. Попросите квалифицированных консультантов определить соответствующие обязательства и даты начала применения требований. Сохраняйте эту запись связанной с утвержденной конфигурацией. Изменение географии, цели или бренда должно побудить к пересмотру там, где это может повлиять на юридический анализ. В результате групповая политика может включать результирующие требования, не скрывая при этом локальных обязанностей.
Конкретный пример представляет собой сводный текст Регламента ЕС об искусственном интеллекте от 27 июля 2026 года. В статье 25 рассматриваются обстоятельства, при которых оператор становится поставщиком системы высокого риска, включая определенные изменения, связанные с брендингом, существенной модификацией или целевым назначением. Статья 26 касается обязанностей развертывающих организаций, включая компетентный человеческий надзор и мониторинг. Эти положения требуют оценки сферы применения, исключений и применимых правил перехода, прежде чем они будут рассматриваться как текущая обязанность для конкретной системы. [4]
На текущей странице Европейской комиссии указаны разные даты начала применения отдельных частей Регламента с учетом поправок 2026 года. Команда интеграции должна вести датированный реестр обязательств, сверенный с консолидированным законодательством и соответствующими профессиональными рекомендациями. В статье не утверждается, что все требования к системам высокого риска применяются ко всем развертываниям на дату закрытия сделки. План сделки должен фиксировать конкретное требование, дату его применения, ответственную организацию и доказательства, необходимые для соблюдения. [5]
Принципы этики ИИ SDAIA обсуждают подотчетность, отслеживаемость, мониторинг и проверку третьих сторон на протяжении всего жизненного цикла системы. Хартия ОАЭ, принятая в июле 2024 года, включает человеческий надзор, управление, подотчетность и соблюдение действующего законодательства. Эти основные публикации предоставляют соответствующие региональные ориентиры для предлагаемой структуры управления. Их статус и применение к конкретному субъекту требуют отдельной оценки. Они не дают общего разрешения на трансграничную передачу данных, регулируемую финансовую деятельность или развертывание в конкретных отраслях. [6],[7]
Для операций в странах Совета сотрудничества арабских государств Персидского залива (GCC), обслуживающих международных клиентов, ведите договорные обязательства наряду с реестром правовых требований. Приложение к договору о безопасности или закупочные требования клиента могут устанавливать условия в отношении доказательств, необходимых для продолжения обслуживания. Проверьте подписанные условия и то, какая сторона вправе принять изменение. Сохраняйте различие между правовыми требованиями, договорными обязательствами и внутренними мерами контроля. Инвестиционному комитету необходима четкая запись основания каждого условия и последствий его невыполнения.
13. Бюджет на сбор доказательств и параллельную работу
Бюджет реализации должен отделять общие расходы по программе от работы, связанной с развертыванием, и временных оперативных расходов. Используйте документированную инвентаризацию в качестве основы объема. Получите оценки для фактических задач оценки, исправления и миграции, а также лежащие в их основе предположения. Запишите зависимости, которые могут изменить количество проверок или продолжительность параллельной работы. Финансовому отделу следует согласовать бюджет с утвержденными пакетами работ и определить владельца каждой существенной сметы.
Следующий бюджет является полностью гипотетическим и использует доллары США. Предположим, что USD 180,000 используется для общей настройки программы, включая реестр, согласование политик и начальные рабочие процедуры. 152 иллюстративных развертывания распределены по трем категориям работ: для 32 требуется углубленная оценка по USD 4,000 за развертывание, для 60 требуется оценка средней трудоемкости по USD 2,000 и для 60 требуется ограниченная проверка по USD 500. Это предполагаемые категории рабочей нагрузки, без утверждений о правовой классификации рисков.
| Пакет работ | Расчет | Предполагаемые расходы |
|---|---|---|
| Общая настройка программы | Фиксированная предполагаемая сумма | 180,000 |
| Интенсивные оценки | 32 развертывания по 4 000 за каждое | 128,000 |
| Оценки средней трудоемкости | 60 развертываний по 2 000 за каждое | 120,000 |
| Ограниченные проверки | 60 развертываний по 500 за каждое | 30,000 |
| Временная параллельная работа | 6 месяцев по 35 000 в месяц | 210,000 |
| Полная базовая реализация | Сумма пяти пакетов работ | 668,000 |
Иллюстративные допущения автора, суммы в USD. Они не представляют наблюдаемые цены поставщиков, ставки оплаты труда, консультационное предложение или рыночный ориентир. Категории оценки в данном расчете взаимоисключающие.
В расчете предполагается, что расходы на оценку покрывают указанную работу по проверке и что временные эксплуатационные расходы являются дополнительными к этим расходам. Сюда не входят обычные операционные расходы бизнеса, налоги, затраты на финансирование, влияние на доходы и работы по устранению недостатков, выходящие за рамки заявленных пакетов работ. В фактическом бюджете потребуются определения объемов работ и учет рабочего времени, чтобы избежать двойного учета одних и тех же расходов на персонал. Иллюстративная сумма представляет собой расходы при выбранных допущениях без привязки к вероятности.
Рассмотрим продление на три месяца при той же предполагаемой ежемесячной стоимости параллельной работы USD 35,000. Это добавляет USD 105,000. Предположим, что восемь интенсивных оценок также необходимо повторить после существенных изменений конфигурации, каждая из которых стоит USD 4,000. Повторная работа добавляет USD 32,000, в результате чего дополнительные расходы составляют USD 137,000, а общий итог после продления составляет USD 805,000. Повторные оценки представляют собой дополнительную работу над существующими развертываниями; они не увеличивают число развертываний в реестре.
Комитету следует изучить причины такого продления. Задержка согласия поставщика, отсутствие доказательств и неудачные тесты на миграцию требуют разных ответов. Бюджетный резерв должен иметь документированную цель и правила утверждения. Модель не дает количественной оценки предотвращенных потерь и не предполагает, что эти расходы создают конкретный инвестиционный доход. Любые предположения об экономии или доходах должны быть подтверждены отдельными доказательствами и согласованы со стоимостью обслуживания услуг во время интеграции.
14. Протестируйте непрерывность, прежде чем полагаться на вариант интеграции
Для каждой существенной услуги определите, что компания может предоставить, пока компонент ИИ ограничен или недоступен. Опишите альтернативный рабочий процесс, кадровые потребности и последствия для клиентов. Проверьте, разрешена ли эта альтернатива соответствующими контрактами и профессиональными требованиями. Ручной процесс должен быть протестирован с использованием репрезентативной работы и утвержденных данных. Запишите объем, который он может обработать, требуемую проверку и объем необработанной работы, который накапливается в выбранных условиях тестирования.
Отделите время технической безотказной работы от завершенного обслуживания клиентов. Приложение может быть доступно при получении результатов, которые требуют существенной коррекции или не могут быть использованы в рамках утвержденного процесса. Определите меру обслуживания, связанную с фактическим обязательством клиента. Предлагаемый тест непрерывности должен сопровождать транзакцию от ввода до проверки и доставки. Учитывайте время, необходимое для разрешения исключений, и способность нижестоящих команд выполнять дополнительную работу.
Определите точку, в которой запасной вариант становится недостаточным. Ответственное лицо должно знать, какие услуги имеют приоритет, а какие обязательства требуют эскалации. В плане интеграции должно быть указано, кто сообщает об изменениях потребителям и кто утверждает расходы на временные мощности. Предлагаемый резервный вариант остается условным до тех пор, пока не будут доступны соответствующие люди, доступ и операционные процедуры. Сохраните данные испытаний и запланируйте повторную проверку при изменении условий.
Инвестиционное обоснование должно отражать период действия как старых, так и новых механизмов. Запишите, какие затраты продолжаются и какие выгоды зависят от принятия миграции. Финансовому отделу следует бросить вызов любому предположению, что полная экономия начинается с момента юридического закрытия сделки, если базовая услуга все еще использует предыдущую среду. Предлагаемая модель обеспечивает видимость временной параллельной работы, чтобы комитет мог оценить денежные средства, необходимые для поддержки согласованного перехода.
Проверяйте доказательства непрерывности перед каждым существенным переключением. Убедитесь, что резервный вариант по-прежнему соответствует текущим данным, доступу поставщиков и штатному расписанию. В плане восстановления, написанном до реструктуризации, могут быть указаны люди, которые больше не обладают необходимыми полномочиями. В протоколе испытания должны быть указаны фактические участники и лица, принимающие решения. В заявлении комитета о приемке должны быть указаны доказательства, подтверждающие соглашение об оказании услуг, одобренное для следующего этапа.
15. Закажите интеграционный мандат с определенными границами работ
Покупатель, заказывающий внешнюю поддержку, должен определить решения, в принятии которых ему нужна помощь, и доказательства, которые необходимо предоставить. Предлагаемый мандат может охватывать сверку реестров развертываний, сравнение мер контроля, управление интеграцией и координацию плана реализации. В нем должно быть указано, какие специальные оценки проводятся консультантами соответствующей квалификации, а какие остаются за командами клиента. Соглашение должно сохранить за руководством ответственность за одобрение деятельности и принятие рисков.
Свяжите результаты с критериями приемки. Результат инвентаризации должен согласовать исходные записи, определить нерешенный объем и закрепить существенные развертывания за ответственными лицами. Структура утверждения должна быть проверена на предмет репрезентативных изменений. Рабочий поток поставщика должен фиксировать подписанные договорные условия и вопросы, по которым решение еще не принято. Процедура инцидента должна быть отработана с соответствующими участниками. В окончательном отчете должны быть указаны ограничения доказательств и действия, которые все еще необходимы для предлагаемой операционной модели.
Прежде чем делиться материалом, согласуйте условия доступа к информации, ее конфиденциальности, хранения и управления конфликтами. Консультант должен получить доступ, соответствующий его задаче и предоставленным полномочиям. Объем должен объяснять, как сообщаются результаты и как неотложные проблемы доходят до руководства. Любая дополнительная работа, выявленная во время обнаружения, должна иметь документированный процесс внесения изменений. Это позволяет клиенту согласовать стоимость и цель дальнейшего расследования еще до его начала.
Коммерческие условия должны отличать гонорар за определенную работу от расходов на внедрение, платы за программное обеспечение и гонораров специалистам. Гипотетический бюджет в этой статье не является предложением по гонорару Matchpoint Partners. Предложение, ориентированное на конкретного клиента, потребует подтверждения объема, юрисдикции, сложности развертывания и доступа к доказательствам. Ни в документе, ни в предварительном обсуждении не содержится обещаний о разрешении регулирующих органов, бесперебойной работе или финансовых результатах.
Для инвестиционного комитета полезным итогом выполнения мандата является запись решения, показывающая утвержденную операционную схему, оставшиеся условия и назначенных ответственных лиц. Эта запись может помочь в последующих проверках управления и будущей интеграции приобретений. Она должна оставаться доступной для эксплуатирующей организации после роспуска команды по проведению транзакций. Критерии выполнения мандата должны отражать согласованные результаты и фактически предоставленные доказательства.
16. Принятие документированного рабочего заключения
Комитет должен получить сверенный инвентарный список и конкретное решение об эксплуатации по каждому существенному развертыванию. Ему следует увидеть, какие системы могут продолжать работу в утвержденных пределах, какие требуют дополнительных условий и какие ждут решения, которое еще не принято. В отчете должны быть указаны доказательства, лежащие в основе этих категорий, существенные зависимости и дата, на которую был сделан каждый вывод. Совокупные проценты выполнения должны сопровождаться последствиями невыполненных задач.
Утвердите последовательность интеграции, используя условия приемки, подкрепленные тестами и ответственным утверждением. Сохраните возможность ограничить конкретную функцию, когда ее условия больше не удовлетворяются. Обеспечьте видимость непрерывности работы клиентов, юридических обязательств и полномочий по инцидентам на протяжении всего перехода. Техническая консолидация может продолжаться, когда предлагаемая среда имеет необходимые разрешения, доказательства оценки и операционную поддержку. Любое остающееся разделение должно иметь документально подтвержденную причину и условие проверки.
Гипотетические расчеты иллюстрируют два различных вопроса управления. Сверка реестра определяет совокупность развертываний, требующих управления, тогда как бюджет реализации определяет расходы в соответствии с выбранными предположениями по объему и срокам. Ни один из расчетов не определяет фактическую готовность к развертыванию или коммерческую ценность. Комитет по приобретению должен заменить эти предположения доказательствами транзакции, прежде чем использовать этот метод для утверждения ресурсов или оценки варианта интеграции.
Предлагаемая структура завершается назначением постоянного ответственного за объединенный процесс управления, ведением учета утвержденных видов использования и рабочим маршрутом для внесения изменений и принятия решений по инцидентам. Ее эффективность требует подтверждения в ходе эксплуатации и анализа. Поэтому следующее инвестиционное решение должно включать стоимость и ответственность за поддержание системы после завершения первоначальной программы интеграции.
Приложение A. Минимальные доказательства для принятия решения о развертывании
В предлагаемой записи о развертывании должно быть указано юридическое лицо, ответственный со стороны бизнеса, утвержденная цель и производственная среда. Сохраните исходные идентификаторы каждой компании и идентификатор группы, использованный после сверки. Свяжите соответствующую модель или версию сервиса, конфигурацию приложения и зависимости. Запишите дату проверки фактов эксплуатации и лицо, проводившее эту проверку. Если обнаружение остается неполным, опишите недостающие доказательства и их последствия для решения.
В разделе утверждения должна быть указана применимая внутренняя политика, а также юридические или договорные условия, предоставленные соответствующими консультантами. Прикрепите результаты оценки с указанием объема испытаний, знаменателей и ограничений. Опишите меры мониторинга, пороговые значения реагирования и механизмы проверки человеком. Зафиксируйте утвержденные возможности действий и ограничения доступа к данным. В решении должно быть указано санкционирующее лицо, дата вступления в силу, условия истечения срока действия или пересмотра, а также изменения, требующие повторной оценки.
В разделе о непрерывности следует описать резервный вариант, его проверенную пропускную способность и лицо, уполномоченное его активировать. Свяжите маршрут инцидента, схему поддержки поставщиков и процедуру сохранения доказательств. В решении о восстановлении должны быть указаны тесты и утверждения, необходимые для возобновления затронутых функций. Следите за тем, чтобы операционная документация соответствовала текущему штатному расписанию и контрактным соглашениям. Учение по передаче ответственности должно подтвердить, что постоянный ответственный может найти доказательства и выполнить необходимые действия.
Приложение Б. Воспроизведение гипотетических расчетов
Инвентаризация начинается со 100 записей от компании A и 80 от компании B. Вычтите 15 повторяющихся административных записей и 25 развертываний, вывод которых из эксплуатации подтвержден, затем добавьте 12 вновь обнаруженных активных развертываний. Результат — 152 активных развертывания. Три показательные категории одобрения включают 82 с полными доказательствами, 50 с условным одобрением и 20, ожидающие решения. Всего в первых двух категориях — 132; деление на 152 дает 86,8421%, отображается как 86,8%.
Категории трудоёмкости оценки представляют собой отдельную классификацию тех же 152 развёрнутых приложений. Умножьте 32 на USD 4,000, 60 на USD 2,000 и 60 на USD 500, чтобы получить предполагаемые расходы на оценку в размере USD 278,000. Добавьте USD 180,000 на общую подготовку и шесть месяцев по USD 35,000 в месяц; итог составит USD 668,000. Три дополнительных месяца и восемь повторных углублённых оценок добавляют USD 137,000. Расходы после продления составляют USD 805,000. Дисконтирование, взвешивание по вероятностям, поправки на инфляцию и расчёт налогов не включены.
Источники
- Национальный институт стандартов и технологий. Рамочная система управления рисками искусственного интеллекта, AI RMF 1.0, NIST AI 100-1, январь 2023 г. Добровольный документ; результаты в области управления, описания контекста, измерения и обработки рисков. Прочтите первоисточник
- Национальный институт стандартов и технологий. Рамочная система управления рисками искусственного интеллекта: профиль генеративного искусственного интеллекта, NIST AI 600-1, июль 2024 г. Зависимости от третьих сторон, доступ к контенту организации и интеграция цепочки создания стоимости. Прочтите первоисточник
- Национальный институт стандартов и технологий. Рекомендации по реагированию на инциденты и соображения по управлению рисками кибербезопасности: Профиль сообщества CSF 2.0, SP 800-61r3, апрель 2025 г. Полномочия по инцидентам, координация с третьими сторонами, восстановление и улучшение. Прочтите первоисточник
- Евросоюз. Регламент (ЕС) 2024/1689, сводный текст от 27 июля 2026 г. Статьи 25, 26 и 113; положения, специфичные для ролей, и правила применения требуют оценки с учетом специфики транзакции. Прочтите первоисточник
- Европейская комиссия. Сроки внедрения и применения Регламента об искусственном интеллекте. Текущий официальный обзор; дата обращения: 10 сентября 2026 г. Прочтите первоисточник
- Управление данных и искусственного интеллекта Саудовской Аравии. Принципы этики искусственного интеллекта. Подотчетность, мониторинг и комплексная проверка третьих сторон; дата обращения: 10 сентября 2026 г. Прочтите первоисточник
- Офис государственного министра ОАЭ по вопросам искусственного интеллекта, цифровой экономики и приложений для удаленной работы. Хартия ОАЭ по развитию и использованию искусственного интеллекта, июль 2024 г. Прочтите первоисточник
