What we log, and what we never touch.

Each request records a timestamp, the route pattern, a status code and the latency. Question text and answer text are never written to any log.

Medications, dosing, biomarkers and indication text never appear in access logs, and identifiers in a requested path are not recorded either.

Passwords and keys are never stored in readable form, and the headers that carry a key stay out of the logs entirely.

Every answer keeps a provenance record of the sources used and the grades given, enough to reconstruct why an answer was given. The record never holds the text of the question.

AI output is marked and logged with tamper evidence, and the log is kept for 365 days. It names the sources cited, never the question or the answer.

Access logs are kept for ninety days, then deleted automatically. What the log holds says who called which route and when, not what was asked.

The access log is metadata and isn't a store of patient data. Read access is limited to a few operational roles. Application keys never get it.

Data and encrypted backups are kept in Germany. Backups are held for fourteen days with a second provider and restored as a test every month, because a backup nobody restores is a hope, not a backup.

The application, its databases and the search index run on servers in Germany, and the encrypted backups are kept in Germany too.

The AI models that write the answers run with providers in the United States, so a prompt can be processed outside the Union. Under their commercial API terms inputs are not used to train their models, but they may be kept for a limited time for abuse monitoring, and no zero-retention arrangement is in place. Moving to European endpoints with zero retention is planned.

Every query, key and record is scoped to the organisation it belongs to, and that scope is enforced in the query itself rather than in the interface above it.

Passwords, keys and password-reset links are never stored in readable form, so a copy of the database yields no usable credential.

Portal and admin accounts can add a second step at sign-in: a code from an authenticator app, or a passkey. An organisation's owner can require it for every member.

Portal sessions end automatically after inactivity, and requests that change data are protected against forgery.

API keys are issued per organisation, rotated or revoked from the portal, and rate-limited per key across per-minute, daily and monthly windows. A rotation can stop the old secret immediately, so a leaked key stops working the moment you act, or keep it for a short grace period during a planned switch. Keys can be limited to chosen endpoints and IP addresses, and can expire.

Every connection is encrypted and every response carries standard browser security headers. A test after each release flags it if any of them goes missing.

Every release is checked against the live service as soon as it is out: the security headers, the medical disclaimer and the statutory notices among them. A failed check flags the release, and we fix it or roll it back.

The code carries a written security review covering sign-in, separation between organisations and the handling of untrusted input. Dependencies are checked against published advisories before they are upgraded.

Production secrets are kept out of the source code, and a release fails if a key would reach anything sent to a browser.

Not certified. Certification is planned and this page will name the certificate and its scope when it exists, not before.

The controls on this page are designed against the Trust Services Criteria for security, availability and confidentiality. No Type I or Type II report has been issued yet. Treat this as a design commitment and not a certification.

The measures above are in place and a retention period is set for every category of data. Records of processing and the processor contracts with every provider are being completed and are not all in place yet. Where a clinic sends patient-related content we act as a processor under a written agreement concluded first, and our people are bound to professional secrecy.

The obligations in force today are met, and the documentation, logging and risk management are built so a high-risk classification could be met on its deferred deadlines without rebuilding the system.

Tell us before you disclose it and give us time to fix it. Write to the address on the contact page and we'll work the issue with you, confirm what we found and credit you if you want the credit.

Don't send patient identifiers to the API, keep your keys out of client-side code, and rotate a key the moment you think it has been seen. The parts under your control are the parts we can't harden for you.

The trust center sums up the controls, where data lives, who processes it and what is and is not audited. The legal page carries the controller, the processing detail and the rights you hold over your data.