Tag: Transparency
All blog posts with this tag.
- 14 Sep, 2026
AI Act and analytics: when should an AI feature in a dashboard be disclosed?
Analytics products increasingly include AI-assisted features: automatic monthly traffic summaries, anomaly detection, generated reporting comments, conversational dashboard assistants and optimisation suggestions. Since 2 August 2026, part of the AI Act’s transparency obligations has applied. This is no longer only a topic for public chatbots, large platforms or general-purpose AI models. It can also concern software publishers adding AI interfaces to professional products, depending on the system and use case. The useful question is not: “Does every AI-powered feature need a warning?” The useful question is: is the person directly interacting with an AI system, or being exposed to AI-generated or manipulated content in a context covered by Article 50? This article gives product, marketing, analytics and compliance teams a practical way to reason about the issue. What started to apply on 2 August 2026 The European Commission published guidelines on 20 July 2026 to help providers and deployers comply with transparency obligations for certain AI systems. These obligations started applying on 2 August 2026. They are meant to help people recognise when they are interacting with an AI system or when content has been generated or modified by AI. Broadly speaking, providers must design certain systems so people are informed when they directly interact with AI, and must add machine-readable marks to enable detection of certain AI-generated or manipulated content. Deployers also have information duties in some cases, including deepfakes, certain public-interest content without human review, and some emotion recognition or biometric categorisation systems. For a professional analytics product, not every automated feature falls into the same bucket. A statistical calculation, a rule-based alert or a background anomaly model is not the same as a visible conversational assistant. Case 1: a conversational assistant in the dashboard This is the clearest case. If a user can ask a dashboard assistant a question such as “why did traffic drop this week?”, the user is directly interacting with AI. Where the Article 50 conditions are met and the AI character is not obvious, the interface must inform the user clearly, distinctly and accessibly at the start of the first interaction that they are dealing with an AI system, not a human analyst or a purely deterministic rule. A concise label is usually enough:AI assistant: responses are generated automatically from the data available in this workspace. Verify important conclusions before making decisions.Transparency should not become a frightening legal wall. It should be clear, accessible and proportionate. Case 2: an automatically generated analytics report summary An automatic summary can have several forms. If it remains internal and helps a team prepare its monthly analysis, the main issue is governance: who can generate it, which data it uses, whether it is reviewed, and how the system avoids inventing causes that are not supported by the data. If the summary is sent to clients, a board, investors or the public, the analysis changes. The text may become information generated by an AI system. In some cases, especially where it concerns matters of public interest without human review or editorial control, Article 50 requires specific information. For a B2B analytics vendor, a simple operational rule can help:an internal AI-generated draft should be identified as such in the interface; an automatically generated external report should keep a generation trace; reports that influence important decisions should not be published without real human review; for information published to inform the public on matters of public interest, any human review invoked for the Article 50 exception should be genuine and documented.The key word is genuine. A superficial approval step should not be described as editorial control. Case 3: anomaly detection A system that flags an unusual traffic variation is not always a direct AI interaction. It may be a statistical model, a threshold rule or a background automated process. That does not mean there are no obligations. If personal data is involved, GDPR, minimisation, documentation and governance remain relevant. But Article 50 transparency is not triggered simply because an algorithm exists. The product should name the feature honestly. “Anomaly detected” may be more accurate than “AI discovered a problem”. If an explanation is generated by a model, separate the measured signal from the generated interpretation. Example:Measured signal: organic sessions fell by 34% over seven days. Generated hypothesis: the drop may be related to three acquisition pages. Status: hypothesis to verify, not an automatic conclusion.This distinction reduces analytical hallucination. Case 4: automatic recommendations AI recommendations are attractive: “improve this page”, “reduce this channel”, “increase this budget”. They are also risky if they hide data limitations. In analytics, a recommendation should show:the data used; the period analysed; known exclusions; confidence level or at least uncertainty; the difference between observation, hypothesis and recommendation.The AI Act raises the transparency question for individuals. Analytics credibility adds another one: does the user understand why the recommendation exists? Good design does not only say “AI-generated”. It gives enough context to verify or challenge the recommendation. Provider or deployer: why the distinction matters The Commission distinguishes providers, who develop or place an AI system on the market, from deployers, who use an AI system under their authority in a professional or organisational context. A SaaS publisher integrating an AI feature into its product may be the provider of that feature for its customers. A company enabling that feature for its employees may be a deployer. In some scenarios, both roles coexist. This matters for product teams. It is not enough to assume that the provider of the underlying model carries all responsibility. The software publisher designing the experience, choosing the data, displaying the output and defining the use case should document its own choices. Checklist for an AI feature in analytics Before launching an AI feature, check:does the feature involve direct interaction between the user and an AI system? could the user think they are interacting with a person or a human-authored analysis? can the generated content be exported, shared or published? is real human review planned before external publication? does the interface clearly indicate what is generated automatically? does the output separate measured data, hypotheses and recommendations? are the necessary prompts, model versions and data sources logged, with personal data filtered, controlled access and a defined retention period? are known limits understandable by a business user? can support teams explain the feature at a high level? are related personal-data processing operations documented separately?What to avoid Avoid labels that make AI invisible. “Automatic analysis” may be too vague if the user is actually interacting with a generative system. Avoid the opposite excess too. A heavy legal banner on every chart can make the interface less readable without improving user understanding. Most importantly, avoid unsupported causal claims. A model can detect a correlation or propose a hypothesis, but it should not invent a business cause without evidence. In an analytics dashboard, transparency is not only about legal disclosure. It should help the user make better decisions. Conclusion The AI Act does not mean that every algorithmic feature in an analytics product needs a permanent warning. It does require serious treatment of situations where users directly interact with AI or receive generated content in a context covered by Article 50. For SaaS publishers, the right response is not only legal. It is product discipline: name AI when it is used, explain its limits, log the relevant context, and separate measured facts from generated interpretation. It is also a credibility opportunity. Useful analytics should not merely generate more commentary. It should generate commentary that can be checked. FAQ Are all automated analytics features covered? No. A statistical rule, a trend calculation or a threshold alert is not automatically covered by the AI Act transparency obligations. The first step is to qualify the system and determine whether it directly interacts with a person or generates content that must be disclosed. Do AI summaries need a banner every time? Not necessarily. The information should be clear, understandable and visible at the right point in the workflow. A stable notice attached to the summary module may be more useful than a repeated intrusive alert. Does human review remove all labelling questions? It depends on the context, the use of the report and the actual level of editorial review. The safer approach is to document the validation chain rather than assume that any human review removes every obligation. SourcesEuropean Commission - Guidelines on transparency obligations for providers and deployers of AI systems European Commission - Transparency obligations under Article 50 of the AI Act European Commission - Guidelines published on 20 July 2026
- 22 Jun, 2026
Analytics privacy notice: useful wording and claims to avoid
A privacy notice can be legally dense and technically wrong. A common example says “we only use anonymous data” while the site sends full URLs, campaign identifiers and IP addresses to several providers. At the other extreme, some notices list twenty abstract categories without helping readers understand what analytics actually does. Quality comes from alignment between:deployed collection; purposes; roles; consent or another applicable framework; retention; rights; the words used.The GDPR requires information to be concise, transparent, intelligible and easily accessible. Articles 12, 13 and 14 govern much of the content. A useful analytics notice should remain readable while describing important facts with enough precision. This is an editorial and operational method, not a universal clause or legal opinion. Start with reality, not a downloaded template Collect four internal sources before writing:the tracker inventory; the data collection summary; contracts, DPAs and subprocessor lists; consent and retention configuration.The notice is the public view of verified facts. It should not be used to guess how the site works. A legal template can structure headings. It cannot know whether you collect a full URL, store IP addresses, create a visitor identifier, allow vendor reuse, send free text, activate extended analytics after consent, export to a warehouse, or share identifiers across sites. Those answers must come from the audit. Use layered information One ten-page policy is not always the best entry point. Layer 1: information at the relevant moment Near the choice or collection, state the essentials:purpose; controller; required or optional nature; link to details; means to accept, refuse or withdraw where consent applies.For strictly limited measurement assessed as not requiring consent, a short notice can link to the analytics section. Layer 2: dedicated analytics section Explain:what is measured; why; how data are reduced; which provider is involved; how long information remains; how to exercise rights or ask questions; which capabilities depend on consent.Layer 3: detailed documentation A technical page or collection sheet can explain fields and transformations. It does not replace GDPR information, but it gives interested readers detail without overloading the first layer. Every layer must tell the same story. Sections to cover 1. Controller identity Name the entity that determines purposes and means, with contact details. In a group, the visible brand is not necessarily the legal controller. Include DPO details where applicable, or a clearly identifiable privacy contact. Useful wording:The controller for audience-measurement data on this site is [entity], available at [address or form]. For data-protection questions, contact [DPO or privacy contact].Avoid:We respect your privacy.It states an intention but identifies nobody. 2. Specific purposes Separate purposes instead of using “improve your experience” for everything. Examples include:measuring visits and viewed pages; detecting navigation errors; understanding acquisition sources; measuring demo requests; producing aggregate statistics; personalising content; measuring advertising campaigns.These do not necessarily share one legal framework. If minimal analytics runs by default and extended analytics starts after consent, say so. Useful wording:We use limited audience measurement to understand visit volume, viewed pages and main traffic sources. Enriched attribution and [other capability] are enabled only after your choice when consent is required.Avoid:We collect data to improve our services and offers.It is too broad. 3. Data categories and signals The notice need not reproduce every technical key, but it should be concrete. Depending on the setup:page path; visit time; referrer domain; approved campaign parameters; reduced device and browser class; approximate country or region; conversion event; optional pseudonymous identifier; temporarily received IP address; consent choice.Distinguish stored data from data used transiently to produce an aggregate result. Useful wording:For each visit, we record the page path, time, referrer domain when transmitted, device category and approved campaign parameters. The IP address is [describe exact handling]. Form contents are not sent to analytics.Avoid:We collect no personal data.An IP address, identifier or combination of signals may be personal data depending on the processing. 4. Legal basis and tracker framework Do not merge:storing or accessing information on the terminal under ePrivacy and national law; the GDPR legal basis for personal-data processing.The analytics consent checklist explains the distinction. Depending on the facts, the notice may refer to consent, legitimate interests after appropriate assessment, limited audience measurement under a conditional national exemption, or strictly necessary functionality. Do not use a legal basis as a marketing badge. Explain how the choice operates or how the assessment is documented. Avoid:Our tool is CNIL compliant, so consent is not needed.The CNIL states that the conditions depend on setup and context, and that providers cannot claim certification or approval based on its self-assessment. 5. Recipients and providers Identify recipient categories and, where it improves transparency, key providers. Explain roles for internal authorised teams, analytics vendor, hosting provider, technical support, agency and data warehouse. “Trusted partners” is not specific enough. Assess whether each provider is a processor, independent controller or another role based on the facts and contract. 6. International transfers Where data are accessible or transferred outside the EEA, explain relevant countries or categories, mechanisms and how to obtain more information. Do not confuse hosting region, vendor headquarters, support access, subprocessors and legal transfer. “Hosted in Europe, therefore no transfer” requires verification of the entire chain. 7. Retention A phrase such as “as long as necessary” needs concrete periods or criteria. Separate:tracker or identifier; raw events; aggregate reports; security logs; backups; exports.Useful wording:Analytics events are retained for [period]. Aggregate statistics remain for [period or criterion]. Technical logs have a separate [period]. Manual exports are deleted under [procedure].For the French CNIL framework, the thirteen-month tracker-lifetime and twenty-five-month collected-information recommendations are reference points to assess, not values to copy blindly. 8. Rights Explain applicable rights and provide a simple contact method. Depending on basis and processing, rights may include access, rectification, deletion, restriction, objection or portability. Truly anonymous analytics may not permit identification for an individual request. Explain this precisely rather than using anonymity as a blanket exception. Include the right to lodge a complaint with the competent supervisory authority. 9. Withdrawal or objection Where consent applies, provide an accessible way to withdraw it according to applicable rules. Where another basis applies and a right to object exists, explain the process. A “manage cookies” link must work on mobile, remain visible and change actual tag behaviour. 10. Date and changes Add a last-updated date and a process for material changes. Review the notice when the team adds a tool, purpose, identifier, retention period, export, provider, country or consent change. A concise change history can help returning readers. A short section to adapt This is an editorial skeleton, not a publication-ready clause.Audience measurement We use [tool] to measure visits, viewed pages and main traffic sources. This helps us detect navigation problems and evaluate content usefulness. Depending on our configuration, processed data include [concrete list]. [Describe IP and identifier handling]. Form contents and unapproved URL parameters are not sent. [Provider] acts as [role] and processes data in [relevant locations and transfers]. Data are retained for [periods by layer]. [Explain the ePrivacy framework and GDPR legal basis, including consent operation where applicable]. You may exercise your rights or ask a question at [contact]. You may [withdraw consent / object] through [method].Every bracket requires a verified answer. Wording that weakens credibility “Completely anonymous data” Use this only when the method supports the claim and the information can no longer reasonably identify or single out a person. Otherwise use precise descriptions such as aggregate data, identifiers removed, pseudonymised data, reduced granularity or IP address not retained in events. These terms are not interchangeable. “No data are shared” When a provider hosts or processes collection, it receives data as part of the processing. “Data are not sold” or “not used for advertising” may be accurate, but “no sharing” is often not. “GDPR compliant” Compliance depends on the controller, purpose, setup, contract and operations. Describe measures instead of issuing a universal verdict. “Necessary cookies” Explain necessary for what. A marketing team finding a tracker useful does not make it technically necessary. “We may change this policy at any time” This does not explain material-change handling. Add a date and an appropriate notification process where required. Align the notice with product delivery Policies are often reviewed annually while stacks change weekly. Add a release control:every new tag request states purpose, data and provider; the privacy or analytics owner assesses impact; the collection summary is updated; the notice and CMP change where necessary; deployment is tested; evidence is retained.For URLs, apply the parameter allowlist before the notice promises reduced collection. A twelve-question editorial audit Ask:Is the controller identifiable? Are purposes separated? Are data described concretely? Is temporary receipt distinguished from storage? Is the GDPR legal basis stated? Is the tracker regime explained without shortcuts? Are providers and roles clear? Were transfers verified? Are retention periods concrete? Are rights and contact accessible? Does withdrawal or objection work? Does the text match the current network and configuration?A negative answer triggers a correction to the stack, the text, or both. Conclusion A good analytics privacy notice does not reassure through adjectives. It provides understandable facts. It explains who measures, why, with which signals, for how long, through which providers, under which framework and with which controls for individuals. Start from the technical inventory, write in layers, validate necessary legal qualifications and connect every stack change to documentation updates. Transparency is not separate from the product. It is the public description of its governance. FAQ Should the analytics vendor be named? The GDPR requires information about recipients or recipient categories. Naming the main provider often improves clarity, although the precise form depends on the processing and notice structure. Can the notice say data are anonymous? Only when anonymisation is demonstrated. Pseudonymised, aggregated or IP-free data are not automatically anonymous. Does the notice replace a consent banner? No. The notice provides detail. Where prior consent is required, a valid choice must occur before covered trackers start. Must every analytics event be listed? Not necessarily in the first layer. Use concrete categories and provide deeper documentation where useful. Sensitive or unexpected events require explicit assessment. What if a vendor changes subprocessors? Assess recipients, transfers, contracts and risk, then update documentation and information where necessary. SourcesRegulation (EU) 2016/679, Articles 12, 13 and 14 CNIL, Examples of privacy information notices CNIL, Informing individuals CNIL, Audience-measurement cookies and consent conditions EDPB, Guidelines on transparency under Regulation 2016/679