Responsible AI From Principles to Operating Controls

Principles do not survive contact with a tribunal

In February 2024, British Columbia's Civil Resolution Tribunal decided Moffatt v. Air Canada. The airline's website chatbot had told a grieving customer he could claim a bereavement fare refund after travel, which contradicted the airline's own policy page. Air Canada argued, in effect, that the chatbot was responsible for its own words. The tribunal rejected that and held the company liable for negligent misrepresentation.

Nothing in that case turned on whether Air Canada had AI principles. It turned on ordinary operating questions. Who owned the accuracy of the bot's answers? Was it tested against the published policy? Was anyone monitoring what it said to customers? Was there a route for a wrong answer to be caught and corrected?

That is the argument of this article. The unit of responsible AI is the control, not the principle. A principle such as "fairness" or "transparency" becomes real only when it is broken down into controls that have an owner, a point in the lifecycle where they run, and an evidence artefact that a third party could inspect. Programs that stop at principles produce policy documents. Programs that reach controls produce systems that can be defended.

The second half of the argument is about efficiency. The three reference points most enterprises now face (the NIST AI Risk Management Framework, ISO/IEC 42001 and the EU AI Act) look like three compliance programs. They are not. Each does a different job, and a single control library mapped once to all three is cheaper and stronger than three parallel efforts.

Three frameworks, three different jobs

The frameworks are often presented as alternatives. In practice, they stack.

NIST AI RMF 1.0 (NIST AI 100-1, released 26 January 2023) is a voluntary risk vocabulary. It organizes AI risk work into four functions: Govern, Map, Measure and Manage. Its value is that it tells you what to think about: context, impacts, measurement, treatment. NIST's companion Generative AI Profile (NIST AI 600-1, 26 July 2024) adds twelve risks that are unique to or made worse by generative AI, including confabulation, data privacy, information integrity, information security, harmful bias and homogenization, intellectual property and value chain and component integration. It also focuses its suggested actions on four considerations: governance, content provenance, pre-deployment testing and incident disclosure. NIST states that the AI RMF itself is being revised under the US AI Action Plan, and on 7 April 2026 it released a concept note for a profile on trustworthy AI in critical infrastructure.

ISO/IEC 42001:2023, published in December 2023, is a management system standard in the same family as ISO/IEC 27001. It does not tell you which risks matter; it requires you to run a system that identifies them, decides on treatment, assigns responsibility, and improves. Its Annex A lists 38 reference controls under nine control objectives, from AI policy and internal organization through impact assessment, the AI system life cycle, data, information for interested parties, use of AI systems and third-party relationships. Unlike NIST, it is certifiable, and ISO/IEC 42006:2025 now sets requirements for the bodies that certify it. ISO/IEC 42005:2025 adds guidance on AI system impact assessment.

The EU AI Act (Regulation (EU) 2024/1689) is law. It assigns obligations by role (provider, deployer, importer, distributor) and by risk category, and it carries fines of up to EUR 35 million or 7% of worldwide annual turnover for the most serious breaches. It applies to organizations outside the EU when their AI systems are placed on the EU market or their outputs are used in the EU.

The practical conclusion: use NIST to decide what your controls must address, use ISO/IEC 42001 to run them as a managed system, and use the EU AI Act (and any other binding law, such as Saudi Arabia's and the UAE's data protection regimes) to set the minimum for systems in scope.

What the 2026 Digital Omnibus changed, and what it did not

The most important regulatory change of 2026 is Regulation (EU) 2026/1744, the "Digital Omnibus on AI". It was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It is the first formal amendment of the AI Act.

The headline is a delay. The obligations for stand-alone high-risk systems listed in Annex III (employment, credit, education, essential services, biometrics, law enforcement and similar uses) now apply from 2 December 2027 instead of 2 August 2026. Obligations for high-risk AI that is a safety component of products covered by EU harmonization law in Annex I move to 2 August 2028.

Several other changes matter for control design:

• AI literacy (Article 4) was softened. Providers and deployers must now take measures to support AI literacy rather than ensure a sufficient level of it. Documented training programs remain the evidence; individual certification is not required.
• Transparency obligations were not delayed. Article 50 duties, such as telling people they are interacting with an AI system and labelling deepfakes, apply from 2 August 2026. Generative systems already on the market before that date have until 2 December 2026 to apply machine-readable marking of synthetic content.
• New prohibitions were added. From 2 December 2026, AI systems for generating non-consensual intimate imagery or child sexual abuse material are prohibited practices.
• Bias detection got a clearer legal basis. Providers and deployers may process special categories of personal data where strictly necessary to detect and correct bias, subject to safeguards.
• Registration did not go away. Systems that a provider concludes are not high-risk under the Article 6(3) exemption must still be registered in the EU database.

The trap is to read the delay as permission to pause. The high-risk requirements themselves (risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness) are unchanged. A credit, hiring or insurance model being designed now will be live on 2 December 2027, and its documentation, data lineage and test history will need to exist by then. Building them retroactively is always more expensive than generating them as the system is built.

A control library mapped to the lifecycle

The core tool is a control library: a short, stable list of controls, each tied to a lifecycle stage, an owner, a required evidence artefact, and the clauses it satisfies. The matrix below is a starting library we use as a reference design. It is deliberately small. Twelve well-run controls beat eighty that nobody operates.

Three design rules make the library work.

1. Map once, at the control level. Each control carries its NIST function, its ISO/IEC 42001 Annex A objective and the AI Act articles it supports. When an auditor asks for ISO evidence or a regulator asks about Article 14, you answer from the same artefact. When the Saudi or UAE regimes apply, add a column rather than a program.
2. Tier the depth, not the existence, of controls. Every AI system gets an inventory entry and a risk tier. A low-risk internal summarizer gets a light version of each control; a credit decision model gets the full version with independent validation. The proportional tiering described in The Enterprise AI Operating Model applies directly.
3. Put controls where work already happens. Evaluation gates belong in the deployment pipeline, data lineage in the data platform, and oversight in the business process. Controls that live in a separate governance tool become paperwork.

Generative AI needs four additions

For systems built on large language models, the standard library needs four controls that classical model risk management did not have:

• Input data handling rules, stating which data classifications may be sent to which models and endpoints. This is where data governance and AI governance meet; see DAMA-DMBOK and Saudi Arabia's NDMO Standards for classification design.
• Adversarial testing before release, covering prompt injection, data exfiltration through tools, and unsafe content, matched to NIST's information security and dangerous content risks.
• Grounding and confabulation checks, measured against a reference set of questions with known answers. The Air Canada bot would have failed a test built from the airline's own policy pages.
• Content provenance, including marking of synthetic content where Article 50 applies.

Evidence: what an auditor will actually accept

Because compliance is judged on evidence, the cheapest program is one where operating the control produces the evidence automatically.

Model cards and datasheets are the backbone of this evidence. The model card format proposed by Mitchell and colleagues in 2019 records intended use, out-of-scope uses, evaluation data, performance across relevant groups, and known limitations. Datasheets for datasets, proposed by Gebru and colleagues, do the same for training and evaluation data. Neither is a regulatory form, but together they cover much of what the AI Act's technical documentation and instructions for use require of providers, and what ISO/IEC 42001 expects under information for interested parties. The rule that makes them useful is to generate them from the pipeline for every released version, not to write them once by hand.

Incident response is the control most programs skip

Most AI governance programs can describe how a system is approved. Few can describe what happens when it goes wrong in production. Yet the EU AI Act sets hard clocks. Under Article 73, providers of high-risk systems must report a serious incident to the market surveillance authority no later than 15 days after becoming aware of it, no later than 10 days where a death may be involved, and no later than two days for a widespread infringement or a serious disruption of critical infrastructure. These obligations follow the high-risk application dates, but the capability to meet them takes months to build.

An AI incident process differs from a standard IT incident process in three ways:

• The trigger is often a pattern, not an outage. A model that is up and fast but systematically wrong for one customer segment is an incident. Monitoring must look at output quality and outcomes, not only latency and errors.
• Containment options are different. You need the ability to roll back to a previous model version, switch a system to human-only handling, or disable a tool an agent can call, without redeploying the application.
• Root cause spans data, model and process. Post-incident reviews should ask whether the data changed, whether the model or prompt changed, and whether the human oversight design failed, and feed the answer back into the control library.

NIST's Generative AI Profile treats incident disclosure as one of its four primary considerations for the same reason: without a working incident loop, every other control is untested.

What to do in the next 90 days

1. Build the AI inventory. Every system using a model, internally built or bought, with an owner, a purpose, the data it touches and a provisional risk tier.
2. Classify against the EU AI Act where you have EU exposure. Identify Annex III candidates now; 2 December 2027 is closer than a typical build cycle for a regulated model.
3. Adopt a control library of 10 to 15 controls, mapped once to NIST functions, ISO/IEC 42001 Annex A objectives and the relevant AI Act articles. Start from the matrix above.
4. Wire three controls into the delivery pipeline: the evaluation gate, the model or system card, and logging. These generate most of your evidence.
5. Set data handling rules for generative AI by data classification, and enforce them at the gateway rather than in a policy.
6. Run an AI incident tabletop using a realistic scenario, such as a customer-facing assistant giving wrong policy answers, and time it against the Article 73 clocks.
7. Decide whether to pursue ISO/IEC 42001 certification. If customers or regulators will ask for third-party assurance, the management system you are building is most of the way there.

Frequently asked questions

What is the difference between NIST AI RMF and ISO/IEC 42001?

NIST AI RMF is a voluntary risk framework that describes what AI risk management should cover through four functions: Govern, Map, Measure and Manage. ISO/IEC 42001 is a certifiable management system standard that requires an organization to run AI governance as a managed, audited and continually improved system, with 38 reference controls in Annex A. Most enterprises use NIST to scope risks and ISO/IEC 42001 to operate the controls.

Did the Digital Omnibus delay the EU AI Act?

Partly. Regulation (EU) 2026/1744, in force since 27 July 2026, moved high-risk obligations for Annex III systems to 2 December 2027 and for Annex I product-related systems to 2 August 2028. Prohibitions, general-purpose AI obligations and Article 50 transparency duties were not delayed, and new prohibitions apply from 2 December 2026.

What should a model card contain?

At minimum: intended use and users, uses that are out of scope, the data used for training and evaluation, performance results including across relevant groups, known limitations and risks, human oversight arrangements, and version history. It should be generated or updated for every released version.

Do we need a separate responsible AI program for generative AI?

No. Extend the same control library with generative-specific controls: data handling rules by classification, adversarial testing, grounding and confabulation checks, and content provenance. Separate programs create duplicated evidence and gaps between them.

Sources and further reading

• NIST AI Risk Management Framework (AI RMF 1.0), National Institute of Standards and Technology, 26 January 2023, with 2026 updates on revision and profiles.
• Generative AI Profile, NIST AI 600-1, NIST, 26 July 2024. The twelve generative AI risks and four primary considerations.
• ISO/IEC 42001:2023 AI management system, ISO/IEC, December 2023.
• ISO/IEC 42005:2025 AI system impact assessment, ISO/IEC, 2025.
• Regulation (EU) 2024/1689, the Artificial Intelligence Act, Official Journal of the European Union.
• Regulation (EU) 2026/1744, Digital Omnibus on AI, Official Journal of the European Union, 24 July 2026.
• The Digital Omnibus on AI enters into force today, Lewis Silkin, 27 July 2026. Summary of amended dates and the Article 4 change.
• EU AI Act news: Digital Omnibus on AI, Mayer Brown, July 2026. Bias detection, registration and SME changes.
• BC Tribunal confirms companies remain liable for information provided by AI chatbot, American Bar Association, February 2024. Summary of Moffatt v. Air Canada, 2024 BCCRT 149.
• Model Cards for Model Reporting, Mitchell et al., 2019.
• Datasheets for Datasets, Gebru et al., 2021.

This article is general guidance, not legal advice. Regulatory positions are stated as of 24 August 2026; confirm obligations for specific systems against the current consolidated text of the EU AI Act and with qualified counsel.