What the DPDP audit trail looks like when agents make the decisions
India's DPDP Act treats an automated decision the same as a human one for the purposes of consent, grievance, and accountability. We walked a real BFSI auditor through a Blackbead trail last quarter. Here's the field they always ask for first — and the one you never thought to log.
The Digital Personal Data Protection Act has been in force long enough that the first wave of enforcement actions is now visible in the press. The pattern is consistent: regulators don't argue about the model. They ask for the trail. If the trail doesn't reconstruct the decision in detail, the fine is set against gross revenue and the conversation gets short.
If your agents are deciding anything that touches a data principal — eligibility, fraud, routing, scoring, even queue-priority — the trail you need to produce is non-trivial. This post documents what we actually generate, what the auditor asked for, and what we'd missed.
The fields the auditor asked for
In order, the first six questions:
- Who is the data principal whose data was processed?
- What consent record applies, and was it active at the moment of processing?
- What decision was made? What was the operative output?
- Who or what made the decision? If it was automated, name the model and version.
- What inputs were used? Specifically, what categories of personal data?
- Can the principal seek redress on this decision? Through what mechanism?
We could answer the first four immediately. We could answer the fifth after grepping logs. The sixth was the one that surprised us.
The schema we now log
Every agent invocation that touches data principal information now writes a row that looks like this:
{
"decision_id": "dpdp-2026-04-28-x9k2",
"principal_id": "",
"consent_ref": "consent:retail-onboarding-v3",
"consent_active_at": "2026-04-28T11:42:17Z",
"purpose": "fraud_screening",
"agent": "payment-fraud-agent",
"agent_version": "1.4.2",
"policy_version": "fraud-policy-2026-04",
"inputs": {
"data_categories": ["transaction_metadata", "device_fingerprint"],
"data_principal_fields": ["account_id", "ip_country"],
"external_signals": ["sanctions_screen:v2", "velocity:v1"]
},
"decision": {
"outcome": "hold",
"score": 0.81,
"tier": "high",
"explainability": ["geo_risk:+0.34", "first_beneficiary:+0.21", ...]
},
"redress": {
"grievance_url": "/grievance/file?ref=dpdp-2026-04-28-x9k2",
"human_review_sla": "PT4H"
},
"trail_hash": "sha256:1c9a..."
} Five things worth calling out.
Consent freshness
consent_active_at is the timestamp we resolved consent against, not the timestamp we processed at. If the consent was withdrawn at 11:42:18, the millisecond ordering matters. We learned this the hard way during a tabletop — auditors asked for the consent state at the exact moment of processing, not the most recent state.
Agent and policy version
The model is one version axis. The policy that wrapped the model — thresholds, allowlists, override rules — is the other. We've had cases where the model didn't change but the policy did, and the decision drifted. If you log only the model version, you can't reconstruct the trail six months later when a customer escalates.
Data categories, not raw inputs
Logging raw input would create a second data lake of regulated data. We log the categories the regulator cares about — transaction metadata, device fingerprint, location — and a reference to where the raw input lived at the moment of processing. The reference doesn't have to survive; the categorisation does.
Explainability, not just score
"The model said no" is not an answer. The explainability array lists the signals that moved the decision, with their contribution. This is what gets shown to the data principal during redress, and what the regulator reads to assess whether the decision was reasonable.
Redress hook
This is the field we'd missed. DPDP requires the data principal to have a route to challenge an automated decision. The trail has to point to that route. A URL, a queue, an SLA — anything resolvable. We now generate the redress link at decision time and persist it in the trail. The principal can click through; the SOC can audit which decisions never got challenged.
The redress hook. When we did our first DPDP tabletop, every other field was present in some form. The redress link wasn't — because nobody had thought of the decision as something a person would want to challenge. It is.
What this costs
Trail rows are around 2KB compressed. At BFSI scale that's significant — but not relative to the audit-readiness premium. Storage tiers cheap, and the read access pattern is sparse (a few rows pulled at a time during a grievance). We hold 7 years in cold storage and 90 days hot.
What we'd tell a CISO standing one up today
- Pick one agent that touches data-principal data. Stand up the trail for that agent end-to-end.
- Run a tabletop. Have someone outside the team try to reconstruct a real decision from cold storage. Whatever they can't reconstruct is what you're missing.
- Wire redress into the trail at decision time, not after the fact.
- Version the policy, not just the model.
The cost of getting this right while the agent count is small is roughly an order of magnitude lower than the cost of retrofitting it once you have forty in production. The Indian regulator's enforcement curve points in one direction. The trail is what keeps you on the right side of it.