Аудит ИИ-систем: что проверить перед запуском и после него

Аудит отвечает на вопрос, можно ли подтвердить заявленное поведение системы воспроизводимыми доказательствами. Для автономных действий отдельно используйте безопасность ИИ-агентов, для чат-бота — тестирование AI-чат-бота. Здесь объект шире: данные, модель, интерфейс, интеграции, люди и эксплуатационный процесс.

Для структуры риска используйте ресурсы NIST AI RMF. Связь общего управления и оценки воздействия описывает официальный обзор ISO по 42001 и 42005.

Зафиксируйте границы аудита

Аудитор рассматривает компоненты, версии, среды и решения системы как отдельный объект проверки.

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

Типовой дефект — проверка одной модели выдаётся за аудит продукта. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

Доказательство — схема контура и список исключений. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает руководитель аудита, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает одинаковое понимание объекта всеми участниками. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «компоненты, версии, среды и решения системы» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «одинаковое понимание объекта всеми участниками».

Проверьте назначение

Аудитор рассматривает заявленные пользователи и допустимые решения как отдельный объект проверки.

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

• Опишите заявленные пользователи и допустимые решения одним предложением без названия продукта.
• Зафиксируйте риск: систему применяют в более опасном сценарии.
• Сохраните подтверждение: карточка назначения и запрещённых применений.
• Назначьте роль «владелец продукта» и дату повторной проверки.

Доказательство — карточка назначения и запрещённых применений. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает владелец продукта, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

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

В материалы по теме «заявленные пользователи и допустимые решения» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «граница, которую можно проверить в интерфейсе и процессе».

Исследуйте происхождение данных

Аудитор рассматривает источники, права, отбор и преобразования как отдельный объект проверки.

• Опишите источники, права, отбор и преобразования одним предложением без названия продукта.
• Зафиксируйте риск: качество оценивают без знания выборки.
• Сохраните подтверждение: паспорт данных и журнал подготовки.
• Назначьте роль «владелец данных» и дату повторной проверки.

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

Доказательство — паспорт данных и журнал подготовки. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает владелец данных, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает прослеживаемый путь от источника к входу модели. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «источники, права, отбор и преобразования» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

Отдельно запишите остаточный риск «качество оценивают без знания выборки» и того, кто его принял.

Запись удерживает дефект между версиями отчёта до достижения результата «прослеживаемый путь от источника к входу модели».

Соберите независимый набор тестов

Аудитор рассматривает типовые, редкие и опасные случаи как отдельный объект проверки.

Типовой дефект — разработчики проверяют на примерах из обучения. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

• Опишите типовые, редкие и опасные случаи одним предложением без названия продукта.
• Зафиксируйте риск: разработчики проверяют на примерах из обучения.
• Сохраните подтверждение: зафиксированная выборка до испытания.
• Назначьте роль «команда качества» и дату повторной проверки.

Доказательство — зафиксированная выборка до испытания. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает команда качества, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает повторяемое сравнение версий. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «типовые, редкие и опасные случаи» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «повторяемое сравнение версий».

Считайте качество по сегментам

Аудитор рассматривает разные языки, форматы и группы пользователей как отдельный объект проверки.

• Опишите разные языки, форматы и группы пользователей одним предложением без названия продукта.
• Зафиксируйте риск: средняя метрика скрывает провал меньшинства.
• Сохраните подтверждение: таблица результатов и доверительных интервалов.
• Назначьте роль «аналитик» и дату повторной проверки.

Типовой дефект — средняя метрика скрывает провал меньшинства. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

Доказательство — таблица результатов и доверительных интервалов. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает аналитик, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает видимые различия вместо одного среднего числа. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «разные языки, форматы и группы пользователей» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

Отдельно запишите остаточный риск «средняя метрика скрывает провал меньшинства» и того, кто его принял.

Запись удерживает дефект между версиями отчёта до достижения результата «видимые различия вместо одного среднего числа».

Проверьте защиту от злоупотребления

Аудитор рассматривает вредоносный ввод, обход правил и утечка как отдельный объект проверки.

Типовой дефект — обычный тест не касается поведения атакующего. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

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

Доказательство — сценарии атак и сохранённые ответы. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

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

Закрытие пункта означает известные ограничения и меры снижения. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «вредоносный ввод, обход правил и утечка» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

Отдельно запишите остаточный риск «обычный тест не касается поведения атакующего» и того, кто его принял.

Запись удерживает дефект между версиями отчёта до достижения результата «известные ограничения и меры снижения».

Оцените человеческий контроль

Аудитор рассматривает момент проверки, остановки и обжалования как отдельный объект проверки.

• Опишите момент проверки, остановки и обжалования одним предложением без названия продукта.
• Зафиксируйте риск: оператор формально присутствует, но не видит оснований.
• Сохраните подтверждение: сценарий вмешательства и время реакции.
• Назначьте роль «владелец операции» и дату повторной проверки.

Типовой дефект — оператор формально присутствует, но не видит оснований. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

Доказательство — сценарий вмешательства и время реакции. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает владелец операции, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает реальная возможность изменить решение. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «момент проверки, остановки и обжалования» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «реальная возможность изменить решение».

Проверьте журналирование

Аудитор рассматривает вход, версия, действие, подтверждение и результат как отдельный объект проверки.

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

• Опишите вход, версия, действие, подтверждение и результат одним предложением без названия продукта.
• Зафиксируйте риск: инцидент невозможно воспроизвести.
• Сохраните подтверждение: пример полного события без лишних данных.
• Назначьте роль «администратор платформы» и дату повторной проверки.

Доказательство — пример полного события без лишних данных. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает администратор платформы, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает достаточная трассировка с ограниченным доступом. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

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

Следующая проверка повторяет действие без пояснения автора.

Отдельно запишите остаточный риск «инцидент невозможно воспроизвести» и того, кто его принял.

Запись удерживает дефект между версиями отчёта до достижения результата «достаточная трассировка с ограниченным доступом».

Сверьте эксплуатацию с документацией

Аудитор рассматривает текущая конфигурация и фактические интеграции как отдельный объект проверки.

• Опишите текущая конфигурация и фактические интеграции одним предложением без названия продукта.
• Зафиксируйте риск: аудитор читает устаревшую архитектурную схему.
• Сохраните подтверждение: автоматическая выгрузка настроек и выборка журналов.
• Назначьте роль «технический владелец» и дату повторной проверки.

Типовой дефект — аудитор читает устаревшую архитектурную схему. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

Доказательство — автоматическая выгрузка настроек и выборка журналов. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает технический владелец, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает совпадение описания с рабочей средой. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

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

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «совпадение описания с рабочей средой».

Составьте план исправлений

Аудитор рассматривает приоритет, владелец, срок и повторный тест как отдельный объект проверки.

Типовой дефект — отчёт заканчивается перечнем наблюдений. Устное объяснение разработчика не заменяет воспроизводимый тест и сохранённый результат.

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

Доказательство — реестр находок с критерием закрытия. Выберите выборку до запуска проверки и сохраните как успешные, так и неуспешные случаи.

За исправление отвечает руководитель программы, а повторную проверку выполняет другой участник, если риск влияет на клиента, деньги или доступ к данным.

Закрытие пункта означает проверенные исправления и принятый остаточный риск. Формулировка «принято к сведению» без срока и критерия закрытием не считается.

В материалы по теме «приоритет, владелец, срок и повторный тест» добавьте точную команду, снимок настройки или идентификатор теста.

Следующая проверка повторяет действие без пояснения автора.

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

Запись удерживает дефект между версиями отчёта до достижения результата «проверенные исправления и принятый остаточный риск».

Карта ответственности

Что изучить дальше

• безопасность ИИ-агентов
• тестирование AI-чат-бота
• prompt injection
• галлюцинации нейросетей
• политика использования ИИ
• база знаний компании
• обезличивание документа

Чек-лист