Безопасность ИИ-продуктов
Когда ИИ-продукту пора остановиться и позвать человека.
ИИ-функция может отвечать по-разному в похожих ситуациях. До запуска нужно разобраться, какой риск допустим, что именно проверяем и когда спорное решение обязательно передаём человеку.
Сигнал
Функция уже приносит пользу, но правила работы с её непредсказуемыми ответами ещё не заданы.
Пока команда не согласовала условия выпуска и передачи решения человеку, риск может незаметно лечь на пользователей, операторов или сам бизнес.
Почему работа застревает
Проблемы начинаются, когда команда считает пользу продукта достаточным основанием для запуска.
Система часто выдаёт удачный результат и нравится участникам проекта. Но что делать с пограничным случаем, когда её останавливать и кому передавать решение, по-прежнему неясно.
С чего начинаю проверку
Сначала разбираю условия, при которых функцию допустимо выпустить к пользователям.
С чего начинаю проверку
- Ситуация
ИИ-функция готовится к запуску, а согласованной оценки риска ещё нет.
- Ограничение
Команда может показать пользу. За неоднозначные случаи между успехом и сбоем при этом никто не отвечает.
- Решение
Задать условия выпуска одной функции: что нужно проверить, когда передать решение человеку и когда отказать.
- Что изменилось
У функции появляются более безопасные и понятные условия выпуска.
Что можно изменить за один шаг
Берём один участок продукта и задаём для него конкретные условия безопасного запуска.
Риском можно управлять, если до запуска воспроизвести сбой и ограничить его последствия, а проверку включить в обязательные условия релиза.
Кейс показывает инженерную работу над безопасностью собственного продукта. Он не подтверждает клинический эффект, результат клиентского проекта или применимость правил к любому продукту.
- Контекст
- Безопасность ИИ-продукта перед запуском и ответственность за его работу.
- Период
- Запись из практики автора
- Роль
- Operational CTO
- Источник
- Кейс о риске продукта
- Откуда данные
- Материалы автора с оговорками к выводам. Часть данных нельзя раскрывать.
- Надёжность данных
- Источник подтверждает этот случай. Более широкие выводы нужно отдельно проверить и согласовать.
- Ограничения публикации
- Клиент не назван. Неподтверждённые показатели не приводятся.
Связанные кейсы
Что показывает практика
Безопасность ИИ-продуктов
До запуска ИИ-продукта обнаружилась возможность доступа к секретам. Оставлять её к выходу пользователей было нельзя.
- Решение
- Воспроизвести проблему и включить детерминированную проверку в обязательные условия релиза.
- Результат
- Опасный доступ закрыли до публичного запуска.
- Роль
- Operational CTO
ИИ в разработке
Системе нужна была надёжная модель до расширения автоматических решений.
- Решение
- Собрать общую картину системы до расширения самостоятельных решений продукта.
- Результат
- Оценивать риск стало возможно по проверяемым данным о системе.
- Роль
- Operational CTO
Надёжность и безопасность
Реальная нагрузка показала, как быстро система ломается, если неясно, когда должен вмешаться человек.
- Решение
- Определить, что под нагрузкой система делает автоматически, а где решение принимает человек.
- Результат
- Стало понятнее, когда система действует сама, а когда передаёт решение человеку.
- Роль
- Operational CTO
Field Notes
Заметки, которые помогут разобраться
Когда ИИ-продукту пора остановить разговор
ИИ может пропустить признак риска и продолжить разговор как ни в чём не бывало. Разбираю, что проверять в таком диалоге и когда его нужно прервать.
Открыть заметкуАгент советует, инженер решает
ИИ-агент уверенно отвечает и при этом может ошибаться. Как поручить ему поиск проблем в коде, а проверку решения оставить человеку.
Открыть заметкуFit / No-fit
Когда формат подходит
Подходит
- Функция готовится к запуску, и нужно определить условия её безопасной работы.
- Руководство готово предусмотреть отказ или откат, а в спорных случаях передавать решение человеку.
- Команда готова показать процесс, в котором польза продукта связана с риском.
Не подходит
- Нужен только общий текст политики об ИИ.
- Компания хочет назвать продукт безопасным, но не готова вводить обязательные проверки перед выпуском.
- Никто не готов принимать решение, когда система попадает в неоднозначную ситуацию.
Activation Sprint
Начать с Activation Sprint
В первом проекте задаём условия выпуска одной функции и порядок передачи спорных случаев человеку. За следующие решения отвечает конкретный участник команды.
Neutral start
Расскажите, где видите риск
Если риск уже виден, но его трудно описать точно, расскажите о ситуации своими словами. Формат работы выберем после этого.