Responsible AI is the work of making a system's outcomes defensible, and it is normally introduced as a values conversation, which is precisely where it starts going wrong. Look at pilots that reach a working prototype and then stop moving, and the blocker is hardly ever the modelling. It is that nobody can produce a lawful basis for the data the thing learned from. It is that the business owner declines to put their name to automated decisions they cannot explain to a customer who rings up angry. It is that the only available answer to what happens when it gets one wrong is a shrug, so nobody with a risk mandate will sign. None of those are ethical objections. They are unanswered engineering and governance questions, they are cheap to answer while a system is still a sketch, and they become ruinously expensive once a board has already been shown a working demo and told to expect it by spring. Deferring them does not remove them; it converts them from requirements into cancellations.
- Whose data trained this, and were they told? Training material is personal data far more often than teams admit, and retention and consent are design decisions taken early or discovered late.
- Who is accountable for a wrong decision? A named person, not a team. The model did it has never survived contact with a regulator or a court.
- Can an affected person get an explanation and a way to appeal? If the only available answer is that the machine-learning model scored them low, you do not yet have a deployable system.
- What did the training data inherit? Historical records encode historical decisions, so any pattern that used to be true of your organisation is a pattern the model will reproduce and present as neutral arithmetic.
- What is monitored after launch? Fairness measured once before release is a snapshot of a moment, and the world that produced the training data keeps moving.
Regulation is what has moved this from a values statement to a delivery constraint, with the European Union's AI Act the clearest instance: obligations scale with how much harm a use case could do, and the categories are written around applications rather than techniques, so what your system is used for matters more than which library built it. That structure is worth internalising even outside Europe, because it matches how customers and insurers are starting to ask their questions too. The starting point in practice is not a framework or a committee. It is visibility. Write down what each system learns from, what it decides or influences, who owns that decision, and what a wronged person can do about it. Most published guidance, from model documentation templates to statutory risk tiers, is a structured version of exactly those four lines, and a team that can answer them on one page is further along than one with a signed policy and no inventory.