AI ethics in product work is the practical business of deciding who is accountable for an AI system's output, what data it is allowed to see, and what happens when it is wrong. It is a set of design decisions, not a values statement, and each one has a right answer you can write down.
The questions that actually matter
Abstract principles are easy to agree with and hard to act on. These five are answerable.
- Who is accountable for the output?
- Name a person or a role. "The model decided" is not an answer anyone can act on, and it is not one a regulator or a client will accept.
- Can a person review it before it has an effect?
- The difference between a system that drafts and a system that acts. Where the cost of being wrong lands on someone else, a human step is not friction, it is the design.
- What data goes in?
- Specifically: whose personal data, under what basis, and does it leave your infrastructure. Most AI-ethics incidents are data-handling incidents.
- Can the user tell it was AI?
- Disclosure is cheap. Discovering an undisclosed AI system after the fact costs trust you do not get back.
- What happens when it is wrong?
- Not if. Is the error visible, correctable, and traceable to what the model was given?
Draft versus decide
The most useful line to draw in a product is between systems that produce a draft for a person to approve and systems that take an action on their own. Drafting is low-risk and the value is real - the human is still accountable and still reading. Acting autonomously is where the hard questions live, and it needs a much stronger justification than "it is usually right".
Show the sources
An AI output you cannot trace is one you have to take on faith. Linking what a model was given - which document, which meeting, which figure and when it was measured - turns an assertion into something a person can check in seconds. It is the single cheapest thing you can build to make an AI feature trustworthy, and it also makes it more useful.
Automation bias is the risk nobody plans for
People approve machine output more readily than they would approve the same thing from a colleague, and the effect gets stronger as the system gets more accurate. So a review step degrades over time unless the interface actively supports scrutiny - showing what changed, what the source was, and what the model was unsure about. A rubber-stamped review is worse than no review, because it manufactures accountability without providing any.
Frequently asked questions
Is it enough to have a human approve the output?
It is necessary and not sufficient. The review has to be one a person can actually do - which means showing the sources, flagging uncertainty, and not presenting forty items in a way that makes bulk approval the only realistic option.
Do we have to tell users AI was involved?
Increasingly a legal question depending on where you operate, and always a trust question. Disclosure costs a sentence; being found out costs considerably more.
What about training on customer data?
Treat it as a data-protection decision with a lawful basis and a clear notice, not as a technical default. "It was in our terms" is not the same as a customer having understood it.
How Spectr helps
Write user stories your developers can actually start
Draft stories with real acceptance criteria, then approve, edit or reject each one
Related terms
Spend less of the week on documents
Spectr drafts the spec, the requirement document and the stories from your meetings. You review and approve.
Free plan available. 30-day free trial on Starter.