Why Principles Do Not Reach the Product

A large majority of organisations deploying AI have published principles. Fairness, transparency, accountability, human oversight, privacy, safety. They are broadly the same everywhere, which is itself informative.

The question that exposes the gap is simple: name a product decision that came out differently because of them.

Most organisations cannot answer. Not because the principles are insincere, but because a principle and a decision are different kinds of object. A principle states a value. A decision requires choosing between options under constraint, and a value that is not attached to a decision rule provides no purchase on that choice.

Consider what happens when a team building a screening tool consults a commitment to fairness. Fairness between whom, measured how, traded against what, and decided by whom? The principle is silent on all four, so the team resolves them implicitly, and the resolution reflects whatever the delivery pressure suggested. The principle was consulted and did no work.

That is the operational failure this cursus addresses. Not a shortage of good intentions, which are abundant, but the absence of machinery that converts them into constraints on specific choices at the moment those choices are made.

Comparing a principle with something that does bind shows precisely what is missing.

A specified subject. We will be fair does not say to whom. A working rule names the populations: applicants by age band, by disability status, by the language they applied in. Naming them is uncomfortable and it is what makes the commitment checkable.

A measurement. Fairness has multiple mathematical definitions that cannot all hold at once, and choosing among them is a substantive decision. A principle that does not choose has deferred the actual question to whoever writes the evaluation.

A threshold. What level is acceptable, decided before the result is known. Without one, any measured disparity gets assessed against a bar set after seeing it, which is the same failure the release gate lesson identified.

And a consequence. What happens when the threshold is not met. If the answer is a discussion, the principle is advisory. If it is that the feature does not ship until it is met or an accountable person accepts the risk in writing, it binds.

Those four turn a value into a control. Notice that none of them requires resolving the underlying ethical question in the abstract. They require deciding it for this system, which is tractable in a way the abstract version is not.

Where principles exist without machinery, they perform a function even so, and it is worth being clear-eyed about what it is.

Published commitments provide reputational cover, satisfy procurement questionnaires, and answer a board question. That value is real and it is entirely available without changing any decision, which is what makes the arrangement stable. The term for it is ethics washing.

The accusation is easy to make and hard to substantiate, so it is more useful to have diagnostic questions than an opinion.

Has a launch ever been delayed or stopped on these grounds? A programme that has never cost anything has never bound anything.

Who can say no, and what happens when they do? If the ethics function advises and the product function decides, the outcome is determined by the second.

Are the principles measured? An unmeasured commitment cannot be breached, which means it cannot be kept either.

Is the review at the start or the end? A review after the architecture is fixed and the launch date is set can produce recommendations and cannot produce changes.

And where do the people doing it report? A function reporting to the team whose work it assesses has the structural problem the governance cursus describes.

These questions are also worth asking of your own programme, where the answers are more useful and less comfortable.

The chain that has to be complete for a principle to affect anything, and the point at which most programmes stop.

A value states what matters. A commitment applies it to this organisation. So far this is a document.

The conversion happens next. For a specific system, name the affected populations, choose a measurement, set a threshold in advance, and attach a consequence to missing it.

That produces a check, which can be run at a defined moment by a named person, with a defined outcome.

Most programmes complete the first two boxes and stop, then wonder why nothing changed. The three that follow are the whole difference between a statement and a control, and each is a small piece of work rather than a philosophical undertaking.

There is a reason organisations stop at the commitment, and it is not only convenience. The abstract questions genuinely are hard, and teams sensibly avoid work with no end.

Fairness has several formal definitions, and results in the algorithmic fairness literature show that key ones cannot be satisfied simultaneously except in degenerate cases. So an organisation attempting to define fairness in general is attempting something that has been shown to have no single answer.

Transparency conflicts with security, with privacy, and with intellectual property, and no general rule resolves those trade-offs.

Human oversight conflicts with the efficiency that motivated the automation.

An organisation that waits for the abstract questions to be settled waits indefinitely, and in the meantime ships systems governed by nothing.

The move that unblocks this is narrowing the scope. Which fairness definition is appropriate for a screening tool where false negatives exclude qualified applicants is answerable. Which is appropriate in general is not.

So the operational principle is: decide per system, record the reasoning, and accept that the answer will differ elsewhere. That feels less satisfying than a universal policy and it is the only version that produces decisions. It is also, not coincidentally, exactly what the AI Act's contextual language asks for.

To attach controls to decisions, you have to know where the decisions are. They are rarely in the meeting labelled as being about ethics.

The consequential ones, in roughly the order they occur.

Whether to build this at all, and for what purpose. The largest decision and the one least often examined, because by the time a governance process engages, the answer has been assumed.

What data to train or ground on, which determines who the system works well for.

What to optimise. A model optimising for interview acceptance rate learns from historical decisions and inherits whatever those decisions encoded. The choice of objective is an ethical choice made in technical language.

Where the threshold sits, which distributes errors between false positives and false negatives, and therefore between different groups of affected people.

How much autonomy the system gets, which determines whether a human is between the output and the consequence.

What the interface shows, which determines whether oversight is possible at all.

And what happens when someone challenges the outcome.

Notice that most of these are made by engineers and product managers in the ordinary course of building, not by anyone who considers themselves to be making an ethical decision. That is precisely why the controls must live in the build process rather than in a separate review, which the next lesson takes up.

The structural feature that distinguishes this from ordinary product quality: the person most affected by these decisions is absent from every meeting where they are made.

A product team has proxies for the user, in research, feedback and support tickets. It has none for the applicant who was screened out, the claimant whose case was deprioritised, or the person a moderation system removed. Those people are not customers, they did not choose to be subject to the system, and many never learn a system was involved.

So their interests are represented only if someone in the room takes that role deliberately, and the default is that nobody does. Everyone present is optimising something legitimate: delivery, cost, accuracy, revenue. The absent party's interest is not opposed, it is simply unrepresented, and unrepresented interests lose by default rather than by argument.

This is the same empty seat the AI governance role cursus identifies in the governance committee, and it is the reason responsible AI cannot be folded into ordinary product quality practice.

The operational responses are modest and real. Name the affected populations explicitly in every assessment, so their existence is on the page. Assign someone to argue their position in review. And where feasible, actually consult them, since affected communities can identify failure modes that no internal analysis surfaces.

Without that, the machinery in the next lesson optimises for the organisation, competently.

Before building the machinery, it helps to know what it is aiming at, stated as observable properties rather than aspirations.

A team building an AI feature encounters the relevant questions inside their normal process, at a point where the answers can still change the design.

The questions are specific enough to answer, and answering them produces a recorded decision rather than a discussion.

At least one launch has been delayed, narrowed or stopped on these grounds, and people can name it.

The measurements exist, are run, and have thresholds set in advance.

Someone independent of delivery can say the bar is not met, and that has consequences.

Affected populations are named in writing on every assessment, and someone is accountable for representing them.

And when something goes wrong, the review examines the decisions that led there rather than only the technical failure.

Notice what is absent from that list. A dedicated ethics board, a lengthy principles document, a maturity score, and a training programme are all things organisations build first and none of them appear. They are not harmful, and they are not the mechanism.

The mechanism is a small number of specific questions asked at the right moment with a consequence attached, which is what the next lesson builds.