AI Governance Frameworks: Regulating Advanced AI

Compute credits and a compliance question

In March 2024 the Union Cabinet approved the IndiaAI Mission with an outlay of ₹10,372 crore, most of it earmarked for empanelling GPU capacity so that Indian startups and research labs could train large models on domestically subsidised compute instead of renting it abroad. Suppose one of those labs succeeds: it trains a genuinely capable general-purpose model on the empanelled cluster and opens an API, including to customers in Germany and France. Nothing in Indian law stops it. But the instant that model is placed on the EU market, a question activates automatically that has nothing to do with what the model says or does: how many floating-point operations did it take to train? Cross a specific number — 10²⁵ — and the lab has stepped from one legal category into another, owing fresh evaluations and disclosures to a regulator in Brussels who has not read a single output the model has produced.

This is what "AI governance" concretely means in 2026: not a philosophical stance for or against AI, but a set of checkable numeric and procedural gates that determine which paperwork, evaluations, and disclosures a given model owes to which government. This chapter builds that machinery from first principles, works the compute arithmetic a compliance engineer at that lab would actually run, and maps the current landscape of hard law, soft law, and self-governance a frontier lab — Indian or otherwise — navigates simultaneously.

Why govern AI at all: three failure modes, four instrument types

The standard economic case for regulating any technology rests on three failure modes markets do not price correctly on their own. First, negative externalities: a biased hiring model imposes costs on rejected applicants who were never a party to the contract between the employer and the AI vendor. Second, information asymmetry: a bank buying a credit-scoring model cannot itself verify the vendor's claims about bias testing or robustness, and a citizen subject to an automated decision has even less visibility. Third, tail risk that insurance and liability markets have not caught up to: a model with meaningful cyberoffensive or biological-uplift capability creates diffuse, hard-to-price risk to people who never interacted with the lab that built it. Regulators reach for observable proxies precisely because the thing they actually care about — how much harm a model will eventually cause, to whom — is unknowable before deployment and often unmeasurable after it.

Four instrument types now operate on the same lab at once, layered rather than exclusive:

Hard law — a binding statute with penalties. The EU AI Act (Regulation (EU) 2024/1689, in force since 1 August 2024) is the fullest example: violating the prohibited-practices tier carries fines up to €35 million or 7% of global annual turnover, whichever is higher. Soft law — government-issued guidance with no direct penalty, but real indirect leverage through procurement rules, litigation, and insurance underwriting. The U.S. NIST AI Risk Management Framework (RMF 1.0, published January 2023) is voluntary on paper and increasingly load-bearing in practice. Self-governance — commitments a firm writes for itself, enforced only by reputation and investor pressure, such as Anthropic's Responsible Scaling Policy. Multilateral coordination — declarations that bind no one directly but seed the vocabulary later hard law borrows, such as the Bletchley Declaration signed at the UK's first AI Safety Summit on 1 November 2023 by 28 countries plus the EU, including the US, China, and India.

The EU AI Act: risk tiers plus a compute gate

The Act's headline structure sorts every AI system into one of four risk tiers by application context, not by how sophisticated the underlying model is. Unacceptable risk (Article 5) is banned outright: government social-scoring systems, real-time remote biometric identification in public spaces for law enforcement (with narrow carve-outs), and manipulative techniques that materially distort behaviour to a person's detriment. High-risk (Annex III) covers systems used in employment decisions, creditworthiness assessment, law enforcement, migration, education, and critical infrastructure — these are legal to deploy but require a documented risk-management system, data governance controls, human-oversight mechanisms, logging, and a conformity assessment before market placement. Limited risk (Article 50) is a transparency tier: chatbots must disclose they are AI, synthetic audio/video must be labelled as a deepfake. Minimal risk covers everything else — spam filters, AI opponents in video games — with no obligation at all.

Layered on top of this, orthogonally, sits a separate track for general-purpose AI (GPAI) — foundation models trained on broad data and adaptable across many downstream tasks. Every GPAI model placed on the EU market owes baseline duties under Article 53 regardless of which tier a given deployment falls into: technical documentation for downstream integrators, a summary of training content sufficient for rights-holders to check for copyright infringement, and a published copyright-compliance policy. If a GPAI model's training compute additionally exceeds a presumptive threshold of 10²⁵ floating-point operations (Article 51(1)(a)), it is presumed to carry "systemic risk," which stacks the heavier Article 55 duties on top: adversarial capability evaluation and red-teaming, tracking and reporting serious incidents to the newly created EU AI Office, adequate cybersecurity safeguards, and reporting of compute and energy consumption. The Commission can also designate a model systemic-risk by a separate capability judgement below the FLOPs line, but the compute figure is the number labs actually plan against, because it is the one they can calculate themselves before Brussels ever evaluates the model. The diagram below shows both tracks — the use-case pyramid and the compute-triggered GPAI gate — as they jointly determine what a specific model deployment owes.

Worked example: does a training run cross the line?

Return to the IndiaAI-Mission-scale lab from the opening scenario. It reserves 8,192 H100 GPUs on its empanelled cluster and runs a 90-day pre-training job. NVIDIA's published H100 SXM5 specification lists 989 teraFLOP/s of dense (no-sparsity) BF16 tensor throughput per GPU — the figure that matters here, since sparsity acceleration is not typically exploitable during dense pre-training. No cluster runs at 100% of that peak: kernel-launch overhead, communication stalls during gradient all-reduce, and pipeline bubbles all eat into it. Chowdhery et al. (2022), reporting Google's PaLM training run, measured 46.2% model FLOPs utilization (MFU) at 540-billion-parameter scale on TPU v4 pods — the widely cited empirical benchmark for a well-engineered large training run. This lab, still tuning its pipeline-parallel implementation, hits a more conservative 40%.

gpus = 8192
peak_flops_per_gpu = 989e12   # H100 SXM5, dense BF16 tensor throughput
mfu = 0.40                    # achieved model FLOPs utilization
days = 90
seconds = days * 24 * 3600    # 7,776,000 s

total_flops = gpus * peak_flops_per_gpu * mfu * seconds
print(f"{total_flops:.3e} FLOPs")
# 2.520e+25 FLOPs

Tracing it by hand: 8,192 × 989 × 10¹² = 8.101888 × 10¹⁸ FLOP/s of aggregate peak throughput. At 40% MFU that is 3.2407552 × 10¹⁸ effective FLOP/s. Multiplied by 7,776,000 seconds of wall-clock training: 3.2407552 × 7.776 = 25.2001... , so the run consumes 2.5200 × 10²⁵ FLOPs — matching the code's printed output exactly. That number sits above the EU AI Act's 10²⁵ systemic-risk gate, so the moment this model is offered to EU users, Article 55 duties attach: red-teaming, incident reporting, cybersecurity safeguards, compute reporting. It sits below the old U.S. EO 14110 threshold of 10²⁶ FLOPs, so the same run would not have triggered the American federal reporting duty even before that duty was rescinded on 20 January 2025. One training run, two regulatory outcomes, decided entirely by which market the API serves — which is exactly why "where do you plan to sell this" is now a compute-governance question and not just a market-access one.

Soft law and self-governance: NIST, Responsible Scaling Policies, Bletchley

The NIST AI Risk Management Framework organises risk management into four continuous functions rather than a fixed checklist: GOVERN (establish organisational policy and accountability before any model is built), MAP (identify the risks specific to a given deployment context), MEASURE (quantify those risks with concrete metrics and testing), and MANAGE (allocate resources to the highest-priority risks and monitor after deployment). Nothing in the RMF is enforceable — a firm that ignores it faces no fine — yet it has become the reference architecture that U.S. federal agencies point to in procurement contracts, and that insurers and plaintiffs' lawyers increasingly cite as the baseline for what "reasonable care" looks like in a negligence claim. Soft law changes behaviour through indirect channels even with zero statutory teeth.

Self-governance operates one level further from any state actor. Anthropic's Responsible Scaling Policy, first published in September 2023, defines AI Safety Levels (ASL) loosely modelled on biosafety-lab BSL tiers: ASL-2 describes today's frontier models, which show early dangerous capabilities but are not yet reliably useful for catastrophic misuse; ASL-3 describes models that meaningfully increase catastrophic-misuse risk and require hardened deployment and security measures before release; higher levels are reserved for capabilities the policy commits to pause scaling on until adequate safeguards exist. OpenAI's Preparedness Framework and Google DeepMind's Frontier Safety Framework are structurally similar capability-threshold commitments from other labs. None of this is legally binding — the enforcement mechanism is reputational and investor pressure — but regulators increasingly cite RSP-style evaluation gates as evidence of what due diligence should look like when drafting the next round of hard law, which is how self-governance today becomes statutory language tomorrow.

Above both sits multilateral coordination. The Bletchley Declaration, signed 1 November 2023 by 28 countries plus the EU — including the US, China, the UK, and India — at the UK's first AI Safety Summit, committed signatories to identify and monitor risks from "frontier AI" and build shared scientific understanding. It binds no one to anything specific, but it seeded the AI Safety Institute network (UK AISI, US AISI, and counterparts established since) that now runs pre-deployment capability evaluations frontier labs voluntarily submit models to, and its vocabulary — "frontier AI," "dangerous capabilities" — now appears in the recitals of hard law drafted afterward.

India's posture and the Brussels effect

On 1 March 2024, MeitY issued an advisory requiring platforms to obtain government permission before deploying "under-tested/unreliable" AI models to Indian users and to label their outputs accordingly. The vagueness of "under-tested" and the friction of a prior-permission requirement drew immediate pushback from startups and investors, and MeitY revised the advisory on 15 March — two weeks later — dropping the approval requirement and replacing it with a due-diligence and labelling obligation folded into the existing IT Rules consent-and-notice framework. The episode is a compact case study in what soft, advisory-based governance can and cannot do: it can be issued and reversed inside a fortnight with no legislative process, which is its structural advantage in a fast-moving field, and it can be reversed just as fast by the next minister or the next lobbying push, which is its structural weakness against the EU's slower but harder-to-unwind statutory architecture. Since then, India's sustained policy attention has concentrated more on capacity — the IndiaAI Mission's compute subsidies, foundation-model grants, and safety institute funding — than on a standalone binding AI statute, placing India's operative stance closer to the United States' historical sectoral, light-touch model (rules layered onto existing regulators like the RBI for fintech AI) than to the EU's single omnibus regulation.

That does not insulate an Indian lab from the EU AI Act. An Indian startup that never plans to sell into Europe may still end up designing to EU AI Act tiers, for the same reason GDPR became a de facto global privacy baseline even for firms with no EU operations (Bradford, 2012, "The Brussels Effect"): maintaining two divergent product configurations — one EU-compliant, one lighter domestic build — costs more engineering and compliance overhead than building a single global baseline to the stricter standard, and any B2B customer in an EU-regulated sector, such as a European bank buying an Indian-built fraud-detection model, will contractually demand EU AI Act conformity regardless of where the vendor is headquartered. The IndiaAI-Mission-trained model from the opening scenario does not need an Indian statute to answer its compliance question — it needs to know its own FLOPs count and its customers' addresses.

Common misconception

Students who first meet "risk tiers" tend to assume the EU AI Act grades how smart or capable a model is, banning the most advanced systems and leaving simple ones alone. That is backwards. The four risk tiers are keyed to application context, not model capability: a basic logistic-regression résumé-scoring model trained on a company's past hiring outcomes is Annex III high-risk regardless of how unsophisticated it is, while a frontier multimodal model generating birthday poems sits in the lightly regulated limited-risk tier. Capability enters only through the separate, orthogonal GPAI compute gate, which applies specifically to general-purpose foundation models and stacks Article 55 duties on top of whichever use-case tier a given deployment of that model also falls into. They are two independent axes — one asking "what is this AI system being used for," the other asking "how much compute went into building the underlying model" — not one capability dial that a regulator turns up or down.

Active recall

Attempt each question before reading its answer.

1. Under the EU AI Act, is a basic logistic-regression model used by an HR team to score and auto-reject résumés ranked higher-risk or lower-risk than a frontier multimodal model used for casual creative writing? Why?
2. A lab reconfigures its base-case run (8,192 H100s, 90 days, 40% MFU, computed above as 2.52 × 10²⁵ FLOPs) to instead use 16,384 H100s for 60 days at 35% MFU. Does the new run cross the EU's 10²⁵ FLOPs systemic-risk gate? Does it cross the former U.S. EO 14110 threshold of 10²⁶ FLOPs?
3. Using that same 16,384-GPU, 35%-MFU configuration, roughly how many days of continuous training would be needed to cross 10²⁶ FLOPs?
4. Why do policymakers use training compute (FLOPs) as a regulatory trigger instead of directly measuring how dangerous a model's outputs turn out to be?
5. What distinguishes "hard law" from "soft law," using the EU AI Act and the NIST AI RMF as the two examples — and how can a purely voluntary framework still change company behaviour with no penalty attached?
6. Why might an Indian AI startup that never plans to sell into the EU still end up designing its systems to EU AI Act risk-tier standards?

Answers

1. The résumé-scoring model is higher-risk — it falls under Annex III as an employment-related decision system regardless of its technical simplicity, because the Act's tiering logic keys off application context, not model sophistication. The creative-writing foundation model sits in the limited-risk transparency tier (it must disclose that its output is AI-generated) unless its training compute separately crosses the GPAI systemic-risk gate, in which case it also picks up Article 55 duties — a second, independent classification, not a promotion within the same tier.

2. Aggregate peak throughput: 16,384 × 989 × 10¹² = 1.6203776 × 10¹⁹ FLOP/s. At 35% MFU: 5.6713216 × 10¹⁸ effective FLOP/s. Over 60 days (5,184,000 s): 5.6713216 × 5.184 × 10²⁴ ≈ 2.9400 × 10²⁵ FLOPs. That crosses the EU's 10²⁵ gate (yes, systemic-risk duties apply) but does not cross the former U.S. 10²⁶ threshold (no). Doubling the GPU count while cutting both the duration and the utilization still leaves the run on the EU side of the line and the U.S. side of the (now-defunct) line — the same split as the base case, despite every input parameter changing.

3. Solve 5.6713216 × 10¹⁸ × t = 10²⁶ for t in seconds: t = 10²⁶ / 5.6713216 × 10¹⁸ ≈ 1.7632 × 10⁷ seconds, which is about 204 days (roughly 6.8 months) of continuous training at that configuration.

4. Compute is measurable before deployment — it can be read off cloud-billing records or cluster logs the moment training finishes, unlike downstream harm, which is often unknown until after a model has already shipped and, in the worst cases, after harm has already occurred. Sastry et al. (2024), "Computing Power and the Governance of AI," make this case explicitly: compute correlates empirically with capability gains via known scaling laws and is harder to misreport than a lab's own capability claims. The proxy is imperfect — algorithmic efficiency improvements let a smaller, cheaper training run match a larger one's capability, which is why thresholds need periodic recalibration — but it is the most auditable ex-ante signal regulators currently have.

5. Hard law (the EU AI Act) carries direct statutory penalties — up to €35 million or 7% of global turnover for the worst violations — enforced by a designated authority. Soft law (the NIST AI RMF) carries no penalty for non-adoption; it changes behaviour indirectly, by becoming the standard federal procurement contracts require, the baseline insurers price policies against, and the yardstick plaintiffs' lawyers invoke to argue a company fell short of "reasonable care" in a negligence suit — voluntary today, functionally load-bearing tomorrow.

6. Maintaining two separate product builds — one EU-compliant, one lighter for the domestic market — costs more in engineering and compliance overhead than building a single global baseline to the stricter standard once. B2B customers in EU-regulated sectors will also contractually require EU AI Act conformity from any vendor, Indian or otherwise, before buying the model. This mirrors the mechanism that made GDPR a de facto global privacy standard (the "Brussels effect") even for companies with no EU footprint: market size, not jurisdiction, sets the ceiling.

Think About It

Think about this: How would you explain ai governance frameworks: regulating advanced ai to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.