Понад 90 постачальників послуг у всьому світі вже запустили або готують до комерційного старту мережі 5G Standalone (SA), як зазначається у звіті Ericsson Mobility Report (листопад 2025). Цей технологічний перехід різко підвищив рівень складності управління інфраструктурою. Індустрія телекомунікацій змушена виходити за межі використання простих текстових ШІ-чатботів та переходити до автономних AI-агентів. Проте автономні мережі не можуть функціонувати виключно на базі ШІ без нагляду людини — вони потребують глибокої інтеграції в ІТ-ландшафт для виконання рутинних операцій.
На практиці розгортання таких агентів стикається з фундаментальною перешкодою: фрагментацією даних (data silos) та жорсткою прив'язкою до систем конкретних постачальників (vendor lock-in). AI-агент не здатен коректно виконати завдання, якщо він ізольований від реального стану мережі або поточного балансу абонента. Традиційні монолітні BSS/OSS системи не розраховані на мікросекундні запити від агентів, а відсутність єдиної шини оркестрації даних перетворює кожну інтеграцію на складний і повільний кастомний проєкт.
Чому AI-чатботи в телекомі безсилі без глибокої інтеграції в BSS/OSS
Більшість сучасних впроваджень штучного інтелекту в телекомі обмежуються рівнем обслуговування клієнтів (Customer Care). Асистенти здатні розпізнати намір користувача, але для виконання дії — наприклад, динамічної зміни конфігурації послуги чи активації додаткового мережевого слайсу — їм бракує інтеграції з бек-офісними системами.
Для автономної роботи AI-агентам потрібен прямий доступ до систем підтримки бізнесу (BSS) та операцій (OSS) у реальному часі. Без цього виникає так звана «swivel-chair automation» (автоматизація з пересадкою), коли ШІ лише формує запит, а фінальне перенесення даних у білінг чи систему провізіонінгу здійснює оператор. Справжня оркестрація вимагає, щоб агенти могли самостійно ініціювати транзакції через стандартизовані API.
Архітектура TM Forum ODA як протидія вендор-локу
Монолітні системи BSS/OSS створювалися під статичні послуги, маючи закриті бази даних та пропрієтарні інтерфейси. Спроба підключити до них AI-агента зазвичай призводить до створення некерованої мережі точкових інтеграцій. Для вирішення цієї проблеми TM Forum розробив концепцію Open Digital Architecture (ODA). Вона передбачає відмову від монолітів на користь компонентної, декуплованої архітектури з API-first дизайном.
Такий підхід ідеально узгоджується із сервіс-орієнтованою архітектурою (SBA) ядерних мереж 5G, що базується на cloud-native принципах (за стандартами 3GPP). Важливо розуміти, що ODA не є «коробковим» рішенням для миттєвого впровадження. Це багаторічна стратегічна дорожня карта модернізації, яка вимагає послідовного розкриття функцій білінгу та мережевого моніторингу через стандартизовані Open APIs.
Вимоги до білінгового ядра: мілісекундний відгук та інтеграція з DooxSwitch
Коли AI-агент ініціює зміну тарифного плану для B2B-клієнта, інтеграційна затримка (latency) повинна вимірюватися мілісекундами. Традиційна пакетна обробка даних (batch processing) у таких сценаріях є неприпустимою. Агент має в реальному часі перевірити ліміти, розрахувати вартість та авторизувати транзакцію без ручного втручання.
У телеком-ландшафті, що керує голосовим та IoT/M2M трафіком, прикладом системи, здатної забезпечити необхідну швидкість, є операторська VoIP-платформа DooxSwitch. Завдяки вбудованому тарифікаційному ядру реального часу (real-time billing) та механізмам LCR-маршрутизації, ця платформа дозволяє обробляти транзакції з мінімальною затримкою. Використання ODA-сумісних API як мосту між клієнтським AI-інтерфейсом та білінгом DooxSwitch дає змогу безпечно автоматизувати комерційні операції.
Оркестрація даних: роль low-code платформи UnityBase в усуненні Data Silos
Навіть зі швидким білінгом, дані часто залишаються розпорошеними: CRM зберігає історію взаємодій, OSS — топологію мережі. AI-агенту потрібен єдиний логічний шар оркестрації, який приховує складність фізичної інфраструктури.
Для побудови такого шару може використовуватися low-code/model-driven платформа UnityBase (спільна розробка компаній технологічного альянсу Intecracy Group, де InBase є ключовим, але не єдиним розробником). Використовуючи єдину модель метаданих (Domain metadata), платформа автоматично генерує REST API, надаючи AI-агентам стандартизований інтерфейс для доступу до різних СУБД. Завдяки асинхронному неблокуючому HTTP-серверу UnityBase забезпечує високу продуктивність інтеграцій, усуваючи необхідність створення тисяч рядків кастомного коду. Для високонавантажених систем (high-load) або підвищених вимог до безпеки застосовуються комерційні редакції Enterprise (EE) або Defence (DE).
Кібербезпека: захист нових точок атаки за вимогами ENISA
Впровадження AI-агентів не скасовує необхідність у надійних протоколах безпеки; навпаки, агенти створюють додаткову поверхню атаки (attack surface). Згідно зі звітом ENISA Threat Landscape 2025, на цифрову інфраструктуру та сервіси припадає близько 27.7% усіх зафіксованих витоків даних. Компрометація AI-агента в телекомі може призвести до несанкціонованої зміни конфігурацій мережі або доступу до персональних даних.
Архітектура ODA вимагає реалізації концепції Zero Trust на рівні API-шлюзів. UnityBase (в редакціях EE/DE) забезпечує ці механізми на рівні платформного ядра, підтримуючи детальний аудит (audit trail), контроль доступу за ролями (RBAC), списки контролю доступу (ACL) та обмеження на рівні записів (Row-Level Security, RLS). Це гарантує, що ШІ-агент матиме доступ лише до того мінімуму даних, який необхідний для виконання конкретної транзакції.
Порівняння legacy-інтеграції AI та ODA-сумісної автономної оркестрації
| Критерій порівняння | Точкові кастомні інтеграції (Spaghetti-код) | Компонентна декуплована архітектура ODA |
|---|---|---|
| Швидкість доступу до білінгу | Висока затримка (секунди), пакетна обробка | Реальний час (мілісекунди) через стандартизовані API |
| Залежність від вендора | Повний lock-in; будь-яка зміна потребує розробки вендора | Спільні API-контракти, легка заміна компонентів |
| Рівень безпеки даних | Спільний доступ до бази даних (високий ризик витоку) | Рольовий та атрибутивний доступ (RLS/ACL) на рівні API-шлюзу |
Поширені питання
Як TM Forum ODA допомагає інтегрувати AI-агентів у білінг без ризику для стабільності мережі?
ODA замінює монолітну архітектуру на декупловані компоненти з API-first дизайном. AI-агенти взаємодіють із білінгом виключно через стандартизовані та захищені Open APIs, що мінімізує ризики прямого втручання в бази даних.
Які технічні вимоги висуваються до API білінгової системи DooxSwitch для роботи з автономними агентами?
API білінгової системи має підтримувати мілісекундний відгук та інтеграцію тарифікації (rating) у реальному часі. DooxSwitch забезпечує цю можливість завдяки оптимізованому тарифікаційному ядру та сучасним інтерфейсам.
Як уникнути витоку персональних даних абонентів при наданні AI-агентам доступу до OSS/BSS?
Необхідно впроваджувати архітектуру Zero Trust. Використання платформних механізмів, таких як Row-Level Security (RLS) та Access Control Lists (ACL) у комерційних редакціях UnityBase, дозволяє суворо обмежувати видимість даних для AI-агента залежно від його поточного завдання.