AI Governance and Regulation in Practice: An Advanced Technical Guide

A compliance program is five artifacts: a documented risk classification, a technical file that survives scrutiny, an incident pipeline with real clocks, a jurisdiction tracker, and a standards-engagement channel. How to build each one.

A risk classification is a documented judgement, not a label; the questionnaire has to be answered in writing before anything else about the program can be scoped. — Image prompt and art direction by Brecht Corbeel; generation pending.

Abstract

Most guidance on AI regulation stops at what the rules say. This article is for the compliance officer, policy lead or engineer who has to make the rules operational: how to run a defensible risk classification against a framework like the EU AI Act, what a technical file actually needs to contain to hold up as evidence rather than a checkbox exercise, how to build an internal incident-monitoring and reporting pipeline against real statutory clocks, how to track obligations across multiple jurisdictions without re-deriving the same work for each one, and how to engage meaningfully with the standards bodies and public consultations that are still writing the rules a program will eventually be judged against. Each section works from primary regulatory text and standards documentation toward a concrete internal process a team can build this quarter.

What a program has to produce

A rule can bind an object without anyone in the building knowing how to comply with it — that gap is the subject of the analytical literature on what AI regulation actually attaches to. This article starts on the other side of that gap. It is written for the compliance officer, policy lead or engineer who has already accepted that a rule applies and now has to produce something in response: a written classification, a file, a reporting pipeline, a way of not re-deriving the same analysis for every jurisdiction, and a channel back into the bodies still drafting the standards the program will eventually be measured against.

Five artifacts recur across every serious AI governance program, regardless of which framework triggered it. This guide builds each one in order, working from the primary text of the regulations and standards rather than from summaries of them, because the practitioner questions — what exactly counts as evidence, what exactly starts a clock, what exactly can be reused — turn on details that summaries routinely flatten.

Step one: classify before you build anything

Nothing else in a compliance program can be scoped until a system has been classified, and classification is a documented judgement, not a label picked off a chart. Under the EU AI Act, Article 6 sets out the test in two tiers. A system is high-risk if it is a safety component of a product — or is itself a product — covered by the Union harmonisation legislation listed in Annex I and subject to third-party conformity assessment under that legislation. Separately, a system is high-risk if it falls within one of the use-case categories listed in Annex III [1].

Annex III is worth reading in full rather than summarised, because the categories are narrower and more specific than “AI used in a sensitive domain.” The eight areas are: biometric identification and categorisation of natural persons; safety components in the management of critical digital infrastructure, road traffic, or water, gas, heating and electricity supply; access to education and vocational training, including systems evaluating learning outcomes; recruitment, selection and management of workers; access to essential private and public services, including creditworthiness and public-benefit eligibility; certain law-enforcement uses, including assessing the risk of a person offending or reoffending; migration, asylum and border-control management; and the administration of justice and democratic processes, including tools assisting a judicial authority in researching and interpreting facts and law [2]. A practitioner’s first working document should be nothing more than this list turned into eight yes/no questions, applied system by system, not once for the organisation as a whole.

A “yes” is not automatically final. Article 6 provides four narrow conditions under which an Annex III system is not treated as high-risk: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns or deviations without replacing or influencing a prior human assessment; or it performs a preparatory task for one of the listed use cases. Any one of these can take a system out of high-risk status — with one hard exception. A system that performs profiling of natural persons is always considered high-risk, regardless of which of the four conditions might otherwise apply [1]. That single carve-out is the most commonly missed line in a first-pass classification, because a system can look narrow and preparatory on every other axis and still trip it.

The documentation requirement attaches here, not later. A provider that concludes an Annex III system is not high-risk must document that assessment before the system is placed on the market or put into service, and keep the record available to national authorities on request [1]. A negative classification with no paper behind it is not a compliant negative classification — it is an unrecorded opinion, and the two are treated differently under inspection.

Once a system is classified high-risk, Article 9 defines the risk management system it must run for the rest of its life: identification and analysis of known and reasonably foreseeable risks to health, safety and fundamental rights; estimation and evaluation of those risks both under intended use and under reasonably foreseeable misuse; testing before market placement specifically aimed at identifying the most appropriate risk-management measures; and an explicit judgement that the residual risk associated with each hazard is acceptable. The article also calls out a specific duty to evaluate whether the system could have a particular adverse impact on minors and other vulnerable groups [3]. Each of those four steps should become a section heading in the assessment document, answered in writing rather than implied.

Organisations outside EU jurisdiction, or building a classification vocabulary before a specific statute applies, can use the NIST AI Risk Management Framework’s MAP function for the same purpose: it is organised, deliberately, as a voluntary set of outcomes rather than a binding test, built around four functions — govern, map, measure and manage — that a team can apply to any system regardless of which jurisdiction eventually claims it [9]. The framework’s companion Playbook turns each function’s outcomes into suggested actions a team can select from rather than a checklist to complete in full — explicitly not “a set of steps to be followed in its entirety” — which makes it a reasonable source of classification questions to borrow from even for a team whose primary obligations sit elsewhere [10]. Where the system in question is a generative one, NIST’s companion Generative AI Profile supplies twelve risk categories specific to that class of system — including confabulation, data privacy, information security, intellectual property, and CBRN information or capabilities — mapped to more than two hundred candidate mitigating actions organised against the same four functions [11]. Used as a checklist rather than a mandate, it fills gaps the EU list does not cover, because it was written for a technology the EU list predates in its specifics.

Step two: build a technical file that would survive a skeptical reader

A technical file exists to answer one question under inspection: what, specifically, was checked, by whom, and when. Article 11 requires that this documentation be drawn up before a high-risk system is placed on the market and kept up to date thereafter, containing at minimum the elements set out in Annex IV [4].

Annex IV is long, but it resolves into a small number of categories that map cleanly onto a binder structure: a general description of the system, including its intended purpose, provider identity, version and interface; the development elements — design specifications, architecture, and the computational resources used; the data requirements — training methodology, dataset provenance, labelling and cleaning procedures; the human-oversight measures needed for a deployer to interpret outputs; performance monitoring detail, including accuracy across relevant populations and foreseeable unintended outcomes; a description of the risk management system built under Article 9; a log of changes made across the system’s operational life; references to the harmonised standards applied or the alternative means used to meet requirements; a copy of the EU declaration of conformity; and the post-market monitoring plan [5]. A file organised as ten tabs against this list, rather than as a narrative report, is both easier to keep current and easier for an inspector to audit against the statute directly.

Figure 1. A technical file is not a narrative written afterward; it is a set of dated sections, and the honest ones show which section is not filled in yet. — Image prompt and art direction by Brecht Corbeel; generation pending.

The harder practitioner question is what makes a file evidence rather than a checkbox exercise, and the internal-auditing literature is more specific on this than the statute is. Raji and colleagues’ framework for internal algorithmic auditing argues that useful documentation has to be produced across the development lifecycle — at problem formulation, at data collection, at each testing stage, at deployment — rather than assembled retrospectively as a narrative once the system is finished [19]. A file built this way carries dated, contemporaneous artefacts: the actual evaluation logs, not a paragraph summarising them; the actual dataset documentation, written when the dataset was assembled, not reconstructed from memory afterward. A file built the other way — a single document drafted at the end to satisfy Annex IV’s headings — is legible to a regulator but weak as evidence, because nothing in it can be independently dated against the development process it claims to describe.

Model cards are the practical unit at the model layer. Mitchell and colleagues specified what a card needs to contain to be useful rather than promotional: intended use and out-of-scope uses stated explicitly, the evaluation data and evaluation factors used, performance metrics disaggregated across relevant subgroups rather than reported only in aggregate, and an explicit statement of caveats and recommendations [18]. The disaggregation requirement is the one checkbox compliance most often skips, because an aggregate accuracy figure is easy to produce and a subgroup breakdown requires the underlying evaluation to have been designed for it from the start. A card that reports only a top-line number, however professionally formatted, has not done the thing the original proposal asked for.

Two further practices are worth building into the file structure directly. First, keep the model documentation and the system documentation as separate, cross-referenced artefacts: the model file describes the weights, the system file describes the deployed product around them — safety mitigations, external testing, deployment-specific behaviour — and the two should be updated on different schedules, since a system can change behind a stable model reference. Second, timestamp and version every entry. A file where every section carries a date and a version tag can answer “was this true when the system shipped, or was it added later” without argument; a file that cannot answer that question is not usable as evidence regardless of what it says.

Step three: build the incident pipeline before you need it

Article 72 requires providers of high-risk systems to establish a documented post-market monitoring system, proportionate to the risks involved, that actively and systematically collects, documents and analyses relevant data on system performance for the whole of its operational life, evaluating continuous compliance with the Act’s core requirements and accounting for interactions with other AI systems where relevant. This sits inside the technical documentation as a formal plan, for which the Commission is to publish a template [7]. Article 9’s risk management addresses risks before deployment; Article 72 is the mechanism that keeps that assessment current after deployment, which is also where most of the evidence an incident investigation will need actually gets generated.

Article 73 sets the clocks that make this operational rather than aspirational. A provider must report a serious incident to the market surveillance authority in the relevant member state no later than fifteen days after becoming aware of it; that period shortens to two days for a widespread infringement, and extends only slightly, to ten days, for an incident resulting in death. Critically, the obligation is triggered once a causal link between the AI system and the incident is established, or once there is a reasonable likelihood of such a link — not once causation is proven. An initial report may be incomplete, followed by a complete one, and the provider must investigate, including a risk assessment and any corrective action, and must not alter the system in a way that would affect a later investigation before informing the authorities [8].

Figure 2. The statutory clock starts at awareness, not at confirmation; a monitoring desk that waits for certainty before it starts counting has already lost days. — Image prompt and art direction by Brecht Corbeel; generation pending.

That “reasonable likelihood” threshold is the design constraint an internal process has to be built around: the clock starts at suspicion, not at certainty, so a monitoring desk that waits for a confirmed root cause before opening a file will already be several days into a fifteen-day window — or a two-day one — before anyone has started counting. A workable pipeline needs, at minimum, an intake channel that accepts reports from users, automated monitoring alerts and internal red-teaming alike; a triage function whose job is specifically to make the “reasonable likelihood” call quickly and to log who made it and when, since that log entry is itself later evidence of when the clock started; and three parallel timers, because a single event can plausibly trigger the fifteen-day, ten-day and two-day tracks simultaneously and the process needs to default to the shortest one that could apply rather than resolve the ambiguity after the fact.

Article 26 supplies the deployer side of the same pipeline, which matters because providers and deployers are frequently different organisations reading different halves of the same incident. Deployers must monitor the operation of a high-risk system based on the instructions for use, inform the provider or distributor without delay where operation presents a risk, keep automatically generated logs for a period appropriate to the system’s purpose and no less than six months, and immediately notify both the provider and the relevant market surveillance authority on identifying a serious incident [6]. A provider’s incident pipeline that has no defined intake from its deployers is missing the half of its evidence base that is closest to the point where most real-world failures actually surface.

NIST’s Generative AI Profile adds one control worth adopting even where the EU Act does not apply: it recommends that organisations establish policies to halt development or deployment of a system if unacceptable negative risk emerges during monitoring [11]. That is a governance decision, not a technical one, and it belongs in the same pipeline document as the reporting clocks, because a team that has never written down who has the authority to pull a system will not resolve that question quickly during an actual incident.

Step four: track obligations across jurisdictions without redoing the work

A compliance program that treats each new jurisdiction as a fresh research project does not scale, and it does not need to. The frameworks differ in mechanism — the EU Act is prescriptive and phased, NIST’s framework is voluntary and organised around outcomes, US state law increasingly splits duties between a developer and a deployer, as in Colorado’s automated-decision-making statute reenacted with primary implementation from 1 January 2027 [20] — but a large share of what each one asks for is a restatement of a small set of underlying commitments, not a genuinely new obligation.

Figure 3. Tracking obligations across jurisdictions only pays off if a new notice is filed against something that already exists; the folder has to come off the board before it can be updated. — Image prompt and art direction by Brecht Corbeel; generation pending.

Two tools do the tracking work so a compliance team does not have to build it from scratch. The OECD.AI Policy Navigator is a live, regularly updated database of AI policy instruments covering more than eighty jurisdictions and organisations, filterable by policy instrument and target group, with visible attribution for who submitted or updated each entry and when [16]. Used as a standing early-warning feed rather than a one-time reference, it turns “did anything change in a jurisdiction we operate in” from a quarterly research task into a filtered query. Underneath most of what the navigator surfaces sits a small common vocabulary: the OECD AI Principles, adopted in 2019 and updated in 2024 and now committed to by forty-seven countries and the European Union, organise trustworthy AI around five values — inclusive growth and well-being, human rights and democratic values including fairness and privacy, transparency and explainability, robustness and safety, and accountability [15]. Diffing a new national instrument against those five values, rather than reading it cold, quickly separates genuine novelty from restatement.

Figure 4. One piece of evidence can satisfy several regimes at once if it is cross-referenced rather than rewritten; the tag through three spines is the whole of what "shared control" means in practice. — Image prompt and art direction by Brecht Corbeel; generation pending.

The second tool is a shared management-system spine to hang jurisdiction-specific obligations on, so that evidence produced once can answer more than one regulator. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System, structured around the same plan-do-check-act cycle used by other management-system standards, and is written as auditable requirements rather than guidance alone [13]. ISO/IEC 23894 supplies the risk-management vocabulary consistent with that structure, intended to be used alongside general risk-management guidance to integrate AI-specific risk activities into an organisation’s existing processes [14]. Practically, this means Article 9’s risk-management steps, NIST’s MAP and MEASURE functions, and a state statute’s impact-assessment requirement can usually be expressed as instances of the same underlying control — an identified risk, an evaluated mitigation, a documented residual — rather than as three separate processes producing three separate sets of paperwork.

The resulting workflow, when a new obligation lands: file it against the shared control map first, and ask which existing control already produces the evidence it requires, before writing anything bespoke. Assign one owner per jurisdiction family, on a fixed review cadence against the OECD navigator supplemented by ad hoc alerts, and treat “no delta found” as a valid, documented outcome of that review rather than a reason to skip logging it.

Step five: engage with the standards bodies still writing the rules

Conformity assessment for the hardest cases — general-purpose systems, systemic-risk thresholds — currently rests on standards that are still being drafted, which means the practitioner window to shape what “adequate” ends up meaning is real, and it is open now rather than after the fact.

Figure 5. A submission during an open comment window is one of the few points where a practitioner can still shape the standard rather than only comply with it; the stamp has not landed yet. — Image prompt and art direction by Brecht Corbeel; generation pending.

The AI Standards Hub, run jointly by the Alan Turing Institute, the British Standards Institution and the National Physical Laboratory, is built specifically as an entry point for this: an observatory tracking AI standards development across standards bodies worldwide, a community function running forums and workshops across industry, government, civil society and academia, and training material aimed at the procedural knowledge — how a standard actually gets drafted and by whom — that most compliance teams never acquire [17]. The concrete first action for a team is to identify the national mirror committee of ISO/IEC JTC 1/SC 42, the joint technical subcommittee responsible for AI standards including the 42001 and 23894 families, through the relevant national standards body, and register interest in the working groups closest to the organisation’s own risk classification.

Regulatory consultations are a second, more direct channel, and NIST’s own process for the Generative AI Profile is a usable template for what participation looks like in practice. NIST posted a request for comments on four draft AI publications, including the profile, through the Federal Register, and collected submissions through the public regulations.gov portal, where they remain visible: more than one hundred fifty commenters, spanning major technology companies, civil society organisations, academic researchers, and state attorneys general, each submission dated and linked [12]. The practical lesson is about what carries weight in a comment period like this: a submission built from a specific failure mode the organisation actually encountered, or a specific metric it could not operationalise as drafted, changes a standard more often than a position statement does, precisely because the drafters are trying to close exactly those evidentiary gaps. The technical file built in step two is, not coincidentally, the same evidence base a strong consultation submission draws on — reusing internal evaluation data as consultation input is frequently the highest-leverage use of that file outside of an actual audit.

Treat engagement as a standing function with an owner and a tracked calendar of open comment windows, the same way legal tracks statutory deadlines, rather than as an occasional activity taken up only when a rule directly threatens the roadmap. By the time a standard is finalised, the window to shape it has closed; the only question that remains is how well the resulting compliance program fits a rule it had no part in writing.

Sequencing the program

None of the five steps above is optional, but they are not equally urgent on day one, and building all five simultaneously is usually why programs stall. Classification comes first, because nothing else can be scoped without it — a technical file, an incident pipeline and a jurisdiction map all take their shape from what a system was classified as. The technical file template comes second, built against Annex IV’s own headings before it is fully populated, because the shape of the file tells a team what evidence to start collecting immediately rather than after a system has already shipped. The incident pipeline comes third: it is the cheapest of the five to build in advance and by a wide margin the most expensive to improvise during a live incident, when the fifteen-day clock is already running. Jurisdiction tracking and standards engagement come last, not because they matter less, but because they are ongoing operational functions rather than one-time projects, and they work best once there is an existing control map and evidence base to hang new obligations and consultation submissions on.

None of this removes judgement from the process. The four-condition derogation test in Article 6, the “reasonable likelihood” threshold in Article 73, and the materiality of a “delta” when mapping a new jurisdictional obligation onto an existing control are all genuinely contestable calls, and no amount of process design turns them into mechanical ones. What the documentation discipline above buys is not certainty — it is defensibility: a written record of which judgement was made, by whom, against what evidence, and when, that can be revisited when the next system, the next incident or the next statute arrives. A compliance program is not the statute it was built to satisfy. It is the evidence trail an organisation can produce, on short notice, in answer to the only question an inspector, an auditor or a court ultimately asks: how do you know?

Sources

1. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 6: Classification Rules for High-Risk AI Systems. EU Artificial Intelligence Act (consolidated text) (2024).
2. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Annex III: High-Risk AI Systems Referred to in Article 6(2). EU Artificial Intelligence Act (consolidated text) (2024).
3. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 9: Risk Management System. EU Artificial Intelligence Act (consolidated text) (2024).
4. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 11: Technical Documentation. EU Artificial Intelligence Act (consolidated text) (2024).
5. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Annex IV: Technical Documentation Referred to in Article 11(1). EU Artificial Intelligence Act (consolidated text) (2024).
6. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 26: Obligations of Deployers of High-Risk AI Systems. EU Artificial Intelligence Act (consolidated text) (2024).
7. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 72: Post-Market Monitoring by Providers. EU Artificial Intelligence Act (consolidated text) (2024).
8. European Parliament and Council of the European Union. EU Artificial Intelligence Act, Article 73: Reporting of Serious Incidents. EU Artificial Intelligence Act (consolidated text) (2024).
9. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). U.S. Department of Commerce (2023). DOI: 10.6028/NIST.AI.100-1.
10. National Institute of Standards and Technology. AI RMF Playbook. NIST AI Resource Center (AIRC) (2023).
11. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). U.S. Department of Commerce (2024). DOI: 10.6028/NIST.AI.600-1.
12. National Institute of Standards and Technology. Comments on NIST-AI-600-1: AI RMF Generative AI Profile. NIST (2024).
13. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 — Information Technology, Artificial Intelligence, Management System. OECD.AI Catalogue of Tools and Metrics (standard listing) (2023).
14. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 23894:2023 — Information Technology, Artificial Intelligence, Guidance on Risk Management. OECD.AI Catalogue of Tools and Metrics (standard listing) (2023).
15. Organisation for Economic Co-operation and Development. OECD AI Principles. OECD.AI Policy Observatory (2024).
16. Organisation for Economic Co-operation and Development. OECD.AI Policy Navigator. OECD.AI Policy Observatory (2026).
17. The Alan Turing Institute, British Standards Institution, and National Physical Laboratory. The AI Standards Hub. AI Standards Hub (2026).
18. Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, et al.. Model Cards for Model Reporting. Conference on Fairness, Accountability, and Transparency (2019). DOI: 10.48550/arXiv.1810.03993.
19. Inioluwa Deborah Raji, Andrew Smart, Rebecca N. White, Margaret Mitchell, Timnit Gebru, et al.. Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing. ACM Conference on Fairness, Accountability, and Transparency (2020). DOI: 10.48550/arXiv.2001.00973.
20. Colorado General Assembly. SB26-189 Automated Decision-Making Technology. Colorado General Assembly (2026).

Originally published at https://absolutedigitalpublishers.com/articles/building-an-ai-governance-program-a-practitioners-guide.