Perusahaan Perlu AI Operating Model, Bukan Sekadar Kebijakan Penggunaan

✦ UNDERCOVER.ID KNOWLEDGE SYSTEM

Perusahaan Perlu AI Operating Model, Bukan Sekadar Kebijakan Penggunaan

◆ FormatPost
↻ Diperbarui11 October 2026
◷ Waktu baca8 menit
✦ KonteksPanduan praktis

Bayangkan sebuah perusahaan sudah punya kebijakan AI.

Dokumennya jelas.

Jangan masukkan data sensitif.

Gunakan tool approved.

Human review untuk output tertentu.

Laporkan incident.

Selesai.

Apakah sekarang perusahaan siap scale AI?

Belum.

Policy menjawab apa yang boleh dan tidak.

Operating model menjawab bagaimana pekerjaan sebenarnya berjalan.

Siapa punya keputusan.

Siapa owner.

Bagaimana use case dipilih.

Bagaimana data diakses.

Bagaimana agent diberi permission.

Bagaimana output dipantau.

Bagaimana cost dikontrol.

Bagaimana improvement masuk production.

Bagaimana incident ditangani.

Policy tanpa operating model mirip punya aturan lalu lintas tanpa jalan, lampu merah, marka, SIM, dan petugas.

Aturannya ada.

Sistemnya belum.

Thoughtworks pada Juli 2026 menyebut banyak initiative AI enterprise bukan gagal karena model lemah, tapi karena organisasi belum membangun “operating system” yang diperlukan untuk govern, scale, dan belajar dari AI-enabled work. Problem yang mereka sorot sangat familiar: accountability kabur, ownership terfragmentasi, governance lemah, measurement buruk, organizational learning terbatas.

Ini inti operating model.

Bukan satu dokumen.

Cara perusahaan menjalankan AI setiap hari.

Siapa boleh memulai use case?

Kalau jawabannya “siapa saja”, innovation cepat.

Risk bisa chaos.

Kalau jawabannya “hanya tim pusat”, aman tapi lambat.

Operating model perlu jalur tengah.

Misalnya semua employee boleh mengusulkan.

Low-risk experiment bisa langsung masuk sandbox.

Use case dengan customer data perlu review.

Agent yang punya write access butuh architecture check.

High-risk decision perlu approval tambahan.

Ada intake.

Ada classification.

Ada path.

Dengan begitu orang tahu.

Tidak perlu bertanya dari nol setiap kali.

Ini jauh lebih scalable daripada policy yang hanya bilang “harus bertanggung jawab”.

Responsible menurut siapa?

Dalam flow apa?

Di titik mana?

Operating model menerjemahkan prinsip menjadi mekanisme.

Decision rights lebih penting dari org chart

Perusahaan suka menggambar box.

AI Steering Committee.

AI CoE.

Data Office.

IT.

Risk.

Legal.

Business Unit.

Diagramnya cantik.

Masalah muncul saat use case nyata datang.

Siapa yang boleh menyetujui?

Siapa yang bisa menghentikan?

Siapa yang menentukan model?

Siapa yang menerima residual risk?

Siapa yang bertanggung jawab kalau output salah?

Kalau tidak ada jawaban, org chart cuma dekorasi.

Decision rights harus explicit.

Contoh:

Business owner memutuskan outcome dan menerima operational accountability.

AI platform team memilih approved technical pattern.

Security mengatur identity dan access.

Legal menentukan restriction pada use case tertentu.

Risk menetapkan threshold.

Finance memonitor economics.

Tidak semua harus masuk committee.

Banyak keputusan bisa delegated.

Operating model yang bagus memperjelas siapa memutus apa.

Semakin banyak agent, semakin penting.

Karena agent tidak menunggu rapat setiap kali action.

Boundary harus dibangun sebelum runtime.

Autonomy harus punya level

Tidak semua AI sama.

Writing assistant.

Recommendation system.

Agent yang bisa mengirim email.

Agent yang bisa mengubah database.

Agent yang bisa membayar.

Kalau policy memperlakukan semuanya sama, control salah.

Operating model harus punya autonomy tier.

Misalnya:

Tier 0: AI memberi informasi.

Tier 1: AI membuat draft.

Tier 2: AI mengeksekusi action reversible dengan approval.

Tier 3: AI otomatis dalam scope terbatas.

Tier 4: AI punya autonomy lebih luas dengan monitoring ketat.

Nama tier bisa beda.

Prinsipnya sama.

Semakin besar impact dan irreversibility, semakin kuat control.

Ini membantu business bergerak.

Mereka tidak perlu debat abstrak “agent boleh autonomous nggak”.

Pertanyaannya lebih spesifik:

Untuk workflow ini, autonomy level berapa?

Jawabannya bisa berubah setelah evidence.

Awal approval manual.

Setelah reliability tinggi, sebagian otomatis.

Operating model bersifat evolutif.

Data access harus menjadi bagian desain

AI policy sering bilang:

“Jangan masukkan data confidential.”

Bagus.

Operating model bertanya:

Bagaimana memastikan?

Apakah system punya connector resmi?

Apakah data classification terbaca?

Apakah access mengikuti user permission?

Apakah agent punya service identity sendiri?

Apakah log disimpan?

Apakah cross-region data flow dibatasi?

Ini technical, tapi sangat operational.

AI semakin tidak hanya menerima copy-paste.

Ia terhubung ke system.

Begitu connector masuk, risk berubah.

User mungkin bisa baca 10 file.

Agent dengan credential salah bisa membaca 10 juta.

Maka least privilege penting.

Operating model harus menentukan pattern.

Jangan memberi agent master key hanya karena lebih gampang.

Permission adalah desain kerja.

Bukan security detail belakangan.

Model lifecycle juga perlu owner

Vendor model update.

Performance berubah.

Harga berubah.

Feature berubah.

Perusahaan perlu process.

Apakah update otomatis dipakai?

Perlu regression test?

Use case kritis harus pin version?

Siapa monitor?

Kalau model retired, apa fallback?

Operating model menjawab.

Ini berbeda dari software tradisional karena AI output probabilistic.

Version change bisa mengubah behavior tanpa code internal berubah.

Makanya evaluation harus berulang.

Bukan hanya saat launch.

Untuk use case penting, perusahaan perlu golden dataset atau test scenario sendiri.

Model baru diuji.

Kalau lebih baik, pindah.

Kalau tidak, tahan.

Ini capability yang nggak muncul di policy.

Tapi sangat menentukan reliability.

Human role harus punya desain, bukan slogan

“Human in the loop.”

Kalimat favorit semua policy.

Loop-nya di mana?

Kalau human harus review 10 ribu output, impossible.

Kalau human cuma approve tanpa context, meaningless.

Operating model menentukan.

Manusia review exception.

Atau sample.

Atau high-risk case.

Atau action di atas threshold.

Design harus sustainable.

Misalnya customer service agent.

AI menangani FAQ.

Human menerima low-confidence case.

Mereka melihat conversation summary.

Bisa override.

Feedback masuk evaluation.

Itu loop yang nyata.

Bukan checkbox.

Perusahaan perlu mendesain human attention sebagai resource langka.

Jangan minta manusia melihat semuanya.

Minta mereka melihat yang penting.

KPI harus mengikuti operating model

Kalau pekerjaan berubah, metric juga.

Customer service dulu diukur tickets handled.

Setelah AI mengambil easy case, human agent menerima case sulit.

Ticket count turun.

Kalau KPI lama tetap, employee terlihat lebih buruk.

Padahal value per case naik.

Operating model harus menghubungkan role dan metric.

Sales proposal otomatis?

Jangan ukur jumlah proposal saja.

Lihat win rate.

Cycle time.

Margin.

Error.

Finance automation?

Lihat close time.

Adjustment.

Exception.

Decision support?

Lihat time to decision dan reversals.

AI mengubah unit of work.

KPI lama sering tidak cocok.

Kalau metric tidak berubah, employee akan optimize ke cara lama.

Transformation tertahan.

Cost governance juga bagian operating model

AI punya cost yang tidak selalu fixed.

Token.

Inference.

Agent loops.

Tool calls.

Storage.

Search.

Compute.

Jika satu agent error dan looping, bill bisa naik.

Perusahaan perlu budget control.

Quota.

Cost per task.

Routing.

Model tier.

Caching.

Observability.

Finance harus bisa melihat.

Ini bukan sekadar IT cost.

Kalau agent menjadi bagian process, variable cost masuk unit economics.

COO dan CFO perlu paham.

Operating model menentukan siapa yang mengoptimalkan.

Developer?

Platform team?

Business?

Semua punya role.

Tanpa ownership, cost dibayar corporate dan business tidak punya incentive efisien.

Chargeback atau showback bisa membantu.

Bukan untuk menghukum.

Untuk visibility.

Incident response jangan menunggu incident pertama

Apa yang terjadi kalau agent mengirim email salah ke 5.000 customer?

Siapa yang bisa stop?

Bagaimana revoke credential?

Bagaimana rollback?

Siapa komunikasi eksternal?

Apakah log cukup?

Policy mungkin menulis “laporkan incident”.

Operating model punya playbook.

Severity.

Channel.

Owner.

Kill switch.

Evidence.

Postmortem.

Learning.

Ini makin penting ketika AI bisa action.

Chatbot salah jawab bisa diperbaiki.

Agent salah action mungkin sudah terjadi di dunia nyata.

Operating model harus punya reversibility.

Kalau action tidak bisa dibalik, threshold autonomy harus lebih rendah.

Simple principle.

Production system butuh operational thinking.

AI tidak boleh jadi exception karena masih baru.

Learning loop adalah bagian paling underrated

Model dan use case berubah cepat.

Operating model yang statis cepat basi.

Perusahaan perlu cadence.

Weekly operational review untuk critical agents.

Monthly portfolio review.

Quarterly model and vendor review.

Incident learning.

User feedback.

Evaluation refresh.

Workflow performance.

Ini membuat organisasi belajar.

Bukan sekadar deploy.

Thoughtworks menekankan organizational learning sebagai salah satu komponen yang sering hilang.

Masuk akal.

AI tidak pernah benar-benar “selesai implementasi”.

System terus berubah.

Data berubah.

User berubah.

Model update.

Regulation berubah.

Operating model harus adapt.

Kalau policy hanya direview setahun sekali, terlalu lambat.

Prinsip tetap stabil.

Mechanism bisa berubah.

Jakarta corporate life punya contoh sederhana

Bayangkan perusahaan dengan kantor di SCBD.

Karyawan pakai AI.

Sales di lapangan.

Finance terpusat.

Customer service outsourced.

Data center cloud.

Vendor global.

Policy perusahaan mungkin satu.

Workflow tersebar.

Operating model harus bisa hidup di seluruh kondisi itu.

Siapa owner kalau outsourced agent memakai AI?

Apa access-nya?

Bagaimana customer data?

Siapa monitor?

Kalau hanya punya “AI acceptable use policy”, banyak pertanyaan tidak terjawab.

Business tidak butuh teori.

Mereka butuh operating answer.

Kalau jam 4 sore ada incident, siapa telepon siapa?

Kalau use case baru muncul besok, masuk jalur mana?

Itulah operating model.

AI operating model seharusnya membuat keputusan lebih cepat, bukan lebih banyak meeting

Ada kekhawatiran kalau governance lengkap berarti bureaucracy.

Seharusnya kebalik.

Kalau rule dan decision rights jelas, meeting berkurang.

Low-risk use case jalan.

High-risk tahu reviewer.

Tool approved jelas.

Data path jelas.

Tim tidak perlu mencari sponsor setiap kali.

Good operating model membuat organisasi predictable.

Prediction mengurangi friction.

Orang tahu process.

Ini kenapa governance dan speed tidak harus berlawanan.

Governance buruk memperlambat.

Governance bagus mempercepat karena menghilangkan ambiguity.

AI operating model bukan satu model universal

Perusahaan bank beda dengan agency.

Healthcare beda dengan e-commerce.

Startup beda dengan conglomerate.

Ada yang centralized.

Ada yang federated.

Ada yang platform-led.

Yang penting elemen dasarnya terjawab.

Value ownership.

Decision rights.

Data access.

Autonomy.

Human oversight.

Evaluation.

Cost.

Incident.

Learning.

Talent.

Jika semuanya punya mekanisme, operating model mulai hidup.

Kalau hanya policy penggunaan, organisasi punya rule tanpa mesin.

AI di perusahaan 2026 sudah terlalu dekat dengan pekerjaan inti untuk dikelola sebagai “software baru”.

Ia bisa membaca.

Membuat.

Memutuskan.

Bertindak.

Itu menyentuh operating model.

Perusahaan yang menyadari ini lebih awal akan punya advantage.

Bukan karena mereka punya rule lebih banyak.

Tapi karena mereka tahu bagaimana manusia, data, model, agent, dan keputusan bekerja sebagai satu sistem.

Policy bilang apa yang jangan dilakukan.

Operating model membuat pekerjaan baru benar-benar bisa dilakukan.

Scroll to Top