The NIST AI Risk Management Framework (AI RMF 1.0): A Practical Adoption Guide for Indian Enterprises
The NIST AI Risk Management Framework is not law in India, and adopting it satisfies no Indian statutory obligation directly. That is the wrong reason to skip it.
Global customers are writing it into contracts. Auditors are using it as the reference for what reasonable AI governance looks like. Standards bodies are converging on the same structure. And critically, the work you do to adopt it is largely the same work the DPDP Act, the EU AI Act, and sectoral regulators will require of you anyway - which means early adoption buys you a head start rather than a parallel programme.
This is how to adopt it without turning it into an eighteen-month documentation exercise.
What the Framework Actually Is
AI RMF 1.0, published by NIST in January 2023, is voluntary, sector-agnostic and non-prescriptive. It does not tell you what controls to implement. It organises the risk management problem into four functions, each with categories and subcategories, and leaves the implementation to you.
That flexibility is both its strength and the reason adoption programmes drift. Without a scoping decision, the framework will expand to fill any amount of available effort.
The four functions:
| Function | The question it answers | Who typically owns it |
|---|---|---|
| GOVERN | Do we have the accountability, policy, culture and processes to manage AI risk at all? | CISO, DPO, executive committee, board |
| MAP | What is this system, in what context, and what could go wrong? | Product owner, business owner, architect |
| MEASURE | How do we quantify and track the risks we identified? | Data science, quality engineering, security testing |
| MANAGE | What do we do about them, and how do we respond when they materialise? | Engineering, operations, incident response |
GOVERN is cross-cutting - it applies continuously and enables the other three. MAP, MEASURE and MANAGE run per system, iteratively, across the lifecycle.
NIST also publishes the Generative AI Profile (NIST AI 600-1), which applies the framework specifically to generative systems. If your AI estate is mostly large language models rather than traditional predictive models, read that alongside the core framework - it addresses the failure modes you will actually encounter.
The Four Functions, With Indian Enterprise Examples
GOVERN in practice means: a published AI policy approved at executive level; a named accountable owner for AI risk; defined risk tolerance stating which uses are prohibited outright; an inventory of AI systems; a workforce competency plan; and third-party AI risk requirements integrated into procurement.
Example: An NBFC establishes that AI may not make a final credit decline decision without human review, documents this as a risk tolerance statement, and routes it through the board risk committee. That single statement drives system design, vendor requirements and audit scope for every lending model thereafter.
MAP means establishing context before building: intended purpose and setting, who is affected, what "correct" means, the assumptions and limitations, and what happens when the system is wrong.
Example: An insurer mapping a claims triage model documents that it operates on motor claims below a value threshold, that affected parties include claimants who may be financially vulnerable, that a false negative delays a legitimate payout, and that the model was validated on data predating a regulatory change in claims handling. The last point is a limitation that only surfaces during a structured MAP exercise, and it is exactly the sort of thing that causes silent failure later.
MEASURE means selecting metrics and actually running them: accuracy against a representative test set, performance disaggregated across relevant groups, robustness under adversarial input, drift monitoring, and human oversight effectiveness.
Example: An IT services firm running a CV screening model measures not only overall accuracy but selection rates disaggregated by gender and by whether the candidate's education was at a metro or non-metro institution - because that proxy is where geographic bias enters Indian hiring data, and aggregate accuracy conceals it entirely.
MANAGE means prioritising by risk, treating, monitoring in production, and responding to incidents.
Example: A payments company defines that any model whose drift metric crosses a threshold reverts automatically to a rules-based fallback, alerts the on-call team, and cannot be restored to production without a documented revalidation.
Mapping to What Already Binds You
This is the section that determines whether adoption is efficient or wasteful. Almost every AI RMF outcome maps to something you already do or already must do.
| AI RMF area | ISO 27001 Annex A | DPDP Act and Rules | Sectoral |
|---|---|---|---|
| GOVERN - policy and accountability | A.5.1 policies; A.5.2 roles and responsibilities | Section 8 accountability; Section 10 DPO for SDFs | RBI IT governance - board-level technology risk accountability |
| GOVERN - inventory | A.5.9 inventory of associated assets | Basis for the RoPA | Regulator expectations on system inventories |
| GOVERN - third-party | A.5.19 to A.5.22 supplier relationships | Processor obligations; sub-processor control | Outsourcing and IT services directions |
| MAP - context and purpose | A.5.31 legal and contractual requirements | Sections 5 and 6 purpose specification; DPIA under Section 10 | Product approval and suitability requirements |
| MEASURE - testing | A.8.29 security testing in development | Algorithmic due diligence for SDFs | Model validation expectations |
| MEASURE - monitoring | A.8.16 monitoring activities | Reasonable security safeguards under Section 8 | Continuous control monitoring |
| MANAGE - incident response | A.5.24 to A.5.28 incident management | Section 8(6) breach intimation; 72-hour Board notification | Sectoral incident reporting timelines |
| MANAGE - decommission | A.8.10 information deletion | Erasure obligations under Section 8 | Record retention requirements |
Add ISO/IEC 42001:2023 to this picture. It specifies a certifiable AI management system built on the same Annex SL structure as ISO 27001, which means it integrates with your existing ISMS rather than sitting beside it. The practical division of labour: AI RMF gives you the risk management method, ISO/IEC 42001 gives you the certifiable management system, and your statutory obligations give you the mandatory floor.
The mapping exercise is not academic. Done properly, it means one control implementation, tested once, evidences an AI RMF subcategory, an Annex A control, a DPDPA obligation and a sectoral requirement simultaneously.
Scoping: Where to Start
The single most common adoption failure is attempting the whole estate at once. Scope in three waves.
Wave 1 - Customer-facing AI that affects outcomes for people. Credit decisions, claims handling, fraud scoring, eligibility determination, CV screening. This is where regulatory attention concentrates, where the EU AI Act's Annex III categories sit, and where the reputational consequence of failure is highest. It is usually a small number of systems, which makes it achievable.
Wave 2 - Internal decision-support with material business consequence. Demand forecasting, pricing recommendations, resource allocation, security triage. Lower regulatory salience, real operational risk.
Wave 3 - Productivity and content generation. Drafting assistants, summarisation, code completion. High volume, low individual consequence. Manage through policy, catalogue and gateway controls rather than per-system assessment.
Resist the temptation to begin with Wave 3 because it is where the volume and visible enthusiasm are. Beginning there produces a large amount of process applied to low-consequence systems, and exhausts organisational patience before you reach the systems that matter.
Who Owns What
Ownership ambiguity stalls more adoptions than technical difficulty. A workable allocation for a typical Indian enterprise:
| Function | Accountable | Responsible | Consulted |
|---|---|---|---|
| GOVERN | CISO or Chief Risk Officer | GRC team | Legal, DPO, business heads, board risk committee |
| MAP | Business owner of the system | Product manager and architect | DPO, legal, security architecture |
| MEASURE | Head of Data Science or Engineering | ML engineers, QE, security testing | GRC, internal audit |
| MANAGE | Head of Engineering or Operations | SRE, incident response | CISO, DPO, communications |
Two structural notes. First, MAP must be owned by the business, not by security. A security-owned MAP produces a document about a system the security team does not understand, and business owners do not recognise their own system in it. Second, MEASURE and MANAGE ownership must be separate from the team building the model, or measurement becomes self-assessment.
What to Automate and What Must Stay Human
| Automatable | Human judgement required |
|---|---|
| Inventory discovery and register maintenance | Deciding whether a use case is acceptable at all |
| Evidence collection for GOVERN controls | Setting risk tolerance and prohibited uses |
| Drift and performance monitoring | Interpreting whether measured disparity is unlawful discrimination |
| Disaggregated metric computation | Choosing which groups to disaggregate across |
| Control-to-framework mapping proposals | Confirming a mapping is genuinely equivalent |
| Alerting on threshold breach and stale assessments | Accepting residual risk |
| Documentation assembly for audit | Explaining a decision to a regulator |
The second column is short but decisive. Note especially that choosing which groups to disaggregate across is a human decision with legal and ethical content - and it is the decision that determines whether your bias testing finds anything at all.
A 90-Day Pilot
Days 1-15: Scope and govern. Pick three to five Wave 1 systems. Name the accountable executive. Draft the AI policy and the risk tolerance statement, including at least two explicitly prohibited uses. Get executive approval on the scope before building anything.
Days 16-35: Inventory and MAP. Build the register covering the pilot systems. Run a structured MAP workshop per system with the business owner present. Document purpose, affected parties, assumptions, limitations and failure modes.
Days 36-60: MEASURE. Define metrics per system. Establish baselines. Run the first disaggregated performance assessment. Expect this phase to surface that the data needed for disaggregation was never collected - discovering that in a pilot is a good outcome, not a failure.
Days 61-80: MANAGE. Define thresholds and fallback behaviour. Wire monitoring and alerting. Write the AI incident response addendum. Run one tabletop.
Days 81-90: Map, measure the programme, and decide. Complete the cross-framework mapping for the controls you implemented. Quantify effort per system. Present to the executive sponsor with a recommendation on Wave 2 scope and a realistic per-system cost.
The deliverable at day 90 is not a completed framework. It is a defensible per-system cost estimate and a demonstrated capability, which is what you need to secure funding for the rest.
Conclusion
AI RMF's value to an Indian enterprise is not compliance with an American framework. It is that the framework supplies a coherent structure for work you are going to be required to do anyway, under DPDPA algorithmic due diligence, under the EU AI Act if you serve European customers, and under sectoral expectations that are converging on the same substance.
Adopting it early is cheap because you can sequence it. Adopting it under contractual or regulatory pressure is expensive because you cannot.
Actionable recommendations:
- Scope to customer-facing, outcome-affecting systems first. Wave 1 is small, high-salience, and achievable. Starting with productivity tooling burns credibility on low-consequence systems.
- Do the cross-framework mapping as you go, not afterwards. Mapping retrospectively produces mappings designed to pass rather than mappings that reflect what you built.
- Give MAP to the business owner. A security-authored MAP describes a system nobody recognises and misses the assumptions that matter.
- Separate MEASURE from the build team. Self-assessed model performance is not assurance, and auditors treat it accordingly.
- Expect the pilot to reveal missing data. Disaggregated performance assessment usually cannot run on day one because the attributes were never collected. Better found in a 90-day pilot than in an audit.
Import the full NIST AI RMF control library. Auto-map it to your existing ISO 27001, DPDPA and sectoral controls, so one implementation evidences all four - with gaps and stale assessments surfaced continuously. See how Dedups.ai accelerates AI RMF adoption.