Microsoft Foundry: Platform AI Agen Perusahaan Azure

Nama Microsoft Foundry mulai muncul di banyak dokumen teknis Azure setelah Microsoft mengganti penyebutan Azure AI Foundry, yang sebelumnya dikenal sebagai Azure AI Studio. Perubahan nama itu bukan sekadar penyegaran merek, melainkan penanda pergeseran fokus: dari tempat mencoba model menjadi pabrik aplikasi dan agen AI berskala perusahaan. Bagi tim yang sedang menimbang platform untuk membangun asisten internal, agen layanan pelanggan, atau alur kerja multi-agen, memahami apa yang sebenarnya ditawarkan platform ini menentukan arah arsitektur untuk beberapa tahun ke depan.

Microsoft Foundry Adalah Platform AI Perusahaan untuk Membangun dan Mengelola Agen

Microsoft Foundry adalah platform AI perusahaan dari Microsoft untuk membangun, membumikan, dan mengatur aplikasi serta agen AI dalam skala besar. Platform ini menyatukan seluruh siklus hidup agen, mulai dari pengembangan terbuka, kecerdasan bawaan, hingga kontrol keamanan, kepatuhan, dan kebijakan yang konsisten pada setiap agen.

Definisi resmi itu menekankan tiga kata kerja: build, ground, dan govern. Membangun berarti menyediakan model dan kerangka kerja. Membumikan berarti menghubungkan agen dengan data perusahaan. Mengatur berarti memberi kendali atas identitas, jaringan, keamanan konten, dan kebijakan.

Dokumentasi Microsoft Learn menyebut Foundry sebagai platform terpercaya yang menyatukan agen, model, dan alat di bawah satu grup pengelolaan. Kemampuan kesiapan perusahaan seperti pelacakan, pemantauan, evaluasi, dan konfigurasi tata kelola sudah tersedia sejak awal, bukan ditambahkan belakangan.

Satu hal yang membedakan penataan baru ini adalah penyederhanaan bidang kendali. Pengelolaan berjalan melalui kontrol akses berbasis peran, jaringan, dan kebijakan yang terpadu di bawah satu namespace penyedia sumber daya Azure.

Mengapa Namanya Berubah dari Azure AI Foundry

Pengumuman perubahan nama disampaikan pada rangkaian acara Ignite. Pergeseran itu menempatkan Foundry sebagai pilar ketiga di samping Microsoft 365 dan Microsoft Fabric.

Pembagian peran tiga pilar tersebut cukup jelas:

• Microsoft 365 menjadi permukaan produktivitas tempat pengguna akhir bekerja, termasuk Copilot, Teams, dan Outlook.

• Microsoft Fabric menjadi fondasi data yang tertata dan terkelola.

• Microsoft Foundry menjadi pabrik agen yang berdiri di atas data dan infrastruktur tersebut.

Model mental lama menganggap platform ini sebagai tempat mencoba model, menyebarkan endpoint, lalu menyambungkannya ke aplikasi. Model mental baru menempatkan agen, alat, alur kerja, dan observabilitas sebagai komponen kelas satu yang bisa disusun ulang.

Perubahan itu juga menyentuh terminologi dan API. Tabel berikut merangkum pemetaan konsep lama ke konsep baru sesuai dokumentasi resmi.

Dimensi	Sebelumnya	Sekarang
Merek platform	Azure AI Studio / Azure AI Foundry	Microsoft Foundry
Merek layanan kognitif	Azure AI Services	Foundry Tools
Portal	Foundry (classic)	Foundry
API agen	Assistants API (Agents v0.5/v1)	Responses API (Agents v2)
Versi API	Parameter api-version bulanan	Rute stabil v1 (/openai/v1/)
Model sumber daya	Hub + Azure OpenAI + Azure AI Services	Sumber daya Foundry tunggal dengan proyek
Terminologi runtime	Threads, Messages, Runs, Assistants	Conversations, Items, Responses, Agent Versions

Proyek berbasis hub masih dapat diakses melalui portal Foundry (classic). Investasi pengembangan baru difokuskan pada proyek Foundry di portal generasi berikutnya.

Bagi organisasi yang sudah memakai Azure OpenAI, tersedia jalur peningkatan sumber daya menjadi sumber daya Foundry. Endpoint, kunci API, dan status yang sudah ada tetap dipertahankan sehingga migrasi tidak memaksa penulisan ulang aplikasi.

Lima Pilar Kemampuan Microsoft Foundry

Halaman produk resmi menata Foundry ke dalam lima kelompok kemampuan. Struktur ini berguna sebagai peta ketika menilai kesesuaian platform dengan kebutuhan tim.

1. Foundry Models: Katalog Model Lintas Penyedia

Katalog model menjadi daya tarik paling langsung. Halaman produk menyebut akses ke lebih dari 11.000 model, mencakup model fondasi, model terbuka, model penalaran, multimodal, dan model spesifik industri.

Penyedia yang tercakup meliputi OpenAI, Anthropic, Meta, Google, xAI, Hugging Face, serta keluarga multimodal MAI milik Microsoft. Dokumentasi Microsoft Learn menyebut angka lebih dari 1.900 model pada katalog Foundry Models, sehingga terdapat selisih penyebutan antara halaman pemasaran dan dokumentasi teknis [perlu verifikasi sumber].

Beberapa kemampuan pendukung melengkapi katalog tersebut:

• Kustomisasi model melalui pelatihan, penyetelan halus, distilasi, dan peningkatan otomatis dengan penulisan kode minimal.

• Model Router yang memilih model paling sesuai untuk setiap tugas secara dinamis, sehingga optimasi biaya dan kualitas berjalan tanpa menulis ulang aplikasi.

• Endpoint dan kredensial tunggal, sehingga pergantian model tidak memaksa perubahan kode aplikasi.

Catatan pada blog teknis menyebut penghematan biaya hingga sekitar 50 persen dari pemakaian Model Router. Angka itu bergantung pada pola beban kerja, sehingga verifikasi melalui evaluasi internal tetap diperlukan sebelum dijadikan asumsi anggaran.

2. Foundry Agent Service dan Kerangka Kerja Agen

Layanan agen menjadi perekat yang mengelola percakapan, pemanggilan alat, keamanan, identitas, dan observabilitas. Peran itu memindahkan beban orkestrasi dari kode aplikasi ke platform.

Dokumentasi membedakan dua jenis agen yang bisa dibuat:

Jenis agen	Cara pembuatan	Cocok untuk
Prompt agent	Deklaratif melalui portal atau SDK	Agen berbasis instruksi dan alat bawaan
Hosted agent	Menjalankan kode milik organisasi sendiri	Logika kustom, runtime bebas kerangka kerja

Hosted agent berjalan pada komputasi yang dirancang khusus untuk agen, lengkap dengan sandbox tingkat mesin virtual dan sistem berkas persisten. Pendekatan itu menjawab kebutuhan agen yang menjalankan proses panjang atau memerlukan isolasi ketat.

Dari sisi kerangka kerja, Microsoft Agent Framework menjadi SDK sumber terbuka yang menyatukan Semantic Kernel dan AutoGen. Kerangka itu mendukung pola orkestrasi sekuensial, group chat, hingga handoff antar agen.

Baca juga Tencent Cloud Free Tier: 30+ Produk Gratis

Fitur pelengkap yang layak diperhatikan mencakup Agent Optimizer untuk mengevaluasi agen dan menghasilkan instruksi yang lebih baik, serta memori agen yang kini mendukung memori prosedural dan kontrol masa berlaku. Skill agen berbasis berkas SKILL.md yang dikelola terpusat memungkinkan penambahan panduan perilaku yang dapat dipakai ulang.

3. Foundry IQ, Tools, dan Lapisan Pengetahuan

Membumikan agen pada data perusahaan menjadi bagian tersulit dalam banyak proyek. Foundry IQ menjawab kebutuhan itu sebagai evolusi dari Azure AI Search.

Foundry IQ adalah sistem pengetahuan yang menghubungkan agen ke data di berbagai sumber seperti OneLake, Amazon S3, dan Snowflake, lalu mengubah pengambilan data menjadi proses penalaran dinamis, bukan sekadar satu kali pencarian vektor.

Pendekatan itu berbeda dari pola pencarian tunggal. Agen dapat melakukan beberapa putaran pengambilan data, menilai relevansi, lalu menyusun jawaban dengan rujukan yang bisa diperiksa.

Di sisi alat, Foundry Tools menyediakan katalog yang mencakup server Model Context Protocol, API berbasis OpenAPI, serta konektor ke aplikasi SaaS. Katalog ini memungkinkan agen berbicara dengan sistem bisnis seperti Salesforce atau SAP tanpa integrasi buatan sendiri untuk setiap kasus.

Toolboxes melengkapi katalog dengan cara mengumpulkan, mengonfigurasi, dan memakai ulang alat dari satu endpoint terkelola. Routines menambahkan kemampuan menjalankan proses terjadwal dan berulang, misalnya agen pemantau risiko SLA yang berjalan tanpa pemicu manual.

4. Observabilitas dan Kepercayaan

Agen yang berjalan di produksi memerlukan jejak yang bisa ditelusuri. Foundry menyediakan pelacakan, pemantauan, dan evaluasi melalui dasbor bawaan.

Dukungan OpenTelemetry membuat jejak agen dapat digabungkan dengan telemetri sistem lain. Kemampuan itu penting ketika satu permintaan pengguna melintasi beberapa agen, alat, dan basis data.

Beberapa kapabilitas dalam kelompok ini:

• Evaluasi bawaan dengan metrik seperti groundedness, relevansi, koherensi, dan kemiripan.

• Benchmarks untuk pemeriksaan kualitas model dan agen secara berulang.

• Evaluator rubrik yang dihasilkan otomatis agar penilaian menyesuaikan konteks tugas.

• Guardrail dan penyaring konten untuk menjaga kepatuhan kebijakan AI yang bertanggung jawab.

• Foundry Control Plane untuk identitas Microsoft Entra, kontrol akses berbasis peran, isolasi jaringan, dan Azure Policy.

Halaman dokumentasi resmi memuat panduan terperinci tentang cara mengaktifkan pelacakan dan menjalankan evaluasi. Referensi dokumentasi Microsoft Foundry di Microsoft Learn menjadi titik masuk paling akurat karena diperbarui mengikuti rilis.

5. Local dan Edge melalui Foundry Local

Tidak semua beban kerja cocok berjalan di awan. Foundry Local menjawab kebutuhan inferensi pada perangkat pengguna.

Foundry Local adalah solusi AI lokal menyeluruh untuk membangun aplikasi yang berjalan sepenuhnya di perangkat pengguna, dilengkapi SDK asli untuk C#, JavaScript, Python, dan Rust, katalog model yang dioptimalkan, serta akselerasi perangkat keras otomatis dalam paket berukuran sekitar 20 MB.

Ukuran paket yang ringan menjadi pertimbangan praktis. Aplikasi yang didistribusikan ke pengguna akhir tidak membengkak hanya karena menyertakan runtime AI.

Foundry Local telah mencapai status ketersediaan umum dengan dukungan lintas platform untuk Windows, macOS, dan Android. Runtime berbasis ONNX menjadi fondasi untuk menjalankan model bahasa kecil secara efisien.

Pola hibrida menjadi kasus pemakaian yang menonjol. Aplikasi dapat mengarahkan permintaan ringan ke Foundry Local dan mengalihkan permintaan berat ke Microsoft Foundry di awan, semuanya dikelola dari bidang kendali yang sama.

Arsitektur Microsoft Foundry dan Alur Permintaan

Pemahaman arsitektur mencegah kesalahan asumsi yang cukup umum. Portal Foundry berperan sebagai pengalaman pengembang dan lapisan konfigurasi, bukan jalur lalu lintas produksi.

Alur khas aplikasi tanya jawab yang membumi pada dokumen internal berjalan seperti ini:

1. Pengguna mengirim pertanyaan melalui aplikasi web, seluler, atau Teams.

2. Aplikasi meneruskan pertanyaan ke API backend milik organisasi.

3. Backend mengambil potongan dokumen relevan dari lapisan pencarian.

4. Backend menyusun prompt berisi pertanyaan dan konteks, lalu memanggil endpoint model.

5. Jawaban beserta rujukan dikirim balik ke pengguna.

6. Telemetri dan log audit dialirkan ke sistem pemantauan.

Implikasinya penting bagi tim keamanan. Otorisasi tingkat aplikasi, pencatatan, dan penerapan kebijakan tetap menjadi tanggung jawab kode backend, meski platform menyediakan banyak kontrol.

Sumber Daya Azure yang Biasanya Menyertai

Solusi Foundry umumnya bersandar pada beberapa layanan Azure lain. Komposisinya bergantung pada pola aplikasi.

Komponen	Peran dalam solusi	Catatan operasional
Sumber daya Foundry	Bidang kendali, proyek, koneksi	Satu sumber daya dengan beberapa proyek anak
Endpoint model	Inferensi model bahasa	Ketersediaan model bergantung wilayah dan kuota
Lapisan pencarian	Pengambilan data untuk pembumian	Kualitas bergantung strategi pemotongan dokumen
Penyimpanan objek	Sumber dokumen untuk indeks	Gunakan akses privat, bukan anonim
Key Vault	Penyimpanan rahasia dan kunci	Rotasi kunci sebaiknya otomatis
Azure Monitor	Log, metrik, dan peringatan	Biaya ingesti perlu dikendalikan
Microsoft Entra ID	Identitas dan kontrol akses	Utamakan identitas terkelola

Menempatkan seluruh komponen di wilayah yang sama menurunkan latensi dan biaya keluar data. Rancangan lintas wilayah sebaiknya dipakai hanya ketika ketahanan atau residensi data menuntutnya.

Hierarki Proyek dan Sumber Daya

Foundry memakai proyek untuk menata model, sumber daya, data, dan aset lain yang mendukung satu solusi AI. Setiap proyek terhubung dengan sumber daya Foundry di langganan Azure.

Satu sumber daya induk dapat menaungi beberapa proyek anak. Konfigurasi dan layanan yang diterapkan pada induk berlaku untuk proyek di bawahnya, sehingga pemisahan tugas antar tim lebih mudah diatur.

Baca juga Panduan Lengkap Amazon S3 : Fitur dan Cara Pakai

Portal menampilkan pengelompokan halaman yang mencerminkan siklus kerja:

• Discover untuk menelusuri model dan layanan terbaru serta menemukan titik awal pengembangan.

• Build untuk mengelola agen, alur kerja, penyebaran model, alat, pengetahuan, guardrail, memori, indeks data, dan evaluasi.

• Operate untuk mengelola aset, kepatuhan kebijakan keamanan, konfigurasi kuota, dan tugas administrasi.

• Docs untuk akses cepat ke dokumentasi.

Setiap proyek memiliki kunci API, endpoint proyek, dan endpoint Azure OpenAI. Ketiga nilai itu memungkinkan aplikasi klien mengakses model, agen, dan aset lain secara aman.

Workflow Builder: Orkestrasi Visual untuk Alur Multi-Agen

Kemampuan yang paling mengubah cara kerja tim pengembang adalah Workflows. Fitur ini menyediakan cara deklaratif berbasis antarmuka untuk menyusun rangkaian aksi.

Alih-alih menulis logika percabangan secara manual di kode aplikasi, tim menggambar graf yang berisi beberapa jenis simpul:

• Simpul agen yang menjalankan tugas tertentu.

• Simpul logika seperti If/Else, For Each, dan Go To.

• Simpul data untuk menetapkan variabel dan mengurai nilai.

• Simpul obrolan dasar untuk mengirim pesan atau mengajukan pertanyaan.

Foundry menjalankan orkestrasi tersebut lengkap dengan pelacakan dan evaluasi. Pola umum tersedia sebagai templat bawaan.

Pola alur kerja	Cara kerja	Contoh kasus
Sequential	Hasil satu agen diteruskan ke agen berikutnya	Pipeline multi-tahap pengolahan dokumen
Human-in-the-loop	Alur berhenti untuk persetujuan manusia	Proses KYC, kepatuhan, tindakan berisiko tinggi
Group chat	Beberapa agen berkolaborasi dengan manajer penentu urutan bicara	Skema pembuat dan pemeriksa, panel ahli

Pola serupa bisa ditulis manual memakai Semantic Kernel atau orkestrator kustom. Perbedaannya terletak pada sifatnya yang visual, terkelola, dan dapat diamati sejak hari pertama.

Kasus Pemakaian Nyata di Berbagai Sektor

Foundry paling sering dipakai untuk aplikasi AI generatif yang membutuhkan tata kelola. Beberapa pola berikut berulang di banyak organisasi.

Tanya Jawab Kebijakan Internal

Karyawan sering kesulitan menemukan kebijakan sumber daya manusia atau keamanan yang tepat. Agen yang terhubung ke indeks kebijakan dapat menjawab dengan rujukan ke dokumen aslinya.

Contoh pertanyaan yang khas menyangkut ketentuan reimbursement perjalanan atau prosedur penggantian kunci layanan. Jawaban dengan sitasi mengurangi risiko salah tafsir.

Pendampingan Agen Layanan Pelanggan

Agen manusia kehilangan waktu ketika harus mencari basis pengetahuan saat percakapan berlangsung. Alat pendamping yang mengusulkan langkah penyelesaian mempercepat penanganan.

Skenario ini menuntut latensi rendah. Prompt ringkas, jumlah potongan dokumen yang terkendali, dan respons streaming menjadi kunci pengalaman yang terasa responsif.

Peringkasan Tiket dan Penyusunan Tindak Lanjut

Utas tiket yang panjang menurunkan konsistensi penanganan. Templat prompt dan evaluasi berkala menjaga kualitas ringkasan tetap stabil.

Contoh nyata mencakup peringkasan utas insiden berisi puluhan pesan menjadi ringkasan singkat, disertai draf pembaruan untuk pelanggan.

Asisten Runbook untuk Tim Teknis

Insinyur yang bertugas jaga kehilangan waktu menavigasi runbook dan laporan pascainsiden. Agen yang membumi pada runbook berformat Markdown menjawab pertanyaan operasional dengan langkah berurutan.

Triase dan Perutean Dokumen Masuk

Surel dan formulir masuk perlu diklasifikasikan dan diarahkan secara akurat. Iterasi prompt yang diuji terhadap sampel berlabel membuat akurasi klasifikasi dapat diukur.

Pengayaan Katalog Produk

Deskripsi produk yang tidak konsisten dan atribut yang hilang menghambat konversi. Pengujian prompt dalam jumlah besar membantu menghasilkan deskripsi standar beserta penafian keselamatan yang seragam.

Sektor yang paling aktif memakai pola ini mencakup jasa keuangan, kesehatan dan ilmu hayati, ritel, manufaktur, sektor publik, serta perusahaan perangkat lunak. Masing-masing menambahkan kendala kepatuhan yang memengaruhi rancangan jaringan dan penyimpanan log.

Model Biaya Microsoft Foundry dan Faktor Pendorong Tagihan

Platform ini memakai penetapan harga berbasis konsumsi. Setiap layanan memiliki model penagihan dan harga masing-masing.

Foundry sendiri berperan sebagai pengalaman pengembangan dan bidang kendali. Biaya utama umumnya berasal dari layanan yang dipakai di baliknya.

Sumber biaya	Dasar penagihan	Catatan pengendalian
Inferensi model	Token masukan dan keluaran	Pendorong biaya terbesar pada aplikasi obrolan
Layanan pencarian	Kapasitas unit, replika, dan partisi	Sesuaikan ukuran dengan volume kueri nyata
Penyimpanan objek	Volume data, transaksi, transfer	Umumnya kecil untuk korpus dokumen terbatas
Jaringan	Bandwidth dan keluar data	Satukan wilayah untuk menekan biaya
Pemantauan	Ingesti dan retensi log	Terapkan sampling dan batas retensi

Beberapa pendorong biaya yang sering terlewat:

• Panjang prompt yang bertambah karena riwayat percakapan tidak diringkas.

• Jumlah potongan dokumen yang diambil terlalu banyak pada setiap permintaan.

• Instruksi sistem yang bertele-tele dan diulang pada setiap panggilan.

• Lingkungan CI/CD yang menyalakan sumber daya duplikat tanpa pengawasan.

• Pencatatan verbose atas prompt dan respons, yang menambah biaya sekaligus risiko keamanan.

Langkah penghematan yang terbukti praktis meliputi pemilihan model paling murah yang masih memenuhi kualitas, penerapan cache pada kueri berulang, pembatasan token keluaran, dan peringkasan riwayat percakapan. Estimasi awal sebaiknya disusun melalui kalkulator harga Azure karena harga bervariasi menurut wilayah dan model.

Halaman produk menyebut skala adopsi yang cukup besar, dengan pemakaian oleh pengembang di lebih dari 80.000 perusahaan dan digital native, termasuk 80 persen perusahaan Fortune 500. Angka tersebut menggambarkan kematangan ekosistem, bukan jaminan kesesuaian untuk setiap organisasi.

Langkah Praktis Memulai Proyek Microsoft Foundry

Latihan resmi memperkirakan waktu sekitar 30 menit untuk membuat dan menjelajahi proyek pertama. Urutan berikut mengikuti alur yang didokumentasikan.

1. Buat grup sumber daya di portal Azure sebagai wadah semua aset percobaan.

2. Buat proyek Foundry dengan nama unik, lalu tentukan sumber daya Foundry, langganan, grup sumber daya, dan wilayah yang direkomendasikan.

3. Tinjau sumber daya induk melalui menu nama proyek, lalu pilih opsi melihat semua sumber daya untuk memahami hierarki.

4. Sebarkan model obrolan dari katalog pada halaman Discover, misalnya model kelas mini untuk menekan pemakaian kuota.

5. Uji model di playground dengan prompt sederhana dan satu prompt lanjutan untuk memeriksa kesinambungan konteks.

6. Catat endpoint proyek dan kunci API yang diperlukan aplikasi klien.

7. Hubungkan aplikasi klien memakai endpoint proyek, bukan endpoint Azure OpenAI.

8. Hapus grup sumber daya setelah percobaan selesai agar tidak menimbulkan biaya berjalan.

Satu kesalahan yang sering terjadi pada langkah ketujuh adalah memakai endpoint yang salah. Endpoint proyek dan endpoint Azure OpenAI memiliki bentuk berbeda dan tidak dapat dipertukarkan.

Portal juga menyediakan bantuan berbasis AI melalui panel Ask AI. Panel itu dapat menjawab pertanyaan tentang kemampuan platform selama eksplorasi berjalan.

Prasyarat yang Perlu Disiapkan

Sebelum memulai, beberapa hal perlu dipastikan tersedia:

• Langganan Azure aktif dengan metode penagihan yang berlaku.

• Izin pembuatan sumber daya pada grup sumber daya, umumnya peran Contributor untuk lingkungan latihan.

• Wilayah yang mendukung model yang dibutuhkan, karena ketersediaan model berbeda antar wilayah.

• Kuota yang memadai untuk penyebaran model, karena penyebaran tunduk pada kuota regional.

Eksplorasi platform dapat dilakukan tanpa akun Azure. Pembuatan agen memerlukan langganan Azure yang aktif.

Organisasi dengan kebijakan yang melarang autentikasi berbasis kunci dapat memakai autentikasi Entra ID. Pendekatan itu menuntut pendaftaran aplikasi di tenant, yang biasanya memerlukan izin administrator global.

Integrasi dengan Ekosistem Microsoft

Nilai tambah terbesar Foundry bagi organisasi yang sudah memakai produk Microsoft terletak pada integrasi. Perpindahan konteks berkurang dan beban operasional lebih ringan.

Alat Pengembang

Integrasi dengan lingkungan pengembangan menjadi titik masuk paling sering dipakai:

• Visual Studio Code melalui Foundry Toolkit untuk membangun, menguji, dan menyebarkan aplikasi AI.

• GitHub Copilot untuk mempercepat produktivitas penulisan kode.

• Microsoft Copilot Studio untuk membangun agen yang memperluas Microsoft 365 Copilot dengan akses ke Foundry Models, Foundry IQ, dan alat MCP.

SDK tersedia untuk Python, JavaScript, .NET, dan Java. Klien proyek terpadu azure-ai-projects versi 2.x menggantikan kumpulan paket terpisah yang sebelumnya dipakai untuk endpoint berbeda.

Distribusi Agen ke Microsoft 365

Agen yang dibangun di Foundry dapat dipublikasikan ke Microsoft 365 Copilot dan Teams. Tata kelola distribusi berjalan melalui Agent 365.

Kemampuan itu menutup jarak antara tim pembangun agen dan pengguna akhir. Agen tidak perlu antarmuka baru karena hadir di tempat kerja yang sudah dipakai sehari-hari.

Kerangka Kerja Sumber Terbuka

Foundry mendukung integrasi dengan protokol dan kerangka kerja terbuka, termasuk sumber pengetahuan pihak ketiga, alat kustom, dan model di luar katalog resmi. Dukungan untuk LangChain dan Semantic Kernel terdokumentasi.

Komunitas pengembang berkumpul di organisasi GitHub resmi. Repositori Microsoft Foundry di GitHub memuat contoh dokumentasi, server MCP, templat aplikasi web agen, laboratorium Foundry Local, hingga tutorial AI bertahap.

Keamanan, Tata Kelola, dan Kepatuhan

Kontrol keamanan menjadi alasan utama banyak organisasi memilih platform terkelola dibandingkan menyusun sendiri. Foundry menerapkan kontrol pada beberapa lapisan.

Identitas dan Kontrol Akses

Autentikasi pengguna berjalan melalui Microsoft Entra ID. Otorisasi memakai kontrol akses berbasis peran Azure pada lingkup langganan, grup sumber daya, atau sumber daya.

Pembatasan yang layak diterapkan mencakup siapa yang boleh menyebarkan model, siapa yang boleh melihat kunci dan endpoint, serta siapa yang boleh mengubah indeks dan sumber data. Untuk aplikasi, identitas terkelola lebih dianjurkan daripada kunci API.

Isolasi Jaringan

Lingkungan pengembangan sering dimulai dengan endpoint publik yang dibatasi aturan firewall alamat IP. Lingkungan produksi sebaiknya memakai private endpoint untuk endpoint model, layanan pencarian, dan penyimpanan.

Kompleksitas DNS menjadi sumber gangguan yang paling sering muncul pada rancangan private endpoint. Resolusi nama harus berfungsi lintas jaringan virtual dan dari lingkungan on-premise.

Penanganan Prompt dan Log

Prompt dan respons perlu diperlakukan sebagai data sensitif. Pencatatan penuh sebaiknya dihindari kecuali sudah melalui persetujuan dan penyuntingan data pribadi.

Log yang aman untuk pemecahan masalah biasanya berisi ID permintaan, latensi, kode status, alasan pembatasan laju, serta jumlah token dan metrik biaya. Isi prompt lengkap justru menambah risiko tanpa banyak manfaat diagnostik.

Ancaman Khas Aplikasi Berbasis Model Bahasa

Pemodelan ancaman untuk aplikasi AI generatif menyoroti beberapa risiko spesifik:

• Prompt injection, ketika instruksi berbahaya diselipkan pada masukan pengguna atau dokumen yang diambil.

• Eksfiltrasi data melalui keluaran model yang membocorkan informasi di luar hak akses pemohon.

• Peracunan pengambilan data, ketika dokumen berbahaya masuk ke indeks pencarian.

Mitigasi yang dianjurkan meliputi perlakuan konten hasil pengambilan sebagai tidak terpercaya, validasi sumber melalui daftar izin, pemisahan instruksi dari teks dokumen, serta instruksi sistem yang secara eksplisit menolak mengikuti perintah dari isi dokumen. Pengujian dengan contoh adversarial perlu berjalan berkala.

Panduan resmi tentang penggunaan AI yang bertanggung jawab tersedia sebagai bagian dari dokumentasi platform. Prinsip Responsible AI dari Microsoft memberi kerangka kebijakan yang dapat diadopsi organisasi.

Perbandingan Microsoft Foundry dengan Alternatif Lain

Pemilihan platform bergantung pada beban kerja utama dan kematangan tim. Tabel berikut merangkum posisi Foundry terhadap opsi lain.

Opsi	Paling cocok untuk	Kekuatan	Keterbatasan
Microsoft Foundry	Aplikasi dan agen AI generatif dengan tata kelola	Katalog model luas, alur agen terpadu, kontrol Azure bawaan	Bergantung ketersediaan model dan kuota per wilayah
Azure Machine Learning	Siklus hidup machine learning penuh	Pelatihan, pipeline, registri model, pola penyebaran	Kurva belajar berat untuk prototipe aplikasi model bahasa
Endpoint model langsung plus aplikasi kustom	Tim dengan kematangan platform tinggi	Fleksibilitas maksimal, sedikit keterikatan platform	Pola pembumian, evaluasi, dan tata kelola dirakit sendiri
Microsoft Copilot Studio	Copilot low-code dan otomasi bisnis	Pembuatan cepat, integrasi Microsoft 365	Kendali tingkat infrastruktur lebih terbatas
Platform GenAI penyedia awan lain	Organisasi yang standar pada awan tersebut	Akses model terkelola dan pola pengambilan data	Model identitas dan jaringan berbeda, friksi migrasi
Tumpukan mandiri di Kubernetes	Kebutuhan self-hosting penuh	Kustomisasi tinggi, opsi hibrida dan on-premise	Beban operasi, penskalaan, dan penambalan keamanan

Foundry menjadi pilihan wajar ketika organisasi membangun aplikasi AI generatif, memerlukan tata kelola perusahaan, menginginkan jalur standar untuk pembumian data, dan lebih nyaman dengan ruang kerja bersama daripada kumpulan notebook.

Pilihan lain lebih tepat pada beberapa kondisi. Kebutuhan pelatihan model kustom dan siklus machine learning lengkap mengarah ke Azure Machine Learning. Kewajiban menjalankan model sepenuhnya di klaster sendiri mengarah ke tumpukan sumber terbuka pada Kubernetes.

Keterbatasan dan Hal yang Sering Menjadi Sandungan

Platform yang bergerak cepat membawa konsekuensi operasional. Beberapa hal berikut layak diperhitungkan sejak perencanaan.

• Pergeseran merek dan fitur membuat jalur antarmuka serta nama layanan berubah, sehingga runbook internal perlu diperbarui berkala.

• Batasan wilayah dan model membuat migrasi antar wilayah tidak sepele ketika model tertentu tidak tersedia.

• Kuota dan pembatasan laju dapat mengganggu produksi jika aplikasi tidak dirancang dengan antrean dan backpressure.

• Kualitas pengambilan data bergantung pada strategi pemotongan dokumen dan penataan indeks, bukan hanya pada model.

• Batas tanggung jawab keamanan sering disalahpahami karena portal bukan jalur runtime produksi.

• Kompleksitas private endpoint menjadikan kesalahan DNS dan perutean sebagai penyebab gangguan yang berulang.

• Evaluasi bukan pekerjaan sekali jadi karena pergeseran domain dan dokumen baru menuntut penilaian ulang.

Satu perubahan yang perlu diperhatikan tim lama adalah pengumuman penghentian Prompt Flow. Panduan migrasi resmi mengarahkan beban kerja agen produksi baru ke Foundry Agent Service.

Beberapa penulis teknis juga mencatat bahwa penyebutan nama produk belum konsisten di seluruh dokumentasi publik pada masa transisi. Verifikasi nama layanan dan SKU pada dokumen resmi tetap diperlukan sebelum adopsi produksi.

Praktik Baik Menjalankan Microsoft Foundry di Produksi

Rekomendasi berikut berasal dari pola yang berulang pada penerapan berskala perusahaan.

Arsitektur dan Lingkungan

• Pisahkan lingkungan pengembangan, pengujian, dan produksi minimal pada tingkat grup sumber daya, lebih baik pada langganan berbeda.

• Tempatkan endpoint model, layanan pencarian, penyimpanan, dan aplikasi di wilayah yang sama.

• Terapkan gerbang evaluasi pada proses rilis sehingga perubahan prompt atau konfigurasi diuji sebelum naik ke produksi.

• Abstraksikan panggilan model di backend agar pergantian model tidak menyentuh banyak berkas.

Keandalan dan Kinerja

• Rancang untuk batas laju dengan antrean, retry berjenjang, dan backoff.

• Tambahkan circuit breaker serta penurunan fungsi yang halus ketika layanan hulu bermasalah.

• Pakai respons streaming untuk menurunkan latensi yang dirasakan pengguna.

• Ambil lebih sedikit potongan dokumen dengan kualitas peringkat yang lebih baik.

Tata Kelola dan Penamaan

• Terapkan konvensi penamaan sumber daya yang konsisten sejak awal.

• Beri tag pada setiap sumber daya, minimal untuk lingkungan, pemilik, pusat biaya, klasifikasi data, dan aplikasi.

• Gunakan Azure Policy untuk memaksa wilayah yang disetujui, private endpoint, dan pengaturan diagnostik.

• Bangun runbook untuk rotasi kunci dan tanggapan insiden.

Observabilitas

• Aktifkan pengaturan diagnostik pada setiap layanan pendukung dan arahkan ke Log Analytics atau Event Hub untuk integrasi SIEM.

• Pantau volume token, tren biaya, kueri teratas, dan alasan kegagalan.

• Pasang peringatan untuk lonjakan galat, peristiwa pembatasan laju, dan kenaikan latensi pencarian.

• Waspadai pola perulangan agen yang tak terkendali karena berdampak langsung pada biaya.

Peta Belajar untuk Tim yang Baru Mengadopsi

Proyek Foundry berjalan lebih lancar ketika fondasi Azure sudah dipahami. Materi berikut menjadi prasyarat yang paling relevan.

Sebelum menyentuh Foundry, tim sebaiknya menguasai:

1. Dasar Azure, mencakup langganan, grup sumber daya, kontrol akses berbasis peran, dan jaringan.

2. Dasar Microsoft Entra ID, mencakup identitas, peran, service principal, dan identitas terkelola.

3. Dasar API, mencakup REST, autentikasi, pembatasan laju, dan pola retry.

4. Dasar data, mencakup penyimpanan dokumen, konsep pengindeksan, dan klasifikasi data.

5. Dasar keamanan, mencakup pengelolaan rahasia, private endpoint, dan audit.

Setelah fondasi itu terpasang, materi lanjutan yang paling berdampak mencakup rekayasa pengambilan data, observabilitas dengan penyuntingan data sensitif, pemodelan ancaman aplikasi model bahasa, praktik LLMOps untuk prompt dan konfigurasi, serta pengelolaan biaya token.

Peran pekerjaan yang paling sering bersinggungan dengan platform ini meliputi arsitek solusi awan untuk beban kerja AI, platform engineer, DevOps engineer, backend engineer, security engineer, dan AI engineer. Jalur sertifikasi Azure yang relevan tersedia melalui Microsoft Learn dan berkembang mengikuti perubahan layanan.

Sumber belajar resmi cukup terstruktur. Kumpulan materi kurasi dari tim akselerasi Microsoft menyediakan tautan ke dokumentasi, blog rilis bulanan, lokakarya berdurasi beberapa jam, dan repositori contoh siap pakai.

Pertanyaan yang Sering Diajukan tentang Microsoft Foundry

Apakah Microsoft Foundry nama resmi produk Azure?

Microsoft memakai nama Microsoft Foundry pada portal dan dokumentasi terbaru sebagai pengganti Azure AI Foundry, yang sebelumnya bernama Azure AI Studio. Beberapa dokumen pihak ketiga masih memakai nama lama, sehingga verifikasi pada dokumentasi resmi tetap dianjurkan.

Apakah ada biaya untuk Microsoft Foundry itu sendiri?

Penetapan harga berbasis konsumsi berlaku pada layanan dan fitur yang dipakai. Foundry berfungsi sebagai pengalaman pengembangan dan bidang kendali, sedangkan biaya utama muncul dari inferensi model, layanan pencarian, penyimpanan, dan pemantauan.

Apa perbedaan Foundry dengan Azure Machine Learning?

Foundry berfokus pada alur kerja aplikasi AI generatif seperti prompt, pembumian data, agen, dan evaluasi. Azure Machine Learning berfokus pada siklus hidup machine learning berupa pelatihan, pipeline, registri model, dan penyebaran.

Apakah dokumen internal dikirim seluruhnya ke penyedia model?

Pada pola pembumian data yang umum, dokumen tersimpan dan terindeks pada layanan Azure milik organisasi. Model hanya menerima potongan hasil pengambilan sebagai konteks prompt, bukan seluruh korpus, sehingga minimalisasi data tetap perlu diterapkan.

Bagaimana cara menekan halusinasi jawaban agen?

Halusinasi tidak dapat dihilangkan sepenuhnya, tetapi dapat ditekan melalui pembumian pada sumber terpercaya, pemaksaan sitasi, pembatasan cakupan jawaban, instruksi penolakan yang jelas, dan evaluasi berkala memakai kumpulan uji representatif.

Apakah Foundry cocok untuk aplikasi yang menghadap pelanggan secara langsung?

Kesesuaian bergantung pada rekayasa latensi, batas laju, dan keandalan. Cache, prompt ringkas, pengambilan data yang tertata, serta retry dengan backoff menjadi syarat agar pengalaman pengguna tetap konsisten pada beban puncak.

Apa yang perlu dilakukan ketika ketersediaan model berubah?

Rencanakan perubahan sejak awal dengan menjaga prompt agar tidak terikat satu model, mengabstraksi panggilan model di backend, dan menguji migrasi ke model atau wilayah alternatif secara berkala.

Sinyal Kesiapan Sebelum Membawa Agen ke Produksi

Peralihan dari purwarupa ke layanan produksi menuntut lebih dari sekadar jawaban yang terasa memuaskan pada uji coba manual. Beberapa indikator berikut membantu tim menilai kesiapan secara objektif.

• Kumpulan uji emas berisi pertanyaan representatif beserta jawaban yang disepakati sudah tersedia dan dijalankan otomatis pada setiap perubahan prompt.

• Akurasi sitasi terukur, bukan hanya diperkirakan, sehingga jawaban yang keliru dapat dilacak sampai ke dokumen sumber.

• Perilaku penolakan teruji, terutama pada pertanyaan di luar cakupan dan permintaan yang menyentuh kebijakan keamanan konten.

• Identitas terkelola sudah dipakai untuk seluruh panggilan antar layanan, dan kunci statis hanya tersisa sebagai jalur darurat.

• Ambang biaya per hari sudah dipasang dengan peringatan aktif, agar lonjakan token tidak terlambat diketahui.

Latihan resmi menempatkan langkah pembersihan sumber daya sebagai bagian wajib. Kebiasaan itu layak dipertahankan pada lingkungan pengujian jangka panjang, karena penyebaran model yang terlupakan tetap menahan kuota regional.

Menyusun Katalog Alat yang Tertata

Toolboxes memungkinkan pengumpulan alat dari satu endpoint terkelola, mencakup server MCP, pencarian web, pencarian berkas, dan interpreter kode. Pola ini menghindari duplikasi konfigurasi ketika beberapa agen membutuhkan alat yang sama.

Pemilahan berdasarkan tingkat risiko memudahkan tata kelola. Alat yang hanya membaca data dapat dibuka lebih luas, sementara alat yang menulis ke sistem bisnis pantas dibatasi pada agen tertentu dengan persetujuan manusia di tengah alur.

Protokol yang menjadi fondasi katalog tersebut terbuka untuk diperiksa. Spesifikasi Model Context Protocol menjelaskan cara server alat mendeklarasikan kemampuan, yang berguna ketika organisasi ingin membangun server sendiri.

Cara Mengikuti Perkembangan Rilis Microsoft Foundry

Tempo rilis platform ini cukup padat, dengan rangkuman fitur bulanan dan gelombang pengumuman besar pada acara Build serta Ignite. Runbook internal yang tidak diperbarui berisiko memandu tim ke jalur antarmuka yang sudah berubah.

Beberapa kanal yang layak dipantau secara berkala:

Kanal	Isi utama	Ritme
Dokumentasi Microsoft Learn	Konsep, panduan langkah, referensi API	Diperbarui mengikuti rilis
Blog Foundry di DevBlogs	Rangkuman bulanan dan pendalaman teknis	Bulanan dan per fitur
Repositori contoh resmi	Notebook, templat, demo acara	Mengikuti rilis fitur
Diskusi GitHub	Tanya jawab konfigurasi, laporan isu	Harian

Pendekatan yang praktis adalah menugaskan satu orang sebagai penjaga catatan perubahan untuk setiap kuartal. Tugasnya menyaring pengumuman yang benar-benar memengaruhi arsitektur berjalan, lalu mencatatnya pada dokumen keputusan arsitektur.

Perubahan yang paling perlu diwaspadai menyangkut penghentian layanan, pergeseran versi API, dan pergantian nama sumber daya. Ketiganya berpotensi memutus integrasi tanpa peringatan langsung di sisi aplikasi.

Untuk organisasi di Indonesia yang terikat ketentuan residensi data, pemilihan wilayah penyebaran menjadi keputusan awal yang sulit diubah. Dokumentasi produk Microsoft Foundry di Azure memuat rincian layanan yang menyertai, sedangkan ketersediaan model per wilayah perlu dipastikan langsung dari portal pada langganan yang dipakai.

Kesimpulan

Microsoft Foundry menandai pergeseran cara Microsoft mengemas kemampuan AI perusahaan: dari kumpulan layanan terpisah menjadi satu platform yang menyatukan model, agen, alat, pengetahuan, observabilitas, hingga opsi inferensi lokal. Katalog model lintas penyedia, Foundry Agent Service, Foundry IQ, dan Workflow Builder membentuk rangkaian yang memungkinkan organisasi bergerak dari purwarupa ke sistem produksi tanpa merakit sendiri setiap lapisan orkestrasi.

Nilai terbesarnya justru muncul pada hal yang jarang terlihat dalam demo, yakni tata kelola. Kontrol akses berbasis peran, isolasi jaringan, penyaring konten, evaluasi terukur, dan pelacakan berbasis OpenTelemetry membuat agen dapat diaudit ketika sudah menyentuh data nyata. Tanpa disiplin itu, keunggulan katalog model dan kecepatan pembuatan agen kehilangan arti pada lingkungan yang diatur ketat.

Beberapa risiko tetap perlu dihitung sejak awal. Biaya token yang tumbuh mengikuti panjang prompt, kuota model yang berbeda tiap wilayah, kompleksitas private endpoint, serta tempo rilis yang cepat menuntut kebiasaan membaca catatan perubahan dan meninjau ulang keputusan arsitektur secara berkala. Panduan resmi pada dokumentasi Microsoft Foundry di Microsoft Learn menjadi rujukan paling aman karena mengikuti perubahan layanan.

Langkah paling masuk akal bagi tim yang baru menimbang platform ini adalah membangun satu kasus pemakaian sempit dengan nilai bisnis jelas, misalnya tanya jawab kebijakan internal, lalu mengukurnya dengan kumpulan uji dan ambang biaya sejak hari pertama. Dari fondasi kecil yang terukur itu, perluasan ke alur multi-agen menjadi keputusan berbasis data, bukan sekadar mengikuti daftar fitur terbaru.

---

Referensi

Microsoft Foundry. (2026). Microsoft Foundry.

Microsoft Azure. (2026). Microsoft Foundry.

Microsoft Foundry. (2026). Microsoft Foundry.

Microsoft Learn. (2026). What is Microsoft Foundry?

GitHub. (2026). Microsoft Foundry Developer Community.

Microsoft Learning. (2026). Get started with Microsoft Foundry.

Microsoft Foundry. (2026). Microsoft Foundry.

Medium. (2026). Azure AI Foundry is now Microsoft Foundry: What Changed and Why It Matters.

DevOpsSchool. (2026). Azure Microsoft Foundry Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for AI and Machine Learning.

Microsoft. (2026). Microsoft Foundry Resources.

GitHub. (2026). Foundry Local.