Ethics is not a role that can be assigned

One of the major AI providers had appointed a head of AI ethics in August 2025. Just under a year later, she had left and the post remained unfilled. According to consistent reports from August 2026, she was the only person in the company whose remit was explicitly defined as ethics. In the same month, two more senior executives from the fields of security and model alignment left the company.

What is interesting about this development is not so much the departures themselves as the rationale given to explain them. Ethical issues, the company claimed, are not limited to a single person or a single team, but are firmly embedded in the model development carried out by several research teams.

This statement is correct. That is precisely what makes it problematic.

Ethics should indeed not be delegated to a single person. However, as a justification for not having a dedicated role, this is only convincing if the organisation ensures in other ways that ethical considerations are taken into account in its decision-making.

Why ethics cannot be delegated to a single role

A single ethics role has a fundamental flaw in its design. It sits at the table when decisions are being made about timetables, market windows and budgets, yet represents a concern that does not generate immediate revenue. Its objections may be taken into account, but they can just as easily be overruled. Under economic or time pressure, the likelihood increases that other interests will be given greater weight.

The manufacturer Axon, known for its Tasers and bodycams, had set up a dedicated AI ethics committee. It comprised thirteen experts from the fields of computer science, law, civil rights and policing. In the spring of 2022, the company presented plans for drones equipped with Tasers in schools. The committee had already voted eight to four against even a strictly limited pilot study. Axon announced the project anyway. As a result, nine of the thirteen members resigned. It was only this public resignation that halted the project, not the preceding ethical assessment. [1]

This example illustrates the limitations of an advisory ethics committee. It was permitted to review, advise and object, but had no binding influence on the decision. It only had an impact when nine of its members resigned and made the conflict public.

This does not fundamentally argue against ethics committees or specialised ethics roles. They can contribute expert knowledge, highlight blind spots and ask uncomfortable questions. However, they cannot assume the ethical responsibility of the decision-makers. Problems arise when the organisation considers its responsibility to be fulfilled simply by establishing such a body.

Added to this is a ‘relief effect’, which can carry greater weight than the limited decision-making power. As soon as there is someone whose job is ‘ethics’, the line of responsibility seems clear. The product team develops what has been specified, those in charge point to the review that has taken place, and in hindsight it can be demonstrated that the organisation has taken the issue into account – at least formally.

Ethical considerations must therefore be embedded where decisions are made: in architectural discussions, when formulating requirements, and during reviews and approvals. The statement with which the company explained the failure to fill the vacancy thus certainly describes a reasonable state of affairs. However, it can just as easily describe a situation in which nobody feels responsible any longer. From the outside, both sound the same at first.

What ethics means within an organisation

In this context, ethics is neither a synonym for the law nor for compliance. The law determines what an organisation is permitted to do. Compliance is intended to ensure that rules and guidelines are adhered to. Ethical deliberation becomes particularly necessary where several legally permissible options exist and an organisation must decide which of these it is prepared to take responsibility for.

In the case of AI systems, for example, this concerns questions such as which decisions may be automated, what data should be used, or when a human must intervene. It is not simply a matter of whether a system works technically. It is also crucial to consider what consequences its use has for those affected and who takes responsibility for them.

Organisational ethics is therefore not primarily reflected in mission statements or job titles; it becomes apparent in specific decisions.

How to recognise embedded ethics

The meaning of the term ‘embedded’ is determined by three questions. These apply just as much to a software house as they do to a mechanical engineering firm with three hundred employees.

1. Is there a name behind a specific decision?

Take any decision made in recent months that affects people: automated pre-sorting, a scoring system or customer communications without human review. Ask who is responsible for this decision.

If a person is named, responsibility is clearly assigned. If reference is made only to a process, a committee or ‘the team’, it is worth asking for clarification. Shared responsibility makes sense, but it must not result in no one ultimately feeling accountable for the specific decision.

This does not mean that a single person should answer all ethical questions on their own. Several experts can and should provide advice. However, the decision must be made and responsibility assumed by someone who can be named.

2. Has anything ever been rejected on ethical grounds?

Genuinely embedded ethics leaves its mark. A feature was scrapped. A data source was not included in the training. A supplier was not selected for a reason other than price. Automation was limited to support functions, even though more would have been technically possible.

If no one can cite such an example, ethical deliberation has apparently never led to an uncomfortable decision so far. That is possible, but unlikely. Ethics that cost neither time nor money and never alter existing plans are likely to have no consequences.

3. Where do ethical concerns end up?

If a developer has a nagging feeling about a requirement, who does she turn to? Does she know the procedure without first having to look for a guideline? Can she raise the issue without being seen as an obstacle to the project? And what happened the last time such a concern was raised?

An escalation procedure that nobody knows about or dares to use is of no help in an emergency. An ethical framework therefore requires not only a formally documented process, but also the assurance that well-founded doubts will be taken seriously.

Three questions, an afternoon and a few concrete examples are often enough to gain an initial impression. The result is usually more meaningful than a guideline on the intranet.

Why companies still create ethics roles

The approach of establishing a dedicated role is appealing, and the reasons for this are understandable:

• An ethics role can be created quickly. It can be approved at a board meeting and filled within a few weeks. Changing a structure takes longer. It affects areas of responsibility, decision-making processes and routines that have often developed over many years.
• A role is also visible. It appears in the sustainability report, in the organisation chart and in responses to auditors. An allocation of ethical responsibility that is embedded in tickets, reviews and approvals is more difficult to communicate externally.
• And finally, a role provides a single point of contact for questions that would otherwise have to be dealt with in many different places simultaneously. This can be helpful, especially when an organisation is only just beginning to systematically address the consequences of its AI usage.

That is why the question currently under discussion – whether companies need a Head of AI – cannot be answered with a simple yes or no. [2] Such a role can be useful if its remit is to build up knowledge, develop processes and integrate ethical considerations into the work of the various departments.

It becomes a problem, however, if it permanently replaces these structures. In that case, the role becomes a place to which ethical questions are passed on, rather than a starting point for addressing them collectively.

How ethics are embedded in decision-making

For the concept of embedded ethics to be viable, four verifiable elements are required:

1. Classification by scope

In collaboration with the departments responsible for the relevant processes, the following should be clarified: Where is AI permitted to act autonomously? Where is it permitted only to make suggestions? Where must a human make the decision? And in which situations should no automated system be involved?

Such decision-making zones make it clear that not every use of AI can be assessed by the same standards. A drafting tool for internal documents has a different scope to a system that pre-sorts job applications or assesses credit risks.

2. One designated person per decision-making area

Responsibility for machine-assisted decisions affecting people should lie with a designated individual. This person does not have to carry out every assessment themselves, nor do they have to decide on all ethical issues alone. However, they must ensure that the necessary weighing up of interests takes place and is documented.

Expert advice, an ethics committee or external support can assist with this responsibility, but cannot replace it.

3. Documentation where decisions are made

Anyone who sets a threshold, selects criteria or defines an escalation path should briefly document why the decision was made in that way. This does not require a lengthy treatise; often, fifteen clear lines in the ticket or review are sufficient.

It is important that the ethical justification is not filed separately from the professional and technical decision. It should be located where it will later be possible to trace how and why a system was developed.

4. A fixed schedule for ethical review

This point is frequently overlooked, although it can quickly undermine the other three. A classification made once becomes outdated at the same rate as tools, models and use cases change.

Model versions are discontinued, successors behave differently in borderline cases, data sets change, or a system that initially provided support is granted additional authorisations. Last year’s approval remains formally valid, even though the conditions on which it was based are no longer the same. Without a fixed schedule for re-evaluation, an organisation may only become aware of such shifts when a complaint or incident arises.

None of this is particularly dramatic. It does not require a new department, but it does require binding decisions and people to make them.