The AI Act Questions to Ask Your Meeting Assistant Vendor (2026)

Every sales team now runs an AI notetaker. Someone invites a bot to the call, or records it botless in the browser, and a transcript and summary appear a minute later. It feels like a small tooling decision. It is not. That recording carries your customers' voices, your commercial terms, and your competitive positioning, and from 2 August 2026 the same recording sits inside two regulatory frameworks at once: the GDPR, which governs where and how the personal data is processed, and the EU AI Act, whose transparency and deployer obligations become applicable on that date.

The good news for buyers is that a transcribe-and-summarise meeting assistant is not a high-risk AI system in the sense that triggers the Annex III conformity-assessment regime. The obligations that do land on you are narrower and more practical: disclose the AI when people are interacting with it, know where the call data is processed, and hold the vendor to it in writing. This guide gives you the seven questions that surface those answers before you sign, with what a good answer looks like and what should make you pause. At the end there is a one-page checklist you can print and take into a vendor call.

Why a DPA and an "EU data centre" are not the finish line

The reflex answer to AI procurement risk is to ask for a Data Processing Agreement and to check that the vendor stores data in Europe. Both matter, and neither is sufficient. A DPA is the contractual floor required by GDPR Article 28; it is only as strong as the specifics written into it. And an "EU data centre" tells you where the files rest, not where the audio is transcribed, where the transcript is summarised, or which company can be compelled to hand any of it over. Meeting assistants are pipelines, not single boxes, and the compliance exposure lives in the parts of the pipeline that a storage-location claim hides.

The seven questions below walk that pipeline end to end. Ask them during evaluation, before any commercial commitment, so the answers shape the contract rather than surfacing during an audit.

Question 1: Where is it hosted, by region and by provider?

Start with the plainest question and refuse a vague answer. "The EU" is not an answer; "Frankfurt, on Hetzner" or "eu-central-1 on AWS" is. Then ask the question most buyers skip: where is the data processed, not just stored? A vendor can honestly say recordings are stored in Germany while the audio is sent to a US transcription service and the transcript to a US language model. For GDPR, both the storage location and every processing location matter.

The reason the provider matters as much as the region is the US CLOUD Act, which lets US authorities compel US companies and their subsidiaries to produce data they control, wherever in the world it is stored. A US-headquartered vendor, or a vendor with a US parent, cannot fully insulate your call data from that reach even with an EU data centre. The architecture that removes the exposure entirely is a vendor that is EU-owned with no US parent and no US processor in the transcription and summarisation path, because there is then no US company in a position to receive such an order.

Question 2: Who are the subprocessors, and where is the full list?

A meeting assistant almost never does everything itself. It relies on subprocessors for transcription, for the language model, for storage, and often for telemetry. Under GDPR Article 28 the vendor must maintain a complete, current list of these subprocessors and give you a mechanism to be informed of changes. The list is where the pipeline stops being a marketing claim and becomes checkable.

Pay particular attention to the two AI steps, because they are the ones most often left unnamed. If the vendor will not name its ASR provider, you cannot assess where your audio goes. If the summarisation model is a US large language model provider, that provider is in your chain regardless of which region hosts the inference, because the company answering to a subpoena is US-domiciled. A vendor that names every subprocessor, including the AI ones, and commits to advance notice of changes, is showing you the whole pipeline. A vendor that names storage but calls the AI providers "trusted partners" is showing you the box and hiding the pipeline.

Question 3: Is my call data used to train or improve any model?

This is the question with the largest commercial and legal consequences, and the one most often buried in terms of service rather than answered in the contract. Ask it directly: are recordings, transcripts, prompts, or generated summaries used to train, fine-tune, improve, or evaluate any model, whether the vendor's own or a third party's accessed via an API? Require the answer in the contract, not on a webpage that can be edited without notice.

The exposure is not hypothetical. Sales calls almost always contain personal data about identifiable people, so training on them is a new processing purpose that needs its own lawful basis, and legitimate interest rarely survives scrutiny for training on third-party business data. Worse, once personal data is trained into model weights it is effectively impossible to remove, so an Article 17 erasure request may become impossible to honour. The commercial risk is just as direct: your calls contain your pricing, your objection handling, and your customer intelligence, and a shared model trained on them can carry that value to competitors on the same platform.

Question 4: Can you control or self-host the model, and what happens when it changes?

AI models are not versioned like ordinary software. A vendor can swap or update the underlying model with no announcement, and the summaries and scores your workflow depends on can change overnight with no change to your inputs. For a meeting assistant that feeds coaching, forecasting, or QA, a silent model change quietly breaks the assumption that this month's outputs are comparable to last month's, and it undermines any audit trail that relies on knowing which model produced a given output.

So ask what control you actually have. Can the model be pinned to a version? Can the vendor tell you, in advance, when it changes, and what changed? At the strongest end of the spectrum, can the assistant be self-hosted or deployed on-premise, so the model runs on infrastructure you or the vendor operate rather than a multi-tenant cloud that can change under you? Self-hosting is not the only acceptable answer, but the ability to pin a version and get advance notice of changes is close to a baseline for anything that produces auditable output.

Question 5: How does the bot disclose itself in the meeting?

This is the question the EU AI Act adds on top of GDPR. Article 50 sets transparency obligations that become applicable on 2 August 2026, alongside the deployer obligations in Article 26, with a short transition into 2 December 2026 for some systems already in use. The relevant rule for a meeting assistant is straightforward: people should be informed when they are interacting with an AI system, unless it is obvious from the context. A recording notetaker is exactly the kind of tool that rule is meant to make visible.

How a vendor satisfies this depends on its capture model, and each model puts the disclosure duty in a different place. A bot that joins the call as a named, visible participant is, by design, disclosing its own presence: everyone can see it in the participant list. A botless or on-device recorder captures without appearing to the other side, which can be a genuinely good workflow, but it means nothing is visible to the counterparty, so the entire disclosure and consent duty shifts to you as the person running it. Neither model is automatically compliant or non-compliant. What you need to know before you buy is which model the tool uses, and therefore who carries the disclosure obligation and how easily you can prove it was met. Article 50 sits on top of, and does not replace, the GDPR consent and lawful-basis rules that already apply to recording a call.

Question 6: What are the deletion and retention guarantees?

Call recordings are among the most sensitive data a company holds, and GDPR storage-limitation and erasure rights mean you cannot keep them forever and must be able to delete them on request. Ask how retention works and whether you control it: can you set a retention period, does deletion actually remove the recording and the derived transcript and summary, and does it propagate to backups within a defined window? A tool that deletes the visible copy but keeps the audio in a backup for a year has not really deleted it.

The subtle failure mode is derived data and backups. When you delete a call, the transcript, the summary, any embeddings built for search, and every backup copy should be on a defined path to deletion too, not just the primary recording. Ask for the retention default, the deletion mechanism, and the backup deletion window in writing.

Question 7: Is a DPA available, and does it match the product?

Finally, close the loop with the contract. A DPA under GDPR Article 28 should be available as standard, not as an enterprise upsell you have to negotiate for. But the point of asking it last is that the DPA has to match the answers to the first six questions. If the vendor told you transcription runs in the EU, the DPA and its subprocessor annex should say so. If the vendor promised no training on your data, the no-training clause should be in the DPA, not a webpage. The DPA is where every verbal reassurance either becomes binding or evaporates.

How today's meeting assistants answer, from public sources

To make the questions concrete, here is how three widely used meeting assistants describe their own processing in their public privacy, security, and DPA documentation, next to Numi. Every cell below is taken from the vendor's own published pages, cited underneath. Where a vendor does not name a provider publicly, the table says so rather than guessing. This is a snapshot of published documentation as of August 2026 and vendors change their stacks, so verify against the current pages before you decide.

Fair-reading notes: Granola's on-device capture is a genuinely private-feeling workflow; the point above is only that audio captured on the device is still sent off the device to US providers for processing, per its own security page. tl;dv is an EU company hosting in the EEA and is the closest of the three to an EU-first story; the one US dependency is its named AI provider. None of the three offers self-hosting, so the "where is it processed" question always resolves to their cloud.

Numi's own position, stated plainly and without overclaiming: transcription and summarisation run on self-hosted models on EU infrastructure, with no US ASR or language-model provider in that path; a DPA is available as standard; customer call data is not used to train models; and the product is self-host and on-prem deployable. Numi does not claim to be "compliant", because compliance is a property of your whole deployment and your own disclosure and retention practices, not of any single tool. What Numi does is make every one of the seven answers above easy to give in your favour.

If you want the deeper legal background behind these questions, see our EU AI Act timeline for B2B SaaS and the 2026 buyer's guide to GDPR-compliant call and meeting recording. To see how Numi is built for this, read about the product.