On August 2, 2025, the EU AI Act's obligations for general-purpose AI (GPAI) models became applicable — six months after the Article 5 prohibitions took effect, and roughly a year before the high-risk regime lands in August 2026. If your team ships AI features into the EU market, the grace period is functionally over. But here's what gets lost in the legal commentary: almost none of what regulators now demand is exotic. Risk management, technical documentation, logging, human oversight, secure development — these are disciplines mature engineering organizations already practice. The gap is that most teams have never applied them to AI systems in a way that produces evidence.

This article connects three layers usually discussed separately: the regulatory landscape (EU AI Act, NIST AI RMF, ISO/IEC 42001), how Microsoft operationalizes AI governance through its Responsible AI Standard and Security Development Lifecycle, and a concrete roadmap for teams that need audit-ready artifacts, not slide decks.

The regulatory landscape in 2025

EU AI Act: risk tiers and dates that matter

The AI Act sorts systems into four tiers. Unacceptable-risk systems — social scoring, manipulative techniques, most real-time biometric identification in public — are banned outright, enforceable since February 2, 2025. High-risk systems (Annex III: HR screening, credit scoring, education admissions, critical infrastructure, law enforcement) carry the full obligation stack: risk management (Article 9), data governance (Article 10), technical documentation (Annex IV), logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), accuracy/robustness/cybersecurity (Article 15), conformity assessment, and EU database registration. Limited-risk systems (chatbots, deepfake generators) owe transparency — users must know they're interacting with AI. Minimal-risk systems are largely unregulated.

The timeline to plan against: prohibitions and AI literacy obligations from February 2025; GPAI obligations and the governance structure (including the EU AI Office) from August 2025; high-risk obligations from August 2026. One late-2025 wrinkle: the Commission's "Digital Omnibus" proposal (November 2025) floated delaying some high-risk deadlines, but as of this writing nothing has changed the dates on the books — plan to August 2026 and treat any extension as found time.

Two points engineers consistently miss. First, the Act distinguishes providers (who place a system on the market) from deployers (who use it). Fine-tune or substantially modify a foundation model, or put your brand on a white-labeled system, and you can be reclassified as a provider — inheriting the full obligation stack. Second, GPAI providers — the model vendors — owe model-level documentation, a copyright policy, and a training-data summary, with extra duties (systemic-risk evaluation, red-teaming, incident tracking) above the 10^25 FLOP threshold. If you build on Azure OpenAI or similar, your vendor carries the GPAI duties; you carry the system-level duties for whatever you ship on top.

NIST AI RMF and ISO/IEC 42001: the voluntary layer

Where the AI Act is law, NIST's AI Risk Management Framework and ISO/IEC 42001 are the scaffolding that makes compliance operational.

NIST AI RMF 1.0 (January 2023) organizes AI risk work into four functions: Govern, Map, Measure, Manage. The July 2024 companion, NIST AI 600-1 (Generative AI Profile), adds twelve GAI-specific risks — confabulation, data privacy, information integrity, CBRN, and others — with suggested actions per risk. NIST also published SP 800-218A, a Secure Software Development Framework community profile for generative AI and dual-use foundation models. The RMF is voluntary and non-certifiable; its value is vocabulary. When your threat model says "we Mapped the context, Measured confabulation rates, and Manage with these mitigations," auditors understand you.

ISO/IEC 42001:2023 is the certifiable one: an AI management system (AIMS) standard in the same mold as ISO 27001, with an Annex A control set and a Statement of Applicability. Through 2025 it has become the default answer to enterprise procurement questionnaires — "are you ISO 42001 certified?" is the new "are you SOC 2?" The pragmatic stack most organizations land on: ISO 42001 for the management system, NIST AI RMF for day-to-day risk work, and AI Act Articles 9–15 as the requirements checklist for EU-facing high-risk systems.

How Microsoft maps governance to engineering

Microsoft is worth studying not because it's flawless but because it's one of the few organizations that has published the full pipeline from policy to pull request.

The Responsible AI Standard v2 translates six principles (fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability) into concrete requirements. The keystone artifact is the Impact Assessment — a mandatory document, drafted before development and updated through the lifecycle, covering intended uses, stakeholders, potential harms, and limitations. Sensitive-use cases (facial recognition, consequential decisions, children) trigger additional review gates.

On the security side, Microsoft's Security Development Lifecycle (SDL) has been extended for AI. SDL already mandated threat modeling, secure design review, and static/dynamic analysis; the AI-era additions include AI-specific threat modeling guidance from the AETHER engineering working group, AI red-teaming as a release gate for generative systems, and the open-source PyRIT (Python Risk Identification Toolkit) for automating red-team probes against LLM endpoints. Microsoft's Service Assurance documentation describes how these practices are applied to its own commercial AI services — effectively the company showing its homework to enterprise auditors.

The engineering-workflow mapping, condensed:

SDL/RAI practice Where it lives in your workflow
Impact Assessment Design doc template, required at feature kickoff
AI threat modeling Architecture review before first build
Data governance (lineage, consent, PII) Data pipeline CI checks, Purview classification
Red teaming / PyRIT probes Pre-release gate, plus scheduled runs in CI
Measurement (groundedness, safety evals) Eval harness in the build pipeline
Transparency note Shipped alongside the feature, versioned with it
Incident response for AI harms On-call runbooks, severity taxonomy extended to AI

Threat modeling for AI systems

Classic STRIDE still works on the infrastructure around a model — spoofed identities, tampered configs, exposed endpoints. What it doesn't cover is the model itself as an attack surface. Microsoft's "Threat Modeling AI/ML Systems" guidance and community practice (OWASP LLM Top 10, MITRE ATLAS) converge on the failure classes you actually need to model:

The practical move is layered modeling: STRIDE for the service architecture, then an AI-specific pass on the trust boundaries that only exist because a model is involved — every place untrusted content flows into a prompt, every tool the model can invoke, every place model output reaches downstream code without validation. Document the output the way SDL expects: a diagram, an enumerated threat list with mitigations and owners, and a residual-risk sign-off. That document is simultaneously an SDL deliverable, an ISO 42001 risk-treatment record, and raw material for the Article 9 risk management file. Write it once, cite it three times.

Documentation and transparency artifacts

Compliance runs on artifacts. The ones that matter:

A practical compliance roadmap

For a team shipping AI features in 2025–2026, in order:

  1. Inventory and classify (weeks 1–4). List every AI system and feature in production and in flight. Classify each against the AI Act tiers. For most product teams the answer is "limited-risk chatbot plus a copilot" — but find out now, not in a discovery request. Kill anything Article 5-adjacent.
  2. Assign roles (week 2). For each system, determine provider vs. deployer status. Name an accountable owner per system — the Act and ISO 42001 both assume named responsibility exists.
  3. Stand up the management skeleton (months 1–3). Adopt NIST AI RMF as your risk vocabulary; scope an ISO 42001 AIMS if certification justifies it. Define the AI policy: approved models, approved use cases, data classes that may never enter a prompt.
  4. Embed SDL-for-AI gates (months 2–4). Add impact assessment + AI threat model to your design review checklist. Add an eval gate (accuracy, groundedness, jailbreak resistance) to CI. Red-team before major releases — PyRIT is free and scriptable.
  5. Industrialize documentation (months 3–6). Template the Annex IV skeleton, transparency note, and impact assessment. Store them in version control next to the code they describe; regenerate on every model or prompt change.
  6. Wire monitoring and incident response (months 4–6). Log model inputs/outputs and versions. Extend your incident severity taxonomy to AI harms (hallucinated advice, PII leakage, unsafe content). The Act's serious-incident reporting duty has deadlines measured in days.
  7. Rehearse the audit (ongoing). Quarterly, pick one AI feature and try to produce its complete evidence pack in an afternoon. Where you can't, that's your backlog.

Conclusion

The EU AI Act, NIST AI RMF, and ISO/IEC 42001 are three lenses on the same demand: treat AI systems as engineered products with managed risk, documented behavior, and accountable owners. Microsoft's RAI Standard and SDL show what that looks like at scale — impact assessments at kickoff, threat models before build, red teams before release, transparency notes at ship. None of it requires new disciplines, just the deliberate application of old ones to a new kind of component. Start with the inventory; every other obligation hangs off knowing what you run.

Further reading