Forem: Guillermo Llopis

I Built a 510-Byte Analytics Script. Here's How (and Why).

Guillermo Llopis — Tue, 07 Apr 2026 07:32:06 +0000

Most analytics scripts are massive. Google Analytics loads ~82 KB of JavaScript. Even privacy-focused alternatives like Plausible (~1 KB) and Umami (~2 KB) are significantly larger than they need to be.

I built Fairlytics with a tracking script that's 510 bytes gzipped. Here's the technical story of why and how.

Why small matters

Every byte of JavaScript your page loads has a cost:

Parse time on mobile devices
Network transfer on slow connections
Render-blocking potential
Core Web Vitals impact

For an analytics script that runs on every page of your site, these costs multiply across every single page view.

The privacy pipeline

When a visitor loads a page with Fairlytics, here's what happens:

The 510-byte script sends a POST request with 4 fields: site ID, page URL, referrer, and page title
Server receives the request along with the IP address and User-Agent (standard HTTP)
The IP is used for an in-memory GeoIP lookup → produces a 2-letter country code → IP is discarded (never stored)
The User-Agent is parsed into browser family + OS family → raw string discarded
Referrer is reduced to domain only
Query parameters are stripped from the URL
A daily-rotating anonymous hash is generated for unique visitor estimation (no cookies needed)

What gets stored: page_path, page_title, referrer_domain, country_code, browser_family, os_family, device_type, session_id, viewed_at

What never touches the database: IP addresses, full user agents, full referrer URLs, query parameters, any form of persistent user ID.

How the script works

The tracker is vanilla JavaScript, no dependencies. It:

Reads the data-site and data-api attributes from its own script tag
Sends a single POST request on page load
Listens for popstate events for SPA navigation
Checks for DNT and GPC signals — if either is set, it does nothing
Uses navigator.sendBeacon when available for non-blocking requests

That's it. No event queue, no batching, no retry logic, no session management, no cookie handling.

What you get without cookies

Without setting any cookies, Fairlytics provides:

Page views and unique visitors (via daily-rotating hashes)
Top pages by traffic
Referrer sources (domain only)
Country, browser, OS, and device type breakdowns
Goal tracking for custom conversion events
Real-time dashboard

The comparison

	Google Analytics	Plausible	Fairlytics
Script size	~82 KB	~1 KB	510 bytes
Cookies	2-4	0	0
Consent banner needed	Yes	No	No
Data points per pageview	17+	~8	4
IP storage	Yes	Temporary	Never

Try it

Fairlytics is live and free to try (10K pageviews/month, no credit card):

<script src="https://app.fairlytics.dev/js/tracker.v1.js"
        data-site="YOUR_SITE_ID"
        data-api="https://app.fairlytics.dev"></script>

One line. 510 bytes. Zero cookies.

Website: https://fairlytics.dev
Live demo: https://fairlytics.dev/demo/

GDPR Analytics Requirements Explained in Plain English

Guillermo Llopis — Mon, 16 Mar 2026 09:09:57 +0000

You've read that GDPR affects your website analytics. You've seen the horror stories about fines. But when you try to find out what you actually need to do, you get 4,000-word legal articles that leave you more confused than when you started.

Here's the short version: GDPR doesn't ban analytics. It just has rules about how you collect and process visitor data. Depending on which analytics tool you use, compliance is either a significant burden or essentially automatic.

What the GDPR Actually Says About Analytics
The GDPR (General Data Protection Regulation) applies when you process personal data of people in the EU. Personal data means any information that can identify a person — directly or indirectly.

For website analytics, the relevant personal data typically includes:

IP addresses. Yes, IP addresses are personal data under GDPR. The Court of Justice of the EU confirmed this in 2016 (Breyer v. Germany).
Cookies and device identifiers. Any unique identifier stored on a visitor's device.
Location data derived from IP addresses.
Behavioral data that could be combined with other data to identify someone (browsing patterns, visit history across pages).
If your analytics tool collects any of these, GDPR applies to that processing.

The Six Requirements That Matter
GDPR has 99 articles and 173 recitals. For analytics, only a handful of requirements actually matter in practice:

You Need a Legal Basis You can't just collect data because you want to. You need one of six legal bases defined in Article 6. For analytics, only two are realistic:

Consent (Article 6(1)(a)): The visitor explicitly agrees to being tracked. This is what cookie consent banners do. It's legally bulletproof but practically painful — most visitors reject cookies, so you lose 30-70% of your data.

Legitimate interest (Article 6(1)(f)): You argue that basic website analytics is a reasonable business need that doesn't override visitors' privacy rights. This can work for basic, aggregated analytics — but not for tools that build individual visitor profiles or track across sites.

Most privacy-focused analytics tools rely on either legitimate interest or argue that they don't process personal data at all (making GDPR requirements not applicable).

You Need a Privacy Policy Article 13 requires you to tell visitors:

What data you collect
Why you collect it (purpose)
What legal basis you rely on
Who processes the data (you, your analytics provider)
How long you keep it
What rights visitors have (access, deletion, etc.)
Whether data is transferred outside the EU
This applies regardless of which analytics tool you use. Even if your analytics is fully GDPR-compliant, you still need to mention it in your privacy policy.

You May Need Consent (The Cookie Rule) This is where people get confused. The cookie consent requirement actually comes from the ePrivacy Directive (2002/58/EC), not GDPR directly. But they work together.

The rule: If you store or access information on a user's device, you need consent — unless it's "strictly necessary" for the service the user requested.

Google Analytics uses cookies → consent required
Matomo uses cookies by default → consent required (unless you enable cookieless mode)
Plausible, Fathom, Fairlytics use no cookies → no consent required under ePrivacy
Several EU data protection authorities, including the French CNIL, have explicitly stated that cookieless audience measurement tools can operate without consent if they meet specific criteria: no cross-site tracking, no individual profiling, data used only for aggregate statistics.

You Need a Data Processing Agreement If you use a third-party analytics service (any cloud-hosted tool), that provider is your data processor under Article 28. You need a Data Processing Agreement (DPA) that covers:

What data they process and why
Security measures they implement
What happens to data when you stop using the service
Their obligations regarding sub-processors
Data breach notification procedures
Most reputable analytics tools provide a DPA. If yours doesn't, that's a red flag.

This requirement doesn't apply if you self-host (since there's no third-party processor).

International Data Transfers Need a Mechanism If your analytics provider stores data outside the EU, you need a legal mechanism for that transfer (Chapter V of GDPR):

EU-US Data Privacy Framework: If the provider is certified, transfers to the US are permitted.
Standard Contractual Clauses (SCCs): Contractual safeguards approved by the European Commission.
Adequacy decisions: Some countries (UK, Japan, South Korea, etc.) are deemed to have adequate data protection.
This is exactly why Google Analytics got into trouble. After the Schrems II ruling invalidated the Privacy Shield in 2020, there was no valid transfer mechanism for GA data going to US servers. The EU-US Data Privacy Framework (adopted July 2023) fixed this for certified companies, but the legal landscape remains uncertain.

Easiest solution: Use an analytics tool that stores data in the EU. This eliminates the transfer question entirely.

Data Minimization and Storage Limitation Article 5 requires that you:

Collect only the data you actually need (data minimization)
Keep it only as long as necessary (storage limitation)
Google Analytics collects 40+ data points per visitor. If all you need is pageview counts and traffic sources, collecting fingerprinting data, demographics, interests, and cross-site behavior violates the minimization principle.

Define a retention period and stick to it. 24 months is a common choice for analytics data — long enough to see year-over-year trends, short enough to be defensible.

What This Means in Practice
Here's a decision tree:

If you use Google Analytics:

You need a cookie consent banner (ePrivacy Directive)
You need consent as your legal basis (GDPR Article 6(1)(a))
You need a privacy policy mentioning GA's data collection
You need to verify Google's DPF certification covers GA
You'll lose 30-70% of your traffic data from consent rejection
You need to configure data retention settings
You need to document this in a Record of Processing Activities
If you use Matomo (self-hosted, cookieless mode):

No consent banner needed (if configured correctly)
You can use legitimate interest as your legal basis
You need a privacy policy mentioning your Matomo setup
No DPA needed (you control the data)
You need to maintain the server and keep it secure
You need to configure IP anonymization manually
If you use a cookieless cloud tool (Plausible, Fathom, Fairlytics):

No consent banner needed
Legitimate interest as legal basis (or no personal data processed at all)
You need a privacy policy mentioning the tool
You need a DPA with the provider (they should provide one)
Verify data is stored in the EU (or that a valid transfer mechanism exists)
That's it
Common Misconceptions
"GDPR means I need a cookie banner." No. GDPR doesn't mention cookies. The ePrivacy Directive requires consent for non-essential cookies. If your analytics tool doesn't use cookies, no banner needed.

"GDPR only applies to EU-based businesses." No. It applies to anyone processing personal data of people who are in the EU. If your website is accessible in Europe (it is), GDPR applies to your analytics.

"I'm too small for anyone to care." Fines are proportional to company size, but enforcement isn't limited to large companies. Austrian, French, and Italian DPAs have all issued decisions against small websites using Google Analytics. More importantly, GDPR compliance is a legal obligation, not a risk calculation.

"Anonymizing IP addresses makes GA compliant." Google's IP anonymization truncates the last octet (e.g., 192.168.1.xxx). The remaining portion is still personal data according to several EU DPAs. Additionally, GA still sets cookies, which requires consent regardless of IP handling.

"I can just block EU visitors." Technically possible, but impractical. You'd need reliable geolocation, you'd lose EU traffic, and it's a poor user experience. Fixing your analytics setup is simpler than geo-blocking an entire continent.

The Simplest Path to Compliance
If GDPR analytics compliance feels overwhelming, here's the minimal path:

Switch to a cookieless, privacy-first analytics tool. This eliminates the consent banner requirement, the cookie management complexity, and most data protection concerns.

Add a section to your privacy policy. Mention what analytics tool you use, what data it collects, your legal basis, and where data is stored. This takes 15 minutes.

Sign the provider's DPA. Download it, sign it, keep it on file. Five minutes.

Set a data retention period. Most privacy-first tools handle this automatically.

That's genuinely it. Four steps, under an hour, and you can stop worrying about analytics compliance.

What About the ePrivacy Regulation?
The ePrivacy Directive is being replaced by the ePrivacy Regulation, which has been in draft since 2017. It keeps getting delayed. When it eventually passes, it will likely:

Maintain the consent requirement for tracking cookies
Potentially create a clearer exemption for audience measurement
Apply directly as a regulation (like GDPR) instead of requiring national implementation
For now, follow the current ePrivacy Directive rules. If you're using cookieless analytics, the regulation change is unlikely to affect you negatively — if anything, it may make things easier by standardizing the audience measurement exemption across all EU member states.

Bottom Line
GDPR analytics compliance is not as complicated as the legal industry makes it seem. The complexity comes from using tools that weren't designed with privacy in mind. If your analytics tool collects personal data, sets cookies, and transfers data internationally, you need consent banners, DPAs, transfer impact assessments, and detailed privacy notices.

If your analytics tool collects no personal data, uses no cookies, and stores data in the EU — compliance is a privacy policy paragraph and a signed DPA.

Fairlytics is built for this second scenario. A 510-byte script, no cookies, no personal data, EU-hosted, with a free tier for sites under 10K monthly views. You can be fully GDPR-compliant in 30 seconds.

EU AI Act Compliance Checklist for 2026: What You Need to Have Ready

Guillermo Llopis — Mon, 16 Mar 2026 09:07:10 +0000

The August 2, 2026 deadline is less than five months away. On that date, the full requirements for high-risk AI systems under the EU AI Act become enforceable — with fines up to €15 million or 3% of global turnover for non-compliance.

This checklist covers every obligation that providers of high-risk AI systems must meet. Use it to audit where you stand and identify what still needs work.

Step 1: Determine if the AI Act applies to you
Before working through the technical requirements, confirm your obligations.

[ ] Classify your AI system. Is it high-risk under Annex III? High-risk domains include biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and administration of justice.
[ ] Determine your role. Are you a provider (you developed the system or had it developed and placed it on the market under your name) or a deployer (you use the system under your authority)?
[ ] Check territorial scope. The AI Act applies to providers placing systems on the EU market and deployers located in the EU — but also to providers and deployers outside the EU if the output of their system is used in the EU. If you are unsure, this post explains the extraterritorial reach.
[ ] Verify the system is not exempt. Systems used exclusively for military, defence, or national security purposes are excluded. Systems used purely for scientific research and development are also exempt. Most commercial AI systems are not.
Step 2: Risk management system (Article 9)
Article 9 requires a documented risk management system that runs throughout the AI system's entire lifecycle — not a one-time assessment.

[ ] Identify and analyse known and reasonably foreseeable risks that the AI system can pose to health, safety, or fundamental rights.
[ ] Estimate and evaluate risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse.
[ ] Adopt risk management measures to eliminate or reduce identified risks. Where risks cannot be eliminated, implement mitigation measures (technical safeguards, human oversight, user information).
[ ] Test the system to identify the most appropriate risk management measures. Testing must be suitable to the intended purpose and must use independently collected test datasets where appropriate.
[ ] Document the risk management process including decisions made, risks identified, measures adopted, and residual risks accepted with justification.
[ ] Plan for continuous monitoring and updating of the risk management system throughout the system's lifecycle, not just at deployment.
Step 3: Data governance (Article 10)
Training, validation, and testing datasets must meet specific quality standards.

[ ] Document your data governance practices including design choices, data collection processes, and preparation operations (annotation, labelling, cleaning, enrichment).
[ ] Ensure datasets are relevant, sufficiently representative, and as free of errors as possible in view of the intended purpose of the system.
[ ] Assess data for possible biases that could lead to discriminatory outcomes, particularly regarding the groups of persons on whom the system is intended to be used.
[ ] Identify and address data gaps or shortcomings and document how these are mitigated.
[ ] Consider the statistical properties of the data, including where applicable the persons or groups of persons on whom the system is intended to be used.
[ ] Where special categories of personal data are processed (Article 10(5)), ensure this is strictly necessary for bias detection and correction, with appropriate safeguards.
Step 4: Technical documentation (Article 11 / Annex IV)
Detailed technical documentation must be drawn up before the system is placed on the market and kept up to date.

[ ] General description of the AI system: intended purpose, developers, version, how the system interacts with hardware and software, applicable regulations.
[ ] Detailed description of system elements and development process: methods and steps taken for development, design specifications, system architecture, computational resources, data processing, training methodologies, key design choices and rationale.
[ ] Monitoring, functioning, and control mechanisms: capabilities and limitations, degrees of accuracy for specific persons or groups, foreseeable unintended outcomes, human oversight measures, technical specifications for input data.
[ ] Risk management documentation: full description of the risk management system implemented per Article 9.
[ ] Description of changes throughout the lifecycle: if the system has been modified, what changed and why.
[ ] Performance metrics and test results: accuracy, robustness, and cybersecurity benchmarks, test logs, validation results.
[ ] Description of the quality management system in place.
This is typically the most time-consuming item on this checklist. Annexa can generate a first draft of your Annex IV technical documentation by analysing your actual codebase — giving you a starting point instead of a blank page.

Step 5: Record-keeping and logging (Article 12)
High-risk AI systems must be designed to automatically log events during operation.

[ ] Enable automatic logging of events relevant for identifying risks at the national level and substantial modifications throughout the system's lifecycle.
[ ] Logs must record at minimum: the period of each use, the reference database against which input data was checked, input data that led to a match, and the identification of natural persons involved in the verification of results.
[ ] Ensure logs are proportionate to the intended purpose of the system and comply with data protection law.
[ ] Retain logs for a period appropriate to the intended purpose, and at least six months unless otherwise provided by applicable law.
Step 6: Transparency and information to deployers (Article 13)
The system must come with clear documentation for deployers (the organisations that use it).

[ ] Provide instructions for use that include the provider's identity and contact details, the system's capabilities and limitations, intended purpose, and level of accuracy.
[ ] Describe known or foreseeable circumstances under which the system may create risks to health, safety, or fundamental rights.
[ ] Specify the performance metrics of the system, including the metrics for specific groups of persons on whom the system is intended to be used.
[ ] Describe human oversight measures and how to effectively implement them.
[ ] Specify the expected lifetime of the system and any necessary maintenance and care measures.
Step 7: Human oversight (Article 14)
The system must be designed to allow effective human oversight during the period it is in use.

[ ] Enable human oversight through appropriate human-machine interface tools identified by the provider before the system is placed on the market.
[ ] Ensure the human overseer can fully understand the system's capacities and limitations, correctly interpret output, decide not to use the system or disregard its output, and intervene or interrupt the system.
[ ] For high-risk systems that identify or affect persons: ensure at least two independent natural persons verify the system's output before action is taken based on that output (unless justified by specific circumstances).
Step 8: Accuracy, robustness, and cybersecurity (Article 15)
[ ] Declare and document the accuracy levels of the system, including the metrics used to measure them.
[ ] Ensure resilience against errors, faults, or inconsistencies that may occur in the system's environment or among other systems with which it interacts.
[ ] Implement technical redundancy solutions where appropriate (backup plans, fail-safes).
[ ] Protect against adversarial attacks relevant to the system, including data poisoning, model manipulation, and adversarial inputs (prompt injection, evasion attacks).
[ ] Implement cybersecurity measures appropriate to the risks, including protection against unauthorised access, model extraction, and data leakage.
Step 9: Quality management system (Article 17)
Providers must implement a documented quality management system.

[ ] Document a compliance strategy including an assessment of applicable regulatory requirements.
[ ] Establish processes for design, design control, development, quality control, and quality assurance.
[ ] Define examination, test, and validation procedures to be carried out before, during, and after development.
[ ] Specify technical standards applied, and where harmonised standards are not applied in full, explain the means used to meet the requirements.
[ ] Establish systems for data management including data collection, analysis, labelling, storage, filtration, mining, aggregation, retention, and any other data operation.
[ ] Implement a post-market monitoring system in accordance with Article 72.
[ ] Define procedures for incident reporting and communication with national competent authorities.
[ ] Document resource management including supply-chain and third-party component management.
[ ] Establish an accountability framework including management and other personnel responsibilities.
Step 10: Conformity assessment and market placement
Before placing the system on the EU market, complete the administrative requirements.

[ ] Conduct the conformity assessment (Article 43). Most high-risk systems under Annex III can use the internal control procedure (Annex VI). Certain biometric systems require third-party assessment by a notified body.
[ ] Draw up the EU declaration of conformity (Article 47) — a formal statement that the system meets all requirements.
[ ] Affix the CE marking (Article 48) — indicating conformity with the AI Act.
[ ] Register the system in the EU database for high-risk AI systems (Article 49) — this must happen before the system is placed on the market.
[ ] Designate an authorised representative in the EU if you are established outside the Union (Article 22).
Timeline: what to prioritise
With less than five months until August 2, 2026:

Do now (March-April 2026):

Classify all your AI systems — know which are high-risk
Start technical documentation (Annex IV) — this takes the longest
Begin your risk management system documentation
Audit your training data governance
Do next (May-June 2026):

Complete the quality management system
Implement logging and record-keeping
Prepare instructions for deployers
Validate human oversight mechanisms
Finalise (July 2026):

Conduct the conformity assessment
Prepare the EU declaration of conformity
Register in the EU database
Affix CE marking
The companies that start now will have time to iterate. The ones that wait until July will be scrambling — and the documentation will show it.

Get started
The longest item on this checklist is technical documentation. If you want to compress weeks of work into hours, Annexa's free risk triage classifies your system in minutes, and the Pro tier generates a full Annex IV dossier from your actual codebase for €49/month.

Whether you use a tool or do it manually, the important thing is to start. August is closer than it looks.

Honest question: is self-hosted analytics still worth the maintenance in 2026?

Guillermo Llopis — Thu, 12 Mar 2026 11:58:41 +0000

I've been self-hosting Matomo for about a year and I'm starting to wonder if the maintenance overhead is worth it for my use case.

Between PHP updates, database optimization, security patches, and the occasional report processing freeze, I'm spending 1-2 hours a month just keeping it running. And that's for a handful of small sites that get maybe 50K pageviews combined.

The thing that surprised me most: out of the box, Matomo uses first-party cookies with a 13-month lifetime and processes IP addresses. You have to explicitly configure cookieless tracking. So the "more private because self-hosted" argument doesn't hold unless you actually change the dfaults.

For anyone else who's been through this: did you stick with self-hosted or switch to a cloud tool? I've been looking at Plausible (which also has a self-hosted community edition), Umami, and some of the lighter SaaS options like Fathom and Fairlytics.

Curious what the trade-off looks like for others. The appeal of self-hosting is real, but so is the time cost.

Tips for r/selfhosted: This sub values honest discussion, not promotion. The post frames it as a genuine question. Don't link to fairlytics.dev in the post, only mention it if someone asks directly in the comments.

Month 1 building an AI compliance SaaS — here's what happened

Guillermo Llopis — Thu, 12 Mar 2026 10:50:26 +0000

I've been building Annexa, a tool that helps AI companies comply with the EU AI Act, for about a month now. Figured I'd share some honest numbers and lessons since this sub appreciates transparency.

The problem: The EU AI Act requires companies deploying high-risk AI systems to produce detailed technical documentation (called "Annex IV") by August 2, 2026. Fines go up to €35M or 7% of global revenue. Most companies I've talked to have no idea where to start.

What I built: A tool that classifies your AI system's risk level (free, no signup), then generates the compliance documentation by analyzing your actual codebase, Python files, YAML configs, JSON schemas. The Pro tier is €49/month.

Stack: Streamlit frontend, Groq (Llama 3.3 70B) for the AI layer, Supabase for auth/storage, Stripe for payments. The core package has zero Streamlit dependencies so the business logic is framework-independent.

What's working:

The free risk triage gets people in the door — zero friction
SEO is starting to pick up. 6 blog posts targeting "eu ai act" long-tail keywords
The August 2026 deadline creates real urgency — people are searching for solutions NOW

What I'd do differently:

Should have started content marketing earlier. SEO takes months to compound
Underestimated how much time compliance research takes vs actual coding
The €49/month price point feels right for SMEs but I'm still validating

Biggest lesson: In compliance SaaS, trust is everything. I added [LEGAL REVIEW REQUIRED] markers throughout generated documents to be transparent about what the tool is and isn't. Counterintuitively, this honesty seems to increase trust rather than reduce conversions.

Happy to answer questions about the EU AI Act, compliance tooling, or the technical architecture.

Link: https://annexa.eu

EU AI Act compliance for ML engineers — what Annex IV means for your training pipeline

Guillermo Llopis — Mon, 09 Mar 2026 11:06:40 +0000

If you're training or deploying ML models that touch EU users, the EU AI Act's August 2026 deadline is getting close. I've been digging into the Annex IV technical documentation requirements and wanted to share what's actually relevant for ML engineers (vs. the legal jargon). What Annex IV requires you to document about your ML system:

Training data provenance: where your datasets came from, how they were collected, preprocessing steps, labeling methodology. Not just "we used CommonCrawl."
Model architecture and design choices: why you chose your approach, what alternatives you considered, and how the architecture relates to the intended purpose.
Validation and testing: metrics used, test datasets, performance across subgroups (bias testing), and the statistical methodology behind your evaluation.
Risk management: what can go wrong, what you did to mitigate it, and residual risks you've accepted.
Data governance: Article 10 requires documenting data relevance, representativeness, absence of errors, and completeness. If you've ever shipped a model with "good enough" data, this is the part that'll sting.
Post-market monitoring: how you'll track performance drift, feedback loops, and incidents after deployment. The kicker: this applies to non-EU companies too if your model's output is used in the EU (Article 2). The threshold is lower than GDPR, it doesn't require you to be "targeting" EU users, just that the output ends up being used there. The full breakdown of what counts as high-risk is in Annex III, hiring tools, credit scoring, biometrics, medical devices, and safety components all qualify. If your model doesn't fall into these categories, you're likely fine with minimal obligations.

For those who want to go deeper, I wrote a detailed breakdown of the extraterritorial scope here: https://annexa.eu/blog/eu-ai-act-extraterritorial/

Has anyone here started working on Annex IV documentation for their models? Curious what approaches people are taking, especially around documenting training data provenance for large-scale datasets.

EU AI Act vs GDPR: What's Different and What Overlaps

Guillermo Llopis — Thu, 05 Mar 2026 08:38:34 +0000

If your company is already GDPR-compliant, you might assume the EU AI Act is more of the same. It is not. While both regulations share some DNA — risk-based thinking, documentation requirements, transparency obligations — they are fundamentally different laws with different goals, different scopes, and different compliance mechanisms.

Understanding where they overlap and where they diverge is critical for avoiding both compliance gaps and duplicated effort.

Different laws, different purposes
The GDPR is a fundamental rights law focused on protecting individuals' personal data. It governs how data is collected, processed, stored, and shared, regardless of what technology is involved.

The EU AI Act is a product safety law focused on ensuring AI systems are safe, transparent, and respect fundamental rights. It regulates how AI systems are designed, developed, validated, and deployed — based on risk category, not data type.

This distinction matters in practice: the AI Act applies even when no personal data is processed. An AI system that analyzes satellite imagery for infrastructure planning, or that optimizes industrial processes using only machine-generated sensor data, still falls under the AI Act if it meets the definition of an AI system. The GDPR would not apply in those scenarios.

Conversely, processing personal data with simple rule-based software (no AI involved) triggers GDPR obligations but not the AI Act.

Where they genuinely overlap
Despite their different focuses, there are real areas of intersection — especially when AI systems process personal data, which most do.

Transparency
Both regulations require transparency, but about different things:

GDPR (Articles 13-14): You must tell individuals that their data is being processed, what data, why, how long, and their rights regarding it.
AI Act (Article 13): You must ensure the AI system itself is designed to be sufficiently transparent for deployers to understand and use it appropriately — including its capabilities, limitations, accuracy levels, and foreseeable misuse scenarios.
If your AI system processes personal data, you need to satisfy both. A privacy notice alone does not meet AI Act transparency requirements, and an AI system transparency sheet does not replace your GDPR obligations.

Risk assessments
This is where duplication becomes a real operational concern:

GDPR requires a Data Protection Impact Assessment (DPIA) under Article 35 when processing is likely to result in high risk to individuals' rights and freedoms.
AI Act requires a Fundamental Rights Impact Assessment (FRIA) under Article 27 for deployers of high-risk AI systems used in certain domains (credit scoring, insurance pricing, law enforcement, migration management, and others).
These two assessments have different scopes, different supervisory authorities, and different procedural requirements. But in practice, most high-risk AI systems that trigger a FRIA will also trigger a DPIA — because they typically process personal data in ways that affect people's rights.

The practical approach: conduct the DPIA first, using the information the AI provider must give you under Article 13 of the AI Act. Then build on it for the FRIA. Do not treat them as entirely separate exercises.

Automated decision-making
GDPR Article 22 gives individuals the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. This includes profiling.

The AI Act addresses a similar concern but from the product side. High-risk AI systems must include human oversight measures (Article 14) — technical features that enable humans to understand, supervise, and intervene in the system's operation. Several categories of AI systems in Annex III explicitly target automated decision-making scenarios: credit scoring, hiring, insurance, and benefits administration.

If your AI system makes or significantly influences decisions about people, you likely need to address both Article 22 GDPR and the AI Act's human oversight requirements. They are not the same obligation, but the engineering solutions often overlap: providing explanations, enabling human review, allowing contestation.

Data governance
GDPR has comprehensive requirements for lawful processing, purpose limitation, data minimization, accuracy, and storage limitation.

The AI Act adds AI-specific data governance requirements in Article 10 for high-risk systems, covering training, validation, and testing datasets. These include requirements for data relevance, representativeness, absence of errors, completeness, and statistical properties. Article 10 also allows processing of special categories of personal data (health, ethnicity, biometrics) for bias detection and correction purposes — something that GDPR alone would generally prohibit.

This is one area where the AI Act explicitly overrides the GDPR's defaults, creating a legal basis for processing sensitive data that is necessary to ensure AI systems do not discriminate.

What GDPR compliance does NOT cover
If you have been through GDPR compliance, you have a head start. But several AI Act requirements have no GDPR equivalent:

AI Act Requirement GDPR Equivalent
Risk classification (prohibited, high, limited, minimal) None — GDPR does not classify systems by risk tier
Annex IV technical documentation None — GDPR records of processing are far less detailed
Conformity assessment (self-assessment or notified body) None
CE marking for high-risk AI systems None
EU database registration (Article 71) DPA registration is mostly gone post-GDPR
Post-market monitoring system (Article 72) None — GDPR does not require ongoing product monitoring
Accuracy, robustness, and cybersecurity requirements (Articles 15) Security measures exist but are far less prescriptive
Quality management system (Article 17) None at this level of specificity
The most significant gap is Annex IV technical documentation. GDPR's records of processing activities (Article 30) cover data flows and purposes. Annex IV demands detailed documentation of your system's architecture, training data provenance, development methodology, testing procedures, risk management system, and post-market monitoring plan. It is an order of magnitude more comprehensive.

What you can reuse from GDPR
Not everything is new ground. GDPR compliance gives you:

Data mapping and inventories. You already know what personal data you process and where it flows. This feeds directly into Annex IV Section 2 (data requirements).

Lawful basis analysis. You have already determined your legal basis for processing. This groundwork helps with AI Act Article 10 data governance requirements.

DPIA methodology. Your DPIA process, templates, and governance structures can be extended for AI Act FRIAs rather than building from scratch.

DPO and governance structures. The organizational muscles you built for GDPR — designated officers, compliance processes, training programs — are directly applicable.

Individual rights mechanisms. Your processes for handling data subject requests can inform the human oversight and contestation mechanisms the AI Act requires.

Vendor management. GDPR Article 28 controller-processor agreements have parallels in AI Act provider-deployer obligations. Your vendor assessment processes can be adapted.

The Digital Omnibus complication
The European Commission's Digital Omnibus proposal (November 2025) aims to reduce regulatory overlap between the AI Act, GDPR, and other digital regulations. Among its proposed changes:

Clarifying the interaction between AI Act FRIAs and GDPR DPIAs to reduce duplication
Streamlining conformity assessment procedures
Extending simplified documentation requirements to all SMEs (not just microenterprises)
The Omnibus is still working through the legislative process. Until it is adopted, organizations must comply with both regulations as written — which means some duplication is unavoidable.

What to do now
Map your AI systems against both frameworks. For each AI system, identify which GDPR obligations apply (does it process personal data?) and which AI Act obligations apply (what is its risk classification?). The overlap set is where you need integrated compliance.

Integrate your impact assessments. Do not run DPIAs and FRIAs as separate projects. Start with the DPIA, extend it to cover fundamental rights beyond data protection, and you have a solid foundation for both.

Extend your documentation. GDPR Article 30 records are a starting point, not a finish line. For high-risk AI systems, you need full Annex IV technical documentation — and it requires significantly more technical detail than anything GDPR demands.

Classify your AI systems. The first step is knowing whether your AI systems are high-risk under the AI Act. Annexa's free risk triage can classify your system in minutes, with no signup required — giving you clarity on which obligations apply before you invest in compliance effort.

Do not assume GDPR compliance is enough. It is a foundation, not a substitute. The AI Act introduces product-safety obligations that have no precedent in data protection law.

The August 2026 deadline is five months away. Companies that treat AI Act compliance as a GDPR extension will find gaps. Companies that start from scratch will waste effort. The right approach is somewhere in between — build on what you have, but recognize what is genuinely new.

Simple Analytics vs Plausible — Which Is Better for Small Sites?

Guillermo Llopis — Thu, 05 Mar 2026 08:21:54 +0000

Simple Analytics vs Plausible — Which Is Better for Small Sites?
You've decided to ditch Google Analytics. Good call. Now you're probably looking at Plausible and Simple Analytics — two of the most popular privacy-first alternatives. They look similar on the surface, but there are real differences that matter when you're running a small site on a budget.

Here's an honest comparison to help you pick.

The Quick Overview
Simple Analytics Plausible
Cheapest plan $15/mo (1 user, 10 sites) $9/mo (1 site)
Free tier 14-day trial only 30-day trial only
Script size ~3 KB ~1 KB
Cookies None None
Open source Partially (script is public) Yes (AGPL)
Self-hosting No Yes
EU-hosted Yes (Netherlands) Yes (Germany)
GDPR compliant Yes, no consent needed Yes, no consent needed
Both tools are cookieless, lightweight, and designed to respect visitor privacy. Neither requires a cookie consent banner. But they take different approaches to how they handle data, what they charge, and what features they include.

Privacy: How They Differ
This is where the two tools diverge most.

Simple Analytics collects no personal data at all. No IP addresses, no hashed identifiers, no device fingerprinting. It literally cannot track individual visitors across pages or sessions. All data is aggregated from the start.

Plausible uses a daily-rotating hash of the visitor's IP address combined with the User-Agent string and a random salt. This creates a temporary identifier that lets Plausible count unique visitors and track sessions within a single day. The hash is never stored — it exists only in memory during processing — and the salt rotates every 24 hours, so the same visitor gets a different identifier the next day.

Both approaches are GDPR-compliant without requiring consent. But if your priority is absolute zero personal data processing, Simple Analytics is stricter. If you want slightly more accurate unique visitor counts and session data, Plausible's approach gives you that.

Pricing: Plausible Is Cheaper to Start
For small sites, pricing matters. Here's how they compare:

Plausible:

Starter: $9/mo for 10K pageviews, 1 site
Growth: $14/mo for 10K pageviews, 3 sites, team members
Business: ~$19/mo for 10K pageviews, 10 sites, funnels, custom properties
Simple Analytics:

Simple: $15/mo for 100K datapoints, 10 sites, 1 user
Team: $40/mo for 100K datapoints, 20 sites, 2 users
At first glance, Plausible looks cheaper at $9/mo. But that's for a single site with only 10K pageviews. If you run multiple small sites — a portfolio, a side project, a client site — you're already at $14/mo.

Simple Analytics starts higher at $15/mo, but you get 10 sites and 100K datapoints right away. If you're a freelancer managing several small projects, Simple Analytics could actually be the better deal.

Neither tool has a permanent free tier — both offer trials only.

Features: What You Actually Get
Dashboard and reporting: Both have clean, single-page dashboards that show you what matters — visitors, pageviews, referrers, top pages, countries, devices, and browsers. If you've used Google Analytics, the simplicity of either tool will feel like a relief.

Goals and events: Both support custom event tracking and goals. Plausible's funnel feature (on the Business plan) lets you see where visitors drop off in a multi-step process. Simple Analytics has automated event collection that can track outbound link clicks and downloads without extra code.

Google Search Console integration: Plausible integrates with Google Search Console to show you which search queries bring visitors to your site — directly in your analytics dashboard. Simple Analytics doesn't have this.

API access: Both offer APIs, though Simple Analytics gates it behind the Team plan ($40/mo). Plausible includes API access on all plans.

Data export: Both let you export your data. Simple Analytics makes this a prominent feature, emphasizing that your data belongs to you.

Email reports: Both can send you weekly or monthly traffic reports by email.

Self-Hosting
Plausible is open source (AGPL license) and can be self-hosted for free. If you have a VPS and are comfortable with Docker, you can run Plausible with no pageview limits and no monthly fees. The community edition gets regular updates.

Simple Analytics cannot be self-hosted. It's cloud-only.

If self-hosting matters to you — for cost savings, data sovereignty, or principle — Plausible wins this category outright.

Script Size and Performance
Both scripts are dramatically smaller than Google Analytics (~22 KB), but there's a difference:

Plausible: ~1 KB
Simple Analytics: ~3 KB
For most sites, both are fast enough that you'll never notice the difference. But if you're obsessively optimizing every byte — and if you're reading a comparison like this, you might be — Plausible is lighter.

For context, there are even smaller options. Fairlytics, for example, ships a 510-byte script, making it the lightest privacy-first analytics tool available. It also has a free tier for sites under 10K pageviews/month.

Who Should Pick Which?
Choose Plausible if:

You want the cheapest entry point ($9/mo for one site)
Google Search Console integration matters to you
You want the option to self-host later
You're comfortable with IP-hash-based unique visitor counting
You want funnels (on the Business plan)
Choose Simple Analytics if:

You want absolute zero personal data processing
You run multiple sites and want them all on one plan
You need automated event collection out of the box
You prefer a company that doesn't process IP addresses at all
You don't need self-hosting
Consider a third option if:

You need a free tier (neither Plausible nor Simple Analytics offers one)
You want the smallest possible script
You're on a tight budget and $9-15/mo is too much for a side project
The Bottom Line
Both Plausible and Simple Analytics are solid, privacy-respecting tools. You won't go wrong with either one. The real question is what you prioritize: Plausible gives you more features per dollar and the flexibility of self-hosting. Simple Analytics gives you stricter privacy guarantees and multi-site simplicity.

For a solo developer running one small site, Plausible at $9/mo is hard to beat. For a freelancer managing multiple client sites who wants the strictest possible privacy stance, Simple Analytics at $15/mo makes sense.

And if you're looking for something with a free tier, a sub-1KB script, and no IP processing at all, Fairlytics might be worth a look.

EU AI Act Annex IV: What Technical Documentation You Actually Need

Guillermo Llopis — Tue, 24 Feb 2026 14:17:23 +0000

If your AI system is classified as high-risk, Article 11 of the EU AI Act requires you to prepare technical documentation meeting the requirements of Annex IV — before you place the system on the market or put it into service. This documentation must be kept up to date throughout the system's lifecycle.

Annex IV is not a suggestion. It is the backbone of the conformity assessment. Whether you self-assess under Annex VI or go through a notified body, this is the document package that proves your system complies. National market surveillance authorities can request it at any time, and they have the power to access your documentation, datasets, and source code.

Here is what Annex IV actually requires, section by section.

The nine sections of Annex IV

1. General description of the AI system

This is your executive summary. It covers:

The system's intended purpose and provider identity
How the system interacts with external hardware or software
Software and firmware version numbers and update requirements
Distribution format — whether it is embedded in hardware, delivered as a downloadable package, accessed via API, or deployed as a service
Hardware requirements for the system to run
The user interface provided to deployers
Instructions for use for the deployer

If your AI system is a component of a larger product, include photographs or illustrations showing external features, markings, and internal layout.

This section is straightforward but often underestimated. The instructions for use must be detailed enough for deployers to fulfill their own obligations under Article 26 — including understanding the system's capabilities, limitations, and human oversight requirements.

2. Development process and methodology

This is the most detailed and technically demanding section. It covers:

Design specifications — the general logic of the system and its algorithms, key design choices with their rationale, what the system is designed to optimize for, the relevance of different parameters, classification choices, expected output format, and output quality expectations.

System architecture — how software components build on or feed into each other and integrate into the overall processing pipeline.

Computational resources — what hardware and compute was used for development, training, testing, and validation.

Data requirements — this is where most companies struggle. You must document:

Training methodologies and techniques used
Training datasets including their provenance, scope, and main characteristics
How data was obtained and selected
Labelling procedures (who labelled, what guidelines, what quality controls)
Data cleaning methodologies applied

Human oversight measures — the technical measures put in place to help deployers interpret the system's outputs, in accordance with Article 14.

Pre-determined changes — any changes to the system and its performance that were planned or anticipated at the time of the initial conformity assessment.

Validation and testing — the procedures used, the validation and test datasets and their characteristics, the metrics used to measure accuracy, robustness, compliance, and potentially discriminatory impacts. All test logs and reports must be dated and signed by the responsible persons.

Cybersecurity measures — what protections are in place against adversarial attacks, data poisoning, model extraction, and other AI-specific threats.

3. Monitoring, functioning, and control

This section addresses system behavior in production:

Performance capabilities and limitations — including degrees of accuracy for specific persons or groups the system is intended to be used on, and overall expected accuracy relative to intended purpose
Foreseeable unintended outcomes — sources of risk to health, safety, fundamental rights, and potential for discrimination
Human oversight specifications — the technical measures enabling human operators to understand and intervene in the system's operation
Input data specifications — what data the system expects and in what format

The emphasis on accuracy broken down by demographic groups is intentional. If your system performs differently across populations (which most do), you must document this explicitly.

4. Performance metrics justification

A short but important section: you must explain why the performance metrics you chose are appropriate for this specific AI system and its intended purpose.

This is not just about reporting accuracy. If you use F1 scores, AUC-ROC, precision-recall trade-offs, or domain-specific metrics, explain why those metrics meaningfully capture the system's real-world performance and compliance with the Act's requirements.

5. Risk management system

A detailed description of the risk management system established under Article 9. This is not a standalone risk register — it must document:

How risks were identified and analyzed throughout the lifecycle
Risk estimation and evaluation methods
Risk mitigation measures and their effectiveness
Residual risks and whether they are acceptable
How the risk management system integrates with the overall development process

Article 9 requires that the risk management system be a continuous iterative process planned and run throughout the entire lifecycle. Your documentation must reflect this — not just a point-in-time assessment.

6. Lifecycle changes

A record of all relevant changes made to the system throughout its lifecycle. This includes changes to:

Training data or data processing
Model architecture or parameters
System behavior or performance characteristics
Intended purpose or deployment context

This section turns Annex IV from a one-time deliverable into a living document. You need a process for maintaining change records, not just a document you write once and file away.

7. Applied harmonised standards

Here you must list the harmonised standards you applied, referencing their publication in the Official Journal of the EU.

The current problem: as of February 2026, no harmonised standards have been formally cited in the Official Journal. Seven primary standards are in development under CEN-CENELEC JTC 21, but none provide a presumption of conformity yet. The most advanced is prEN 18286 (Quality Management Systems for AI Act compliance), which entered public enquiry in October 2025. Full delivery of harmonised standards is targeted for Q4 2026 — after the August deadline.

Where no harmonised standards have been applied (which is everyone, right now), you must provide detailed descriptions of the alternative solutions you adopted to meet each requirement, plus a list of other relevant standards and technical specifications you followed.

In practice, this means referencing standards like ISO/IEC 42001 (AI Management Systems), ISO/IEC 23894 (AI Risk Management), or the AESIA guidance documents — while acknowledging these do not provide formal presumption of conformity under the AI Act.

8. EU Declaration of Conformity

A copy of the declaration of conformity issued under Article 47. This is a formal document where the provider declares that the AI system meets all applicable requirements of the regulation.

9. Post-market monitoring system

A detailed description of how you will evaluate the system's performance after deployment, including the post-market monitoring plan required by Article 72(3). This covers:

How you will collect and analyze data on the system's real-world performance
What metrics you will track post-deployment
How you will detect and respond to performance degradation
Your incident reporting procedures
How post-market findings feed back into the risk management system

Where standards stand today

The standards situation creates real uncertainty for companies preparing documentation now.

CEN-CENELEC JTC 21 is developing seven primary harmonised standards covering risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity, bias management, and quality management systems. These were originally expected by late 2025 but are now targeted for Q4 2026. In October 2025, CEN-CENELEC adopted exceptional acceleration measures — allowing standards to skip the formal vote stage after a positive enquiry vote — to speed delivery.

prEN 18286 is the most mature standard. Its Annex ZA directly maps QMS requirements to Articles 11, 17, and 72 of the AI Act, making it the closest thing to a practical blueprint for Annex IV compliance.

ISO/IEC 42001, while internationally recognized, is not part of the EU harmonisation process. The EU AI Office indicated in 2024 that it does not fully align with the final AI Act text. The JRC found it provides limited coverage of logging and recordkeeping. It is complementary, not sufficient.

The practical implication: you cannot rely on any single standard for presumption of conformity today. You must document your own approach to meeting each requirement and be prepared to explain it to regulators.

The Digital Omnibus factor

The Digital Omnibus proposal (November 2025) could push the high-risk compliance deadline to December 2, 2027 for Annex III systems, contingent on harmonised standards not being ready. It would also extend simplified documentation requirements from microenterprises to all SMEs and introduce proportionate expectations for small mid-cap companies.

But the Omnibus is still a proposal. It must pass through Parliament and Council. And even if adopted, companies would still need to demonstrate "good faith" compliance effort. Documentation requirements under Annex IV do not change — only when they must be ready.

Best available guidance: AESIA

Spain's AI supervisory agency (AESIA) published 16 practical guidance documents in December 2025, developed through its AI regulatory sandbox where 12 real AI systems were tested across six sectors.

Guide 15 is a 62-page document focused specifically on technical documentation. It covers required content, preferred format, and best practices for structuring and storing Annex IV documentation. These are the most detailed publicly available compliance resources for Annex IV, developed by the EU's first operational national AI supervisory body.

The guides are non-binding and described as "living resources," but they offer the closest thing to a practical reference for Annex IV preparation. You can access them at aesia.digital.gob.es.

Common mistakes

Treating it as a one-time document. Sections 5, 6, and 9 explicitly require ongoing maintenance. If your documentation is a static PDF from six months ago, it is already non-compliant.
Generating documents without evidence. Regulators look for verifiable artifacts — actual test results that influenced design decisions, genuine risk assessments, real audit logs. Assertions without evidence will not pass conformity assessment.
Ignoring data provenance. Section 2 requires detailed documentation of training data origin, selection criteria, labelling procedures, and cleaning methods. This is nearly impossible to reconstruct after the fact if you did not track it during development.
Skipping the metrics justification. Section 4 is short but important. "We used accuracy" is not a justification. You need to explain why your chosen metrics meaningfully capture real-world performance for your specific use case.
Waiting for harmonised standards. The standards are late. The deadline may or may not move. Starting now with the available guidance (AESIA, ISO frameworks, the regulation text itself) is far better than waiting for perfect clarity.

What to do now

Audit what you already have. Most teams have scattered fragments of Annex IV documentation across design docs, Jupyter notebooks, model cards, and internal wikis. Inventory what exists and identify gaps systematically.
Start with the hardest sections. Sections 2 (development process) and 5 (risk management) are the most demanding and the most likely to have gaps. Start there while institutional knowledge is still fresh.
Implement documentation processes. Annex IV compliance is not a document — it is a process. Set up version-controlled documentation, data lineage tracking, and change logs now. Every week you delay makes retrospective documentation harder.
Use the AESIA guides as a reference. Spain's 16 practical guidance documents are the most detailed publicly available resource. Guide 15 on technical documentation is a practical starting point.
Generate a first draft. Annexa can analyze your codebase (Python, YAML, JSON) and generate a first-draft Annex IV dossier, identifying gaps and flagging sections that need legal review. It will not replace your engineering team's judgment, but it gives you a concrete starting point instead of a blank page.

The August 2026 deadline may or may not shift. The documentation requirements will not. Start now.

Do I Need a Cookie Consent Banner for My Website?

Guillermo Llopis — Tue, 24 Feb 2026 13:16:37 +0000

If you've ever built a website, you've probably asked yourself this question. The answer isn't a simple yes or no — it depends on what technologies your site uses, where your visitors are, and what data you collect. Here's a straightforward guide.

The short answer

You need a cookie consent banner if your website sets non-essential cookies or uses tracking technologies that store data on the visitor's device. If your site only uses strictly necessary cookies (or no cookies at all), you can skip the banner entirely.

Let's break down what that means in practice.

What the law actually says

Two main laws govern cookie consent in Europe:

The ePrivacy Directive (sometimes called the "Cookie Law") says you need consent before storing or accessing information on a user's device. This applies to cookies, localStorage, and similar technologies, regardless of whether personal data is involved.

The GDPR defines how that consent must be collected: freely given, specific, informed, and unambiguous. Pre-ticked boxes, implied consent, and "by continuing to browse you agree" banners are all invalid. The 2019 Planet49 ruling from the Court of Justice of the EU made this crystal clear — consent must be an active, affirmative choice.

In February 2025, the European Commission formally withdrew the long-awaited ePrivacy Regulation that was supposed to replace the directive, so these rules remain the law of the land. A "Digital Omnibus" proposal from November 2025 would let users set cookie preferences at the browser level rather than site-by-site, but that won't take effect before 2027 at the earliest.

When you DO need a cookie banner

You need a consent banner if your website uses any of these:

Analytics cookies — Google Analytics, Adobe Analytics, Hotjar, and similar tools that set cookies to track visitor behavior
Advertising cookies — ad networks, retargeting pixels, Google Ads conversion tracking
Social media tracking — Facebook Pixel, Twitter tracking, embedded social widgets that set cookies
Third-party cookies of any kind — chat widgets, A/B testing tools, or any embedded service that stores data on the visitor's device

The test is simple: if you disable the cookie, does a feature the user explicitly requested break? If the site Works fine without it, the cookie isn't strictly necessary and requires consent.

Google Analytics specifically

Google Analytics 4 sets first-party cookies and sends data to Google's servers in the US. Multiple European regulators, in Austria, France, Italy, Denmark, and Norway, have ruled that using Google Analytics violated the GDPR. The EU-US Data Privacy Framework (adopted July 2023) provides a legal basis for the data transfer, but that framework is currently being challenged at the CJEU and its political foundations are uncertain.

Even if the data transfer is legal, GA4 still sets cookies. That means a consent banner is required, and you can only load the tracking script after the user consents. Studies consistently show that 50-60% of visitors reject cookies when given a genuine choice — meaning your GA4 data is incomplete from day one.

When you DON'T need a cookie banner

Strictly necessary cookies

You never need consent for cookies that are essential to a service the user explicitly requested:

Session cookies for login/authentication
Shopping cart cookies on e-commerce sites
CSRF tokens for security
Load balancing cookies
The cookie consent preference cookie itself

These are exempt under the ePrivacy Directive because they serve the user's request, not the site owner's interests.

Cookie-free analytics

If your analytics tool doesn't set cookies and doesn't store data on the visitor's device, the ePrivacy Directive doesn't apply. No cookie banner needed.

Privacy-first analytics tools like Plausible, Fathom, and Fairlytics take this approach. They measure page views, referrers, and device types without setting any cookies or collecting personal data. You get the traffic insights that matter without the legal overhead.

The CNIL audience measurement exemption

France's CNIL offers a specific exemption: analytics cookies can skip consent if they're used exclusively for audience measurement and meet strict criteria — first-party only, limited to 13-month lifetime, data retained no more than 25 months, no cross-site tracking, no data sharing with third parties. CNIL updated these guidelines in July 2025 and published a self-evaluation tool.

Important caveat: Google Analytics does not qualify for this exemption, regardless of configuration, because data is processed by a third party (Google).

What about outside the EU?

United Kingdom

The UK has its own rules under PECR (Privacy and Electronic Communications Regulations), which work similarly to the EU's ePrivacy Directive. Prior consent is required for non-essential cookies. The Data (Use and Access) Act, which received Royal Assent in June 2025, increased the maximum fine to GBP 17.5 million or 4% of global turnover, a massive jump from the previous GBP 500,000 cap.

United States

There's no federal cookie consent law in the US. State privacy laws like CCPA/CPRA follow an opt-out model, not opt-in. You don't need a cookie banner per se, but if your cookies feed advertising or data-sharing systems, you need a "Do Not Sell or Share My Personal Information" link. Connecticut's CTDPA specifically targets dark patterns in cookie banners, and their AG has begun enforcement sweeps.

Brazil

Brazil's LGPD requires opt-in consent for non-essential cookies, similar to the EU approach.

Canada

PIPEDA requires consent before collecting personal information. Implied consent may be sufficient for low-risk analytics, but tracking cookies generally require express consent.

The enforcement reality

This isn't theoretical. Regulators are actively fining companies for cookie violations:

Google was fined EUR 325 million by France's CNIL in 2025 for displaying ads without consent — their third cookie-related fine, up from EUR 150 million in 2022 and EUR 100 million in 2020
SHEIN received a EUR 150 million fine from CNIL in 2025 for placing advertising cookies without consent
TikTok was fined EUR 5 million for making it harder to refuse cookies than to accept them

The pattern is clear: dark patterns (making rejection harder than acceptance) are the top enforcement target. And fines are escalating.

A 2025 study by Aarhus University found that only 15% of cookie banners actually meet minimum GDPR requirements. 43% of sites set tracking cookies without valid consent. Just because everyone has a cookie banner doesn't mean they're doing it right.

A simple decision flowchart

Does your site set any cookies? → If no, you don't need a banner.
Are all your cookies strictly necessary (login, cart, security)? → If yes, you don't need a banner.
Do you use cookie-free analytics that don't store anything on the visitor's device? → If yes, you don't need a banner for analytics.
Do you use Google Analytics, ad pixels, or other tracking cookies? → You need a banner. It must have equally prominent Accept and Reject buttons. You can only load tracking scripts after the user consents.

The simplest path: don't use cookies at all

The easiest way to avoid cookie banners is to not need one. Replace Google Analytics with a cookie-free alternative, remove ad pixels you're not actively using, and audit your site for third-party scripts that set cookies without your knowledge.

Many site owners are surprised to discover that half their cookies come from third-party scripts they added years ago and forgot about. A quick audit with your browser's developer tools (Application → Cookies) can reveal what's actually being set.

For analytics specifically, tools like Fairlytics give you page views, top pages, referrers, browsers, and countries, all in a 510-byte script that sets zero cookies. You get the data you need to make decisions without the consent management overhead.

Best Free Invoice Tracking Templates for Google Sheets (2026)

Guillermo Llopis — Wed, 18 Feb 2026 10:24:41 +0000

If you track invoices in Google Sheets, you've probably searched for a good template. There are dozens out there, but most are either too basic (just a blank table) or too complex (pivot tables you'll never use). I tested five popular free templates and compared them on what actually matters for freelancers and small businesses: ease of use, payment tracking, and whether they handle overdue invoices.

*1. Smartsheet Invoice Tracker
*
Clean layout with columns for invoice number, client, amount, date sent, and payment status. Good starting point for freelancers. Missing: overdue alerts and aging analysis.

*2. Coefficient Invoice Template
*
Comes with conditional formatting that highlights paid vs. unpaid invoices. Has a dashboard tab with summary charts. Slightly overkill if you just need a simple list, but great if you want visual reporting.

*3. Xappex/Sheetgo Template
*
Built to integrate with Sheetgo's automation tools, but works fine standalone. Well-structured columns. Best if you plan to connect multiple sheets or data sources later.

*4. FreshBooks-Style Template
*
More of an invoice generator than a tracker, it creates professional-looking invoices you can send to clients. Some people repurpose it as a tracker, but it's not designed for logging received invoices.

*5. Google Sheets Built-In Template
*
Go to File > New > From template gallery > Invoice. Zero setup, but it's barebones. You'll need to add columns for payment status, due dates, and anything beyond the basics.

*Quick Comparison
*
| Template | Payment Tracking | Overdue Alerts | Dashboard | Ease of Setup |
|----------|:---:|:---:|:---:|:---:|
| Smartsheet | Yes | No | No | Easy |
| Coefficient | Yes | Yes | Yes | Medium |
| Xappex | Yes | No | No | Easy |
| FreshBooks | No | No | No | Easy |
| Google Built-in | No | No | No | Instant |

*The Real Bottleneck
*
The template is the easy part. The hard part is actually filling it in — opening each invoice PDF, finding the invoice number, copying the amount, typing the date. That's where most of the time goes.

If you receive invoices by email, tools like AutoInv can extract the data automatically using AI and paste it into your sheet. It works with any template layout and any invoice format.

Is My AI System High-Risk? How to Classify Under the EU AI Act

Guillermo Llopis — Wed, 18 Feb 2026 09:41:33 +0000

The EU AI Act's biggest enforcement date (August 2, 2026) is now less than 6 months out. That's when full requirements for "high-risk" AI systems become enforceable, including mandatory risk management, technical documentation (Annex IV), conformity assessment, human oversight, and post-market monitoring. Fines for non-compliance: up to €15M or 3% of global revenue.
The tricky part is figuring out whether your system counts as high-risk. The Commission was supposed to publish classification guidelines by February 2, they missed that deadline. So here's a practical breakdown based on the regulation itself.
Two pathways to high-risk:

Product safety (Annex I): Your AI is a safety component of a regulated product (medical devices, machinery, vehicles). Applies from August 2027.
Standalone (Annex III): Your AI operates in one of 8 domains: biometrics, critical infrastructure, education, employment, essential services (credit scoring, insurance), law enforcement, migration/borders, or justice/democracy. Applies from August 2026. The exception most people miss: Article 6(3): Not every system touching these domains is automatically high-risk. If your AI performs a narrow procedural task (like extracting contact details from CVs without ranking candidates), improves a completed human activity, or only flags patterns for human review, it may qualify for an exception. BUT: if your system profiles individuals in any way (evaluating performance, predicting behavior, assessing personality), it's always high-risk, regardless of the exception conditions. A CV parser that extracts dates = not high-risk. A CV parser that ranks candidates = high-risk. If you claim the exception, you must document it (Article 6(4)) before placing the system on the market. No documentation = non-compliance even if the system genuinely qualifies. Conformity assessment: For most Annex III systems, you can self-assess (internal control). Third-party assessment is required only for biometric identification systems or if you haven't applied the harmonized standards. Common mistakes I see: Classifying after development instead of during design Assuming non-EU companies are exempt (the Act applies where the system is used, not where it's built) Treating classification as one-time (it must be reassessed when intended purpose changes) Underestimating what counts as "profiling" Spain's AESIA has already published 16 practical guidance documents if you want something concrete to work from while waiting for the Commission's delayed guidelines. I wrote a more detailed breakdown with examples of what is and isn't high-risk here: https://annexa.eu/blog/is-my-ai-system-high-risk/