Система підтримки на базі ШІ, яку вважали захищеною лише на етапі виводу моделі, випускала дані клієнтів через «бічний вхід» — шлях, яким записи CRM потрапляють у промпт. Аналіз причин інциденту (post-mortem) автора показує, що захисту лише тексту, який генерує модель, недостатньо — вхідний запит, дані, отримані з внутрішніх інструментів, і кінцевий вивід потребують незалежних засобів захисту. Інакше компанія може розкрити імена, електронні адреси та ідентифікатори, навіть не зафіксувавши порушення на етапі виводу моделі.

Чому ці три межі мають значення

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

  • Ingress (Вхідний потік) – необроблений запит, який вводить клієнт.
  • Return path (Шлях повернення) – інформація, яку агент отримує з підпорядкованих систем, наприклад, CRM.
  • Emission (Вивід) – текст, який модель повертає користувачеві.

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

Від демо-версії до продакшену: важко здобуті уроки

Перехід прототипу в режим реальної роботи служби підтримки виявив конкретні помилки, які не враховував простий підхід «спочатку редагування, потім відправка».

  • Токенізація замість редагування – видалення імені або електронної адреси до того, як вони потраплять до моделі, заважає системі сформулювати правильну відповідь. Зберігайте оригінальне значення в безпечному сховищі, замінюйте його випадковим UUID у промпті, а після завершення роботи моделі повертайте UUID назад. Це дозволяє тримати необроблені дані поза контекстом моделі, зберігаючи функціональність.

  • Валідація ідентифікаторів за допомогою контрольних сум – регулярний вираз може виявити рядок, схожий на номер рахунку; контрольна сума підтверджує, чи є він справжнім ідентифікатором. Фільтр контрольних сум не дозволяє агенту сприймати довільні числа як конфіденційні дані, зменшуючи кількість хибнопозитивних спрацювань, які інакше спричиняли б непотрібне редагування.

  • Об'єднання перекриваючих фрагментів – записи клієнтів часто містять ім'я, після якого йде електронна адреса, що мають спільні символи (наприклад, «John Doe john.doe@example.com»). Токенізація лише імені залишає фрагмент електронної адреси у відкритому тексті, який може бути виведений. Розглядайте всю область перекриття як єдиний токен.

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

  • Відстеження еталонних даних (ground truth) – коли людина редагує чернетку, створену ШІ, перед відправкою, модель уже видала помилкову відповідь. Порівняння чернетки ШІ з остаточним повідомленням, схваленим людиною, виявляє прогалини в точності та не дає системі навчитися повторювати помилки.

Ризики для бізнесу

ШІ-агенти клієнтської підтримки знаходяться на перетині публічної взаємодії та внутрішніх сховищ даних.

Контраргумент: чому деякі все ще віддають перевагу редагуванню

Висновок

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