AI & Automation
AI Governance & Compliance
Ship AI your risk function will actually approve
- DPDP Act 2023 and GDPR by design
- Audit trails, not after-the-fact assertions
- Model risk documentation your auditors accept
- 4-6 weeks
- Governance package delivered
- 100%
- AI decisions traceable to inputs
Alongside a build, not as a separate project
Request-level audit logging
Why this stops projects
The technical work finishes and then the system sits in staging for four months while risk, legal and security ask questions nobody prepared for. Where does the data go. What happens when it is wrong. Who approved this. Can we delete one customer's data from the vector index.
Those are all reasonable questions with cheap answers if you designed for them, and expensive answers if you did not.
The DPDP constraints that matter architecturally
Purpose limitation. Data collected to deliver a service generally cannot be repurposed to train a model without fresh consent. This shapes what your AI is allowed to learn from.
Erasure that reaches everywhere. A data principal can require deletion. If their information sits inside embeddings in a vector store with no lineage back to the source record, you cannot honour that. Chunk-level lineage is the fix, and it has to go in early.
Consent that is specific and revocable. Bundled, pre-ticked or vague consent is not consent. That changes form design, not just policy wording.
Significant Data Fiduciary duties. Above certain thresholds you owe additional obligations including a Data Protection Officer and independent audits. Worth knowing which side of the line you are on before you scale.
Human oversight, designed rather than declared
"A human reviews the output" is not a control unless you can say who, with what authority, seeing what context, within what time, and what happens when they disagree with the model. We specify that concretely and build the queue, the escalation path and the audit record that proves it happened.
How it runs
What the engagement looks like
Phases, not a proposal. Each one has an output you can see.
- 1
Inventory and classify
Week 1Every AI use case listed and risk-rated. Most organisations discover two or three they did not know about, usually in a spreadsheet.
- 2
Map the data
Weeks 1-2What personal data is involved, on what legal basis, where it goes, how long it stays and which sub-processors touch it. The unglamorous work that determines what you are allowed to build.
- 3
Design the controls
Weeks 2-4Human oversight where the risk requires it, refusal behaviour, PII handling, audit logging and retention. Designed into the system rather than described in a policy nobody reads.
- 4
Document to audit standard
Weeks 4-5Model risk documentation, DPIA and the use-case register, written so an auditor or a client's security team can follow it without a workshop.
- 5
Rehearse the failure
Week 6A tabletop exercise on an AI-specific incident — a wrong high-stakes output, a data leak through a prompt, a provider breach. Whether the runbook survives contact is better learned now.
Proof
Where we have done this
Mobile network operator
Recovering more from overdue accounts by contacting fewer of them
An operator chased every overdue account with the same reminder cadence and the same escalation, spending heavily on balances that would never be recovered, offering settlements to customers who would have paid in full, and pushing customers in genuine difficulty through a sequence designed for someone else.
- 23%
- Recovery uplift on aged balances
- 31%
- Fewer contacts per rupee recovered
- 100%
- Recommendations with a recorded reason
Multi-specialty hospital group
Cutting pre-authorisation turnaround from 9 days to 36 hours
A four-hospital group was carrying a nine-day median on insurance pre-authorisation, with two coders and three billing staff assembling each request by hand from records spread across the HIS, the LIS and a shared drive.
- 9 days → 36 hrs
- Median pre-authorisation turnaround
- 83%
- Requests assembled without manual entry
- 2.7x
- Coder throughput on assisted specialties
FAQ
Questions we get asked
Does the DPDP Act actually change how we build AI?
Yes, in concrete ways. Consent must be specific and revocable, purpose limitation constrains reusing data to train or fine-tune, and data-principal rights mean you need to locate and delete an individual's data — including anything embedded in a vector store. That last one is a real architectural constraint and it is much cheaper to design for than to retrofit.
Do we need to comply with the EU AI Act?
If you offer services into the EU, likely yes, and the obligations depend on your risk classification. Most business automation lands in limited or minimal risk with transparency obligations. We classify your use cases and tell you what actually applies rather than treating everything as high risk.
Can this run alongside a build, or does it have to come first?
Alongside, and that is the point. Governance produced after the system exists tends to describe what got built rather than shape it. Running in parallel means controls like audit logging and PII handling are designed in while they are still cheap.
Will you help with client security questionnaires?
Yes. Much of what enterprise buyers ask for — data flows, sub-processors, retention, oversight design — is exactly what this engagement produces. Teams routinely reuse it to shorten procurement.
Talk to someone who does ai governance
Thirty minutes with an engineer who has delivered this, not an account manager. You will get a straight answer on feasibility, rough cost and where it would fail.
Or email [email protected] · we reply within 1 business day