OECD AI Principles: What the 2024 Revision Requires as Evidence

The OECD AI Principles changed on 3 May 2024. The revision added or strengthened language on general-purpose and generative AI; information integrity and reasonably foreseeable misuse; privacy and intellectual property; lifecycle safety; override and decommissioning mechanisms; and environmental sustainability. Those additions turn a familiar principles document into a sharper evidence problem.

The official OECD principles page still organizes the recommendation around five values-based principles and five recommendations to policymakers. The useful implementation test sits one level lower. A team needs an artifact proving that it acted on each principle during an incident review. A policy PDF proves approval, but says very little about the request an authenticated employee sent to a model at 4:47 p.m. on a Friday.

TL;DR

• The OECD recommendation was adopted in 2019 and revised most recently on 3 May 2024.
• The 2024 language expands the evidence burden around generative AI and foreseeable misuse; information integrity and lifecycle safety; privacy and intellectual property; and override and sustainability.
• No governance register or model card, including one connected to a single gateway, proves the whole recommendation.
• Routed-request records support a narrow slice: identity and purpose; destination and classification; policy version and outcome; and time.

The 2024 revision changes the evidence question

The OECD Recommendation on Artificial Intelligence was adopted on 22 May 2019, then amended on 8 November 2023 and 3 May 2024. Its structure remains compact: five values-based principles sit beside five recommendations directed to policymakers. The 2024 revision updates the language for systems and risks that became harder to treat as edge cases, especially general-purpose and generative AI.

That history matters because an organization may have mapped its controls against the 2019 text and assumed the work was finished. The newer language asks for evidence across a wider operating surface. Information integrity needs different proof than model safety. Environmental sustainability needs different records than a human override. Privacy and intellectual property concerns can arise in the data used to build a model and in a prompt sent during ordinary use.

I would reject any OECD control map with one green cell labelled "AI gateway." It is neat, comforting, and wrong. The recommendation crosses organizational governance and model evaluation, along with operational response and live request handling.

Lifecycle and governance records

Lifecycle evidence begins before an HTTP request reaches a model. An AI inventory should identify the system and owner; approved purpose and affected users; dependencies and current status. Governance records should show who approved deployment and which risks were accepted. They should also record when the decision was reviewed and who holds authority to suspend use. The 3 May 2024 revision's attention to safety across the lifecycle makes a launch-day assessment an incomplete record.

The physical test uses a conference-room screen and one deployed assistant. A reviewer should be able to find its owner and intended use, its last assessment and escalation contact, plus its retirement state without opening six browser tabs and messaging the engineer who built it. If those facts live only in a slide deck, the program has a presentation artifact rather than an operating record.

This is the territory covered by an AI accountability framework and a broader AI governance strategy. An HTTP enforcement layer can contribute runtime records. Executive ownership and proof of a board-approved risk process belong to the governance program.

Model evaluation and system assessment

General-purpose and generative AI require evidence about the model and the configured system. That evidence can include evaluation scope and test cases, plus known limitations and review dates. It should also include the decision that followed a failed test. The OECD revision's focus on misuse and reasonably foreseeable misuse makes the evaluation set especially important. A team needs to document which misuse cases it considered and how those cases affected deployment conditions.

This work happens before and around inference. It belongs with model evaluation and red teaming, as well as data governance and change control. A request log can show that a policy blocked a classified prompt. Model test results, training-data provenance reviews, and fairness assessments require separate evidence.

The NIST AI RMF implementation work already separates governance and mapping from measurement and management activities. Apply the same discipline to the OECD principles. Evaluation artifacts support claims about model behavior. Runtime decision records show what the organization permitted during use. Mixing the two produces weak evidence for both.

Human override and incident procedures

The 2024 revision strengthens the expectation that systems can be overridden or repaired when they create undue harm or exhibit unwanted behavior. They can also be decommissioned. Evidence therefore needs to name the person authorized to stop the system and the conditions that trigger action. It should also record the decision and verify that traffic stopped or the affected route moved to a safer configuration.

A credible incident package contains the approved procedure and named authority. It also contains the incident timeline and decision record, with verification that the intervention took effect. The procedure should also distinguish a model rollback from a route block. One changes the deployed artifact. The other prevents selected callers or data classes from reaching a destination. They can happen together, but they leave different evidence.

At 2:13 a.m., nobody wants to discover that the "kill switch" is a paragraph in a governance manual. I think override tests should be scheduled and recorded, even when mildly inconvenient. DeepInspect can enforce a changed policy on deliberately routed HTTP traffic. Local-model decommissioning and model-weight repair sit outside that boundary. Incident command does too.

Routed-request enforcement and evidence

The request boundary supplies a narrow, high-resolution evidence stream. For an authenticated user or agent sending HTTP traffic to an LLM, a policy decision can record the supplied identity and role; stated purpose and model destination; prompt classification and policy version; and allow or block result with a timestamp. That record shows what the enforcement point decided for this request under the policy active at that moment.

The record exposes the post-authentication gap. Authentication identifies a caller. Per-request authorization decides whether that caller may send this data to this model under the current policy. The responsible AI governance program needs both the policy record and the production decision record.

Mark the exclusions in the same evidence map. Routed-request evidence leaves model fairness and training-data provenance to other systems. Environmental impact and labor effects also sit elsewhere, as do model explainability and organization-wide accountability. It also says nothing about local inference or traffic that bypasses the designated HTTP route.

DeepInspect

DeepInspect covers the routed-request slice of this evidence map. It sits as a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. The application supplies identity context. DeepInspect evaluates the request against identity-aware policy. It applies the configured allow or block action, including redaction where configured, and produces a per-decision audit record.

DeepInspect contributes evidence about live HTTP requests and responses routed through it. Model evaluation, training-data governance, explainability, environmental measurement, local inference, and organization-wide accountability remain with their respective owners.

Book a technical deep dive at deepinspect.ai.