Your staff get the best AI.
Your customers’ data never leaves the building.
BizWa Shield sits between your employees and the AI models they want to use. Every PAN, Aadhaar, account number, name and address is replaced with a placeholder before the prompt leaves your network — and restored in the reply, on your side. Every request, allowed or refused, lands on an append-only ledger.
That is gateway mode. If your team is still on personal Claude subscriptions, Shield starts earlier — reading what is already on the machine, with no API keys and nothing to migrate.
Your staff are already using AI. You just can’t see it.
A relationship manager drafting an EMI reminder pastes the customer’s name, account number and PAN into a chat window because it saves twenty minutes. It works. It also means customer data has left the bank, with no record that it happened and no way to tell a regulator what was shared.
Blocking the tools doesn’t stop this — it moves it to personal phones. The only durable answer is to give staff a path that is easier than the workaround and safe by construction.
Three options, and none of them is good
Ban it
Policy says no AI at work. People use it anyway — on personal accounts, on personal phones, outside anything you administer. You carry the exposure and get none of the visibility.
Expense it and hope
Everyone buys their own subscription and claims it back. Five invoices arrive each month, and not one of them tells you what the work cost or what it touched.
Build a gateway
The right long-term answer, and the expensive one to start. It wants API keys for everybody, a migration off the tools your people already like, and an engineer who is currently fully booked.
There is a fourth, and it is where we start. Claude Code already writes a full transcript on every developer’s machine — every turn, the model that served it and the token counts. Reading it needs no API keys, no migration and no change to how anybody works. That is governance before you have a gateway, and it is where most teams should begin.
Everyone else starts at the gateway. Shield can start at the laptop.
The two modes answer different questions and it matters which one you are buying. Reporting mode tells you what your AI work is costing, today, with nothing to install centrally. Gateway mode sits in the request path and can prove what happened. They are separate on purpose.
| Reporting mode | Gateway mode | |
|---|---|---|
| Who it is for | Teams on personal Claude Pro or Max | Teams with API keys |
| What it covers | Claude Code | Any tool that can point at a base URL |
| Needs API keys | No | Yes |
| Masking and policy enforcement | No | Yes |
| On the audit ledger | No, deliberately | Yes, hash-chained |
| Tells you what it cost | Yes | Yes |
| Tells you what actually happened | No | Yes |
| Where the number comes from | The developer’s own machine, self-reported | The gateway, in the request path |
Reporting mode is self-reported: the totals come from the developer’s own machine, and that is exactly as strong as it sounds. It is why those figures are never written to the ledger — one unverifiable row would cost every other row its meaning. The long version, and what each mode can prove to an auditor.
Everything below this point describes gateway mode.
Screens from the running product
Not a mock-up and not an illustration. This is what an administrator opens, with demonstration data in it. Pick a screen.
Requests, identifiers masked and anything withheld — read from the audit ledger itself rather than a separate counter, so this screen and the trail an auditor reads can never disagree. Tap the screen to open it full size.
Four steps, and one of them is the whole product
Your staff work normally
They type in the tool they already use, or in a chat window we provide. No new habits, no forms, no training day.
Identifiers are replaced before anything leaves
PAN, Aadhaar, bank account, IFSC, mobile, email, card, names and postal addresses are detected and swapped for placeholders — inside your network. Checksums do the deciding, so a number that merely looks like an Aadhaar isn’t treated as one.
The model answers the placeholders
Claude, GPT, Gemini, Sarvam or a model on your own hardware. It writes the letter without ever being told who the customer is.
The reply is restored on your side, and recorded
The real values go back into the answer on your premises, after the model has responded. The request is appended to a ledger that holds counts by kind and never the values themselves.
Four mechanisms a competitor’s slide can’t honestly copy
The ledger cannot be quietly edited
Two independent layers. The database itself refuses UPDATE, DELETE and TRUNCATE on the audit table — a database administrator typing the delete gets an error. And every row carries a SHA-256 hash of the row before it, so anyone who disables the first layer breaks the chain, and verification catches it. That is arithmetic, not our assurance: your auditor can re-do the maths offline from a CSV export.
Nothing is processed unrecorded
If the ledger cannot be written, the request is refused. There is no mode in which a prompt reaches a model without a record existing first.
Policy changes need a second pair of hands
Every edit to what a department may reach is staged. Nothing takes effect until someone publishes it, which increments a version and writes a changelog entry with the publisher’s name. Every ledger row names the policy version that judged it.
The audit trail is not a second copy of your data
The ledger records that three identifiers of a given kind were masked. It does not record what they were. A compliance record that quietly accumulates customer identifiers would be the worst possible outcome, so the design forbids it.
Written against Indian identifiers, Indian languages and Indian rules
Tamil, Hindi, Telugu — and the Tanglish in between
Your staff type romanised Indian languages on English keyboards, and they paste customer emails written in Tamil or Devanagari script. Shield masks names and addresses in both — “Ramesh Kumar ji”, “ராமேஷ் குமார் அவர்களின்”, “శ్రీ రమేష్ గారికి” — and reads an Aadhaar written in Devanagari digits as the same twelve digits a checksum would.
Written against DPDP and the RBI IT framework
Two policy packs ship with the product. DPDP-2023 blocks bulk customer-data requests, processing without consent, and cross-border transfers of personal data. RBI-IT blocks movement of KYC and customer lists, prompt-injection and instruction-override attempts, and core-banking credentials reaching a model. Both are mandatory: they can be extended from the console but not switched off. Masking of PAN and Aadhaar is locked on for the same reason.
Every department on a different leash
Treasury can be restricted to a model running on your own hardware while Retail Banking uses the cloud. Not by policy document — the other options are not on their screen. Daily per-user limits are counted from the ledger itself, so the cap and the audit trail can never disagree.
Your model, your hardware, when you’re ready
Shield speaks to cloud models and to models running on your own GPU through the same interface. Moving a department on-premises is a configuration change, not a project.
One setting in your existing tools
Shield speaks both the OpenAI and the Anthropic request formats. Tools your teams already use point at Shield by changing one thing: the address they call. Nothing else in them changes.
# Before client = OpenAI(base_url="https://api.openai.com/v1", api_key=VENDOR_KEY) # After client = OpenAI(base_url="https://shield.yourbank.internal/v1", api_key=SHIELD_TOKEN)
It runs on your infrastructure — a single service and a PostgreSQL database. Authentication is username and password to begin with, structured so that Active Directory or your SSO replaces it without touching anything else.
- ·AES-256-GCM for the placeholder vault, keys from your environment only
- ·SHA-256 hash chain over an append-only PostgreSQL table
- ·Aadhaar validated by Verhoeff checksum, cards by Luhn
- ·OpenAI and Anthropic request formats, streaming supported on both
- ·No telemetry, and no outbound calls except to the model providers you configure
Built for the people who have to answer for it
- Banks and NBFCs whose staff are already using AI tools unofficially
- Compliance and risk teams who need to answer “what did we share, and when”
- Bank IT vendors who want a governance layer under an AI feature they are already selling
- Any regulated business in India handling PAN, Aadhaar or account data
The questions procurement actually asks
Do we need API keys to start?
Not for reporting mode. It reads the Claude Code transcripts already sitting on your developers’ machines, so it works while everyone is still on a personal Pro or Max subscription — no keys, no migration, nothing for them to change. Gateway mode does need API keys, because a prompt can only be masked and recorded if it passes through us. Most teams start with reporting and move when compliance rather than cost makes the decision.
What stops your engineers reading our data?
The mapping from placeholder back to the real value is encrypted with a key that lives in your environment, held only in memory for the life of a single request, and destroyed when that request finishes. It is never written to the audit record. Shield runs on your infrastructure — we have no copy to read.
Could someone quietly edit the audit log?
Two layers, and the second one is mathematics. The database refuses to update or delete those rows. Every row also carries a SHA-256 hash of the row before it, so tampering that gets past the first layer still breaks the chain, and verification reports exactly which entry broke. Your auditor can repeat the check offline from an exported CSV.
Does this slow our people down?
Masking adds a few milliseconds. What a user waits for is the model’s own thinking time, exactly as they would without Shield in the path.
We already use ChatGPT and Copilot. Do we replace them?
No. Shield sits in front of whatever you use. Existing tools point at it by changing the address they call.
What about names and addresses, not just numbers?
Both are masked. Names are detected from context — honorifics, “S/o”, “Customer Name:”, salutations — and from a list of common Indian given names. Addresses key off unit markers, place words like Nagar and Salai, and PIN codes. To be precise, because it matters: this is rule-based detection, not a machine-learning model. It is deterministic, it behaves identically every run, and an auditor can read every rule. It will not catch every unusual name, and an administrator can switch either detector off if it over-reaches on your phrasing.
Who decides the rules?
You do, in the console. And no edit takes effect until someone explicitly publishes it — the person making a change and the moment it goes live are separate, deliberately.
What happens if the model is unavailable?
The request returns a clean error and is recorded. It is never retried automatically, and it never falls back to a different model unless that department’s policy names one.
The fastest way to understand Shield is to watch it withhold a request.
Give us twenty minutes and we will show you a prompt being blocked, the placeholder text that would have gone to the model, and the ledger entry that recorded it.
Or write to us and we’ll send a recorded run-through. For the customer-facing side of the same engine, see BizWa Retail.