Review customer data and confidential information before AI use

Copying a customer message into an AI window takes only a moment. The same message may contain contact details, contractual information, an internal calculation and information about other people. Often only a small part is necessary for the requested writing assistance. The central question is therefore not simply whether a tool is generally available for business use. It concerns the actual task, the necessary information and where that information will go.

This guide addresses organisational use of generative AI in Germany and the EU. Legal position and source review: 9 November 2026. It distinguishes data protection, contractual confidentiality and trade secrets from practical implementation recommendations. Every case described is a fictional learning example. The article gives no blanket approval for customer information and does not replace assessment of actual contracts or additional professional and sector-specific obligations.

Describe the task before attaching the document

Begin with the intended result. Does the team want to improve an approved public help text? Assess an individual situation? Make a message easier to understand? Those tasks need different information. An instruction to process a customer file does not reveal which parts of the file are necessary or what kind of decision is actually being requested.

In the fictional example, a service team wants a clear draft response about a delivery-date change. The AI is not asked to make a contractual decision or send a message. An approved general delivery policy and a short description of the communication situation may be sufficient. A full name, address, bank details and the entire correspondence history do not become necessary merely because they sit in the same file.

Record this boundary in a short brief. A colleague can then assess whether an attachment actually belongs to the task. It also makes quality review more precise: the draft must not invent a promise or individual entitlement when the approved task was only general writing assistance. A more detailed prompt is not automatically a more appropriate prompt.

Separate three different protection questions

Personal data, confidential contractual material and trade secrets are not identical categories. A technical drawing can be confidential without identifying anyone. Publicly known contact information may still relate to a person. An internal price can require careful handling without automatically satisfying every statutory condition for a trade secret.

Section 2 GeschGehG defines a trade secret through several conditions, including appropriate secrecy measures. Section 4 concerns unlawful acquisition, use and disclosure. A data protection assessment consequently does not replace reviewing a confidentiality agreement or establishing authority to disclose another business's information. Keep the conclusions of those reviews distinguishable.

Map the complete information path

Look beyond the visible chat window. A request may pass through an interface, an intermediary and several tools. Uploaded files may also become part of a knowledge collection, search index or workspace. An output can subsequently be distributed through a shared link, download or email draft. Each of those handovers can change who receives the information.

For the intended use, identify the source, preparation step, AI application, any separate model provider, additional tools and result storage. Add the points at which people or other systems gain access. A small diagram using actual names and responsibilities is more useful than a general picture of cloud computing that does not describe the selected service.

The service team's initial path might be limited to a prepared text and an organisation-managed workspace. Connecting the entire ticket system later would be a substantial expansion. The initial assessment of one text field does not automatically cover access to every customer case. Treating that connection as just another convenience setting would conceal a change in the actual processing.

Look for identification beyond names

A customer reference, an unusual combination of location and order details or a richly described incident may identify people without a written name. Replacing a name with Person A therefore does not automatically create anonymous data. With pseudonymised information, association remains possible under the relevant conditions. The description of the transformation should match what it actually achieves.

Check filenames, subject lines, comments and embedded material. A letter with its visible name removed can still identify the person through the filename. A spreadsheet can contain hidden columns or additional sheets. A screenshot may expose customer names around its edges. Review the exact version that will be transferred rather than only the most prominent paragraph.

The DSK guidance dated 6 May 2024 discusses personal data across an AI application's lifecycle. It is supervisory guidance rather than a complete approval catalogue. Looking only at the first visible lines of a document does not perform that broader assessment. The process should make hidden and indirectly identifying information part of the review.

Reduce information according to the task

Reduction starts by selecting what the specific task needs. That differs from uploading an entire document and asking the model to keep it confidential afterwards. Writing assistance can often use a short prepared factual extract. An assessment of an individual case may need different information and a more demanding review. Do not pretend those situations are interchangeable.

This table does not automatically establish lawfulness. It shows how a large collection of information becomes a reviewable question. If a task genuinely cannot be completed without particular content, describe that need. A preference for a longer prompt does not establish necessity. An acceptable amount of information depends on the purpose rather than the amount the service can technically accept.

Distinguish a learning request from a real customer file

An explicitly fictional training request could say: “Draft a factual response to a general enquiry about a delivery-date change. Use only the attached approved delivery information. Do not invent dates, refund rights or personal circumstances. The text remains a draft for human review.” This is an example written for the exercise, not a quotation from a real customer exchange.

The task does not require an actual customer file. The exercise can use a wholly synthetic situation, such as a customer wanting a clear explanation of the next steps. Replacing the names in an actual message would not, by itself, turn it into an independently invented training case. Its remaining facts could still point to the original people or business.

Compare the result with the approved information. If the response adds a goodwill promise or a definite date, that is a quality problem. Correct the draft and assignment. Providing more personal details is not an automatic solution to an unsupported statement. The team should not increase disclosure simply because the first answer was unsatisfactory.

Determine legal basis, role and contract separately

Processing personal data requires the appropriate basis. A processing agreement is not a universal substitute for that assessment. Equally, an ordinary services contract does not automatically settle all data protection roles. The relevant factors include the actual purposes, decisions and activities of the parties involved, not merely the product names on the invoices.

The EDPB guide to controllers and processors explains these roles and the binding agreement needed for processing on behalf of a controller. Establish who acts for which purposes and whether further recipients or subprocessors participate. Different steps in the overall service may require different role assessments.

A responsible organisational function should document that classification. The service or editorial team should receive an understandable description of the approved use. A staff member responding to an urgent customer request should not have to invent a legal position from several inconsistent contract pages. Clear operational guidance is the practical outcome of the earlier review.

Treat training and retention as different questions

Whether inputs are used to train a model is different from how long they are stored. A service may process information to execute a request, maintain a history, create technical logs or perform other declared functions. Review the actual terms and settings. One promotional statement does not answer all those questions or establish what happens in every feature.

Record the applicable contract version, reviewed feature scope and assessment date. A change of setting or a newly enabled feature should make the affected assessment identifiable. Keep earlier documentation as evidence, but do not treat it as an unchanging description of a service that has subsequently changed. The record needs to distinguish what was checked from what is merely assumed.

Assess locations and recipients concretely

A data-centre location does not answer every question about recipients, support access and subsequent processing. Establish the actual parties and agreed scope. If personal data is transferred to another organisation outside the European Economic Area, the relevant international-transfer conditions require additional assessment. A broad geographic label is not a substitute for that information.

The EDPB guide to international transfers distinguishes these conditions from the other requirements for processing. A transfer mechanism does not replace the remaining data protection obligations. Conversely, a product that appears European by name does not prove every real information path stays within the assumed boundaries.

In procurement, assign responsibility for obtaining and assessing the necessary information. The operational team then needs usable instructions for the approved functions. A collection of unchecked country lists with no connection to the actual service offers little practical help. The question is what happens to this information in this selected configuration.

Limit accounts and connected sources to their purpose

An AI workspace should not receive the widest available permissions merely for convenience. Preparing a general customer response does not require write access to the entire customer-management system. Read-only access can still expose a large amount of confidential content. Its real scope needs to match the assigned task instead of being treated as harmless by default.

Separate preparation from execution. A draft can initially be produced without permission to send it. A connected document search can be limited to an appropriate reviewed collection. When the use expands, new sources and actions should be examined explicitly rather than silently placed under an old approval. The resulting boundary should be technically enforceable where the system supports it.

The DSK technical and organisational guidance dated June 2025 considers AI systems across their lifecycle. It particularly addresses development and operation. It can inform procurement questions, but does not replace assessment of the specific combination of application, model and additional services the organisation intends to use.

Check confidentiality at the output boundary too

An output can repeat the protected information contained in the input. It can also generate inaccurate statements about customers or staff. A smoothly rewritten summary does not become publishable simply because its wording is new. Review its content, intended recipient and delivery route before sharing it. Rephrasing is not a transformation that automatically removes confidentiality.

In the example, the service team checks that the draft communicates only the approved delivery information. Necessary individual details are added at the appropriate later handling step. A decision about an actual goodwill arrangement remains with the authorised person. The AI draft should not imply that an instruction to grant such a benefit already exists.

Screenshots used for training or public demonstrations also need selection. A seemingly ordinary answer can expose a customer reference, workspace name or another case around its edges. Prefer prepared learning views to hurried redaction of a live conversation. The visible central answer is not necessarily the only information the image contains.

Make retention and individual rights operational

The organisation needs to know where information has been placed. Depending on the service, that may include uploaded copies, results, shared links and managed storage as well as the original file. A coherent record helps the team handle individual requests and internal deletion requirements instead of guessing which copy a person is referring to.

Documentation should not become another uncontrolled complete collection. For evidence of an assessed use, its purpose, approved service scope, responsible role and selected supporting records may be more useful than retaining every prompt indefinitely. Decide what needs to be kept, for what reason and for how long in the actual workflow. More stored material is not automatically better evidence.

The consolidated GDPR text supplied by the Hamburg supervisory authority contains the relevant provisions on processing, processors and security. Official legal acts remain authoritative. A delete button in one interface does not, by itself, demonstrate how every affected item is handled elsewhere in the service.

Prepare a response to accidental disclosure

Have an internal route for reporting an unsuitable file uploaded by mistake. Staff need an available contact and concrete initial actions. A prohibition followed only by blame is more likely to delay reporting than support a factual response. Preparation should make it possible to establish what happened without creating additional unnecessary exposure.

Record the relevant account, service, feature, information and any further recipients. Limit additional processing and preserve appropriate evidence without multiplying uncontrolled copies. The responsible functions then assess legal consequences and necessary actions. Their decisions should be grounded in the actual service configuration and facts rather than assumptions about what a chat interface normally does.

An accidental upload is not automatically a reportable personal data breach in every situation. Equally, the assessment should not be omitted merely because the visible conversation has been deleted. Data protection, information security and contractual reporting arrangements need to be considered according to the circumstances. Establish this response route before the first substantial production use.

Keep a concise and useful use profile

A practical use profile names the task, permitted information categories, reviewed feature scope and responsible approval. It also explains the boundaries: sources that are not connected, information requiring additional assessment and the function responsible for reviewing a new use. This creates an operating guide rather than a general statement about AI somewhere in the organisation.

For the fictional service team, the profile can describe preparing general draft responses from approved information. Access to complete customer files, assessment of sensitive personal circumstances and autonomous sending remain separate operations requiring their own review. This is an organisational example, not a statutory default configuration that every business must copy.

Revisit the profile when the service changes. An intermediary, another document collection or an automatic action can materially alter the information path. A successful earlier test of a short writing task does not approve that extension. Make the changed facts visible so that the relevant people can assess them without reconstructing the entire project history.

Access to another organisation's material is not ownership

An agency may have access to information without having unrestricted authority to share it. In a fictional example, a customer provides an unpublished product plan for website design. That establishes the agreed design assignment. Whether an additional AI service may receive the plan, and to what extent, still depends on actual authority and agreements.

A contact person's agreement does not automatically answer every further question. The document may include a supplier's information, employee data or other contractually protected material. A writing task might instead use an approved factual description that does not need those details. Assess that alternative before passing a complete document through several services.

Record the information category and task the decision actually covers. An identifiable responsible function is more useful than a note saying the customer agreed. If authority or scope remains unclear, hold the transfer and resolve the specific question. The urgency of a design deadline does not remove that uncertainty.

Checklist before the first real transfer

• The actual task and expected result are described.
• The information genuinely needed for that task has been identified.
• Personal data, contractual confidentiality and possible trade secrets have been considered separately.
• The transferred file version has been checked, including names, metadata and additional content.
• Renaming is not confused with complete anonymisation.
• Roles, the processing basis and necessary agreements are settled for the actual information path.
• Training, retention, access and deletion have been assessed as different questions.
• Recipients and possible international transfers are not inferred only from a product name.
• Tools and connected sources have the access intended for the defined purpose.
• Results are reviewed for accuracy and protected information before onward use.
• Requests, deletion requirements and accidental transfers can be handled in practice.
• A responsible function is identified for extensions of the use.

Begin with one clearly bounded task

Select a use whose information needs can be understood. Test it first with independently invented data and approved general content. Then resolve the remaining factual and legal questions for the intended production use. A successful formulation in a learning exercise does not answer those questions on its own. It establishes only what was actually tested.

Responsible AI use comes from suitable tasks, clear responsibilities and an inspectable information path. The goal is neither the largest possible prohibition nor blanket permission. It is a supportable decision about which particular processing should occur under which conditions. That decision remains reviewable when information scope, recipients and subsequent changes are documented coherently and kept connected to the actual workflow.