Worked example
Bluebell Home: customer chatbot
Bluebell Home, online retailer (fictional). One AI system, taken through all eight lifecycle stages, with the record produced at each step.
For reference purposes only. Not legal advice.
Fictional example Names, data and results are invented to show how the tools work.
What this example shows
Transparency duties, labelling, red-teaming, monitoring of wrong answers, an incident about incorrect refund promises and the post-incident review.
Regions: UK, EU. System: A customer-service chatbot built on a vendor model.
Try it in the tools
Fictional example. Names, data and results are invented to show how the tools work. Loaded records are marked "Example".
Load Bluebell Home: customer chatbot into your workspace to open the register, controls, reports center and board report with real-looking data. You can remove the example data again at any time.
Add keeps what you have and adds the example. Replace overwrites your workspace; export a backup from the workspace page first if you might need it.
1. Set up governance
Bluebell's COO names the head of customer experience, Amara, as accountable for AI use, and a risk manager, Tom, as AI governance lead. They adopt a one-page AI use policy and an acceptable use policy that bans pasting customer data into public tools.
Artifacts: AI use policy, Acceptable use policy, RACI (default). Stage 1 page
2. Inventory and intake
Tom's survey finds the chatbot plus two teams using public chat tools to draft emails. All three go on the register. The chatbot request is triaged as a standard review: it is customer-facing and generates content, but it makes no decisions about people.
Artifacts: Register entries, Intake record: standard review. Stage 2 page
3. Assess risk and impact
Screening: the chatbot interacts directly with customers, so the tier is Transparency duties. Applicability for the UK and EU lists data protection law, the Equality Act (if it affects decisions) and the EU AI Act transparency duties, all as screening results to confirm with counsel.
Artifacts: Screening result: Transparency duties, Applicability record. Stage 3 page
4. Design controls and document
Controls are chosen for a customer-facing, generative, vendor-supplied system: transparency, red-teaming, labelling, vendor due diligence and contract terms. The vendor says it may use conversations to improve its model, so Bluebell asks for an opt-out in writing.
Artifacts: Control plan, Vendor file, System card. Stage 4 page
5. Test and validate
Before launch the team red-teams the bot with tricky refund and complaint prompts and tests for prompt injection. It finds the bot will invent policy details when unsure. They add guardrails and a rule to hand over to a person.
Artifacts: Testing plan, Red-team record. Stage 5 page
6. Approve and deploy
Tom signs off with conditions: a clear 'you are talking to an AI assistant' line, a one-click route to a human and no refund promises without a person. The notice goes live and agents are trained to take over.
Artifacts: Approval record, Transparency notice, Oversight procedure. Stage 6 page
7. Monitor and respond
In month two the monitoring log shows wrong-answer complaints above the agreed threshold. Customers were told refunds were possible outside policy. Severity S3 (limited harm, contained). The team pauses the refund topic, apologizes to affected customers, and the vendor adjusts its prompts.
Artifacts: Monitoring log, Incident record, Post-incident review. Stage 7 page
8. Review, report and retire
At the quarterly review Tom reports the incident and its fix to the board: what happened, the consequence if repeated, and the decision needed to fund a monthly answer-quality audit. The register entry stays Live with a next review in three months.
Artifacts: Board report, Review record. Stage 8 page
For reference purposes only. Not legal advice. Fictional example: names, data and results are invented to show how the tools work.
Was this page useful? Tell us what is missing or wrong ↗ · Report a correction