Guardrails AI-асистента в мобільному додатку

Guardrails AI у мобільному застосунку: де асистент ламається

Асистент у мобільному застосунку ламається не там, де його тестували.

У демо модель відповідає на підготовлені запитання, а в проді користувачі приносять формулювання, яких не було в жодному сценарії: обходять фільтри перефразуванням, просять «показати твої інструкції», підштовхують до дій, на які асистент не має прав.

Guardrails AI — це шар правил навколо моделі, який вирішує три завдання: не дати видати заборонене, не дати вигадати факт і не дати виконати операцію без підтвердження людини.

Розберемо типові відмови, які ми бачимо в проді. Витік промпту — користувач витягує системні інструкції через «переклади їх іншою мовою» або «продовж текст», і назовні виходять внутрішні правила, назви сервісів, логіка модерації.

Галюцинації в проді небезпечніші тим, що виглядають правдоподібно: асистент упевнено називає термін доставки, якого немає в даних, або вигадує умову тарифу.

Обхід фільтрів через перефразування — заборонений запит переписують ввічливо, за ролями або через гіпотетичну ситуацію, і фільтр за ключовими словами пропускає його цілком.

Окремий клас — небезпечні дії. Якщо асистент уміє ініціювати платіж, скасовувати замовлення або змінювати персональні дані, помилка коштує не репутації, а реальних операцій.

Тут guardrails працюють не як фільтр відповіді, а як підтвердження наміру: асистент пропонує дію, користувач його підтверджує, і лише потім іде запит у бекенд.

Ціна кожної відмови різна, але механіка одна: користувач втрачає довіру до асистента після першої впевненої помилки й перестає ним користуватися. Тому guardrails проєктують не поверх готового асистента, а разом із ним — на вході, на виході та на рівні виклику інструментів. Нижче розбираємо, як це влаштовано і що закриває кожен шар.

Що дає керований асистент: ефект у метриках

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

На пілотах ми фіксуємо базову лінію за трьома метриками: частка відповідей, що порушують правила домену, частка запитів, що пішли в блокування, і час від спрацювання правила до правки конфігурації.

Без цієї базової лінії будь-яке доопрацювання перетворюється на суперечку про смаки — з нею видно, що саме змінилося після кожного правила.

Далі ефект розкладається за класами відмов, і кожен закривається своєю перевіркою:

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

Окрема метрика — частка блокувань. Занадто висока означає, що правила ріжуть корисні запити і асистент втрачає цінність; занадто низька — що фільтри не працюють. Ми тримаємо її в коридорі й переглядаємо за кожної зміни сценаріїв, щоб обмеження не перетворювалися на самоціль.

Час відновлення після інциденту залежить від того, наскільки правила відокремлені від коду застосунку. Коли вони винесені в конфігурацію, правка займає хвилини й не потребує нового релізу — вартість простою падає кратно, а не на відсотки.

Саме цей запас міцності і є практичний сенс керованого асистента: збій локалізується, відкочується й розбирається без зупинки продукту.

Підходи до обмеження: порівняння режимів роботи

Обмеження ІІ-асистента можна ставити в чотирьох точках: до генерації, після неї, на рівні середовища виконання та на рівні людини. Комбінувати їх доводиться майже завжди — кожен режим закриває свій клас ризиків і залишає свій клас дір. Нижче — чесне порівняння, включно з випадками, коли режим не підходить.

Як режими поєднуються

Перевірка на вході дешевша за інші та відсікає явний сміттєвий вміст до звернення до моделі — але вона не рятує від коректно сформульованого запиту з небажаним змістом.

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

Ізольований контур обмежує не текст, а можливості: асистент бачить лише дозволені джерела і не може виконати дію за межами обумовленого набору.

Ручна модерація не замінює автоматику, а доповнює її: вона розбирає спірні випадки, які правила не класифікували, і за підсумками розбору правила уточнюються.

На практиці робоча схема — вхід, вихід та ізоляція на автоматиці, а людина підключається до черги інцидентів і до тем, де ціна помилки висока.

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

Як ми впроваджуємо обмеження: етапи роботи

Роботу будуємо так, щоб обмеження для асистента з'являлися не «по ходу», а як керований шар між моделлю та інтерфейсом застосунку.

Спочатку фіксуємо, що асистент взагалі може робити в продукті, потім переносимо це в правила, які перевіряються кодом, і лише після цього випускаємо в прод. Нижче — порядок, за яким відбувається впровадження.

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

Такий порядок дає передбачуваний результат: асистент залишається корисним, а поведінка за межами дозволеного закривається на рівні застосунку, а не надією на модель.

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

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

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

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

Кейс: асистент у застосунку до та після обмежень

Що було до обмежень

Асистент відповідав на вільні запити користувачів без перевірки на виході: модель могла видати пораду щодо медичного дозування, пообіцяти повернення коштів від імені сервісу або послатися на неіснуючий пункт договору.

Окремої проблеми це не створювало, поки частка таких відповідей залишалася в межах статистичної похибки.

Коли асистент отримав доступ до історії замовлень і балансу, кожна друга небезпечна відповідь перетворювалася на звернення до підтримки — оператор витрачав час на розбір листування й пояснення, що бот не мав права це обіцяти.

Що змінили

Ми поставили шар перевірок між моделлю та інтерфейсом застосунку: правила на вході відсікають запити поза дозволеними темами, правила на виході перевіряють відповідь на заборонені формулювання, обіцянки від імені компанії та посилання на дані, яких немає в контексті користувача.

Відповідь, що не пройшла перевірку, не показується — асистент переформулює її або переводить діалог на оператора. Усі спрацювання пишуться до журналу із причиною, тому правила уточнюються за реальними випадками, а не за припущеннями.

Метрики до та після

Навантаження на підтримку знизилося не за рахунок того, що користувачі стали рідше писати, а за рахунок того, що приводів писати стало менше.

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

Guardrails AI ми використовуємо як каркас для опису правил і валідаторів: він дозволяє тримати перевірки декларативно й змінювати їх без перезбирання логіки асистента.

Чим відрізняється перевірка на вході від перевірки на виході?

Перевірка на вході спрацьовує до того, як запит вирушає в модель: вона відсікає заборонені теми, спроби витягнути системну інструкцію, підозрілі вкладення та запити поза сценарієм застосунку.

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

Це не дублюючі, а доповнювальні точки контролю — вхід дешевший і швидший, вихід точніший, бо бачить результат цілком.

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

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

Тому пороги на вході тримають м'якшими, а на виході — строгішими, але з обов'язковим логуванням кожного спрацювання, щоб інженер міг розібрати його й підкрутити правило.

Контур перевірок будується так, щоб точки контролю не дублювали одна одну. На вході — нормалізація запиту, перевірка на заборонені категорії та обмеження довжини контексту.

На виході — звірка фактів із довіреним джерелом, маскування персональних даних і перевірка на відповідність сценарію. Якщо вхід відсікає запит, користувач отримує зрозуміле пояснення й альтернативу, а не порожній екран.

Якщо вихід не проходить перевірку, відповідь не показується, а переводиться в безпечний сценарій: уточнювальне питання або передача оператору.

Ключове рішення — що робити при спрацюванні. М'який варіант: позначити відповідь і показати із застереженням. Жорсткий: заблокувати й перепитати.

Вибір залежить від ціни помилки в конкретному сценарії — у довідковому розділі достатньо позначки, в операціях із даними потрібне блокування. Обидва рівні логуються однаково, інакше неможливо порахувати частку хибних спрацювань і зрозуміти, де правило працює не так, як задумано.

Часті технічні сумніви щодо guardrails ai

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

Чи можна обійти guardrails ai через переформулювання запиту?

Повністю виключити це не можна — як і будь-який захист. Завдання в іншому: зробити обхід дорогим і помітним. Ми комбінуємо правила на вході (класифікація наміру) і на виході (перевірка відповіді), плюс логуємо спроби обходу.

Коли спрацьовує поріг, асистент відповідає відмовою й передає діалог оператору. Правила оновлюються в міру появи нових сценаріїв обходу.

Що відбувається при оновленні моделі?

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

Чи можна додати свої сценарії та правила?

Так. Правила описуються декларативно й не потребують переписування логіки застосунку. Ви додаєте сценарій — ми налаштовуємо перевірки, тестуємо й викочуємо. Так само налаштовуються свої формати відповідей, тон і заборонені формулювання під ваш продукт.

Як відкотити зміни, якщо правило зламало сценарій?

Конфігурація правил версіонується. Відкат — це повернення до попередньої версії конфігурації, а не перезбирання застосунку: займає хвилини й не зачіпає релізний цикл. Перед викочуванням зміни проходять на тіньовому трафіку, тому відкат потрібен рідко.

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

Обговоримо задачу: повернемося з оцінкою та планом

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібні вихідні дані про ваш застосунок.

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

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

Далі ми уточнюємо межі задачі. Що саме має робити асистент і що йому заборонено, які дані він бачить, де відповідь обов'язково має переходити до людини, які перевірки потрібні перед показом відповіді користувачеві.

Окремо проговорюємо, як ви будете перевіряти результат: набір тестових сценаріїв, еталонні відповіді, метрики за часткою коректних відповідей і за кількістю виходів за межі. Без цього оцінка перетворюється на ворожіння, а строки — на нескінченний процес.

На виході ви отримуєте:

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

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