Naavi.org

 

A new era in Certification of professionals in the area of Data Protection has dawned in India with the collaboration of FDPPI with MYRA School of Business.

For the first time in India, a leading professional body in Data Protection is joining hands with an AICTE-approved Business School to create a new model of professional education and certification.

 

The Foundation of Data Protection Professionals in India (FDPPI) and MYRA School of Business, Mysuru, are in the process of formalising a Memorandum of Understanding (MoU) under which professional certification programmes developed by FDPPI will be offered under the joint FDPPI–MYRA brand.

This partnership marks a significant milestone in the evolution of professional education in the field of Data Protection, Privacy, AI Governance and Data Auditing.

A Journey That Began in 2019

When FDPPI launched its professional certification programmes in 2019, the Indian Data Protection ecosystem was still in its infancy.

At that time, most certification programmes available in India revolved around the GDPR. Professionals aspiring to build a career in Privacy largely depended on international certifications or programmes that interpreted Indian requirements through a GDPR lens.

FDPPI took a different path.

It recognised that India required professionals who understood not merely international privacy principles but also the unique legal and technological landscape emerging under the Information Technology Act, 2000 and, subsequently, the Digital Personal Data Protection Act, 2023 (DPDPA).

Over the years, FDPPI developed an India-centric body of knowledge, continuously refining its curriculum to reflect evolving legislation, judicial interpretations, governance practices, and implementation experience.

Competition Has Increased—So Has the Need for Differentiation

As the importance of Data Protection has grown, several organisations have entered the certification space.

After FDPPI introduced its programmes, industry bodies and private training organisations launched their own certifications. Today, there are numerous programmes marketed under titles such as “Certified Data Protection Officer”, “Certified DPO”, “Privacy Professional”, and similar designations.

Healthy competition benefits the profession.

However, it has also created a situation where prospective students often find it difficult to distinguish between a short-duration training programme and a professionally governed certification backed by sustained academic and industry expertise.

Certification should not merely represent attendance at a training programme. It should signify competence, ethical commitment, professional accountability and continuing development.

That is precisely where the FDPPI–MYRA initiative seeks to create a meaningful distinction.

More Than a Training Programme

The proposed FDPPI–MYRA certification framework is not intended to be another entry in an already crowded catalogue of professional courses.

Instead, it represents the coming together of two complementary strengths.

FDPPI contributes:

• years of specialised expertise in Data Protection, AI Governance and Data Audit;
• India-specific frameworks such as DGPSI;
• professional certification standards;
• industry practitioners and subject matter experts; and
• an active community of Data Protection professionals.

MYRA School of Business contributes:

• academic rigour;
• structured learning methodology;
• institutional quality assurance;
• research orientation; and
• the credibility associated with an AICTE-approved management institution.

Together, the partnership bridges the traditional divide between academia and professional practice.

A New Category of Professional Credential

This collaboration creates something that has been largely absent in India—a certification that carries both professional legitimacy and academic association.

Rather than functioning merely as a training provider, FDPPI brings to the partnership years of experience as a professional standards organisation that has actively contributed to India’s Data Protection ecosystem through publications, conferences, research, governance frameworks and professional networking.

MYRA brings the discipline and credibility of higher education.

The result is a professional credential that combines knowledge, practical implementation capability, governance understanding and ethical responsibility.

Preparing Professionals for Tomorrow

The Data Protection professional of the future cannot be confined to understanding statutory compliance alone.

Modern organisations require professionals capable of navigating an increasingly interconnected landscape involving:

• Digital Personal Data Protection;
• AI Governance;
• Information Security;
• Cyber Risk;
• Data Auditing;
• Corporate Governance;
• Regulatory Compliance; and
• Responsible Innovation.

The FDPPI–MYRA collaboration is designed with this future in mind.

The programmes are expected to evolve continuously alongside developments in legislation, technology and industry practice.

Beyond Certification

Professional education does not end with passing an examination.

The objective is to build a community of competent professionals who continue to learn, share experiences and contribute to the growth of India’s Data Protection ecosystem.

The partnership therefore aims not only to offer certifications but also to encourage research, case study development, executive education, industry interaction and thought leadership in emerging domains such as AI Governance and Data Assurance.

Looking Ahead

The proposed MoU represents more than an institutional partnership.

It symbolises the maturation of the Data Protection profession in India.

Professional competence must increasingly be supported by academic rigour. Academic knowledge must equally be informed by practical implementation experience.

The FDPPI–MYRA collaboration seeks to combine both.

As India moves towards full implementation of the Digital Personal Data Protection Act and organisations prepare for an AI-driven digital economy, the need for professionals who possess not only technical knowledge but also governance capability, ethical sensitivity and business understanding will become increasingly important.

The FDPPI–MYRA initiative is intended to prepare such professionals.

The formal announcement of the partnership, along with details of the first jointly branded certification programmes, will be made shortly.

For FDPPI, this is another step in its continuing mission of building India’s own ecosystem of competent, ethical and globally respected Data Protection professionals.

The journey that began in 2019 is now entering its next chapter.

Naavi

We have discussed in these columns, more than once, that of all the Data Fiduciaries the Digital Personal Data Protection Act, 2023 has created, the hospital occupies a category of its own.

The reason is captured in a single line that I keep returning to: in a hospital, data is life. It follows, almost as a matter of logic, that a “data breach” in a hospital is not merely a compliance event — it is a patient-safety event.

Here, we set out the full case for that proposition, and the framework — DGPSI-Hospital — that I believe hospitals must build to honour it.

Let me begin not with the law, but with a case.

A tragic illustration: when a “data” event becomes a “life” event

Consider an incident reconstructed through forensic investigation. A patient record carried a note of a known allergy. At some point before a clinical incident, the record was edited. After the event, it was edited again. The exact nature of the edits could not be fully established. What the investigation could establish was chilling: the edits were made by an unknown person, using the stolen password of the IT Administrator, from an unrecognised IP address.

On the surface this is a textbook information-security failure — an identity theft, a compromised credential, an unauthorised access. The CIA triad of Confidentiality, Integrity and Availability has every vocabulary to describe it. But notice where the story actually lands. The compromised property was the integrity of an allergy record. And the consequence of a tampered allergy record is not a leaked file or a regulatory fine. The consequence is borne by a human being on a hospital bed.

This is the whole argument in miniature. An identity theft produced an information-security breach, which culminated in a patient-safety compromise. The bits were the medium; the patient was the casualty. Any framework that stops at “we have restored the data and reset the password” has missed the event that actually mattered.

Why a hospital breach is not a bank breach

We instinctively model “data breach response” on the financial sector, because that is where breach management matured. But the analogy breaks at the most important point — reversibility.

A bank breach is largely reversible. Restoring lost data, reversing a fraudulent transaction, or curing a consent gap can substantially undo the damage. Money is fungible; records can be rebuilt; the harm, however serious, is usually recoverable.

A hospital breach is different. The harm can be irreversible. No restored backup brings back a life. A delayed treatment, a wrong dosage administered on a corrupted record, a result that reached the wrong clinician at the wrong time — these cannot be rolled back to last night’s snapshot. And because the harm is of a different character, the response and the remedies must be of a different character too.

The triggers, importantly, are varied. A patient-impacting incident in a hospital can arise from a technology failure, a human error, an AI malfunction, a privacy violation, or a malicious attack. The cause is almost incidental. What unifies them is the question that must always be asked at the end: did this hurt a patient?

Same problem, two domains

Here is the conceptual bridge on which the entire DGPSI-Hospital approach rests:

An unexpected harmful event is to a hospital what a personal-data breach is to a data fiduciary.

Both are managed through the same disciplined loop — see it, report it, fix it, and stop it from recurring. Only the names and the rulebooks differ.

On the clinical side, a patient-safety event is, in the working definition under NABH’s Patient Safety & Quality (PSQ) framework, any occurrence in the process of care that is inconsistent with the desired patient outcome or with routine hospital operations.

On the data side, a personal-data breach is, under the DPDP Act 2023, any unauthorised or accidental compromise of the confidentiality, integrity or availability of personal data.

Read those two definitions side by side and the structural parallel is unmistakable. Two domains, two vocabularies — one shape of problem.

Two rulebooks, one architecture

The two domains are governed by two very different instruments, and a hospital is simultaneously subject to both.

	NABH — PSQ chapter	DPDP Act 2023 + Rules 2025
What it is	Patient Safety & Quality Improvement standard	India’s data-protection statute
Issued / enforced by	Quality Council of India; 6th Edition (2025)	Data Protection Board of India
Nature	Voluntary accreditation standard	Binding statutory obligation
Core duty	Run an incident system across every unit	Safeguard data and manage every breach
Goal / teeth	Continual, measurable quality improvement	Penalty up to ₹250 crore for safeguard failure

The point is not that one is “softer” than the other. The point is that they share an architecture — an incident system, an escalation path, an investigation, a remediation, a governance owner. A hospital that already runs a mature NABH patient-safety incident system is not starting from zero on DPDPA breach management. It is being asked to run a structurally identical loop on a second class of event.

Where DPDPA goes beyond NABH

That said, the convergence is not complete. NABH treats information largely as a governance and risk-management issue, which maps reasonably well to data-principal rights and PII security. But the DPDPA imposes a set of legal obligations that NABH’s 6th edition simply does not address. These are the gaps a hospital must consciously close.

DPDPA 2023 / Rules 2025 requirement	NABH 6th-ed. coverage	Action for the hospital
S.8(8)–(9) + S.13 — publish DPO/contact; grievance-redressal mechanism	PRE.7 handles clinical complaints, not data grievances	Designate a data-protection contact/DPO and a data-grievance channel with defined timelines
S.14 — right to nominate (exercise rights on death/incapacity)	Not addressed	Offer patients a nominee option for their personal-data rights
S.10 + Rule 12 — Significant Data Fiduciary duties: DPIA, audit, India-based DPO	Not addressed	Large hospital groups should assess SDF-designation risk and prepare DPIA/audit capability
S.8(2) — processor contracts	IMS assumes in-house control; vendor data terms unspecified	Bind every HIS/cloud/AMC vendor by a DPDPA-compliant data-processing contract
S.16 + Rule 14 — cross-border transfer limits	IMS.1.g references law generally; no transfer-location control	Map data residency; restrict transfers to the government-notified position

DGPSI-Hospital (The framework for DPDPA Compliance developed by Naavi for FDPPI) exists precisely to integrate the two regimes — privacy management, cyber resilience, AI-risk management and data-breach response — into a single framework, rather than leaving the hospital to reconcile a voluntary quality standard and a binding statute in two disconnected committees.

What counts as an “event”?

The two regimes also classify events differently, and the difference is instructive.

The hospital grades by severity. A sentinel event — death, severe or permanent harm — triggers an immediate investigation. An adverse event is one that reached the patient and caused harm. A near miss was caught before it reached the patient. Severity drives the response.

The data regime, by contrast, has one definition and no tiers. A personal-data breach is any compromise of confidentiality, integrity or availability of personal data — and I would add, any consent violation or denial of a data principal’s rights. There is no threshold. Every breach is, in principle, reportable. The hospital’s graded culture must therefore accommodate a co-resident regime that does not grade at all.

The convergent clock: reporting on the clock

If there is a single point from this discussion that hospital leadership should pin to the wall, it is the one about time.

The serious-event Root Cause Analysis (RCA) window in the hospital world (24–72 hours) lines up almost exactly with the statutory breach-reporting deadline under the data law. I call this the convergent clock.

On the NABH side: a sentinel event is escalated immediately to the quality team and top management; the RCA is opened within 24–72 hours; and the harm is disclosed to the patient and the family.

On the data-fiduciary side: the Data Protection Board and every affected data principal are notified “without delay”; a detailed report reaches the Board within 72 hours of awareness. And note the tighter overlay — where the incident is a cyber-security incident, the CERT-In six-hour reporting obligation also bites.

Two clocks, started by the same incident, ticking in parallel. A hospital that runs them as one synchronized process will comply with both. A hospital that runs them separately will miss at least one.

Fix the case, then fortify the system

Remediation, too, runs in parallel — first the specific case, then the system that allowed it.

On the NABH side, CAPA (corrective and preventive action) redesigns the process, retrains staff and revises the protocol; and FMEA (Failure Mode and Effects Analysis) together with tracked quality indicators closes the loop proactively.

On the data-fiduciary side, the hospital must contain and mitigate — close the gap, reset credentials, recover data and limit harm to data principals — and then harden safeguards: strengthen security controls, retain logs for at least one year, and audit periodically.

Same instinct, two vocabularies: treat the patient in front of you, then immunise the system behind you.

Ownership and consequences: who owns it, and what is at stake

A loop without an owner is a wish. Each regime assigns ownership, and each carries its own stakes.

On the hospital side, ownership sits with the Quality, Patient-Safety and Hospital-Safety committees, anchored in the International Patient Safety Goals, with board-level review of safety and risk. At stake: patient harm, accreditation and reputation.

On the data-fiduciary side, ownership sits with the Data Protection Officer (mandatory for a Significant Data Fiduciary), answerable to the Data Protection Board of India, under a statutory duty of reasonable safeguards. At stake: penalties up to ₹250 crore, and reputation.

Different owners, different penalties — but, again, the same incident triggering both.

The role the system forgets: the Patient Safety Officer

This brings me to the figure who is too often missing from the data-protection conversation in hospitals — the Patient Safety Officer (PSO).

Let me be precise about what the PSO is not. The PSO is not a second DPO, nor a junior CISO. Their job is the clinical-harm axis — not breach notification, not firewalls, but the answer to a single question: “Did this hurt a patient, and what do we do clinically about it?”

That role plays across all three phases of an incident.

Before — design and prevent. The PSO arbitrates the security-versus-safety trade-offs that no firewall engineer can resolve alone: auto-logoff in the ICU, multi-factor authentication at the crash cart, screen lockouts during a code. They bring the safety lens into DPIAs and procurement — safe failure modes, usability, alarm fatigue — and they own the clinical downtime / business-continuity model, drilling it like a code blue.

During — respond. The PSO runs the clinical-harm triage (“is this a patient-safety event?”), throws a safety-net around affected patients (who needs clinical re-checking or follow-up), and supplies the clinical-harm assessment that informs the DPO’s notification decision.

After — learn. The PSO leads the root-cause analysis of the harm pathway (delayed result → delayed treatment), routes data incidents into the adverse-event and Morbidity & Mortality reporting system, owns patient-safety KPIs for cyber resilience, and builds a just-culture for near-miss reporting.

The cleanest way I can put the division of labour is this:

The CISO asks whether the information was protected. The DPO asks whether the compliance held. The PSO asks whether the patient was safe.

Three different questions about one event — and only when all three are answered is the event truly closed.

From the CIA Triad to the CDP Human Triad

All of this exposes the limitation of the model on which information security has rested for three decades — the CIA triad.

The CIA triad protects information. Confidentiality: information is not disclosed to anyone not authorised to see it. Integrity: information is not altered or tampered with without authorisation. Availability: information and systems are accessible whenever needed. It was built for an era when systems were seen mainly as repositories of data, and the impact of a breach was measured in lost or leaked information.

But the harm now lands on people, and the CIA triad cannot see it. Consider three cases in which the information is technically “fine” and yet a human is harmed:

• A ransomware attack compromises availability — but the real consequence is delayed treatment for a patient.
• A faulty AI recommendation leaves confidentiality and availability perfectly intact — yet a wrong output can still expose a patient to harm.
• A privacy violation damages no data at all — yet the person’s autonomy and freedom of choice are undermined.

In each case the CIA triad reports “all clear” while a human being is hurt. That gap is the reason I have proposed graduating from the CIA Information Triad to the CDP Human Triad for the hospital environment.

Three guardians, three mandates

The CDP Human Triad translates into a governance structure of three guardians, each with a distinct mandate.

CISO — protects the Information. Information and network security, cyber defence and incident response, business continuity, technology resilience. Asks: “Are the systems, and the data in them, protected?”

DPO — protects the Privacy. Consent governance, privacy and DPDPA compliance, data-principal rights, purpose limits and breach notice. Asks: “Are the person’s rights and choices protected?”

PSO — protects the Patient. Clinical safety, human-impact and AI-safety oversight, digital risk to patient care, incident management and harm mitigation. Asks: “Is the patient protected — whatever the cause?”

This is the heart of a new jurisprudence in DPDPA compliance for hospitals: the role of the DPO in a hospital must be re-thought, not lifted unchanged from a bank or an IT company. DGPSI-Hospital adopts exactly this CISO–DPO–PSO structure as its framework of compliance.

Governance in practice: a RACI for the triad

To stop the triad from becoming three silos that each sign off on a separate audit, responsibility has to be allocated activity by activity. The following RACI matrix — Responsible (does the work), Accountable (owns the outcome), Consulted, Informed — is how DGPSI-Hospital distributes the work of a single incident.

Activity	CISO	DPO	PSO
Detect, contain & technically recover the incident	A / R	I	C
Clinical-harm triage — is this a patient-safety event?	C	C	A / R
Breach notification (Board & patients) + CERT-In 6-hr report	C	A / R	C
Safety-net affected patients (clinical follow-up / re-check)	I	C	A / R
Run clinical downtime / business-continuity operations	C	I	A / R
Root-cause analysis of the harm pathway	C	C	A / R
Security-vs-safety control trade-offs (auto-logoff, MFA)	R	C	A
DPIA & vendor / SBOM assurance for care-critical systems	R	A / R	C

Read down the columns and you can see each guardian’s centre of gravity; read across the rows and you can see that no single incident belongs to any one of them alone.

The same loop, end to end

To close the circle, here is the entire lifecycle of an incident, shown in both vocabularies at once. Different stakes — a life versus a record — but the same disciplined loop.

Stage	Hospital · NABH	Data fiduciary · law
Identify	Incident reporting: near-miss / adverse / sentinel	Detect and become aware of the breach
Classify	Grade by severity and by domain	Assess scope and risk to data principals
Report	Escalate sentinels; disclose to patient	Notify Board + principals; 72-hour report
Investigate	Root-cause analysis (5-Whys)	Forensic investigation of the breach
Remediate	CAPA — corrective & preventive action	Containment and mitigation
Prevent	FMEA + continual quality improvement	Stronger safeguards + log retention
Govern	Quality & safety committees	DPO + Data Protection Board

The takeaway is simple to state and hard to live: see it, classify it, report it on the clock, find the root cause, fix the system, prevent recurrence — on both axes, every time.

The roadmap: DGPSI-Hospital

DGPSI-Hospital is a framework of DPDPA compliance that integrates information security, privacy and patient-safety principles into one framework. Its central thesis is the one I have tried to build across this entire discussion:

Healthcare security must graduate from the CIA Information Triad to the CDP Human Triad — and must build the CISO–DPO–PSO structure to deliver it.

A hospital that internalises this stops asking the narrow question, “How do we avoid a ₹250-crore penalty?” and starts asking the right one: “How do we make sure that, when something goes wrong with our data, no patient is harmed — and if one is, that we see it, treat it, report it and learn from it?”

That is what it means to say that a hospital is a fiduciary for human life, and not merely a fiduciary for personal data. The data law gives us the discipline. Patient safety gives us the purpose. DGPSI-Hospital is the bridge between them.

Comments and counter-views are welcome, as always. This discussion will continue as the DGPSI-Hospital framework is finalised.

Naavi 

This is in continuation of our earlier post on “Model Risk Management” guidelines released by RBI as draft for public comments.  (Copy of guidelines)

Let us discuss the “Chapter II” of the draft guidelines on “Governance”.

This chapter prescribes that an RE is accountable for the “Outcomes” of all models used by it irrespective of whether it was developed internally or sourced from outside. The focus on “Outcomes” and not the technology itself is a very intelligent way of bringing all “Automated Decision making” into the realms of the regulation.

The regulation also requires that there should be a “Board Approved Model Risk Management Framework” in place including AI/ML models. Since the definition of “Models” extend to all algorithms, analytics, interfaces, applications, decision-based rules, and other computational tools which, by virtue of their use, have a material impact on decision-making in various business processes, this applies to even internal excel sheets which are designed to take decisions and influence client decisions.

The Model Risk Management Framework (MRMF) should therefore cover risks that arise from the use of any automated decision making algorithms.

The distinction of what is included and what  is not in the regulation depends on the detailed definition of a “Model” which uses three  components.

1. Input Component

2. Processing Component

3. Output component.

Input component includes “Data”, “Decision rules” and “Assumptions”.

Processing component includes “Statistical”, “Mathematical” techniques including AI which is used to analyse and interpret the input components.

Output components are the business and operational decision making that arises out of the model.

This is a very broad definition and hence MRMF has to include all decision related risks where the decision making uses a software component which  uses any form of intelligence.

The Board should be responsible for the oversight on MRMF and periodically approve and review. Guideline also recognizes the need for factoring the RE’s risk appetite.

This exactly reflects the DGPSI principles where the risk assessment is vetted by the top management  and a “Deviation Justification Document” based  on the Risk absorption capacity is adopted.

Committees  under the Board and the Senior Management are expected to establish appropriate procedures etc to mitigate the risks.

Chapter III of the  draft regulations address the “Model Risk Management” (MRM) requirements.

The MRM requirements suggest three lines of defence namely

a) Model owners being first line of defence,

b) An independent model risk management and validation function being second line of defence, and

c) A  robust and independent internal audit function being third line of defence

This is the same as “Process Owners” as the  process  level risk managers envisaged in the DGPSI. Suggests Concurrent supervision  including performance testing.

The guideline recommends “Risk Based Model Tiering” with “High” or “Low” which should be reviewed at least annually. Models  classified as “High Risk” should be approved by an appropriate committee. The Risk assessment is based on the impact on the financial outcomes affecting the RE as well as the potential implication on the consumers.

An appropriate inventory of all “Models” need to be maintained by the RE with details such as Model Owners, developers, Validators, approvers, risk, intended use, dependencies etc. This is similar to the “Process Inventory” recommended under DGPSI.

RE should ensure that the Grievance redressal system should cover the consumer risks.

Chapter IV covers the Model Life Cycle Management which requires appropriate  documentation and procedures of model selection, development, validation, approval, deployment and online monitoring.

RE should also manage appropriate Change Management, Business Continuity management  and  De-commissioning of unused models.

Under Chapter V, the guideline specify how policies and procedures should guide third party models in the entire life  cycle of acquisition, use, de-commissioning etc.

Guidelines specify that An RE should define the scope of AI / ML model, including for foundational AI models and frontier AI models, and put in place additional controls, commensurate with its potential impact on customers, business operations, and financial outcomes.

In cases where the third-party provider does not disclose adequate information regarding the AI / ML model, the RE should identify risks that arise from such constraints, and put in place the necessary mitigants, such as limiting the usage.

In cases where the third-party provider does not disclose adequate information regarding the AI / ML model, the RE should identify risks that arise from such constraints, and put in place the necessary mitigants, such as limiting the usage.

RE should put in place appropriate control boundaries through system-level controls or model design features to mitigate risks of hallucinations, particularly in models capable of generating content (e.g., generative AI models) and use cases where the model outputs directly or indirectly drive customer interaction or decision making.

It should ensure that models are not overfitted to training data and are capable of appropriate generalisation.

An RE should establish appropriate mitigants to address the data risks such as data quality, non-representativeness, incompleteness, breach of intellectual property rights. (*Ed: Need to add Personal Data Protection also) Changes in data distribution, including data drift and concept drift, should be monitored and addressed on an ongoing basis.

Guidelines prescribe “Human Oversight”  on AI and adoption of “Kill Switch”  stating

An RE should establish robust human oversight for AI models including use cases involving automated decision-making by models. It should establish appropriate risk mitigants which inter-alia include:
(i) Human-in-command arrangements (e.g., human-in-the-loop / human-on-the-loop / other human oversight mechanisms);
(ii) override, suspension, or deactivation mechanisms, including kill-switch arrangements; and,
(iii) periodic review of model outputs and model-driven decisions by humans to identify anomalies.

Chapter VI clarifies that these guidelines once approved will super cede relevant provisions in the Guidance Note on Credit Risk management dated October 12, 2002.

In summary,  RBI has produced a comprehensive governance framework that extends beyond AI to encompass every automated decision-making model used by regulated entities. Its emphasis on Board accountability, lifecycle governance, independent validation and human oversight makes it one of the most mature regulatory approaches to AI governance in India.

From the DGPSI perspective, many of the principles—Board oversight, risk-based governance, process ownership, inventories, lifecycle management and documented risk acceptance—are already embedded within the DGPSI framework, demonstrating a strong convergence between RBI’s regulatory expectations and established data governance best practices.

This development has given some additional thoughts  for elaborating certain  aspects of DGPSI-Banks.

Just as “Data is Life” is a key differentiator for   DGPSI-Hospital framework,  “Model Risk Management” becomes a key distinction of DGPSI-Banks framework.

Naavi

1. An Interesting Workshop on Healthcare is being organized by KIMS Hospitals in Secunderabad on 27th June 2026.

Details are as follows.

 

Naavi is happy to participate in the event.

Naavi

In continuation of our previous post,  here is an outline of the 16 page draft guidelines issued by RBI on AI usage in Regulated Entities (RE), for public comments.

The scope of the guideline  has been defined broadly as to cover “Models” and termed Artificial Intelligence as a “Technology”. The risks arising out these models usage is termed as “Model Risks” which may lead to inaccurate outcomes, flawed decisions, financial losses, operational disruptions, compliance failures and other adverse consequences for REs, consumers and the financial system.

The Guideline itself is called “Guidance on Regulatory Principles for Model Risk Management 2026”  (GRP-MRM).

Hence  the guidance lays down a broad set of regulatory principles for the management of risks arising from use of models which includes AI/ML. The guidance is applicable to all REs.

The chaptalization of the guidance note is as follows:

Chapter I: Preliminary

Chapter II:  Goverance

Chapter III Model Risk Management

Chapter IV: Model LifeCycle Management

Chapter V: Specific Models

Chapter VI: Other Provisions.

Chapter I covers the Introduction, Applicability and Scope as well as the definitions.

For the purpose of the guidance, “Model” has been defined as follows:

‘Model’ means a system, whether developed internally, sourced from third-parties, or a combination thereof, that incorporates data, applies theoretical, empirical, or judgement-based assumptions (input component), uses statistical, mathematical, economic, financial, or such other cognitive techniques (including Artificial Intelligence (AI) / Machine Learning (ML)) to analyse, interpret relationships and process inputs (processing component) and produce results that are used for business or any other operations and decision making (output component).

It includes algorithms, analytics, interfaces, applications, decision-based rules, and other computational tools which, by virtue of their use, have a material impact on decision-making in various business processes, irrespective of whether such tools are recognised as models by the RE.

Illustration – A spreadsheet-based loan pricing calculator deployed or used by an RE may be considered as only a basic mathematical tool. However, if the RE uses this tool to derive lending rates, customer margins, or credit terms, such that it takes inputs (borrower type, tenor, credit score, collateral value), applies processing logic (interest rate grids, risk-weighted spreads, margin formulas), and produces an output (final lending rate or price) which then affects business decisions, then it should be considered as a model

This approach is a huge innovation that avoids the debate on “What is the technical definition of AI” and focusses more on the intention  of the use of software to by pass human intervention. (This may impact our definition of AI in the DGPSI-AI framework).

…To Be Continued

Naavi

Also Listen to t he explainer here

View the Video Overview here.: