A generated site starts collecting data on its first day
An AI tool can put a contact form, a newsletter box, a chat widget, analytics and a map on a new site in one afternoon. All five are standard components, which is exactly why they show up: describe the company, pick the features, and the site arrives already asking visitors for a name, an email address, a question, a route or an identifier for the session. Nothing about that is suspicious. It is simply what a default build looks like.
What does not arrive is the decision behind each of them. Somebody has to say which of the five may run, for what purpose, what each one keeps and for how long. Those answers belong to the business, not to the tool that built the page, so they are missing from every generated site — and the site publishes anyway.
A small business feels this as a list of features, not a list of obligations. The kitchen studio in Brno asked for a form that reaches the sales inbox, a box that adds addresses to the mailing list, a widget that answers on Saturday morning, analytics that shows which pages work, and a map that points to the workshop. Five features were delivered. Five separate agreements were not, because agreeing is not a feature anyone can pick from a menu.
The result is a site where everything works and nothing can be proven. Every component behaves exactly as designed, and nobody can say what a visitor actually agreed to.
The five places your site asks for consent
The contact form and the newsletter box look alike and are not the same request. A form answers a question somebody chose to ask, and keeping that message is part of the service until the matter is closed. The newsletter box is a marketing purpose: it needs its own explicit opt-in, its own wording, and a way out that does not require a password. One sentence covering both covers neither.
The chat widget and the analytics script are somebody else’s code running on your page. The widget passes the conversation, the device and often the previous page to a provider the visitor has never heard of; analytics sets an identifier and follows the visit. Both are useful, both hand data to a third party, and neither waits for permission before it starts.
The embedded map is the one nobody notices. A visitor who has clicked nothing has already handed their address to the map provider by opening the page. Booking widgets, videos and payment forms behave the same way: the request leaves before the consent does.
Five places, five purposes, five answers that have to exist before the first visitor arrives.
The list has to name real services
Every one of those components passes data to somebody who handles it on your behalf, and the generated privacy text names none of them. The host, the form’s delivery service, the newsletter tool, the CRM behind the form, the chat provider, the analytics account, the scheduler, the payment provider. Ask a tool to write the privacy page and you get correct general paragraphs that would suit a dental practice and a software house equally well.
The useful version is short and dull: a list. For each service — what it receives, where the data sits, under whose contract, how long it stays, and who answers when somebody asks for their file. A small business rarely needs more than a dozen lines. The list is only as true as the last time somebody checked it, which is why it needs an owner rather than a paragraph.
Refusing has to be as easy as accepting
A banner that highlights acceptance and hides refusal two screens deep is not consent, whatever its wording says. The same is true of a newsletter box pre-ticked because unticking it costs a click, and of an unsubscribe link that leads to a form asking for a reason. When saying no takes effort, the yes beside it does not count.
Somebody also has to be able to prove it later. When did this person agree, to what, and what did they see at the time — that question has a date in the answer. Without a record kept against the person rather than in somebody’s memory, what you have is a story about consent, not consent. The same record settles how long each list lives before it is deleted.
What AI is genuinely good at here
Use it to build the inventory, then check the inventory against the site. Hand it the page, the forms and the scripts, or the built output, and ask what collects data, where it goes, for which purpose and in whose name. It is quick to draft the consent wording for each purpose, to map every form field to a retention period, and to write the test nobody writes by hand: decline everything, then see what still fires.
Do not let it decide what the business actually wants. Which purposes are needed, whether the chat widget earns its place, whether analytics may run before consent, what stays for a year and what is deleted after thirty days — each carries a cost and somebody who answers for it. The final list must also name the services you really pay for, in accounts that really exist, because a plausible name is worth nothing when a request arrives.
Then walk the site as a visitor who refuses. Decline the banner, submit the form, open the chat, watch what loads anyway, ask for your data and see whether an answer arrives with a name on it.
Consent belongs to the build, not to the banner
The banner is the visible corner of the setup; the list behind it is what has to exist before launch. Purposes, services, records, retention, and a way to withdraw that works without a password. Businesses that treat those as paragraphs generated along with the page discover where they stand the first time a visitor, a partner or an authority asks what exactly was agreed — and the answer takes days to rebuild. Businesses that build the list into the launch checklist answer in a minute, from a file that already exists. The generated page is identical either way; only one of them can be explained.
Related service: Website and web application development