What AI Ethics Actually Means for Engineers

Cutting through the buzzwords to what practitioners actually need to care about.

You’ve seen the headlines.

AI is biased.

AI is dangerous.

AI needs to be regulated.

Researchers publish papers. Activists organize. Governments draft legislation. And somewhere in the middle of all of this, you’re sitting at your keyboard trying to figure out what any of it actually means for the system you’re building.

Most of that conversation isn’t aimed at you.

That’s not a criticism of the researchers, the activists, or the regulators. They’re addressing real problems. But their focus is AI as a societal phenomenon, not AI as an engineering discipline. The questions they’re asking, like “should AI be used for this at all?” or “what regulatory framework should govern large language models?”, are legitimate questions. They’re just not the questions a software architect needs to answer on a Tuesday afternoon.

But there’s a different set of questions that don’t get nearly enough attention. What does ethical design actually look like in a system you’re responsible for? now? today? What decisions are you making right now, probably without realizing it, that carry ethical weight? And when something goes wrong, who’s accountable, and what does accountability even mean when a model made the call?

Those are engineering questions. They deserve engineering answers.

What “AI Ethics” Actually Refers To

Let’s get the terminology out of the way, because it’s genuinely confusing.

“AI ethics” is used to mean at least three different things, often in the same conversation.

• Sometimes it refers to high level philosophical principles, such as fairness, autonomy, and human dignity.
• Sometimes it refers to specific technical properties of AI systems, like whether a model’s predictions are equally accurate across demographic groups.
• And sometimes it refers to governance and regulation, meaning the rules and structures that organizations and governments put in place to ensure AI is used responsibly.

All three of those things are real. All three matter. But they’re not the same thing, and conflating them is a reliable way to have an unproductive conversation.

For practitioners, the most immediately relevant layer is the middle one, the technical properties of AI systems. The philosophical principles give us the “why.” The governance structures give us external requirements to satisfy. But the technical layer is where engineers actually have leverage.

It’s where you are making decisions, today.

The Three Zones You’re Operating In

When you interact with AI, you typically interact with it in three distinct zones. Each way carries different ethical responsibilities.

Zone 1 is the zone where you’re building AI systems. You’re training models, designing pipelines, writing the code that makes predictions and decisions. In this zone, your choices about training data, model architecture, evaluation metrics, and deployment configuration are the primary drivers of the system’s ethical properties. The model will reflect your decisions, including the decisions you didn’t realize were ethical decisions.

Zone 2 is deployment and operation. You’re not necessarily building the model itself, but you’re integrating it into a product, configuring it, setting the thresholds, determining when it applies and when it doesn’t. Many engineering teams building AI-enabled systems live entirely in this zone. They buy or license AI capabilities from vendors and embed them into their systems. The ethical responsibilities here are different from the first zone. You didn’t choose the training data. But you chose to deploy this system, in this context, to these users. That’s a choice with ethical consequences.

Zone 3 is consumption. You’re using AI tools in your own work. Code completion, documentation generation, automated testing. AI is an assistant helping you build better applications. Here the stakes are often lower, but they’re not zero. What are you doing with AI generated output that you haven’t verified? Where are you letting the tool make decisions you should be making yourself?

You may touch all three zones regularly. Some engineers may operate in all three zones within a single sprint. And you may not even think about which zone you are in.

Yet, the zones carry different responsibilities. Naming which zone you’re operating in changes how you think about what you’re accountable for.

Ethics Is an Engineering Discipline

AI ethics is not just philosophy. It’s not just compliance. It’s an engineering discipline with measurable properties, testable outcomes, and design patterns that either support or undermine ethical behavior in a system.

Think about what that means in practice.

Take fairness. In most teams, fairness is treated as a value, something you aspire to, something you put in a mission statement. But fairness is also a measurable property with distinct definitions that your team could choose to optimize for. Most teams haven’t made that choice consciously. The model has made it for them.

Think about accountability as an architectural question. Does your system log enough context to explain any decision it makes after the fact? Can a human review and override the output? The system will be wrong sometimes. When that happens, is there a clear escalation path?

These are design decisions. They need to be made deliberately at design time, or they won’t be made at all.

Transparency works the same way. Publishing a statement about your responsible AI commitments is a governance exercise. Transparency in the engineering sense is something entirely different. It’s whether the people affected by your system’s decisions can understand why those decisions were made, and whether they have any recourse when those decisions are wrong.

One is a policy document. The other is an architectural property you either build in or leave out.

The difference between a system that respects people and one that doesn’t usually comes down to choices that engineers make, often without realizing those choices have ethical dimensions at all.

That’s where the leverage is.

Who This Newsletter Is For

AIligned is written for engineers and architects who actually build and operate AI systems. People who want to do this work well, and who recognize that “doing it well” includes the ethical dimensions of the systems they ship.

Each issue will take one concrete piece of this puzzle and look at it from a practitioner’s angle. Sometimes that means establishing vocabulary and mental models that the general discourse leaves frustratingly vague. Sometimes it’s a case study of a real system that failed in an instructive way, with lessons you can carry back to your own work. Sometimes it’s a practical walkthrough of a specific technique, like how to audit a model for bias or how to build an audit trail that actually supports accountability.

The goal is always the same. To help you build AI systems that treat people well.

It’s not a simple goal. None of this is simple. But it’s engineering. And engineers are good at hard problems.

Lee Atchison is a software architect, author, and technology thought leader. He is the author of Architecting for Scale (O’Reilly) and The Software Conductor, and was the founder and CTO of Product Genius, an AI startup. He writes about software architecture, cloud systems, and AI at Software Architecture Insights.