Banyak proyek AI dimulai dengan scope yang cukup jelas.
Ada use case yang ingin dibuktikan, model atau platform yang akan digunakan, integration yang perlu dibuat, tim yang mengerjakan, serta budget untuk membawa ide tersebut sampai ke pilot.
Masalahnya mulai berubah ketika pilot berhasil.
AI yang sebelumnya digunakan oleh beberapa orang mulai masuk ke workflow sehari-hari. Jumlah request meningkat. Lebih banyak data dan system ikut terhubung. Tim lain mulai mengadopsinya. Reliability, security, cost, dan kualitas output yang sebelumnya cukup diperiksa selama development sekarang harus dipantau terus.
Pada titik ini, biaya AI tidak lagi berhenti pada biaya membangun aplikasi.
Production AI membutuhkan budget untuk menjalankan dan mengoperasikannya.
Menjelang penyusunan IT budget 2027, perbedaan ini penting karena beberapa komponen biaya justru baru terlihat setelah AI masuk production.
Pilot dirancang untuk menjawab pertanyaan utama: apakah use case ini bisa bekerja?
Production harus menjawab pertanyaan yang jauh lebih luas.
Apakah sistem tetap bekerja ketika usage bertambah? Bagaimana biaya berubah ketika jumlah request meningkat? Apakah output masih sesuai dengan standar yang ditetapkan? Apa yang terjadi ketika model, API, database, vector store, atau tool yang digunakan mengalami gangguan?
Dalam pilot, engineer bisa memeriksa log secara manual ketika sesuatu berjalan tidak sesuai harapan.
Dalam production, pendekatan tersebut sulit dipertahankan karena AI menjadi bagian dari service yang digunakan secara rutin.
AWS membedakan kebutuhan observability antara proof of concept dan pre-production. Pada tahap PoC, fokusnya masih pada debugging dan validation. Mendekati production, observability perlu berkembang menjadi monitoring menyeluruh terhadap system health, performance, cost, dan quality.
Perubahan inilah yang sering tidak cukup tercermin dalam project budget awal.
Untuk perencanaan 2027, setidaknya ada tiga area yang perlu diperhitungkan secara terpisah.
Biaya model biasanya menjadi angka pertama yang muncul ketika membahas operating cost AI.
Itu memang penting, tetapi production cost tidak selalu berhenti pada harga input dan output token.
Satu user request bisa melibatkan beberapa komponen sebelum menghasilkan jawaban akhir. Aplikasi mungkin perlu melakukan retrieval, memanggil model beberapa kali, mengakses tool atau API, menyimpan context, menjalankan guardrail, lalu mencoba fallback ketika salah satu tahap gagal.
Pada agentic workflow, satu request bahkan dapat menghasilkan beberapa model invocation dan tool call.
Karena itu, volume user tidak selalu sama dengan volume model call.
Misalnya sebuah workflow memanggil model, tetapi output pertama tidak memenuhi requirement sehingga sistem melakukan retry.
Dari sisi user, hanya ada satu request.
Dari sisi infrastructure dan AI consumption, request tersebut bisa menghasilkan beberapa invocation.
Pola yang sama dapat terjadi ketika agent gagal menjalankan tool, context terlalu panjang, atau workflow menggunakan beberapa model untuk menyelesaikan satu task.
AWS sendiri memasukkan token consumption, model invocation, latency, error rate, hingga cost attribution sebagai bagian dari observability untuk generative AI workloads.
Itulah mengapa budget dengan satu baris:
“AI API usage”
sering terlalu sederhana untuk production planning.
Perhitungan sebaiknya dimulai dari cara AI benar-benar digunakan.
Sebuah internal assistant yang menjawab pertanyaan singkat memiliki consumption pattern yang berbeda dari document processing workflow dengan context panjang.
Agent yang mengakses beberapa business system berbeda lagi.
Begitu juga aplikasi yang menggunakan Retrieval-Augmented Generation, multimodal input, atau high-volume inference.
Perusahaan perlu memahami beberapa variabel seperti jumlah request, panjang context, model yang digunakan, jumlah model call dalam satu transaction, supporting infrastructure, serta proyeksi adoption setelah service dibuka ke lebih banyak pengguna.
Dengan cara ini, budget tidak hanya menggambarkan harga model.
Budget mulai menggambarkan economics dari workload-nya.
Production AI juga menambah kebutuhan monitoring yang tidak sepenuhnya sama dengan traditional application.
CPU normal belum tentu berarti AI bekerja dengan baik.
Endpoint bisa tetap tersedia ketika kualitas output menurun. Response bisa berhasil secara teknis tetapi membutuhkan token jauh lebih banyak dari biasanya. Agent dapat terus melakukan API call tanpa menghasilkan outcome yang diinginkan.
Karena itu, production AI membutuhkan visibility pada beberapa layer sekaligus.
Traditional application metrics seperti availability, latency, error rate, CPU, memory, dan infrastructure utilization tetap penting.
Namun AI menambahkan dimensi lain seperti model usage, token consumption, prompt dan response behavior, quality evaluation, tool execution, serta agent trace.
AWS merekomendasikan metrics, logs, dan traces yang juga menangkap AI-specific telemetry, termasuk token count, tool call, prompt-response information, dan user feedback. Untuk compound AI system, end-to-end tracing menjadi penting karena satu request dapat melewati beberapa model call, database query, dan tool execution.
Perkembangan platform enterprise AI juga bergerak ke arah yang sama. Red Hat AI 3.5, misalnya, membawa model evaluation, inference health, AI performance, dan per-user token consumption lebih dekat ke platform layer.
Ini memberi gambaran bahwa evaluation dan observability mulai menjadi bagian dari infrastructure yang dibutuhkan untuk menjalankan enterprise AI, bukan aktivitas tambahan yang hanya dilakukan selama development.
Model yang berhasil melewati test sebelum launch belum tentu memberikan hasil yang sama selamanya.
Prompt dapat berubah. Knowledge source diperbarui. Workflow berkembang. Model provider dapat merilis versi baru. Pola input dari user juga berubah setelah aplikasi digunakan dalam kondisi nyata.
Karena itu, evaluation sebaiknya tidak diposisikan sebagai satu milestone sebelum launch.
Tim perlu memiliki baseline untuk mengetahui apakah kualitas berubah ketika komponen di dalam sistem ikut berubah.
Pada workload tertentu, ini bisa berarti automated evaluation. Pada kasus lain, human review tetap diperlukan.
Kompleksitasnya berbeda untuk setiap use case, tetapi pekerjaannya tetap membutuhkan capacity, tooling, dan ownership.
Semua itu perlu mendapatkan tempat di budget.
Bagian ketiga sering lebih sulit terlihat karena bukan berupa satu service atau satu license.
Ini adalah pekerjaan untuk menjaga AI tetap usable setelah go-live.
Production environment akan berubah.
Jumlah user bertambah. Data source berubah. Integration baru ditambahkan. Model diganti. Security requirement diperbarui. Cost pattern yang terlihat normal saat launch bisa berbeda beberapa bulan kemudian.
Ketika incident terjadi, seseorang juga perlu menentukan apakah sumber masalah berasal dari aplikasi, model, provider, prompt, retrieval layer, tool integration, atau data.
AWS memasukkan incident response, escalation process, cost optimization, ongoing monitoring, governance, serta continuous improvement sebagai bagian dari perjalanan organisasi menuju production-grade generative AI.
Artinya, AI operations bukan hanya maintenance terhadap infrastructure.
Tim perlu mempertahankan visibility terhadap hubungan antara application behavior dan AI behavior.
Di sinilah kebutuhan terhadap operating model mulai terlihat.
Siapa yang menerima alert ketika cost melonjak?
Siapa yang mengevaluasi perubahan kualitas output?
Apa yang dilakukan ketika external model API mengalami degradation?
Bagaimana rollback dilakukan ketika perubahan prompt atau agent workflow menghasilkan behavior yang tidak diinginkan?
Bagaimana model version, prompt, dan supporting assets dilacak sehingga perubahan dapat direproduksi dan dievaluasi?
Pertanyaan tersebut baru terasa operasional ketika AI sudah menjadi bagian dari business process.
Karena itu, pekerjaan di belakangnya perlu direncanakan sebelum production workload bertambah terlalu jauh.
Daripada menempatkan seluruh investasi AI di bawah satu project budget, perencanaan bisa dibagi menjadi tiga lapisan.
Ini adalah bagian yang paling familiar dari pilot:
Sebagian besar pilot sudah memiliki budget yang cukup jelas untuk area ini.
Bagian ini muncul ketika workload mulai aktif:
Biaya di sini akan mengikuti adoption dan architecture yang digunakan.
Lapisan ketiga adalah pekerjaan yang membuat production system tetap terjaga:
Tidak semua organisasi membutuhkan struktur atau tooling yang sama.
Namun membedakan ketiganya membantu menghindari situasi ketika project berhasil masuk production tetapi tidak ada capacity yang secara jelas dialokasikan untuk menjaganya setelah itu.
Tidak harus dimulai dari forecast yang sangat kompleks.
Langkah pertama justru memastikan workload yang akan masuk production sudah cukup jelas.
Lihat bagaimana AI digunakan hari ini, lalu proyeksikan bagaimana penggunaannya berubah setelah adoption meningkat.
Beberapa pertanyaan bisa membantu membentuk baseline:
Berapa banyak pengguna atau transaction yang diperkirakan menggunakan AI?
Ini memberikan starting point untuk usage forecast.
Berapa banyak model call yang sebenarnya terjadi per transaction?
Satu user request belum tentu sama dengan satu inference.
Apakah workload membutuhkan retrieval, tool calling, atau external API?
Setiap dependency menambah operating component dan failure mode.
Apa yang harus dimonitor setelah go-live?
Infrastructure health saja biasanya tidak cukup untuk AI workload.
Bagaimana kualitas output akan dievaluasi?
Tentukan apakah evaluation dilakukan secara automated, sampled, melalui human review, atau kombinasi beberapa metode.
Siapa yang menangani incident dan optimization setelah production?
Ownership menentukan apakah kebutuhan tersebut ditangani internal, melalui managed service, atau kombinasi keduanya.
Jawaban dari pertanyaan ini biasanya memberikan gambaran budget yang lebih realistis dibanding sekadar mengalikan jumlah user dengan harga token.
Operating budget bukan berarti perusahaan harus menerima semua biaya production begitu saja.
Justru ketika workload sudah dapat diamati dengan baik, optimization menjadi lebih konkret.
Tim bisa melihat use case mana yang mengonsumsi paling banyak token, workflow mana yang sering melakukan retry, atau application mana yang sebenarnya tidak memerlukan model dengan capability tertinggi.
Mereka juga dapat menilai apakah context terlalu panjang, caching dapat digunakan, model routing diperlukan, atau agent terlalu sering memanggil tool.
Visibility seperti ini sulit diperoleh jika cost hanya dilihat sebagai satu total invoice pada akhir bulan.
Cost control membutuhkan hubungan antara spending dan workload yang menghasilkan spending tersebut.
Tidak semua perusahaan ingin membangun operating capability untuk AI sepenuhnya dari awal.
Membangun application dan mengoperasikan production AI membutuhkan skill set yang sebagian tumpang tindih, tetapi tidak identik.
Development team fokus membawa use case sampai production.
Operations perlu menjaga reliability, observability, cost, security, dan lifecycle setelah workload digunakan sehari-hari.
Di sinilah managed AI operations dapat menjadi salah satu opsi dalam perencanaan.
Tujuannya bukan menggantikan ownership perusahaan terhadap AI.
Tim internal tetap menentukan business requirement, risk appetite, dan keputusan penting terkait penggunaan AI.
Managed operations dapat membantu menjaga operational layer di belakangnya: monitoring, evaluation, incident handling, usage visibility, optimization, serta perubahan lifecycle yang terus terjadi setelah production.
Pilot yang berhasil memang merupakan milestone penting.
Namun go-live bukan akhir dari biaya maupun pekerjaan.
Begitu AI masuk ke production, perusahaan mulai berhadapan dengan usage yang lebih besar, behavior yang lebih sulit diprediksi, lebih banyak integration, serta requirement untuk menjaga kualitas dan reliability secara berkelanjutan.
Itulah mengapa perencanaan IT budget 2027 sebaiknya tidak hanya menjawab:
berapa biaya untuk membangun AI?
Perencanaan juga perlu memperhitungkan apa yang dibutuhkan untuk menjalankannya sepanjang tahun.
Runtime dan usage menentukan bagaimana workload dikonsumsi.
Evaluation dan observability membantu melihat apakah AI masih bekerja sesuai harapan.
Ongoing operations memastikan sistem dapat dipantau, ditangani, dan dioptimalkan ketika environment berubah.
Ketiganya membuat budget lebih dekat dengan kondisi yang benar-benar akan dihadapi setelah production.
The pilot gets AI into production. The operating plan keeps it useful there.
ICS Compute membantu enterprise merencanakan dan menjalankan production AI environment melalui observability, evaluation, cost visibility, optimization, dan managed AI operations yang disesuaikan dengan workload serta operating model perusahaan.