Responsible AI conversations with clients: scripts for five moments
In this article (6 sections)
Related programme: the FDE for Professionals course (16 weeks (proposed)). See also open Forward Deployed Engineer jobs in India, updated daily.
Responsible AI conversations with clients go best when they are tied to a specific moment in the project and a specific decision, not delivered as a principles lecture. There are five moments where these conversations reliably arise: the kickoff, the request for data, a result that treats some group worse, the client's wish to remove human review, and the first incident. Having words ready for each makes you sound like a careful engineer rather than an obstacle.
The scripts below are for a fictional engagement: an assistant that helps a lender's operations team prioritise loan-document queries. Adapt the details; keep the structure — state the observation, name the risk plainly, offer a concrete option, and hand the decision to the person who owns it.
Moment 1: the kickoff
Clients rarely raise ethics at kickoff. Raise it briefly and practically, as part of scope.
**You:** Before we lock scope, three quick questions that affect the design. Who is affected if the assistant gets a priority wrong? Is there any group of customers we should check separately — for example by language or region? And who on your side signs off on how the tool is used? **Client:** Mainly our operations staff. I'm not sure about groups — why? **You:** Because if the tool works well on English queries and worse on Hindi ones, an average score would hide it. I'd like to report results by language from the first test. It costs very little and saves an awkward discovery later.
What this achieves: you have named affected parties, a slice to measure and an owner, all in two minutes, without the word "ethics".
Moment 2: the data request
When you ask for data, be precise about what you need and what you do not.
**You:** For the first evaluation we need about 200 past queries with the priority your team assigned. We don't need customer names, account numbers or phone numbers. Can your team mask those before sharing, or would you like us to provide a masking script you run on your side? **Client:** It's easier if we just send the full export. **You:** I understand. The difficulty is that once full records are in our environment, we both carry more obligations for them. If you run the masking step, the files we receive have what we need and nothing more. I'll send the script and a sample of what the output looks like today.
Why it matters: data minimisation is a principle in India's Digital Personal Data Protection Act, 2023, which requires consent to be limited to the personal data necessary for the purpose. You don't need to cite the Act in the meeting; your client's legal team will recognise the reasoning.
Moment 3: a result that treats a group worse
This is the conversation engineers most often avoid. Do not avoid it and do not soften it into nothing.
**You:** One finding before the headline numbers. On English queries the assistant matched your team's priority in 88 of 100 test cases. On Hindi and Hinglish queries it matched in 31 of 50. That gap is large enough that I wouldn't release it as is. **Client:** Can we just release it for English queries? **You:** That's one option, and it's a legitimate one if the Hindi queries keep going to your team as today. The risk to avoid is the assistant quietly handling Hindi queries badly while the overall number looks fine. Option two is to spend a week improving Hindi performance and retest. I'd recommend option one now and option two in parallel. Your call on which.
The figures here are illustrative. Note the structure: the numbers with denominators, a clear recommendation, and the decision left with the client.
Moment 4: "Can we remove the human check?"
Once a tool performs well, clients often ask to cut the review step to save time.
**Client:** The team says the drafts are good. Can we let it route queries without anyone checking? **You:** Possibly, for some queries. Here's what I'd suggest. Let's look at the past month's reviews: which categories did reviewers never change, and which did they change often? For the first group, we can move to spot-checking — say, one in ten — and keep full review for the second. We'd track error rates on the spot checks and reinstate full review automatically if they rise. **Client:** Why not remove it everywhere if it's mostly right? **You:** Because "mostly right" includes the cases that matter most. A wrongly deprioritised query about a disputed payment has a different cost from a wrongly prioritised address change. Keeping review on the high-cost categories is cheap insurance.
Moment 5: the first incident
Something will go wrong. The conversation afterwards shapes the relationship more than the incident itself.
**You:** I want to walk you through what happened on Tuesday. The assistant marked twelve queries about loan closure as low priority. They were delayed by a day. The cause was a change in the wording of a template your team introduced last week, which our test set didn't include. We've added those examples to the test set, fixed the behaviour and confirmed the twelve were handled. I've written a one-page review; it includes one thing we should have done differently — alerting when query patterns change suddenly — and a date for adding that. **Client:** Why didn't you catch it before? **You:** Our tests covered the templates that existed when we built them. That was a gap in our monitoring, not something your team did wrong. The fix is the alert.
Own the part that was yours. Don't shift blame onto the client's template change, even though it was the trigger.
A pocket card
| Moment | Say | Avoid |
|---|---|---|
| Kickoff | Who's affected, which groups to slice, who owns use | A principles lecture |
| Data | What you need and don't; offer masking | Accepting full exports "to save time" |
| Skewed result | Numbers with denominators; options; recommendation | Averaging it away |
| Remove review | Evidence-based step-down with triggers | Yes or no without data |
| Incident | Facts, cause, fix, your gap, date | Blame |
Explaining uncertainty to non-technical audiences is covered in the hallucination conversation script. For experienced engineers working towards client-facing AI delivery, FDE for Professionals is a proposed advanced programme that includes responsible-AI practice; ask a counsellor about its current schedule.
Pankit Kumar has 10 years in Data Science & AI, building and shipping production systems in regulated pharma and clinical environments. He is a freelance trainer at Boston Institute of Analytics, AnalytixLabs and Scaler, and has taught this material to thousands of working professionals.
This article is part of our FDE for Professionals programme — 16 weeks (proposed). An accelerated advanced pathway for IT professionals ready to own enterprise AI delivery.
Explore FDE for Professionals