Watch out for a Discussion on AI Governance Standard for India

Naavi and FDPPI have already released DGPSI AI as a standard for implementation of DPDPA in AI environment.

This framework includes  6 principles  followed by 22 implementation specifications of which 9 are by deployers and 13 are by developers.

Together this has the potential to be called as the AI Governance Standard for India since it meets the recent guidelines of RBI and the challenges indicated by the Open AI-Hugging Face issue.

Naavi will be discussing more on this concept during August 21-23 training for Independent Data Auditors as well as the master class for CEDPO which will precede on August 9th.

Naavi

Posted in Privacy | Leave a comment

Posted in Privacy | Leave a comment

Does AI Safety Come from Closed Models or Transparent Models?

(In continuation of the earlier article)

The recent debate surrounding the interaction between OpenAI’s proprietary models and the Hugging Face open-model ecosystem has also brought another question back into the spotlight.

Hugging Face reportedly relied on an open-weight model during incident response because commercial models’ guardrails limited forensic analysis, reigniting the debate between closed AI and open-weight AI.

We need to discuss governance, accountability, and auditability matters related to AI along with what is more secure…an Open or Closed model.

According to one school of thought,  advanced AI models should remain proprietary, tightly controlled, and accessible only through guarded interfaces. The other believes that openness, peer review, and community scrutiny are the foundations of trustworthy AI.

Closed Model Argument

Developers of proprietary AI systems maintain that restricting access is an essential safety measure. If powerful models are freely downloadable, malicious actors can:

  • remove built-in safety guardrails,
  • automate cyber attacks,
  • generate sophisticated malware,
  • create convincing misinformation,
  • bypass content restrictions, and
  • exploit vulnerabilities at scale.

From this perspective, restricting access is comparable to placing sensitive equipment inside a secure laboratory instead of leaving it on a public street. However, history may suggest otherwise.

The Open Model Argument

Advocates of open models compare AI to cryptography. Modern cryptographic systems are not secure because their algorithms are secret. They are secure because thousands of experts have examined them, attacked them, tested them, and failed to break them.

They argue that transparency often exposes weaknesses before criminals exploit them. Open-source software powers much of today’s Internet, not because it is impossible to attack, but because vulnerabilities are discovered and corrected rapidly by a global community.

The same principle is increasingly being applied to AI. If researchers cannot inspect a model, how can they independently verify:

  • hidden biases,
  • security weaknesses,
  • unsafe behaviour,
  • hallucination tendencies,
  • privacy leakage, or
  • undocumented capabilities?

Transparency creates accountability. However, it is also true that transparency lowers the barrier for misuse and this paradox needs to be resolved.

Real Question

The fundamental question here may not be whether closed systems are safer or open systems are safer. It could be how the “Development of AI” is governed. There has to be accountability at the developer’s level. The DGPSI-AI model that has been put up by Naavi/FDPPI for DPDPA compliance addresses this issue by making a submission of an “Explainabilty statement by the developer mandatory” and such statement to contain details of how the development was tested and whether auditability and accountability is ensured. (Check page 20 of the document  )

It is essential for AI developers to ensure the answering of the following questions.

  • Who approved the model?
  • What data was used for training?
  • Is the data legally obtained?
  • How is personal data protected?
  • What testing has been conducted?
  • What are the known limitations?
  • Who monitors performance after deployment?
  • What happens when the model behaves unexpectedly?
  • Who is accountable for its decisions?
  • Can an independent auditor verify compliance?

Under DPDPA 2023 where the user of the software is a “Data Fiduciary”, he has a duty to raise such questions with the developer and the developer should if the source code is not public assume the responsibility of a “Joint Data Fiduciary”.

Further just these steps may not prove that the AI cannot go rogue. Hence all AI usage as “Significant Risk” and treating the user as a “Significant Data Fiduciary” is a mandatory requirement.

In the interim when industry battles the IPR issues FDPPI urges academic institutions to join hands with FDPPI to set up AI tools Audit laboratories so that AI tools can be subjected to third party audit. This will be a good faith attempt for the developer and the deployer of AI to mitigate the AI risks.

Naavi

Posted in Privacy | Leave a comment

Is Open AI guilty of unleashing the Hugging Face attack to challenge the publicity of Anthropic’s Mythos?

The Open AI-Hugging Face incident is a watershed moment in the development of higher intelligence AI.

To recall the incident it is reported that :

In mid-July 2026, the AI startup Hugging Face (which runs a popular platform where developers share AI models and datasets) discovered that its internal computer systems had been hacked. Over a weekend, AI agents carried out thousands of actions across many temporary virtual computers, moving through the company’s internal systems. Hugging Face reported it to police before anyone knew who was behind it.

It was subsequently found that the hacker was not a human but it was one of OpenAI’s own AI models, which broke out of a testing environment and into Hugging Face’s protected systems.

During the investigations it was found that OpenAI was running an internal test to measure how good its models are at hacking. The models were being tested for hacking capabilities in an isolated testing environment with constrained network access and had their normal safety checks turned off as a result.

Some analysts believe that this is an “Accident” and there was no “MensRea” or “Guilty mind” on the part of Open AI.

But Naavi.org belongs to an alternate school of thought which considers that this test was an attempt to create a tool for committing a crime. Hacking is a crime in every law though security analysts claim that it is part of the Cyber Security tool. But training an AI agent to commit hacking was a clear criminal activity similar to a terrorist country developing Nuclear weapon to destroy the world.

This is not scientific research. This is Criminal Tool development. Open AI should not be allowed to escape with a mere apology. OPEN AI therefore  must be made to pay a price.

Every country has a cyber law provision to make this a punishable crime. Even India has provisions under ITA 2000 which can be invoked to send a notice to OPEN AI to show cause why the attempt should not be considered as an attempt to break into secure systems in India including those declared “Protected” under Section 70 of ITA 2000.

It is alleged that the models weren’t told to attack Hugging Face. They were just trying to win at the test (a benchmark called “ExploitGym”). All evidence suggests the models were hyperfocused on finding a solution, going to extreme lengths to achieve a narrow testing goal. They figured out that Hugging Face might host answers that would help them cheat, escaped their sandbox, reached the open internet, and used publicly exposed credentials across four accounts on four services to break in.

This is a defence for claiming lack of “MensRea” to make this incident miss the Criminal Charges.

But Civil Charges should remain and Open AI should be asked to explain the failure of security. Negligence is evident since there were no guardrails to prevent the model attempting the hacking outside the laboratory environment. There is also no evidence to prove that an other system was also attacked.

During 2000 when the “I Love You” virus escaped the Phillipines laboratories and devastated the world, (P.S: The virus originated at AMA Computer College , now AMA Computer University,  in the Philippines and caused an estimated damage of upto $20 billion worldwide), the technology sector was not as advanced as now.

Presently OPEN AI could be considered negligent in not setting the outer boundaries for the testing of the Agentic software . There could be one speculation that this was engineered as a leak to counter the publicity that Anthropic got for its “Mythos AI” exploits. Hence the “Lack of MensRea” or lack of guilty intention on the part of Open AI can be challenged.

Hence it is essential for the Government of India to issue a notice to Open AI to provide an assurance that “No system other than the reported hugging face systems and more particularly no systems in India has been hacked using the capabilities of Open AI either in laboratory testing or otherwise”.

Naavi

 

Posted in Privacy | Leave a comment

Catching Up with key developments

During the last week when we were diverted towards other activities, following developments have taken place which still needs attention.

1.Open AI hacking of Huggingface

2.Bank of Baroda Data breach

3. AI in Auto sector

This is in addition to the RBI Data Governance Framework which is relevant for our DGPSI-Bank discussion.

Watch out for a series of articles on these topics.

Naavi

Posted in Privacy | Leave a comment

RBI’s Single Source of Truth (SSOT) Principle Will Transform Data Governance in Indian Banking

The Reserve Bank of India (RBI) released its Draft Guidance on Regulatory Expectations for Data Governance on 15 July 2026, inviting public comments. The draft introduces several important concepts in enterprise data governance, many of which have already been incorporated into the DGPSI (Data Governance and Protection Standard of India) framework. One of the most significant among them is the concept of Single Source of Truth (SSOT) in data architecture.

While designing a DPDPA-compliant Data Governance and Protection Management System (DGPMS), one of the most challenging areas is the implementation of the Data Principal Rights Management System. A Data Principal may exercise several statutory rights, including the right to know how personal data is being processed, the right to correct information, the right to erase data, or the right to withdraw consent either wholly or partially.

Effective implementation of these rights requires a well-designed data governance architecture. If multiple, uncontrolled copies of personal data are scattered across different systems, applications, or business units, responding accurately to such requests becomes difficult, expensive, and sometimes impossible. Unless the organisation has complete visibility over every instance of the data, compliance with DPDPA obligations cannot be assured.

In contrast, when every data element has a clearly identified authoritative version, the data remains accurate, current, and manageable. Corrections, deletions, consent withdrawals, valuation, and audit trails can all be executed with confidence and consistency.

For decades, information security professionals have advocated distributed storage architectures to minimise the risk of a single point of failure. Concentrating all data in one repository was traditionally viewed as increasing cyber risk by creating an attractive target for attackers.

However, the legal obligations arising under modern privacy and data protection laws have altered this perspective. Today, the absence of a clearly defined authoritative data source can itself become a significant compliance risk. Organisations are increasingly expected to demonstrate that they know exactly where personal data resides and can act upon it without ambiguity.

From a governance perspective as well, different business functions—operations, risk management, compliance, audit, and senior management—must make decisions based on the same trusted data. Competing versions of the same data inevitably lead to inconsistent reporting, flawed analytics, and poor decision-making.

The challenge, therefore, is no longer merely securing data. It is about balancing cybersecurity requirements with governance and regulatory obligations.

The RBI’s explicit adoption of the Single Source of Truth (SSOT) principle is therefore a landmark development. It will require many banks and other regulated entities to revisit and significantly redesign their existing data architecture and governance practices.

The draft guidance requires that:

  • Every Regulated Entity (RE) should establish and maintain a Single Source of Truth (SSOT) for every data element.
  • No parallel or competing authoritative sources should exist for the same data element.
  • All downstream systems, analytical models, reports, and business processes should derive their data from the designated SSOT.

Importantly, the RBI does not prescribe a single implementation model. A Regulated Entity may adopt a centralised, federated, or hybrid architecture, provided the SSOT framework ensures:

  • clear identification of the authoritative source for every data element;
  • consistency of data across business, risk, compliance, and all other organisational functions; and
  • complete traceability of aggregated data and reports.

The draft further requires that:

  • the designation of the SSOT, and any subsequent changes, must be approved by the Data Governance Executive Committee (DGEC) and documented; and
  • the Data Governance Committee (DGC) should be informed of such decisions.

In addition, every Regulated Entity should establish robust reconciliation mechanisms to identify and resolve inconsistencies between the SSOT and downstream data repositories.

The RBI has also recognised that the risks associated with centralisation can be mitigated through federated or hybrid architectures, where data may remain physically distributed while being governed through a well-defined authoritative source and controlled access mechanisms. Such architectures can provide the benefits of SSOT without compromising resilience or security.

This is likely to become one of the most significant implementation challenges for banks and other RBI-regulated entities over the coming years.

The DGPSI-Banks framework already incorporates these governance principles within its DPDPA compliance methodology. The RBI’s draft guidance further validates this approach and provides an additional regulatory impetus for organisations to strengthen their data governance architecture around the concept of a trusted and authoritative Single Source of Truth.

Watch out for the Naavi’s “Gateway Risk Management System” to elaborate how the balancing can be achieved between the SSOT principle and mitigation of the Single Source of Failure risk. (SSOF).

Naavi

Posted in Privacy | Leave a comment