NIST AI RMF: управление рисками ИИ и план на 30 дней

На вопрос «Следуете ли вы NIST AI RMF?» отвечайте фактами о том, как устроено управление рисками ИИ в конкретной системе: кто за них отвечает, что вы проверили, какие действия разрешили системе и что делаете при сбое. NIST AI RMF включает 4 функции, а его применение добровольное; за первые 30 дней стоит наладить рабочий процесс управления рисками и честно зафиксировать его пробелы. Структуру задаёт NIST AI RMF.

AI Risk Management Framework (AI RMF) от National Institute of Standards and Technology (NIST) помогает организациям учитывать риски для людей, организаций и общества при проектировании, разработке, внедрении и использовании ИИ. Область его применения шире самой модели: значение имеют и люди, и данные, и права доступа, и условия работы системы. Этот подход описан в AI RMF 1.0.

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

Источники проверены: 26 октября 2026 года. Рамочный документ, Playbook и Generative AI Profile сверены с действующими страницами и публикациями NIST. На странице NIST AI RMF сказано, что AI RMF 1.0 пересматривается, при этом ссылка по-прежнему ведёт на эту версию. Это сообщение не означает, что новая версия уже опубликована или что объявлена дата её выхода.

Как устроен NIST AI RMF

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

NIST AI 100-1: основной документ

NIST AI 100-1 — идентификатор публикации AI RMF 1.0, выпущенной 26 января 2023 года. В первой части рассматриваются риск и характеристики, позволяющие доверять системе; во второй — ядро, Core, и профили, Profiles. Core объединяет управление рисками в функции Govern, Map, Measure и Manage, каждая из которых включает категории и подкатегории. Они описывают результаты и действия, а не универсальный аудиторский чек-лист с вердиктом «пройдено / не пройдено». Рамочный документ и сведения о выпуске NIST; AI RMF 1.0, части 1 и 2.

К характеристикам, от которых зависит доверие к ИИ, относятся валидность и надёжность работы системы; её безопасность; защищённость и устойчивость; подотчётность и прозрачность; объяснимость и интерпретируемость; защита приватности; справедливость при контроле предвзятости, способной причинить вред. Один лишь гладко сформулированный ответ ничего из этого не подтверждает. NIST рассматривает эти характеристики и компромиссы между ними в разделе 3 AI RMF 1.0.

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

NIST AI RMF Playbook: как выбрать подходящие меры

NIST AI RMF Playbook дополняет Core рекомендуемыми действиями, ссылками и пояснениями о том, как достичь описанных результатов. NIST прямо разрешает организациям выбирать подходящие им рекомендации и не ожидает, что каждая организация выполнит их все. Playbook не задаёт последовательность шагов в чек-листе. NIST Playbook; вопросы и ответы о NIST Playbook.

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

Четыре функции: какие записи нужны небольшой команде

Рассматривайте функции во взаимосвязи. Govern охватывает Map, Measure и Manage, а работа повторяется и уточняется на протяжении жизненного цикла ИИ. После теста, выявившего новый риск, может понадобиться пересмотреть контекст; после инцидента — изменить политику. NIST не предписывает двигаться по этапам только в одну сторону. NIST AI RMF Core.

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

Идентификаторы и описания результатов взяты из таблиц функций NIST Core. Это выбранные опорные пункты; таблица не претендует на охват всех подкатегорий.

Govern: дайте ответственному право остановить систему

Govern задаёт политики, ответственность и культуру, необходимые для управления рисками. В эту функцию NIST включает документированные роли, ответственность руководства, обучение сотрудников и контроль со стороны человека. NIST Core, Govern.

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

Рабочее правило контроля со стороны человека может выглядеть так: «Ассистент может готовить черновики ответов на основе утверждённых материалов поддержки. Перед отправкой сотрудник поддержки обязан проверить источник и получателя. Ассистент не имеет права оформлять возвраты средств или менять доступ к учётным записям. Руководитель поддержки может отключить его; для возобновления работы нужны ответственный инженер и руководитель поддержки».

Это пример того, как можно организовать процесс. Для другого рабочего процесса могут быть оправданны иные полномочия. Главное, чтобы реальные права доступа и порядок проверки соответствовали правилу.

Map: опишите функцию продукта, а не только модель

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

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

Затем опишите риск через причину, событие и последствие: «Из-за ошибки в фильтре учётной записи извлекается обращение другого клиента; ассистент включает его в черновик; проверяющий отправляет конфиденциальные сведения не тому клиенту». Формулировка «риск для приватности» сама по себе не объясняет инженеру, что исправлять.

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

Measure: проверяйте именно тот риск, который описали

Measure использует количественные, качественные или смешанные методы для оценки рисков и характеристик доверия. NIST включает сюда тестирование в условиях, близких к эксплуатации, документирование ограничений и оценку таких аспектов, как защищённость, приватность и предвзятость, причиняющая вред. NIST Core, Measure.

Для ассистента поддержки подготовьте сценарии с обычным вопросом, отсутствующим исходным материалом, противоречащими друг другу правилами, записями другого клиента и вредоносной инструкцией внутри найденного текста. Промпт-инъекция — это попытка злоумышленника передать инструкции, которые перенаправят поведение системы; в разделе 2.9 Generative AI Profile NIST рассматриваются и прямые атаки, и атаки через материалы, извлекаемые системой.

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

Определите критерии приёмки до просмотра результатов. В нашем примере раскрытие данных одного клиента другому блокирует выпуск, даже если остальные ответы выглядят хорошо. Это предложенное нами правило выпуска, а не порог, установленный NIST. Небольшой набор тестов способен обнаружить сбой; успешное прохождение не доказывает, что сбои невозможны.

Manage: превращайте результаты проверок в решения

Manage определяет приоритеты рисков и распределяет ресурсы для работы с ними. NIST включает сюда решения о продолжении разработки или развёртывания, варианты действий — например, снижение или принятие риска, — механизмы отключения систем, постоянный мониторинг и реагирование на инциденты. NIST Core, Manage.

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

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

NIST AI 600-1: что добавляет Generative AI Profile

NIST AI 600-1, или Generative Artificial Intelligence Profile, применяет NIST AI RMF к рискам, которые характерны именно для генеративного ИИ либо усиливаются при его использовании. Документ опубликован 26 июля 2024 года и дополняет AI RMF 1.0. Он не заменяет основной рамочный документ и не вводит отдельную сертификацию. Страница публикации NIST.

Профиль выделяет 12 областей риска и предлагает действия, соотнесённые с NIST AI RMF. При его разработке основное внимание уделялось управлению, происхождению контента, тестированию до развёртывания и раскрытию сведений об инцидентах. Происхождение контента — это сведения о том, откуда он взялся и какова его история. Эти аспекты помогают связать генерируемые результаты с рабочими процессами, в которых закреплена ответственность. NIST AI 600-1, введение, раздел 2 и приложение A.

Для ассистента поддержки начните с преобразования актуальных рисков в конкретные сценарии сбоев:

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

Это примеры внедрения на основе описаний рисков из профиля, а не сокращённый официальный чек-лист. Остальные названные области — информация или возможности в химической, биологической, радиологической или ядерной сфере (CBRN); опасный контент, контент с насилием или разжиганием ненависти; воздействие на окружающую среду; целостность информации; интеллектуальная собственность; непристойный, унижающий достоинство и/или оскорбительный контент. Оцените, насколько они применимы к вашей системе, и зафиксируйте обоснование. Полные определения приведены в разделе 2 NIST AI 600-1.

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

Первые 30 дней: план внедрения NIST AI RMF

Цель — показать работающий процесс в чётко определённых границах. Этот график — наша рекомендация, а не срок NIST, уровень зрелости или гарантия завершения работы. Поддерживайте управление на всём протяжении внедрения: календарь помогает организовать первый месяц, но не задаёт обязательную последовательность функций NIST AI RMF.

1. 1

   Дни 1-5: определите границы и ответственных

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

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

   Сохраните: первоначальный реестр, закреплённые обязанности и правило контроля со стороны человека, сверенное с реальными правами доступа функции.

2. 2

   Дни 6-10: опишите сбои и выберите меры

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

   Внесите сценарии причинения вреда в реестр рисков. Проверьте полноту списка с помощью Generative AI Profile. Расставьте приоритеты с учётом возможных последствий, вероятности и неопределённости; назначьте ответственного за меры по каждому риску. Решите, какие сбои блокируют выпуск, а какие требуют сузить область применения.

   Сохраните: описание системы, реестр рисков, выбранные меры, перечень недостающих подтверждений и предлагаемые критерии приёмки.

3. 3

   Дни 11-20: проверьте конфигурацию для эксплуатации

   Выполните типовые сценарии, сценарии сбоев и атак на конфигурации, которую собираетесь использовать. Зафиксируйте идентификаторы модели или сервиса, промпты, настройки поиска и права инструментов в той мере, в какой они доступны. Если поставщик скрывает значимую деталь, отразите это ограничение в оценке.

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

   Сохраните: протоколы оценки с версиями, нерешённые проблемы и ссылки на связанные риски. Не выдавайте непроверенное предположение за успешно пройденную проверку.

4. 4

   Дни 21-30: примите решение, проведите учения и подготовьте отчёт

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

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

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

Обучение NIST AI RMF: отработайте принятие решений

Обучайте людей тем решениям, за которые они отвечают. GOVERN 2.2 касается обучения сотрудников и партнёров управлению рисками; результат — способность выполнять свои обязанности. NIST Core, Govern.

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

NIST также описывает Current Profiles и Target Profiles — текущие и целевые профили, которые отражают существующие и желаемые результаты управления рисками. Их сравнение показывает оставшуюся работу. Небольшая компания может использовать это различие в указателе подтверждающих материалов: внедрено, частично внедрено, запланировано или неприменимо с обоснованием. Эти обозначения статусов предлагаем мы. AI RMF 1.0, раздел 6.

Что сообщить клиенту, аудитору или совету директоров

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

Если внедрение ещё идёт, скажите об этом прямо. Например:

Мы внедряем практики NIST AI RMF для нашего ассистента клиентской поддержки. Ответственные назначены, реестр систем и оценка рисков подготовлены. Проверки и учения по реагированию на инциденты ещё не завершены. Пока соответствующие решения не приняты, функция остаётся в существующих ограниченных границах применения.

Если практики уже работают и это подтверждено записями, можно ответить подробнее:

Мы используем NIST AI RMF 1.0 для организации управления рисками нашего ассистента клиентской поддержки и применяем подходящие меры из Generative AI Profile. Мы поддерживаем правила ответственности и контроля, ведём записи о системах и рисках, сохраняем результаты оценок и используем процедуры реагирования на инциденты. В описании охвата указаны оценённые конфигурации, известные ограничения, незавершённые действия и следующий пересмотр. Это описание нашего внедрения, а не сертификация NIST.

Эти примеры нужно адаптировать к вашим реальным подтверждениям. Не копируйте более сильную формулировку, пока лежащие в её основе меры остаются только в планах.

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

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

Что стоит изменить разработчикам, эксплуатационным командам и покупателям

Разработчикам: рассматривайте новые полномочия как изменение проектного решения. Если ассистенту, который готовит черновики, разрешить возврат средств, риск изменится, даже когда модель и промпт остаются прежними. До включения этой возможности обновите описание системы, тесты прав доступа и решение о согласовании.

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

Покупателям и основателям: запрашивайте границы проведённой оценки, свежие результаты проверок и оставшиеся ограничения. В заявлении поставщика о следовании NIST AI RMF должно быть понятно, что контролирует он, а что предстоит настроить или отслеживать вам.

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

Пересмотр NIST AI RMF не устраняет уже известные риски. Продолжайте управлять ими и явно указывайте в документации используемую версию.

Как соотносятся NIST AI RMF, ISO/IEC 42001 и EU AI Act

Используйте эти документы с учётом их разных задач. ISO/IEC 42001:2023 устанавливает требования к системе менеджмента ИИ в организации. Организации могут пройти независимую сертификацию такой системы менеджмента; сама ISO сертификатов не выдаёт. Обзор стандарта от ISO; разъяснение ISO о сертификации.

European Union AI Act устанавливает юридические обязанности в зависимости от роли участника, системы и её применения. Записи, подготовленные в рамках AI RMF, могут помочь в этой работе, но следование NIST AI RMF не доказывает соблюдение закона. Применимые правила и сроки проверяйте в руководстве Европейской комиссии по AI Act, а связанные материалы сайта — на нашей странице об EU AI Act.

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

Завышенные ожидания: сертификаты, проценты выполнения и безопасные модели

Главное преувеличение — утверждать, что принятие NIST AI RMF доказывает безопасность системы. Рекомендации NIST помогают организовать управление рисками; значимые подтверждения по-прежнему относятся к конкретной системе, контексту и решениям. В Core прямо заложены гибкость и повторение работы с учётом новых результатов. NIST AI RMF Core.

Сертификация по NIST AI RMF не означает сертификат от NIST

NIST не сертифицирует организации на соответствие AI RMF. Описывайте своё внедрение, его охват и подтверждающие материалы; не заявляйте, что вы «сертифицированы NIST». Независимая оценка может быть полезна, но в отчёте должно быть указано, кто, что и по каким критериям проверял. От этого отчёт не становится сертификатом, выданным NIST. Официальная отправная точка — добровольный AI RMF от NIST.

Заполненный чек-лист не заменяет решения о риске. NIST не задаёт универсальную допустимую величину риска, а Playbook не требует выполнять все предложенные действия. Выберите критерии приёмки с учётом возможного вреда и объясните их. AI RMF 1.0, раздел 1.2.2; рекомендации Playbook.

Подтверждения поставщика не охватывают всё ваше приложение. Данные для поиска, средства контроля доступа, интеграции и пользователи добавляют собственный контекст. NIST прямо рассматривает сторонние компоненты и постоянное управление ими; сохраняйте материалы поставщика и одновременно проверяйте собственную рабочую конфигурацию. NIST Core, Map и Manage.

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

Частые вопросы

Зачем нужен AI RMF?

Риски ИИ возникают во взаимодействии технологий, людей и условий эксплуатации. NIST AI RMF помогает организациям управлять этим взаимодействием на всём жизненном цикле, в том числе учитывать последствия для людей, которые не являются непосредственными пользователями. Это добровольный инструмент, а не требование закона о его внедрении. NIST AI RMF 1.0.

Какие 5 рисков связаны с ИИ?

Для функции на основе генеративного ИИ можно привести пять примеров: неверные, но уверенные ответы; утечка конфиденциальных данных; предвзятость, причиняющая вред; чрезмерное доверие людей к системе; атаки, перенаправляющие её поведение. Они соответствуют областям, рассмотренным в Generative AI Profile, но не составляют полный список рисков из профиля. NIST AI 600-1, раздел 2.

Какова главная цель NIST Risk Management Framework (RMF)?

Если речь об AI RMF, который рассматривается здесь, цель — помочь организациям управлять рисками ИИ и учитывать характеристики доверия при разработке и использовании. В ответе клиенту уточняйте «AI RMF», чтобы было понятно, какой именно рамочный документ вы имеете в виду. Обзор NIST AI RMF.

Обязательно ли применять NIST AI RMF?

Сам NIST AI RMF доброволен. Отдельно проверьте договорные, закупочные и юридические обязательства, применимые к вашему бизнесу: принятие добровольного рамочного документа не решает вопрос об их исполнении. Обзор NIST AI RMF.

Что придёт на смену RMF?

На странице NIST об AI RMF, проверенной 26 октября 2026 года, сказано, что версия 1.0 пересматривается; ссылка по-прежнему ведёт на неё. Из этого сообщения нельзя заключить, что новая версия уже вышла. NIST AI 600-1 — дополнительный Generative AI Profile. Страница NIST AI RMF.

Заменит ли ИИ управление финансовыми рисками (FRM)?

Из AI RMF нельзя сделать вывод, будет ли работа по управлению финансовыми рисками заменена ИИ. Этот документ посвящён тому, как организации управляют рисками ИИ, в том числе обязанностям людей и контролю с их стороны; он не содержит прогноза о замене профессии. NIST Core, Govern.

Какие 3 подхода к кибербезопасности считаются лучшими?

Универсальной тройки лидеров для всех организаций нет. Выбирайте рекомендации по кибербезопасности с учётом своих систем, обязательств и требований к подтверждению защищённости. В этом контексте используйте AI RMF для работы со специфическими рисками ИИ вместе с существующей программой безопасности; предусмотренные им результаты в области защищённости и устойчивости не охватывают всю функцию кибербезопасности. NIST AI RMF 1.0.

Уходит ли кибербезопасность в прошлое?

Внедрение ИИ не устраняет потребность в работе по обеспечению безопасности. AI RMF включает оценку защищённости и устойчивости, управление рисками третьих сторон и реагирование на инциденты. Для команды, эксплуатирующей систему, это по-прежнему обязанности, которые нужно распределить и подтвердить их выполнение. Это следствие для организации работы, а не прогноз рынка труда. NIST Core.

Какая угроза кибербезопасности сегодня №1?

Ни одну угрозу нельзя поставить на первое место для всех компаний. Приоритет отдавайте тому, что может причинить вред в ваших условиях эксплуатации. В примере с ассистентом поддержки несанкционированный доступ к данным и промпт-инъекции требуют отдельных тестов; их приоритет зависит от данных и доступных полномочий. NIST Generative AI Profile, раздел 2.9.

С чего начать в понедельник

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

Так у следующего ответа клиенту появится конкретная основа: какая система входит в охват, какие подтверждения уже есть и что ещё предстоит сделать.

Практические заметки о внедрении ИИ в рабочие продукты — в рассылке.