AI Governance Frameworks Compared: NIST, EU AI Act, and What Indian Companies Adopt
An AI governance framework question usually arrives uninvited. A customer sends a vendor questionnaire with a section headed "AI governance." A client contract adds a clause referencing the EU AI Act. A job posting asks for "familiarity with NIST AI RMF." Nobody plans to study AI governance; it shows up in the inbox and demands an answer.
This page compares AI governance frameworks that actually exist: what each one is, whether it is law or advice, who it binds, and which ones an Indian company genuinely needs. The honest frame, stated up front because it is this article's thesis: most of these frameworks are voluntary; one is binding law with reach far beyond Europe; India has deliberately chosen not to pass a separate AI law. Most Indian companies adopting a framework do it because a customer asked, not because a regulator did.
If you are deciding whether to take an AI governance certification, that is a different question; we cover the credentials separately.
What Is an AI Governance Framework?
An AI governance framework is a structured set of principles, processes and controls that an organisation uses to decide how AI systems are built, tested, deployed and monitored: who is accountable, which risks must be assessed, what evidence must be kept, and when a system must not ship at all.
Three distinctions organise everything else on this page, so take them first. Governance is not ethics: ethics states what is desirable, governance assigns responsibility, defines process and produces evidence, and an auditor cannot inspect an intention. Governance is not model performance: a model can be accurate and still be ungoverned, with no record of its training data, no named owner and no procedure for when it fails. And governance applies to systems, not just models: the retrieval corpus, the prompt template, the fallback logic and the human review step are all in scope. What governance tries to control, ultimately, is the real risks that come with deploying AI systems, from biased decisions to silent failures.
One example will run through this article: a loan-approval model at an Indian NBFC. It lands in the EU AI Act's high-risk category, touches DPDP-covered personal data, and sits under RBI's remit, which makes it perfect for showing how the frameworks overlap.
Framework vs regulation vs standard: three different things people call "a framework"
The word "framework" is doing three different jobs in this space, and confusing them is the most common mistake in the field.
A voluntary framework (NIST AI RMF, the OECD AI Principles) is guidance you choose to adopt. It has no legal force anywhere; its power is that customers and procurement teams ask for it. A regulation (the EU AI Act, India's DPDP Act) is binding law:
non-compliance carries penalties, and it applies to you whether or not you have heard of it. A certifiable standard (ISO/IEC 42001) is voluntary to adopt, but once adopted it can be audited by an accredited third party and certified, which is what makes it useful in procurement.
The practical consequence: "we follow the NIST AI RMF" is a description of internal practice nobody can verify. "We are ISO/IEC 42001 certified" is an externally audited claim. "We comply with the EU AI Act" is a legal obligation, not a choice. These are not interchangeable.
AI Governance Frameworks Compared (2026)
Here is the table the title promises, before anything else. Every row is traceable to a primary source, linked in the sections below.
| Framework | Issuer | Status | Scope | Risk approach | Applies to | Certifiable? | Where it bites in India |
|---|---|---|---|---|---|---|---|
| NIST AI RMF 1.0 | NIST, US Dept of Commerce | Voluntary; no legal force anywhere | All AI systems; sector- and jurisdiction-neutral | Four continuous functions (Govern, Map, Measure, Manage), not risk tiers | Anyone who adopts it; common in US procurement and vendor questionnaires | No. NIST issues no certification | Reaches Indian firms through US client contracts and RFPs; the most common answer to "describe your AI risk approach" |
| EU AI Act (Regulation (EU) 2024/1689) | European Parliament and Council | Binding law, directly applicable in 27 member states | AI systems and general-purpose AI models on the EU market, or whose output is used in the EU | Risk tiers (unacceptable / high / limited / minimal) plus a separate GPAI track | Providers, deployers, importers, distributors, including outside the EU (Art. 2) | No, but high-risk systems need conformity assessment and CE marking, some via a notified body | Directly binds Indian companies selling into the EU or whose AI output is used there; reaches others via customer contracts |
| ISO/IEC 42001:2023 | ISO and IEC (JTC 1/SC 42) | Voluntary standard, but increasingly mandated contractually | An AI management system (AIMS): organisational processes, not individual models | Plan-Do-Check-Act cycle with risk and impact assessment against Annex controls | Any organisation that develops, provides or uses AI products or services | Yes, the only framework here that certifies an organisation, via an accredited certification body | The most requested credential in Indian enterprise procurement; IT services and SaaS firms use it to clear security reviews |
| OECD AI Principles | OECD | Intergovernmental recommendation; non-binding on companies | Values and policy advice addressed to governments | Principle-based; no tiers, controls or audit criteria | Adherent governments (47 as of Aug 2026); companies only via derived national law | No | India is not an adherent (it endorsed the G20 AI Principles instead); still matters because the EU AI Act adopted the OECD definition of "AI system" |
| DPDP Act 2023 + DPDP Rules 2025 | Parliament of India; Rules notified by MeitY | Binding law; Rules notified 14 Nov 2025 with an eighteen-month phased compliance period | Processing of digital personal data; not AI-specific, but reaches most AI systems touching personal data | Obligation-based: notice, consent, purpose limitation, security safeguards, breach notification; heavier duties for Significant Data Fiduciaries | Data Fiduciaries in India, and offshore processing tied to goods or services offered in India | No | The one genuinely binding AI-adjacent obligation for a domestic-only Indian company; training data, inference logs and RAG corpora are all in scope |
| India AI Governance Guidelines | MeitY, under the IndiaAI Mission | Voluntary guidance; states a separate AI law is not needed at present | National direction: seven Sutras, six pillars, an action plan, practical guidelines | Harm-based and adaptive: "voluntary measures supported by techno-legal solutions", with baseline measures possibly mandatory later | Industry, developers and regulators in India | No | Signals Indian regulators will apply existing law (IT Act, DPDP, consumer protection, civil and criminal codes) to AI rather than write new AI law |
| RBI FREE-AI framework | Committee constituted by RBI | Committee recommendations to RBI; not binding directions | AI in the Indian financial sector | Seven Sutras, six pillars (Infrastructure, Policy, Capacity, Governance, Protection, Assurance), 26 recommendations | Banks, NBFCs and other RBI-regulated entities | No | The most concrete sectoral signal in India; BFSI teams are folding AI into existing model-risk governance ahead of any binding direction |
Deliberately omitted: Singapore's Model AI Governance Framework, Canada's AIDA, the Council of Europe's AI Convention and China's generative AI measures. They matter regionally and are out of scope for an India-first comparison; one mention each, no rows.
How to read this table
Three points. First, the Status column matters most: only two rows are binding law for an Indian company, and one of those is not about AI at all. Second, the Certifiable column is what procurement cares about, which explains why ISO/IEC 42001 gets budget approval when NIST AI RMF does not, despite NIST being the better engineering framework. Third, these are complements, not alternatives: a mature company uses NIST as its internal method, ISO/IEC 42001 as its external proof, and the EU AI Act as its hard constraint.
If the "Certifiable?" column has you thinking about individual credentials rather than organisational ones, that is a separate question, and our sibling page covers [AI governance certifications and what each one examines] accordingly.
Build an AI-First Career, Master the Complete Skillset
Choose from our industry-leading programs designed for career success
Modern Software and AI Engineering Program
Master full-stack development with AI integration
+1000 moreModern Data Science and ML with specialisation in AI
Advanced data science techniques with AI specialization
+1000 moreAdvanced AIML with Specialisation in Agentic AI
Deep dive into AIML with focus on Agentic systems
+1000 moreDevOps, Cloud & AI Platform Engineering
Build and manage AI-powered cloud infrastructure
+1000 moreAI Engineering Advanced Certification by IIT-Roorkee
Premier AI engineering certification from IIT-Roorkee
AI Forward Deployed Engineer Program
Full-stack engineering, production AI and client-facing consulting
+1000 moreNIST AI RMF: What Govern, Map, Measure and Manage Actually Mean
The NIST AI Risk Management Framework (AI RMF) 1.0 was released by NIST on 26 January 2023, is intended for voluntary use, and is published as NIST AI 100-1 alongside a companion Playbook. It is designed for organisations of any size in any sector, and it maps to, rather than replaces, existing risk practice. Most pages restate NIST's one-liners for the four functions. Below: what a team actually does, and what artifact exists afterwards. (For readers searching "NIST AI RMF", this is the section to send them.)
Govern: the function that fails first
Operationally: name an accountable owner per AI system; define what the organisation will and will not build; set the escalation path when a model misbehaves; give somebody the authority to stop a release. Artifacts: an AI system inventory, an acceptable-use policy, a named risk owner per system, a documented escalation route.
The point competitors skip: Govern is cross-cutting, not step one; NIST positions it as informing every other function continuously. It is the one most organisations skip because it requires authority rather than tooling. A team with excellent bias metrics and nobody empowered to block a launch has not governed anything.
Map: establishing context before measuring anything
Operationally: document what the system is for, who it affects, what happens when it is wrong, and the realistic misuse cases, before building evaluation criteria. Artifacts: a system context document, an impact assessment, a stakeholder list, an intended-use and out-of-scope-use statement.
For the NBFC loan model, Map records that rejected applicants are affected, that a false rejection costs differently than a false approval, and that the model was never intended to screen commercial loans, which is exactly the misuse a business team will eventually attempt.
Measure: quantifying what Map identified
Operationally: pick metrics that reflect the identified risks, not aggregate accuracy; test across subgroups; measure robustness, drift and explainability; document what was not measured and why. Artifacts: an evaluation report with subgroup breakdowns, a test dataset with documented provenance, a record of known limitations.
A single accuracy number is not a measurement of risk. Equal accuracy across two populations can still mean unequal harm when the cost of an error differs between them. This is where governance and performance metrics in machine learning genuinely converge, and where an engineer's existing skills transfer directly.
Manage: acting on what Measure found
Operationally: prioritise the identified risks, decide which to accept and document that acceptance, implement mitigations, and monitor in production with a defined response procedure. Artifacts: a risk register with treatment decisions, monitoring thresholds, an incident response runbook, a decommissioning plan.
The most under-built artifact is the decommissioning plan. Organisations plan how to launch a model and never how to retire one, and an unretired model that nobody owns is a classic audit finding.
The Generative AI Profile (NIST AI 600-1)
NIST released the Generative AI Profile as NIST AI 600-1 on 26 July 2024, to help organisations identify risks specific to generative AI and map them to the same four functions. For this audience it is the bridge between a framework written for classical ML and the LLM applications most readers actually build: confabulation, prompt-driven data leakage, harmful outputs, and provenance of generated content.
The EU AI Act: Risk Tiers and the Obligations Timeline
The EU AI Act (official text, Regulation (EU) 2024/1689) is the world's first comprehensive AI law. As a regulation it is directly applicable; no national transposition is needed. Its obligations depend entirely on what your system does, not on what technology it uses. An EU AI Act summary in one line: classify your use case, and the tier tells you your duties.
The four risk tiers (EU AI Act risk levels), with concrete examples
| Tier | What it means | Examples | Core obligation |
|---|---|---|---|
| Unacceptable risk | Prohibited outright (Article 5) | Social scoring by public authorities; manipulative techniques materially distorting behaviour and causing harm; untargeted scraping of facial images from the internet or CCTV to build recognition databases; emotion inference in workplaces and schools (narrow exceptions) | Do not deploy. No compliance route exists |
| High risk | Permitted, heavily regulated (Article 6, Annexes I and III) | Recruitment and worker management; creditworthiness assessment; access to education; certain law-enforcement, migration and infrastructure uses; AI as a safety component of a regulated product | Risk management system, data governance, technical documentation, logging, human oversight, accuracy and robustness, conformity assessment and CE marking |
| Limited risk (transparency) | Permitted with disclosure duties (Article 50) | Chatbots and other systems interacting with people; systems generating synthetic text, audio, image or video; deepfakes; emotion recognition outside prohibited contexts | Tell the user: disclose AI interaction; mark synthetic content in machine-readable form |
| Minimal risk | Everything else | Spam filters, recommendation engines, inventory forecasting, most internal tooling | No obligations; voluntary codes of conduct encouraged |
Example cells checked against the Act's Article 5 and Annex III text in August 2026; the Commission's overview of the tiers matches. The point readers most need: the tier is a property of the use case, not of the model. The same LLM is minimal risk in a documentation search tool and high risk in a CV-screening tool. That is the sentence confused engineers get wrong.
General-purpose AI models: the separate track
GPAI models are regulated on their own track rather than by use-case tier: transparency and technical documentation duties for all providers, plus additional obligations (systemic-risk assessment, incident reporting) for models deemed to present systemic risk. The Act presumes systemic risk above a cumulative training-compute threshold set in Article 51; check the consolidated text for the exact figure rather than quoting secondary summaries.
Practical framing: if you fine-tune or call someone else's foundation model rather than training one, these duties sit primarily with the model provider. What lands on you is the documentation they hand down and your duty to use it, which is why the model card and licence terms you skim today become compliance artifacts tomorrow.
Understanding how large language models are actually structured helps here: the GPAI rules live at the model layer, while the risk-tier rules live at the application layer built on top of it.
The obligations timeline: what the AI Omnibus changed in July 2026
Verified against the European Commission's official implementation timeline and the Commission's AI Omnibus announcement on 21 August 2026. Set a quarterly re-verification reminder for this table.
| Date | What applies |
|---|---|
| 1 August 2024 | The AI Act enters into force |
| 2 February 2025 | General provisions (definitions, AI literacy) and the Article 5 prohibitions apply |
| 2 August 2025 | Obligations for general-purpose AI model providers start; member states establish competent authorities and governance structures (AI Office operational) |
| 2 August 2026 | The majority of the Act's rules come into force and enforcement starts, including Article 50 transparency obligations |
| 2 December 2026 | Grace period ends on the AI Omnibus's new Article 5 ban on AI systems generating non-consensual intimate imagery or child sexual abuse material, and on Article 50(2) watermarking readiness for existing generative systems |
| 2 August 2027 | Member states should have operational AI regulatory sandboxes |
| 2 December 2027 | Rules for high-risk AI systems in Annex III apply (moved from 2 August 2026 by the AI Omnibus) |
| 2 August 2028 | Rules for high-risk AI embedded in regulated products (Annex I) apply (moved from 2 August 2027 by the AI Omnibus) |
The Omnibus, plainly: the AI Omnibus entered into force on 27 July 2026, after political agreement in May 2026 and final Council approval in June 2026. It deferred the high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) while leaving the rest of the August 2026 milestone intact. Practical consequence: transparency obligations and EU AI Act compliance enforcement began on 2 August 2026; the heavy high-risk work now lands in December 2027.
Then the trap, which is the genuinely useful advice: a deferral is not a cancellation, and a conformity assessment for a high-risk system is measured in quarters, not weeks. Teams that read the deferral as permission to stop preparing will be the ones scrambling in late 2027.
Does the EU AI Act apply to companies outside the EU?
Yes, in defined circumstances. Article 2 reaches providers who place AI systems or GPAI models on the EU market regardless of where they are established, and it reaches providers and deployers in third countries where the system's output is used in the EU. A Bengaluru SaaS company with a single German customer using its AI feature is in scope. An Indian IT services firm building a high-risk system for a European client sits inside that client's supply chain even if it is not itself the provider.
The nuance nobody states: for most Indian companies, the Act arrives through a contract before it arrives through a regulator. Your European customer, facing its own obligations, pushes them down to you as contractual warranties. In practice, the first EU AI Act enforcement most Indian companies experience is a procurement questionnaire.
How Scaler Transformed Careers in Different Fields
Scaler learners achieved 2.5x salary growth with average post-Scaler CTC reaching ₹23L.
Google
Amazon
Microsoft
Flipkart
Adobe1200+ moreISO/IEC 42001: The Only One You Can Actually Be Certified Against
The verified facts: ISO/IEC 42001:2023, "Information technology: Artificial intelligence: Management system", was published in December 2023 as the first edition, by ISO and IEC through JTC 1/SC 42. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS), and it applies to organisations of any size that develop, provide or use AI-based products or services.
The conceptual barrier: a management system standard certifies processes, not products. ISO/IEC 42001 does not say your model is fair; it says your organisation runs a defined, documented, audited process for deciding whether your model is fair, with evidence the process was followed.
The fastest analogy for this audience: 42001 is to AI what ISO 27001 is to information security. Same Plan-Do-Check-Act structure, same Annex-control pattern, same accredited-certification-body model. Companies already certified to 27001 can often extend the existing management system instead of building one, which is a practical observation absent from competing pages. Most of an AIMS is, in effect, disciplined MLOps practices this kind of management system formalises with an audit trail.
Procurement dominance follows: it is the only framework in this comparison producing a certificate a customer's procurement team can verify. NIST adoption is a claim; 42001 certification is an audited fact. That asymmetry, not technical superiority, is why it gets budget in Indian IT services and SaaS while NIST stays informal.
What it does not do: certification does not establish EU AI Act conformity. It is strong supporting evidence and maps well onto several of the Act's requirements, but a certificate is not a conformity assessment. Conflating the two is a real and consequential mistake.
OECD AI Principles: The Layer Underneath the Others
The verified facts, from the OECD's own page: adopted in 2019 and updated in May 2024, with 47 adherents including the EU as of August 2026. Five value-based principles (inclusive growth and well-being; human rights and democratic values including fairness and privacy; transparency and explainability; robustness, security and safety; accountability) plus five recommendations addressed to policy makers.
Why a working engineer should care at all: the OECD's definition of an "AI system" is the definition the EU AI Act adopted, and the vocabulary of most national AI strategies traces back here. It is substrate, not a compliance obligation, and these AI governance principles show up inside every other framework on this page.
The differentiating fact, verified and absent from every competing page: India is not an OECD AI Principles adherent. The OECD's own list notes G20 members committed to the G20 AI Principles (derived from the OECD text) instead, India among them. Two sentences, and proof the page was researched rather than assembled.
AI Governance in India: DPDP, MeitY, RBI, and Why Companies Comply Anyway
The conclusion first, because it inverts what most readers assume: India has deliberately chosen not to pass a standalone AI law, existing statutes apply, and yet Indian companies are adopting AI governance frameworks at pace, because their customers require it, not because Indian regulators do. Everything below evidences AI governance in India under that thesis.
The DPDP Act 2023 and the DPDP Rules 2025
The Digital Personal Data Protection Act was enacted in 2023; the DPDP Rules were notified on 14 November 2025, introducing an eighteen-month period for phased compliance, which places the bulk of obligations in 2027. The exact rule-by-rule phase dates sit in the notified Rules; this page deliberately avoids quoting specific months without the gazette in hand.
Why does an AI article cover a data-protection law? Because DPDP (Digital Personal Data Protection) is the binding statute most AI systems in India actually touch. Training data containing personal data of Indian users sits inside its scope, including scraped or purchased data. Purpose limitation is the provision with the sharpest AI edge: personal data collected for one stated purpose cannot simply be repurposed as training data for an unrelated model. Inference logs and RAG corpora are routinely overlooked: a vector store of customer support transcripts holds personal data, and a prompt log capturing user inputs is a data store like any other. And erasure requests are operationally hard against a trained model; deleting a row is easy, unlearning it from weights is not, and pretending that problem is solved fools nobody.
Practical tip, the article's most useful single insight: maintain a record of what personal data flows into every AI system. That one artifact is the Map function of the NIST AI RMF, a documented requirement of an ISO/IEC 42001 AIMS, and your working DPDP compliance evidence, all at once. One record, three frameworks satisfied.
MeitY's India AI Governance Guidelines
MeitY released the India AI Governance Guidelines in November 2025 under the IndiaAI Mission (announcement), drafted by a high-level committee chaired by Prof. Balaraman Ravindran of IIT Madras. They comprise seven Sutras, six pillars, an action plan across short, medium and long horizons, and practical AI governance guidelines for industry, developers and regulators.
The seven Sutras, verbatim: Trust is the Foundation; People First; Innovation over Restraint; Fairness & Equity; Accountability; Understandable by Design; Safety, Resilience & Sustainability. The six pillars: Infrastructure; Capacity Building; Policy & Regulation; Risk Mitigation; Accountability; Institutions.
The quotable position, stated in the document itself: "a separate law to regulate AI is not needed given the current assessment of risks", with existing laws on information technology, data protection, consumer protection and the civil and criminal codes used to govern AI applications. The approach is "voluntary measures supported by techno-legal solutions", with an explicit note that some baseline measures may become mandatory as the industry matures. An AI policy India interpretation for the reader: there is no Indian equivalent of the EU AI Act and none is imminent by design; "no AI law" does not mean "no obligations", since DPDP, the IT Act and consumer protection law apply today; and the direction of travel is voluntary-now, mandatory-later, so governance capability built now is optionality, not compliance.
RBI's FREE-AI framework for financial services
The Reserve Bank of India constituted the Committee on FREE-AI (Framework for Responsible and Ethical Enablement of Artificial Intelligence) on 26 December 2024, chaired by Dr. Pushpak Bhattacharyya of IIT Bombay, following an announcement in the December 2024 Monetary Policy Statement. The committee's report, published on 13 August 2025, sets out seven Sutras, six strategic pillars (Infrastructure, Policy, Capacity, Governance, Protection, Assurance) and 26 actionable recommendations.
Status, stated precisely because several summaries get it wrong: these are committee recommendations to the RBI, not binding directions. For readers searching RBI AI guidelines, this framework is the document their compliance teams are reading, but nothing in it is yet a circular or master direction.
Why it belongs here: it is the clearest sectoral signal in India. BFSI already runs mature model-risk governance under RBI supervision, so AI governance is being folded into existing model-risk frameworks rather than built from scratch. And note the structural echo: MeitY's own document says its seven Sutras were adapted from the RBI FREE-AI Committee report. India's regulatory idiom is coherently, deliberately light-touch, one observation no competitor makes.
Turn Learning into Career Growth
The honest picture: export obligations, not domestic mandate
Lay the argument out cleanly. India has no binding, AI-specific law, and MeitY says one is not needed at present. Indian companies are nonetheless adopting NIST language and pursuing ISO/IEC 42001 at a visible pace. The driver is commercial, not regulatory: Indian IT services and SaaS companies sell to European and American enterprises, and those customers push their own obligations down the supply chain as contractual warranties and questionnaire items. Compliance arrives as a customer document, not a government notice.
GCCs are the sharpest case: a Hyderabad or Bengaluru capability centre inherits its parent's EU or US obligations wholesale, and the parent's compliance calendar becomes the GCC's calendar with no Indian regulatory trigger at all. Scaler's India AI workforce data tracks the roles this pressure is creating. The consequence for the reader: if you work at an Indian company, "what does Indian law require?" is usually the wrong first question. The right first question is "who are our customers, and what do their regulators require of them?"
Which AI Governance Framework Do You Actually Need?
Every competing page ends at "it depends." This one answers. Your obligations are set by where your users are, what your AI decides about them, and what your customers' contracts require, in that order. Company size matters far less than readers assume. An enterprise AI governance framework is mostly the row for IT services and GCCs below.
| If you are... | Binding on you | Worth adopting | Do first |
|---|---|---|---|
| Indian SaaS with EU customers | EU AI Act (market placement or EU-used output); DPDP for Indian user data | ISO/IEC 42001 once enterprise deals demand proof | Classify each AI feature against the risk tiers; most SaaS features are limited-risk, so Article 50 disclosure (live since 2 Aug 2026) is your immediate duty, not the 2027 high-risk work |
| IT services vendor building for overseas clients | Usually the client's obligations, inherited contractually; DPDP for Indian operations | ISO/IEC 42001: the highest-return investment here | Clarify your contractual position: provider, or component supplier to the client's provider? That decides who owns conformity assessment |
| Domestic-only Indian fintech or NBFC | DPDP Act and Rules; RBI's existing model-risk and outsourcing directions | RBI FREE-AI recommendations; NIST AI RMF as internal method | Fold AI systems into the model-risk governance you already run; do not build a parallel function |
| GCC of a US or EU parent | Whatever binds the parent, in practice | Parent's framework, adopted wholesale | Ask the parent's compliance team what they committed to; do not pick a framework independently |
| Early-stage startup | DPDP if you process Indian personal data; EU AI Act if you have EU users | None yet; NIST's Map function as a lightweight habit | Keep a one-page record per AI feature: what it does, what data trains it, who owns it, what happens on failure |
Row by row, directly. Indian SaaS selling to the EU: the deferral of high-risk obligations to December 2027 does not defer Article 50 transparency duties, which are live now; classify first, because most teams either over-estimate their tier and panic or under-estimate it and miss a disclosure duty. IT services vendor: ISO/IEC 42001 pays for itself in cleared security reviews; this is the one row where a certification is unambiguously right, because the credential is billable evidence in client audits. Domestic-only fintech: you are not free of obligations, they just arrive through RBI and DPDP rather than any AI law; one integrated framework, not two. GCC: alignment beats independent judgement, and divergence from the parent is the most common GCC audit finding. Early-stage startup: formal frameworks are premature; a startup that spends runway on ISO certification before product-market fit has made an expensive mistake. A one-page record costs an afternoon and covers most of a first enterprise questionnaire. Being willing to say "not yet" is exactly the credibility this page runs on.
How AI Governance Becomes Engineering Work
Every obligation in this article eventually becomes an artifact somebody has to build and maintain. Governance failures are usually documentation failures, not ethical ones: the team knew the model trained on stale data; nobody wrote it down, so nobody caught it. Five artifacts, what builds them, and who requires them. This is where AI model governance stops being a memo.
Model documentation
A record per model: intended use, out-of-scope uses, training data sources and dates, evaluation results with subgroup breakdowns, known limitations, and the owner. Model cards are the common format, required in substance by the EU AI Act's technical documentation duties for high-risk systems, NIST's Map and Measure functions, and ISO/IEC 42001's documented-information requirements.
Treat it as a versioned file in the model's repository, updated in the same pull request that changes the model; documentation outside version control goes stale within a quarter, and a stale model card is worse than none. Wiring it into the same pipeline that ships the model is exactly what CI/CD for machine learning is for.
Data lineage and provenance
Knowing where every training and retrieval dataset came from, under what licence or consent basis, when it was collected, and what has been derived from it. Required by the EU AI Act's data governance provisions, DPDP's purpose-limitation and erasure duties in the Indian context, and NIST's Map function. AI data governance lives or dies on this artifact.
The hard case is not the primary training set; it is the derived artifacts: embeddings in a vector store, cached retrieval chunks, fine-tuning sets assembled from production logs. Each is a copy of data whose provenance most teams cannot reconstruct after the fact. A team I worked with discovered their vector store held embeddings of customer support transcripts, personal data, no recorded consent basis, and had to rebuild ingestion around a lineage record. Build the record at ingestion; it cannot be reconstructed later. Readers new to pipeline structure can see where lineage capture belongs in how machine learning pipelines are structured.
Bias and robustness testing
Disaggregated evaluation across relevant subgroups, adversarial and edge-case testing, drift monitoring, and a documented record of what was and was not tested. Required by NIST's Measure function, the EU AI Act's accuracy and robustness requirements, and ISO/IEC 42001's impact assessment.
The engineering problem is usually that the protected attribute is not in the dataset, often because collecting it was itself a privacy decision. The standard mitigations (proxy analysis, targeted evaluation sets, external audit) all help and none is fully satisfactory; saying so plainly is more useful than pretending the tooling solved it.
Human oversight
Designing the point at which a person can meaningfully intervene, and making the interface support real intervention rather than nominal review. Required by the EU AI Act's human oversight requirements for high-risk systems and NIST's Govern and Manage functions.
The point that lands hardest with engineers: "a human reviews the output" is not oversight if that human sees 400 cases an hour with no information to disagree with. Genuine oversight needs context, time and authority to override; automation bias is a design problem, not a policy problem. Agentic AI governance compounds this: in multi-step agent systems the consequential decision may be a tool call three steps upstream of the visible output, so intervention points have to be designed against how agentic AI systems are architected, not against the final message.
Incident logging and post-market monitoring
Recording what the system did, retaining logs for the required period, detecting degradation in production, and running a defined procedure when something fails. Required by the EU AI Act's logging and post-market monitoring duties, NIST's Manage function, and ISO/IEC 42001's monitoring clauses.
The reassuring truth: most teams already have observability infrastructure and are simply not retaining the right fields for the right duration, so the governance requirement is usually a retention-policy and schema change, not a new system. The instrumentation detail maps closely onto AI observability for LLM systems.
Governance is not only the compliance team's job. Four of the five artifacts above (model documentation, lineage, evaluation, monitoring) are engineering deliverables, not policy documents, and the engineers who can produce them are the ones whose organisations pass audits. See what an AI engineering curriculum actually covers.
Common Mistakes When Adopting an AI Governance Framework
AI governance best practices inverted: the mistakes are more useful because they are specific. Roughly in order of frequency:
- Treating the frameworks as alternatives. They are complementary layers: a method (NIST), a proof (ISO/IEC 42001), a constraint (the EU AI Act).
- Classifying by technology instead of use case. "We use an LLM, so we are high-risk" is wrong; so is "it is only a chatbot, so nothing applies." Article 50 disclosure applies to chatbots today.
- Reading the Omnibus deferral as a cancellation. High-risk obligations moved to December 2027; conformity assessment lead times mean preparation cannot wait.
- Assuming no Indian AI law means no Indian obligations. DPDP, the IT Act and consumer protection law apply now.
- Governance as a document, not a process. A policy PDF nobody executes produces audit findings faster than no policy, because it is evidence of a process not followed.
- Confusing ISO/IEC 42001 certification with EU AI Act conformity. Supporting evidence, not a substitute.
- Buying a governance platform before defining the process. Tooling encodes decisions; if the decisions do not exist, the tool makes them for you.
- No named owner. The most reliable predictor of governance failure is a system nobody is accountable for; this is also the most common finding in a first-time AI audit.
Governance literacy is quietly becoming part of the standard AI engineering skill set rather than a separate specialism; the broader AI engineer roadmap now sits alongside it.
FAQs
What is an AI governance framework?
A structured set of principles, processes and controls defining how an organisation builds, tests, deploys and monitors AI systems: who is accountable, which risks must be assessed, what evidence is retained, and when a system must not ship. Examples include the NIST AI RMF and ISO/IEC 42001.
What are the main AI governance frameworks?
The NIST AI RMF (voluntary, US-issued), the EU AI Act (binding law), ISO/IEC 42001 (certifiable standard) and the OECD AI Principles (intergovernmental recommendation). In India, add the DPDP Act and Rules, MeitY's India AI Governance Guidelines and RBI's FREE-AI framework.
What is the difference between the NIST AI RMF and the EU AI Act?
The NIST AI RMF is voluntary guidance organised into four functions (Govern, Map, Measure, Manage) with no legal force. The EU AI Act is binding law that classifies systems by risk tier and imposes obligations accordingly. You choose to adopt NIST; the Act applies to you regardless.
Does the EU AI Act apply to companies outside the EU?
Yes, in defined circumstances. It reaches providers placing AI systems or general-purpose AI models on the EU market regardless of establishment, and providers and deployers in third countries where the system's output is used in the EU. Most Indian companies encounter it first through customer contracts.
When do the EU AI Act's high-risk rules actually apply?
2 December 2027 for Annex III stand-alone high-risk systems, and 2 August 2028 for Annex I high-risk AI embedded in regulated products; the AI Omnibus (in force since 27 July 2026) deferred both from their original 2026 and 2027 dates. Transparency obligations and general enforcement began on 2 August 2026.
Does India have an AI law?
No standalone AI law, and MeitY's India AI Governance Guidelines state that a separate AI law is not needed at present. Existing statutes (the DPDP Act 2023, the IT Act, consumer protection and the general civil and criminal codes) apply to AI systems today.
Is ISO 42001 mandatory?
No. ISO/IEC 42001:2023 is a voluntary standard. It is, however, the only framework here against which an organisation can be independently certified, which is why enterprise customers increasingly require it contractually even though no regulator does.
Who is responsible for AI governance in a company?
Accountability normally sits with a named executive owner, with the work split across engineering (documentation, testing, monitoring), legal and privacy (regulatory interpretation), and risk or audit (assurance). AI governance responsibilities with no named owner are the most common governance failure.
Do I need a certification to work in AI governance?
Not to apply governance practices as an engineer. Credentials matter mainly for dedicated compliance, audit and privacy roles, a separate question covered on our AI governance certifications page.
Conclusion
The map, not the detail: one binding law with global reach (the EU AI Act), one voluntary method worth adopting (the NIST AI RMF), one certifiable standard procurement actually recognises (ISO/IEC 42001), and in India, real obligations that arrive through data-protection law and customer contracts rather than an AI statute. For most Indian companies the practical question is not what Indian law requires, but what their customers' regulators require of their customers. Choose deliberately, and AI governance stops being a questionnaire you fear and becomes an artifact set you already maintain. Framework statuses and EU AI Act dates verified against primary sources on 21 August 2026.
