Regulatory Compliance: EU AI Act, NIST AI RMF, and ISO 42001

AI regulation is no longer a future concern for engineering teams — it is a present engineering requirement. The EU AI Act entered into force in August 2024 and its requirements are progressively applying throughout 2025 and 2026. NIST's AI Risk Management Framework has been adopted by US federal agencies and referenced by private sector enterprises as the baseline for AI risk governance. ISO 42001 provides the management system standard that organisations use to demonstrate AI governance maturity to auditors and enterprise customers.

This lesson translates these frameworks into engineering-level obligations. Regulatory frameworks are written for policy audiences; engineering teams need to understand what these frameworks require in terms of specific technical decisions, system design, logging requirements, and documentation.

EU AI Act Structure

The EU AI Act is the world's first comprehensive AI regulation with binding legal effect. Understanding its structure is necessary for determining whether and how it applies to a given AI system.

Prohibited uses (Article 5). A small set of AI applications are prohibited outright: AI systems that use subliminal techniques to manipulate behaviour in ways that cause harm, AI that exploits vulnerabilities of specific groups (age, disability), real-time remote biometric identification in public spaces by law enforcement (with narrow exceptions), social scoring by public authorities, and AI systems that infer sensitive attributes from biometric data for discriminatory purposes. These are absolute prohibitions that apply regardless of any mitigation measures. If your AI system falls into these categories, the regulatory obligation is to not build it.

High-risk AI systems (Annex III and Article 6). The largest and most engineering-relevant category. High-risk AI systems are those used in safety-critical applications or applications with significant potential for harm to individuals. Annex III enumerates the high-risk categories: biometric identification and categorisation, critical infrastructure management, educational and vocational training (AI that determines access to education), employment and worker management (CV screening, performance monitoring, work allocation), essential private and public services (credit scoring, insurance, social benefits assessment), law enforcement, migration and border control, administration of justice, and democratic processes.

As of mid-2026, it is important to read the Annex III categories carefully — the Act specifies not just the sector but the specific use case. An AI system used in healthcare for administrative scheduling is not high-risk; an AI system used to assist medical diagnosis or treatment decisions is high-risk. An AI system that recommends job candidates from a large pool is high-risk; an AI system that automates payroll calculation is not.

General Purpose AI (GPAI) models (Articles 51-56). Applies to providers of general-purpose AI models (foundation models). GPAI providers must maintain technical documentation, comply with copyright law, publish summaries of training data, and for GPAI models with systemic risk (large training compute thresholds), conduct adversarial testing, report serious incidents to the EU AI Office, and ensure model safety. This primarily affects foundation model labs (OpenAI, Anthropic, Google, Meta as the providers of these models), not the engineering teams building applications on top of them.

Minimal-risk AI systems. The vast majority of AI systems — chatbots, recommendation systems, spam filters, content moderation, AI-assisted document drafting — fall into the minimal-risk category and are subject to the Act's transparency provisions (informing users they are interacting with an AI) but not to the extensive obligations of high-risk systems.

What High-Risk AI Means for Engineering Teams

For engineering teams building or operating high-risk AI systems, the EU AI Act creates specific technical obligations.

Conformity assessment. High-risk AI systems must undergo a conformity assessment before being placed on the market. For most categories, providers can self-declare conformity (the product documentation demonstrating compliance is produced and maintained internally, without third-party audit). For some categories (biometric identification, AI for law enforcement, AI for administration of justice), notified body assessment by an accredited third party is required. Engineering teams must produce and maintain the technical documentation that constitutes the conformity assessment record.

Technical documentation requirements (Annex IV). The technical documentation for a high-risk AI system must include: a general description of the system and its intended purpose, a description of the system's elements and development process, information about the training methodology and training datasets, measures taken to examine and mitigate biases in training data, the validation and testing procedures and results, the technical measures to ensure robustness, accuracy, and cybersecurity, and a description of the monitoring, functioning, and control of the system. This documentation must be maintained and updated throughout the system's lifetime.

Logging requirements (Article 12). High-risk AI systems must be capable of logging automatically and for the period appropriate to the intended purpose. Logging must enable post-hoc verification of the system's functioning and enable the tracing of situations that may present a risk. For engineering teams, this means: automatic logging of system inputs and outputs, logging of the model version in use, logging of decisions made and the data used to make them, and retention of logs for a period defined by the intended use case (the Act references the period appropriate to the intended purpose — for some use cases, this may be years).

Human oversight (Article 14). High-risk AI systems must be designed to allow natural persons to effectively oversee the functioning. This means: the system must be understandable to the natural persons responsible for oversight (explainability requirement), those persons must be able to override or interrupt the system, and the system must have safeguards against over-reliance on AI outputs. Engineering implications: design AI outputs to include explanatory information (what factors drove the decision, how confident the model is), implement override mechanisms in the user interface, and design workflows where the AI assists rather than replaces human judgment.

Accuracy, robustness, and cybersecurity (Article 15). High-risk AI systems must achieve an appropriate level of accuracy and be designed to be robust against errors, faults, and inconsistencies. Cybersecurity of high-risk AI systems specifically covers resilience against adversarial attacks — the security techniques covered in earlier lessons in this course are directly relevant to Article 15 compliance for high-risk systems. The Act requires systems to be designed to prevent and minimise the effects of adversarial attacks.

NIST AI Risk Management Framework

The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) provides a process-oriented approach to AI risk management. It is structured around four core functions that form a continuous cycle.

Govern. Establishes the organisational context for AI risk management. Covers: accountability and responsibility assignments (who is responsible for AI risk decisions), risk tolerance definition (what level of AI risk is acceptable), policies for AI development and deployment, culture and incentive structures that support risk management, and mechanisms for considering AI impacts on affected parties. Engineering team implication: there should be a designated person or team responsible for AI risk governance, documented risk tolerance thresholds, and a policy that covers prohibited use cases and requires risk assessment before deployment.

Map. Identifies and characterises AI risks in context. Covers: categorising the AI system and its expected impacts, identifying the stakeholders affected, documenting assumptions and limitations, assessing the context of deployment (who are the users, what is the intended use, what are the foreseeable misuses), and building a risk catalogue for the specific system. Engineering team implication: before deploying an AI system, produce a risk assessment document that covers the intended use case, affected stakeholders, identified risks (using the OWASP LLM Top 10 and STRIDE as inputs), and foreseeable misuse scenarios.

Measure. Quantifies and monitors AI risks and performance. Covers: defining metrics for AI system performance, risk, and trustworthiness; implementing testing and evaluation processes; monitoring AI systems in production; and evaluating the effectiveness of risk mitigations. Engineering team implication: define measurable quality and safety metrics for each AI system, build eval suites that cover both capability and safety, implement production monitoring that tracks these metrics, and review them regularly.

Manage. Responds to identified AI risks. Covers: prioritising and treating identified risks, implementing risk controls, maintaining and improving the system, and planning for incidents. Engineering team implication: risk treatment decisions should be documented (accepted, mitigated, transferred, avoided), implemented controls should be tested for effectiveness, and an incident response plan should be defined for AI-specific incidents.

AI RMF profiles and playbooks. NIST has released sector-specific AI RMF profiles and playbooks (including for financial services, healthcare, and critical infrastructure) that adapt the core framework to the specific risk context of each sector. If your organisation operates in a regulated sector, consult the relevant sector-specific profile.

ISO 42001: AI Management System Standard

ISO 42001 (published December 2023) is the ISO management system standard for artificial intelligence. It follows the same high-level structure as ISO 27001 (information security) and ISO 9001 (quality management), making it familiar to organisations that have implemented those standards.

Scope. ISO 42001 applies to any organisation that develops, provides, or uses AI systems in its products or services. Unlike the EU AI Act, which applies to AI systems based on their risk level, ISO 42001 applies broadly as an organisational management system for AI governance.

Key clauses relevant to engineering teams:

Clause 6 (Planning): Requires AI risk assessment processes, identification of AI system impacts, and planning of controls to address identified risks. Engineering implication: maintain documented risk assessments for AI systems, updated when the system or context changes.

Clause 8 (Operation): Requires operational controls for AI systems including design and development controls, data management controls, and assessment of AI systems prior to deployment. Engineering implication: design and development decisions for AI systems must be documented, data provenance must be maintained, and pre-deployment assessment (testing, security review) must be performed and recorded.

Clause 9 (Performance Evaluation): Requires monitoring, measurement, analysis, and evaluation of AI system performance. Engineering implication: define and measure AI system quality and safety metrics, conduct regular internal audits, and perform management reviews.

Clause 10 (Improvement): Requires treatment of nonconformities (when the AI system behaves contrary to requirements) and continuous improvement. Engineering implication: maintain an incident register for AI system nonconformities, conduct root cause analysis, and implement corrective actions.

ISO 42001 and certification. Organisations can be certified against ISO 42001 by an accredited certification body, following the same model as ISO 27001. Certification demonstrates to enterprise customers and regulators that AI governance is implemented as a systematic management process. At mid-2026, ISO 42001 certification is becoming a procurement requirement in enterprise B2B contexts, particularly for AI vendors supplying regulated industries.

GDPR Article 22: Automated Decision-Making

Article 22 of GDPR gives individuals the right not to be subject to decisions based solely on automated processing that produce significant legal or similarly significant effects. This has direct implications for AI systems that make or influence decisions about individuals.

Scope. Article 22 applies when: the processing is solely automated (no meaningful human involvement), the decision produces legal effects or similarly significant effects (denial of credit, rejection of an employment application, denial of insurance, exclusion from a public service), and the decision concerns the data subject (affects the individual whose data was processed). All three conditions must be met.

Engineering obligations under Article 22. For AI systems in scope: provide meaningful information about the logic of the automated processing (not just "we use AI" — describe the factors the system considers and how they affect outcomes), implement the right to have the decision reviewed by a human, and implement the right to contest the decision. These are not just policy requirements — they require engineering: explainability features in the AI output, a human review workflow with access to the full AI reasoning, and a mechanism for the individual to provide additional information or context that the human reviewer can consider.

What "solely automated" means in practice. Many organisations attempt to satisfy Article 22 by adding a nominal human review step to their automated decision process. Regulators have made clear that a human who simply rubber-stamps AI decisions without exercising genuine judgment does not constitute meaningful human involvement. If the human reviewer does not have the information, time, or authority to override the AI decision, the processing is functionally solely automated regardless of the nominal review step.

Practical Compliance Checklist for AI Systems

Translating the above frameworks into a practical compliance checklist that an engineering team can use for a specific AI system.

Step 1: Classification. Is the system prohibited under EU AI Act Article 5? (Stop if yes.) Is the system high-risk under Annex III? Is GDPR Article 22 triggered? Is the organisation subject to sector-specific AI regulation (financial services, healthcare, critical infrastructure)?

Step 2: Documentation. For high-risk systems: produce Annex IV technical documentation. For all systems: document the intended use case, affected stakeholders, training data sources, known limitations and failure modes, and testing and evaluation results.

Step 3: Data governance. Is there a documented lawful basis for all personal data processed? Is de-identification or synthetic data used where feasible? Is there a retention and deletion policy for training data and model inputs/outputs? Is there a process for satisfying right to erasure requests?

Step 4: Technical controls. Is logging implemented at the level required by Article 12 (for high-risk systems)? Are human oversight mechanisms implemented (Article 14)? Is adversarial robustness testing conducted (Article 15)? Are the AI-specific security controls from this course implemented?

Step 5: NIST AI RMF alignment. Is there a risk assessment document for this system (Map)? Are quality and safety metrics defined and being measured (Measure)? Is there an incident response plan for AI-specific incidents (Manage)?

Step 6: ISO 42001 alignment. Is the system covered by the organisation's AI management system scope? Is there a pre-deployment assessment record? Is there a monitoring plan for in-production performance?