Data protection impact assessment: meeting recording and transcription¶
Draft: needs the owner's lawyer review. Not legal advice. This is a worksheet of facts and options. It reaches no legal conclusion: every "decision" entry is for counsel and the customer. Replace every
<...>before use. Whether a DPIA is mandatory, and who must carry it out (customer as controller, us as processor assisting), is for counsel to decide.
Assessed by
1. The processing¶
- What: a Bill or Ben meeting bot joins a Microsoft Teams meeting through Attendee, records audio, produces a transcript with Deepgram, and answers people it recognises. Transcript text goes to the meeting model for summaries and tasks. Spoken answers use ElevenLabs. (See the Sub-processors list.)
- Who is recorded: every participant, including guests and people outside the customer. Participants are matched to platform users by the Teams identity; an unmatched speaker is "unknown".
- Roles: customer = controller; Bill & Ben = processor (see the DPA template).
- Scale:
. - Where the data lives: Attendee (self-hosted by us, on Hetzner), our platform database, the sub-processors above for the time of processing.
2. Lawful basis: options for counsel¶
We list the options the customer may rely on; we do not choose.
| Option | What counsel must decide |
|---|---|
| Customer's legitimate interests | Balancing test; whether guests and external participants change it; opt-out route |
| Consent of each participant | How it is asked and recorded in a live meeting; what happens to a participant who declines; withdrawal |
| Contract (employees) | Whether it can apply to recording that is not strictly needed for the work |
| Other |
Special-category data (health, union, etc. said aloud) and children:
3. Transparency measures in the product¶
| Measure | What it does |
|---|---|
| AI notice | When the agent joins, it posts a chat message and speaks a line that it is an AI assistant, plus the fixed sentence "This meeting is recorded and transcribed." A tenant may reword the AI sentence but not drop the AI phrase or the recording sentence |
| Visible name | The bot appears as "Bill (AI)" or "Ben (AI)" in the participant list |
| Evidence | Each showing of the notice is an audit row (ai.notice.shown) in a hash-chained log |
| Privacy notice | Describes meeting data, retention and rights |
Gap to review: the notice is posted at join. A person who joins later sees the chat message only if the chat history is visible to them.
4. Risks and mitigations¶
Likelihood and severity are for counsel and the customer to rate:
| # | Risk | Mitigation in the repository | Open point for counsel |
|---|---|---|---|
| R1 | Participants are recorded without knowing | AI notice in chat and voice at join; "(AI)" bot name; recording sentence cannot be edited out | Is it enough for late joiners and guests? |
| R2 | An unauthorised speaker gives the agent a command | Every command goes through the permission check; an unknown speaker is never allowed; a failed check means no run | None in code |
| R3 | The agent embarrasses or exposes a person by answering an unauthorised speaker | Policy decline_once: at most one polite refusal per person per meeting (per 24 h), never a second message; silent and decline_always are the other values; an unreadable policy or ledger means silence. The refusal text states no reason beyond "people your admin has allowed" |
Is one spoken refusal acceptable, or should the default be silent? |
| R4 | Transcripts kept longer than needed | Default 90 days for transcripts, set per tenant in the console; a nightly job deletes through Attendee delete_data for bots older than the cutoff |
Is 90 days justified for each customer? |
| R5 | Deletion of one person's voice or words on request | Not possible per speaker in Attendee. A user-erasure request fails closed (status failed, nothing deleted) until a policy exists. Deleting the whole meeting or the whole tenant works |
Which policy: delete the whole meeting, redact, or refuse with reasons? |
| R6 | Data leaves the UK or EEA to model and speech vendors | Sub-processor list with locations to confirm; per-tenant model allow-list lets a customer exclude a vendor; optional EU or UK regional endpoints are listed as options in docs/buy-and-prepare.md |
Transfer tool and risk assessment per vendor |
| R7 | Another tenant reads the meeting data | Row-level security on every table; bots tagged with tenant_id, and the retention and delete code never touches a bot without it; per-tenant agent environment |
Independent test result: |
| R8 | Unauthorised access or tampering | Permission check on every action; hash-chained audit with a nightly verifier; no UPDATE or DELETE on the audit table for application roles | None in code |
| R9 | Logs or monitoring carry meeting content | Better Stack must receive no content; the owner checks log scrubbing before launch (see Sub-processors) | Result of the check: |
| R10 | Data of a left or deleted customer remains | Tenant deletion removes rows, volumes, model access and sign-in org; backup copies are not edited and expire by rotation within about 12 months (7 daily, 4 weekly, 12 monthly); a checker script shows zero rows left | Whether about 12 months of backup expiry is acceptable, or the rotation is shortened |
| R11 | The agent's answers are wrong or biased and a person relies on them | Not addressed by this document beyond the AI notice |
5. Rights handling¶
Export: tenant or person data zipped within 72 hours (privacy.export). Erasure: see R5 and R10. Objection and withdrawal of consent:
6. Consultation and sign-off¶
| Item | Value |
|---|---|
| Data protection officer's advice | |
| Views of participants or their representatives | |
| Residual high risk? Regulator consultation needed? | |
| Decision on lawful basis | |
| Approved by | |
| Next review |