Free learning route
Sales conversations about AI security
How to run an AI discovery conversation, qualify whether a use case is real, spot the risk signals that need a specialist, describe limitations honestly, and hand over to a technical colleague with enough written context that they do not have to start again.
For: For account managers, business development and customer success people who have to discuss AI security credibly without being engineers.
Before you start: None. No coding and no technical background required.
First session: about 30 minutes. Times are estimates; work at your own pace.
Tick completed steps to save progress in this browser. No account or quiz needed. Clearing browser data removes progress.
What you will be able to do
- Run a discovery conversation about an AI use case using questions that surface data, users and consequences.
- Qualify a use case as ready, needs-specialist or not-ready, and say why in one sentence.
- Recognise four risk signals that must trigger a security colleague before any commitment.
- Describe what an AI system cannot reliably do without either overselling it or scaring the customer.
Start now · about 20 minutes
Run a written discovery on a fictional request
- Read this fictional request: Lumen Health Insurance, a mid-size insurer, says 'we want AI to handle our claims queries so customers get answers faster'.
- Write out ten discovery questions covering five areas: what decision or task this replaces, what data the system would read, who the users are and whether they are staff or customers, what happens when the answer is wrong, and who inside Lumen approves the launch.
- Answer each of your own questions with the most likely assumption a hopeful seller would make, then mark each assumption as confirmed, assumed or unknown. Everything will be assumed or unknown, which is the point.
- Choose the three unknowns that would most change the shape of the work and write one sentence each on why.
- Write a one-sentence qualification verdict: ready, needs-specialist, or not-ready, with the reason.
Done when: You have ten questions, each marked confirmed, assumed or unknown, three prioritised unknowns, and a one-sentence verdict you would be comfortable reading aloud to the customer.
Lesson 1 · about 25 minutes
Discovery: ask about consequences, not technology
Discovery is finding out whether there is a real problem, whose it is, and what a good outcome would look like. It is not a technical review, and you do not need to know how a model works to do it well. What you do need is to stop taking the customer's stated solution as the requirement. 'We want AI for claims queries' is a solution; the requirement is somewhere behind it, in a queue length, a cost per contact, or a complaint trend.
Five question areas cover most AI use cases. First, the task: what does a person do today, and how often. Second, the data: what would the system have to read, and does any of it concern people, money or health. Third, the users: staff or customers, and how many. Fourth, the consequence of a wrong answer: annoying, expensive, or harmful. Fifth, the decision path: who signs off, and does that person know this conversation is happening.
The consequence question changes everything and is most often skipped. In the fictional Lumen Health case, an assistant that summarises policy wording for staff is a productivity tool; the same assistant telling a customer whether their claim is covered is a decision affecting that person's money and health, with a different approval path and different obligations. The technology may be identical. The risk is not.
Write the answers down during the call and read the summary back before the call ends. Anything you cannot fill in is an open question, not a detail. Saying 'I do not know yet, and here is who will' is a credibility move, and it is the habit that keeps you from promising something the delivery team cannot build.
Try it
Take your Lumen discovery notes and rewrite the customer's request as a one-paragraph problem statement with no solution words in it, then list what you still do not know.
Check your answer
If your problem statement still contains the words AI, assistant, chatbot or model, you have restated the solution. A good version names the task, the volume, the people affected and the cost of the status quo.
Read more
- Technical Writing One - Google for Developers
Free course. The audience section is directly useful for deciding what the customer already knows and what they need to learn.
- AI Risk Management Framework | NIST
Free and voluntary. Read the Map function only; it is essentially a professional discovery question set about context and intended use.
- Advisory and customer-facing delivery skills
Site page on scoping and communicating AI security work.
Lesson 2 · about 25 minutes
Qualification: ready, needs-specialist, or not-ready
Qualification is deciding what to do next with what discovery told you, and the honest set of outcomes has three options rather than two. Ready means the use case is specific, the data is understood, a sponsor exists, and a technical colleague can scope work. Needs-specialist means it may well be viable but a named risk signal has to be examined first. Not-ready means something structural is missing, usually a sponsor, a defined task, or access to the data.
Four risk signals should always convert a conversation into needs-specialist rather than a commitment. One: the system would read personal, health or payment data. Two: its output reaches customers or the public directly, without a person reviewing it. Three: it would take actions in another system, such as updating a record or issuing a payment, rather than only producing text. Four: the customer names a regulator, an audit, or a specific law as the reason for the project.
Any one of these means the security or compliance shape of the work is decided by someone other than you, and that is fine. Your job is to spot the signal, name it in plain words, and bring in the right colleague early enough to influence the design.
Not-ready is a legitimate answer. In the Lumen example, if nobody owns the claims queue and nobody has approved sharing claims data, there is no engagement to scope yet, and the productive next step is helping the customer find that owner. Recording that decision, with the reason, stops the same unqualified request returning in three months as an urgent deadline.
Try it
Score the fictional Lumen case against the four risk signals, then write your verdict and the single next action with an owner and a date.
Check your answer
Lumen trips at least two signals: claims data is personal and financial, and customer-facing output without review is likely. The correct verdict is needs-specialist, and the next action names a security or compliance colleague, not a proposal.
Read more
- Guidance on AI and data protection - ICO
Free UK regulator guidance. Use it to recognise when personal data makes a use case a specialist conversation; do not give legal advice yourself.
- Regulation (EU) 2024/1689 (AI Act), official text on EUR-Lex
Free official source. If a customer claims an obligation, link the text and bring in a specialist rather than interpreting it.
- AI governance, risk and compliance skills
Site page on the frameworks your compliance colleagues will use.
Lesson 3 · about 25 minutes
Talk about limitations without losing the room
Customers ask two questions that sellers answer badly: can it get things wrong, and can it be manipulated. The accurate answer to both is yes, and saying so early is what makes the rest of your claims believable. Describe a limitation together with the control and the residual risk, in that order, so the conversation moves to design rather than doubt.
Three limitations are worth being fluent in. First, these systems produce plausible text that can be wrong, so any use where being wrong matters needs a citation, a human check, or a narrow scope. Second, text the system reads can change what it does: this is prompt injection, and it has no complete fix, so the control is limiting what the system is allowed to do and to reach. Third, a retrieval system will surface whatever it was given access to, so permissions have to be handled deliberately or an assistant becomes a way around them.
Use a three-part sentence each time. Limitation, in plain words. Control, and who owns it. Residual risk, stated. For example: 'It can produce a wrong summary. We reduce that by answering only from your own documents and showing the source, which your team reviews for the first month. It will still occasionally miss context, so we would not put it in front of claimants in phase one.' That is a sentence a security reviewer will let you keep saying.
Avoid three phrases, because specialists hear them as inexperience: 'it is fully secure', 'the model never sees your data' when it demonstrably processes the prompt, and 'prompt injection is solved'. Say instead what is true about configuration, retention and containment, and if you do not know, confirm it in writing.
Try it
Write three limitation-control-residual-risk sentences for the fictional Lumen assistant: one about wrong answers, one about manipulation of the input, and one about access to claims documents.
Check your answer
Each sentence should end with something still unresolved. If a sentence ends with the risk removed, it is a claim rather than an honest limitation, and it will be tested later at your expense.
Read more
- OWASP Top 10 for LLM Applications
Free. Read the entries for prompt injection, sensitive information disclosure and excessive agency; the names alone make you easier for engineers to work with.
- AI Incident Database
Free. Real published incidents, useful for explaining why a control matters without inventing scenarios.
- Cyber Security Toolkit for Boards - NCSC
Free. Written for non-technical decision makers; a good model for the level of language to use with an executive buyer.
Lesson 4 · about 20 minutes
Hand over so the technical team does not start again
The last step of a good sales conversation is a written handover. Without one, the technical colleague repeats your discovery, the customer answers the same questions twice, and the difference between the two versions becomes a scoping argument later.
A usable handover is one page with six items: the problem statement in the customer's own words, the data involved and its sensitivity, the users and whether output reaches customers, the risk signals you spotted, the open questions with owners, and what has already been said to the customer, including any numbers or timelines mentioned. That last item is the one that saves the engagement, because it tells the technical team what they are now expected to deliver.
Be explicit about commitments versus possibilities. 'We said a pilot could plausibly run in a quarter if data access is ready' is very different from 'we committed to a quarter', and the technical team needs to know which one the customer heard.
Keep the handover free of anything you would not want forwarded: no credentials, no sample customer records, no copies of the customer's confidential documents. Reference where those live instead. Practise the format on the fictional Lumen case so your first real handover is not also your first draft.
Try it
Write the six-item handover for the fictional Lumen case, including one commitment you might plausibly have made in the call and how you would correct it if it was wrong.
Check your answer
A good handover lets a colleague brief the customer without rereading your notes. If your open questions have no owner and no date, they will not be answered before the next meeting.
Read more
- Technical Writing One: know your audience
Free. Short section on deciding what a reader already knows, which is exactly the handover problem.
- LLM Applications Cybersecurity and Governance Checklist - OWASP GenAI Security Project
Free. Skim the governance sections to see which questions your technical colleagues will need answered.
- AI Security Consultant path
Site page describing the consulting role this handover feeds into.
Keep what you made
AI discovery and handover pack
A reusable one-page discovery question set, a three-outcome qualification rule with the four risk signals, three limitation-control-residual-risk sentences in your own words, and a six-item handover template, all worked through on the fictional Lumen Health example.
- The problem statement contains no solution words and names the cost of the status quo.
- Every discovery answer is marked confirmed, assumed or unknown.
- The qualification verdict is one of ready, needs-specialist or not-ready, with a reason.
- Each limitation sentence names a control, an owner, and a residual risk.
- The handover records what was already said to the customer, and contains no customer data or credentials.
Completing a route records your practice, not a qualification or proof of job readiness.
Where to go next
- Technical pre-sales for AI security →
Go here when you want to run the technical validation and demo yourself rather than hand it over.
- AI fundamentals →
Start here if the mechanics of how these systems work are still unclear when customers ask.
- Leading AI security work →
Move on if your conversations are increasingly with executives about programme and accountability rather than a single use case.