Національні телеком-оператори стикаються з проблемою: дані, необхідні для запуску AI-проєктів, виявляються фрагментованими, неконсистентними, містять пропуски та не мають єдиних довідників. Спроба натренувати AI-моделі на таких даних дає неякісний результат, що унеможливлює впровадження інтелектуальних систем для підвищення ефективності обслуговування абонентів чи оптимізації мережі.
Причина: архітектурний хаос та відсутність Data Governance
Ця проблема виникає через історично сформовану екосистему OSS/BSS, яка у великих телеком-операторів може налічувати 15–25 систем різних поколінь. Кожна система (CRM, білінг, системи управління мережею, системи підтримки абонентів) створювалася для вирішення своєї вузької задачі, часто без врахування потреби в уніфікованому профілі клієнта або єдиних довідниках. Як наслідок, один і той самий клієнт може мати кілька записів з різними адресами, контактними даними чи навіть іменами, а дані про послуги та тарифи зберігаються у розрізнених білінгових системах. Це призводить до того, що концепція Customer 360 (єдиного, повного погляду на клієнта) не працює, а time-to-market (швидкість виведення на ринок) нових тарифних планів обмежується необхідністю ручного узгодження даних між legacy-системами.
Варіанти рішення: від MDM до Data Mesh
Розв’язання проблеми вимагає системного підходу до управління даними. Один з варіантів — впровадження MDM (управління майстер-даними) з consolidate-моделлю, де MDM-хаб (центральне сховище майстер-даних) тільки зіставляє та агрегує дані з різних джерел, а самі дані залишаються у вихідних системах. Цей підхід відносно швидко впроваджується, але не гарантує цілісності при оновленнях, оскільки джерела можуть продовжувати створювати дублікати. Більш надійний, але складніший варіант — MDM з registry-моделлю, де створюється централізована модель майстер-даних з API для синхронізації змін назад у джерела. Це забезпечує вищий рівень консистентності, але вимагає значних зусиль для інтеграції та перебудови процесів. Для великих телеком-операторів з децентралізованими командами та високою автономністю бізнес-доменів, перспективним є підхід Data Mesh, який розглядає дані як продукт, де кожен домен відповідає за якість і доступність своїх даних, що усуває єдину точку відмови та масштабує управління даними.
Типова помилка
Часто компанії, особливо у телеком-секторі, поспішають із запуском AI-проєктів, фокусуючись виключно на технологіях та точності (accuracy) AI-моделей. Вони витрачають значні ресурси на розробку складних алгоритмів, не визначивши на старті чітких бізнес-метрик успіху. Це призводить до того, що проєкт може показувати високу точність моделі, але не приносити реальної бізнес-цінності, оскільки незрозуміло, як ця точність конвертується у зменшення операційних витрат, зростання задоволеності клієнтів чи збільшення прибутку.
Правильний шлях полягає у визначенні бізнес-метрики першою: це може бути відсоток зекономленого часу операторів контакт-центру, відсоток зменшення помилок при обробці запитів або конкретний ROI від впровадження AI. Accuracy моделі — це важлива інженерна метрика, але вона вторинна. Бізнес-цінність має бути пріоритетом, і тільки тоді інвестиції в AI стають виправданими.
На прикладі типового сценарію національного телеком-оператора з мільйонами абонентів, який надає як B2C, так і B2B послуги, ми бачимо, як AI Act (який набув чинності в ЄС у 2024 році і вже сьогодні впливає на компанії, що працюють з європейськими партнерами) створює нові виклики для VoIP та контакт-центрів. Вимоги до прозорості, пояснюваності та недискримінації AI-систем означають, що оператор не може просто впровадити голосового бота для автоматизації дзвінків, не забезпечивши повну прозорість його роботи та можливість аудиту рішень. Це стосується і систем LCR-routing (маршрутизації дзвінків за найменшою вартістю), які можуть використовувати AI для оптимізації трафіку. Без належного управління даними та чітких політик data governance, виконання цих вимог стає неможливим.
Технології для AI у комунікаціях
Для успішної інтеграції AI у телеком-інфраструктуру та відповідності вимогам AI Act важливим є використання перевірених технологічних рішень:
- Apache Kafka — розподілена платформа для потокової передачі подій, яка використовується для асинхронної доставки подій про зміну даних між різними системами OSS/BSS, наприклад, між CRM та білінгом (топіки customer.created, account.updated). Без Kafka синхронізація йшла б через point-to-point виклики, які при 15+ системах перетворюються на тенета залежностей. Будь-яка зміна в одній системі спричиняє каскадний збій у трьох інших, і час інтеграції нової системи зростає з тижнів до місяців.
- API Gateway — єдина точка входу для всіх API-викликів, яка забезпечує централізоване управління доступом, маршрутизацію та моніторинг. У нашому сценарії API Gateway використовується для уніфікації доступу до даних клієнтів з різних OSS/BSS систем, надаючи єдиний інтерфейс для AI-сервісів. Без нього розробники AI-моделей мали б інтегруватися з десятками різних API, що значно ускладнює розробку, підтримку та безпеку.
- Kubernetes — open-source система для автоматизації розгортання, масштабування та управління контейнеризованими застосунками. Kubernetes забезпечує масштабування інтеграційних мікросервісів та AI-моделей під час пікових навантажень, наприклад, у дні масових розсилок. Без нього пікові години призводили б або до timeout’ів API, або до надлишкового виділення інфраструктури «про запас», що дорого і неефективно.
На практиці, для управління VoIP-трафіком та інтеграції AI-моделей для аналізу голосових даних використовується DooxSwitch Platform (VoIP-платформа для телеком-операторів від DooxSwitch), що включає softswitch, multi-tenant PBX, SIP-routing, білінг та WebRTC. Це дозволяє, наприклад, виявляти шахрайство або автоматично визначати наміри абонента в реальному часі, забезпечуючи прозорість та аудит AI-систем у голосових каналах згідно з вимогами AI Act.
Ризики
Незважаючи на переваги, існують ризики, які можуть зашкодити проєктам з інтеграції AI в телеком-комунікації. Найбільший з них — відсутність чітко визначеного власника майстер-даних на старті проєкту. Якщо немає однієї відповідальної сторони, яка визначає стандарти якості даних та політики їх оновлення, то MDM-ініціатива приречена на провал, а AI-моделі продовжать працювати на неякісних даних. Інший ризик полягає в недооцінці складності інтеграції legacy-систем. Навіть з використанням Kafka та API Gateway, синхронізація даних з систем, яким 20+ років, може виявитися значно дорожчою та тривалішою, ніж очікувалося, якщо не провести глибокий аудит їхньої архітектури.
Послідовне впровадження практик data governance та MDM, що передує запуску AI-проєктів, переводить дані з категорії «некерований актив» у готовий ресурс для AI-моделей та управлінської аналітики. Це усуває сюрпризи від garbage-in/garbage-out і дозволяє телеком-операторам не тільки відповідати вимогам AI Act, але й отримувати реальну бізнес-цінність від інтелектуальних систем. Наприклад, Softengi розробляє кастомні AI-моделі для виявлення аномалій трафіку та потенційного шахрайства у VoIP-мережах, а команди Softline та Data Management IG мають досвід у впровадженні комплексних рішень для побудови стабільної омніканальної архітектури.