Enterprise AI in Production

{Describe your session in 2 paragraphs}

Every major Indian bank now has an AI governance policy document. Most are useless in production.
I’ve spent the last several years operationalizing AI governance frameworks — RBI’s FREE AI guidelines, the EU AI Act (for global banking clients), ISO 42001, NIST AI RMF, and the DPDP Act — across production ML systems at some of India’s largest financial institutions. The gap between what these frameworks demand on paper and what engineering teams actually build is enormous.
This talk breaks down the specific engineering failures I’ve seen when banks try to make AI governance real:
What I’ll cover:

The model inventory problem. Most banks can’t answer “how many ML models are in production right now?” — not because they don’t care, but because there’s no reliable system of record. Shadow models, notebook-deployed scoring functions, and vendor black-box APIs all escape the governance net. I’ll show what an operational model registry looks like when governance is a first-class requirement, not a retrofit.
Audit trail architectures that actually survive an RBI inspection. RBI’s FREE AI framework demands explainability, fairness testing, and decision traceability. The typical response is a PDF report generated post-hoc. The production-grade response is a lineage pipeline that captures input data snapshots, feature transformations, model version, inference output, and the human override (if any) — queryable months after the decision was made. I’ll walk through the architecture: what we logged, where we stored it, how we made it queryable, and what broke.
Fairness testing in production, not in notebooks. Every bank runs fairness metrics during model development. Almost none monitor fairness drift in production. I’ll share a concrete implementation where caste and gender proxy variables in credit scoring were monitored post-deployment, including the operational decision of what happens when the fairness threshold is breached mid-quarter — do you kill the model, flag for manual review, or retrain? Each choice has different engineering and business consequences.
The organizational failure mode. The Chief Risk Officer owns the governance policy. The ML engineering team owns the models. Neither owns the pipeline that connects them. I’ll describe the architectural pattern that bridges this — a governance middleware layer that sits between model serving and downstream consumers — and the one design decision I would change today.

{Mention 1-2 takeaways from your session}

What the audience takes away:

A concrete reference architecture for AI governance in regulated financial services
Three specific failure modes they will encounter (with mitigation patterns)
Operational metrics: what to track, where governance adds latency, and the real cost of compliance-grade logging
The single biggest architectural mistake in AI governance (treating it as a reporting layer instead of an infrastructure layer)

This is not a talk about why governance matters. Everyone in the room already knows that. This is a talk about the engineering decisions that make governance survive contact with production.
{Which audiences is your session going to beneficial for?}

{Add your bio - who you are; where you work}

Ramanuj is an AI architecture and governance practitioner with 16+ years of enterprise experience. He has deployed production AI systems across India’s largest banks and insurance companies, operationalizing regulatory frameworks including RBI’s FREE AI guidelines, ISO 42001, and the DPDP Act. His career spans Oracle (Principal — AI Architecture & Strategy), AWS (where he led AWS’s AI initiatives in India’s FSI practice), EY, Cognizant, and HDFC Life. He teaches Business Analytics at TAPMI Bangalore and publishes “Signal at the Top,” a newsletter on AI strategy for business leaders.