Back to Projects
ScamShield ID: Building an Evidence-Grounded AI Agent for Digital Fraud Triage
Merancang workflow AI agent berbasis Langflow dan Gemini untuk menganalisis bukti dugaan penipuan digital, menghasilkan structured risk assessment, mengekstrak entitas penting, dan menyusun rekomendasi berbasis bukti.
LangflowGeminiGenerative AILLMPrompt EngineeringStructured OutputsAI Agent WorkflowJSON Schema
Overview
ScamShield ID adalah prototipe AI-powered digital fraud triage agent yang dirancang untuk membantu pengguna melakukan analisis awal terhadap bukti dugaan penipuan digital secara lebih terstruktur.
Alih-alih hanya meminta Large Language Model (LLM) menjawab pertanyaan umum seperti "Apakah ini penipuan?", sistem memecah proses analisis menjadi beberapa tahap dan memaksa model menghasilkan keluaran terstruktur yang mencakup kategori insiden, tahap kejadian, tingkat risiko, confidence score, entitas yang berhasil diekstrak, ringkasan kasus, dan rekomendasi tindakan selanjutnya.
Masalah utama yang ingin saya eksplorasi melalui proyek ini bukan sekadar kemampuan LLM memahami teks, tetapi bagaimana sebuah LLM dapat ditempatkan di dalam workflow yang lebih terkontrol agar:
- tidak bebas membuat struktur jawabannya sendiri,
- membedakan fakta yang tersedia dari asumsi,
- menghasilkan output yang dapat digunakan kembali oleh sistem lain, dan
- mengubah hasil analisis mesin menjadi laporan yang tetap mudah dipahami manusia.
ScamShield ID dikembangkan sebagai capstone project dengan pendekatan AI agent workflow, menggunakan Langflow sebagai orchestration layer dan Gemini sebagai model utama.
Important limitation: ScamShield ID merupakan sistem triage, bukan sistem verifikasi fakta atau penentu hukum. Analisis dibatasi pada bukti yang diberikan pengguna dan tidak secara otomatis membuktikan bahwa suatu organisasi, rekening, individu, atau pesan benar-benar merupakan pelaku penipuan.
My Role
Sebagai pengembang utama, saya merancang alur sistem mulai dari problem formulation hingga structured output dan human-readable report generation.
Fokus utama implementasi saya meliputi:
- Merancang workflow multi-stage menggunakan Langflow untuk memisahkan proses analisis bukti, pembentukan structured risk assessment, pengecekan informasi, dan penyusunan laporan akhir.
- Mendesain prompt agar LLM melakukan analisis hanya berdasarkan bukti yang tersedia dan menghindari penambahan detail yang tidak didukung input.
- Mendefinisikan output schema yang konsisten untuk menangkap informasi seperti
case_stage,incident_category,risk_level,overall_confidence, danextracted_entities. - Mengembangkan proses entity extraction terhadap nama organisasi, individu, platform, rekening bank, nominal transaksi, nomor telepon, URL, timestamp, serta informasi sensitif yang mungkin telah diberikan korban.
- Menguji workflow menggunakan skenario dugaan penipuan dengan karakteristik berbeda dan melakukan debugging terhadap masalah structured output, schema mismatch, dan report rendering.
- Mengubah structured machine output menjadi laporan yang lebih mudah dibaca manusia menggunakan tahap formatting terpisah.
System Architecture
Secara konseptual, ScamShield ID menggunakan alur:
terminal
User Evidence
↓
Evidence Analysis
↓
Structured Risk Assessment
↓
Evidence / Consistency Checking
↓
Human-Readable Report Formatter
↓
Final Fraud Triage Report
Workflow Architecture: ...
Pemisahan ini dilakukan karena membiarkan satu prompt menangani seluruh proses sekaligus membuat behavior model lebih sulit dikontrol.
Dengan memecah workflow, setiap tahap memiliki tanggung jawab yang lebih sempit.
1. Evidence Input
Pengguna memberikan bukti yang ingin dianalisis, misalnya:
- isi percakapan,
- deskripsi kronologi,
- informasi transaksi,
- URL,
- nomor rekening,
- nomor telepon,
- nama organisasi,
- atau informasi relevan lain yang tersedia pada kasus.
Sistem tidak seharusnya memperlakukan informasi yang tidak terdapat pada input sebagai fakta.
Prinsip ini menjadi salah satu constraint utama dalam desain prompt ScamShield.
2. Evidence Analysis
Pada tahap pertama, LLM membaca keseluruhan bukti dan mencoba memahami pola kasus.
Model diminta mengidentifikasi beberapa aspek utama:
- apa yang sedang terjadi,
- pada tahap mana insiden berada,
- kategori dugaan penipuan,
- indikator risiko yang terlihat,
- informasi sensitif yang mungkin sudah diberikan,
- serta entitas penting yang dapat diekstrak dari bukti.
Tahap ini dirancang sebagai proses evidence-grounded reasoning, yaitu keputusan harus dapat ditelusuri kembali ke informasi yang benar-benar terdapat pada input.
3. Structured Risk Assessment
Hasil analisis tidak langsung diberikan sebagai paragraf bebas.
Sebaliknya, LLM diwajibkan mengikuti struktur output tertentu.
Struktur inti yang saya gunakan antara lain:
terminal
{
"case_id": "string",
"case_stage": "PRE_TRANSFER | POST_TRANSFER | POST_CREDENTIALS",
"incident_category": "FAKE_RECRUITMENT | PHISHING | INVESTMENT | FAKE_SHOP | ACCOUNT_TAKEOVER | OTHERS",
"risk_level": "LOW | MEDIUM | HIGH",
"overall_confidence": 0.0,
"summary": "string",
"final_recommendation": "string",
"safety_note": "string",
"extracted_entities": {
"claimed_organization_names": [],
"person_names": [],
"platforms": [],
"bank_names": [],
"bank_accounts": [],
"account_holder_names": [],
"transaction_amounts": [],
"phone_numbers": [],
"urls": [],
"key_timestamps": [],
"disclosed_sensitive_information": []
}
}
Pendekatan ini membuat output model lebih mudah:
- divalidasi,
- ditampilkan pada UI,
- diteruskan ke workflow lain,
- disimpan dalam database,
- maupun dianalisis secara programatik.
Why Structured Output Matters
Salah satu eksperimen utama dalam proyek ini adalah membandingkan mental model antara LLM sebagai chatbot dan LLM sebagai komponen sistem.
Jika model hanya menghasilkan respons bebas seperti:
"Pesan ini kemungkinan besar adalah penipuan. Sebaiknya berhati-hati dan jangan melakukan pembayaran."
hasil tersebut mudah dibaca manusia tetapi sulit digunakan oleh aplikasi lain.
Sebaliknya, structured output memberikan contract yang lebih jelas:
terminal
risk_level → HIGH
case_stage → PRE_TRANSFER
incident_category → FAKE_RECRUITMENT
overall_confidence → 0.95
Sistem lain kemudian dapat menggunakan informasi tersebut tanpa harus melakukan parsing terhadap paragraf natural language.
Namun, penggunaan structured output juga memperkenalkan masalah baru: schema alignment menjadi bagian dari system correctness.
Model tidak cukup hanya "menjawab dengan benar". Output juga harus memiliki field, tipe data, dan struktur yang sesuai dengan contract yang diharapkan tahap berikutnya.
Evidence-Grounded Prompting
Salah satu risiko utama penggunaan Generative AI dalam domain seperti fraud analysis adalah hallucination.
LLM memiliki kecenderungan mengisi celah informasi menggunakan pola yang pernah dipelajarinya.
Dalam ScamShield ID, behavior tersebut justru berbahaya.
Misalnya, jika bukti hanya menyebut:
terminal
"Silakan transfer biaya administrasi ke rekening berikut."
model tidak boleh mengarang:
- bank yang digunakan,
- nama pemilik rekening,
- jumlah transaksi,
- identitas pengirim,
- atau status legal organisasi.
Karena itu, prompt dirancang dengan prinsip:
terminal
Analyze the case only from the evidence available through the provided tools
and return exactly one structured response following the required output schema.
Tujuannya bukan menghilangkan hallucination secara absolut, melainkan mempersempit ruang model untuk menghasilkan klaim yang tidak memiliki basis pada evidence.
Case Stage Classification
Saya membagi kondisi pengguna menjadi tiga tahap utama:
| Case Stage | Interpretation |
|---|---|
| PRE_TRANSFER | Pengguna belum mengirim uang maupun informasi sensitif |
| POST_TRANSFER | Pengguna telah melakukan transfer atau kehilangan dana |
| POST_CREDENTIALS | Pengguna telah memberikan credential atau informasi sensitif |
Pemisahan ini penting karena rekomendasi yang diberikan sistem harus berubah berdasarkan kondisi pengguna.
Kasus sebelum transaksi membutuhkan pendekatan pencegahan.
Kasus setelah kehilangan uang membutuhkan langkah mitigasi dan dokumentasi.
Sementara kebocoran credential membutuhkan respons yang berbeda lagi karena risiko dapat meluas ke account takeover.
Incident Categorization
ScamShield juga mengklasifikasikan kasus ke beberapa kategori:
terminal
FAKE_RECRUITMENT
PHISHING
INVESTMENT
FAKE_SHOP
ACCOUNT_TAKEOVER
OTHERS
Klasifikasi ini sengaja dibuat terbatas.
Daripada membiarkan model membuat nama kategori baru setiap saat, enum memberikan ruang keputusan yang lebih terkendali dan membuat data hasil analisis lebih mudah digunakan untuk agregasi atau evaluasi di masa depan.
Entity Extraction
Selain klasifikasi risiko, workflow juga mengekstrak informasi faktual dari bukti.
Contohnya:
terminal
{
"claimed_organization_names": ["PT Nusantara Digital"],
"person_names": ["Budi Santoso"],
"platforms": ["WhatsApp"],
"bank_names": ["Bank Nusantara"],
"bank_accounts": ["123456789012"],
"account_holder_names": ["Budi Santoso"],
"transaction_amounts": ["Rp750.000"],
"key_timestamps": ["02/08/2026 09:10", "02/08/2026 09:16"]
}
Contoh tersebut menggunakan skenario sintetis, bukan kasus nyata.
Entity extraction membuat informasi yang sebelumnya tersebar dalam percakapan panjang berubah menjadi data terstruktur yang dapat digunakan kembali.
Structured Output: Hasil analisis diubah menjadi representasi
terstruktur sebelum masuk ke tahap report generation.
Example Case: Suspicious Recruitment Message
Untuk menguji workflow, salah satu skenario sintetis yang digunakan adalah dugaan fake recruitment.
Skenario tersebut menggambarkan seseorang yang menerima pesan mengenai lowongan pekerjaan dari pihak yang mengaku mewakili sebuah perusahaan.
Pengguna kemudian diminta membayar biaya sebesar Rp750.000 ke rekening tertentu dalam tenggat waktu singkat.
Dalam contoh tersebut:
- pengguna belum melakukan transfer,
- tidak ada credential sensitif yang telah diberikan,
- terdapat permintaan pembayaran,
- terdapat tekanan waktu,
- dan pembayaran diarahkan ke rekening atas nama individu.
Hasil triage yang diharapkan secara konseptual:
terminal
{
"case_stage": "PRE_TRANSFER",
"incident_category": "FAKE_RECRUITMENT",
"risk_level": "HIGH",
"overall_confidence": 0.95
}
Yang menjadi fokus eksperimen bukan hanya apakah LLM dapat mengatakan bahwa pesan terlihat mencurigakan.
Hal yang lebih penting adalah apakah model dapat:
- mengekstrak detail penting dengan benar,
- tidak mengarang detail yang tidak tersedia,
- memilih kategori dari enum yang tersedia,
- membedakan kondisi sebelum dan setelah korban mengalami kerugian,
- serta mengembalikan seluruh informasi tersebut dalam schema yang konsisten.
From Machine Output to Human-Readable Report
Structured JSON sangat berguna bagi sistem, tetapi tidak ideal sebagai antarmuka akhir untuk pengguna non-teknis.
Karena itu, ScamShield memiliki tahap terpisah yang mengubah hasil analisis menjadi report yang lebih natural.
Final Report: Structured risk assessment diformat ulang menjadi laporan
yang lebih mudah dipahami pengguna.
Pemisahan antara analysis representation dan presentation representation membuat workflow lebih modular.
Structured object tetap menjadi source of truth, sedangkan formatter hanya bertanggung jawab mengubah representasinya menjadi laporan.
Dengan demikian, format frontend dapat diubah tanpa harus mengubah proses reasoning utama.
Engineering Challenges & Debugging
Membangun workflow berbasis LLM berbeda dari membuat aplikasi deterministik biasa.
Beberapa masalah utama justru muncul pada kontrak antar-komponen.
1. Structured Output Was Not Automatically Reliable
Pada eksperimen awal, workflow pernah menghasilkan kondisi:
terminal
No structured output returned
Model dapat memahami instruksi secara semantik, tetapi tahap berikutnya tetap gagal apabila respons tidak dikembalikan dalam struktur yang tepat.
Hal ini mendorong saya untuk memperlakukan output schema bukan sebagai instruksi tambahan, melainkan sebagai bagian inti dari desain sistem.
2. Explicit Output Schema Was Required
Salah satu debugging step menunjukkan bahwa model membutuhkan output schema yang didefinisikan dengan lebih eksplisit.
Tanpa contract yang jelas, downstream component tidak dapat menjamin keberadaan field yang dibutuhkan.
Hal ini mengubah cara saya memandang prompt engineering:
Prompt yang baik tidak hanya menjelaskan apa yang harus dipikirkan model, tetapi juga mendefinisikan interface yang harus dipenuhi model.
3. Schema Mismatch Broke Report Rendering
Pada salah satu iterasi, structured analysis sebenarnya sudah berhasil dihasilkan tetapi laporan akhir tetap kosong.
Masalahnya bukan pada kemampuan LLM memahami kasus.
Masalah berada pada ketidaksesuaian schema antara output dari tahap analisis dan input yang diasumsikan oleh tahap report generation.
Kasus ini menunjukkan bahwa dalam sistem AI berbasis workflow, traditional software engineering concern seperti interface contract dan data shape tetap sama pentingnya dengan kualitas prompt.
4. Sink Compatibility
Beberapa pendekatan awal menggunakan JSON/Table-oriented sink yang tidak menghasilkan representasi akhir sesuai kebutuhan.
Workflow kemudian menggunakan tahap formatting berbasis Template untuk menghasilkan laporan yang lebih stabil dan mudah dikonsumsi pengguna.
5. Model/API Quota Is an Operational Dependency
Eksperimen juga mengalami API rate/quota limitation.
Hal ini menjadi pengingat bahwa AI application tidak hanya bergantung pada akurasi model.
Reliability sistem juga dipengaruhi:
- API availability,
- quota,
- latency,
- retry strategy,
- dan dependency terhadap external model provider.
Untuk prototype ini, fokus implementasi masih berada pada workflow correctness. Production-grade retry, fallback model, persistent logging, dan observability menjadi area pengembangan berikutnya.
What I Learned About AI Agent Engineering
1. Prompt Engineering Is Only One Layer
Sebelum membangun workflow ini, mudah untuk menganggap kualitas aplikasi LLM terutama bergantung pada prompt.
Eksperimen ScamShield menunjukkan bahwa kualitas sistem juga sangat dipengaruhi oleh:
terminal
Prompt
+
Schema
+
Workflow
+
State / Data Flow
+
Validation
+
Presentation
Prompt yang bagus tetap dapat menghasilkan aplikasi yang rapuh jika contract antar-node tidak konsisten.
2. Structured Output Turns an LLM Into a System Component
Natural language sangat fleksibel untuk manusia tetapi buruk sebagai interface antar-program.
Dengan schema-constrained outputs, LLM dapat ditempatkan di tengah sebuah software pipeline dengan kontrak yang jauh lebih eksplisit.
3. Grounding Is More Important Than Confidence
Model dapat terdengar sangat yakin meskipun informasi yang dimilikinya tidak lengkap.
Karena itu, objective utama tidak seharusnya:
"Bagaimana membuat model terdengar yakin?"
melainkan:
"Apakah setiap kesimpulan memiliki dukungan yang tersedia pada evidence?"
4. AI Safety Can Be an Engineering Constraint
Dalam domain fraud analysis, hallucination bukan sekadar kesalahan UX.
Klaim yang tidak didukung evidence dapat menyesatkan pengguna atau menuduh pihak tertentu tanpa dasar.
Karena itu, limitation dan safety note menjadi bagian dari struktur output, bukan sekadar disclaimer tambahan pada UI.
5. Agentic Workflow Does Not Mean Maximum Autonomy
ScamShield sengaja menggunakan workflow yang cukup terstruktur.
Setiap komponen diberikan tanggung jawab spesifik daripada membiarkan satu agent mengambil seluruh keputusan secara bebas.
Pengalaman ini memperkuat prinsip bahwa autonomy sebaiknya ditambahkan hanya ketika memberikan manfaat yang nyata.
Current Limitations
ScamShield ID masih merupakan prototype dan memiliki beberapa keterbatasan penting:
-
No Independent Fact Verification Sistem belum melakukan validasi independen terhadap rekening, domain, organisasi, nomor telepon, atau identitas yang disebutkan pada bukti.
-
LLM Output Is Non-Deterministic Walaupun structured output mempersempit variasi respons, model Generative AI tetap dapat menghasilkan perbedaan antar-eksekusi.
-
No Production-Grade Evaluation Dataset Yet Prototype belum memiliki benchmark dataset berlabel yang cukup besar untuk mengukur precision, recall, false-positive rate, ataupun calibration secara representatif.
-
Limited Multimodal Evidence Pipeline Dukungan terhadap berbagai bentuk bukti seperti screenshot, dokumen, OCR, metadata gambar, atau lampiran lainnya masih dapat dikembangkan lebih lanjut.
-
No Persistent Case Management Workflow saat ini berfokus pada triage dan belum menjadi sistem incident-management lengkap dengan authentication, case history, audit trail, dan investigator dashboard.
Future Development
Beberapa pengembangan yang ingin saya eksplorasi selanjutnya:
1. Multimodal Evidence Processing
Memperluas input menjadi:
terminal
Text
Screenshots
Images
PDF/Documents
URLs
Transaction Receipts
sehingga satu kasus dapat dianalisis dari beberapa evidence source sekaligus.
2. Retrieval-Augmented Verification
Mengintegrasikan retrieval terhadap sumber terpercaya untuk membantu melakukan cross-check informasi seperti:
- domain,
- organisasi,
- nomor rekening yang dilaporkan,
- pola phishing,
- atau informasi fraud intelligence lainnya.
Output retrieval tetap harus dipisahkan secara jelas antara:
user-provided evidence dan externally retrieved evidence.
3. LLM Evaluation Framework
Membangun dataset evaluasi khusus untuk mengukur:
- incident classification accuracy,
- case-stage classification,
- entity extraction precision/recall,
- schema compliance,
- hallucination rate,
- recommendation consistency,
- dan confidence calibration.
4. Human-in-the-Loop Review
Untuk kasus ambigu atau high-impact, sistem idealnya tidak membuat keputusan final secara otomatis.
Kasus tersebut dapat diarahkan ke reviewer manusia dengan seluruh evidence dan structured analysis yang telah dipersiapkan AI.
5. Case Management Dashboard
Structured output ScamShield memungkinkan pengembangan lebih lanjut menjadi dashboard yang menampilkan:
terminal
Case Queue
Risk Level
Incident Type
Extracted Entities
Evidence
Recommended Actions
Review Status
Audit History
Dengan pendekatan ini, prototype dapat berkembang dari single-user AI assistant menjadi fraud triage platform yang lebih lengkap.
Strategic Engineering Takeaways
-
LLM Output Harus Diperlakukan Sebagai Untrusted Data Kemampuan model menghasilkan bahasa yang meyakinkan tidak menghilangkan kebutuhan terhadap schema validation, grounding, dan downstream checking.
-
AI Agent Workflow Tetap Merupakan Software System Bugs yang saya temukan tidak hanya berasal dari prompt, tetapi juga dari schema mismatch, data flow, rendering, dan external API dependency.
-
Structured Output adalah Jembatan antara Generative AI dan Traditional Software Engineering Output terstruktur membuat hasil reasoning LLM dapat digunakan secara deterministik oleh komponen aplikasi lainnya.
-
Evidence Grounding Lebih Penting daripada Jawaban yang Terdengar Pintar Dalam domain sensitif seperti fraud analysis, sistem yang mengakui informasi tidak tersedia lebih berguna daripada model yang mengisi kekosongan dengan asumsi.
-
Prototype AI yang Baik Bukan Model yang Tidak Pernah Gagal Nilai eksperimen justru muncul ketika failure mode dapat ditemukan, dijelaskan, dan diterjemahkan menjadi perbaikan arsitektur berikutnya.