Who has to comply with Article 25: the vendor or the company using the tool?

The controller, which is the organization that decides why and how the data is used. When you record your meetings, that's you, not your software vendor. Vendors aren't directly bound by Article 25 today, but the EDPB says controllers should only use systems with data protection built in, and should ask vendors to show how their software lets them comply. The EU AI Act draws a similar line between the vendor that builds a tool and the organization that uses it.

GDPR Article 25 for AI Note Takers: Why a DPA Is Not Enough

GDPR Article 25 asks for privacy built into the tool, not just a DPA. What privacy by design and by default mean for AI meeting assistants.

Sandeep ZachariahCEO, Zackriya Solutions

November 13, 20266 min readPrivacy & SecurityEnglish

A note from our CEO: the best data protection is data the vendor never receives. GDPR Article 25 for AI note takers: why a DPA isn't enough. Meetily runs on your device, transcribing and summarizing locally; the Meetily team is not your processor and never receives meeting content; no meeting bot joins the call; the code is open source so you can check how it works

TL;DR

GDPR Article 25 has two parts. Privacy by design (25(1)) means data protection is built into how a system works, from the start and while it runs. Privacy by default (25(2)) means the out-of-the-box settings use only the personal data each purpose needs. The duty sits with the controller, the organization using the tool, so you can only meet it with tools that were built for it.

A Data Processing Agreement (DPA) is a contract. It governs what a vendor does with your meeting data after it arrives. It doesn't stop the data reaching the vendor. Meetily, the open-source AI note taker, transcribes on your device by default, and a fresh install also writes summaries on your device, so the Meetily team never receives your audio, transcripts or summaries. Recordings, transcripts and summaries stay on your computer. If you add your own API key for summaries, the transcript text goes to the provider you chose, under your account. If you switch transcription to a cloud provider, the audio goes to that provider.

The key takeaway: a contract can promise to protect your data. Architecture can make sure the vendor never has it.

People ask us one question more than any other on European sales calls: "Is Meetily GDPR compliant?" It usually comes from a data protection officer, and what they usually mean is Article 25. I think Article 25 is one of the most misunderstood parts of the GDPR(opens in new tab), so I want to explain what it actually says, and how we built Meetily around it.

Article 25(opens in new tab), officially "data protection by design and by default", has two parts.

25(1) is privacy by design. The organization using personal data must put appropriate technical and organizational measures in place, "both at the time of the determination of the means for processing and at the time of the processing itself." In plain words: data protection has to be part of how the system is built and how it runs, not something added later through legal paperwork. The European Data Protection Board puts it in one line in its guidelines on Article 25(opens in new tab): "Effectiveness is at the heart of the concept of data protection by design."

25(2) is privacy by default. Out of the box, only the personal data needed for each specific purpose should be processed. The law names four things: how much data is collected, how far it is processed, how long it is stored, and who can access it. Users should not have to opt out of data collection. The default state must already be the private state.

To me, the law is asking a technical question: is the system designed to protect data, or is it designed to collect data and then governed by contracts?

Article 25 is addressed to the controller, the organization that decides why and how the data is used. In a meeting, that's you, not your software vendor. But you can only meet it with tools that were built for it. That's why the GDPR also says the makers of products should be encouraged(opens in new tab) to design for it, and why the EDPB tells controllers to ask vendors to show how their software lets them comply.

How cloud meeting tools answer it, and why that is weak

When a cloud meeting assistant says "we are GDPR compliant," what it usually means is this:

It has a Data Processing Agreement (DPA): a contract between the vendor and the customer that says "we promise to handle your data responsibly."
It uses Standard Contractual Clauses (SCCs): legal clauses used as the basis for sending meeting data to servers outside the European Economic Area (EEA), often in the US. Since 2020, they also need a check of the destination country's laws.
It may have an ISO 27001 certification or a SOC 2 report: independent checks of its security practices.

None of these change a single thing about where data goes. Meeting audio, transcripts, people's voices and words still travel to the vendor's cloud. Most vendors protect that data with good technical measures, like encryption. But the DPA and SCCs only govern what happens after it arrives. They are organizational measures, not technical ones.

Article 25(1) asks for appropriate technical and organizational measures, built into the processing. A DPA is a contract. It does not change how the system handles your data, and it does not keep a copy of your meetings off someone else's servers.

	Typical cloud meeting assistant	Meetily (default setup)
Where meeting audio is processed	The vendor's cloud	Your device
Where transcripts and summaries are stored	The vendor's servers	Your device
Is the vendor your processor for meeting content?	Yes, so you need a DPA	No, the Meetily team never receives it
Transfer outside the EEA by the vendor	Often, covered by SCCs or the Data Privacy Framework	None for meeting content
What you rely on	The contract and the vendor's security	The architecture, which you can check in the open source code(opens in new tab)

Meetily's default: local transcription and the on-device summary model. If you add your own API key for summaries, the transcript text goes to that provider, and that provider becomes your processor. The same applies if you switch transcription to a cloud provider: the audio goes to that provider. Sources: GDPR Article 25(opens in new tab), Article 28(opens in new tab), EDPB Guidelines 05/2021 on transfers(opens in new tab).

How Meetily is built for it, and why that is different

The Meetily team never receives your meeting data. The app doesn't send recordings, transcripts or summaries to our servers, so there is nothing of yours for us to store, read or lose.

Where your meeting data goes. With a typical cloud meeting assistant, a bot joins or an app records the call, audio is uploaded to the vendor's cloud for transcription, summaries and storage, and shared with cloud hosting and AI subprocessors, often outside the EU; the DPA and SCCs only set rules once the data is on those servers. With Meetily's default setup, recording, transcription with Parakeet or Whisper, summarizing with an on-device model and saving all happen on your device. Optionally, you can add your own API key and the transcript text goes to the AI provider you pick, under your account, which becomes your processor. The Meetily team never receives audio, transcripts or summaries, makes no transfer abroad and is not your processor for meeting content — A DPA governs what a vendor does with your data after it arrives. Architecture decides whether it arrives at all.

This maps to Article 25 directly:

Privacy by design (25(1)). Local-first was a design decision we made when we started the product. Transcription runs on your device by default, using models installed on your own machine (Parakeet or Whisper). For summaries, you choose: a model that runs on your device, or your own API key with a provider you pick. From day one, the intention was that the vendor never touches the data.
Privacy by default (25(2)). You don't have to change anything to get the private setup. The default state, install and use, already keeps meeting audio, transcripts and summaries on your device. You don't have to turn anything off. Even if you later connect a cloud AI provider, that connection runs between you and the provider. The Meetily team isn't part of it.
Data minimization (Article 5(1)(c)(opens in new tab)). We receive no meeting content, so there is nothing on our side to minimize. Your team still decides what to record and how long to keep it.
No transfer abroad by us. Articles 44 to 49(opens in new tab) govern sending personal data to countries outside the EEA, such as the US or India. Meetily sends no meeting data to us, so we make no transfer. If you choose to send transcripts to a cloud AI provider with your own API key, that is your transfer, and the usual rules apply.
A simpler controller and processor setup. With cloud tools, you are the controller and the tool is the processor. That needs a DPA and puts duties on both sides. With Meetily, Zackriya Solutions, the company behind Meetily, never becomes your processor for meeting content, because we never receive it. You stay the controller of your meeting data throughout.

Why this is a stronger position for European buyers

A DPA can be broken. A cloud provider can have a data breach. A foreign government can demand the data: under the US CLOUD Act(opens in new tab), US authorities can require US providers to hand over data in their possession, custody or control, even when it is stored in the EU. Its subprocessors, like AWS or Google Cloud, can change their terms. All of these risks exist even with a perfect DPA in place.

Meetily's position doesn't depend on any of these. It doesn't depend on trusting the Meetily team. It doesn't depend on reading a privacy policy. It doesn't depend on the strength of EU-US data transfer frameworks, which have been challenged in court three times in ten years. The EU's top court struck down Safe Harbor in 2015(opens in new tab) and Privacy Shield in 2020(opens in new tab). Their replacement, the Data Privacy Framework, survived a first challenge(opens in new tab) in September 2025, and an appeal is pending. Meetily's position depends on the architecture, which anyone can check by reading the open source code(opens in new tab).

Timeline of EU-US data transfer frameworks. Safe Harbor, adopted in 2000, was struck down by the EU Court of Justice on 6 October 2015 in Schrems I. Privacy Shield, adopted on 12 July 2016, was struck down on 16 July 2020 in Schrems II. The Data Privacy Framework, adopted on 10 July 2023, was upheld by the EU General Court on 3 September 2025 in Latombe v Commission, and an appeal is pending — Three EU-US transfer frameworks since 2000. Two were struck down; the third is in force, with an appeal pending.

This is what we mean by privacy by architecture. The guarantee is structural, not contractual.

Meetily Enterprise: raising the bar further

For organizations, we built Meetily Enterprise to take this further.

Meetily Enterprise runs entirely inside an organization's own private network or servers, including the AI processing. Fully self-hosted. Fully configurable. Monitored and managed by the organization's own IT and security teams. And critically, with no connection to us at all. Not for updates. Not for telemetry. Not even for licensing.

That means an organization running Meetily Enterprise doesn't depend on us for the data layer. There is no call home. There is no license check reaching out to our servers. Nothing leaves the organization unless its own people choose to send it. The organization controls every byte, every process and every connection.

To me, this is the gold standard for organizational privacy. Not compliance by contract. Not compliance by audit. Privacy by the simple fact that there is no outside party involved at all.

This is how we read Article 25. It isn't legal advice, and whether a setup meets the GDPR depends on how you use and configure it, so check your own setup with your data protection officer. If it helps, we're happy to walk your DPO through how Meetily handles meeting data.

Frequently Asked Questions

Article 25 of the GDPR is the rule on data protection by design and by default. Article 25(1), privacy by design, requires the controller to build appropriate technical and organizational measures into processing, both when it designs the system and while the processing runs. What counts as appropriate depends on the state of the art, the cost, the nature, scope, context and purposes of the processing, and the risks to people. Article 25(2), privacy by default, requires that by default only the personal data needed for each specific purpose is processed. That covers the amount collected, the extent of processing, the storage period and who can access the data. By default, personal data must not be made available to an indefinite number of people without the person's own action.

Privacy by design is about how a system is built: protection is part of the architecture from the start and while it runs. Privacy by default is about the starting settings: out of the box, the system uses only the data each purpose needs, and nobody has to opt out to get the private setup. For a meeting tool, design is where the audio and transcripts go. Default is what happens if you install it and change nothing.

Article 25(2) names four limits, and each one maps to a meeting tool. Amount: the tool should record only the meetings you choose, not every call on your calendar. Extent of processing: a fresh install shouldn't send recordings to a vendor for transcription, summaries or AI training. Storage period: you, not the vendor, should decide how long recordings and transcripts are kept. Access: by default, nobody outside your team should be able to open them. With Meetily's default setup, recording, transcription and summaries run on your device, so all four limits sit with you.

The idea comes from Ann Cavoukian, who later served as Information and Privacy Commissioner of Ontario, Canada. She co-wrote a 1995 report on privacy-enhancing technologies and later set out seven principles: proactive not reactive; privacy as the default setting; privacy embedded into design; full functionality; end-to-end security; visibility and transparency; and respect for user privacy. Data protection authorities adopted the framework in 2010. The GDPR made it law in Article 25, which applies from 25 May 2018. The seven principles are guidance; Article 25 is the legal duty.

The controller, which is the organization that decides why and how the data is used. When you record your meetings, that's you, not your software vendor. Vendors aren't directly bound by Article 25 today, but the EDPB guidelines on Article 25 say controllers should only use systems with data protection built in, and should ask vendors to show how their software lets them comply. The EU AI Act draws a similar line between the vendor that builds a tool and the organization that uses it.

Not on its own. A DPA is the contract Article 28 requires whenever a vendor processes personal data for you. It sets rules for what the vendor does with the data after it arrives. Article 28(1) also says you may only use vendors that give sufficient guarantees about their technical and organizational measures, so the contract is a starting point, not the proof. Article 25 asks a different question: whether the system itself is built to protect the data and to use only what each purpose needs. A DPA, SOC 2 report or ISO 27001 certificate can be part of the answer, but none of them changes where your meeting data goes.

No. Privacy by default means the private setting is the starting setting. If users have to find a switch to stop their meetings being used for training, the default is not the private one. Article 25(2) asks that, out of the box, only the data each purpose needs is processed. If you send transcripts to an AI provider, check which AI providers train on your data.

Article 25 has no fine of its own. Breaking it falls under Article 83(4): up to €10 million or 2% of the company's total worldwide annual turnover for the previous year, whichever is higher. That is the lower of the GDPR's two fine levels, and the actual amount depends on the case. Authorities can also order changes to the processing or ban it. The fine falls on the controller, the organization using the tool, because Article 25 is the controller's duty.

They are the steps an organization takes to protect personal data. Technical measures are built into systems, such as encryption, pseudonymization, access controls, or processing data on the user's own device. Organizational measures are rules and processes, such as policies, staff training and contracts like a DPA. Article 25 asks for appropriate measures of both kinds, but it doesn't prescribe specific ones. The EDPB says what matters is that they actually work.

Start with where the data goes, then read the paperwork. Check these in order: 1. Where audio is transcribed: on your device, in the EU, or elsewhere. 2. Where transcripts and summaries are stored, and whether the vendor can access them (here is how to trace it). 3. What the default settings do before anyone changes them, including whether recordings are used for AI training. 4. Whether a bot joins the call, since a bot is visible to every participant and usually means the vendor records the meeting (notes without a bot). 5. Whether data leaves the European Economic Area (EEA), under which transfer mechanism, and which subprocessors are involved. 6. Who decides how long recordings are kept. 7. Whether you can run it on your own servers if your security team needs full control. Then ask for the DPA and security reports, which still matter for the questions the architecture leaves open.

It removes the hardest questions. With cloud transcription, the vendor receives the audio, so you need a DPA, a subprocessor list, a transfer mechanism if servers are outside the EEA, and trust in the vendor's security. With on-device transcription, the audio is processed on your own computer, so there is no vendor processing and no transfer for the transcript. EU data residency is a good answer for cloud tools; on-device processing means the vendor never receives the audio to begin with (why meeting data belongs on your device). You still have your own duties as the controller, like a legal basis and telling participants.

Not for meeting content. Meetily transcribes on your device by default, and the Meetily team never receives your audio, transcripts or summaries, so we are not your processor for them. If you use your own API key for summaries, the AI provider you chose processes the transcript text, so you would need a DPA with that provider. The same goes for the audio if you switch transcription to a cloud provider. Our AI provider privacy reference lists each provider's retention terms.

It can. If you send a transcript to an AI provider based outside the European Economic Area (the EU plus Iceland, Liechtenstein and Norway), such as in the US, your organization is making a transfer under Articles 44 to 49 of the GDPR, so the usual transfer rules apply. Meetily itself makes no transfer, because it doesn't send meeting data to us. If you want no transfer at all, use the on-device summary model, which is the default.

Yes. Local processing removes the vendor and transfer questions, but your own duties stay. You still need a legal basis for recording, you still have to tell participants, and you still decide how long to keep recordings and transcripts. You may need a data protection impact assessment (DPIA) first, and local files rely on your device security, such as disk encryption (Article 32). In some countries, works councils also need to be involved before you record staff meetings. Our GDPR guide for meeting transcription walks through each step.

No. Meetily Enterprise is self-hosted meeting transcription for organizations that need full control over their data. It runs entirely inside your organization's own network or servers, including the AI processing. It doesn't connect back to Meetily for updates, telemetry or licensing. Once it's installed, we have no data about how you use it. Nothing leaves your organization unless your own people choose to send it.

No. Meetily is GDPR compliant by design, but it holds no formal GDPR certification, and we don't hold SOC 2 or ISO 27001 either. Certifications check a vendor's security controls, while Article 25 asks what the design does by default, and both matter. They matter most when the vendor holds your data; for meeting content, the Meetily team holds none. Under Article 25(3), an approved certification can be one element that helps show compliance, but it never settles the question on its own. You can check how Meetily handles data yourself, because the code is open source.

Partly, and only to vendors that process data for their customers. On 21 October 2026, EU ambassadors agreed the Council's position on the Digital Omnibus, a package that includes changes to the GDPR. It would make data protection by design and by default apply to processors as well as controllers, for their own obligations, without changing the controller's duty. It is not law yet: the European Parliament still has to agree its position, and then both sides negotiate a final text. A vendor that never receives your meeting data isn't your processor for it, so the change wouldn't apply to that data.

Get started

Ready to try Meetily?

Join 739,000+ users who use Meetily for private meeting transcription. No bots, privacy first. Community Edition free.

No meeting bots

100% local transcription

Free & open source

Download Free

Star on GitHub (32K+) · Open source & self-hostable

Get Started with Meetily

Meetily Pro

Advanced features for individuals and teams.

Download

Get Meetily for Mac or Windows. Free and open source.