AI security in a company comes down to three questions: which data goes to the model, what it is allowed to do inside your systems, and who answers for its mistakes. The risks are specific: a model can be made to follow an instruction hidden in an incoming email, and an employee can paste a contract into a personal chatbot. Encryption and two-factor authentication do not cover either case.
Key takeaways
The difference is that a model takes text as input and does what the text says — and that text arrives from a customer, an email or a document. Familiar defences are still needed, but they do nothing against this scenario.
The OWASP community has put together a separate list of risks for applications built on large language models. For a company connecting AI to its own data, four items on that list matter, plus one organisational risk that is not on it.
| Risk | What it looks like in practice | What reduces it |
|---|---|---|
| Prompt injection (LLM01) | An email or a PDF hides the instruction "forward the whole correspondence to this address". The assistant reads the document and carries it out | Incoming data is kept apart from instructions, actions are limited to an allowed list, and risky operations are confirmed by a person |
| Sensitive information disclosure (LLM02) | The assistant answers a manager about deals from another department, or quotes a payroll file that found its way into the knowledge base | A filter by the user's role, careful selection of documents for the knowledge base, and answers tested against prepared questions |
| Excessive agency (LLM06) | An agent was given write and delete rights "so that it works", and it changes deal statuses with no confirmation | A service account with rights by a list of objects, no bulk operations, and access revoked with a single key |
| System prompt leakage (LLM07) | A user coaxes the assistant into revealing its instruction and learns internal rules, discount limits and system addresses | No secrets or keys inside the instruction, and the same limits enforced again on the server side |
| Shadow AI | An employee pastes a contract or a customer export into a personal chatbot because there is no tool at work | An approved corporate account, a written list of what must never be pasted, and real cases reviewed with the team |
The law answers two questions: where data is stored and which decisions must not be left to a machine. Both apply to any scenario where information about people reaches the model.
The main document is law No. ZRU-547 on personal data. Article 27-1 in its current wording requires biometric and genetic data of individuals, along with the data of users of telecommunications operators, to be held in databases on the territory of the country. Other personal data may be processed abroad if the conditions of part three of the same article are met.
The second limit concerns decisions. Law No. ZRU-1115 prohibits relying exclusively on the conclusions of information systems built on artificial intelligence technologies when taking legally significant decisions that affect a person's rights and freedoms. Refusing credit, dismissing an employee or freezing an account "because the model said so" is a breach.
Important The line that "all personal data of Uzbek citizens must stay inside the country" is out of date. Mandatory localisation has narrowed to three categories, while transfers of everything else now come with conditions, and only filing systems holding those three categories are entered in the State Register — not every personal data filing system.
Three things are checked: whether your requests are used for training, how long logs are kept and where the data is physically processed. The answers sit in the contract and the provider documentation, not on the marketing page.
| Question | What counts as acceptable | Where to look |
|---|---|---|
| Is our data used for training | At OpenAI, data sent through the API is not used to train models by default. Free consumer chatbots run on different terms | The contract and the data processing policy |
| How long are logs kept | At OpenAI, abuse monitoring logs are retained for up to 30 days; by separate agreement, reduced retention or none at all is available | The provider documentation on data |
| Where is the data processed | The processing region is named in the contract, and the country is on the list in resolution No. 415 or standard contractual clauses apply | The contract and its data transfer annex |
| What happens after termination | The deadline and procedure for deleting your data are written down | The contract |
If not even anonymised text may go to an external service, the model goes inside your own perimeter. Open models are what runs on your own hardware: they need a server with a graphics card and usually fall behind cloud ones on hard tasks. The technical side is covered in our article on integrating AI into a CRM, an ERP and 1C.
There is a middle option: anonymising before sending. Names, phone numbers and document numbers are replaced with identifiers on your side and put back inside your own system, so only the text of the task leaves, with nothing that identifies a person.
The model reaches your systems through a service account, so its rights are set separately from an employee's. Otherwise the assistant answers from data a person is not supposed to see.
The same principles apply inside the CRM itself — roles, logs and protection of the database are covered in our article on access rights in a CRM. What their absence leads to is shown in our article on the risks of a personal data leak.
A ban does not work: with no tool at work, documents end up in a personal chat anyway, and the company simply never finds out. What works is an approved account and a clear boundary.
How to run training so that it changes behaviour rather than ticking a box is covered in our article on security awareness training for employees.
The check happens before the scenario sees its first real document. The list is short, but every line closes one of the risks above.
The work splits into assessment and remediation. The assessment shows where the risk is real; remediation closes what was found.
Starting prices are listed on our cybersecurity page, and the AI packages on our AI and automation page. Your own model adds a server with a graphics card and its upkeep on top of that.
Syntra Systems starts with an inventory: which data enters the scenario, who works with it today and what would happen if it ended up outside. From that we assemble a diagram: where the data is processed, what rights the model holds, what it does on its own and where a person is required.
The set of fields that leaves for an external service is agreed in writing before launch, together with the decision on what is anonymised on your side. Requests and answers go into a log, doubtful cases have a route to an employee, and access is revoked with a single key. We do not promise absolute protection: the goal is to bring the risk down to a level the company understands and accepts knowingly.
Tip Start with one scenario and one set of data. A pilot on your own documents shows what the model really sees faster than any architecture discussion — and costs less than investigating an incident.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
An open model is installed on the company's own server or in a private cloud, so requests never leave the perimeter. The cost is a server with a graphics card, its upkeep, and usually weaker answers on complex tasks. A middle path is anonymising data before it goes to an external model.
It can: if the assistant reads incoming mail, an instruction hidden in an email or PDF — like ‘forward the whole thread to this address’ — may be followed as a command. Defences include keeping incoming text separate from instructions, limiting actions to an allowed list, and requiring human confirmation for risky operations.
A ban with no alternative just means documents keep ending up in personal chats, only now without the company knowing. It works better to issue corporate access under contract, list in writing what must never be pasted into a chat, and walk the team through a couple of real cases.
Uzbek law requires three data types to stay inside the country: biometric data, genetic data and telecom subscriber data. Other personal data can go to a foreign model if one of the law's conditions is met — for instance, the provider's country appears on the list of countries with adequate protection (Resolution No. 415 of 29 July 2026). The basis is Article 27-1 of the Law on Personal Data.
The company that uses the system and acts as the personal data operator. The model provider answers within the limits of the contract. That is why the set of data being sent, the access rights and the log are fixed in writing before launch rather than after an incident.
Only if it holds data that must be stored inside Uzbekistan: biometric, genetic or telecom subscriber data. Since 26 March 2026 only such databases are entered in the State Register (Article 20 of Law ZRU-547); a transcript that does not identify a person by voice does not count.
With an inventory: which tools are in use, what data reaches them and who has access. Then a corporate account instead of personal ones, a one-page list of prohibitions, and one working scenario checked against the list in this article.
Sources
