Guardrails AI-ассистента в мобильном приложении

Guardrails AI в мобильном приложении: где ассистент ломается

Ассистент в мобильном приложении ломается не там, где его тестировали. В демо модель отвечает на подготовленные вопросы, а в проде пользователи приносят формулировки, которых не было ни в одном сценарии: обходят фильтры перефразом, просят «показать твои инструкции», подталкивают к действиям, на которые у ассистента нет прав. Guardrails AI — это слой правил вокруг модели, который решает три задачи: не дать выдать запрещённое, не дать выдумать факт и не дать выполнить операцию без подтверждения человека.

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

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

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

Что даёт управляемый ассистент: эффект в метриках

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

Дальше эффект раскладывается по классам отказов, и каждый закрывается своей проверкой:

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

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

Время восстановления после инцидента зависит от того, насколько правила отделены от кода приложения. Когда они вынесены в конфигурацию, правка занимает минуты и не требует нового релиза — стоимость простоя падает кратно, а не на проценты. Именно этот запас прочности и есть практический смысл управляемого ассистента: сбой локализуется, откатывается и разбирается без остановки продукта.

Подходы к ограничению: сравнение режимов работы

Ограничения ИИ-ассистента можно ставить в четырёх точках: до генерации, после неё, на уровне среды исполнения и на уровне человека. Комбинировать их приходится почти всегда — каждый режим закрывает свой класс рисков и оставляет свой класс дыр. Ниже — честное сравнение, включая случаи, когда режим не подходит.

Как режимы сочетаются

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

Ручная модерация не заменяет автоматику, а дополняет её: она разбирает спорные случаи, которые правила не классифицировали, и по итогам разбора правила уточняются. На практике рабочая схема — вход, выход и изоляция на автоматике, а человек подключается к очереди инцидентов и к темам, где цена ошибки высока.

Выбор режима — это выбор между задержкой ответа, полнотой сценариев и стоимостью поддержки. Мы разбираем ваш сценарий и подбираем комбинацию под него, а не «самую безопасную» из абстрактных соображений.

Как мы внедряем ограничения: этапы работы

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

1. Аудит сценариев. Проходим по всем точкам, где пользователь общается с ассистентом: чат, подсказки в формах, генерация текста, ответы на вопросы по данным. Для каждого сценария выписываем, какие действия допустимы, какие данные попадают в запрос и что считается недопустимым ответом.
2. Схема политик. Сводим сценарии в единую карту правил: тематические ограничения, запрет на выдачу персональных данных, требования к тону и формату ответа, поведение при неуверенности модели. Схема согласуется с продуктом и юристами до написания кода.
3. Настройка проверок. Реализуем фильтры на входе и выходе: проверка запроса до отправки в модель и валидация ответа перед показом пользователю. Правила держим декларативно — их можно менять без пересборки приложения.
4. Тесты на устойчивость. Прогоняем наборы попыток обойти ограничения: переформулировки, смена языка, вставка инструкций в пользовательский текст. Фиксируем, сколько попыток блокируется и какие ответы уходят в ручную проверку.
5. Выпуск в прод. Включаем ограничения поэтапно: сначала на части пользователей, с логированием срабатываний и метриками отказов. Если доля ложных блокировок растёт, правила корректируются до полного включения.
6. Передача команде. Отдаём документацию по политикам, инструкцию по добавлению новых правил и регламент пересмотра при изменении продукта — чтобы ограничения поддерживались без нас.

Такой порядок даёт предсказуемый результат: ассистент остаётся полезным, а поведение за пределами разрешённого закрывается на уровне приложения, а не надеждой на модель.

Политики доступа и правила обработки данных

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

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

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

Кейс: ассистент в приложении до и после ограничений

Что было до ограничений

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

Что изменили

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

Метрики до и после

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

Guardrails AI мы используем как каркас для описания правил и валидаторов: он позволяет держать проверки декларативно и менять их без пересборки логики ассистента.

Чем отличается проверка на входе от проверки на выходе?

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

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

Контур проверок строится так, чтобы точки контроля не дублировали друг друга. На входе — нормализация запроса, проверка на запрещённые категории и ограничение длины контекста. На выходе — сверка фактов с доверенным источником, маскирование персональных данных и проверка на соответствие сценарию. Если вход отсекает запрос, пользователь получает понятное объяснение и альтернативу, а не пустой экран. Если выход не проходит проверку, ответ не показывается, а переводится в безопасный сценарий: уточняющий вопрос или передача оператору.

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

Частые технические сомнения по guardrails ai

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

Можно ли обойти guardrails ai через переформулировку запроса?

Полностью исключить это нельзя — как и любую защиту. Задача в другом: сделать обход дорогим и заметным. Мы комбинируем правила на входе (классификация намерения) и на выходе (проверка ответа), плюс логируем попытки обхода. Когда срабатывает порог, ассистент отвечает отказом и передаёт диалог оператору. Правила обновляются по мере появления новых сценариев обхода.

Что происходит при обновлении модели?

Guardrails ai живут отдельно от модели, поэтому смена версии не ломает правила — но требует прогона регрессии. Мы держим набор тестовых диалогов, на которых проверяем, что новая модель не начала обходить ограничения и не потеряла качество на ключевых сценариях. Только после прохождения тестов модель уходит в продакшн.

Можно ли добавить свои сценарии и правила?

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

Как откатить изменения, если правило сломало сценарий?

Конфигурация правил версионируется. Откат — это возврат к предыдущей версии конфигурации, а не пересборка приложения: занимает минуты и не затрагивает релизный цикл. Перед выкаткой изменения проходят на теневом трафике, поэтому откат нужен редко.

Опишите задачу — вернёмся с оценкой и планом под ваш продукт.

Обсудим задачу: вернёмся с оценкой и планом

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

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

На выходе вы получаете:

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

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