Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
This is the practice the firm grew out of. We spent a decade mapping data, fixing consent and writing records of processing for brands operating in dozens of countries. Now every client is putting a language model in front of that same data, and the questions have changed shape.
Privacy consultancy is the work of finding out what personal data an organisation actually holds, why, and under which law, then engineering the systems and habits that keep it lawful. Green Arrow Consultancy has run privacy programmes for global consumer brands since around 2017, and now does the same work for AI systems, where the questions are training data, retention, logging and who the model provider really is.
Privacy by design has been in UK and EU law since 2018. It is also, in most organisations we assess, a phrase that appears in a policy and nowhere else. The test is simple. Ask where in the last project the privacy decision was made, who made it, and what changed in the build as a result. If a document was written and signed after the system went live, the principle has not been implemented.
Done properly it looks unremarkable. A screening question at the start of every project. A retention period set in the database schema rather than in a policy nobody enforces. A form that collects three fields instead of eleven because somebody asked what the other eight were for. An export routine built on day one, so a subject access request does not require a developer.
Most privacy failures are configuration failures. A tag that fires before consent. A form posting to a third party nobody registered. A backup with no retention rule. A test database seeded from production. A shared drive with permissions inherited from a team that no longer exists. None of these are legal questions, and all are findable by someone who knows how the systems are built. That is why privacy runs out of an engineering practice here, close to our website management and ethical analytics teams.
For a UK organisation the operative law is the UK GDPR alongside the Data Protection Act 2018, with the Privacy and Electronic Communications Regulations covering cookies and electronic marketing, and the Information Commissioner's Office as regulator. If you have customers, staff or visitors in the EU, EU GDPR applies to that processing too. The two texts look identical and differ enough to catch you out on transfers, representatives and supervisory authority.
There is no single federal consumer privacy statute. California moved first and is the reference point most vendors build to. Colorado, Connecticut, Virginia and Texas are examples of the wave that followed, and more states legislate each year, so treating the list as fixed is a mistake. The common shape is a right to know, delete, correct and port, plus a right to opt out of sale, sharing and targeted advertising. Several states require a browser-level universal opt-out signal to be honoured automatically, which is a technical obligation rather than a policy one. Sensitive data usually needs opt-in consent even in an opt-out state.
One website often has to behave differently for a visitor in Munich, one in Denver and one in Sao Paulo: geolocation logic, region-specific consent, region-specific notices and a tag configuration that respects all of them. Getting it wrong towards over-collection is a compliance problem. Getting it wrong the other way quietly destroys your marketing data. The detail sits in our cookie consent management work.
Personal data leaving the UK or the EU needs a lawful transfer mechanism: an adequacy decision, the UK international data transfer agreement or addendum, EU standard contractual clauses, or an approved alternative. The paperwork is the easy half. The hard half is the transfer risk assessment, which asks what actually happens to the data in the destination country. Every cloud AI service you adopt is a transfer question before it is a model question.
Three phases with two hinges. The hinges are where most programmes quietly fail.
Data mapping across systems, suppliers and territories, with interviews in marketing, HR, customer service and IT, because the register in the drawer rarely matches the platforms in use. The output is a record of processing that is true, and a gap list ranked by risk.
Unlawful tracking on a high-traffic site, an unregistered processor holding special category data or a retention rule that does not exist all come before renaming a policy document. The waves get agreed in writing so the programme has a shape.
Consent reconfigured, tags governed, retention enforced at database level, processing agreements chased, notices rewritten to describe what the site actually does, access rights pruned. This is where a privacy practice with engineers is worth more than one without.
A screening question in project intake, a short assessment when the answer is yes, named owners for each processing activity, and privacy-first training built on your own systems.
Quarterly review of the record of processing, a vendor and sub-processor cycle, rights request handling, breach rehearsal, and a report a board or a regulator can read. An unoperated programme decays within a year, invisibly, until something goes wrong.
Darren Tyler has been doing work for me on Energizer's website compliance. Not only has he met our teams expectations but exceeded them.
If a proposal does not cover most of this list, it is a documentation project wearing a privacy label.
Every client has asked some version of the same question in the last two years: can we put a language model in front of our data without creating a problem. Usually yes, because the risk sits in a small number of specific, answerable places rather than in the technology as a whole.
Does anything you send become training material for someone else's model? On the enterprise arrangements we deploy, no, by contract and by configuration. On consumer products the answer is often different, and it changes when terms change. The distinction between an enterprise API tier and a consumer chatbot is the most consequential one in AI privacy and the least understood inside businesses. A member of staff pasting a customer list into a personal chatbot account is a different processing activity from the same text going to a contracted endpoint under a processing agreement, even when the model underneath is identical.
Ask a provider three questions and write the answers down. Are prompts and outputs logged. For how long. Who inside the provider can read them. Trust and safety retention windows are real and exist for good reasons, and they still belong in your record of processing, because personal data a member of staff pastes into a prompt is personal data you have transferred.
Treat model providers exactly as you treat any other processor: processing agreement, sub-processor list, security review, transfer mechanism, defined retention, named owner on your side. If inference happens outside the UK or the EU it is an international transfer and needs the same assessment as any other. Retrieval adds one more problem, because a corpus built from your own documents inherits every access control mistake in the source systems. We map source permissions into retrieval itself and test with accounts at different privilege levels, which is where this work meets our AI security practice.
A short, specific entry: what the feature does, which categories of personal data reach it, the lawful basis, whether any output is an automated decision with a significant effect, which provider processes it and where, retention at each hop, whether a human reviews outputs, and how someone objects. Written before launch this takes an afternoon. Reconstructed a year later under regulatory pressure it takes a fortnight, and it is never as good.
A privacy review of an AI feature is not abstract. It is half a dozen specific questions and the control that closes each one.
| AI use case | Privacy question it raises | Control that answers it |
|---|---|---|
| Customer service assistant built on past tickets | Old tickets hold names, addresses and complaints. Is this a new purpose? | Purpose assessment, pseudonymised corpus, retention limit on the index, and a notice describing the use |
| Internal enterprise search across HR and finance | Can it surface a document the asker is not entitled to read? | Permission-aware retrieval mapped from source systems, tested at several privilege levels |
| Sales assistant summarising CRM records | Sensitive or special category detail hiding in free-text notes | Field-level exclusion at ingestion, redaction on the way in, and a documented lawful basis |
| Marketing copy generated from customer data | Profiling, and whether the output counts as targeted advertising in a US state | Consent and opt-out signal checked before use, plus a suppression list the generator respects |
| Recruitment screening or ranking | Automated decision-making with a legal or similarly significant effect | Impact assessment, meaningful human review, an explanation route and an appeal path |
| Staff using a public chatbot for work | Uncontrolled transfer of personal data to an unassessed processor | An acceptable use policy with a sanctioned tool, training, and a monitored alternative |
Drawn from the reviews we run before an AI system goes live. The pattern repeats across sectors.
The operating half of a programme, which is the half that decides whether the assessment was worth paying for.
Every supplier touching personal data gets a contract check, a processing agreement, a transfer mechanism, a security review and a place in the register. We use the UpGuard platform for continuous supplier posture rather than an annual questionnaire.
Intake, identity verification, discovery across every system, redaction and response inside the statutory clock. The bottleneck is always discovery, so we make the search repeatable and record where each system keeps its copies.
Short, role-specific sessions built on your own systems and your own near-misses. Marketing, customer service, HR and engineering each get the version matching the decisions they make.
Retained capacity for organisations needing an owner without a full-time hire, working alongside your counsel. We are a member of the International Association of Privacy Professionals.
Darren consistently demonstrated exceptional technical skill and a strong understanding of various jurisdictions' legal requirements.
More on scope, pricing and ways of working in the full FAQ, and definitions in the glossary.
It establishes what personal data an organisation holds, why, under what lawful basis and for how long, then closes the gap between that and the law. In practice: data mapping, records of processing, notices, consent handling, impact assessments, vendor review, transfer assessments, rights workflows, retention schedules and training. A consultancy that writes policy documents and stops has done about a third of the job.
A statutory DPO is required under UK and EU GDPR for public authorities, for large-scale regular and systematic monitoring, and for large-scale processing of special category data. Plenty of organisations outside those tests appoint a privacy lead anyway. We provide outsourced DPO and privacy lead capacity on a retainer, working alongside your legal counsel.
The operational difference is the default. UK and EU GDPR require permission before non-essential tracking begins, so it starts off. The US state laws following California give consumers a right to opt out of sale, sharing and targeted advertising, so it starts on. Colorado, Connecticut, Virginia and Texas are examples of that pattern spreading, and several states require universal opt-out signals to be honoured automatically.
When the processing is likely to result in high risk to individuals. Usual triggers are large-scale processing, profiling or automated decisions with a significant effect, systematic monitoring, special category or children's data, innovative technology, and combining datasets collected for different purposes. Most customer-facing AI assistants trip at least one. We run it before the build, because the mitigations change the architecture.
It depends which tier of a provider's service you are on, and this is the most misunderstood point in AI privacy. Consumer chatbot products and enterprise API tiers differ on terms, retention and logging. The enterprise arrangements we deploy use training opt-out, defined retention and processor terms, and we write the answer into your record of processing.
The assessment phase is typically four to eight weeks depending on systems and territories in scope. Remediation then runs in waves, highest risk first, and a mature estate takes a few quarters rather than a few weeks. Operating it is continuous, because new suppliers, campaigns and AI features arrive every month and each creates processing that has to be recorded.
Yes. We design the intake, identity verification, search and redaction process, then either run it or train your team to. The part organisations underestimate is discovery: finding every system holding a record for one person, including the marketing platform, the ticketing tool, the backup and the spreadsheet on someone's desktop.
We run programmes across the UK, the EU, the USA, Asia Pacific, the Middle East, South America and South Africa, mostly for multi-territory consumer brands whose estates must behave differently by visitor location. We are not a law firm and give no legal advice. We provide the engineering layer that turns a legal position into configured systems and written records.
Written and reviewed by the Green Arrow Consultancy team, led by Darren Tyler, founder and chief executive.
Most engagements begin with a data map, because you cannot defend a position you have not written down. Tell us the territories and the systems, and we will scope the assessment.