Зростання глобальних втрат від телеком-фроду до $41.82 млрд у 2025 році порівняно з $38.95 млрд у 2023 році (згідно з даними CFCA Global Fraud Loss Survey 2025) змушує операторів зв'язку та великі enterprise-компанії радикально переглянути підходи до безпеки своїх каналів обслуговування. Традиційні контакт-центри, що роками спиралися на закриті монолітні системи BSS/OSS, опинилися перед складним вибором. Бізнес вимагає ефективності та негайного впровадження AI-агентів, розумних голосових помічників і безшовної омніканальності. Проте спроби впровадити ці інструменти стикаються з критичною вразливістю VoIP-трафіку.
Сучасні контакт-центри намагаються знайти баланс між ефективністю AI-керованих омніканальних взаємодій та необхідністю захисту комунікацій від витонченого шахрайства, такого як спуфінг та фрод із підписками (subscription fraud). За оцінками CFCA, використання справжніх або вкрадених ідентичностей у схемах із підписками завдає галузі $5.31 млрд щорічних збитків. Ефективний клієнтський сервіс сьогодні неможливий без інтеграції інновацій у безпечне, модульне ядро, захищене на рівні сигналізації.
Анатомія вразливості: чому сучасний контакт-центр став ціллю для фроду
Сучасний контакт-центр — це складна розподілена система, що поєднує SIP-транки, системи інтерактивного голосового автовідповідача (IVR), механізми розподілу викликів (ACD) та бази даних клієнтів. Коли компанії намагаються швидко розгорнути нові цифрові канали обслуговування через розрізнені API-інтеграції, створюється архітектура зі слабко захищеними точками дотику.
Зловмисники використовують ці слабкі місця для соціальної інженерії та фінансового шахрайства. Відсутність надійної автентифікації джерела виклику у традиційному VoIP дозволяє імітувати дзвінки від реальних клієнтів (спуфінг), обходячи первинні етапи перевірки. Додатково ситуацію ускладнюють глобальні вразливості телеком-інфраструктури. У звіті ENISA Threat Landscape 2025 наголошується, що експлуатація застарілих сигнальних протоколів, таких як SS7 та Diameter, залишається значним ризиком для мобільних мереж. Це означає, що покладатися виключно на традиційні методи верифікації (наприклад, SMS-паролі) під час звернення клієнта до контакт-центру стає дедалі небезпечніше.
Від моноліту до ODA: як відкрита архітектура дозволяє безпечно підключати AI-агентів
Головна перешкода на шляху до безпечного впровадження штучного інтелекту — це закрита структура монолітних систем BSS/OSS. Інтеграція сучасного AI-агента в такий моноліт перетворюється на негнучку схему "точка-точка", де кожне оновлення системи може призвести до збоїв у клієнтському сервісі.
Рішенням є перехід до концепції Open Digital Architecture (ODA), яку розвиває консорціум TM Forum. ODA пропонує замінити монолітні legacy-системи компонентною, API-first архітектурою. У цій моделі AI-інструменти підключаються як незалежні мікросервіси, що взаємодіють з ядром оператора через стандартизовані відкриті інтерфейси. Слід зазначити, що ODA не є готовим "коробковим" рішенням, яке можна розгорнути миттєво. Це довгострокова стратегія і референсна архітектура для трансформації.
Використання ODA відкриває шлях для безпечної інтеграції AI-агентів через захищені API шлюзи. Це дозволяє чітко контролювати контекст запитів штучного інтелекту, логувати кожну його дію та обмежувати доступ до даних, що є критично важливим для підготовки до європейського законодавства (AI Act).
Криптографія проти спуфінгу: впровадження RFC 8224 та SIP Identity у клієнтському сервісі
Для захисту голосового каналу від підміни Caller ID та верифікації походження вхідних дзвінків галузь використовує криптографічні механізми. Технічним стандартом для цього є IETF RFC 8224 (Authenticated Identity Management in SIP).
Цей стандарт визначає використання заголовка Identity у SIP-повідомленнях. Заголовок містить криптографічно підписану інформацію про походження виклику. Коли абонент телефонує до контакт-центру, оператор-ініціатор підписує виклик, а прикордонний контролер (SBC) приймаючої сторони перевіряє цей підпис. Якщо підпис дійсний, AI-агент або оператор контакт-центру отримує підтвердження того, що номер не був підмінений. Важливо розуміти, що впровадження RFC 8224 та пов'язаних технологій (як-от STIR/SHAKEN) вирішує виключно проблему автентифікації Caller ID. Вони не ліквідують фрод повністю і не замінюють загальних систем управління ризиками, оскільки не захищають від зламу самого пристрою або соціальної інженерії.
Логіка маршрутизації: блокування IRSF та реєстраційного фроду на рівні комутатора
Контакт-центр може стати не лише жертвою вхідних атак, але й інструментом для генерації збитків через International Revenue Share Fraud (IRSF). Зловмисники можуть експлуатувати логіку IVR або зламувати SIP-облікові записи для масової переадресації викликів на платні міжнародні номери, отримуючи відсоток від вартості дзвінка.
Мінімізація IRSF вимагає вбудовування суворих правил безпеки безпосередньо у логіку маршрутизації викликів контакт-центру. Це включає блокування міжнародних напрямків за замовчуванням, заборону неавторизованої переадресації на рівні IVR та використання систем моніторингу, які здатні виявляти аномалії в трафіку в режимі реального часу.
Матриця архітектурних вимог до сучасного контакт-центру
| Рівень | Технологія / Стандарт | Бізнес-цінність |
|---|---|---|
| Рівень сигналізації | Захист від спуфінгу через RFC 8224 (SIP Identity) | Запобігає підміні номерів клієнтів зловмисниками |
| Рівень інтеграції | Перехід на ODA (Open Digital Architecture) API | Замінює монолітні зв'язки гнучкими мікросервісами для AI |
| Рівень маршрутизації | Контроль IRSF у реальному часі | Блокує несанкціоновану переадресацію на платні номери |
| Рівень відповідності | Контроль контексту AI-агентів (AI Act compliance) | Гарантує прозорість та аудітованість дій штучного інтелекту |
Архітектурний перехід: як модернізувати ядро без зупинки бізнес-процесів
Для великих операторів (Tier-1/Tier-2) та enterprise-компаній відмова від монолітних рішень повинна відбуватися без ризику для безперервності бізнесу. Найкращим підходом є створення захищеного інтеграційного шару, який бере на себе функції маршрутизації даних, безпеки та оркестрації API.
Для реалізації таких масштабних трансформацій застосовується експертиза консорціуму Intecracy Group. Технологічним фундаментом для проектування cloud-native архітектур та модернізації застарілих систем часто виступає low-code / model-driven платформа UnityBase. Це спільна розробка компаній консорціуму, де InBase є ключовим, але не єдиним розробником.
UnityBase використовує єдину доменну модель (Domain metadata), що дозволяє швидко генерувати REST API для підключення AI-агентів та безпечно зв'язувати нові цифрові канали з існуючими legacy-системами. Платформа забезпечує архітектурну безпеку через вбудовані механізми контролю доступу на рівні рядків (RLS) та атрибутів, а також веде детальний журнал аудиту (audit trail) кожної операції. Для проектів із підвищеними вимогами до безпеки або високонавантажених телеком-середовищ офіційна сторінка платформи рекомендує використовувати комерційні редакції Enterprise або Defence. На базі платформи створюються корпоративні системи, такі як Megapolis.DocNet або Scriptum.DMS, які можуть бути інтегровані з операторськими голосовими шлюзами. Це дозволяє AI-агенту або оператору автоматично обробляти інциденти та керувати документами під час розмови, зберігаючи при цьому повний контроль над даними та відповідність корпоративним стандартам безпеки.
Поширені питання
Як стандарт RFC 8224 допомагає захистити контакт-центр від підміни Caller ID?
Стандарт RFC 8224 визначає використання заголовка Identity у протоколі SIP, який містить криптографічно підписану інформацію про походження виклику. Приймаюча система перевіряє цей підпис, що дозволяє верифікувати справжність номера абонента та захистити контакт-центр від підміни Caller ID (спуфінгу).
Які переваги дає перехід на Open Digital Architecture (ODA) при інтеграції AI-агентів?
Перехід на ODA замінює застарілі монолітні системи BSS/OSS на компонентну, API-first архітектуру. Це дозволяє безпечно інтегрувати AI-агентів як незалежні мікросервіси через стандартизовані відкриті інтерфейси, забезпечуючи контроль доступу до даних та гнучкість системи.
Як запобігти фроду типу IRSF (International Revenue Share Fraud) у логіці розподілу дзвінків?
Для запобігання IRSF необхідно впровадити правила маршрутизації на рівні комутатора: за замовчуванням блокувати несанкціоновані міжнародні напрямки, заборонити автоматичну переадресацію викликів через IVR на зовнішні номери та використовувати моніторинг для блокування аномальної активності в реальному часі.