TL;DR: Start with what can hurt customers or end the company this quarter, and keep process minimal. Week one: inventory what the chatbot can see and do, fix the critical gaps (authorization on data access, no secrets in prompts, output rendering, cost limits, logging), check vendor data terms, and add a kill switch. Week two: a one-page AI policy with an owner, a lightweight intake for new AI features, an incident runbook, basic evaluation and abuse monitoring, and customer-facing transparency. Then grow toward a recognised framework as customers and regulation require.
How to approach it
Prioritise by risk and cost, not by framework completeness. Separate urgent technical fixes from the minimum governance scaffolding, and explain what you deliberately defer.
A strong answer
Inventory
what it sees and does
Fix critical gaps
authz, secrets, rendering
Vendor terms
data use, retention
Kill switch
and logging
Light process
owner, review, register
Week one: reduce real risk.
| Action | Why |
|---|---|
| Map the chatbot: data it reads, tools and actions, who can talk to it, where output goes | You cannot prioritise without it |
| Server-side authorization on any data lookup | Cross-customer data leaks end startups |
| Remove secrets and internal logic from prompts | Prompts leak |
| Safe output rendering, no external images or raw HTML | Exfiltration and XSS |
| Rate and spend limits per user and key | Denial of wallet |
| Log prompts, retrieval, tool calls and versions (with redaction) | Investigate incidents |
| Kill switch for tools and the feature | Contain in minutes |
| Review model provider terms: retention, training use, region | Customer contracts and privacy law |
Week two: minimum governance.
- One-page AI policy: approved providers, data that may not be sent to models, who approves new AI features, incident contact.
- Owner: a named person accountable for AI risk (often the CTO or a security lead).
- Intake: a short form for new AI features, routing anything with sensitive data, actions or untrusted input to a security review.
- Incident runbook: what counts as an AI incident, who decides, how to contain, how to notify customers.
- Evaluation and monitoring: a small regression suite of known attacks run before releases; alerts on spend spikes and unusual tool calls.
- Transparency: tell users they are talking to an AI and what it can and cannot do.
What to defer, deliberately. Formal certification (ISO/IEC 42001), extensive model cards, large committees. Revisit when enterprise customers, EU exposure or sector regulation require them; the inventory and policy above make that step much smaller.
Regulatory check. Ask whether the chatbot touches regulated uses or EU users: a customer-service bot usually carries transparency duties under the EU AI Act; one that makes credit or employment decisions is high-risk and changes the plan.
What interviewers probe next
- "The CEO wants to add autonomous refunds next month." Route through intake: policy code for refund limits, human approval above a threshold, logging and red teaming before launch.
- "Enterprise customers send security questionnaires about AI." The inventory, policy, vendor terms, logging and incident runbook answer most of them.
- "How do you measure progress?" Critical gaps closed, percentage of AI features registered and reviewed, time to contain in drills.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A 30-person startup launched a customer chatbot with no AI governance at all, and a large prospective customer has just sent a security questionnaire about it.
Start here
What do you fix in week one?
What could cause a breach or a huge bill this month?
What can hurt customers or end the company this quarter: inventory what the chatbot can see and do, fix authorisation on data access, remove secrets from prompts, sanitise output rendering, add cost limits and logging, check vendor data terms, and add a kill switch.
Carry it forwardFix critical technical gaps before writing policy.
Weak answerStarting with a framework gap assessment.
Constraint changes
What if the chatbot can look up any customer's orders by ID?
Whose identity does the lookup check?
That is the top fix: the lookup must check that the order belongs to the authenticated customer, in code. Test it with two test accounts. This single flaw could expose every customer's data, so it outranks every governance task.
Carry it forwardAuthorisation flaws come first.
Weak answerAdding a prompt rule instead of a code check.
Constraint changes
What do you add in week two?
What minimum process keeps new risks visible?
A one-page AI policy with an owner, a lightweight intake for new AI features, an incident runbook, basic evaluation and abuse monitoring, and customer-facing transparency that tells users they are talking to AI. Keep each piece small enough to actually use.
Carry it forwardMinimal policy, intake, runbook and monitoring.
Weak answerWriting a 40-page policy nobody reads.
Constraint changes
How do you answer the security questionnaire honestly?
Would your answers survive a follow-up call?
Describe what is in place now, with evidence, and what is planned with dates. Customers accept a credible plan more than vague claims. Prepare a short security note on the chatbot covering data flows, provider terms, access control, injection handling and logging, and reuse it.
Carry it forwardHonest current state plus dated plans.
Weak answerClaiming controls that are not yet in place.
Constraint changes
When do you adopt a recognised framework?
What would trigger the need for a framework?
When customers or regulation require it, typically as enterprise sales grow or if the product enters regulated uses. Build on the minimal practices you already run, and map them to NIST AI RMF or ISO/IEC 42001 rather than starting again.
Carry it forwardGrow into frameworks as demand appears.
Weak answerPursuing certification before basic controls work.
Now defend it
What plan would you present to the founders?
Week one: inventory, authorisation fixes, no secrets in prompts, safe rendering, cost limits, logging, vendor terms and a kill switch. Week two: a one-page policy with an owner, intake, incident runbook, basic evaluation and abuse monitoring, and AI disclosure. Answer questionnaires honestly with a reusable security note, and grow toward a recognised framework as customers and regulation require.
How it's scored
Weak: Starts with writing a comprehensive framework or forming a committee.
Hire: Prioritises technical fixes and a minimal policy, owner and intake.
Strong Hire: Sequences by risk with concrete controls, explicitly defers heavy process, checks regulatory triggers, and ties governance to customer assurance.
Common mistakes
- Paperwork before fixing data access.
- No owner, so nothing happens.
- Ignoring model provider data terms.