The headlines are familiar: an AI agent escaped its sandbox, bypassed a restriction, or found a way to do something its operators did not intend. There is no need to dissect those reports here. The more useful question comes before the incident: what did the system learn about when not to succeed?
That question deserves more than a promise to improve safeguards. It asks whether the principles an organization publishes have any meaningful relationship with the behavior its training process encourages, and whether anyone is responsible for examining the distance between the two.
There is no shortage of language for the behavior society wants from machines. Asimov's fictional laws of robotics made restraint central to the idea of a capable robot. Decades later, IBM itself recalls a line attributed to a 1979 training manual: computers cannot carry accountability, so management decisions should not be handed over to them. Neither is a complete answer for contemporary AI. Both make an uncomfortable starting point for the conversation.
The ambition was never simply to make machines more capable. It was to make capability conditional on something more important than finishing the job.
A principle becomes interesting when it costs you something
It is easy to endorse responsible AI while nothing is at stake. Ask whether an organization values fairness or privacy and the answer is unlikely to surprise you. Ask which useful capability it would delay, constrain or decline to protect those values, and the conversation becomes considerably more informative.
The Harvard DCE discussion of responsible-AI principles is useful here, not because its vocabulary is unfamiliar, but because it acknowledges that desirable objectives can pull against each other. More transparency about data, for example, can create a privacy problem. Naming both principles does not settle the trade-off.
That is where a training discussion should begin. What should a model do when fulfilling a request conflicts with another expectation? Who decides which consideration takes precedence, and how does that decision become something the model is taught rather than something the organization merely believes?
Consider a hypothetical assistant asked to produce a customer briefing before an important meeting. Some information is approved for that purpose; other information is accessible somewhere in the environment but has not been authorized for this use. The requested result could be more complete if the assistant used everything it could find.
There are now at least two ideas of success. One is a richer briefing delivered on time. The other is a briefing that respects the information boundary, even if it is less complete, or a request for clarification before proceeding.
No principle has disappeared. Privacy still matters, and usefulness still matters. The difficult work is deciding what their relationship means in this situation. If the organization cannot articulate the correct outcome for its own hypothetical example, asking a model to “follow our responsible-AI principles” postpones the decision rather than resolves it.
This is why an ethics statement is not enough of a specification. Before anyone asks whether a model has learned the right behavior, the people responsible for that behavior need to agree on what they would recognize as right.
Teaching principles is already part of the work
It would be convenient to argue that AI developers have concentrated on capability and simply forgotten to teach restraint. It would also ignore published work that makes principles part of training.
In Anthropic's Constitutional AI research, a set of principles guides the generation of critiques and revised responses. Those revisions are used for supervised training. A further stage uses AI-generated preferences to train a preference model, which supplies the reward signal for reinforcement learning. The principles are involved in constructing the feedback from which the model learns, not merely displayed beside the finished product.
That distinction matters. A reward signal is part of how a training process favors some behavior over alternatives. In the Constitutional AI method, the route from principle to behavior passes through judgments about responses and a learned preference model. There is a concrete mechanism to examine: what is being preferred, how those preferences are produced, and how well the resulting behavior satisfies the intended principles.
OpenAI's deliberative alignment research takes another approach: directly teaching safety specifications and training a model to recall and reason over them before answering. The authors report improvements in resistance to adversarial requests, reduced unnecessary refusals, and better generalization beyond the training distribution. These are documented approaches, not an inventory of every current model's training recipe.
The answer to “Are principles involved in training?” is therefore already yes, for published methods. That should move the argument forward, not end it.
A method can make explicit use of principles without establishing that every relevant conflict has been represented, that every preference judgment captures the intended value, or that success in an evaluation transfers to every deployment. Reported improvements are evidence of progress. They are not an unlimited assurance claim.
Nor should the goal be a model that refuses everything difficult. The deliberative alignment research explicitly examines unnecessary refusal alongside safety. A system that will not help with legitimate work has failed a different part of its purpose. The challenge is discrimination: proceeding when it should, asking when it lacks a necessary fact, and stopping when the constraint actually applies.
The serious question is not whether anyone has tried teaching AI to follow principles. It is what the teaching has achieved, where it remains unreliable, and how precisely an organization can describe those limits before putting the model to work.
The definition of success deserves more scrutiny
Return to the briefing assistant. Imagine an evaluation that checks whether the briefing is accurate, complete and delivered in the requested format. Those are reasonable things to measure. They are not sufficient to decide whether the assistant should have used every piece of information it included.
Now imagine that the assistant leaves out a restricted detail and explains why. Does the evaluation recognize a correct boundary decision, or does it count missing information against the result? This is a hypothetical design choice, not an allegation about a particular provider. It exposes how easily a principle can be present in the policy and absent from the definition of a good answer.
Training that uses preferences or rewards makes those judgments consequential. In the Constitutional AI method, the preference model becomes the reward signal. That makes the quality of the preference an important object of scrutiny, not a detail to hide behind the phrase “aligned with our values.”
There is a second distinction to make. A model that can explain why privacy matters has demonstrated something different from a model that handles the briefing correctly when the privacy issue is indirect, the request is urgent, and the missing permission is easy to overlook. An explanation belongs in the evidence. It should not be mistaken for the whole of it.
This does not require inventing an impossible standard under which only perfection counts. It requires matching the assurance claim to what was actually tested. If an evaluation establishes a result under particular conditions, say what those conditions were. If a deployment introduces circumstances outside that evidence, acknowledge the additional uncertainty rather than allowing the word “responsible” to cover it.
The emphasis on generalization in the deliberative alignment research is important for precisely this reason. Learning to apply a policy beyond familiar examples is itself a research objective. The existence of the policy and the ability to apply it in a new situation are separate achievements.
So why does teaching principles not settle the problem? Part of the answer is that teaching is mediated by choices: which situations are represented, which responses are preferred, what counts as an error, and what the evaluation can establish. A principle has to survive that translation. Writing it down does not show that it has.
This is where scrutiny should become more demanding without becoming accusatory. Ask whether correct refusal, clarification and limited completion are represented as successful outcomes. Ask what happens when useful work and a constraint conflict. Ask which conclusions the evidence does not support.
Stopping must be allowed to count as success. Otherwise the organization has not finished defining what it wants, however polished its statement of principles might be.
A management system cannot learn on the model's behalf
This is also where it is tempting to reach for a certificate or a regulation as a more authoritative answer. Surely a recognized framework can settle what an organization ought to do.
It can help organize the responsibility. It cannot turn an organizational commitment into learned behavior by itself. The European Commission describes ISO/IEC 42001 as a standard that helps establish an AI management system. That is a different object from the behavior of an individual model in the briefing scenario.
The distinction should make the standard more useful, not less. The question for management is whether its processes require somebody to examine the training and evaluation decisions that matter, assign responsibility for unresolved gaps, and act on the result. For this article's argument, that is the connection to demand. It is not a claim that ISO/IEC 42001 prescribes a particular reward function or training algorithm.
The EU AI Act has another role again. It is a legal framework, not an alternative set of model weights. The Commission's standardisation guidance distinguishes the Act's legal requirements from the standards used to support compliance, and makes the conditions for a presumption of conformity explicit: relevant harmonised standards must be referenced in the Official Journal. An arbitrary AI-related certificate is not a substitute.
There is an especially useful warning in that same guidance. The Commission says that ISO/IEC 42001's goals and definitions do not align with the quality management system required under the Act, which is why it requested a standard focused on that regulatory requirement. Treating the two as interchangeable would erase a distinction the regulator itself makes.
The point is not to dismiss regulation as another document from Brussels, or to dismiss standards because they cannot guarantee a model's conduct. The point is to stop asking them to do the wrong job. Ethical principles express expectations. Management processes organize responsibility. Applicable law establishes obligations. Training and evaluation must still address the behavior expected from the system.
These layers should inform one another, but evidence does not travel between them automatically. A well-governed process is not proof of every output. A desirable output is not proof of a compliant organization. A model cannot absorb its provider's accountability by being taught to say the right things.
Governance belongs in the training conversation
Ask an organization whether it has responsible-AI principles, a board and champions. Those are worthwhile questions. The next question should be what those people can change.
Can they challenge the definition of a successful task? Can they require evidence for behavior that is inconvenient to the business case, such as refusing a request or completing less work? Can they prevent a release when the organization cannot explain an important gap between its commitments and its evaluations?
Without that authority, governance risks becoming a place where decisions are documented after their consequences have already been accepted. The remedy is not necessarily another committee. It is getting the right questions into the decisions while they are still open.
Microsoft's 2026 Responsible AI Transparency Report page offers a concrete example of making that relationship visible. It connects Microsoft's principles to its Responsible AI Standard, describes risk-management activities, and identifies a central pre-release oversight process. It gives a reader something more specific to examine than an assurance that responsibility matters.
That deserves recognition without becoming an exemption from scrutiny. A company's account of its practices is evidence of what it reports, not independent proof that every system behaves as intended. The valuable next step is to ask what those practices required in a particular decision, what evidence was considered sufficient, and what remained unresolved.
The same distinction applies to buyers who do not train their own foundation models. You cannot inspect or change every part of a supplier's process. You can still ask for the evidence relevant to the behavior you intend to rely on, identify what the supplier has not established, and decide whether your use case can tolerate that gap.
That might mean accepting a narrower task, requiring an additional approval, or declining to deploy the system for a particular purpose. Those are recommendations about how to act on uncertainty, not assertions that every problem can be repaired downstream. Procurement should not convert an unanswered technical question into an assumed assurance simply because the contract is ready.
For developers, the challenge reaches into the training choices themselves. For buyers, it reaches into selection, acceptance and use. Both need a responsible owner capable of distinguishing what is promised from what the evidence supports.
Ask for the lesson, not the slogan
The public discussion does not need another declaration that AI ought to be safe, fair and accountable. It needs more demanding conversations about how those expectations influence the behavior being taught, and what happens when the evidence falls short.
Start with one principle your organization claims to follow. Choose one realistic task in which honoring it makes completion slower, narrower or impossible. Then ask the model developer, the evaluation team and the accountable business owner to explain what the correct outcome is and what evidence shows the system can reach it.
Do not accept a recital of the principle in place of that explanation. Ask how it influenced the training or selection decision, how the relevant behavior was evaluated, and who has authority to reject the result. If nobody can answer, that is a specific governance task to complete, not a reason to accuse an entire industry of indifference.
Published training research shows that principles can participate in the learning process. It also gives a more substantive basis for scrutiny than assuming that a model has either “learned ethics” or has not. The useful work lies in examining the translation, the evidence and the limits.
Before approving the next system, make somebody show what success looks like when the right answer is to do less. Then make sure that person has the authority to insist on it.
References
- Encyclopaedia Britannica: Three laws of robotics
- IBM: AI decision-making: Where do businesses draw the line?
- Harvard DCE: Building a responsible AI framework
- Anthropic: Constitutional AI: Harmlessness from AI feedback
- Guan et al.: Deliberative alignment: Reasoning enables safer language models
- European Commission: Understanding the standardisation of the AI Act
- Microsoft: 2026 Responsible AI Transparency Report
Top comments (0)