Opportunities and risks of AI in business
When business leaders discuss AI, the conversation quickly reaches one question: Is the model trained on our data?
The concern is justified. But training is only part of the issue.
A provider may not use customer data for training. The data still has to be processed and may be logged. Training, processing, storage and access are different questions.
Without context, AI remains general
A language model can write and summarise well. It only knows the current customer case and the company’s valid process when it receives the necessary context.
The information for a customer enquiry might be spread across an email, an order, a service report and the warehouse system. AI could prepare the current status, open questions and proposed next step.
The employee no longer has to reconstruct the context from scratch.
The same connections also create risk. May the AI see only this case or all customer records? May it prepare a draft or send the message as well?
Value and risk arise in the same place: the AI’s access to working context.
AI does not create every risk from scratch
Much of a company’s data is already in the cloud. Questions about access, storage and data residency therefore predate AI. The Swiss Federal Data Protection and Information Commissioner states that a company remains responsible when a cloud provider processes data on its behalf.
Data residency is often a contractual commitment for specific services, not a technical boundary around every form of processing. It may not cover logs, backups or support access. In its data residency commitments, Microsoft therefore describes which data is stored in the selected region.
AI does not invent this issue. It can, however, find and combine information from several cloud systems much faster and derive new conclusions from it. An overly broad permission therefore becomes much more consequential.
This combination of an existing cloud landscape and new AI capabilities leads to five questions that should be answered before productive use.
1. What may the AI see?
Handling open service cases rarely requires access to the entire document archive. AI should only reach information that the responsible person is authorised to see and needs for the task.
In practice, permissions often reflect years of organisational change. Documents may have been shared with large groups, and AI can find them much faster than a person. Microsoft explicitly warns that incorrectly configured permissions for its AI connectors can expose sensitive content too broadly.
Before connecting a system, a company should therefore understand what data it contains, who owns it and whether its permissions are still correct.
2. What happens during an AI request, and what remains?
Before a request reaches the model, the application assembles its context from instructions, messages and connected systems. This becomes the input for inference, the calculation through which the model produces an answer.
Inference usually takes only a few seconds. During that time, the model keeps calculated values in a cache so that it does not have to process all preceding context again for every new piece of text. This direct calculation state is normally discarded after the request.
Some providers retain calculated parts of the input in a prompt cache so that similar requests can be answered faster and at lower cost. Depending on the service, this cache can remain for minutes or hours. There is no universal standard. These derived data should therefore be part of the risk assessment, even though they are not stored as a readable conversation.
Conversation histories, uploaded files, logs, search indexes and backups belong to the application around the model and can remain much longer. For each service, a company should know where inference takes place, what is temporarily cached and what is stored after the request.
Providers are unlikely to describe their infrastructure in full. Their commitments should still cover maximum retention, tenant isolation, processing location, training, logging and sub-processors. If the remaining risk is unacceptable, the affected data should be removed, anonymised or processed in a more controlled environment.
3. What can the AI infer from the data?
An often overlooked risk lies not in one piece of information but in the connection between several pieces.
A calendar entry, an absence and an email exchange may appear harmless on their own. Combined, they can produce a sensitive assumption that is wrong but still sounds convincing.
Companies must therefore consider which conclusions can emerge from several sources and where such assessments must not be used.
AI should not judge customers, employees or legal responsibility on the basis of incomplete information.
4. What may the AI do?
There is a significant difference between preparing a summary and performing an action.
AI can draft an email, change an order or trigger a purchase. Every additional permission increases both the possible value and the impact of an error.
A new use case should therefore begin with read access. AI shows its sources, marks gaps and proposes a next step. A person reviews the result and decides.
Only after this interaction works reliably should the company consider automating clearly bounded actions. The OWASP Foundation warns against giving an AI system more agency than its task requires.
5. Who reviews and improves the system?
Guardrails are more than a technical filter. They also define the task, valid sources, visible uncertainty and required approvals. It matters who may correct an error and how a proven correction becomes a new rule.
AI is not complete after a single acceptance test. Models, data and processes change. Trust develops through regular review, correction and adoption. The NIST AI Risk Management Framework likewise treats risk management as a continuous task with clear responsibilities and human oversight.
Safety and value belong together
A sound architecture separates persistent company knowledge from inference. Source systems, conversation histories and approved knowledge areas remain in an environment chosen by the company. The model receives only the context required for each request and remains replaceable computing capacity.
My whitepaper on reliable AI covers ownership, approval and controlled learning.
The sensible starting point is therefore not a company-wide assistant that can immediately see and do everything. It is one real, recurring workflow.
This is where I can help. Together with the responsible people, I examine a specific workflow. Which information is searched for today? Which systems contain it? How might AI access it? Which permissions, contracts and policies apply? Who reviews the result and approves changes?
On that basis, we can test past cases with clear review steps. This reveals early where AI helps and which rules or technical connections are still missing. The result is not dependence on one provider, but a sound basis for the next decisions.
For more than 20 years, I have worked on systems that must operate reliably in practice. Today I combine that experience with AI product development and vendor-independent AI architecture. My starting point is not the latest model, but the real work and the wider context in which it must operate.
This allows AI to become neither an uncontrolled experiment nor a tool that can do too little to be useful. It becomes reliable support for everyday work.