I built the risk engine (packages/core) so it doesn't know what "EU AI Act" means. It knows controls, evidence, and policy mappings. The regulation-specific part is a mapping layer on top, not baked into the primitives.
The EU AI Act is still what most of Opencomplai's rules currently encode, because it's the most immediately enforceable AI regulation right now, with a live enforcement date and real fines.
That split matters because the alternative, hardcoding "Annex III" and "Article 5" into the core assessment logic, turns every new framework into a rewrite. NIST AI RMF. ISO 42001. Whatever the next jurisdiction ships. I'd rather add a policy-mapping module than fork the engine.
Concretely: core has no HTTP dependency and no regulation-specific naming in its primitives. It evaluates controls and policy mappings, full stop. The CLI and services consume that engine and apply whichever mapping is loaded.
If your team is bracing for NIST RMF or an ISO 42001 audit rather than the EU AI Act, the same architecture carries the mapping over. The risk assessment logic doesn't get rewritten.
This is an architecture bet, and it might be wrong. I'd rather find that out from people working against a second framework than assume it from a whiteboard.
A short read starting in packages/core shows where the regulation boundary sits, generic risk-assessment machinery on one side and EU-AI-Act-specific mapping on the other: github.com/Opencomplai/opencomplai.