How the GovCompass model maps to the major frameworks
The GovCompass governance model is not a new framework competing with the established ones; it is a synthesis of them, arranged into a single chain. Every link has an anchor in an authoritative source: NIST and ISO/IEC 42001 for the design-and-execution structure, EU AI Act Article 9 for the binding harm-to-risk-to-control chain and the residual-risk judgment, and COSO ERM, the IIA Three Lines Model, and ISO 31000 for the enterprise-risk foundation it inherits.
The GovCompass governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → model is not a new framework competing with the established ones. It is a synthesis of them, arranged into a single chain: a governance system, operating on a design level and an execution levelexecution levelThe tier at which AI systems are built, deployed, and operated in accordance with the policies and standards set at the governance design level.Open full entry →, that holds each principleprincipleOne of the seven responsible-AI values a governed system should live up to (fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, human oversight). A principle is abstract: it states an outcome, not a lever you can pull. It becomes governable by naming the harm that would breach it, assessing the risk that harm carries, and placing controls against that risk. When GovCompass holds a principle this way it calls it a pillar. See pillar, harm, risk.Open full entry → by naming the harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → that would breach it, assessing the riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → that harm carries, placing controls that reduce it across the preventive, detective, and corrective types, judging the residual riskresidual riskThe risk that remains after controls have reduced it. No control reduces a risk to zero, and not every control is worth its cost, so a deliberate judgment is made: whether the cost of further control is justified by the reduction it would buy, and whether the remaining risk is acceptable against the organization's risk appetite. This is a design-level judgment, where execution reports back up and governance accepts the residual risk, calls for more control, or declines the use case. EU AI Act Art. 9(5) requires it to be judged acceptable per hazard and overall. See risk, control, risk appetite.Open full entry → against appetite, and proving the whole with evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry →.
Every link in that chain has an anchor in an authoritative framework. This article maps the model to the frameworks an AI governanceAI governanceGovernance extended for AI: the same organizational steering at the highest level, widened to cover what makes AI different (it works in probabilities rather than fixed rules, learns from data, and can act at a speed and scale no human reviewer can match). It inherits the existing governance structure and brings AI inside the disciplines the organization already runs, rather than creating a parallel system in a silo. It operates on two levels, design and execution. See governance, governance design, execution level, responsible AI.Open full entry → professional works with, so the model can be used as a single mental structure without losing the ability to speak each framework's language when an auditor, a regulator, or a certification asks. It is a companion to what is AI governance, which sets out the chain itself.
The two-level structure: design and execution
The split between governance designgovernance designThe tier at which governance structures, policies, frameworks, and standards are established; sets the rules the execution level must follow.Open full entry → and execution is the structure the major AI frameworks already use.
The NIST AI Risk Management Framework separates its govern function, the cross-cutting organizational layer of policies, accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry →, and culture, from the map, measure, and manage functions that run continuously against each system. Govern is the design level; map, measure, and manage are execution. NIST is explicit that govern is infused throughout the others and that their outputs feed back into govern to update it, which is the design-execution loop.
ISO/IEC 42001 is built as an AI management systemAI management systemThe organizational structure, policies and processes for governing AI across its life cycle, as formalized in ISO/IEC 42001.Open full entry → on the Plan-Do-Check-Act cycle: the planning clauses establish the design (context, leadership, policy, roles, risk planning), and the operation, evaluation, and improvement clauses are the execution (running the controls, auditing, correcting). A management system is by definition a design that operates continuously, which is the same two levels.
The AIGP body of knowledge follows the same shape: its early competencies cover establishing organizational expectations, policies, and roles (design), and its later domains cover governing development and deployment across the AI life cycleAI life cycleThe looped stages of an AI system: design → data/development → validation → deployment → operation & monitoring → retirement, each with native controls and gated transitions.Open full entry → (execution).
The chain: principle, harm, risk, control, residual risk, evidence
The heart of the model, that controls reduce risks which trace back through a harm to a principle, is the structure the EU AI Act makes binding and the standards operationalize.
EU AI Act Article 9 sets the order directly: identify and evaluate the risks a high-risk system poses to health, safety, and fundamental rights, then adopt targeted risk management measures that address the risks identified, and ensure the residual risk is judged acceptable. It requires that every mitigation measure map back to the specific risk it addresses; controls and risks held in separate documents with no mapping is a compliance failure. That harm-to-risk-to-controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry → line and the residual-risk judgment are the chain, in law. The Act's framing of risk as the probability and severity of a harm is what places harm at the start of the chain.
ISO/IEC 42001 operationalizes the same order: its risk treatment clause requires the organization to choose controls for its identified risks and check them against the Annex A control set, and its impact assessmentimpact assessmentA structured evaluation, carried out in the plan-and-design stage, of the harms an AI system could cause and the risk those harms carry, before the system is built. The first place the governance chain is run, and the cheapest point in the life cycle to reduce risk. The anchor artifact of the planning stage; under the EU AI Act, a fundamental-rights impact assessment is required for certain high-risk deployers. See harm, risk, life cycle.Open full entry → clause provides the execution instrument. The standard requires the link between a risk and its treatment, the same traceability the AI Act demands.
The NIST RMF expresses the chain across its functions: map identifies the risk in context, measure assesses it, and manage applies the control and tracks the residual.
The three control typescontrol typesThe three ways a control can work, the distinction any auditor recognizes. Preventive controls stop the harm before it can occur, for example by refusing an action the system is not permitted to take. Detective controls reveal a failure once it occurs, through testing, logging, and monitoring. Corrective controls limit the damage and feed the lesson back into prevention, through escalation, intervention, and incident response. A preventive control alone is rarely enough; a strong program shows all three at work for the risks that matter. See control.Open full entry →, preventive, detective, corrective, are the auditor-standard taxonomy, and they map onto Article 9's structure: elimination or reduction through design (preventive), monitoring and testing (detective), and mitigation, escalation, and incident response for what remains (corrective).
Where ERM anchors the model
AI governance does not start from a blank page. It inherits the enterprise risk management an organization already runs, and three ERM frameworks anchor that inheritance.
COSO ERM, in its 2017 form, provides the enterprise structure the model's design level sits inside. Its five components, governance and culture, strategy and objective-setting, performance, review and revision, and information, communication and reporting, span twenty principles. The model's harm-risk-control chain is the risk identification, assessment, and response that COSO places under performance, applied to the seven AI principles, and the residual-risk-against-appetite judgment is a COSO mechanism. Risk appetiterisk appetiteThe level of risk an organization's leadership is willing to accept in pursuit of its objectives, set at the governance design level. It is the benchmark against which residual risk is judged acceptable or not, inherited from the organization's broader governance and applied to AI. A concept from enterprise risk management (COSO ERM) before it is an AI one. See residual risk, governance design.Open full entry → is a COSO concept before it is an AI one.
The IIA Three Lines Model, renamed in 2020 from the older "three lines of defence", anchors the roles in the model's design level: the first line owns and manages risk and controls, the second line provides oversight, challenge, and expertise (where a dedicated AI governance function or AI Officer typically sits), and the third line provides independent assurance. The providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → and deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → roles the AI Act defines operate inside this structure, not beside it.
ISO 31000 anchors the generic risk discipline itself: its process, establish the context, then risk assessment (identification, analysis, evaluation), then risk treatment, with communication and monitoring throughout, is the generic form of the model's harm-risk-control chain. ISO/IEC 42001's risk clauses are the AI-specific expression of that generic process, which is exactly why AI governance can be described as inherited-and-extended rather than invented. The alignment is not coincidental: analysis of the EU AI Act's Article 9, the ISO risk standards, and the NIST RMF finds they converge on the same top-level steps, define, assess, and treat risks, all under a govern process, which is precisely the design-and-execution structure this model uses.
Why the synthesis holds
The frameworks agree because they describe the same underlying discipline from different angles. NIST gives the process model and the design-execution loop. ISO 42001 gives the certifiable management system. The EU AI Act gives the binding legal obligations, with the harm-to-risk-to-control traceability and the residual-risk judgment as hard requirements. COSO, the Three Lines Model, and ISO 31000 give the enterprise risk foundation the AI-specific frameworks inherit. The AIGP body of knowledge is the professional competency map across all of them.
The GovCompass model arranges these into one chain so an AI governance professional can hold a single structure in mind and translate it into whichever framework the situation demands: NIST language for a US procurement conversation, ISO 42001 for a certification audit, Article 9 for an EU high-risk obligation, COSO and the Three Lines Model for the board and internal auditinternal auditThe third line of defense: independent assurance that AI assessments, controls and documentation actually operate — reporting to the board, never to the builders.Open full entry →, the AIGP body of knowledge for the credential. One model, many dialects.