India's AI ambition is clear, and the foundations are strong. The next step is to make trust and safety just as concrete at the point of deployment, inside the enterprises using AI for payments, credit, healthcare, hiring and compliance. The aim is for each of them to be able to show, with operational evidence as well as written principles, that they know when a model is not behaving as intended. They should also be able to catch such issues quickly and demonstrate this capability to a regulator.

Here, the case rests on a simple distinction. For risks that are adversarial and system-mediated, building on existing national cybersecurity practice is the quickest route to meaningful coverage. For risks that arise within models themselves, such as bias, hallucination and drift, India will need new tools and dedicated teams. The two efforts work best in parallel, and progress on the first does not need to wait for the second.

What cybersecurity cannot cover?

Extension has limits, and the argument is stronger for saying so. Some AI failures are not attacks at all. A credit model can quietly disadvantage rural borrowers, and a medical assistant can mistake anxiety for a gastric condition. No firewall or SIEM will flag either, because nothing has been breached. These are failures of fairness, accuracy and alignment, and they need specialists in statistics, domain ethics and model evaluation. This is why the NIST AI Risk Management Framework and ISO/IEC 42001 treat AI risk management as a discipline.

The strongest objection to extension concerns skills is that security teams today lack ML expertise. That is a real constraint, and the later sections address it. It is a reason to train and supplement security teams, not to build parallel monitoring, logging and incident response for the risks they already handle.

Policy is already moving this way

India's regulators are not starting from a blank page. RBI's FREE-AI report (August 2025) offers 26 recommendations under six pillars, and its central choice is to build on what already exists. It proposes AI-specific upgrades to existing directions instead of a standalone rulebook. The upgrades include bringing AI threats such as model poisoning and adversarial attacks into cyber risk assessments and strengthening the digital lending, fraud risk and IT governance directions. MeitY's November 2025 guidelines carry the same logic across sectors, adapting RBI's seven sutras and relying on existing laws and sectoral regulators [3].

On the other end, the institutions are strengthening too. CERT-In's allocation rose to INR 269 crore in 2026-27 from INR 255 crore, and the Data Protection Board's budget doubled to INR 10 crore. The two bodies have different mandates, so the contrast between them reflects how mature each is, not neglect. The IndiaAI Safety Institute, announced in January 2025 on a hub-and-spoke model, is now building its leadership, with a director recruitment under way in mid-2026. In the meantime, CERT-In's established reporting pipeline and enterprise relationships give India a working base to extend.

The convergence zone

Much documented AI harm is adversarial. CERT-In's November 2024 advisory warned of deepfake-enabled fraud. In Thales's 2026 survey, 64% of Indian organizations ranked AI as their top data security risk and 65% reported deepfake-driven attacks. Bitdefender's 2025 survey found 63% of respondents believing that they had faced an AI-involved attack. Both vendors sell security products, and both figures are self-reported, so it is advised to treat them as signals. What the case needs is incident data, which is why recommendation one matters.

Deepfake fraud attacks the verification layer. Detection is an arms race, so durable controls are provenance, out-of-band verification and callbacks for high-value approvals. Indian tools such as Vastav AI help, and the 2026 IT Rules now mandate labelling and provenance metadata for synthetic media on platforms. Neither covers an enterprise's internal approval channels.

Prompt injection resembles SQL injection, but the UK's NCSC warns comparison is dangerous. LLMs do not separate instructions from data, so injection may never be fully mitigated and must be managed by reducing impact. That strengthens the case for security teams. Least privilege, sandboxing and human approval for consequential actions are their daily work.

Model supply chain compromise resembles a backdoored dependency. Checkpoints, fine-tuning data and third-party model APIs belong in existing vendor-risk processes.

AI-enabled phishing is cheaper and more persuasive, but sender verification, behavioural baselines and anomaly detection still apply.

The agentic shift

The case strengthens as AI moves from chatbots to agents with credentials and authority to act. OWASP's 2025 LLM Top 10 expanded "Excessive Agency" to cover excess functionality, permissions and autonomy, and MITRE ATLAS catalogues adversary techniques against AI systems. An agent that can query customer records or issue refunds raises questions of non-human identity, credential scoping and tool permissions. A poisoned document can steer it into misusing legitimate access. This is access control and incident response applied to a new kind of actor.

What already exists, and what is missing?

CERT-In's 2022 directions already make attacks on AI and ML systems reportable within six hours. Furthermore, its July 2025 guidelines define an AI bill of materials, but compliance is voluntary. However, what is missing is narrower. This includes consequential model failures, mandatory provenance for high-stakes models, verification on enterprise channels, and inference-level logs.

Some recommendations

1. Extend CERT-In's reportable categories from attacks on AI to consequential AI failures. Owner: CERT-In. Reportable events would be those where hallucination, drift or model compromise causes a materially wrong decision in a regulated sector. Thresholds prevent noise. Metric: share of qualifying incidents reported within twelve months.

2. Consider making AIBOM a requirement for high-consequence models. Owners: sector regulators, through procurement and vendor-risk rules. The guidelines exist; the step is to require them. Metric: share of production models with documented provenance.

3. Require output audit trails for high-consequence AI. Owners: sector regulators, extending CERT-In's existing log requirements. Credit, health, hiring and insurance systems should retain inference outputs, confidence scores and human-review records. Metric: ability to reconstruct a contested decision on request.

What this looks like in practice?

A bank's security operations centre adds inference-log monitoring for its loan assistant, flags anomalous prompt patterns at the LLM gateway, limits the agent to read-only database credentials, and keeps a playbook for who is paged when a model checkpoint hash changes. The SOC, escalation path and audit trail are unchanged. No new function is needed to start.

Where could this go wrong?

Security teams may lack ML skills, so train them and embed ML engineers. Security framing may crowd out fairness work, so bias needs named owners and budgets from day one. Extension may decay into box-ticking, so require adversarial red-teaming of deployed models.

What enterprises should do now?

Regulation moves at legislative pace and deployment moves faster. Give security teams an explicit AI mandate covering verification, input and agent containment, supply chain integrity and output logging. In parallel, hire or partner for bias auditing, hallucination accountability and alignment monitoring.