Category: Compliance
All blog posts in this category.
- 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
- 07 Sep, 2026
Cyber Resilience Act: preparing incident reporting for software, scripts and SDKs
The Cyber Resilience Act is progressively becoming operational for software publishers. From 11 September 2026, manufacturers in scope will have to report actively exploited vulnerabilities and severe incidents that impact the security of products with digital elements. For a B2B SaaS company, analytics tool, JavaScript script, SDK or component distributed to customers, the topic should be analysed carefully. It would be wrong to assume that every SaaS service is automatically covered in the same way. It would also be risky to wait until December 2027 before organising incident response. This article is not a legal qualification. It gives product, security and engineering teams a practical preparation method when they distribute software or components used by customers. What changes on 11 September 2026 The European Commission states that, as of 11 September 2026, manufacturers must report certain events concerning products with digital elements: actively exploited vulnerabilities and severe incidents affecting product security. The timelines are short:early warning without undue delay and within 24 hours of becoming aware; vulnerability notification within 72 hours; final report within the applicable deadline, including 14 days after a corrective measure or mitigation becomes available for an actively exploited vulnerability, or within one month of the 72-hour notification for certain severe incidents.Notifications go through the CRA Single Reporting Platform, operated by ENISA, and are routed to the competent CSIRTs according to the applicable rules. The important point is that these reporting obligations arrive before the full application of the main product obligations under the Cyber Resilience Act. They should be prepared now, even if other parts of the regime come later. Why scripts and SDKs deserve attention Analytics teams often think first about the security of the main application: authentication, dashboard access, exports and databases. But the product surface can include other elements:a JavaScript script installed on customer sites; a client-side or server-side SDK; an open-source library maintained by the vendor; a connector or plugin; an API used to collect or expose data; an admin interface capable of changing injected code.These elements do not automatically have the same legal qualification. But they belong in the security inventory, because a vulnerability in a distributed component can affect multiple customers at once. For an analytics product, the collection script is especially sensitive. It runs on third-party websites, in visitors’ browsers, and may be updated centrally. A distribution flaw, compromised build or unauthorised modification could have a broader impact than a broken chart in a dashboard. Do not confuse a bug, a vulnerability and a severe incident Not every technical issue is a CRA report. A broken chart, a loading problem or an aggregation error is not necessarily an actively exploited vulnerability or a severe security incident. The first step in the runbook should therefore be qualification.Situation Question to askFunctional bug Does it affect product security or only user experience?Internally found flaw Is it exploitable, exposed, fixed or communicated?Actively exploited vulnerability Is there evidence of real exploitation?Security incident Does it have a severe impact on product security or users?Personal-data incident Does it also require separate GDPR breach assessment?The risk runs both ways. Under-reporting a truly serious issue exposes the organisation. Reporting every unqualified bug creates noise and weakens response discipline. The decision should be documented even when the conclusion is that no report is required. The minimal runbook to prepare A useful runbook must be concrete. It should not merely say “notify legal”. It should allow the team to act in the first hours. 1. Component inventory List products, scripts, SDKs, plugins and connectors distributed or made available to customers. For each one, document the internal owner, repositories, build pipeline, update mechanism, exposed customers, critical dependencies and communication channels. 2. Qualification criteria Define a simple grid: whether security is affected, whether exploitation is observed, potential impact, customer scope, corrective measure availability, technical evidence and possible parallel obligations. 3. Decision team Identify who can qualify the event: engineering, security, product, leadership, legal and the DPO when personal data is involved. Backups should be known. Weekends and holidays should be covered. 4. Timestamping The deadline starts when the organisation becomes aware. The team must record when it had enough information to suspect or qualify the event. A ticket without a reliable timestamp will make compliance harder to demonstrate. 5. Evidence and logging Preserve logs, versions, build hashes, deployed artefacts, exploitation traces, customer messages, internal alerts and qualification decisions. The evidence should be sufficient to reconstruct the timeline. 6. Reporting channel The Single Reporting Platform is operated by ENISA. Teams should know who has the necessary access, which information is needed and what to do if the primary access path is unavailable. ENISA has indicated that there is no API planned at this stage, which makes human procedures even more important. 7. Customer communication Regulatory reporting does not replace customer communication. Prepare concise templates: what is known, what remains uncertain, what customers should do and when the next update will come. Analytics and third-party scripts An analytics script should be treated as a sensitive asset, even when it collects limited data. It may be embedded in public pages, conversion funnels or authenticated environments. The security of the script therefore matters not only to the vendor but also to the sites that install it. Concrete controls include:separation of rights between application code, build pipeline and script publication; dependency review; signing or integrity controls for artefacts where relevant; detection of unexpected changes; fast rollback capability; mitigation or disabling procedure; documentation of versions deployed to customers.These practices are useful beyond the CRA. They reduce operational risk and make crisis communication more reliable. What to decide now Teams that wait for the first incident to organise their response will lose time in the first 24 hours. Those are exactly the most constrained hours. By the end of September, a software team should be able to answer four questions:Which customer-distributed components could be in scope? Who qualifies an actively exploited vulnerability? Who can submit a notification within the deadline? How can the decision timeline be proven?If these answers do not exist, the topic is not yet under control. Conclusion The Cyber Resilience Act should not be reduced to a distant 2027 deadline. Reporting obligations applying from 11 September 2026 already require manufacturers in scope to prepare. For SaaS and analytics vendors, the priority is not to panic or to assume everything is automatically covered. The priority is to inventory components, qualify roles, prepare the runbook and document decisions. A good reporting process is not only a regulatory response. It is evidence of product maturity. FAQ Does the CRA apply to every SaaS dashboard? Not automatically. The qualification depends on the product, the role of the organisation and the way software components are placed on the market or provided. The article is a preparation checklist, not a legal classification of every SaaS case. Should every security bug be reported through the CRA process? No. The reporting duty discussed here concerns actively exploited vulnerabilities and severe incidents with a security impact, according to the CRA framework. Ordinary bugs still need internal handling, but they should not be confused with regulatory reporting triggers. Why should analytics teams care? Analytics stacks often include scripts, SDKs, API keys, client-side configuration and third-party dependencies. Even when the legal obligation falls elsewhere, teams need clear incident routing and supplier contacts. SourcesEuropean Commission - Cyber Resilience Act reporting obligations European Commission - Cyber Resilience Act summary ENISA - CRA Single Reporting Platform FAQ
- 13 Apr, 2026
GDPR audience measurement: the CNIL framework to understand before choosing a tool
Audience measurement is no longer just a tooling decision. It is a governance decision. An SMB may legitimately want to understand pages, sources and simple conversions without turning its website into a heavy marketing stack. That is a reasonable goal. The mistake is to turn a privacy-first product choice into a blanket legal promise. The CNIL framework is more specific. It describes conditions under which strictly limited audience measurement can, in some cases, be implemented with a lighter consent burden. That position depends on the real purpose, configuration, retention period, absence of cross-use, provider role and visitor information. The useful question is therefore not "which tool removes all legal work?". The useful question is: does my actual setup remain within a documented, minimal and verifiable audience-measurement perimeter? What the CNIL framework says The CNIL explains that traffic and performance statistics can be necessary for operating a website or application. It therefore describes a limited perimeter for audience-measurement trackers, provided the purpose stays strictly focused on the site or app audience and is carried out for the publisher's exclusive account. The framework excludes uses that combine the data with other processing, send non-anonymous data to third parties, or follow a person globally across several websites or applications. The CNIL also recommends informing users, limiting tracker lifetime, capping retention for collected information and periodically reviewing those periods. It provides a self-assessment tool to help vendors document their analysis. That nuance matters. Self-assessment is not certification, and it does not prejudge what the CNIL could conclude during an investigation. Site publishers still need a cautious, documented reading of their setup. The criteria that should guide the choice Before choosing an analytics solution, check these points first. 1. Strictly limited purpose Collection should help understand traffic, performance, content viewed or navigation issues. If the same tool is used for retargeting, advertising activation, profiling or CRM enrichment, the setup no longer fits a minimal audience-measurement perimeter. 2. No vendor reuse The provider should process data for your account. Reuse for the provider's own services, advertising, global benchmarks or loosely governed product improvement increases risk. 3. No cross-site tracking An identifier shared across several publishers or domains to follow global browsing behavior is incompatible with minimal audience measurement. 4. Statistical data and limited retention The logic should remain aggregated and proportionate. Retention periods should be limited and reviewed. Raw or pseudonymized records should not become a permanent marketing archive. 5. Clear visitor information Even when a lighter collection setup is possible, visitors still need clear information. The privacy policy should explain what is collected, why, for how long, by whom and how rights can be exercised. Strict and Extended: a useful product separation For privacy-first analytics, separating a minimal mode from an enriched mode is clearer than offering one vague switch. Strict should cover the core needs: page views, readable sources when available without enrichment, volumes, trends and simple conversions. It should minimize fields and avoid data that is not necessary for the stated purpose. Extended should be explicit. It can support richer needs: detailed UTM campaigns, advanced events, goals, technical context, segmentation or multi-site analysis. Those uses can be legitimate, but they should be treated as configuration choices, not as the silent default. This distinction helps product teams, DPOs, marketers and clients talk about the same operational reality. The checklist before publishing Before presenting your analytics setup as launch-ready, document at least:the exact measurement purpose; the fields collected in Strict; the fields added in Extended; retention periods; absence of cross-use with other processing; potential transfers and contractual basis; the updated privacy policy; the internal or vendor analysis based on CNIL sources; the profile-change procedure; the owner who approves collection changes.This documentation does not replace legal review, but it prevents marketing copy from becoming operational debt. What Pomelo should promise publicly The strongest position is not an absolute claim. It is a controlled product promise:cookieless by default; minimal collection; clear documentation of collected fields; explicit Extended configuration when teams need richer detail.That is more durable than a slogan. European SMBs, B2B SaaS teams and multi-site digital teams need analytics that is readable, governable and stable over time. Sources Sources checked on May 9, 2026.CNIL, Cookies and audience measurement solutions CNIL, audience-measurement self-assessment tool, July 2025 Article 82 of the French Data Protection Act