Making AI Fraud Detection Explainable with Amazon Bedrock and AWS Serverless Architecture
For our Bharat Builds 2026 project, we built a system that translates high AI anomaly scores into actionable summaries for environmental inspectors. Discover how we integrated Amazon Bedrock, AWS Lambda, S3, and SAM to generate clear, evidence-backed inspection case files.
The Explainability Challenge
Our Phantom Plastic module analyzes Extended Producer Responsibility (EPR) recycling records.
It combines physics-based rules, Isolation Forest anomaly detection, and graph-based learning.
Consider a hypothetical recycler that reports processing large amounts of plastic waste.
The system might identify several inconsistencies:
- Electricity consumption appears insufficient for the reported recycling volume.
- Material transactions show unusual patterns.
- Certificate prices appear inconsistent with estimated processing costs.
- The recycler has suspicious network relationships.
Each signal is useful, but presenting these findings as raw feature values can make an inspector's job harder.
We wanted to convert technical evidence into concise, actionable summaries.
Why Amazon Bedrock?
Amazon Bedrock offers managed access to foundation models through AWS APIs.
Our goal was to use a language model for explanation, rather than giving it responsibility for deciding whether a recycler was fraudulent.
This distinction is important.
The anomaly detection system calculates the risk indicators. The language model's job is to communicate the existing findings.
We implemented this approach in:
phantom/aws/narrative.py
The module supports two summary-generation paths:
- A deterministic summary generated directly from the structured case file.
- A model-generated summary using Amazon Bedrock when the required configuration and service access are available.
This gives the application a fallback when Bedrock is not configured or a request fails.
Designing the Summary Generation Workflow
The intended architecture looks like this:
Anomaly Detection Pipeline
|
Structured Case File
|
Amazon S3
|
API Gateway Request
|
AWS Lambda
|
Retrieve Case Evidence
|
Summary Generation
/ \
v v
Amazon Bedrock Template
\ /
v v
Inspector Summary
The case file is stored as structured data, which can then be retrieved through the API.
The Lambda handler uses the case data to request a summary.
When configured, the summarization module calls the Amazon Bedrock Runtime API using Boto3.
The implementation uses the Bedrock Converse API, which provides a standardized interface for supported conversational models.
Controlling What the AI Can Say
One of our most important engineering choices was restricting summary generation to the supplied evidence.
Our system prompt instructs the model to write a short briefing for a pollution control board inspector.
It emphasizes four principles:
1. Use only the provided evidence.
The model should not introduce new statistics, transactions, or allegations.
2. Avoid declaring guilt.
An anomaly is a reason for investigation, not proof of misconduct.
3. Prioritize actionable observations.
A useful summary explains what the inspector should verify first.
4. Keep the output concise.
The prompt requests a short, plain-language briefing rather than a lengthy technical report.
The Bedrock request is configured with a relatively low temperature of 0.2, aiming for more consistent output.
These controls reduce the risk of unsupported statements, although they do not guarantee that a generated summary will always be accurate.
For a production compliance workflow, human review and additional output validation would still be necessary.
Integrating Bedrock with Our Serverless API
Our AWS SAM template defines a Lambda function for retrieving cases.
It also includes an environment variable for selecting the Bedrock model:
PHANTOM_BEDROCK_MODEL: !Ref ModelId
The model identifier can be supplied during deployment.
The corresponding Python code uses the AWS SDK to call Bedrock's Converse API.
Conceptually, the request follows this pattern:
response = bedrock.converse(
modelId=MODEL_ID,
system=[{"text": SYSTEM_PROMPT}],
messages=[
{
"role": "user",
"content": [
{"text": case_json}
]
}
],
inferenceConfig={
"maxTokens": 300,
"temperature": 0.2
}
)
The actual implementation also selects the evidence fields to include and handles errors.
Importantly, the application does not require Bedrock to produce every case summary.
If the model is unavailable, the code falls back to a deterministic template constructed from the case data.
Why the Fallback Matters
Generative AI services introduce operational dependencies.
A model might be unavailable in a particular AWS Region. Access permissions might not be configured. Requests may also fail or be throttled.
For an inspection application, we don't want the absence of a language model to make the underlying evidence inaccessible.
Our fallback preserves the core functionality: the inspector can still receive a readable summary of the suspicious indicators.
This is an architectural lesson we found especially valuable.
Generative AI should enhance an evidence-driven system, not become its single point of failure.
Current Implementation and Next Steps
The Bedrock integration code and SAM infrastructure are part of the public repository.
The deterministic summary generation has been tested offline. The repository documentation does not yet confirm a successful live Bedrock invocation or end-to-end SAM deployment.
Our next step is to validate the model integration using an enabled Bedrock model in a supported AWS Region.
We would also add access controls, operational monitoring, audit logs, and systematic evaluation of summary faithfulness against the original evidence.
Final Thoughts
Working on this feature helped us understand an important principle in applied AI.
Detecting a suspicious pattern and explaining that pattern are two different problems.
Machine learning helps us prioritize what deserves attention.
Generative AI can help communicate why it deserves attention.
And AWS provides managed building blocks for bringing these capabilities together.
Our longer-term vision is an auditing system where every high-risk finding is accompanied by traceable evidence and a clear starting point for human investigation.
Because the goal of responsible AI is not simply to generate conclusions.
It is to help people make better-informed decisions.
Relevant Implementation: phantom/aws/narrative.py, lambda_handler.py, template.yaml
Built for: Bharat Builds 2026 by WeMakeDevs
#AWS #AmazonBedrock #GenerativeAI #AWSLambda #Serverless #ExplainableAI #Sustainability #BharatBuilds #WeMakeDevs
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article