Back to Blog

I Ask One Question Before Any AI Launch: Who Isn't Here?

A five-step Bystander Map you can run in one afternoon, with an illustrative clinic example, to find the people your AI will affect before it reaches them.

Direct answer

How can a company find who its AI could harm before launch?

Dr. Jonah Tebaa recommends a one-afternoon exercise called the Bystander Map. List every output the AI produces, name four rings of people each output touches (user, subject, bystander, downstream person), write the worst plausible harm for each ring, add one cheap guardrail for every severe or irreversible harm, and re-run the map when data, channels, or ninety days change.

Overhead view of a dark conference room at night: seven people work heads-down around a walnut table under one warm lamp, an empty chair at the far end, and a woman outside the glass wall lit only by her phone.

The launch reviews I sit in tend to look alike, so here is a composite of them. Seven people around the table: a product owner, two engineers, a designer, someone from operations, someone from sales, and me, brought in to ask the uncomfortable questions. The demo runs cleanly. Everyone in the room is either building the tool or will use it. Nobody is asking whether it is ready, because for the seven of us, it is.

Then comes the question I now ask before every AI launch: who isn't here? The room usually goes quiet, because the honest answer is everyone the system would actually act on. The tool would send messages, rank people, and summarize their records. None of those people would ever see this meeting.

Why Launch Reviews Miss the Affected Person

A launch review is built to answer one question: does it work? The people invited are the ones who can answer it, which means builders and users. That is a sensible guest list for a quality check and a poor one for a harm check.

The gap is structural, not careless. The person a message is about, the person whose phone receives it, and the person who inherits a summary six months later are not customers of the product. They have no login, no feedback channel, and no reason to know the system exists. So their experience never shows up in a demo, a pilot metric, or a satisfaction score.

In my work with companies across Lebanon and the wider region, I see the same pattern. Teams test the AI against the people they can reach. They rarely test it against the people it can reach. That is the difference I try to close, and it takes an afternoon, not a program.

The Bystander Map, Step by Step

I call the exercise the Bystander Map. You need a whiteboard, the people who own and build the product, and one person willing to keep asking who else is affected. Here are the five steps.

  1. List every output and where it travels. A message, a score, a ranking, a summary, a recommendation. For each one, write down where it goes after the system produces it: which phone, which inbox, which file, which colleague.
  2. Name four rings for each output. The user is who operates the tool. The subject is the person the output decides or speaks about. The bystander is a third party whose data, phone, or name gets touched without their involvement. The downstream person is whoever inherits the output later.
  3. Write the worst plausible harm per ring, in one sentence. Plausible, not cinematic. Then tag each with a severity and whether it can be undone.
  4. Attach one cheap guardrail to every severe or irreversible harm. A confirmation step, a narrower scope, redaction, a human check. One guardrail, not a redesign.
  5. Set a re-run trigger. Run the map again when a new data source arrives, when a new channel is added, or when ninety days have passed, whichever comes first.

The discipline is in step three. Writing the harm as a single sentence forces the group to say what could happen to a specific person, instead of nodding at "privacy risk" and moving on.

A Worked Example: Mapping a Reminder Assistant in Ninety Minutes

The following is an illustrative example, not a real client. Picture a mid-sized clinic that wants an AI assistant to send appointment reminders and sort incoming patient messages by urgency. The seven people in the launch review are staff. I ask the question, and we fill in the map.

Output one: the reminder text. The user is the front desk. The subject is the patient. The bystander is the family member, in this case the patient's sister, whose number the patient listed years ago as a secondary contact, and who now receives a text naming the clinic and the specialty. The downstream person is whoever borrows that phone or scrolls that thread later.

The worst plausible harm sits with the bystander ring: a patient's diagnosis-adjacent visit is disclosed to a relative they never chose to tell. Severity is high. Reversibility is none, because nobody can un-read a message.

In the room, nobody had thought of it. The number was in the record, the system was allowed to use it, and the reminders tested perfectly. Nobody in the meeting was the sister.

Output two: the urgency ranking. The subject is the patient who wrote in. The worst plausible harm is a message written in a dialect or in Arabic typed with Latin letters being read as low priority, leaving someone waiting who should not wait. That one gets a human check on any message the system is not confident about.

Of everything on the board, one change mattered most: a confirmation step before any message goes to a secondary contact. The patient, or the front desk on the patient's behalf, confirms that this person may receive this kind of message, and the default wording stays generic. It took a few hours to build. It removed the harm that could not be reversed.

What to Do With the Map

A finished map leads to one of three decisions. Add the guardrail and launch. Launch smaller, to a group where the harm stays contained, and widen later. Or do not launch that feature yet. All three are legitimate. The only bad outcome is the fourth one, where the harm is discovered by the person it happens to.

Keep the map somewhere visible and treat step five as real. New data sources and new channels are exactly when a quiet, well-mapped system becomes a different system.

Three regional details deserve their own line on the whiteboard. First, shared family phones: in many households, one phone serves several people, so a message addressed to a patient or customer may be read by a parent, a spouse, or a child. Second, WhatsApp forwarding: any output sent through a messaging app can be forwarded, screenshotted, or pasted into a family group in seconds, so assume it travels. Third, dialect and language gaps: Lebanese Arabic, Arabizi, and mixed Arabic, French, and English within a single sentence are routine, and models trained mostly on formal text often misread them. Those are not edge cases here. They are the everyday conditions your output will land in.

If you take one thing from this piece, take the question. Put it on the agenda for your next launch review, and leave a physical chair empty if that helps. Then ask the room to name who would sit in it.

Frequently asked questions

How long does a harm-mapping session take?

For one product with a handful of outputs, plan on ninety minutes to half a day. The first pass is the slow one, because people have to agree on what the system actually sends out. After that, a re-run when something changes usually takes under an hour, since you are editing a map that already exists instead of drawing a new one.

Who should be in the session?

The person who owns the product, someone who builds it, and someone who talks to real customers or patients every day, such as front desk, support, or field staff. Add one person who was not involved in the build and has no stake in the launch date. Their job is to keep asking who else the output reaches.

Is this only for large companies or regulated sectors?

No. Small companies often need it more, because they launch faster and have no compliance team to catch a problem. If your AI sends messages, ranks people, or summarizes someone's information, it touches people beyond your users, and the map costs one afternoon and a whiteboard.

What if the map shows harm we can't fully remove?

Then you choose among three honest options: add a guardrail that shrinks the harm, launch to a smaller group so the harm stays contained, or do not launch that feature. What you should not do is ship it and leave the harm unwritten. A known, named risk that someone owns is a manageable one.

Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.