Frontier Governance Framework
Published February 2026 · Printed in the footer of all 16 pages, and as the second entry in the Appendix II change log: "February 2026 - One year update following finalization of the EU Code of Practice for General Purpose AI, NY RAISE Act and CA Transparency in Frontier Artificial Intelligence Act".
Not law. This is a company's own public position on AI regulation. It is not law, and it carries no legal force.
What it argues for
This is the governance regime Microsoft holds itself to for its own most capable models, and it is written so that the regime tracks law rather than sitting beside it. It says its genesis is "the voluntary Frontier AI Safety Commitments that Microsoft and fifteen other AI labs made in May 2024," and it confines itself to capabilities that "could be misused to threaten national security or pose at-scale public safety risks," leaving everything else — bias, discrimination, culturally contextual harms — to Microsoft's broader AI governance program. The mechanism is a two-stage gate: a cheap "leading indicator" screen on general-purpose benchmarks, run at four points from pre-training through pre-deployment and repeated at least every six months, which triggers a "deeper capability assessment" only for models showing frontier capabilities; that assessment classifies each tracked capability as low, medium, high or critical, and high/critical models cannot ship without further mitigation. The scope is set explicitly by statute — the screen runs on "any model that is in scope for frontier model requirements under applicable laws, such as the EU AI Act, California's Transparency in Frontier AI Act (TFAIA), and New York's Responsible AI Safety and Education (RAISE) Act." On what regulation itself should look like, the document argues for an outcome-oriented, proportional, evidence-based regime rather than prescriptive rules: it "adopts an outcome-oriented approach to facilitate flexibility and innovation in AI risk management," uses deliberately qualitative rather than numeric capability thresholds "as they offer important flexibility," and presses governments toward holistic assessment that counts system-level mitigations and societal factors, not just model capability — "This type of holistic assessment will be needed if countries are to meaningfully calibrate risk thresholds and related governance requirements." It also carries a hard stop: "If, during the implementation of this framework, we identify a risk we cannot sufficiently mitigate, we will pause development and deployment until the point at which mitigation practices evolve to meet the risk."
Stated positions (13)
- Tracks five high-risk capabilities: CBRN weapons, offensive cyberoperations, advanced autonomy, and — added in this February 2026 update — loss of control and harmful manipulation. Everything not threatening national security or at-scale public safety is explicitly pushed out of this framework and into Microsoft's general AI governance program.
- Scope is defined by law, not by Microsoft: the leading-indicator assessment runs on "any model that is in scope for frontier model requirements under applicable laws, such as the EU AI Act, California's Transparency in Frontier AI Act (TFAIA), and New York's Responsible AI Safety and Education (RAISE) Act," plus substantially fine-tuned first- or third-party models where fine-tuning compute exceeds 1/3 of base-model compute (defaulting to 1/3 of 10^25 FLOPs when the base is unknown).
- Prefers qualitative capability thresholds over numeric ones — low/medium/high/critical per capability — "as they offer important flexibility across different models and contexts at a time of nascent and evolving understanding of frontier AI risk assessment and management practice."
- Commits to a pause: "If, during the implementation of this framework, we identify a risk we cannot sufficiently mitigate, we will pause development and deployment until the point at which mitigation practices evolve to meet the risk." A post-mitigation re-evaluation must land the model back at low or medium before deployment.
- Two-stage screening cadence: leading-indicator assessment during pre-training, after pre-training, after post-training and prior to deployment, repeated at least every six months; deeper assessment only for models showing frontier capabilities, and repeated on material changes to the deployed model's risk profile.
- Capability elicitation is required, not optional — evaluations must fine-tune, prompt-optimise, scaffold in multi-agent setups and connect tools to maximise the tracked capability, with elicitation resources extrapolated to those available to the relevant threat actors.
- Third-party evaluation is conditional, not guaranteed: Microsoft "engage[s] qualified third parties to conduct evaluations in ways that are appropriate to the risk profile of the model," with the decision made by internal experts independent of the model development team, and discloses the extent of third-party involvement "where applicable."
- Security scales with risk, on an explicitly full-stack argument that Microsoft owns the infrastructure: baseline protection for anything triggering the screen; high-risk models get restricted weight access, encrypted weights, defence in depth and adversarial security red teaming against weight theft; critical-risk models would need hardened tamper-resistant workstations and "physical bandwidth limitations between devices or networks containing weights and the outside world" — and it concedes "further work and investment are needed" before critical-level security is actually adequate.
- Deployment authority is named and internal: Executive Officers responsible for Microsoft's AI governance program (or delegates) approve a three-part case — adequately mitigated to low/medium, marginal benefits outweigh residual risk, and deployable securely and trustworthily. The framework is subject to independent internal audit and board oversight, with anonymous employee reporting and anti-retaliation protection.
- Transparency is bounded rather than absolute: capability, evaluation and risk-classification information "will be shared publicly, with care taken to minimize information hazards... and to protect commercially sensitive information," and Microsoft will report on tracked high-risk capabilities "as required by regulation and as appropriate to effectively manage frontier risks."
- Update discipline is a public commitment: an explicit review at least every twelve months, all updates reviewed by Microsoft's Chief Responsible AI Officer before adoption, and "All material revisions will be made public within 30 days of adoption." The Feb 2026 update also "adjust[ed] the update cadence to align with regulatory obligations."
- Defers to external standards rather than proposing its own regulator: NIST AI RMF (govern/map/measure/manage), ISO/IEC 42001, ISO 27001, SOC 2, NIST SP 800-53 and 800-218, the RAND security-level framework, and Frontier Model Forum technical reports on risk taxonomy and thresholds.
- Admits an open gap: the two newly added capabilities have no published thresholds. Appendix I says only that Microsoft is "studying and progressing methods" for loss of control and harmful manipulation and is still "setting appropriate risk acceptance criteria" — so three of five tracked capabilities have concrete four-level thresholds and two do not.
About this document
A 16-page PDF headed "Frontier Governance Framework", footer-dated February 2026 and issued in Microsoft's corporate name. No individual signs it and no author is named, though it assigns decisions to unnamed "Executive Officers responsible for Microsoft's AI governance program" and reserves review of any change to the Chief Responsible AI Officer. It is the second version: Appendix II is a two-row change log recording the February 2025 original and this "one year update following finalization of the EU Code of Practice for General Purpose AI (CoP), NY RAISE Act and CA Transparency in Frontier Artificial Intelligence Act". After a contents page it runs six numbered sections — evidence-based management of frontier risk; capabilities and risks; evaluation and assessment; mitigations; governance; collaboration and continuous learning — followed by Appendix I, which holds one table per capability setting low, medium, high and critical thresholds against deployment requirements, and Appendix II. Five "tracked high-risk capabilities" are named: CBRN weapons, offensive cyberoperations, advanced autonomy, loss of control and harmful manipulation. The last two are new in this version and carry prose placeholders rather than threshold tables. The text is almost entirely self-directed, describing Microsoft's own screening, testing, security tiers, sign-off and publication practice against external standards (NIST SP 800-53 and 800-218, SOC 2, ISO/IEC 42001, the NIST AI Risk Management Framework, the RAND security levels, Frontier Model Forum reports). It asks little of anyone else, beyond collaboration on evaluation science and a note that holistic assessment is needed "if countries are to meaningfully calibrate risk thresholds and related governance requirements".
How this sits against AI law
Each stance compared with what EU and US instruments actually require. Where no instrument addresses a theme, that gap is shown rather than hidden.
Scope and update cadence pegged to regulation
Microsoft runs its leading-indicator screen on any model in scope for frontier requirements under applicable law — naming the EU AI Act, California's TFAIA and New York's RAISE Act — plus substantial fine-tunes using more than a third of base-model compute. It reviews the framework at least every twelve months and publishes material revisions within 30 days of adoption.
Article 51(2) presumes a general-purpose AI model has high-impact capabilities, and so systemic risk, once cumulative training compute exceeds 10^25 floating point operations — the trigger Microsoft adopts, including as the one-third default where a third party's base-model compute is unknown.
SB 53 catches "large frontier developers" above 10^26 FLOPs and $500 million in revenue and requires any change to a published framework to be republished within 30 days with a justification — the same 30-day clock Microsoft writes into its own update rule.
Pre-deployment evaluation and independent assessment
Models that trip the leading-indicator screen undergo a deeper capability assessment with adversarial testing and deliberate capability elicitation. Qualified third parties are engaged "in ways that are appropriate to the risk profile of the model", with that call made by internal experts who are independent of the model development team.
Article 55(1)(a) requires model evaluation under standardised, state-of-the-art protocols "including conducting and documenting adversarial testing of the model", while leaving the choice between internal and independent external testing to the provider.
Illinois SB 315 makes an annual independent third-party safety audit compulsory for large frontier developers, where Microsoft keeps external evaluation discretionary and decides internally when to commission it.
Security of model weights and infrastructure
Any model that triggers the screen receives baseline protection, with controls scaling at high risk (restricted weight access, encrypted weights, defence in depth, third-party security red teaming) and at critical risk (hardened tamper-resistant workstations, physical bandwidth limits). The framework benchmarks itself against the RAND security levels and NIST standards.
Article 55(1)(d) demands only "an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model", naming no tiers, controls or benchmark framework.
SB 53 requires a large frontier developer's published framework to describe the cybersecurity practices it uses to secure unreleased model weights against unauthorised access, modification or transfer.
Public transparency about capabilities and risk classification
Microsoft says information about a model's capabilities and limitations, the relevant evaluations and its risk classification will be shared publicly, with care taken to minimise information hazards and protect commercially sensitive information, and that it will report on tracked high-risk capabilities "as required by regulation".
Article 53 requires technical documentation for the AI Office and for downstream providers plus one public artefact — a sufficiently detailed summary of training content — but nothing in the Act obliges a provider to publish evaluation results or a model's risk rating.
SB 53 requires a transparency report published before or concurrent with deployment, and for large frontier developers it must summarise the catastrophic-risk assessments carried out and the results of those assessments.
Incident reporting to authorities
Microsoft commits to channels for employees, customers and external parties to report concerns and, where serious or critical incidents that may pose public safety or national security risks are identified, to investigate and "provide reports to regulatory authorities and impacted customers as appropriate". No recipient and no deadline are named.
Article 55(1)(c) requires providers to keep track of, document and report serious incidents and possible corrective measures "without undue delay" to the AI Office and, as appropriate, to national competent authorities — a named recipient and a clock the framework does not restate.
California's SB 53, which is in force, sets 15 days for reporting a qualifying safety incident, or 24 hours where there is imminent risk of death or serious physical injury. New York's 2026 Frontier Model Transparency and Safety Act will add a 72-hour route to state authorities when it takes effect on 1 January 2027.
Codes of practice as the route to compliance
The framework was rewritten specifically following finalisation of the EU Code of Practice for General Purpose AI, and Microsoft undertakes to highlight how it aligns the framework and the products it covers with international, national and industry consensus best practices and standards.
Articles 55(2) and 56 make adherence to an approved code of practice the designated way for a systemic-risk provider to demonstrate compliance until a harmonised standard is published; a provider adhering to neither must demonstrate alternative adequate means of compliance to the Commission.
No US instrument offers a code-of-practice or collective-standard route to compliance — California, New York and Illinois each require the developer to write, publish and stand behind its own framework instead.
Loss of control and harmful manipulation
This version adds loss of control and harmful manipulation to the tracked high-risk capabilities, but Appendix I gives neither a threshold table. Microsoft states it is researching approaches to evaluating models for both in a pre-deployment context and is still setting appropriate risk acceptance criteria.
Article 55(1)(b) requires a systemic-risk provider to assess and mitigate systemic risks now rather than to research a method for doing so later, and Article 51 leaves no carve-out for capabilities a provider has not yet learned to measure.
The RAISE Act's definition of "critical harm" expressly covers a model that "acts with no meaningful human intervention" in ways that would be criminal if done by a human, so a safety protocol with no acceptance criterion for loss of control leaves the statute's core case unaddressed.
Microsoft has written a compliance document rather than an advocacy one: on scope, thresholds, weight security and public reporting it tracks California's SB 53 almost clause for clause, down to the 30-day republication clock, and where it exceeds the law it exceeds the EU AI Act, whose general-purpose model duties are drafted as bare outcomes rather than tiers or named controls. The soft spots are the enforceable edges — on incident reporting, and on the two capabilities added this year, the framework commits to less precision than either the EU's "without undue delay" to the AI Office or the 72-hour and 15-day state clocks. US federal law is absent from the picture entirely: EO 14179 revoked EO 14110 and imposes nothing on private developers, and America's AI Action Plan is recommendation rather than obligation, so every binding US requirement Microsoft is writing to comes from three states.
Source
https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/Frontier-Governance-Framework-Feb-2026.pdf- Date on the page:
- February 2026
- Source checked:
- opened and confirmed on 2026-09-18