Personal AI assistant (email, calendar, tasks)

Knowledge workers lose hours each day to inbox triage, scheduling ping-pong and task bookkeeping. A personal assistant connects an LLM to the person's mail, calendar and task tools, summarises what matters, drafts answers, proposes meeting slots and files follow-ups. The value is real but the risk profile is unusual: the agent reads untrusted third-party content (incoming mail) while holding the user's credentials, so permission design and human approval matter more than model choice.

Problem & value

• Today: people triage dozens to hundreds of messages per day, copy action items by hand, negotiate meeting times by email and prepare for meetings by searching old threads. Human executive assistants solve this for few people only.
• AI value: inbox summaries and priority ranking, draft replies, automatic extraction of tasks and deadlines, scheduling proposals, briefings before meetings, and voice access on the go.
• Evidence: vendors (Microsoft, Google) publish time-saving claims from their own pilots; independent, long-term measurements are scarce, so measure locally with a baseline before rollout rather than trusting vendor figures [1][2].
• Distinction: this use case is the individual's delegate. Company-wide knowledge Q&A is KNOW-002; drafting-only is LANG-002; classification and routing of shared mailboxes is LANG-012.

Variants

• Employee copilot inside the suite: Microsoft 365 Copilot (Outlook, Teams, Planner) or Gemini in Google Workspace.
• Executive / founder assistant: broad delegation including scheduling on behalf of others, travel and expense follow-ups.
• Scheduling-only agent: negotiates slots with external parties by email (lower scope, lower risk).
• Private use: family calendar, bills and appointments, shopping lists; often voice-first on a phone or smart speaker.
• Self-hosted privacy assistant: local models, IMAP/CalDAV only, for lawyers, doctors, journalists and others with confidentiality duties.
• Shared mailbox / team inbox: several users, role-based access; closer to LANG-012 and CONV-004.

How it works

1. connectors (mail, calendar, tasks, contacts; OAuth, least-privilege scopes)
2. ingestion + index (embeddings of mail/notes, thread reconstruction, contact graph)
3. intent: chat/voice request or scheduled trigger (morning digest, new mail)
4. agent loop: LLM plans, calls tools (search mail, read thread, free/busy, create draft)
5. policy layer: classify each action as read | draft | reversible write | irreversible/external
6. human approval for external-facing or irreversible actions (send, accept, delete, pay)
7. audit log + undo

• Tool use: the model calls typed tools through function calling or the Model Context Protocol (MCP), the open standard for connecting assistants to tools and data [3].
• Personalisation: retrieval over the user's sent mail yields tone and recurring answers; a preference file holds working hours, meeting rules and VIP contacts.
• Autonomy ladder: read-only summaries first, then drafts (never sent), then auto-send for narrow, user-approved rules (e.g. accepting invites from internal colleagues in free slots).
• Human-in-the-loop: sending to external recipients, changing or cancelling meetings with others, deleting data and anything involving money require explicit confirmation by default.
• Prompt-injection boundary: treat all mail content as untrusted data; the agent must not follow instructions found inside messages, and tools that can exfiltrate data (send mail, open URLs) are gated [4][5].

Data preparation

The data is the user's own: mailbox, calendar, task lists and notes, usually in M365, Google Workspace or an IMAP server, plus shared mailboxes and attachments on file shares. Little preparation is needed compared with other use cases, but the quality of the result depends on a few basics.

Typical gaps: overflowing inboxes without folders or labels, shared mailboxes with mixed responsibilities, calendars that do not show real availability, tasks scattered across notes and sticky notes, and over-broad access rights that let the assistant see more than the user should. Incoming mail is untrusted and may contain injected instructions.

Preparation steps: clean up permissions and sharing before connecting (PREP-023), define which mail and folders the assistant may read and which data classes may go to which tool (PREP-024), write down delegation rules, tone examples and standard replies as gold examples (PREP-016), and agree labels or categories (PREP-019). For recurring business mail, a curated set of templates helps. Tools: mailbox rules, labels, the vendor admin console, a test mailbox. Rough share of effort: below 15 percent; most work is policy and permissions, not data conversion.

Implementation paths

Which path for whom

• SMB: Path A, because mature mailbox and calendar assistants (e.g. built into M365 or Google Workspace, or EU-hosted tools) exist at SMB prices for a standard process.
• Enterprise: Path B, because delegated access, approval rules and logging should follow the company's own identity, policy and shared AI platform instead of per-seat consumer tools.
• Developer: Path C, because open-source agent stacks with a local model let you control permissions and keep mail content in-house.
• Private: Path A, because a ready app is easiest; privacy-minded users can run a local setup with Ollama or LM Studio (Path C).

Path A — Buy (recommended for most SMBs)

• Suite-integrated: Microsoft 365 Copilot (Outlook/Teams/Planner), Google Gemini for Workspace; check data-residency settings, because inference routing and sub-processors have changed over time [2].
• Standalone assistants: Superhuman AI, Shortwave, Fyxer AI, Motion, Reclaim, Notion Mail and similar; mostly US-hosted, so check DPA, transfer mechanism and sub-processors.
• EU / privacy-oriented: Mistral Le Chat with connectors (France), Proton Mail with Lumo (Switzerland, outside the EU but GDPR-adequate), Nextcloud Assistant with Mail and Calendar (Germany, can run local models), Open-Xchange and Mailbox.org stacks, plus Tuta (Germany) for encrypted mail without AI inbox features.
• Choose A when: the organisation already runs Microsoft 365 or Google Workspace and wants minimal integration work.

Path B — Build on cloud APIs

• Models: frontier LLMs with tool use and structured outputs (Claude, GPT, Gemini) via EU regions where offered (Azure OpenAI EU data zones, Vertex AI EU, AWS Bedrock Frankfurt/Paris), or Mistral's API (EU provider).
• Connectors: Microsoft Graph, Gmail and Google Calendar APIs, IMAP/CalDAV, Todoist/Notion/Asana APIs, often through MCP servers.
• Orchestration: LangGraph, OpenAI Agents SDK, Claude Agent SDK, n8n for scheduled digests; store tokens in a secrets vault and use per-user OAuth with minimal scopes.
• Choose B when: you need custom rules, a specific tool landscape or multi-tenant behaviour not covered by Path A.

Path C — Self-host (open source)

• Models: open-weight instruction/tool-use models such as Qwen3, Mistral Small/Medium-class, Llama or gpt-oss, served with vLLM or Ollama; Whisper or similar for voice.
• Stack: Nextcloud Assistant, Open WebUI with MCP tools, n8n, local vector store (pgvector, Qdrant), Radicale/Baikal for CalDAV, Dovecot/IMAP.
• Hardware: HW3 for reliable multi-step tool use over long threads; HW2 works for digests and drafts with smaller models but errs more in planning.
• Trade-off: full data control, but weaker tool-use reliability than frontier APIs and ongoing ops effort.

Path D — Custom training

Rarely justified. Fine-tuning a small model on the user's own sent mail for tone, or a classifier for priority/urgency from corrections, can cut cost and latency. Needs hundreds to thousands of labelled examples and care with GDPR (training on mail content of third parties).

State of the art (2026)

• Assistants have moved from "summarise this thread" to agents that plan across mail, calendar and documents; MCP connectors are widely supported by assistant products and agent SDKs [3].
• Reliable: summaries, draft replies, extracting dates and action items, single-step scheduling against free/busy.
• Unreliable: long multi-party scheduling negotiations, ambiguous delegation ("handle this"), time-zone and recurrence edge cases, tone for sensitive messages, and silently dropping a message from a digest.
• Security is the main frontier: indirect prompt injection is the top-ranked LLM risk in OWASP's list; an agent with private data access, exposure to untrusted mail and an outbound channel is the classic "lethal trifecta" [4][5]. Defences are architectural (privilege separation, approval gates, no auto-rendering of remote content, allow-lists), not just filters.
• Computer-use agents can operate web UIs where no API exists, but are slower and more brittle than API connectors.

Shared resources & combinations

• Shares the LLM + tool-calling + vector-index stack with KNOW-002, CONV-004 and CONV-026; one self-hosted server (HW3) can serve several of these.
• Natural combinations: LANG-002 (drafting), LANG-012 (classification), CONV-003 (booking with external parties), AGENT-002 (back-office automation), voice front-end as in CONV-014.
• Meeting transcription and minutes can be a separate input channel; note that recording colleagues has its own legal basis and works-council issues.

Effort, cost & KPIs

• Path A: days to weeks; per-user subscription, typically in the range of tens of EUR per user per month; main effort is permissions, rollout and training.
• Path B: 1-3 months for a hardened agent with approval UI, audit log and tests; cost drivers are tokens per mailbox size, number of tool calls and security review.
• Path C: 2-4 months plus ongoing operations; GPU server and maintenance.
• KPIs: time spent in mail/scheduling per week (before/after), draft acceptance rate and edit distance, scheduling round-trips per meeting, missed-important-mail rate (audit sample), approval-override rate, security incidents, user trust score.

People & change

Involve management for the policy, IT and IT security for connectors and permissions, the DPO for mailbox processing and each affected user, who must stay in charge of what the assistant sends. Mailboxes contain personal data of third parties and often employee communication, so DPIA screening and an AVV are needed; keep confidential mail (HR, legal, medical) out of scope.

Works council: yes in companies with one. Assistants that log mailbox and calendar activity are objectively suited to monitor behaviour, so §87(1) no. 6 BetrVG applies as with M365 Copilot; §90(1) no. 3 requires timely information. Agree a works agreement stating that logs are not used for performance control. In public bodies the Personalrat is responsible.

AI literacy: support staff with short trainings on prompt injection, reviewing drafts and confidentiality (AI Act Art. 4; GUIDE-006, GUIDE-007). Start with a volunteer pilot group of 5 to 10 people, begin with read-only digests and drafts, and only later enable sending or calendar changes with approval. Typical concerns: surveillance, loss of personal tone and mistaken mails; address with draft-only mode and visible logs. See GUIDE-004, GUIDE-008 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: typically limited risk: the user must be informed when interacting with an AI system, and AI-generated content that appears to come from a human needs care under Art. 50 (a draft the user reviews and sends as their own is generally the user's communication). Art. 4 AI literacy applies to staff. If the assistant is used to evaluate or monitor employees, or to decide on task allocation based on behaviour, Annex III employment points may make it high-risk; emotion inference from voice or text at work is prohibited under Art. 5(1)(f). Not legal advice [6].
• GDPR: mailboxes contain personal data of third parties who never agreed to AI processing; need a legal basis (usually legitimate interest with documented balancing, per EDPB Opinion 28/2024 reasoning), DPA with the vendor, transfer safeguards, DPIA for broad mailbox access, and data minimisation (limit scopes, retention of indexes) [7]. Special-category data (health, union membership) in mail needs extra care.
• Employment law / works council: in Germany co-determination (BetrVG sec. 87) applies when tools can monitor behaviour; private mail on business accounts is a further trap.
• Professional secrecy: lawyers, doctors and others must check confidentiality duties before sending mail to external AI services.
• Security risks and mitigations: prompt injection via mail, over-broad OAuth scopes, token theft, accidental sends, hallucinated meeting details. Mitigate with least privilege, read/draft default, approval gates, allow-listed recipients and domains, no auto-loading of external content, rate limits, kill switch, full audit log and regular red-team tests.

Getting started

1. Define scope: read-only digest for one pilot group; list actions that must always need approval.
2. Check the existing suite's assistant first (Path A), including data residency, sub-processors and admin controls; run a DPIA if the scope is broad.
3. Establish a baseline of mail/scheduling time and run a 4-week pilot with 10-20 users.
4. Add drafting, then scheduling; review a weekly sample of drafts and digests for misses and errors.
5. Test prompt-injection scenarios with crafted mails before enabling any send or delete permission.

Sources

1. Microsoft — Microsoft 365 Copilot overview and privacy — https://learn.microsoft.com/copilot/microsoft-365/microsoft-365-copilot-privacy
2. Microsoft — EU Data Boundary documentation — https://learn.microsoft.com/privacy/eudb/eu-data-boundary-learn
3. Model Context Protocol — specification and security best practices — https://modelcontextprotocol.io/specification
4. OWASP — Top 10 for LLM Applications (LLM01 Prompt Injection) — https://genai.owasp.org/llm-top-10/
5. Simon Willison — Model Context Protocol has prompt injection security problems — https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. EDPB — Opinion 28/2024 on AI models and personal data — https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en
8. Nextcloud Assistant — https://nextcloud.com/assistant/