DSGVO-Compliant Meeting Analysis

Meeting analysis with AI is powerful—but stay DSGVO-compliant. Core principle: analyze the meeting, not the people. Bewerte das Meeting, nicht die Teilnehmer. The core principle is simple: analyze the meeting, not the people.

What’s Allowed vs. What’s Not

What We CAN Do

1. Structure Analysis

• ✅ “3 decisions were made in this meeting”
• ✅ “4 action items were defined”
• ✅ “Meeting ran 45 instead of planned 30 minutes”

2. Format Assessment

• ✅ “This was planned as a Daily but became a problem-solving session”
• ✅ “Topic X should have been a separate workshop”
• ✅ “This decision could have been made async”

3. Insight Extraction (Anonymized)

• ✅ “Insight: Legacy requirement ≠ current reality”
• ✅ “Pattern detected: Decisions repeatedly deferred”
• ✅ “Principle: User perspective catches developer blindspots”

4. Decisions + Action Items

• ✅ “Decision: GraphQL instead of REST for new API”
• ✅ “Action: Create API spec by Friday”
• ✅ “Open: Budget approval pending”

What We CANNOT Do

1. Participant Profiles

• ❌ “Sebastian dominates discussions”
• ❌ “Lars is reserved on architecture questions”
• ❌ “Profile updated: Volker shows resistance to proposals”

2. “Who Said What”

• ❌ “Sebastian said: ‘This is too complex’”
• ❌ “Lars argued for Option A”
• ❌ “Volker contradicted the proposal”

3. Behavior Assessment

• ❌ “Sebastian was impatient”
• ❌ “The team was not prepared”
• ❌ “Person X derailed the meeting”

4. Political Analysis

• ❌ “Subtext: Lars is trying to gain influence on SC”
• ❌ “Dynamic: Territorial conflict between teams”
• ❌ “Sebastian is filling the CTO void”

Gray Zone: How to Handle

Quotes Without Attribution

• ❌ NOT: “Lars said: ‘We need more tests’”
• ✅ INSTEAD: “It was noted that more tests are needed”

Naming Decision Owners

• ⚠️ GRAY ZONE: “Sebastian is owner for API design”
• ✅ BETTER: In action items only when necessary for accountability

Team Dynamics

• ❌ NOT: “The team was divided”
• ✅ INSTEAD: “No agreement reached, follow-up meeting scheduled”

Technical Implementation

## CRITICAL RULES (Tier 1)

NEVER in output:
- Connect names with statements ("X said...")
- Behavior assessments of people
- Profiles or characterizations
- Political dynamics between people

ALWAYS:
- Passive formulations ("It was decided...")
- Meeting focus, not people focus
- Anonymized insights

Two-Output Strategy

Output 1: Official Debrief (DSGVO-compliant)
├── Decisions
├── Action Items
├── Insights (anonymized)
└── Meeting Assessment (format, not people)

Output 2: Personal Subtext (ONLY for you)
├── Your own Manöverkritik
├── What you could do better
└── Notes for yourself

Important: Output 2 is YOUR private document. Don’t share, don’t store in official systems.

Legal Background

DSGVO Art. 6 - Lawfulness

Processing of personal data only with:

• Consent OR
• Legitimate interest (but: balance required!)

Meeting transcription:

• Generally allowed if everyone is informed
• Creating profiles: Additional consent required
• Storing “who said what”: Problematic

Works Council Relevance (Germany)

In DE: Works council has co-determination rights for:

• Performance and behavior monitoring
• Automated processing of employee data

Meeting analysis can fall under this if:

• People are evaluated
• Speaking time is tracked
• Performance is derived

Checklist Before Use

• Team is informed that transcription is happening
• No person profiles are created
• No “who said what” attribution
• No behavior assessments
• Output focuses on meeting, not people
• Personal notes separate from official debrief
• When in doubt: Ask works council / data protection officer

Summary

Remember: The meeting is the subject, not the people in it.

Sources

• DSGVO Art. 6: Lawfulness of processing
• BetrVG §87: Works council co-determination (Germany)
• Data protection best practices: Anonymization techniques