TL;DR

AI made compliance faster — automated evidence collection, continuous control monitoring, audit prep that used to take weeks now takes days. But the same AI systems doing that work introduced a standards stack of their own: the EU AI Act, NIST’s AI RMF, ISO/IEC 42001. Large organizations don’t get to choose between their existing frameworks (SOC 2, GDPR, FedRAMP) and this new one — they now run both, and the new one governs the tool that’s helping run the old one.

Originally published at portfolio.hagzag.com.

The Assistant That Saw Too Much

A compliance team wires an AI assistant into their evidence pipeline — pull the latest access logs, summarize control exceptions, draft the auditor response. It works. It works well enough that within a quarter it’s touching ticket systems, config repos, and production logs directly, because that’s where the evidence lives.

Then someone asks the obvious question during a review: what exactly does this thing have access to, and who’s watching it? The logs it’s summarizing contain employee names, customer identifiers, sometimes health or financial data depending on the system. The AI assistant built to prove the organization is compliant is now, itself, a system that needs to be proven compliant. That’s the part the roadmap didn’t have a line item for.

The Standards AI Actually Introduced

This isn’t a hypothetical regulatory future. Three frameworks already exist, at different levels of enforceability, and each one assumes the AI system is the thing being regulated — not just the tool doing the regulating.

EU AI Act. The EU AI Act classifies AI systems by risk tier and attaches real penalties to that classification: prohibited-practice violations run up to €35 million or 7% of global annual turnover, whichever is higher, and violations of high-risk system obligations run up to €15 million or 3% of turnover. It also has extraterritorial reach — a non-EU provider whose AI system is used within the EU is exposed to the same enforcement. For a compliance-adjacent AI tool with access to production and customer data, “high-risk” classification is a real possibility, not an edge case.

NIST AI Risk Management Framework. Voluntary, U.S.-government-issued, and increasingly the de facto baseline procurement teams ask about even outside government contracts. It structures AI governance around four functions — govern, map, measure, manage — and it’s the closest thing the industry has to a shared vocabulary for “how do we actually assess an AI system’s risk” before the EU AI Act’s enforcement infrastructure fully matures.

ISO/IEC 42001. The first certifiable standard for an AI Management System (AIMS) — the AI-governance equivalent of what ISO 27001 did for information security. It’s structured for organizations that provide or use AI-based products, which matters: you don’t have to be building models to be in scope, you just have to be running them against production data.

None of these replace GDPR. Automated decision-making under Article 22 was already a live enforcement area before any of this, and an AI system making or influencing decisions about people — hiring, credit, access — inherits that obligation directly.

What Large Organizations Actually Have to Do

Reading the frameworks is the easy part. Implementing them inside an org that already has a SOC 2 program, a security team, and now an AI assistant embedded in half its workflows is where it gets real.

  • Inventory AI systems and classify by risk tier first. The same instinct that drives FedRAMP scoping — knowing exactly which systems touch what data before you write a single control — applies here. You can’t govern what you haven’t listed, and most orgs discover the list is longer than IT thought, because business units adopted AI tools faster than procurement tracked them.
  • Extend existing GRC programs instead of building a parallel one. Treating “AI compliance” as a separate initiative from your SOC 2 or ISO 27001 program creates duplicate evidence requests and duplicate audit fatigue. The controls overlap more than they diverge — access governance, change management, incident response — so map AI-specific requirements onto the control framework you already have, and add the delta.
  • Put real access governance around AI agents touching production or PII. Least privilege, scoped credentials, audit trails on what the agent read and wrote, and a human-in-the-loop gate before anything irreversible happens. An AI assistant with standing production access is a bigger blast radius than most service accounts get, and it usually got there faster and with less review.
  • Expect AI governance to show up in procurement, not just regulation. Enterprise vendor risk assessments increasingly ask what AI governance framework you follow before they’ll sign. That’s a commercial consequence, not a regulatory one, and it’s already showing up in RFPs.

What Actually Goes Wrong

The most common failure isn’t ignorance of the frameworks — it’s treating AI compliance as a checkbox bolted onto the SOC 2 renewal instead of a first-class control domain with its own owner. A team adds “AI governance” as a paragraph in the existing security policy, doesn’t reclassify which systems are in scope, and doesn’t touch access controls on the AI tools already running in production. Six months later an auditor — or worse, an incident — asks what data the AI assistant can see, and the honest answer is “we’re not entirely sure.” That gap is exactly what ISO/IEC 42001 and the EU AI Act’s risk-tiering are designed to close, and it only closes if someone owns it before the question gets asked.

Conclusion

AI didn’t replace the compliance workload — it added a layer to it. Treat the systems doing your compliance work with the same scrutiny you’d apply to any vendor with production access, because under the frameworks now in force, that’s exactly what they are.

Open Questions

  • How should organizations weight NIST AI RMF (voluntary, US) against EU AI Act (binding, extraterritorial) when they operate in both jurisdictions — build to the stricter standard by default, or maintain separate control sets?
  • For orgs already ISO 27001-certified, how much of ISO/IEC 42001 can realistically be satisfied through existing controls versus requiring net-new evidence and audit cycles?
  • Where’s the practical line between “AI system in scope for governance” and “ordinary SaaS tool with an AI feature” — does every AI-assisted workflow need risk classification, or only ones with production/PII access?