ChatiTec — Legally Compliant & Data-Protection-Compliant AI from Augsburg
Annex 1 to the Data Processing Agreement
Convenience translation. This English text is provided for information only. The legally binding version is the German original (
AVV – Anlage 1: Technische und organisatorische Maßnahmen). In case of any discrepancy, the German version prevails. German statutory references (e.g. § 203 StGB) are retained; “GDPR” refers to the General Data Protection Regulation (German: DSGVO).
Technical and Organisational Measures (TOMs) pursuant to Art. 32 GDPR
As of: 23.10.2026
Processor: Sat-iTec Systemhaus GmbH
Platform: ChatiTec (hosting: Augsburg data centre, own Proxmox infrastructure)
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the processor implements the technical and organisational measures described below in order to ensure a level of security appropriate to the risk (Art. 32 GDPR).
1. Confidentiality (Art. 32(1)(b) GDPR)
1.1 Physical access control (physical access to processing facilities)
- Operation in a data centre in Augsburg with access protection (e.g. mantraps/turnstiles and locking systems, logging of entries, video surveillance).
- Servers in locked racks; access only for authorised personnel on a need-to-know basis.
- Visitors are accompanied and logged.
1.2 System access control (protection against unauthorised use of systems)
- Authentication via individual user accounts; no shared accounts for administrative tasks.
- Passwords are hashed with Argon2 (memory- and compute-intensive, salted hashing method).
- Two-factor authentication (TOTP 2FA) available/enforceable for accounts.
- JWT-based session tokens with rotation (short validity period, renewal/invalidation).
- Rate limiting to fend off brute-force and abuse attempts.
- Automatic locking/time-out of inactive sessions.
1.3 Data access control (authorisation-based access to data)
- Role and authorisation concept (least privilege); separate administrator and user roles.
- Logging of security-relevant access in the audit log.
- Provider secrets (API keys of external AI providers) are stored encrypted with Fernet; no plain text in configuration or repository.
- Regular review and revocation of authorisations that are no longer required.
1.4 Separation control (tenant separation/purpose limitation)
- Separate database VM (data storage on a separate virtual machine, separated from application services).
- Logical separation of the data of different customers/tenants.
- Separation of production, test and development environments.
1.5 Pseudonymisation and anonymisation
- PII tokenisation before every transmission to external AI providers: personal data and professional secrets are automatically detected and replaced by placeholders.
- Anonymisation is enforced by default (
PII_FORCE_FOR_EXTERNAL=true); sending identifying plain-text data to external providers is prevented at system level.
- Re-mapping of the placeholders is possible exclusively locally on the German infrastructure and is Fernet-encrypted.
- Purely local models (Ollama/vLLM) are available as a transfer-free alternative without any external data outflow.
2. Integrity (Art. 32(1)(b) GDPR)
2.1 Transfer control (transport)
- Transport encryption by means of TLS (certificates via Let's Encrypt) for all connections to the platform.
- External transmissions take place exclusively in encrypted form and exclusively in anonymised form.
2.2 Input control (traceability)
- Audit log for logging security-relevant events (e.g. logins, administrative changes).
- Time-stamping and – where necessary – attribution to the triggering user accounts.
- Protection of logs against unauthorised alteration.
3. Availability and resilience (Art. 32(1)(b) and (c) GDPR)
- Data backup: daily full backup of the database with automatic plausibility check; retention 14 days; in addition, backup of the systems in a physically separate fire compartment as an unalterable online backup (immutable backup, protection against deletion and encryption by malware); key material is stored separately from the backups.
- Restore procedures and regular testing of the ability to restore (Art. 32(1)(c) GDPR).
- Operation on Proxmox virtualisation with separate virtual machines for application, database and data backup.
- Protective measures against overload and attacks (including rate limiting, monitoring).
- Uninterruptible power supply and air conditioning provided by the data centre.
- Protection against malware (hardening, prompt patch management).
4. Encryption (Art. 32(1)(a) GDPR)
- Transport: TLS for all external connections.
- Secrets: Fernet encryption of the provider API keys and of the local PII mapping data.
- Passwords: Argon2 hashing (no reversible storage).
- Encryption of stored content at application level: chat content, placeholder mappings and memory entries are encrypted with Fernet (AES-128-CBC + HMAC-SHA256), with keys derived per tenant.
5. Process for regularly testing, assessing and evaluating (Art. 32(1)(d) GDPR)
- Data protection management process with regular review of the effectiveness of the TOMs.
- Regular patch and vulnerability management; prompt installation of security-relevant updates.
- Order control: contractual commitment and monitoring of sub-processors (see Annex 2).
- Obligation of employees to maintain data secrecy and – where applicable – professional secrecy (§ 203 StGB), awareness-raising/training.
- Incident response process for personal data breaches (detection, assessment, notification pursuant to DPA § 7).
- Regular internal security reviews of the application and configuration as well as prompt installation of security updates.
6. Data protection by design and by default (Art. 25 GDPR)
- Data minimisation through anonymisation enforced by default before external processing.
- Option of fully local operation without external transfer as a privacy-friendly default setting for processing operations requiring particular protection.
- Deactivation of providers with increased third-country concerns (DeepSeek deactivated by default).
As of: 23.10.2026 – The measures are reviewed regularly and adapted to the state of the art.