From framework to control
Regulations and frameworks describe outcomes. They do not tell you which rule to deploy at which gateway. The work of a policy control plane is translation: take an obligation, turn it into one or more testable rules, assign an owner and collect evidence that the rule runs. This article describes that mapping approach for two widely cited references. It is educational information, not legal advice, and readers should confirm obligations with qualified counsel.
What the two references are
The EU Artificial Intelligence Act is a binding regulation that takes a risk-based approach. It sets obligations that vary with how an AI system is classified, with stricter requirements for high-risk systems and prohibitions for certain practices. Application dates are phased, so check the current official timetable. The NIST AI Risk Management Framework is voluntary guidance organized around four functions: govern, map, measure and manage. ISO/IEC 42001 is a related management system standard for AI. The three overlap in themes but differ in legal force.
A mapping method
- Inventory: list AI systems, owners, purposes and data sources. You cannot classify what you have not found.
- Classify: decide the risk category of each system under the rules that apply to you.
- Extract obligations: break each applicable requirement into specific statements.
- Write controls: express each statement as a rule, a procedure or both, with a named owner.
- Attach evidence: define what record proves the control operated, and where it is stored.
- Test and review: sample evidence on a schedule and update the map when rules change.
Where runtime policy helps
Some obligations are procedural, such as documentation and human oversight design. Others can be partly enforced at runtime, such as logging of system activity, restrictions on data use, access limits and gates that require human approval. A control plane can enforce those and produce records as a by-product. Be careful not to overstate: a runtime rule contributes to meeting an obligation, but it does not by itself demonstrate compliance.
Avoiding checkbox mapping
A spreadsheet that links every clause to a vague control looks complete and proves little. Prefer fewer controls that are concrete and tested. For each mapped control, ask whether an auditor could verify it from the evidence alone. Keep the mapping in version control so changes to regulation, guidance or your systems produce a visible diff, and review it when any of the three changes.
An example of one mapped control
Take the obligation that people should be able to oversee a consequential AI decision. The mapped control might be a rule that decisions above a defined impact threshold require a named human approver before they take effect. The owner is the business process lead. The evidence is the decision log showing approver identity, time and outcome, sampled quarterly. The test is an attempt to push a high-impact decision through without approval, which must fail.
This is a single illustration, not a statement of what any law requires for your system. Confirm the exact obligations that apply to you before you rely on any mapping.
Keeping the map current
Regulation, standards and your own systems will change. Assign an owner to watch official sources, set a review date each quarter and record what changed. When a new AI system or a major model change is proposed, treat the update of the map as part of the release checklist so that classification and controls are never an afterthought.
