OpenComplAI is designed to keep AI risk-assessment logic separate from the rules used to represent a particular regulatory framework. In a DEV Community post published on October 27, the project’s developer described the approach as a reusable engine for evaluating controls and evidence, with regulation-specific requirements handled in a mapping layer.
The immediate focus remains the EU AI Act: the developer says most of OpenComplAI’s encoded rules currently relate to that regulation. The architectural goal, however, is to avoid making the engine itself depend on EU AI Act terminology. That separation is intended to make it possible to adapt the system for other frameworks without rebuilding its central assessment machinery.
A general engine, with framework-specific mappings
In this design, the core engine evaluates controls and their associated evidence, while a policy mapping connects those underlying elements to the requirements of a chosen framework. The distinction is important: a control is an assessment building block, whereas a mapping explains how that building block relates to a particular policy or regulation.
The developer says the core package has no HTTP dependency and does not use regulation-specific names in its primitives. Instead, command-line tools and services use the engine and apply whichever mapping is loaded. That gives the system a boundary between general risk-assessment functions and the framework-specific interpretation placed on top.
Hardcoding the wording of one regulation into the assessment logic would make each additional framework more costly to support, the developer argues. Adding another jurisdiction or standard could then require changes throughout the engine, or a separate fork. With a mapping layer, the intended alternative is to leave the general assessment process intact and add a new policy mapping where needed.
The developer describes this as an architectural bet, not a proven result. The post invites feedback from teams working with a second framework, rather than relying only on an assumption made during design. That makes practical experience with another framework the next meaningful test of the approach.
What the project currently supports
OpenComplAI’s GitHub repository describes the project as an open-source compliance tool that can run risk assessments in CI/CD pipelines. It says the EU AI Act is evaluated natively, while NIST AI RMF is derived from the same evidence through a crosswalk. The repository labels that NIST support partial and unreviewed, and says it does not have a separate NIST scanner.
The repository describes ISO/IEC 42001 differently: it provides an attestation-led pack in which entries remain unverified until an attestation is recorded. It also lists DORA and EBA as mapped only. These distinctions matter because a framework mapping is not necessarily equivalent to a full, independently evaluated implementation.
There is a difference in emphasis between the developer’s post and the repository’s more detailed description. The post says the architecture can carry a mapping to NIST RMF or ISO 42001 without rewriting risk-assessment logic. The repository, meanwhile, qualifies the current NIST and ISO coverage as partial and unreviewed, and explains that the two are handled in different ways. The architectural possibility should therefore not be read as a claim that every framework is already fully supported.
The project also makes clear that its output is not a certification of compliance. Its repository describes evidence artifacts, checks and documentation workflows, while noting that generated documentation may contain placeholders where required information has not been supplied. Teams still need to provide and review evidence, make decisions about their obligations, and assess whether the tool’s coverage meets their needs.
Why the separation matters to developers
AI compliance work can touch product requirements, technical controls, supporting evidence and release processes. When those concerns are tied directly to a single framework inside a codebase, changes in regulatory scope can become entangled with changes to the underlying risk logic. Separating the mapping from the engine gives developers a way to keep those concerns more distinct.
That structure can also make the software easier to inspect. A team can ask which controls the engine checks, what evidence it expects, and how a selected framework maps to those checks. The mapping becomes a reviewable part of the compliance implementation rather than an implicit assumption scattered through assessment code.
For teams that use continuous integration, this kind of tooling can move a compliance check closer to the development workflow. OpenComplAI’s repository describes automated checks that can run before release and produce pass-or-fail outcomes. In general, a pipeline gate can help teams catch missing controls or evidence during development, but its usefulness depends on what the gate actually tests and whether its inputs are current and complete.
The separation also has limits. A mapping can only represent what has been encoded and reviewed. If two frameworks define different obligations, a translation from one set of evidence to another may be incomplete or inappropriate. The repository’s qualified descriptions of NIST and ISO coverage underline why teams should inspect the framework-specific status rather than assume that a shared engine means identical depth across all regimes.
What teams can evaluate next
OpenComplAI is presented as open-source software for incorporating AI compliance checks into development pipelines. Its repository describes a command-line interface, a Python SDK and CI integrations, alongside services for tasks such as risk assessment and evidence handling. The pricing page says the open-source version is free under the AGPL-3.0 licence; an Enterprise offering adds a hosted dashboard, support and other organisation-scoped services.
For developers evaluating the approach, a useful next step is to inspect the boundary between the core and its mappings, then test the tool against a real system and the framework obligations relevant to that system. Teams should examine which checks are native, which are derived or attestation-led, what evidence is required, and how incomplete or stale evidence is handled. They should also confirm how the project’s licence applies to their intended use.
The project’s own next test is broader validation. Its developer wants feedback from people applying the same engine to a second framework. If that work shows that a new mapping can be added without invasive changes to the core, it would support the design’s central claim. If it exposes assumptions embedded in the assessment primitives, the architecture may need to change.
For now, OpenComplAI offers a concrete example of treating regulatory policy as a layer over reusable risk-assessment machinery. The distinction is useful to developers because it makes the framework boundary visible. But flexibility in architecture does not establish completeness in compliance: the mappings, evidence and review process still determine what a system can meaningfully assess.
Sources: DEV Community, The Verge, TechCrunch, GitHub, Opencomplai
