Buddy stores data about children: their medicines, their sleep, how they feel, their days. In the EU that is special-category data under GDPR Article 9, about people who need extra protection. This page is for anyone who runs their own Buddy, and for anyone who wants to help get this right.
It covers three things:
- What Buddy already does in the code.
- What you have to do yourself when you run it. The code can't do this part for you.
- What is still open, and how to tell us what you think.
This page isn't legal advice. Whoever runs a Buddy instance is the data controller for it and decides what the law requires of them. The design and the reasons behind it are in GDPR: erasure, export and data minimization.
- Accounts: guardians' names, email addresses, time zone and language, and children's names and usernames. Sign-in itself happens in Keycloak, which runs alongside Buddy.
- Family life: calendars, tasks and progress, meal plans and ratings, pickups, babysitters, work locations and print templates.
- Health data: medicine schedules and dose status, medicine effect and side-effect notes (guardians' daily ratings, kept with the dosage of that day), the sleep diary, and feelings check-ins (a colour, up to three words and a short note, by the child or by a guardian about them).
- AI assistant: the family's own provider API keys (encrypted), and each session's notes and chat.
- Logs: user and child ids (never names, emails or health data) in audit logs. See observability.md.
- Deleting an account erases the person. It covers every feature, including Keycloak and copies in shared streams, and survives a restore from backup through the erasure ledger.
- A sole guardian can delete a child. The app shows what will be deleted before anything is.
- Download my data: every guardian can export what Buddy holds about them and their children, as JSON.
- The AI assistant sends less.
- Children appear as "child 1", "child 2".
- Calendar titles are only sent for the family's own items that concern the child (or nobody). Everything else is sent as "busy".
- AI conversations are deleted after 30 days. A session's notes and chat are wiped 30 days after the session ends.
- A guardian has to acknowledge the AI notice first. No AI session starts until a guardian has read what is sent to the family's chosen provider and acknowledged it.
- Every read of health data is logged: who read a child's medicines, sleep diary or feelings check-ins, and through which route (as guardian, as the child, or through a group share), and every view through a doctor's share link.
- Secrets stay out of logs and storage: tokens are kept out of telemetry, and stored AI keys and saved API responses are encrypted.
Work through this list before real families use your instance. docs/privacy-setup.md walks through each item step by step, with a backup rotation script and templates for the record of processing, the DPIA and the notice.
- Privacy notice. Tell guardians, in words a child's parent understands:
- what you collect (the list above);
- why, and on what legal basis — health data needs an Article 9 condition, usually explicit consent;
- how long you keep it (see backups, logs and AI below);
- who receives it: your hosting provider, your email provider, and the AI provider the family picks;
- how to use their rights. Deleting the account and "Download my data" are in the app; say how to reach you for anything else.
- Record of processing activities (Article 30): what you process, why, for whom, where, and for how long.
- Data protection impact assessment (DPIA) (Article 35). Children's health data processed at scale, plus AI, will almost certainly need one.
- Data processing agreements (Article 28) with everyone who handles the data for you:
- your hosting provider (Oracle Cloud for the Docker setup, or Azure);
- your email provider (the deploy scripts use Brevo);
- any log or monitoring service you add.
- Back up for no more than 30 days. Backups still contain people who have since deleted
their account.
- Docker: deploy/README.md, section 7, has the dump commands and the restore steps. The restore steps put the erasure ledger back so erased people are erased again.
- Azure: the managed database keeps its own point-in-time backups. Check their retention. The ledger steps for an Azure restore aren't written yet (see below).
- Decide where the logs go, and for how long. The health-data audit logs only help if they
are kept somewhere. Set
OTEL_EXPORTER_OTLP_ENDPOINTto a log backend (observability.md). Then decide who can read the logs and when they are deleted, and put that in your notice. Without a backend the logs stay wherever your container logs go. - Check the AI notice against your privacy notice. The text guardians acknowledge is a
starting point. It lives in
src/frontend/buddy/src/app/core/i18n/translations/*/mealplan.ts, underaiAssistant.dataSharing.- Families bring their own key, so the AI provider is their choice. Buddy still assembles the data and sends it there.
- If the provider is outside the EU/EEA, that is a transfer your notice should cover.
- Free text that names someone stays. "Pick up Emil" in a shared calendar's item title stays when Emil's account is deleted. It's the family's shared plan, the other members can edit or delete it, and who wrote it is erased.
- No access log screen in the app. Buddy is meant to be run by each family, and that family has someone technical who can read the audit logs. Who has read a child's medicines, sleep diary or feelings check-ins is in the logs (see "Decide where the logs go" above).
- Azure restore. The erasure-ledger steps for restoring an Azure point-in-time backup aren't documented yet.
- A question, a disagreement, or something this page gets wrong: open an issue in the repository. Changes to this page are welcome as a pull request.
- Something that exposes people's data: don't open a public issue. Report it privately as SECURITY.md describes.