Turning the OECD AI Principles Into Corporate Duties

The demo always feels clean. Then the inputs get messy, the edge cases show up, and the first “small” model tweak lands as a large business fact. I feel the pressure right there: everyone wants speed, no one wants blame, and the work that matters most is the work you can prove later.

Start with who is responsible for harm

Human-centered values sound good until someone has to own the consequences. When a system can mislead, discriminate, or cause real-world harm, the duty is to name the responsible role and make that role show up in records. First step: assign one accountable function for each AI use case and require a written approval gate that links the use case to that function, with dates and owners.

Demand transparency that someone else can verify

Transparency is not posting a vague statement. It is providing enough detail that an internal reviewer, an auditor, or an external investigator can understand what the system is doing and why the company chose it. First step: create an “AI system fact sheet” for each model deployment that includes purpose, data sources categories, main limitations, and what changed between versions.

Prove robustness with failure evidence, not confidence claims

Robustness, security, and safety do not live in confidence scores. They live in observed behavior under stress, including distribution drift, adversarial inputs, and failure modes you did not predict at launch. First step: run a documented pre-launch robustness test suite, then store the results and the pass or fail criteria so a later reviewer can see what was actually checked.

Build evidence of accountability before the system is retired

Accountability fails when it only exists at launch. The duty is to keep decision trails through upgrades and retirement, so the company can explain not only what it built, but what it stopped maintaining and when. First step: require versioned change logs for every meaningful model or workflow change, and add a retirement plan field with an end date and owner sign-off.

Manage risk like a living workflow

Risk management cannot be a one-time workshop. It must connect threat modeling, legal and operational review, and controls that are actually used when the system runs in the world. First step: for each AI use case, maintain a risk register that lists risks, likelihood and impact ratings, controls, and current status, and review it on a fixed cadence tied to model or policy changes.

Monitor performance and drift with defined thresholds

Monitoring is not “we watch it.” It is measuring outcomes, detecting drift, and having triggers that force a decision. If you cannot say what you will do when metrics slip, your monitoring duty is only hope. First step: define monitoring metrics and thresholds in advance, then write down the response decision tree for each threshold breach (pause, rollback, retrain, or human review).

Create an incident response that treats AI as a source of events

Incident response for AI must handle both technical and harm events, including incorrect outputs, unsafe behavior, and misuse that the model enables. The duty is to have a process that can be executed fast, with clear roles and evidence capture. First step: draft an “AI incident playbook” that includes severity levels, who decides, what data to preserve, and the timeline for initial assessment and containment actions.

Protect human-centered values with human-in-the-loop limits

Human-centered values fail when “human review” becomes a rubber stamp. The duty is to specify what humans must do, under what conditions they must intervene, and what they are allowed to override. First step: define a review policy for high-risk outputs that sets when the system must escalate to a human, what information the reviewer sees, and what override requires documentation.

Make “explainability” practical for the job people actually do

Explainability is useful only if it helps someone make a decision or stop harm. The duty is to ensure the explanation artifacts are tied to the workflow, with human users trained to use them and with logs that show when explanations mattered. First step: pilot explanations with the real operators who approve outputs, and record whether they can identify the reason for rejection or escalation from the explanation the system provides.

Tie every approval to measurable controls

A governance committee can become theater if it approves without proof. The duty is to require evidence that controls were tested, reviewed, and will be monitored, not just that someone said the right words. First step: convert approval requirements into a checklist of artifacts you must attach, such as fact sheets, risk register entries, robustness results, monitoring setup proof, and the incident playbook reference.

When you can show the work behind the principle, it stops being a slogan and starts being a choice you can stand behind. After the Demo is where this matters most, because that is when metrics drift, failures repeat, and accountability either has evidence or it does not.