← Усі пости

Есе · червень 2026 р.

3 рівні захисту AI-агента — що буде якщо він сказонить

AI-агент захищений трьома незалежними рівнями. Layer 1 — prompt rules з білим списком тем; агент відмовляється виходити за межі компетенції. Layer 2 — LLM supervisor; друга модель перевіряє відповіді на критичних полях (ціни, дати, домовленості). Layer 3 — human-in-the-loop для VIP і нетипових випадків. 2-5% запитів агент сам ескалює людині.

Це питання яке клієнти задають перед запуском у 9 з 10 випадків: «А якщо ваш AI скаже клієнту якусь дичину?» Чесна відповідь — без захисту скаже. З трьома рівнями захисту — практично ні. Ось як це працює технічно і що ми гарантуємо.

Layer 1 — Prompt rules і white-list scope

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

  • давати конкретну ціну без виклику ціни з прайсу через API;
  • обіцяти терміни поставки без виклику стану складу через API;
  • підтверджувати знижку понад 5% без ескалації до менеджера;
  • відповідати на запитання поза скоупом продажів (рекламації, технічна підтримка, юридичні питання) — ескалюй.

Якщо запитання не входить у скоуп — відповідь: «Це питання я переадресую колезі». І створи задачу в CRM.

Що це дає: 70-80% потенційних помилок не відбуваються, бо агент відмовляється відповідати, якщо немає підтвердження з системи. Він не вигадує ціну — він просить API дати реальну ціну. Не вигадує дату — питає календар. Це працює тому що LLM (Claude Opus 4.7, GPT-5) добре виконують instruction-following з чітко прописаними обмеженнями.

Layer 2 — LLM supervisor (друга модель перевіряє першу)

Другий рівень — це менша і швидша модель, яка перевіряє відповідь першої перед відправкою клієнту. У Grow2.ai архітектурно це виглядає так:

  • Agent (Claude Opus 4.7 або GPT-5) генерує драфт відповіді.
  • Supervisor (Claude Haiku 4.5 або GPT-5-mini) отримує оригінальний запит + драфт + правила.
  • Supervisor повертає JSON approve/reject з reason.
  • Якщо approve=false — драфт відкидається, агент перегенеровує або ескалує.

Що supervisor перевіряє: числа (ціна проти прайсу), дати (реалістична дата зустрічі), tone (бренд voice), promise (агент не обіцяв того що компанія не може виконати). Cost: supervisor — менша модель, плюс ~$0.001-0.005 на запит. На 10K запитів/міс — додаткові $10-50. Безкінечно дешевше за один поганий випадок з VIP-клієнтом.

Layer 3 — Human-in-the-loop (ескалація + audit)

Третій рівень — гарантована людська точка контролю в двох сценаріях.

  • Сценарій А: AI сам ескалює. Якщо confidence score нижче порогу (зазвичай 0.7) або supervisor дав approve=false, агент створює задачу в CRM з поміткою «потрібен manual review», передає менеджеру з готовим контекстом.
  • Сценарій Б: VIP-сегмент і critical fields. Заздалегідь визначені сегменти завжди проходять через людину. Агент готує draft відповіді, менеджер 30 секунд переглядає, надсилає або корегує.

Аудит: кожна відповідь агента зберігається з повним логом — оригінальний запит, system prompt, відповідь supervisor, фінальне рішення, хто і як це підтвердив. Якщо клієнт пише «ваш бот мені сказав 50%, де знижка?» — за 30 секунд знаходимо повний trail.

Що відбувається коли все одно сталося

Чесно: 2-5% запитів агент відпрацьовує неоптимально. Не «фантазує ціну» — це блокується Layer 1-2 — але дає шаблонну відповідь де клієнт чекав персоналізації, або довго думає на нестандартному запиті. Це не «помилка» в інженерному сенсі — це деградація якості порівняно з найкращим менеджером. Що з цим робимо: weekly review перших двох місяців, customer feedback loop, A/B testing на спірних полях. Це не «налаштував і забув» — це постійний процес.

Що НЕ дає захист

Антихайп-частина. Жоден з трьох рівнів захисту не гарантує:

  • емпатії на емоційному запиті («у мене сьогодні помер тато, не можу приїхати на огляд» — AI зрозуміє контекст і ескалює, але це не людська відповідь);
  • гнучкості на нестандартному пропонуванні («давайте я заплачу за 6 місяців наперед зі знижкою 30%» — це не у промпті, ескалація);
  • інтуїції на «гарячих» сигналах (коли клієнт пише з нюансами, які людина-продажник зчитає одразу, а AI пропустить).

AI-агент з трьома рівнями захисту — це safety net, не магія. Він дає вам впевненість що базові помилки заблоковані. Складна частина — все ще робота вашої команди.

Часті запитання

Що буде якщо AI-агент дасть клієнту неправильну ціну?

Технічно це не повинно статися: Layer 1 забороняє агенту вигадувати ціну — він викликає API прайсу через function call. Layer 2 supervisor перевіряє відповідну ціну проти прайсу перед відправкою. Якщо все одно сталося (баг інтеграції) — у вас є повний audit log: коли запит надійшов, який прайс був актуальним, яку ціну сказав агент, хто з менеджерів був онлайн. На основі цього вирішуєте: визнати свою ціну для клієнта, або пояснити з посиланням на правильну.

Як часто AI-агент помиляється і як ви це міряєте?

Метрика 1: Error rate — % відповідей, заблокованих supervisor. Норма: 3-8%. Метрика 2: Escalation rate — % запитів, які агент сам передає людині. Норма: 10-20%. Метрика 3: Customer feedback — кількість скарг на «бот ляпнув не те». Норма: менше 0.5% всіх запитів. У Grow2.ai ми моніторимо всі три метрики в реальному часі і робимо weekly review перші 2 місяці.

Чи можна аудитувати кожну відповідь AI-агента?

Так — це обов'язкова частина setup'у. Кожна відповідь зберігається з: timestamp, оригінальний запит клієнта, system prompt active на момент, відповідь agent (draft), відповідь supervisor (approve/reject + reason), фінал (sent/escalated), хто з менеджерів торкався. Audit log зберігається 12+ місяців, експортується в JSON або CSV.

Що відбувається при downtime LLM-провайдера (OpenAI, Anthropic)?

У Grow2.ai агент має multi-provider failover: якщо primary (Anthropic Claude) не відповідає більше 10 секунд, агент автоматично переключається на secondary (OpenAI GPT-5) з тим самим промптом. SLA Anthropic і OpenAI окремо — 99.9%; разом — 99.99%. Якщо обидва впадуть одночасно — агент переходить у graceful degradation: всі заявки попадають у чергу з поміткою «manual response required», менеджери обробляють вручну.