Culture Dive — Privacy Policy

DRAFT FOR LEGAL REVIEW. This is not legal advice. This document was written by reading the Culture Dive codebase, table by table and call by call. It describes what the system does today, including the places where it does nothing. No lawyer has reviewed it. Do not publish it until Spanish counsel has reviewed it and every [PLACEHOLDER: …] has been filled in with a real, checked fact.

Version: [PLACEHOLDER: version number and effective date — set at publication]

1. Who is responsible for your data

• Controller: APC Labs SLU, a company established in Spain.
• Registration number: [PLACEHOLDER: company registration / NIF — from the incorporation documents. A number appears on the live marketing site; it has not been verified against any company record and must not be copied across.]
• Registered address: [PLACEHOLDER: registered office address.]
• Contact for privacy questions: [PLACEHOLDER: a monitored address on the company domain. It must be a real mailbox with a named owner, because it is the address that receives objections and rights requests under sections 11 and 12.]
• Data protection officer: [PLACEHOLDER: whether a DPO is required under Article 34 of the Spanish LOPDGDD has not been determined, and no DPO or internal compliance owner is named anywhere. Counsel to determine; a person to be named either way.]

Our lead supervisory authority is the Spanish Agencia Española de Protección de Datos (AEPD).

2. Who this policy is about

Two very different groups. Read the one that applies to you.

• Part A — people who use Culture Dive. Staff at our client organisations, people we have invited, and our own staff. If you signed in, or were sent an invitation, this is you.
• Part B — people who appear in content we collect. Culture Dive analyses public discourse about brands. That content can name real people who have never used this product and never heard of us. If you are a journalist, executive, creator or commentator who has been mentioned in something we collected, this is you, and section 11 is written for you specifically.

This policy covers the Culture Dive product. [PLACEHOLDER: confirm whether it also covers the culturedive.ai marketing site, which has its own cookie and analytics arrangements that the product does not share. If it does, the cookie section below must be extended. Today culturedive.ai/privacy returns a 404.]

Part A — People who use Culture Dive

3. What we hold about you

Your account

We do not hold your password, your authenticator secret, or your passkeys. Those are held by Supabase Auth (section 13). We never see them.

Your access

• Which workspaces you belong to, your role in each, when it was granted and by whom, and if it was revoked, when and by whom.
• For our own staff: a free-text reason recorded when staff access was granted. That reason is about a named person.

Invitations

• The email address invited, the role, when it was sent, when it expires, who sent it, and whether and when it was accepted.
• Only a hash of the invitation link is stored, never the link itself.
• If the invitation email bounces, our email provider tells us and we record that it bounced and what kind of bounce it was.

If you were invited and never accepted, we still hold your email address. You are in this policy too. Section 12 explains what you can ask for.

Billing

• A Stripe customer reference for the workspace.
• The full payload of every billing event Stripe sends us, stored exactly as it arrived. Those payloads routinely contain the name, email address and billing address of whoever paid. We store them verbatim so we can reconcile a disputed charge against what Stripe actually said, rather than against our interpretation of it.
• We never see or store card numbers. Payment happens on a page hosted by Stripe.

Our record of what happened

We keep an audit log. Each entry records who did what, in which organisation and workspace, whether it succeeded, what it affected, a request reference and a short session reference.

Two honest details:

• Some entries carry additional detail, and for invitation and staff-administration events that detail includes email addresses.
• The audit table has columns for IP address and browser user-agent. They are never filled in. No IP address and no user-agent string is written to that log by any part of this system. We are telling you this because the schema implies otherwise and an auditor reading it would reach the wrong conclusion.

What our staff write

Reports are written by people. A report can mention a person — a client contact, an executive, a journalist. That text is stored, revisioned and, once published, immutable.

What we do not hold

• No analytics. No product analytics, no session recording, no heatmaps, no advertising or marketing pixels anywhere in the portal or the admin application.
• No behavioural email tracking. Our emails do not contain an open-tracking pixel and do not rewrite links for click tracking. Both are switched off in code and both are asserted by automated tests. One of the reasons is specific: link tracking would put an invitation's bearer token into our email provider's click log.
• No profiles built about you from your behaviour.
• No special-category data. We do not ask for it and have nowhere to put it.

4. Why we hold it, and our legal basis

[PLACEHOLDER: no lawful basis has been formally recorded anywhere for any processing. The column below is our reading of what each purpose would most plausibly rest on, not a decision anyone has taken. Counsel to confirm each row, and the result should be recorded in the record of processing activities, which also does not exist yet.]

Where we rely on legitimate interest, you can object. See section 12.

5. Cookies

The Culture Dive product sets three cookies. All of them are strictly necessary or directly requested by you, which is why there is no cookie banner. A banner here would be theatre.

The first two are set with HttpOnly and Secure and are not readable by scripts, except cd_csrf, which must be readable by our own script for the protection to work. The third is only ever set when you click to dismiss the prompt, and only on a page you are already signed in to.

No third party can be contacted from a page in the portal: the content security policy allows connections and images only from our own origin, and a report is rendered with everything blocked.

[PLACEHOLDER: confirm the 180-day lifetime of the passkey-prompt cookie is acceptable. It is a user-interface preference, which is the category that is normally exempt from consent, but the exemption usually contemplates something shorter. Shortening it costs nothing.]

Part B — People who appear in content we collect

6. What this is, in plain terms

Culture Dive measures how a brand is talked about. To do that we collect public content and analyse it. That content can name you even though you have never used this product, never gave us anything, and have no relationship with us.

We think you are entitled to a straight account of that.

7. What we actually collect today

Today we collect one thing: the answers that AI answer engines give to our questions.

On a schedule, we ask ChatGPT, Perplexity and Gemini a fixed set of questions about a client's brand and category — questions like "what is this brand known for", "what criticisms come up about it", "who are its main competitors". We store the answer.

Those answers are free text written by a language model. They routinely name real people — founders, executives, journalists, critics, creators. When that happens, we are holding personal data about you that came out of a model, not out of anything you published.

Two things follow, and both matter:

• The model may be wrong about you. It may attribute a quote, a role or an opinion to you incorrectly. We store what it said because *what it said* is the thing we are measuring. We do not treat it as a fact about you, and neither should anyone reading our reports.
• We record which engine was asked, which model was asked for, and which model actually answered, against every stored answer.

What we do not collect today. Our system has entries for Instagram, TikTok, Reddit, YouTube, news RSS feeds and general web pages. No collector for any of them has been built. Nothing in this product currently fetches a social post, an article or a review. When the first one is built, this policy will be updated before it runs — including a proper legitimate interests assessment and a decision on how we give notice to the people whose content we collect.

[PLACEHOLDER: this section must be rewritten, not amended, when the first social or news collector ships. The change from "a model mentioned you" to "we collected your post" is a different processing operation with a different balance and a different notice duty.]

8. What we do with it

• We read it with a model. One AI model reads each stored item and proposes a sentiment, a confidence figure, some themes and a one-sentence summary. If your name is in the item, it goes to the model, and it can be repeated in the summary.
• A person rules on it. A member of our staff decides what is meaningful. Nothing goes into a client's report without that.
• We may quote it. Where a report needs evidence, we quote briefly and attribute it to the engine that produced it.

Items marked in our system as link-only are never sent to an AI model and never reproduced — only linked. Answer-engine output is not in that category, because it was generated in response to our own prompt.

9. Our legal basis, and the balance we have struck

We rely on legitimate interests (Article 6(1)(f)): the interest of a business in understanding how it is perceived in public discourse, and our interest in providing that service.

The balancing factors, as we see them:

• The content is public, or is generated in response to a neutral question.
• The subject matter is brands, products and categories — not individuals. We hold no entity for a person, we build no profile of a person, and we score, rank and compare items, never people.
• The audience is one client organisation, behind authentication. Reports are not published.
• We minimise what is reproduced. Our editorial rule is that quotes from third-party content are capped at 125 characters.

Two honest qualifications on that last point.

[PLACEHOLDER: the 125-character cap is not enforced by the software. It exists as a comment in one migration file. Nothing truncates a quote today. It must be enforced in code before this policy is published, or the sentence must be deleted. A minimisation control that only exists in a document is not a minimisation control.]

[PLACEHOLDER: no legitimate interests assessment has been carried out or written down. The paragraph above is the argument; it is not the assessment. Counsel to produce a documented LIA before publication.]

10. Telling you we hold it

Article 14 of the GDPR says that when we get personal data from somewhere other than you, we should tell you. We are not able to do that for content collected at scale: we generally have no contact details for the people named in it, and finding them would mean collecting more data about them than we hold now.

We therefore rely on Article 14(5)(b) — that individual notice would take disproportionate effort — and we publish this policy instead. [PLACEHOLDER: counsel to confirm the Article 14(5)(b) position and whether anything more is expected, for example a machine-readable notice or a searchable index page. This has not been assessed.]

11. If you are named in something we collected

You can object. You do not have to explain why in any particular form, and you do not have to be a customer.

Write to [PLACEHOLDER: privacy contact address] and tell us:

• your name, and any handle or spelling we would find it under;
• if you know it, roughly where or when you think you were mentioned;
• what you want — removal, correction, or a copy of what we hold.

What we will do: search for your name in the content we hold, tell you what we find, and remove it unless we have a compelling reason not to. We will answer within one month. If we need longer because the request is complex, we will tell you inside that month and explain why.

What we cannot do well yet, stated plainly:

[PLACEHOLDER: this is currently a manual process with no tooling behind it. There is no index over names in collected content, no search built for this purpose, and no supported way to remove a single item — the system keeps a per-client fingerprint ledger of every item ever seen, designed to outlive the content itself, so removing an item without also handling that ledger would let the same item be re-collected as new. Before this section is published, build: a name search over collected content, a single-item removal path, and a tombstone in the fingerprint ledger so a removed item stays removed. Until then, the commitment above can be honoured, but slowly and by hand, and the policy should say so rather than imply a self-service process exists.]

You can also complain to the AEPD, or to the supervisory authority where you live. Details are in section 15.

Both groups

12. Your rights, and what we can actually do today

You have the right to ask for a copy of your data, to have it corrected, to have it deleted, to have its use restricted, to object to processing based on legitimate interests, and to receive it in a portable format. You will never be charged or penalised for asking.

What you can do right now, yourself, in the portal:

Everything else is a manual request to [PLACEHOLDER: privacy contact address]. We will answer within one month.

Where we have to be honest about limits:

• Deletion. We do not currently delete user accounts. Under the Spanish LOPDGDD, records connected to a contractual relationship must be *blocked* rather than erased for the period in which liability could arise, and our system was built around that duty — a person's record is kept and their access is removed, rather than the record being destroyed. [PLACEHOLDER: this is only half true today. The blocking mechanism exists as a pair of database columns that are read on every sign-in but are written by nothing — there is no action that blocks an account, no schedule that unblocks it, and no rule about what a blocked record may be used for. There is also no deletion function of any kind, and twenty database relationships would refuse one. Decide the blocking policy, build the block action and the unblock schedule, and then rewrite this paragraph. Do not publish a description of a control that does not exist.]
• Access and portability. There is no export function. A request would be answered by hand today. [PLACEHOLDER: build an export. The audit vocabulary already reserves an event for it and nothing can emit it.]
• Restriction and objection. Same position: honoured by hand, not by a mechanism.

Whatever we do in response to a request, we record it in the audit log.

13. Who else handles your data

We keep this list short on purpose, and it lists only providers that are actually wired into the running system.

About OpenRouter and the models behind it. OpenRouter routes each request onward to a model provider. Our system deliberately does not pin which provider serves a call — that portability was a design decision — with the consequence that we cannot say from our own records which company processed any given request. [PLACEHOLDER: this is a real problem for the record of processing activities and for the sub-processor list a client will ask for. Two things must happen: OpenRouter's account-level data policy (retention, logging, and whether prompts may be used for training) must be checked, tightened and written down — nothing in the code sets any of it, so whatever the account default is, is our position; and a decision is needed on whether to record the serving provider per call.]

Not on this list, and worth saying: we use no third-party analytics, no advertising network, no marketing automation platform, no customer-data platform, and no data-broker or scraping vendor. Some such vendors appear in our internal planning documents. None is connected to anything.

14. Sending data outside the EU

All processing we control happens in the EU: the database is in Frankfurt, the application runs in Frankfurt, error reporting is on an EU-region host and the code refuses to start otherwise.

But several of our providers are US companies, and one of them — the AI gateway — routes requests onward to providers whose location we do not record. So we cannot claim there is no international transfer.

[PLACEHOLDER: for each provider in section 13, counsel must establish the transfer basis and record it — adequacy decision (for example the EU–US Data Privacy Framework, and whether the provider is certified), standard contractual clauses, and whether a transfer impact assessment is required. This has not been done for any of them. The OpenRouter position is the hardest and should be settled first, because it is the one where the receiving party is not fully known.]

15. How long we keep things

We have to be straightforward here. This system does not currently delete anything, and no retention schedule has been set.

The database is built for it — the two largest tables are partitioned by month specifically so that old data can be dropped — but the job that would drop them has never been written. Every category below therefore has, today, an actual retention period of "indefinitely".

[PLACEHOLDER: a retention schedule per data class is the single most important gap in this document, and it blocks the document. A privacy policy that cannot state a retention period is not finished. Two engineering traps for whoever builds the job: the per-client content fingerprint ledger is deliberately not partitioned and will survive any partition drop, so it needs its own pruning schedule; and dropping a partition is a schema operation that will orphan the AI readings attached to it rather than removing them.]

16. AI and automated decisions

Nothing we send to an AI model contains your account data. We checked this specifically. When we ask an answer engine a question, the request contains our own prompt, the brand name and the category, and nothing else — no user record, no email address, no account identifier, no IP address. The optional field that would let us tag a request with a user identifier is available to us and is deliberately never used.

Content we have collected does go to a model. That is the reading step described in section 8. If a collected item names a person, that name goes to the gateway and onward to a model provider.

No decision about you is made automatically. There is no scoring, ranking or profiling of individuals in this product. Sentiment attaches to a piece of content, not to a person — there is no person record for anyone in Part B and nothing is aggregated against a name. Nothing in this product produces a legal effect or a similarly significant effect on any individual, so the automated-decision rules in Article 22 do not apply.

A person rules on every conclusion. AI output is a candidate. A member of our staff keeps it, kills it or merges it, and a named person authors and publishes every report.

If that changes, this section changes first. Specifically: if we ever build a feature that identifies, ranks or evaluates named individuals — for example mapping creators by their affinity to a brand — that is profiling, it needs its own assessment under both the GDPR and the EU AI Act, and it will not ship before that assessment is written. [PLACEHOLDER: this feature appears in the commercial design materials as a priced product. It does not exist in the software. If it is going to be built, the assessment should be commissioned now rather than during the build.]

17. How we protect data

• Every workspace's data is isolated in the database itself, by row-level security, not only in application code. Isolation is proved by an automated test suite that attempts cross-tenant reads and requires them to fail.
• The audit log cannot be changed or deleted by the application. [PLACEHOLDER: today this rests on a single control — the database privileges withheld from the two application roles. A second control, a trigger that refused updates and deletes outright, was removed as a side effect of a later change and has not been restored, and no test covers it. Restore it. Separately, the log is append-only but not tamper-evident: the columns designed to chain each entry to the previous one exist and are empty, because the component that would fill them was never built. Do not describe the log as tamper-proof until it is.]
• Sign-in is by magic link, with optional authenticator app and passkeys.
• Error reports are scrubbed before they leave: request bodies, cookies and headers are dropped, query strings are redacted, all local variables are stripped from stack traces, and a user is reduced to an identifier — never an email address.
• Invitation links are stored only as a hash. The link itself exists only in the email.
• Payment card details never reach our systems.

18. Changes to this policy

We will update this policy when the product changes, and we will change it before the change goes live, not after. Where a change materially affects you, we will tell you.

[PLACEHOLDER: there is currently no mechanism to show a user a legal document or to record that they have seen one. Two database tables were specified for this and neither exists, and there is no screen in the product on which a document could be shown or accepted. Until it is built, "we will tell you" means by email, and this paragraph should say so.]

19. Complaints

If you are unhappy with how we have handled your data, tell us first at [PLACEHOLDER: privacy contact address]. We would rather fix it.

You can also complain to the Spanish data protection authority:

> Agencia Española de Protección de Datos (AEPD)

> C/ Jorge Juan, 6, 28001 Madrid, Spain

> www.aepd.es

If you live in another EU country, you can complain to your own supervisory authority instead.

Reviewer notes — Privacy Policy

Everything the draft above cannot yet state as fact, with the evidence.

Blocking. This policy cannot honestly be published until these are resolved.

Corrections this review made to the draft, which the reviewer should not undo