How Can a Company Find Who Its AI Could Harm Before Launch?

Most AI launch reviews ask whether the system works. Dr. Jonah Tebaa argues they should also ask a second question, and ask it before the first customer is touched: who is affected by this system that is not sitting in the meeting? In his work advising companies in Lebanon and across the MENA region, he has found that the answer is almost always "quite a few people," and that nobody has written them down.

The Room Is Built for the Wrong Check

According to Dr. Tebaa, a launch review has a natural guest list: the product owner, the builders, and the staff who will operate the tool. That group can judge functionality well. It cannot judge harm, because the people most exposed to an AI's output are rarely users of it. They are the person a message is about, the relative whose phone receives it, or the colleague who inherits a summary months later.

He describes this as a structural blind spot rather than negligence. These people have no login and no feedback channel, so they never appear in a pilot metric or a satisfaction survey. A team can pass every internal test and still deploy a system that acts on people it has never met.

The full argument, including the worked example, appears in his original article, I Ask One Question Before Any AI Launch: Who Isn't Here?

The Bystander Map

Dr. Tebaa's answer is a short working session he calls the Bystander Map. It needs a whiteboard, the product's owner and builders, and one person outside the build who is willing to keep asking who else is affected. It runs in five steps.

1. Inventory every output the system produces, whether a message, score, ranking, summary, or recommendation, and note where each one travels after it leaves the system.
2. For each output, identify four rings of people: the user, the subject the output is about, any bystander whose data, phone, or name is touched, and any downstream person who inherits the result later.
3. Write the worst plausible harm to each ring in a single sentence, and tag it with how severe it is and whether it can be reversed.
4. Assign one inexpensive guardrail to every severe or irreversible harm. Examples include a confirmation step, a narrower scope, redaction of sensitive details, or a human check.
5. Set a trigger for repeating the exercise: a new data source, a new channel, or ninety days, whichever arrives first.

He is particular about the third step. One sentence per harm, naming a specific person, prevents the group from settling for vague labels like "privacy risk."

An Illustration From a Clinic

Dr. Tebaa uses an illustrative case, not a real client, to show the method. A clinic deploys an assistant that sends appointment reminders. The staff who review the launch all see it working. The map, however, surfaces a person no one had considered: a family member whose number the patient listed years earlier as a secondary contact. Under the existing design, that person could receive a text naming the clinic and its specialty.

The harm is unintended disclosure of someone's health visit to a relative they did not choose to tell, and it cannot be undone. The fix he describes is small: a confirmation step before any message goes to a secondary contact, with generic default wording. It is a few hours of work that removes the one irreversible harm on the board.

Regional Conditions the Map Must Include

Dr. Tebaa asks teams in the region to add three local realities to the exercise. Phones in many households are shared, so a message intended for one person may be read by several. Messages sent through WhatsApp can be forwarded or screenshotted within seconds, so any output should be assumed to travel. And language is layered: Lebanese Arabic, Arabic typed in Latin letters, and sentences that mix Arabic, French, and English are routine, yet many models handle them poorly. In his view, these are baseline conditions rather than edge cases.

What Happens After the Map

Dr. Tebaa says a completed map ends in one of three decisions: launch with the guardrail, launch to a smaller group where the harm stays contained, or hold that feature back. He treats all three as sound judgment. The outcome he warns against is a fourth one, where the first person to identify the harm is the person it happens to.

Frequently asked questions

What is a "bystander" in business AI deployment?

A bystander is a third party whose data, phone number, or name is touched by an AI system without their being its user or its subject. In Dr. Tebaa's framework, this might be a relative listed as an emergency contact who receives a message meant for a patient. Bystanders matter because they never chose to interact with the system and usually cannot object.

Why does Dr. Tebaa argue launch reviews overlook affected people?

Because the reviews are staffed by people who build or use the product, and those people can only speak for their own experience. The individuals an AI acts on, writes about, or reaches indirectly are absent from the room and from the metrics. He sees the omission as a design flaw in the review process rather than a lapse by the team.

How does the harm map differ from a standard AI risk register?

A risk register typically lists categories of risk at the level of the organization or the model, such as bias, security, or compliance. The Bystander Map starts from each output and asks which named person is affected at each ring, then pairs every severe harm with a specific guardrail. It is narrower, more concrete, and built to be finished in an afternoon and redone when conditions change.

What should a small or mid-size Lebanese company do if it finds a severe, irreversible harm?

Dr. Tebaa suggests treating it as a launch decision, not a footnote. The company can add a low-cost guardrail such as a confirmation step, restrict the feature to a smaller group, or delay that feature until the harm can be contained. Whichever path it takes, the harm should be written down and assigned to an owner, then revisited whenever data or channels change.