Process
How I think about responsible AI
Responsible AI isn't a review you run before launch. It's a way of designing that changes what you build from the first decision — and in a few important places, it runs directly counter to how product design is usually taught. Here's the thinking underneath every engagement.
Principle 1: Design for the user in the worst state, not the average one
Standard product design optimizes for the typical user having a typical day, then handles the edge cases if there's time. In most software, that's the right economy — most people are near the middle most of the time.
Health AI breaks that logic, because the cost of failure isn't evenly distributed. A mediocre experience mildly annoys someone who's fine. A missing safeguard can genuinely harm someone who's frightened, in pain, in crisis, or not in a state to question what a screen is telling them. When the worst outcome lives at the edge, the edge stops being an edge case — it becomes the case that matters most. So I design for the person least able to absorb a wrong answer, and let the typical user inherit a product that was built carefully enough for someone who needed it more.
Principle 2: Design the failure path before the success path
Most teams design what a feature does when the AI is right, ship it, and treat "what if it's wrong" as an error state to patch later. That order is backwards for anything giving people health answers.
The real risk in a health AI product isn't a confident correct answer — it's a confident wrong one, delivered to someone with no reason to doubt it. That's not an edge to clean up at the end; it's the central thing the design has to account for. So before I design what the product says when it's sure, I design what it does when it isn't: where it hedges, where it holds back, where it hands off to a human, where it puts friction in front of a decision that shouldn't be made on the AI's word alone. Get the failure path right and the success path is easy. Do it in the other order and the failure path never really gets designed at all.
Principle 3: A disclaimer is not a safeguard
The most common way products "handle" AI risk is a line of fine print, filed wherever it's least intrusive and most legally defensible. It protects the company on paper and does almost nothing for the person actually using the product.
A real safeguard is designed into the moment the risk occurs. It's how the interface signals what it knows versus what it's guessing, at the point where the user is about to act on it — not buried in settings, not a wall of text nobody reads at signup. Responsibility that lives where it's convenient to file isn't responsibility; it's documentation. The work is putting it where the user actually is, at the moment it actually matters.