Standard GPAI obligations under Article 53 focus on documentation, copyright compliance, training data summaries, and transparency disclosures. Systemic-risk obligations add a higher bar for models trained above roughly 10²⁵ FLOPs, including structured red-teaming, incident reporting, risk management documentation, and cybersecurity measures for weights and infrastructure. The distinction matters because the second tier adds active assurance duties, not just records.
Why the Two Obligation Tiers Are Not Doing the Same Job
Standard GPAI obligations are mostly about making a model legible to regulators, downstream deployers, and rights holders: documentation, transparency, and copyright-related reporting. Systemic-risk obligations shift the question from disclosure to assurance. They assume that a model of sufficient scale can create wider, harder-to-reverse harm, so the provider must prove it can detect, reduce, and respond to that risk rather than merely describe the model.
That difference changes the compliance posture. A provider can satisfy the first tier with governance artefacts that explain what the model is and how it was trained. The second tier demands that the provider show how it is continuously managing higher-impact failure modes, including abuse, unsafe capability release, and security weaknesses around model weights and infrastructure. For background on why policy and assurance expectations are tightening around AI systems, the EU AI Act frames the higher-risk end of the spectrum as requiring stronger lifecycle controls.
Practitioners often miss that the line between the tiers is not about whether a model is “good” or “bad”; it is about whether the model’s scale and deployment profile justify a stronger duty of care. In practice, many teams discover that only after release pressure has built, not while the governance file is being drafted.
How the Higher Bar Changes Day-to-Day Operations
For standard GPAI, the operational work is mainly documentary and disclosure oriented. Teams need a coherent model summary, a copyright policy, and enough training-data visibility to support downstream compliance and accountability. That work is important, but it is largely static once prepared.
Systemic-risk obligations are different because they require active controls that keep working after launch. The provider must maintain risk management documentation, run structured red-teaming, report serious incidents, and harden the security of model weights, training artefacts, and connected infrastructure. This is closer to an ongoing assurance programme than to a filing exercise. It also means the provider needs clear ownership across security, model governance, legal, and operations rather than leaving the obligation inside a single policy team.
- Standard tier: explain the model, its training sources at a high level, and the rights-related safeguards that surround it.
- Systemic-risk tier: test the model for harmful capability, monitor for emergent failure modes, and retain evidence that the tests and mitigations were actually performed.
- Standard tier: publish information that helps others assess the model.
- Systemic-risk tier: demonstrate that the provider can respond when the model or its surrounding environment behaves in unsafe or unstable ways.
A useful way to think about the distinction is that standard obligations make the model inspectable, while systemic-risk obligations make it governable under stress. Guidance from OWASP NHI Top 10 is helpful here because the surrounding identity and access layer often becomes part of the risk surface once models are connected to tools or credentials. The controls break down when organisations treat red-teaming as a one-time launch gate, because the risk profile changes as prompts, tools, weights, and deployment contexts evolve.
Where the Boundary Gets Messy in Practice
Tighter systemic-risk controls often increase engineering and governance overhead, so organisations have to balance stronger assurance against speed of release and operating cost. That tradeoff becomes visible when a model is borderline on scale, widely embedded in products, or used in a tool-using architecture where failure can propagate quickly.
The hardest edge case is not the headline threshold itself, but the operational reality around it. A model may sit below the formal systemic-risk threshold and still justify stronger internal controls because of its sensitivity, user base, or integration profile. Best practice is evolving here, and there is no universal standard that says threshold crossing should be the only trigger for heavier governance. Providers should therefore avoid a narrow “below threshold means low effort” mindset.
This is also where security and compliance intersect. If model weights, deployment infrastructure, or connected secrets are weakly protected, the provider may technically have the right documentation but still fail the spirit of the higher-tier obligations. The NHIMG analysis of LLMjacking shows why credential and access exposure can become an AI governance issue, not just a classic security issue. Teams should treat the systemic-risk tier as the point where AI governance, security engineering, and incident handling stop being parallel workstreams and become one combined control problem.
Risk and Threat Considerations
The material risk difference is that standard GPAI obligations mainly create transparency exposure if they are incomplete, while systemic-risk obligations are meant to reduce the chance that a large-capability model can be abused, destabilise downstream systems, or amplify security failures. The higher tier exists because weak assurance around a powerful model can turn a documentation gap into a real operational and trust problem.
Failure mechanism: Providers may satisfy disclosure requirements without building the testing, monitoring, incident reporting, and weight-protection controls needed to contain harmful behaviour. That gap leaves room for unsafe capability release, inadequate detection of model misuse, and compromise of the surrounding infrastructure or secrets that support the model lifecycle.
Impact: The result can be broader user harm, weaker accountability after incidents, and greater exposure of model assets, training artefacts, or connected systems. At scale, the failure is not just non-compliance; it is loss of control over how the model is used and what damage it can cause.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Article 53 — GPAI Obligations | Directly governs standard GPAI transparency and documentation duties. |
| Article 55 — Systemic Risk Obligations | Directly governs higher-bar duties for GPAI models with systemic risk. | |
| Recommendation — Document the model, training data summary, and copyright disclosures required for GPAI release. Run red-teaming, maintain incident reporting, and document risk controls for systemic-risk models. | ||
| ISO/IEC 42001:2023 | 8.2 — AI risk treatment | Supports ongoing AI risk treatment where assurance must extend beyond disclosure. |
| Recommendation — Maintain AI risk treatment controls that keep high-impact models under continuous governance. | ||
| NIST AI RMF | GOV-2 — Map, Measure, and Manage AI Risks | Fits the shift from static documentation to measurable AI risk management. |
| Recommendation — Measure model risks continuously and manage them with documented governance decisions. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Relevant to protecting model infrastructure and connected systems from weak hardening. |
| Recommendation — Harden model infrastructure and enforce secure configuration baselines for connected assets. | ||
| NIST CSF 2.0 | RS.MA — Incident Management | Applies to the incident reporting and response duties added at systemic-risk level. |
| Recommendation — Define incident handling triggers and retain evidence that AI incidents are reported and managed. | ||
Practitioner Guidance
What to prioritise: Determine whether the model is being governed as a documentation-only GPAI or as a capability that needs active assurance. If the deployment includes tool access, sensitive data, or high-volume public use, treat the systemic-risk tier as the default planning assumption rather than an exceptional add-on.
Decision rule: If your evidence package can explain the model but cannot show red-team results, incident handling, and weight or infrastructure protections, you are not ready for the higher tier. The practical test is whether the organisation can prove ongoing control, not whether it has a polished policy set.
What to verify: Confirm that someone owns the red-team schedule, that incident thresholds are defined, and that security controls for model artefacts are reviewed with the same seriousness as production credentials. The common mistake is to separate AI governance from infrastructure security even though the obligations depend on both.
Practitioner takeaway: Standard GPAI obligations help explain the model, but systemic-risk obligations are where the provider must demonstrate it can still control the model when the environment, the users, or the model itself become unpredictable.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
