{"id":14672,"date":"2026-09-05T17:00:32","date_gmt":"2026-09-05T10:00:32","guid":{"rendered":"https:\/\/crocodic.com\/?p=14672"},"modified":"2026-09-05T17:00:35","modified_gmt":"2026-09-05T10:00:35","slug":"ai-finops-untuk-enterprise-cara-mengendalikan-biaya-llm-ai-agent-dan-multi-model","status":"publish","type":"post","link":"https:\/\/crocodic.com\/en\/ai-finops-untuk-enterprise-cara-mengendalikan-biaya-llm-ai-agent-dan-multi-model\/","title":{"rendered":"AI FinOps untuk Enterprise: Cara Mengendalikan Biaya LLM, AI Agent, dan Multi-Model"},"content":{"rendered":"

Ketika perusahaan hanya memiliki satu chatbot internal atau satu proof-of-concept generative AI, biaya biasanya masih mudah dipahami. Tim mengetahui model yang digunakan, jumlah pengguna relatif kecil, dan tagihan provider dapat dilihat sebagai bagian dari experimentation budget. Situasinya berubah ketika AI masuk ke customer service, finance, software development, internal knowledge, document processing, analytics, dan AI agents yang menjalankan workflow lintas sistem. Pada tahap tersebut, perusahaan tidak lagi hanya membeli akses terhadap sebuah model. Perusahaan mulai mengonsumsi intelligence sebagai operational resource<\/strong> yang volumenya berubah mengikuti jumlah pengguna, kompleksitas workflow, panjang context, model yang dipilih, jumlah reasoning step, tool calls, retries, dan berbagai infrastructure di belakangnya.<\/p>\n\n\n\n

Perubahan tersebut mulai terlihat pada data enterprise 2026. Survei McKinsey menemukan AI spending meningkat hampir empat kali lipat ketika organisasi bergerak dari isolated use cases menuju enterprise-wide adoption, sementara 93% responden mengatakan pengeluaran AI mereka sudah melampaui budget. McKinsey menggunakan istilah enterprise AI tokenomics<\/strong> untuk menggambarkan disiplin yang lebih luas dari sekadar menghitung token: organisasi perlu memahami model selection, routing, orchestration, agent behavior, workflow design, infrastructure consumption, dan bagaimana seluruh pengeluaran tersebut akhirnya menghasilkan business value. (McKinsey & Company<\/a>)<\/p>\n\n\n\n

Perubahan economics ini semakin penting ketika AI agent mulai digunakan. Gartner memperkirakan inference cost per agentic workflow dapat meningkat lebih dari lima kali lipat hingga 2028 karena agent tidak hanya membaca prompt lalu menghasilkan satu respons. Agent dapat melakukan reasoning beberapa tahap, menggunakan tools, mengevaluasi hasil, memanggil model kembali, dan mengulangi proses sampai objective tercapai. Gartner menyebut kondisi ini sebagai Inference Paradox<\/strong>: harga per unit intelligence dapat semakin murah, tetapi total biaya per workflow tetap meningkat karena sistem menggunakan semakin banyak intelligence untuk menghasilkan outcome yang lebih kompleks. (Gartner<\/a>)<\/p>\n\n\n\n

Karena itu enterprise membutuhkan pendekatan baru terhadap cost management. Pertanyaan yang relevan bukan lagi hanya \u201cberapa biaya satu juta token?\u201d<\/strong>, melainkan:<\/p>\n\n\n\n

\u201cBerapa biaya intelligence yang dibutuhkan untuk menghasilkan satu business outcome yang dapat diverifikasi?\u201d<\/strong><\/p>\n\n\n\n

Inilah konteks di mana AI FinOps<\/strong> mulai menjadi capability strategis.<\/p>\n\n\n\n

Apa Itu AI FinOps?<\/strong><\/h2>\n\n\n\n

AI FinOps adalah praktik untuk membuat biaya, konsumsi, ownership, performance, dan business value penggunaan artificial intelligence dapat dilihat, dialokasikan, diprediksi, dan dioptimalkan secara berkelanjutan. FinOps Foundation menjelaskan FinOps for AI sebagai perluasan praktik FinOps untuk menghadapi karakter AI yang memiliki development cycle lebih cepat, cost unpredictability lebih tinggi, kebutuhan governance lebih besar, serta konsumsi yang dapat tersebar melintasi model providers, SaaS AI, cloud infrastructure, data center, dan berbagai bentuk AI services. Tujuannya bukan sekadar menurunkan tagihan, tetapi menyelaraskan AI consumption, investment, dan business value<\/strong>. FinOps Foundation \u2014 FinOps for AI<\/a> (FinOps Foundation<\/a>)<\/p>\n\n\n\n

Perbedaan tersebut penting karena dua aplikasi dengan jumlah user yang sama dapat menghasilkan biaya AI yang sangat berbeda. Customer-service assistant mungkin melakukan satu model call dengan context pendek untuk setiap pertanyaan. Procurement agent dapat membaca beberapa dokumen, mencari data supplier, memeriksa inventory, menjalankan reasoning berulang, menggunakan model khusus untuk document extraction, dan memanggil model reasoning lain sebelum menghasilkan recommendation. Mengukur keduanya hanya berdasarkan seat atau jumlah request menyembunyikan perbedaan economics yang sebenarnya.<\/p>\n\n\n\n

FinOps Foundation bahkan merekomendasikan organisasi bergerak dari sekadar melihat total token menuju unit cost metrics<\/strong> seperti cost per query, cost per user, dan cost per workflow. Dengan metrik tersebut business stakeholder dapat memahami AI menggunakan unit yang lebih dekat dengan operasi perusahaan daripada sekadar melihat miliaran token pada invoice provider. FinOps Foundation \u2014 Tokenomics dan AI Cost Management<\/a> (FinOps Foundation<\/a>)<\/p>\n\n\n\n

AI FinOps dengan demikian bukan hanya pekerjaan Finance. Ia berada di persimpangan Finance, Engineering, Architecture, Procurement, Product, dan Business Owner<\/strong>, karena keputusan yang membentuk biaya AI sering dibuat jauh sebelum invoice muncul.<\/p>\n\n\n\n

Mengapa Cloud FinOps Saja Belum Cukup?<\/strong><\/h2>\n\n\n\n

Banyak prinsip Cloud FinOps tetap sangat relevan: visibility, allocation, forecasting, budgeting, unit economics, optimization, dan governance. Namun AI menambahkan consumption primitive baru yang lebih dinamis. Traditional compute biasanya mempunyai hubungan yang relatif jelas antara resource dan workload. AI dapat menghasilkan cost berbeda untuk request yang terlihat sama karena panjang context, reasoning depth, tool interaction, generated output, model choice, ataupun retry berbeda.<\/p>\n\n\n\n

McKinsey mencatat token usage untuk agent yang mengerjakan task yang sama bahkan dapat memiliki variasi hingga 30 kali, yang membuat traditional forecasting jauh lebih sulit. Ketika organisasi berpindah dari copilots menuju agents, forecast harus memperhitungkan user adoption, workflow expansion, routing strategy, serta perubahan penggunaan frontier versus open-weight models. (McKinsey & Company<\/a>)<\/p>\n\n\n\n

Karena itu AI FinOps perlu menghubungkan tiga perspektif sekaligus. Pertama adalah technology consumption<\/strong>, misalnya token, inference, GPU, vector storage, dan model API. Kedua adalah workflow consumption<\/strong>, misalnya berapa banyak model calls, retries, retrieval, tool execution, atau agent steps yang dibutuhkan. Ketiga adalah business economics<\/strong>, yaitu apakah seluruh consumption tersebut menghasilkan sesuatu yang bernilai seperti resolved customer case, invoice yang berhasil direview, document yang selesai diproses, atau decision time yang berkurang.<\/p>\n\n\n\n

Jika ketiga layer tersebut tidak dihubungkan, organisasi dapat mempunyai cost dashboard yang sangat detail tetapi tetap tidak mengetahui apakah pengeluaran AI tersebut ekonomis.<\/p>\n\n\n\n

Biaya AI Jauh Lebih Luas daripada Harga Token<\/strong><\/h2>\n\n\n\n

Harga input dan output token merupakan komponen paling terlihat, tetapi bukan seluruh biaya AI. Enterprise AI dapat mengonsumsi model inference, embeddings, vector databases, storage, document processing, API calls, search services, observability, guardrails, network traffic, orchestration infrastructure, agent runtime, cloud compute, serta engineering dan operational capacity. Jika perusahaan menggunakan self-hosted atau open-weight model, economics-nya berpindah dari API token menuju GPU capacity, utilization, serving infrastructure, monitoring, dan team yang mengoperasikannya.<\/p>\n\n\n\n

FinOps Foundation menekankan bahwa AI spend dapat tersebar di berbagai technology category sekaligus, termasuk SaaS AI providers, hyperscale cloud platforms, enterprise agreements, model vendors, data center investment, dan infrastructure lain. Inilah alasan invoice satu provider tidak dapat dianggap sebagai total cost sebuah AI capability. (FinOps Foundation<\/a>)<\/p>\n\n\n\n

Misalnya sebuah internal knowledge agent terlihat murah karena model API hanya menghabiskan Rp20 juta per bulan. Tetapi jika workflow tersebut juga menggunakan enterprise search, document parsing, vector database, reranking model, orchestration platform, monitoring, serta dedicated infrastructure, total economics-nya dapat berbeda secara signifikan. Sebaliknya, model dengan harga per token lebih tinggi bisa menghasilkan total workflow cost lebih rendah apabila mampu menyelesaikan pekerjaan dengan lebih sedikit reasoning loops dan retries.<\/p>\n\n\n\n

Karena itu:<\/p>\n\n\n\n

Model termurah belum tentu menghasilkan workflow termurah, dan workflow termurah belum tentu menghasilkan business outcome paling ekonomis.<\/strong><\/p>\n\n\n\n

AI FinOps perlu mengoptimalkan seluruh path dari request sampai outcome, bukan hanya satu line item pada invoice.<\/p>\n\n\n\n

Crocodic Perspective: Dari Cost per Token ke Cost per Accepted Business Outcome<\/strong><\/h2>\n\n\n\n

Untuk enterprise, Crocodic melihat token sebagai technical consumption unit<\/strong>, bukan ultimate business unit. Token penting untuk budgeting dan optimization, tetapi management membutuhkan denominator yang lebih dekat dengan business outcome.<\/p>\n\n\n\n

Framework sederhananya:<\/p>\n\n\n\n

Total AI Cost \u2192 AI Workflow \u2192 Verified Outcome<\/strong><\/p>\n\n\n\n

Kemudian perusahaan dapat menghitung:<\/p>\n\n\n\n

AI Unit Economics = Total AI Workflow Cost \u00f7 Accepted Business Outcomes<\/strong><\/p>\n\n\n\n

Kata accepted<\/strong> penting. Jika AI menghasilkan 10.000 output tetapi 30% harus dibuat ulang manusia karena salah, menghitung cost per generated output akan terlihat terlalu optimistis. Unit economics seharusnya menggunakan outcome yang memenuhi quality threshold atau benar-benar dapat digunakan.<\/p>\n\n\n\n

Contohnya:<\/p>\n\n\n\n

Use Case<\/strong><\/td>Technical Metric<\/strong><\/td>Business Unit Metric<\/strong><\/td><\/tr>
Customer Service AI<\/td>token\/request<\/td>cost per resolved case<\/td><\/tr>
Invoice AI<\/td>token\/document<\/td>cost per accepted invoice review<\/td><\/tr>
Procurement Agent<\/td>token\/workflow<\/td>cost per completed vendor analysis<\/td><\/tr>
Coding Assistant<\/td>token\/developer<\/td>cost per accepted engineering task<\/td><\/tr>
Contract AI<\/td>token\/document<\/td>cost per reviewed contract<\/td><\/tr>
Internal Search<\/td>token\/query<\/td>cost per successfully resolved question<\/td><\/tr>
Sales Agent<\/td>token\/account<\/td>cost per qualified account action<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Perubahan denominator ini sangat penting karena optimization tidak lagi dilakukan semata untuk mengurangi token. Perusahaan dapat menerima cost AI yang lebih tinggi apabila productivity, quality, revenue, risk reduction, atau processing speed meningkat lebih besar.<\/p>\n\n\n\n

Tujuan AI FinOps bukan meminimalkan biaya AI. Tujuannya adalah meminimalkan biaya untuk menghasilkan business outcome pada quality level yang dibutuhkan.<\/strong><\/p>\n\n\n\n

1. Bangun Visibility Sebelum Melakukan Optimization<\/strong><\/h2>\n\n\n\n

Enterprise tidak dapat mengoptimalkan cost yang tidak dapat diatribusikan. Namun AI spending sering tersebar: business unit membeli subscription sendiri, developer menyimpan API key pada project, team berbeda menggunakan provider berbeda, dan beberapa workflow dibangun tanpa melewati central platform. McKinsey menyebut sebagian AI spending menjadi sulit terlihat karena business units dan citizen developers dapat membeli atau membangun AI capability secara independen dari central IT. (McKinsey & Company<\/a>)<\/p>\n\n\n\n

Langkah pertama AI FinOps karena itu bukan menurunkan token, melainkan membuat AI inventory<\/strong>. Perusahaan perlu mengetahui provider, model, application, agent, API key, owner, business unit, environment, cost center, dan use case yang menggunakan AI. FinOps Foundation juga merekomendasikan inventory account, API key, provider, dan payment method sebagai fondasi awal token cost management. Setiap key idealnya mempunyai named owner, approved use case, serta cost center agar consumption dapat dialokasikan. (FinOps Foundation<\/a>)<\/p>\n\n\n\n

Jika satu shared API key digunakan sepuluh aplikasi, Finance mungkin mengetahui total spend tetapi tidak dapat menentukan aplikasi mana yang menyebabkannya. Jika model usage dapat ditag berdasarkan application, workflow, environment, user group, atau business unit, perusahaan mulai dapat melakukan showback<\/strong> dan kemudian chargeback bila memang diperlukan.<\/p>\n\n\n\n

Visibility memberikan jawaban terhadap pertanyaan dasar: siapa menggunakan AI, model apa yang digunakan, untuk workflow apa, seberapa sering digunakan, dan berapa total economics-nya.<\/p>\n\n\n\n

2. Jangan Gunakan Frontier Model untuk Semua Pekerjaan<\/strong><\/h2>\n\n\n\n

Salah satu sumber waste paling umum adalah menggunakan model paling powerful sebagai default untuk setiap task. Strategi ini masuk akal selama experimentation karena tim ingin memperoleh quality maksimum dengan cepat, tetapi dapat menjadi mahal pada production scale.<\/p>\n\n\n\n

Tidak semua task mempunyai complexity yang sama. Classification sederhana, extraction terstruktur, routing, summarization dasar, atau formatting kemungkinan dapat ditangani model yang lebih kecil dan murah. Complex reasoning, ambiguous decision, atau high-value analysis mungkin membutuhkan model yang lebih powerful. AWS secara eksplisit merekomendasikan right-sizing model selection<\/strong> serta routing request yang sederhana menuju model lebih murah selama quality threshold tetap terpenuhi. Model selection juga perlu terus dievaluasi karena model, harga, dan workload dapat berubah. AWS Generative AI Lens \u2014 Model Cost Optimization<\/a> (Dokumentasi AWS<\/a>)<\/p>\n\n\n\n

Ini menghasilkan pola:<\/p>\n\n\n\n

Task Complexity \u2192 Quality Requirement \u2192 Minimum Capable Model<\/strong><\/p>\n\n\n\n

bukan:<\/p>\n\n\n\n

All Requests \u2192 Best Available Model.<\/strong><\/p>\n\n\n\n

Dalam environment multi-model, model routing dapat menjadi salah satu optimization lever paling kuat. Routine workload dapat menggunakan low-cost model, sedangkan request yang memenuhi criteria tertentu dielevasikan ke model dengan reasoning lebih tinggi.<\/p>\n\n\n\n

Namun routing juga mempunyai cost dan risk. Dynamic routing yang terlalu kompleks dapat mempersulit debugging dan menyebabkan behavior berubah antar-request. Karena itu keputusan routing perlu mengikuti evaluation evidence, bukan sekadar harga provider.<\/p>\n\n\n\n

3. Agentic AI Membutuhkan Cost Boundary, Bukan Hanya Token Quota<\/strong><\/h2>\n\n\n\n

AI agent menambah satu variabel baru: jumlah langkah tidak selalu diketahui sebelumnya<\/strong>. Agent dapat melakukan planning, memanggil tool, membaca hasil, melakukan reasoning kembali, kemudian mengubah strategy. Dalam architecture multi-agent, satu agent bahkan dapat meminta agent lain melakukan pekerjaan tambahan.<\/p>\n\n\n\n

Fleksibilitas ini yang membuat agent powerful, tetapi juga membuat cost lebih sulit diprediksi. Gartner memperkirakan routing pekerjaan dari basic chatbot menuju agentic reasoning model meningkatkan inference cost provider sedikitnya lima kali dan dapat jauh lebih besar ketika task semakin kompleks. (Gartner<\/a>) AWS juga memasukkan stopping conditions untuk long-running agent workflows<\/strong> sebagai bagian dari generative AI cost optimization guidance. (Dokumentasi AWS<\/a>)<\/p>\n\n\n\n

Karena itu agent perlu mempunyai economic guardrails seperti maximum reasoning steps, tool-call limits, retry limits, maximum context, workflow timeout, model escalation limits, dan cost ceiling per workflow. Jika agent gagal mencapai confidence yang cukup setelah threshold tertentu, workflow dapat berhenti atau dialihkan kepada manusia daripada terus mengonsumsi intelligence tanpa batas.<\/p>\n\n\n\n

Agent autonomy tanpa economic boundary membuat cost berubah dari parameter engineering menjadi probabilistic outcome.<\/strong><\/p>\n\n\n\n

Ini tidak berarti setiap agent harus mempunyai hard budget sangat kecil. Boundary harus mengikuti value workflow. Fraud investigation atau high-value contract analysis dapat memperoleh allowance lebih besar dibanding task administratif sederhana. Yang penting adalah organization membuat trade-off tersebut secara eksplisit.<\/p>\n\n\n\n

4. Ukur Cost per Workflow, Bukan Hanya Cost per Model<\/strong><\/h2>\n\n\n\n

Cost dashboard sering menampilkan Provider A, Model B, dan jumlah token. Data tersebut berguna bagi engineering, tetapi tidak cukup bagi business owner. Mereka membutuhkan jawaban seperti: berapa biaya AI customer service minggu ini? Berapa biaya satu procurement workflow? Use case mana yang semakin mahal tetapi business value-nya tidak bertambah?<\/p>\n\n\n\n

Model dapat digunakan banyak workflows sekaligus, dan satu workflow dapat menggunakan beberapa models. Karena itu attribution harus bergerak ke workflow layer.<\/p>\n\n\n\n

Misalnya Procurement Agent menggunakan Model A untuk document extraction, Model B untuk comparison, embedding model untuk retrieval, serta enterprise search untuk policy. Jika cost hanya dilihat per-model, organization tidak pernah mendapatkan true economics procurement workflow.<\/p>\n\n\n\n

FinOps Foundation secara eksplisit mendorong penggunaan unit metrics seperti cost per query, cost per user, dan cost per workflow<\/strong> agar AI spending dapat dikaitkan dengan business stakeholder. (FinOps Foundation<\/a>) Gartner juga melihat economics agentic application mulai bergerak dari traditional per-seat models menuju pricing berbasis aktivitas atau outcome yang dapat diukur. (Gartner<\/a>)<\/p>\n\n\n\n

Inilah alasan instrumentation sebaiknya membawa identifier seperti:<\/p>\n\n\n\n

Business Unit \u2192 Application \u2192 Workflow \u2192 User\/Agent \u2192 Model \u2192 Outcome<\/strong><\/p>\n\n\n\n

sehingga satu workflow dapat ditelusuri dari consumption sampai business result.<\/p>\n\n\n\n

5. Context Adalah Cost Multiplier yang Sering Tidak Terlihat<\/strong><\/h2>\n\n\n\n

Enterprise AI cenderung mengirim semakin banyak context agar output terlihat lebih pintar. Internal assistant mengambil beberapa dokumen, customer agent memuat history yang panjang, dan agent memasukkan output tool sebelumnya kembali ke conversation. Context menjadi lebih besar setiap step dan seluruh data tersebut dapat diproses berulang.<\/p>\n\n\n\n

Padahal lebih banyak context tidak selalu menghasilkan lebih baik. Information yang tidak relevan meningkatkan token consumption dan dapat memperbesar noise yang harus dipahami model. AWS memasukkan optimization terhadap prompt length, response length, prompt caching, dan filtering sebagai bagian dari cost-aware generative AI design. (Dokumentasi AWS<\/a>)<\/p>\n\n\n\n

Karena itu AI FinOps dan AI architecture bertemu pada prinsip minimum sufficient context<\/strong>. Agent seharusnya memperoleh informasi yang cukup untuk mengambil keputusan, bukan seluruh informasi yang secara teknis tersedia. Retrieval dapat dibatasi berdasarkan relevance, permission, date range, atau business entity. Tool juga dapat mengembalikan field yang dibutuhkan saja daripada seluruh database record.<\/p>\n\n\n\n

Keuntungan approach tersebut bukan hanya cost. Context yang lebih sempit juga dapat meningkatkan security, privacy, latency, dan observability.<\/p>\n\n\n\n

6. Multi-Agent Bukan Default Optimization Strategy<\/strong><\/h2>\n\n\n\n

Multi-agent architecture memungkinkan beberapa agent mempunyai responsibility berbeda dan bekerja bersama. Namun setiap handoff dapat menambah model inference, context duplication, orchestration overhead, latency, dan failure surface. Arsitektur yang secara diagram terlihat modular dapat menghasilkan cost per outcome jauh lebih tinggi daripada single agent atau deterministic workflow.<\/p>\n\n\n\n

Artikel Crocodic mengenai AI Orchestration: Menghubungkan Model, Data, dan Sistem<\/a> membahas trade-off ini: direct model call atau satu agent dengan tools sering kali lebih sederhana, sedangkan multi-agent menambah coordination overhead, latency, cost, dan failure mode. (Crocodic<\/a>)<\/p>\n\n\n\n

Karena itu keputusan multi-agent perlu menghasilkan measurable capability yang memang tidak dapat dicapai lebih efisien dengan architecture yang lebih sederhana. Memisahkan Finance Agent dan Procurement Agent mungkin masuk akal jika permission, data domain, dan evaluation criteria berbeda. Membuat lima agents hanya untuk menjalankan pipeline linear yang sebenarnya deterministic kemungkinan hanya menambah complexity.<\/p>\n\n\n\n

Jumlah agent bukan indikator AI maturity. Cost per successful workflow dan reliability jauh lebih penting daripada jumlah autonomous components di dalam architecture.<\/strong><\/p>\n\n\n\n

7. AI Gateway Dapat Menjadi Control Plane untuk AI FinOps<\/strong><\/h2>\n\n\n\n

Ketika satu aplikasi menggunakan satu provider, cost tracking masih dapat dilakukan langsung dari billing provider. Namun ketika puluhan aplikasi dan agents menggunakan beberapa models, central control mulai memberikan value. Perusahaan membutuhkan tempat untuk menerapkan quota, model routing, usage attribution, rate limit, observability, serta policy yang sama tanpa mengubah setiap application secara terpisah.<\/p>\n\n\n\n

Crocodic membahas architecture tersebut melalui AI Gateway: Kontrol Model, Data, dan Biaya AI<\/a>. AI Gateway dapat menjadi control point antara applications atau agents dan model ecosystem sehingga organization mengetahui siapa menggunakan model, berapa token yang dikonsumsi, model apa yang dipilih, dan policy apa yang berlaku. (Crocodic<\/a>)<\/p>\n\n\n\n

Namun AI Gateway dan AI FinOps bukan hal yang sama. Gateway adalah salah satu technical enforcement and telemetry layer<\/strong>, sedangkan AI FinOps merupakan operating practice yang menentukan bagaimana data consumption diterjemahkan menjadi budgeting, allocation, optimization, forecasting, dan business accountability.<\/p>\n\n\n\n

Secara sederhana:<\/p>\n\n\n\n

AI Gateway \u2192 menghasilkan control dan telemetry.<\/strong><\/p>\n\n\n\n

AI FinOps \u2192 menggunakan telemetry untuk membuat economic decision.<\/strong><\/p>\n\n\n\n

Gateway dapat membatasi 100 juta token per bulan. FinOps menentukan apakah batas tersebut masuk akal berdasarkan workflow value.<\/p>\n\n\n\n

8. Jangan Hanya Mengurangi Biaya; Hilangkan AI yang Tidak Dibutuhkan<\/strong><\/h2>\n\n\n\n

Tidak semua workload yang menggunakan AI sebenarnya membutuhkan AI. Ini mungkin optimization dengan ROI tertinggi.<\/p>\n\n\n\n

Jika process dapat diselesaikan dengan deterministic rule, jangan panggil reasoning model. Jika kebutuhan hanya memindahkan data dari ERP ke CRM, gunakan integration. Jika invoice hanya perlu divalidasi berdasarkan tiga deterministic field, gunakan rule engine. Jika satu query dapat diselesaikan dari database, AI tidak harus berada di tengah.<\/p>\n\n\n\n

AI sebaiknya digunakan pada bagian workflow yang membutuhkan interpretation, reasoning, language understanding, anomaly analysis, recommendation, atau kemampuan lain yang sulit diselesaikan deterministic software.<\/p>\n\n\n\n

Pendekatan tersebut berhubungan dengan AI Readiness Assessment Crocodic<\/a>, yang menempatkan business readiness dan system readiness sebelum keputusan integrasi AI. Jika process tidak mempunyai business value yang jelas atau underlying system belum siap, menambahkan AI justru dapat meningkatkan cost dan complexity tanpa memperbaiki operational outcome. (Crocodic<\/a>)<\/p>\n\n\n\n

AI FinOps terbaik kadang bukan menemukan model yang 30% lebih murah, tetapi menemukan workflow yang seharusnya tidak memanggil model sama sekali.<\/strong><\/p>\n\n\n\n

AI FinOps Bukan \u201cToken Cutting\u201d<\/strong><\/h2>\n\n\n\n

Fokus yang terlalu besar pada token dapat menciptakan optimization yang salah. Team dapat mempersingkat prompt tetapi accuracy turun sehingga human review bertambah. Model yang lebih murah menghasilkan lebih banyak errors sehingga retries meningkat. Agent steps dipotong tetapi task completion turun. Finance melihat model cost turun sementara total labor cost naik.<\/p>\n\n\n\n

Karena itu optimization perlu menjaga minimal tiga dimensions:<\/p>\n\n\n\n

Cost \u2192 Quality \u2192 Business Outcome<\/strong><\/p>\n\n\n\n

Menekan salah satunya tanpa dua lainnya bukan optimization.<\/p>\n\n\n\n

Model dapat dibandingkan menggunakan metric:<\/p>\n\n\n\n

Dimensi<\/strong><\/td>Contoh<\/strong><\/td><\/tr>
Cost<\/strong><\/td>cost per workflow<\/td><\/tr>
Quality<\/strong><\/td>acceptance rate<\/td><\/tr>
Latency<\/strong><\/td>time to completion<\/td><\/tr>
Reliability<\/strong><\/td>successful completion rate<\/td><\/tr>
Human Effort<\/strong><\/td>review minutes<\/td><\/tr>
Business Value<\/strong><\/td>revenue, savings, risk reduction<\/td><\/tr>
Risk<\/strong><\/td>error consequence<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Jika Model A menghabiskan Rp300 per workflow dengan 95% acceptance rate sedangkan Model B hanya Rp150 tetapi acceptance rate 60%, model yang terlihat dua kali lebih murah belum tentu lebih ekonomis setelah human rework diperhitungkan.<\/p>\n\n\n\n

Inilah alasan enterprise membutuhkan AI unit economics<\/strong>, bukan sekadar AI billing dashboard.<\/p>\n\n\n\n

Crocodic AI Cost Stack<\/strong><\/h2>\n\n\n\n

Untuk memahami total AI economics, Crocodic dapat membaginya menjadi lima layer.<\/p>\n\n\n\n

Layer<\/strong><\/td>Cost Driver<\/strong><\/td><\/tr>
Model Layer<\/strong><\/td>input\/output tokens, multimodal processing, embeddings<\/td><\/tr>
Context Layer<\/strong><\/td>retrieval, context size, vector database, search<\/td><\/tr>
Orchestration Layer<\/strong><\/td>agent steps, retries, model routing, multi-agent<\/td><\/tr>
System Layer<\/strong><\/td>API, compute, storage, network, observability<\/td><\/tr>
Business Layer<\/strong><\/td>human review, failure, rework, operational outcome<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Struktur ini membantu menjelaskan mengapa model invoice tidak selalu sama dengan true cost. Model layer mungkin hanya sebagian dari total economics, terutama ketika AI mulai masuk ke workflows yang membutuhkan integration dan human decision.<\/p>\n\n\n\n

Management kemudian dapat melakukan optimization pada layer yang tepat. Jika problem berada pada token, model right-sizing dapat membantu. Jika agent terlalu banyak melakukan retries, perbaiki workflow. Jika context terlalu besar, perbaiki retrieval. Jika human review tinggi, quality issue mungkin lebih penting daripada price. Jika use case tidak menghasilkan value, hentikan workload tersebut.<\/p>\n\n\n\n

Forecasting AI Agent Lebih Sulit daripada Forecasting Chatbot<\/strong><\/h2>\n\n\n\n

Chatbot dengan fixed user population relatif mudah diproyeksikan menggunakan jumlah user \u00d7 request \u00d7 average token. Agentic workflow mempunyai distribution yang lebih dinamis karena satu workflow dapat selesai dalam tiga steps atau tiga puluh steps. Selain itu user adoption dapat memperbesar jumlah workflow, dan agents sendiri dapat memicu workload tambahan tanpa direct human request.<\/p>\n\n\n\n

Karena itu forecasting sebaiknya menggunakan scenario, bukan hanya average.<\/p>\n\n\n\n

Misalnya:<\/p>\n\n\n\n

Low Scenario<\/strong> \u2014 adoption 20%, average 5 agent steps.
Base Scenario<\/strong> \u2014 adoption 50%, average 8 steps.
High Scenario<\/strong> \u2014 adoption 80%, average 15 steps.<\/p>\n\n\n\n

Kemudian tambahkan model mix, context size, retries, dan quality escalation. McKinsey juga menyarankan AI FinOps forecasting mulai memperhitungkan adoption growth, workflow expansion, routing changes, serta shifts antara frontier dan open-weight models. Organisasi dengan forecasting maturity lebih tinggi dilaporkan memiliki AI spending efficiency yang lebih baik. (McKinsey & Company<\/a>)<\/p>\n\n\n\n

Forecast seperti ini membantu CIO dan CFO melihat bukan hanya kemungkinan invoice bulan depan, tetapi cost curve ketika AI benar-benar berhasil diadopsi<\/strong>.<\/p>\n\n\n\n

Ironisnya, AI initiative yang berhasil dapat menciptakan cost problem terbesar karena semakin banyak business users ingin menggunakannya.<\/p>\n\n\n\n

Showback Sebelum Chargeback<\/strong><\/h2>\n\n\n\n

Tidak semua organization perlu langsung menagihkan biaya AI ke business unit. Chargeback terlalu awal dapat mengurangi experimentation dan membuat user menghindari use case yang sebenarnya bernilai. Tetapi setidaknya setiap unit sebaiknya dapat melihat konsumsi dan economics-nya melalui showback<\/strong>.<\/p>\n\n\n\n

Misalnya dashboard menunjukkan:<\/p>\n\n\n\n

Finance AI: Rp80 juta\/bulan.
Customer Service AI: Rp150 juta\/bulan.
Engineering AI: Rp200 juta\/bulan.<\/p>\n\n\n\n

Angka tersebut kemudian harus dihubungkan dengan output:<\/p>\n\n\n\n

Finance AI \u2192 120.000 invoice reviews.
Customer Service \u2192 45.000 resolved interactions.
Engineering AI \u2192 productivity metrics atau accepted tasks.<\/p>\n\n\n\n

Diskusi budget lalu menjadi lebih produktif. Finance tidak hanya melihat \u201cAI menghabiskan Rp430 juta\u201d, tetapi dapat membandingkan workload yang menghasilkan value dengan workload yang tidak.<\/p>\n\n\n\n

AI FinOps pada akhirnya meningkatkan accountability<\/strong>, bukan hanya control.<\/p>\n\n\n\n

Kapan Open-Weight atau Self-Hosted Model Lebih Ekonomis?<\/strong><\/h2>\n\n\n\n

Ketika volume AI sangat tinggi, organisasi sering mulai mempertanyakan apakah model API masih menjadi pilihan paling ekonomis. Open-weight model atau self-hosting dapat memberikan control lebih besar dan pada workload tertentu cost yang lebih rendah, tetapi economics-nya perlu dihitung secara lengkap.<\/p>\n\n\n\n

API provider membuat organisasi membayar consumption dan memperoleh managed infrastructure. Self-hosted model memindahkan responsibility kepada organization: GPU capacity, utilization, model serving, scaling, upgrades, security, reliability, monitoring, dan engineering.<\/p>\n\n\n\n

Karena itu break-even tidak dapat dihitung hanya dengan membandingkan harga per token. Workload volume, utilization pattern, latency requirement, model quality, operational team, dan hardware commitment perlu diperhitungkan.<\/p>\n\n\n\n

Gartner melihat open-weight models sebagai salah satu optimization path untuk high-cost agentic workload, tetapi hal tersebut membawa trade-off engineering dan infrastructure yang harus dipertimbangkan. (Gartner<\/a>) AWS juga menekankan bahwa inference paradigm\u2014managed, provisioned, hosted, on-demand, atau batch\u2014mempunyai cost structure berbeda dan perlu dipilih berdasarkan workload. (Dokumentasi AWS<\/a>)<\/p>\n\n\n\n

Dengan demikian pilihan architecture harus mengikuti total cost of intelligence<\/strong>, bukan hanya provider price list.<\/p>\n\n\n\n

AI FinOps Maturity Model<\/strong><\/h2>\n\n\n\n

Perusahaan tidak perlu langsung membangun sophisticated AI cost platform. Capability dapat berkembang bertahap.<\/p>\n\n\n\n

Level<\/strong><\/td>Kondisi<\/strong><\/td><\/tr>
Level 1 \u2014 Invisible<\/strong><\/td>AI spend tersebar, ownership tidak jelas<\/td><\/tr>
Level 2 \u2014 Visible<\/strong><\/td>Provider, model, application, dan token terlihat<\/td><\/tr>
Level 3 \u2014 Allocated<\/strong><\/td>Cost dapat dipetakan ke team\/use case<\/td><\/tr>
Level 4 \u2014 Unit Economics<\/strong><\/td>Cost per workflow\/outcome tersedia<\/td><\/tr>
Level 5 \u2014 Optimized<\/strong><\/td>Model routing, budget, forecast, anomaly control aktif<\/td><\/tr>
Level 6 \u2014 Value Governed<\/strong><\/td>AI investment dialokasikan berdasarkan risk-adjusted business value<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

FinOps Foundation merekomendasikan pendekatan maturity crawl, walk, run<\/strong>, karena organization akan lebih cepat mencapai sustainable cost practice dengan membangun visibility dan attribution terlebih dahulu daripada menunggu comprehensive governance selesai. (FinOps Foundation<\/a>)<\/p>\n\n\n\n

Perusahaan pada Level 1 belum membutuhkan complex dynamic model router. Yang dibutuhkan adalah mengetahui siapa menggunakan AI. Perusahaan pada Level 4 mungkin sudah layak memperkenalkan workload routing, quality-adjusted unit economics, atau automated optimization.<\/p>\n\n\n\n

AI FinOps KPI untuk CIO dan CFO<\/strong><\/h2>\n\n\n\n

Dashboard yang hanya menampilkan total token tidak cukup untuk management. KPI perlu menghubungkan consumption, technical quality, dan outcome.<\/p>\n\n\n\n

KPI<\/strong><\/td>Apa yang Diukur<\/strong><\/td><\/tr>
Total AI Spend<\/td>Budget exposure keseluruhan<\/td><\/tr>
Spend by Business Unit<\/td>Ownership<\/td><\/tr>
Spend by Use Case<\/td>Portfolio allocation<\/td><\/tr>
Cost per Workflow<\/td>Operational unit economics<\/td><\/tr>
Cost per Accepted Outcome<\/td>Quality-adjusted economics<\/td><\/tr>
Frontier Model Ratio<\/td>Dependency pada high-cost model<\/td><\/tr>
Average Agent Steps<\/td>Agent complexity<\/td><\/tr>
Retry Rate<\/td>Waste\/reliability<\/td><\/tr>
Human Override Rate<\/td>Quality\/control<\/td><\/tr>
AI Spend Variance<\/td>Forecast accuracy<\/td><\/tr>
Cost Growth vs Usage Growth<\/td>Efficiency<\/td><\/tr>
Cost Growth vs Business Value<\/td>ROI alignment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Salah satu metric paling berguna adalah cost per accepted outcome<\/strong> karena metric ini sulit dimanipulasi hanya dengan menurunkan token. Jika cost turun tetapi acceptance rate ikut turun, metric tersebut akan mengungkapnya.<\/p>\n\n\n\n

AI FinOps Juga Merupakan Architecture Discipline<\/strong><\/h2>\n\n\n\n

Sebagian besar AI cost sebenarnya ditentukan oleh engineering decision. Menggunakan satu model atau multi-model, memasukkan seluruh conversation history atau melakukan summarization, menggunakan RAG atau memasukkan dokumen penuh, single agent atau multi-agent, real-time inference atau batch processing\u2014semuanya merupakan architecture decisions sebelum menjadi finance problem.<\/p>\n\n\n\n

Itulah sebabnya AI FinOps perlu masuk ke architecture review.<\/p>\n\n\n\n

Sebelum production, team dapat menjawab: berapa estimated workflow cost, bagaimana cost berubah jika adoption meningkat 10\u00d7, model mana yang dapat diganti, apakah context mempunyai limit, apakah retry dibatasi, dan apakah workflow mempunyai fallback deterministic.<\/p>\n\n\n\n

Jika pertanyaan tersebut hanya muncul setelah invoice besar datang, FinOps berubah menjadi remediation.<\/p>\n\n\n\n

Praktik yang lebih mature membuat economics menjadi design constraint<\/strong> sejak awal.<\/p>\n\n\n\n

AI cost bukan sesuatu yang terjadi setelah architecture selesai. Architecture adalah salah satu faktor yang menentukan AI cost.<\/strong><\/p>\n\n\n\n

Apa Hubungan AI FinOps, AI Gateway, dan AI Orchestration?<\/strong><\/h2>\n\n\n\n

Ketiganya berhubungan tetapi tidak interchangeable. AI Gateway Crocodic<\/a> menyediakan centralized control terhadap model access, quota, routing, usage, dan cost telemetry. AI Orchestration Crocodic<\/a> mengatur bagaimana model, data, tools, agents, workflow, dan manusia bekerja bersama untuk menyelesaikan outcome. AI FinOps menggunakan data dari kedua layer tersebut untuk menjawab apakah seluruh consumption ekonomis dan bagaimana budget sebaiknya dialokasikan.<\/p>\n\n\n\n

Hubungannya dapat digambarkan:<\/p>\n\n\n\n

Business Workflow \u2192 AI Orchestration \u2192 AI Gateway \u2192 Models \/ Providers<\/strong><\/p>\n\n\n\n

sementara:<\/p>\n\n\n\n

Telemetry \u2192 AI FinOps \u2192 Budget \/ Optimization \/ Governance Decision<\/strong><\/p>\n\n\n\n

Misalnya AI FinOps menemukan satu workflow memakai frontier model untuk 90% request padahal evaluation menunjukkan hanya 15% yang membutuhkan reasoning tinggi. Policy kemudian dapat diubah pada gateway atau orchestration agar simple tasks menggunakan model lebih murah. Setelah perubahan, quality dan cost per outcome dievaluasi kembali.<\/p>\n\n\n\n

Ini adalah feedback loop, bukan one-time optimization.<\/p>\n\n\n\n

Crocodic Perspective: Optimize Intelligence per Outcome, Bukan Token per Request<\/strong><\/h2>\n\n\n\n

Token optimization memang penting, tetapi enterprise sebaiknya menghindari kondisi di mana seluruh AI strategy akhirnya berubah menjadi kompetisi membuat prompt termurah. Intelligence memiliki value ketika menghasilkan capability yang sebelumnya mahal, lambat, atau sulit dilakukan.<\/p>\n\n\n\n

Karena itu Crocodic melihat optimization menggunakan urutan berikut:<\/p>\n\n\n\n

Business Outcome \u2192 Required Quality \u2192 Required Intelligence \u2192 Lowest Sustainable Cost<\/strong><\/p>\n\n\n\n

bukan:<\/p>\n\n\n\n

Lowest Cost Model \u2192 Cari Pekerjaan untuk Model Tersebut.<\/strong><\/p>\n\n\n\n

Business outcome menentukan quality threshold. Quality threshold menentukan intelligence yang dibutuhkan. Architecture kemudian mencari cara paling ekonomis menyediakan intelligence tersebut.<\/p>\n\n\n\n

AI FinOps yang matang tidak bertanya \u201cberapa sedikit token yang bisa kita gunakan?\u201d, tetapi \u201cberapa sedikit intelligence cost yang diperlukan untuk mencapai outcome pada quality dan risk level yang dapat diterima?\u201d<\/strong><\/p>\n\n\n\n

Pendekatan tersebut membuat Finance dan Engineering menggunakan bahasa yang sama. Engineering tidak dipaksa sekadar menekan token, sementara Finance dapat memahami alasan beberapa workflows memang membutuhkan model atau architecture yang lebih mahal.<\/p>\n\n\n\n

Roadmap Implementasi AI FinOps<\/strong><\/h2>\n\n\n\n

Tahap pertama adalah membuat inventory seluruh penggunaan AI: provider, models, applications, agents, owners, business units, API keys, contracts, dan payment methods. Tahap kedua adalah membangun attribution sehingga consumption dapat dipetakan ke application dan use case. Tahap ketiga mulai mengukur unit economics seperti cost per workflow. Tahap keempat menghubungkan cost dengan acceptance rate dan business outcome. Baru setelah foundation tersebut tersedia, organization dapat memperluas optimization melalui model routing, context optimization, caching, batch processing, agent limits, provider negotiation, atau open-weight models.<\/p>\n\n\n\n

Roadmap sederhananya adalah:<\/p>\n\n\n\n

Discover \u2192 Attribute \u2192 Measure \u2192 Optimize \u2192 Govern \u2192 Forecast<\/strong><\/p>\n\n\n\n

Setiap tahap menghasilkan capability untuk tahap berikutnya. Model routing tanpa attribution dapat memangkas biaya tetapi perusahaan tidak tahu siapa mendapat benefit. Budget tanpa unit economics dapat membatasi innovation yang justru profitable. Forecast tanpa observability hanya menghasilkan spreadsheet berdasarkan asumsi.<\/p>\n\n\n\n

AI FinOps sebaiknya berkembang bersama maturity AI perusahaan.<\/p>\n\n\n\n

Jangan Menunggu AI Spend Menjadi Besar<\/strong><\/h2>\n\n\n\n

AI FinOps tidak harus menjadi enterprise transformation programme saat organization baru mempunyai beberapa workloads. Tetapi instrumentasi dasar sebaiknya dimulai lebih awal karena architecture yang dibuat tanpa attribution akan semakin sulit diperbaiki ketika adoption tumbuh.<\/p>\n\n\n\n

Gartner memperkirakan global AI-optimized IaaS spending mencapai sekitar US$42,3 miliar pada 2026, meningkat sekitar 96% dari tahun sebelumnya. Gartner juga memperkirakan spending inference mencapai US$23,3 miliar dan melampaui training pada tahun yang sama, seiring AI berpindah dari model development menuju continuous execution di production workflows. (Gartner<\/a>)<\/p>\n\n\n\n

Pergeseran tersebut menggambarkan perubahan economics yang lebih luas. Biaya AI di masa depan bukan hanya biaya membangun model atau melakukan pilot. Semakin banyak biaya akan berasal dari menjalankan intelligence secara terus-menerus di dalam proses bisnis<\/strong>.<\/p>\n\n\n\n

Dengan kata lain, AI spend akan semakin menyerupai operational cost.<\/p>\n\n\n\n

Operational cost membutuhkan ownership, monitoring, forecasting, dan optimization.<\/p>\n\n\n\n

Dari AI Experiment Menuju AI Unit Economics<\/strong><\/h2>\n\n\n\n

Pada tahap experimentation, keberhasilan sering diukur dari apakah AI dapat melakukan sesuatu. Pada tahap enterprise scale, pertanyaannya berubah menjadi apakah AI dapat melakukan sesuatu secara reliable, aman, dan ekonomis<\/strong>.<\/p>\n\n\n\n

Sebuah agent yang mampu menyelesaikan procurement analysis memang menarik. Namun enterprise harus mengetahui berapa cost-nya, berapa banyak yang dapat dilakukan per bulan, bagaimana cost berubah ketika adoption tumbuh, berapa persentase hasil yang diterima user, model apa yang sebenarnya diperlukan, dan apakah business value lebih besar daripada total operational cost.<\/p>\n\n\n\n

McKinsey menemukan hanya sekitar 20\u201325% organisasi dalam surveinya yang sudah memiliki mature AI FinOps capabilities, meskipun mayoritas telah bergerak melampaui experimentation. Mereka merekomendasikan centralized AI control plane yang memberikan single view terhadap spend, usage, performance, dan business outcomes agar organization dapat melakukan forecasting dan optimization dengan lebih baik. (McKinsey & Company<\/a>)<\/p>\n\n\n\n

Di sinilah AI FinOps seharusnya diposisikan: bukan sebagai mekanisme Finance untuk memperlambat AI adoption, tetapi sebagai capability yang memungkinkan perusahaan melakukan scaling tanpa kehilangan economics<\/strong>.<\/p>\n\n\n\n

Jika penggunaan AI perusahaan mulai tersebar di berbagai aplikasi dan model, AI Gateway Crocodic<\/a> dapat menjadi salah satu technical foundation untuk model routing, quota, usage tracking, dan cost visibility. Jika cost muncul dari workflow yang melibatkan banyak models, agents, tools, dan enterprise systems, AI Orchestration Crocodic<\/a> membantu memisahkan langkah mana yang memang membutuhkan intelligence dan mana yang sebaiknya tetap deterministic. Untuk organisasi yang masih belum mengetahui apakah data, system, governance, dan economics-nya siap untuk scale, AI Readiness Assessment Crocodic<\/a> dapat menjadi assessment layer sebelum architecture diperluas.<\/p>\n\n\n\n

AI yang lebih murah tidak otomatis menghasilkan AI strategy yang lebih baik. AI yang lebih powerful juga tidak otomatis menghasilkan business value lebih tinggi. Enterprise membutuhkan kemampuan untuk mengetahui berapa banyak intelligence yang dikonsumsi, siapa yang menggunakannya, untuk outcome apa, dan apakah economics-nya tetap masuk akal ketika penggunaan meningkat dari ratusan menjadi jutaan workflows.<\/strong><\/p>\n\n\n\n

Itulah peran AI FinOps: mengubah biaya AI dari tagihan teknologi yang sulit diprediksi menjadi business economics yang dapat dilihat, dipertanggungjawabkan, dan dioptimalkan secara berkelanjutan<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"

Ketika perusahaan hanya memiliki satu chatbot internal atau satu proof-of-concept generative AI, biaya biasanya masih mudah dipahami. Tim mengetahui model yang digunakan, jumlah pengguna relatif kecil, dan tagihan provider dapat dilihat sebagai bagian dari experimentation budget. Situasinya berubah ketika AI masuk ke customer service, finance, software development, internal knowledge, document processing, analytics, dan AI agents […]<\/p>\n","protected":false},"author":42,"featured_media":14039,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[1498],"tags":[],"class_list":["post-14672","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-enterprise-automation"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/posts\/14672","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/comments?post=14672"}],"version-history":[{"count":1,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/posts\/14672\/revisions"}],"predecessor-version":[{"id":14673,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/posts\/14672\/revisions\/14673"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/media\/14039"}],"wp:attachment":[{"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/media?parent=14672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/categories?post=14672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/crocodic.com\/en\/wp-json\/wp\/v2\/tags?post=14672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}