Build an AI compliance program as a lifecycle process: assign accountable owners, inventory AI use, map the rules that apply to each use, assess risks, set and test controls, retain evidence, monitor operation, and retire systems safely. There is no single checklist for every regulated business: the relevant requirements depend on where the organization and affected people are, the sector, the system’s purpose, and the organization’s role. NIST’s AI Risk Management Framework (AI RMF) can help structure the work, but it is voluntary guidance—not a legal certification or a substitute for applicable law.
What should an AI compliance program do?
An effective program should make it possible to answer, for every AI use: who is accountable, what the system does, which obligations apply, what risks were identified, which controls were approved, and how the organization will detect and respond to change or harm. Treat the system—not only the model—as the unit of governance. A deployed use may combine a model, data, software, supplier services, human decisions, and a particular operating context.
As an Amazon Associate I earn from qualifying purchases.
Use the program to connect existing legal, compliance, privacy, security, safety, data-governance, and operational risk processes. Avoid creating a parallel process that cannot reach the people who approve, operate, or suspend a system. NIST describes its framework as a voluntary, cross-sector resource organized around GOVERN, MAP, MEASURE, and MANAGE; GOVERN applies across the other functions. Its framework page identifies AI RMF 1.0 as released on January 26, 2023, and says the framework is being revised, so check the current version and related guidance when implementing it. NIST AI Risk Management Framework; AI RMF 1.0 PDF; NIST AI RMF FAQs.
How do I build an AI compliance program for a regulated business?
Use the sequence below as an operating cycle, not a one-time launch checklist. The controls and review depth should reflect the use case, risk, and applicable rules.
- Set the mandate and decision rights. Obtain executive sponsorship, define the organization’s risk appetite and escalation authority, and name accountable owners for legal interpretation, compliance, engineering, security, privacy, data governance, procurement, and business operations. Document who can approve a use, impose restrictions, accept residual risk, suspend a system, and authorize its return to service. Provide role-appropriate workforce training and a route for raising concerns. NIST’s GOVERN guidance calls for documented roles and communication, training, leadership accountability, and a risk-aware culture. NIST AI RMF Core: Govern.
- Inventory AI and its dependencies. Cover internally built and purchased systems, AI embedded in other products, third-party models, pilots, and employee use of AI tools. Assign an owner and capture each system’s purpose, users and affected people, deployment context, organizational role, data inputs, model and supplier dependencies, jurisdictions, lifecycle status, and known limitations. Define a process for employees and suppliers to disclose new uses, and reconcile the inventory with procurement, software, and project records. Scale inventory effort to risk; NIST specifically calls for an inventory mechanism and safe decommissioning procedures. NIST AI RMF Core: Govern.
- Scope the rules before choosing controls. For each use, identify where the organization operates, where affected people are located, and where outputs are used. Determine the relevant sector and general laws, contracts, regulator expectations, and the organization’s role in the AI value chain. Then document which requirements apply and why. “Regulated business” does not identify one uniform set of AI obligations; the actual sector, jurisdictions, activity, role, and intended purpose matter.
- Classify the use under the applicable rules. Record the rationale, not just a label such as “high risk.” For an EU AI Act analysis, assess the system and actor against the Act’s scope and classification rules. The European Commission’s high-risk guidelines page says the guidelines are draft and non-binding, reflect the Commission’s interpretation, and provide examples that are not exhaustive. Use them as guidance, while checking the applicable legal text and the system’s specific facts. European Commission guidelines for providers and deployers of AI high-risk systems.
- Assess impacts and risks in context. Document intended purpose, foreseeable misuse, affected people, plausible harms, expected benefits, uncertainty, and when a person must review or override an output. Consider privacy, security, reliability, safety, fairness and bias, explainability, accessibility, and rights impacts where relevant. Set acceptance criteria and escalation thresholds before deployment. Revisit the assessment when the purpose, users, data, model, supplier, or operating environment changes.
- Select controls and validate before use. Choose measures proportionate to context and risk, such as data-quality checks, access limits, human review, supplier due diligence, security safeguards, user instructions, fallback processes, testing, and limits on permitted use. Record test methods and data, relevant performance and subgroup results, threshold rationale, known limitations, approvals, and decisions about residual risk. Do not treat a model evaluation alone as validation of the full system in its intended setting.
- Operate, monitor, and respond. Set monitoring frequency according to risk. Define how the organization will detect performance shifts, data or model changes, unexpected outputs, misuse, complaints, incidents, and changes in law or supplier conditions. Establish escalation, containment, user communication, any applicable regulator reporting, correction or rollback, and approval to restart. Plan periodic reviews as well as event-triggered reassessments.
- Keep evidence and improve the program. Maintain versioned records linking each system to its owner, role and classification rationale, applicable obligations, risk assessment, controls, evaluations, approvals, training, supplier information, monitoring, incidents, and changes. Review program governance periodically and when material facts or requirements change. Define an exit process for systems that are replaced, withdrawn, or no longer safe, including safe decommissioning and disposition of dependencies.
How do we know whether an AI system is high-risk?
There is no reliable shortcut based only on a model’s sophistication, the vendor’s label, or the fact that an organization is regulated. High-risk classification is a legal question tied to a particular rule set, system, actor, and use. First establish jurisdiction, intended purpose, context, and the organization’s role; then apply the relevant classification provisions and record the analysis. If a classification is borderline, escalate it to the designated legal or compliance owner before the use proceeds.
For systems within the EU AI Act’s scope, the Commission’s cited high-risk classification guidelines are draft and non-binding, and their examples are not exhaustive. They can inform an analysis but should not be mistaken for the binding Act itself or a universal classification test. European Commission high-risk system guidelines.
Rank #2
What does the EU AI Act example require—and who does it cover?
The EU AI Act illustrates why role and scope matter. Article 9 describes iterative risk management for high-risk AI systems, including identifying and analyzing known and reasonably foreseeable risks, considering foreseeable misuse, evaluating risks using post-market monitoring information, selecting mitigation measures, and testing. For covered high-risk systems, testing is performed as appropriate during development and before market placement or use, against predefined metrics and thresholds, to identify suitable measures and demonstrate consistent performance for the intended purpose and compliance with applicable requirements.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The European Commission AI Act Service Desk’s Article 9 rendering is based on the consolidated Act as of July 27, 2026; its explanatory summary is identified as non-binding, while the Act’s legal text is the authority. Article 9 obligations apply within the provision’s scope, not to every AI system or every regulated business. The page also notes risk-management requirements may be part of or combined with relevant internal processes under other Union law. European Commission AI Act Service Desk: Article 9, Risk management system.
Which dates matter under the EU AI Act?
Do not turn separate dates for different provisions and actors into one universal deadline. The European Commission pages give the following milestones; check the linked pages and applicable legal text for changes before relying on them.
| Provision or actor | Date listed by the Commission | What the date applies to |
|---|---|---|
| General-purpose AI (GPAI) provider obligations | August 2, 2025 | The Commission’s GPAI guidance says provider obligations began applying on this date. |
| Commission enforcement powers for GPAI | August 2, 2026 | The Commission’s guidance says its enforcement powers enter application on this date. |
| GPAI models placed on the market before August 2, 2025 | August 2, 2027 | The Commission’s guidance gives providers of these models this compliance date. |
| Certain high-risk areas | December 2, 2027 | The Commission’s high-risk page lists this date for certain areas; applicability depends on the specific provision and system. |
| AI in specified products | August 2, 2028 | The Commission’s high-risk page lists this date for AI in specified products; it is not a general deadline for all AI systems. |
The GPAI dates concern providers of general-purpose AI models; they are not deadlines for every organization deploying AI. The Commission’s high-risk page lists distinct dates for certain areas and product-integrated systems, so determine which provision and role apply to the system in question. European Commission guidelines for providers of general-purpose AI models; European Commission high-risk system guidelines.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should NIST AI RMF fit into a compliance program?
NIST AI RMF 1.0 is a voluntary, cross-sector framework, not binding law and not a universal compliance certification. Its four functions—GOVERN, MAP, MEASURE, and MANAGE—offer a way to organize governance, context-setting, evaluation, and response. GOVERN is cross-cutting: it supports the other functions through accountability, policies, roles, inventory, training, and review. Use the framework to structure internal work and evidence, then separately map binding obligations for each system and jurisdiction. NIST AI Risk Management Framework; NIST AI RMF 1.0.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →| Resource | Status and reach | How to use it |
|---|---|---|
| NIST AI RMF 1.0 | Voluntary, non-sector-specific framework | Organize governance and lifecycle risk work; do not present adoption as proof that legal duties are met. |
| EU AI Act provisions, including Article 9 | Binding legal requirements for systems and actors within scope | Identify applicable provisions and build controls and evidence that address those obligations. |
| European Commission high-risk classification guidelines | Draft, non-binding guidance on the Commission page | Consult as an interpretive aid; verify classification against the applicable Act and facts. |
What evidence should we keep for AI compliance?
Keep records that let a reviewer reconstruct what was approved, for what purpose, under which assumptions, and what changed afterward. Maintain a versioned system file or linked record set containing:
Best Value
- Accountability: named business and technical owners, approvers, escalation paths, role assignments, and relevant training records.
- System and scope: purpose, deployment context, users and affected groups, organization’s role, jurisdictions, model and supplier dependencies, data inputs, lifecycle status, and known limitations.
- Legal and classification analysis: applicable obligations, classification rationale, assumptions, source versions or dates consulted, and decisions on unresolved questions.
- Risk and impact decisions: intended purpose, foreseeable misuse, identified harms and benefits, uncertainty, acceptance criteria, review thresholds, mitigations, and residual-risk approvals.
- Control and validation material: supplier assessments, data controls, access and security measures, human-review design, instructions, fallback plans, test methods and results, subgroup results where relevant, thresholds, limitations, and approval records.
- Operational history: monitoring plans and findings, model or data changes, complaints, incidents, corrective actions, communications, reassessments, and suspension or restart decisions.
- Exit records: withdrawal or replacement decision, decommissioning steps, and treatment of connected services and dependencies.
Keep evidence proportionate to risk and preserve enough context to interpret it; a collection of unversioned test outputs or policy documents may not show which system version or decision they support. The NIST GOVERN guidance connects documentation with transparency, human review, accountability, monitoring, and safe decommissioning. NIST AI RMF Core: Govern.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
