## Kesenjangan eksekusi di jaringan live Pada jaringan telekomunikasi yang berjalan nyata, perbedaan antara “model yang memprediksi” dan “agen yang bertindak” cepat berubah menjadi kenyataan operasional—karena langkah berikutnya bukan sekadar bagan, melainkan perubahan konfigurasi, pemicu pemeliharaan, atau pembaruan parameter yang berdampak langsung pada bisnis. Pembingkaian McKinsey sangat tegas: AI hanya dapat memberi peningkatan bila operator membangun operating model di sekelilingnya—termasuk governance dan mekanisme closed-loop—bukan hanya sekadar menambah perangkat. ([https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks?utm_source=pulse.latellu.com&utm_medium=editorial)) Tekanan dari praktisi dapat dipahami. KPI menuntut perhatian pada uptime, konsumsi energi, mean time to repair (MTTR), dan churn. Namun tim juga menghadapi batasan yang keras: integrasi OSS/BSS, kelelahan alarm, change control, audit trail, serta risiko biaya yang besar bila tindakan keliru. Karena itu, “agentic workflows” memerlukan lapisan infrastruktur yang dapat (1) memahami apa yang harus dilakukan dan (2) membuktikan apa yang telah dilakukan—dengan batas persetujuan ketika jangkauan dampak (blast radius) belum jelas. Artikel ini membahas bagaimana operator telekomunikasi dapat mengoperasionalkan AI agentik berbasis ontology untuk optimasi jaringan, predictive maintenance, pengurangan churn, dan peluncuran 5G/6G—dengan menekankan keluaran infrastruktur dan ROI, bukan klaim vendor. Jalur adopsi menjadi pusat perhatian: data mesh dan enterprise assets yang dikendalikan, tata kelola tool-calling, serta operational observability yang membuat setiap aksi agen dapat ditelusuri. ## Apa arti “agentic” dalam operasional telekomunikasi Agentic workflows bukan “obrolan LLM dengan otomatisasi.” Dalam telekom, “agentic” berarti sistem mampu (a) menguraikan maksud operasional menjadi rangkaian deterministik tool calls, (b) memvalidasi prasyarat terhadap kondisi aktual atau mendekati waktu nyata, dan (c) menyimpan catatan eksekusi yang dapat diaudit—mengaitkan setiap keputusan dengan hasil yang terukur. Secara konkret, maksud operator seperti “stabilkan pemanfaatan PRB di Sektor 12 untuk klaster sel A” berubah menjadi prosedur kontrol yang terbatasi: 1) **Baca state:** kueri baseline KPI saat ini (misalnya distribusi utilisasi PRB, tingkat keberhasilan RRC setup, indikator retransmisi) untuk klaster sel yang persis dalam rentang waktu yang didefinisikan, lalu ambil versi konfigurasi terkini. 2) **Susun rencana dengan batasan:** hasilkan kandidat set parameter *hanya* dalam rentang yang disetujui dan aturan dependensi (misalnya guardrail yang mencegah perubahan ketika pola osilasi baru-baru ini terdeteksi). 3) **Eksekusi tool-call:** panggil API workflow konfigurasi (atau workflow engine) dengan skema yang mewajibkan pengenal (cell IDs, parameter IDs, version IDs) dan menghasilkan artefak konfigurasi diff. 4) **Verification gate:** jalankan job verifikasi yang memeriksa kesesuaian telemetry “sebelum/sesudah” serta delta KPI terhadap aturan penerimaan (bukan “feeling” manusia). 5) **Tulis audit:** simpan masukan tool, diff, klasifikasi kebijakan/risiko, dan hasil verifikasi sebagai jejak yang tidak dapat diubah untuk change control dan evaluasi pascakejadian. Rangkaian inilah yang membedakan agen dari recommender. Recommender bisa salah namun tetap “terlihat benar” di dashboard; agen justru harus **membuktikan**—melalui prasyarat yang eksplisit dan verifikasi KPI—bahwa tindakan mencapai maksud operasional tanpa melanggar batas keselamatan. Dalam arsitektur Open RAN, mekanisme closed-loop serupa secara konseptual sudah dikenal. Lapisan “SMO” (Service Management and Orchestration) pada Open RAN mengorkestrasi operasi RAN, sedangkan “RIC” (RAN Intelligent Controller) menyediakan kontrol terstruktur untuk fungsi radio. Referensi Ericsson dan ekosistem lainnya menjelaskan fungsi RIC non-real-time dan near-real-time serta peran SMO dalam meng-host elemen workflow AI/ML untuk pelatihan dan panduan kebijakan. ([https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations](https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations?utm_source=pulse.latellu.com&utm_medium=editorial)) ([https://www.juniper.net/us/en/research-topics/what-is-ric.html](https://www.juniper.net/us/en/research-topics/what-is-ric.html?utm_source=pulse.latellu.com&utm_medium=editorial)) Implikasi rekayasa: diperlukan action model yang konsisten agar dapat bekerja di berbagai domain (RAN, core, energi, operasi lapangan). Action model tersebut harus dipetakan ke izin tool, data contracts, dan sinyal observabilitas. Tanpa itu, AI agentik akan turun menjadi demo yang rapuh—“terdengar masuk akal”—tetapi tidak mampu bertahan menghadapi manajemen perubahan produksi. ## AI berbasis ontology untuk keterlacakan aksi AI berbasis ontology berarti entitas dan relasi domain direpresentasikan dalam bentuk eksplisit yang dapat dibaca mesin (sebuah ontology). Contohnya: sel, situs, lapisan radio, alarm, mode kegagalan, maintenance work orders, dan pemetaan dampak layanan. Tujuannya bukan keindahan semantik—melainkan traceability. Agen harus bisa mengutip jalur ontology yang tepat untuk membenarkan sebuah tool call. Dalam telekom, “ontology” sering kali terfragmentasi. Insinyur memahami keberadaannya tersebar di dashboard, runbook, model inventaris OSS, dan pengetahuan tribal. Mengoperasionalkan ontology untuk agen berarti memformalkan tiga hal: 1) **Entitas:** objek yang ada (cell, sector, RU/DU/CU bila relevan, alarm, trouble tickets). 2) **Relasi:** bagaimana objek terhubung (anomali daya radio terkait KPI tertentu dan topologi). 3) **Kendala:** tindakan apa yang boleh dilakukan di kondisi yang mana. Di sinilah telecom data mesh menjadi penting. Telecom data mesh adalah pendekatan yang dipimpin operator untuk mendistribusikan kepemilikan data dan menghadirkan data products melalui kontrak yang dikendalikan lintas domain. Alih-alih “lake” monolitik yang tak pernah dipercaya, didefinisikan data products (telemetry, inventory, event history) dengan quality SLAs dan lineage. Penekanan operasional McKinsey sejalan: AI memberi hasil ketika operator merestrukturisasi ekonomi jaringan dan operating model—termasuk disiplin optimasi dan mekanisme proactive maintenance yang mengubah dinamika penanganan tiket dan MTTR. ([https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks?utm_source=pulse.latellu.com&utm_medium=editorial)) Sebelum memilih agent frameworks, bangun atau formal isasikan ontology dan data contracts untuk closed-loop workflow yang akan dijalankan pertama (maintenance, optimasi, atau rollout). Jika tidak, diperlukan waktu berbulan-bulan untuk menyelaraskan “yang dianggap dilihat agen” dengan data apa yang sebenarnya terdapat di sistem. ## Telecom data mesh untuk masukan yang dapat diaudit Telecom data mesh untuk AI agentik tidak berarti “membuat data lake.” Artinya, agen mengonsumsi data products yang dikendalikan—lengkap dengan provenance (asal data), freshness (seberapa mutakhir), dan kualitas (seberapa andal). Bila tool call tidak dapat diaudit masukannya, tidak mungkin mempertahankan justifikasinya dalam change control. Predictive maintenance pada dasarnya proses closed-loop, meski manusia tetap dilibatkan. Agen biasanya membutuhkan: - telemetry yang disejajarkan waktu (counter, aliran KPI), - riwayat insiden dan perbaikan (tickets, outcome MTTR), - topologi dan inventaris aset (apa yang berubah di mana), - katalog intervensi (pekerjaan apa yang dapat dipicu dan dengan izin apa). Sinyal operasional nyata terlihat pada cara sebagian aktor ekosistem menghubungkan workflow berbasis AI dengan sistem trouble ticket. Perjalanan Telefonica Germany menuju autonomous networks dijelaskan lewat solusi predictive maintenance berbasis AI yang terintegrasi dengan sistem trouble ticket untuk pembuatan tiket otomatis dan operasi closed-loop. ([https://info.tmforum.org/Predictive-maintenance-begins-Telefnica-Germanys-journey-towards-autonomous-networks.html](https://info.tmforum.org/Predictive-maintenance-begins-Telefnica-Germanys-journey-towards-autonomous-networks.html?utm_source=pulse.latellu.com&utm_medium=editorial)) Demikian pula, pada optimasi energi dan ekonomi peluncuran 5G, operator membutuhkan closed loops yang kaya telemetry. Percobaan Vodafone UK bersama Ericsson menguraikan use case AI/ML seperti “5G Deep Sleep” dan “Radio Power Efficiency Heatmap,” serta melaporkan hasil energi yang terukur dalam konteks uji coba. ([https://www.ericsson.com/en/press-releases/3/2025/vodafone-uk-and-ericsson-trial-ai-solutions-for-improved-5g-energy-efficiency](https://www.ericsson.com/en/press-releases/3/2025/vodafone-uk-and-ericsson-trial-ai-solutions-for-improved-5g-energy-efficiency?utm_source=pulse.latellu.com&utm_medium=editorial)) Rencana data mesh harus memuat *data products* yang persis akan digunakan agen untuk pengambilan keputusan dan verifikasi. Buat “tool-call input contract” sebelum pengembangan: skema telemetry, jendela waktu, aturan pemetaan aset, serta ambang kualitas. Dengan itu, tindakan agen berubah dari tebakan menjadi bukti rekayasa. ## Tata kelola tool-calling yang melindungi sistem Tata kelola tool-calling menentukan aksi agen mana yang diizinkan, bagaimana dieksekusi, dan kapan perlu persetujuan—sekaligus memungkinkan traceability atas hasil agen. Anggap tata kelola ini sebagai dua lapisan: 1) **Permissioning dan policy:** tool apa yang boleh dipanggil agen, parameter apa, serta kondisi apa yang menyertainya. 2) **Keselamatan eksekusi:** rate limits, mode dry-run, batasan blast-radius, dan jalur rollback. Kerangka tata kelola untuk “agentic AI” tengah muncul. IMDA Singapura meluncurkan Model AI Governance Framework for Agentic AI pada Januari 2026, dengan jelas memosisikan deployment AI agentik yang andal dan aman lewat empat dimensi utama: membatasi risiko sejak awal, akuntabilitas manusia yang bermakna, penerapan kontrol teknis, dan memberi tanggung jawab kepada pengguna akhir. ([https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai](https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai?utm_source=pulse.latellu.com&utm_medium=editorial)) Meski yurisdiksi berbeda, translasi rekayasa bersifat universal. Untuk jaringan telekom, “risk bounding” menjadi kebijakan yang konkret: - Jika agen menyarankan penyesuaian daya radio, minta persetujuan ketika KPI sel menunjukkan ketidakstabilan sebelumnya. - Jika agen merekomendasikan pemeliharaan, minta konfirmasi ketika dependensi work order mengindikasikan probabilitas dampak pelanggan yang tinggi. - Jika agen merencanakan rollout 5G, minta validasi lintas-sistem (inventaris, kapasitas, batasan spektrum) sebelum ada penulisan konfigurasi. Tata kelola seharusnya selaras dengan control loops Open RAN “SMO dan RIC”. Ekosistem menjelaskan panduan RIC near-real-time serta peran RIC non-real-time dalam workflow AI/ML dan panduan kebijakan. ([https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations](https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations?utm_source=pulse.latellu.com&utm_medium=editorial)) ([https://www.juniper.net/us/en/research-topics/what-is-ric.html](https://www.juniper.net/us/en/research-topics/what-is-ric.html?utm_source=pulse.latellu.com&utm_medium=editorial)) Lapisan tata kelola perlu sejalan dengan control loops tersebut: tool calls yang menerjemahkan kebijakan menjadi perubahan konfigurasi harus bisa diaudit dan idealnya melewati orchestrators yang sudah dipercaya (change management, workflow engines, serta validation pipelines). Terapkan “go-live gate” untuk setiap tool yang dapat dipanggil agen. Mulai dari tool yang bersifat read-only (kueri telemetry, pencarian topologi), lalu menuju dry-run untuk konfigurasi diff, kemudian eksekusi bertahap dengan persetujuan manusia. Ini bukan sikap konservatif—ini memastikan bulan produksi pertama agen tetap bertahan. ## Observabilitas operasional untuk pembuktian aksi Operational observability bagi agentic workflows berarti kemampuan menjawab, setelah kejadian: - observasi apa yang dikonsumsi agen, - artefak penalaran apa yang dipakainya (node ontology mana, skor model mana, aturan mana), - tool mana yang dipanggil, dengan input yang persis, - dampak terukur pada KPI, - dan mode kegagalan apa terjadi ketika ia gagal. Sebagian vendor observabilitas dan kerangka enterprise menggambarkan “agent observability” sebagai tracing pemakaian tool dan dependensi end-to-end, bukan hanya memantau satu panggilan model. Misalnya, materi Dynatrace mengulas insight end-to-end melalui tracing execution flows untuk perilaku agen dan tool calls. ([https://www.dynatrace.com/news/blog/announcing-agentic-framework-support-and-general-availability-of-the-dynatrace-ai-observability-app/](https://www.dynatrace.com/news/blog/announcing-agentic-framework-support-and-general-availability-of-the-dynatrace-ai-observability-app/?utm_source=pulse.latellu.com&utm_medium=editorial)) Dalam telekom, “green dashboards” berbahaya karena KPI bisa membaik sementara kualitas aksi memburuk (tiket salah, intervensi yang tidak perlu, atau misconfigurasi diam-diam yang tidak langsung memicu crash). Karena itu, observabilitas harus memasukkan *action verification*. Agen hanya “benar” bila menghasilkan outcome operasional yang memang diinginkan di jaringan. Salah satu pijakan konkret untuk kebutuhan observabilitas dapat diambil dari cara sebagian operator memformalkan integrasi operasi jaringan. Cakupan GSMA Foundry tentang kerja inspeksi dan maintenance berbasis AI dan computer vision milik Türk Telekom menekankan outcome operasional (pengurangan inspeksi) dan mengisyaratkan integrasi workflow yang bisa diukur dari AI ke aksi operasi lapangan. ([https://www.gsma.com/get-involved/gsma-foundry/gsma_resources/how-turk-telekom-achieved-a-98-reduction-in-site-inspection-time-using-ai-and-computer-vision/](https://www.gsma.com/get-involved/gsma-foundry/gsma_resources/how-turk-telekom-achieved-a-98-reduction-in-site-inspection-time-using-ai-and-computer-vision/?utm_source=pulse.latellu.com&utm_medium=editorial)) ## Bukti kasus: penghematan energi Vodafone UK Vodafone UK menerapkan solusi AI Ericsson, termasuk “5G Deep Sleep.” Ericsson melaporkan uji coba memungkinkan radio masuk ke kondisi hibernasi energi ultra-rendah sehingga menghemat hingga 70% konsumsi energi saat jam lalu lintas rendah. Ericsson juga melaporkan penurunan konsumsi daya harian 5G Radio Units hingga 33% di seluruh lokasi uji coba di London. ([https://www.ericsson.com/en/press-releases/3/2025/vodafone-uk-and-ericsson-trial-ai-solutions-for-improved-5g-energy-efficiency](https://www.ericsson.com/en/press-releases/3/2025/vodafone-uk-and-ericsson-trial-ai-solutions-for-improved-5g-energy-efficiency?utm_source=pulse.latellu.com&utm_medium=editorial)) Ini bukan “pemasaran ROI dari vendor AI.” Ini template yang berguna untuk menginstrumentasi agentic workflow: - **Masukan keputusan:** pola trafik dan perilaku radio. - **Tool calls:** mengorkestrasi mode sleep serta ambang parameter sel. - **Verifikasi:** konsumsi energi dan dampak performa yang terukur di bawah kondisi uji coba nyata. Berikut visualisasi dari dua metrik uji coba yang dilaporkan tersebut (bukan benchmark global, melainkan bukti yang bisa dibandingkan operator terhadap KPI energi mereka sendiri).

Pada workload energi dan optimasi, jadikan “tool-call verification” wajib. Tetapkan metrik keberhasilan yang akan diterima (penurunan konsumsi energi tanpa kemunduran KPI) dan pastikan observabilitas dapat menghubungkan setiap aksi agen ke metrik-metrik tersebut. ## Bukti kasus: loop maintenance Telefonica Germany Telefonica Germany mendeskripsikan predictive maintenance sebagai terintegrasi dengan sistem trouble ticket untuk pembuatan tiket otomatis, mendukung operasi jaringan closed-loop dan efisiensi operasional. Studi kasus TM Forum menekankan prediktabilitas dan kontrol closed-loop yang memperbaiki mean time to repair serta ketersediaan jaringan. ([https://info.tmforum.org/Predictive-maintenance-begins-Telefnica-Germanys-journey-towards-autonomous-networks.html](https://info.tmforum.org/Predictive-maintenance-begins-Telefnica-Germanys-journey-towards-autonomous-networks.html?utm_source=pulse.latellu.com&utm_medium=editorial)) Yang paling bernilai secara operasional di sini adalah batas workflow (workflow boundary). Agen tidak sekadar menghasilkan skor risiko. Agen memicu aksi ticketing di sistem yang dikendalikan operator. Di sanalah perbedaan antara “prediction” dan “agentic workflow.” Agar pola ini dapat diterapkan dengan aman: - Ikat entitas ontology ke skema trouble-ticket (kelas fault dipetakan ke field tiket yang mana). - Tata kelola tool call: pembuatan tiket harus dibatasi pada subset aset yang terverifikasi atau rentang confidence tertentu. - Observasi outcome: ukur apakah pembuatan tiket berkorelasi dengan penurunan MTTR—bukan sekadar menambah kebisingan. Untuk predictive maintenance, agen pertama sebaiknya memiliki satu action boundary yang bernilai tinggi (pembuatan tiket atau rekomendasi work order), bukan klaim otonomi luas “membaiki apa pun.” ## Urutan adopsi untuk rollout satu kuartal Adopsi AI agentik gagal ketika tim memperlakukan arsitektur sebagai “fase,” bukan sebagai mekanisme pengantaran (delivery mechanism). Solusinya adalah urutan adopsi yang memaksa integrasi sejak awal, serta menunda otonomi hingga bukti tersedia. ### Fase 0 ke 1: instrumentasi workflow Pilih satu closed-loop workflow yang memetakan langsung ke KPI jaringan: - optimasi jaringan (ambang energi atau kapasitas), - predictive maintenance (tiket/work order), - enablement rollout (validasi perencanaan dan pengecekan staging). Kemudian instrumentasi end-to-end: dari telemetry ke decision menuju tool call hingga verifikasi KPI. Bahkan sebelum agen benar-benar “pintar,” tulang punggung observabilitas sedang dibangun. Agar bisa diukur (bukan sekadar “logging diaktifkan”), tetapkan elemen operasional ini sejak awal: - **Baseline window:** apa yang diperlakukan sebagai “normal” (misalnya 14 hari sebelumnya, distribusi jam yang sama). - **Action attribution key:** field yang dipakai untuk mengaitkan decision→execution→verification (misalnya `workflow_run_id` + `cell_id` + `config_version`). - **Verification window:** berapa lama setelah aksi menilai dampak KPI (misalnya 1–6 jam untuk perubahan parameter; 24–72 jam untuk intervensi maintenance tergantung SLA tiket-ke-work-order). - **Acceptance criteria:** aturan pass/fail yang eksplisit (misalnya metrik target membaik X% tanpa melampaui ambang regresi Y% pada KPI layanan seperti keberhasilan RRC setup, call drop rate, atau throughput). - **Penanganan counterfactual:** apa yang dijadikan pembanding (misalnya “sel/store kontrol” yang tidak diintervensi, atau wilayah holdout dengan karakteristik baseline yang identik). Target pada Fase 1 adalah memastikan kemampuan menjawab dengan cepat: “Ketika agen bertindak, apakah jaringan berperilaku sesuai harapan—dibandingkan saat ia tidak bertindak?” ### Fase 2: kontrakkan ontology dan data mesh Formalkan entitas dan relasi ontology untuk workflow tersebut, lalu hubungkan agen ke data products dengan lineage serta ambang kualitas. Di sinilah sebagian besar upaya “agentic” mati, karena tim tidak mampu menyelaraskan asset IDs, jendela waktu, atau taksonomi event lintas sistem. Secara operasional, “contracting” bukan sekadar menyepakati skema. Ini menuntut: - **Data freshness SLA:** tingkat keterlambatan yang masih dapat diterima untuk setiap masukan (telemetry vs inventory vs riwayat alarm sering memiliki batasan berbeda). - **Ambang kualitas:** apa yang membuat masukan dianggap tidak layak (counter yang hilang, celah melebihi toleransi, pemetaan cell yang tidak konsisten). - **Lineage traceability:** dari mana setiap field berasal dan bagaimana transformasi diterapkan. - **Fallback behaviors:** apa yang dilakukan agen saat data product gagal melewati quality gates (misalnya menolak bertindak; meminta masukan manusia; beralih ke kebijakan konservatif yang sudah disetujui). Ini mencegah agen bertindak berdasarkan kebenaran yang parsial atau tidak terpetakan—salah satu mode kegagalan paling umum pada deployment telekom. ### Fase 3: eksekusi tool-calling yang dikendalikan Perkenalkan tool-calling dengan permissioning: - baca-only terlebih dahulu (tool telemetry dan inventaris), - dry-run untuk konfigurasi diff, - eksekusi bertahap dengan approval gates. Gunakan logika kerangka tata kelola yang mirip dengan empat dimensi IMDA (risk bounding, accountability, technical controls, end-user responsibility), diterjemahkan menjadi kontrol operasional telekom. ([https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai](https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai?utm_source=pulse.latellu.com&utm_medium=editorial)) Untuk menjaga staging tetap aman, tetapkan “blast radius” yang dapat diterima sebelum otomatisasi: - **Cakupan:** per-cell/per-sektor vs per-klaster vs seluruh armada (fleet-wide). - **Batas ukuran perubahan:** delta parameter maksimum per run. - **Batas konkurensi:** berapa banyak workflow yang bisa dieksekusi serentak. - **Pemicu rollback:** alarm KPI atau kegagalan verifikasi mana yang memicu reversal otomatis atau eskalasi ke manusia. - **Aturan checkpoint manusia:** untuk pilot awal, tautkan approval ke risk classifier (rendah/sedang/tinggi) dan minta sign-off hanya ketika classifier melewati ambang. Dengan cara inilah tata kelola berubah dari teks kebijakan menjadi kontrol operasional. ### Fase 4: buktikan ROI dalam 90 hari Target bisnis harus dapat diukur dalam satu kuartal. McKinsey melaporkan bahwa pada skala, kapabilitas AI memungkinkan operator mencapai 30–70% lebih sedikit trouble tickets, penurunan 55–80% pada biaya operasi network operations center, dan MTTR yang 30–40% lebih cepat—beserta perbaikan pengalaman pelanggan. Angka-angka ini tidak spesifik operator di sini, tetapi menjadi indikator seperti apa “bukti ROI” yang seharusnya terlihat bila instrumentasi dilakukan dengan benar. ([https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/issue-brief-ai-driven-telecom-networks?utm_source=pulse.latellu.com&utm_medium=editorial)) Di bawah ini visualisasi kedua—fokus pada *tiga rentang* yang mendefinisikan target ROI untuk operational observability dan ekonomi tiket.

Komit pada rencana adopsi yang membuat observabilitas dan tool-call governance selesai dibangun dalam hitungan minggu, bukan bulan. Lalu ukur ROI dalam 90 hari menggunakan ekonomi tiket dan MTTR atau outcome energi—kalau tidak, utang integrasi baru akan terkuak belakangan. ## Terapkan pola agen untuk rollout 5G Pada rollout 5G/6G, “action boundary” operasional sering kali berada pada perencanaan dan verifikasi: situs mana yang akan diaktifkan, parameter mana yang distaging, bagaimana memvalidasi kesiapan di OSS inventory, serta memastikan rollout tidak melanggar SLA pelanggan. Workflow agentik berbasis ontology dapat dioperasionalkan dengan memetakan artefak rollout: - rollout work orders, - batasan spektrum dan kapasitas (jika relevan), - inventaris network element, - delta KPI yang diharapkan setelah aktivasi. Meski banyak pembahasan AI-RAN, operator dapat mengikat rollout agen pada apa yang sudah dipublikasikan ekosistem tentang komponen kontrol Open RAN dan AI orchestration di lapisan SMO/RIC. Dokumentasi SMO Ericsson menekankan dukungan RIC non-RT bagi AI/ML workflow termasuk model training dan kebijakan panduan—persis di mana governance dibutuhkan untuk keputusan rollout. ([https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations](https://www.ericsson.com/en/reports-and-papers/white-papers/smo-enabling-intelligent-ran-operations?utm_source=pulse.latellu.com&utm_medium=editorial)) ([https://www.juniper.net/us/en/research-topics/what-is-ric.html](https://www.juniper.net/us/en/research-topics/what-is-ric.html?utm_source=pulse.latellu.com&utm_medium=editorial)) Satu realitas yang perlu dicek sejak awal: tidak semua langkah rollout bisa diautomasi. Ketika risiko rollout tinggi, agentic workflows tetap bisa dipakai dalam mode semi-otonom: agen menghasilkan rencana staging yang terverifikasi, sementara operator menyetujui tool calls. Secara terpisah, Nokia dan vendor lain menggambarkan “deep sleep” serta penghematan energi yang peka terhadap trafik sebagai fitur yang diaktifkan AI. Misalnya, deskripsi Nokia tentang mode extreme deep sleep mengklaim pengurangan konsumsi energi hingga 95% selama periode tidak aktif dengan memprediksi pola trafik dan mengoptimalkan ambang aktivasi. Klaim ini dipublikasikan vendor, tetapi berguna sebagai parameter untuk verifikasi yang ditargetkan oleh agen. ([https://www.nokia.com/blog/ai-builds-the-foundation-for-zero-energy-use-at-zero-traffic/](https://www.nokia.com/blog/ai-builds-the-foundation-for-zero-energy-use-at-zero-traffic/?utm_source=pulse.latellu.com&utm_medium=editorial)) Perlakukan rollout sebagai proyek integrasi yang membutuhkan observabilitas. Instrumentasi keluaran agen yang digunakan untuk menyetujui aksi rollout, lalu verifikasi KPI setelah setiap aktivasi bertahap. Tujuan bukan “rollout sepenuhnya otonom.” Tujuannya adalah “lebih sedikit kejutan rollout dengan bukti keputusan yang bisa ditelusuri.” Agar observabilitas rollout bersifat operasional (bukan retrospektif), tetapkan template “proof of safety” khusus rollout untuk setiap batch bertahap: - **Pemeriksaan prasyarat (tool read-only):** kelengkapan inventaris, baseline hardware/konfigurasi yang diharapkan, serta batasan spektrum/kapasitas (atau padanan relevan dalam sistem perencanaan). - **Artefak rencana (ontology-grounded):** work orders dan network elements yang dipilih agen, serta kendala apa yang mendorong pemilihan tersebut. - **Metrik verifikasi:** proksi dampak ke pelanggan dan KPI radio/layanan yang dipantau setelah aktivasi (misalnya ketersediaan, proksi keberhasilan panggilan, band throughput/latency, tingkat alarm kunci). - **Aturan stop/go:** ambang eksplisit yang memicu penghentian batch, rollback, atau eskalasi ke manusia. - **Attribution:** kaitkan plan-run ID agen ke verification run, agar terbukti apakah keputusan konfigurasi berkorelasi dengan outcome SLA. Dalam praktik, ini mengubah “risiko rollout” menjadi amplop rekayasa yang terukur—sehingga otonomi berikutnya bisa diperluas hanya bila bukti mendukungnya. ## Checklist operator untuk infrastruktur agentik Manajer telekom sering meminta “arsitektur terbaik.” Namun dalam praktik, artefak yang paling menentukan justru membosankan—tetapi krusial: - izin tool dan approval gates untuk setiap aksi yang dapat dilakukan agen, - data contracts untuk telemetry, inventory, dan riwayat insiden, - cakupan ontology untuk entitas dan kendala pada workflow pertama, - operational observability yang menelusuri dari tool call ke outcome KPI, - rencana pengukuran 90 hari yang dikaitkan ke MTTR, volume tiket, atau KPI energi. Kerangka tata kelola untuk agentic AI yang menekankan risk bounding dan technical controls mendukung pendekatan ini bahkan di luar negara mana pun. Model IMDA menegaskan pembatasan risiko sejak awal dan implementasi kontrol teknis. ([https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai](https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai?utm_source=pulse.latellu.com&utm_medium=editorial)) Untuk pengadaan dan manajemen program: jadikan deliverables instrumentasi sebagai syarat dalam kontrak pengantaran (delivery contract). Jangan menerima “kami mengintegrasikan AI” tanpa bukti bahwa tim bisa menjawab: tool call apa yang persis dilakukan, data product inputs apa yang digunakan, dan outcome apa yang terjadi. Bila targetnya ROI, geser bahasa pengadaan dari “kapabilitas AI” menjadi “bukti aksi yang dikendalikan.” Pada kuartal pertama, harus ada kemampuan untuk memutar ulang keputusan agen, mengaudit input tool, dan menunjukkan delta KPI yang terkait dengan aksi-aksi tersebut. ## Penutup: tuntut kontrol go-live yang dapat ditelusuri Jadikan traceable tool-calling sebagai kebutuhan produksi: bangun operasional telekom berbasis agentik dengan governed execution boundaries, decisioning yang bertumpu pada ontology, data contracts yang bisa diaudit, serta operational observability yang mengaitkan setiap aksi ke outcome KPI yang terukur.

Trending Topics

Browse by Category

Trending Topics

Browse by Category