Emails remain drafts
The system prepares reply drafts but never sends them itself. Sending remains technically under human control; there is no automatic-send switch that can be enabled accidentally.
Security & Compliance
Control you can demonstrate
This page explains the technical architecture principles KIKS systems use to address requirements under the GDPR and the EU AI Act. The legal assessment is carried out for the specific use case; assurances concerning data location, data flows and scope are agreed contractually for each project.
Permission model
The AI can only do what has been explicitly enabled
KIKS systems follow an allowlist approach: every action the AI may perform is defined and enabled individually before implementation. Anything not enabled is technically unavailable to the system — a system boundary, not an informal policy.
Documents are reviewed first
Recognised and structured documents are presented for review. They are saved or processed further only after a responsible person confirms the result.
Defined data access
The system receives access only to the data sources required for the specific process. Those permissions are documented in writing.
Traceability
Every step is logged and can be reconstructed
For every run, the system records what happened: the input processed, the data accessed, the action taken and the basis for it. You can see what the AI did and why.
What the log records
- processed inputs and data sources used
- actions performed and their timestamps
- the system's rationale or decision basis
- human approvals granted or refused
How you can use it
- internal reviews by IT or data protection teams
- supporting information for records of processing activities
- answers to management or auditor questions
- incident analysis, with individual cases reconstructed
Data sovereignty
EU data location as an architectural principle
You decide where processing takes place. Both options are designed so that data does not leave the EU. The specific processing chain, participating providers and assured data location are assessed, documented and contractually agreed before the project begins.
On-Premise
The system runs entirely on your own infrastructure. This can be appropriate for particularly sensitive data or strict internal IT requirements.
- data and models remain in-house under the agreed architecture
- integration with your existing IT security environment
- external services are excluded from the agreed processing chain
EU Cloud
An architecture using German and European providers and European language models. The services and data locations actually used are approved and agreed contractually for the project.
- European language models, such as Mistral, instead of US models
- hosting and processing with EU providers
- documented data flows and storage locations
GDPR
Implementation in line with GDPR principles
Data protection shapes the architecture from the outset. Whether the specific solution meets all applicable GDPR requirements is assessed for the individual use case. The resulting technical measures and contractual assurances are defined and documented before implementation:
Data minimisation
Only the personal data required by the specific process is handled. Broader access is not configured in the first place.
Processor arrangements
Participating providers, data flows and storage locations are recorded in writing, providing a basis for data processing agreements under Article 28 GDPR.
Accountability
Complete logging makes processing traceable and supports records of processing activities and internal controls.
Deletion and return
Test data, sample emails and access credentials that are no longer required are deleted or returned at the end of the project, unless retention obligations apply.
EU AI Act
Article 50 of the EU AI Act: transparency by design
Transparency and labelling under Article 50 of the EU AI Act, applicable from 2 August 2026, are considered in the system architecture: AI interactions and AI-generated content are identified as such. Any additional obligations are assessed according to the risk category and the specific use case and are documented contractually.
Risk assessment before implementation
Each use case is classified before work begins: its risk category and resulting obligations are identified. High-risk applications are implemented only after a separate assessment and explicit agreement.
Human oversight built in
Approval stages and a draft-first approach keep relevant decisions with people. Oversight is part of the system architecture, not a policy added afterwards.
Transparency and labelling
AI interactions and AI-generated content are visibly identified. Logging, documented changes and regular reports support the transparency and documentation duties established for the project.
What KIKS deliberately does not build
- uncontrolled AI agents without clear boundaries
- automatic email sending without approval
- black-box processes without logging
- systems that process data outside the EU
- AI making legal, medical or payment decisions without human review
- systems without clear ownership
Start securely
What boundaries does your process need?
Describe the workflow and the data involved. I will assess how it can be designed with control, logging and GDPR principles in mind; the specific legal assessment is carried out per project, or as a paid Initial Analysis.