Artificial intelligence tools are quickly becoming part of everyday work in companies. Turning to them for a draft e-mail, a summary of a contract, an interpretation of a table or a piece of code is now ordinary behaviour. That convenience raises a new question, however: where does the information typed into the tool go, and who stays in control of it? Artificial intelligence and data security is a matter for managers as much as for technical teams. In this article we set out, in general terms, the points that companies should pay attention to. It is not legal advice, and expert support should be sought for specific situations.
The first question is the simplest one: what are employees typing into these tools? A paragraph pasted in for proofreading may contain a customer name, pricing, a project that has not been announced yet or a password. This kind of sharing is usually not malicious. It happens out of a wish to finish the job quickly and without anyone noticing.
It therefore helps for a company to classify the data it holds. Even a simple distinction gives direction:
When it is decided in advance which class of data may be entered into which tool, employees do not have to make the call on their own every time. The classification does not have to be perfect. What matters is that everyone knows the same distinction.
The data a customer entrusts to you is not yours, but the duty to protect it is. If the contract with the customer contains confidentiality provisions, transferring that data to a third party's system may breach the contract. An artificial intelligence tool that runs outside the company is, in most cases, exactly such a third party. Being open with the customer on this point also matters for preserving trust.
Personal data is even more sensitive. Personal data protection legislation imposes obligations regarding the purpose for which data is processed, to whom it is transferred and where it is stored. Using artificial intelligence does not remove these obligations. In practice, the safest approach is to remove or anonymise identifying information before it is entered into a tool and not to share data that is not needed at all. Where there is doubt, a legal adviser should be consulted.
Every tool has different terms regarding data. There may also be significant differences between the individual and business versions offered by the same provider. Before a tool is adopted for enterprise AI use, its terms of use and privacy notice should be read and answers sought to the following questions:
If these questions cannot be answered clearly, confidential data should not be entered into the tool. Because terms can change over time, they should be reviewed again at regular intervals. This assessment should not be left to a single employee. The IT and legal sides should look at it together.
A ban on its own often fails to deliver the expected result. If the tool is useful, employees may find a way to use it through personal accounts and without the company's knowledge, which removes oversight altogether. A healthier route is to identify approved tools and explain clearly how they are to be used.
A written AI usage policy does not need to be long. It serves its purpose if it states which tools may be used, which data may not be entered, how output is to be checked and who should be told when a mistake is noticed. The rules should be backed by short training and real-life examples. Once employees understand what is risky and why, following the rule becomes easier. The policy should have an owner and be updated as new tools come along.
Security concerns not only the data that goes into a tool but also the information that comes out of it. Large language models can produce information that is convincing and wrong. They may cite a source that does not exist, invent a figure or leave out an important condition when summarising a text.
Output should therefore be checked by someone who knows the subject, especially if it is going outside the company or will form the basis of a decision. Calculations should be redone, references verified at the source, and legal and financial texts shown to a specialist. The tool's answer should be treated as a draft that needs checking, not as established fact. The consequences of faulty output are borne by the company that uses the tool, not by the tool.
For companies that develop or commission software, code produced by code assistants is a separate topic. Such code may appear to work and still be lacking in terms of security. Unchecked user input, skipped authorisation checks and suggestions to use a component that is outdated or does not actually exist are among the AI security risks that may be encountered.
Code generated with artificial intelligence should go through the same review process as code written by hand. It should be read by another developer, tested and assessed from a security point of view. It is also important to make sure that the code sent to the tool does not contain passwords, access keys or customer data. For many companies the source code itself counts as a trade secret.
The risk grows when an artificial intelligence tool is connected to the company's systems, for example when it can access documents, e-mails or a database. In that case the tool's access should be limited to the narrowest scope it needs to do its job. If an employee can reach information through the tool that they are not authorised to see, the authorisation scheme has lost its purpose. It is also a known risk that instructions hidden inside an incoming document or e-mail can steer the tool in the wrong direction.
Where the tool can act on its own, for example when sending e-mail or changing records, human approval should be required for steps that cannot be undone. Keeping a record of who uses which tool and for what purpose matters as well. These records make it possible to understand what happened when a problem arises and help show whether the rules are being followed. Closing the tool accounts of employees who leave the company should not be forgotten either.
Despite every precaution, an employee may enter information into a tool that should not have been entered. In that situation the greatest risk is that the incident is kept quiet. An environment in which employees can report a mistake without hesitation allows the problem to be noticed early.
Who is to be notified, which steps are to be followed and who decides should all be settled in advance. If the shared information is a password or an access key, it should be changed immediately. If customer data or personal data is involved, the legal obligations should be assessed with expert support. Every incident should also be treated as an opportunity to review the rules and the training.
Benefiting from artificial intelligence tools and protecting data are not opposing goals. A company that classifies its data, chooses its tools deliberately, writes down its rules and checks the output can look after both. What matters is accepting that this is not a one-off task and that it has to be revisited as tools and terms change.
If you want control over where your data sits and who can access what, software designed around your own processes can make that control easier. You can take a look at BYK Yazılım's custom software service and request a quote by telling us about your needs.