The hard part of building AI here is deciding what is allowed into the prompt
What changes in Britain is that the data question comes before the model question. UK GDPR governs what customer information may enter a prompt, where it sits afterwards, and who must be involved when an output affects somebody. Those answers determine the architecture, so they are settled before anything is built.
An AI feature is a new way of moving personal data around an organisation, and that is the part most proposals skip. A support assistant reading a customer's history is processing personal data. So is a tool that drafts a reply, ranks an application or summarises a recorded call. Deciding what may go into the prompt, and what happens to it afterwards, is an architectural decision rather than a policy written later.
The usual sequence is that a pilot works, gets adopted, and only then does anyone ask where the data went. Somebody pasted real customer records into a general assistant while testing. The provider's terms allow retention for abuse monitoring, in a region nobody checked. There is no record of what was assessed before launch, because nothing was. Meanwhile the tool has started making decisions, declining, prioritising, flagging, with nobody reviewing them meaningfully and no way to tell a customer why an outcome went the way it did.
When this work makes sense
Questions worth asking any supplier
Ask what personal data enters the prompt and what is stripped before it does, because that single answer determines the whole compliance position and is usually assumed rather than decided.
Ask where the provider processes and retains prompt content, because a default that suits a consumer product is not automatically right for your customer records.
Ask whether an impact assessment happens before the build or after the demo, because after the demo it only describes decisions already taken.
Ask how a person will know they are talking to a machine, because designing that in is straightforward and retrofitting it after complaints is not.
Ask what human involvement looks like in practice, because a reviewer approving a queue without seeing any reasoning is a rubber stamp rather than a safeguard.
Deliverables
A written record of what personal data the feature touches and what is removed before the model call
A data protection impact assessment prepared before build, in a form your own adviser can review
Architecture that keeps identifiable data out of the model call wherever the task does not need it
Provider processing and retention terms confirmed in writing rather than assumed from a marketing page
Clear disclosure in the interface that the user is dealing with an automated system
A human review step carrying the information a reviewer needs in order to disagree, not merely approve
Logging that lets you reconstruct why a particular output was produced for a particular person
Built with
Process
The first thing we do is map the data, not the model. We work out what personal data the feature would touch, how much genuinely needs to reach a model, and what can be removed, tokenised or kept on your side of the boundary. Very often the useful task needs far less identifiable information than the first design assumed. That map then drives everything else: which providers are appropriate, what has to be assessed, what has to be logged, and where a person must stay in the loop.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to handle personal data in an AI feature
Strip it before the prompt
Fits: Most tasks, where the model needs the shape of the problem rather than the identity of the person
Limits: Needs work upstream to find and remove the right fields, and some tasks genuinely need the detail
Send it under contracted terms
Fits: Cases where the task cannot be done without identifiable data and the terms have been read
Limits: You rely on a third party's retention behaviour, which your own adviser has to be comfortable with
Run a model on infrastructure you control
Fits: Organisations whose data cannot leave their boundary, commonly in regulated sectors
Limits: Costs more, trails the frontier providers on many tasks, and you own the maintenance
Case studies
No case study is published for this work yet, and nothing has been released. Our London office is at 37th Floor, 1 Canada Square, Canary Wharf, London E14 5AA; enquiries reach us at uk@mbgdesk.com. Most engineering is done from our head office in Hyderabad. Client work will be published only with permission.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do we need an impact assessment for this?
Frequently yes, and that judgement belongs to your own data protection adviser. What we do is make it answerable: documenting what data the feature touches, what leaves your systems, what the provider retains, and what the output affects. An assessment written against that is a real one.
Can we use a general assistant with customer data?
Only once somebody has read the terms that apply to your account, which differ from the consumer ones. The questions are what is retained, for how long, where, and whether prompt content trains anything. The risk is rarely that the answer is bad; it is that nobody checked.
Must we tell people they are talking to a machine?
Design for it regardless of what your adviser concludes about obligation. An assistant that lets a customer believe there is a person there produces the worst kind of complaint when they find out. Say it plainly at the start, keep the route to a human visible, and avoid a name that implies otherwise.
What counts as meaningful human involvement?
A reviewer who can see why the system reached its output, has authority to disagree, and has time to use it. A queue of decisions with an approve button and a throughput target is not review, and will not read as review if it is ever examined.
Where is our data actually processed?
That depends on the provider and on settings against your account, and it is worth checking rather than assuming. Several offer region-constrained processing and several default elsewhere. If your position requires a particular region, that narrows the provider list, which is an architecture decision rather than an integration detail.
Can AI make decisions about our customers?
Some, with care, and the boundary is a matter for your own legal adviser. The design rule is that the more a decision affects someone's access to something, the more genuinely a person must be in it and the better you must be able to explain it afterwards. Build that path first.
Our pilot works. Why is the build more work?
Because a pilot answers whether the output is good enough and skips every question about data, logging, review and failure. The build has to answer what enters the prompt, what is retained, who reviews what, and what happens when the model is wrong or unavailable. That is most of the engineering.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.