In brief
- Processing, retention and model training are separate activities and need separate assessment.
- The processed data can include documents, system instructions, search results and metadata in addition to the visible prompt.
- Connectors, web search and business systems extend the data flow beyond the model itself.
- The organisation remains responsible for purpose, permitted data, access rights and appropriate safeguards.
The data flow begins before the model
An AI request usually contains more than the text a person enters. The application may add system instructions, conversation history, user information or passages retrieved from internal sources. The model processes this combined package.
A reliable assessment therefore follows the data from its original source to the final storage or action system, rather than stopping at the connection to the model provider.
- Step 1
Input
A person asks a question, pastes content or uploads a document.
- Step 2
Context
The application adds rules, prior messages or approved business knowledge.
- Step 3
Processing
The model processes the supplied content and generates an output.
- Step 4
Return
The application displays the output or prepares it for another work step.
- Step 5
Downstream systems
The output and metadata may subsequently enter logs, databases, tickets or business applications.
Processing, retention and training are not the same
A provider must technically process data to generate a response. That does not automatically mean the content is stored persistently or used for training. Conversely, exclusion from training does not mean that no logs or application data are retained.
- Model inference: content is processed for the current request.
- Application state: conversations, files or assistants may be stored for later use.
- Safety logs: providers may retain content or derived signals to detect misuse.
- Training and improvement: whether customer data can be used is a separate product and contractual question.
- Operational metadata: timestamps, account, model, token volume, errors and cost can be logged without retaining complete content.
Not all business data requires the same protection
Permitted use should not be decided once for an entire AI tool. A public product sheet, an internal procedure and a contract containing personal data create different requirements. A simple classification gives employees and project teams practical boundaries.
- Public: information already published and approved
- Internal: working material without particular confidentiality requirements
- Confidential: contracts, pricing, strategy, source code or trade secrets
- Personal: information relating to an identified or identifiable person
- Specially protected: for example health information or data subject to professional or official secrecy
Accountability follows the full data flow
Using a cloud or AI provider does not transfer the organisation’s accountability for its processing. The organisation needs to know which parties process which data, for what purpose, in which locations and with which subprocessors or third parties.
Where personal data is disclosed to other countries, the applicable Swiss requirements and safeguards for cross-border transfers also need to be assessed.
| Stage | Which data flows? | Possible recipients or storage locations | Required control |
|---|---|---|---|
| Input and interface | Question, upload, user identifier and device or session data | In-house application, SaaS interface, browser telemetry and support system | Classify data, remove unnecessary fields and deliberately configure content-bearing logs |
| Knowledge access | Search query, retrieved passages, metadata and permission information | Source system, search index, vector store, connector or integration service | Check access on every request, assign source ownership and test permission revocation |
| Model processing | System instruction, user question, context, tool results and generated answer | Model provider, selected region and its approved subprocessors | Evidence the product, contract, region, training use and retention for the exact endpoint |
| Output and downstream systems | Answer, sources, proposed action, feedback and operational metadata | Ticketing, email, database, monitoring, analytics or archive | Check destination authorisation and approval, minimise logs, and test export and deletion |
Protection comes from architecture and clear rules
An internal policy is useful but insufficient on its own. A sound solution reduces unnecessary data before a model request and technically limits access, retention and onward disclosure.
- Step 1
Classify
Define which data is permitted for the use case.
- Step 2
Minimise
Send only required passages and fields; anonymise or pseudonymise where appropriate.
- Step 3
Configure
Set training, retention, regions and stateful features deliberately.
- Step 4
Restrict
Grant roles, sources and actions according to least privilege.
- Step 5
Verify
Test data flows, settings, deletion and logs, and reassess them when the product changes.
Example: contract questions in customer service
A customer service assistant prepares answers about existing contracts. The application retrieves only approved clauses, removes personal data that is unnecessary for the task and sends the relevant passages to the model. Roles determine who may access each contract. Answers include sources and are reviewed before being sent. Contractual terms and technical settings define whether content is retained or used for training, while internal logs contain only what is needed for quality and operation.
What to remember
Map the complete data path for one concrete use case, from the user to every downstream system. Only then can you decide which data is permitted and which technical, organisational and contractual controls are required.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
General guidance based on official sources. This is not legal advice; requirements must be assessed for the specific use case and applicable jurisdiction.