Author
Dr. Christian Schüller
Co-Founder & Product Tech Lead, TRENPEX
Subscribe to our newsletter
Share
The decisive boundary is not between good and bad AI
Personal AI tools are fast, capable, and often already available on a person's phone or laptop. That is precisely why they so easily become a shortcut at work: summarising an email, reviewing a contract, structuring a customer question, explaining an error log, or revising code.
The decisive question is not whether a model is good or bad. It is: may this information be processed by this particular service for this purpose?
The following considerations start from a simple observation: what matters is not whether an AI account is called personal or business, but whether the specific data processing is approved. A personal service is generally not an approved company environment, but the account label alone does not determine permissibility. Anyone entering work content into an unapproved service can cross that boundary unintentionally.[2] This is not a call to ban AI in companies; it is a call to consider approval, data, and purpose together.
Approval decides, not the account type
A personal account can be appropriate for personal or publicly available content. It is not, however, automatically selected by your company, contractually reviewed, administered, or integrated into its security and data-protection processes. Conversely, a business account is suitable only when it has been approved for the specific purpose and data class.
Business offerings differ from personal offerings in more than price. Depending on the provider and product, they may include separate business terms, access management, contractual documentation, data controls, and other default provisions. For example, OpenAI and Anthropic describe different default rules for the use of inputs in model training for business customers than for their consumer products.[3][4]
That does not automatically make every business tool suitable for every piece of information. It does create an environment in which the company can govern approvals, permissions, retention, supplier agreements, and data classes. What remains decisive is documented approval of the specific service for the specific use case.
An NDA does not become relevant only when a document is sent
A confidentiality agreement does not protect only files labelled confidential. It may cover customer information, prices, technical details, negotiations, source code, operational data, and information from conversations. A prompt can contain precisely this information even when no attachment is uploaded.
Whether entering content into an external service is permissible depends on the specific NDA, data classification, customer contracts, internal policies, and the agreement with the provider. This is a legal and organisational assessment, not a property of the model. When in doubt, the business unit, IT security, data protection, or legal department should decide.
Four questions must be answered separately: may the information be disclosed under the NDA or contract? Are personal data processed lawfully for this purpose? Do the provider's contract, configuration, and retention practices permit this data flow? And are the security risks of the chosen tool under control? A positive answer to one question does not replace the others.
Four situations to check before prompting
First: an email or meeting record. Names, project numbers, delivery dates, and specific problems alone can be confidential or personal information.
Second: contracts, quotations, and customer documents. Uploading a PDF is not only a practical work step; it also discloses its contents to the selected service.
Third: source code, logs, and architecture diagrams. Even without customer data, they can reveal trade secrets, credentials, or vulnerabilities.
Fourth: connected services and shared chats. Connectors, shared links, or feedback features can expand the scope of the data and people affected.
Turning off training does not solve the approval problem
Privacy options matter, but they answer only part of the question. A setting may restrict the use of future conversations for model training. It still does not say whether your company has permitted sending this data to that service or whether the required contractual and retention rules apply.
A temporary chat is not blanket approval either. For example, OpenAI states that temporary chats in ChatGPT are not used for training and can be deleted from its systems after 30 days. That is a specific product feature, not a substitute for an NDA review or company-wide approval.[3]
Anonymization can reduce risk, but it is not blanket approval. Replacing names with placeholders is often insufficient when combinations of roles, locations, dates, project details, or customer details still make a person identifiable. Pseudonymized data remain personal data as long as re-identification using additional information is possible. Data should therefore be minimized or anonymized locally before transfer and checked for remaining identifiability. Even fully anonymized content can contain confidential information or trade secrets.[8][9]
A practical decision framework
- Personal or public content: a personal AI tool can be appropriate if company policy permits it.
- Work content: first check the purpose, data class, and service. Use only a tool approved by the company for this use case.
- Confidential, personal, or especially sensitive content: check the NDA or contract, data-protection requirements, provider agreement, and security controls. If explicit approval for the data flow is missing, do not enter the content.
- Unclear cases: stop before prompting and clarify approval with your manager, IT security, data protection, or legal department.
This framework is deliberately simple. It does not replace a contract review, but it prevents two common misconceptions: that a familiar personal account is automatically a permitted work channel, and that a business account automatically completes this assessment.
Governance must make safe use the easiest choice
A KPMG and University of Melbourne study reports that employees sometimes use AI at work in ways their employers have not authorised.[1] Where guardrails are unclear or hard to use, such use becomes harder to detect and manage. Good AI governance is therefore more than a policy on the intranet. It connects roles, data, systems, and workflows so that employees have a safe and productive option.[12][13][14]
This includes clearly named, easily accessible company tools, understandable data classification, and concrete examples of what may and may not be entered. Teams also need a fast path for questions. If approval arrives only after several emails, meetings, and weeks, the unofficial shortcut wins.
A process for every AI use case
The NIST AI Risk Management Framework describes a useful cycle: establish governance, map the context and risks of a use case, measure those risks, then manage and monitor them. For generative AI, NIST adds a dedicated risk-profile approach.[5][6]
As a practical implementation of this framework, every relevant AI use case should have a named owner, a clear purpose, a permitted data class, a reviewed provider and tool configuration, and criteria for human review. Before wide deployment, teams should test results with realistic but permissible examples. After deployment, monitoring, feedback, and a way to report errors or data incidents are needed.
Data governance begins before the first prompt
For business AI, it is not only the model in use that matters. Equally important are the data it can reach, the connected systems they come from, who approves access, and how long they are retained. ISO/IEC 42001 describes a management system for this with policies, responsibilities, risk treatment, and continual improvement.[7]
Once personal data are involved, organisations should also assess and document the purpose, legal basis, controller and processor roles, and consequences for affected people. The EDPB and the UK ICO stress that this assessment depends on the particular use case and data processing.[8][9]
Training and human review are operational controls
An approval is effective only when people know how to work with it. Employees must be able to identify which tools are allowed, which data may not be entered, when results need review, and where to report uncertainty or incidents. For providers and deployers within the scope of the AI Act, Article 4 requires a sufficient level of AI literacy; the European Commission emphasises context-specific knowledge building.[10]
Human review does not mean rewriting every answer word for word. It means that a person with subject-matter responsibility reviews the facts, conclusions, and consequences of an AI output before it influences a customer decision, publication, contractual position, or change in a system.
Security does not end with protecting the prompt
Approval of the data flow is only the first check. Once an approved AI tool is connected to company systems or used agentically, further risks arise: prompt injection, sensitive-information disclosure, insecure integrations, and manipulated data sources. The OWASP Top 10 for LLMs recommends addressing these risks across development, deployment, and operations.[11]
AI tools should therefore receive only the permissions they need for their task. Interfaces, connectors, approvals, and changes to data or systems need traceable logs and, for consequential actions, human approval.
Closing thought
At work, this is not only about a helpful text or a good summary. It is about whether a particular service may process particular data for a particular purpose under the applicable contracts, data-protection requirements, and security controls.
The best habit is therefore short and effective: before you paste or upload anything, check the content, purpose, tool, and approval. Minimise or anonymize data locally where permissible and appropriate. If the data flow remains unclear, stop before prompting.
Sources and notes
[1] KPMG and the University of Melbourne, Trust, attitudes and use of artificial intelligence: A global study 2025.
[2] Ruben Hassid, "How to Use Your Personal AI at Work", Substack, accessed 11 July 2026. Link
[3] OpenAI, "How your data is used to improve model performance" and "Data Controls FAQ". The documentation describes different provisions for personal and business offerings as well as data controls for temporary chats. Link
[4] Anthropic, "Is my data used for model training?" The documentation distinguishes consumer products from commercial offerings such as Claude for Work and the API. Link
[5] NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.
[6] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
[7] ISO/IEC, ISO/IEC 42001:2023 - Artificial intelligence management systems.
[8] European Data Protection Board, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models.
[9] Information Commissioner's Office, What are the accountability and governance implications of AI?
[10] European Commission, AI Literacy - Questions & Answers.
[11] OWASP Foundation, Top 10 for LLMs and GenAI Apps, 2025.
[12] Batool, Zowghi and Bano, AI governance: a systematic literature review, AI and Ethics, 2025.
[13] Birkstedt et al., AI governance: themes, knowledge gaps and future agendas, Internet Research, 2023.
[14] Schneider et al., Governance of Generative Artificial Intelligence for Companies, preprint, 2024.