How to legally secure an AI assistant with access to corporate systems?

Why an Assistant with System Access Poses a Different Risk Than a Regular Chat

The difference between a chat tool and an AI assistant connected to company systems lies in who decides on the data. In a regular chat, an employee enters text manually and chooses what leaves the company. An assistant with access to email, shared drives, accounting, or CRM searches for information on its own. It reads contracts, customer correspondence, and personnel files if it has the authorization. The company thus loses track of exactly what the tool has processed.

Technically, assistants are connected to systems via connectors. Increasingly, these are connectors built on the MCP (Model Context Protocol) standard, an open protocol through which a language model reads data from other applications and performs actions within them. Each connector expands the scope of data and actions available to the assistant. Whether this data also reaches the model provider depends on the architecture of the solution: where the connector runs, what data travels to the model, and what is stored in the logs. The company must therefore verify the data flows of each component, not just the model itself.

For company management, this leads to a simple consideration. Anyone who enables an assistant with blanket access suddenly exposes personal data of employees, customers, and suppliers, along with company know-how. The general opportunities and risks of deploying artificial intelligence in a company are summarized in the article on opportunities and legal challenges of artificial intelligence in business. This text focuses on contracts, personal data, and liability.

Who is Liable When an Assistant Makes a Mistake

The company that deployed the assistant is primarily liable for the processing of personal data. Under the General Data Protection Regulation (GDPR), the controller is the entity that determines the purposes and means of processing. A provider that processes data on behalf of the company and according to its instructions is typically a processor. If the assistant sends a sensitive document to the wrong recipient or exposes salaries to the entire company, the company must evaluate the incident, report it to the authority if necessary, and explain it to the affected individuals.

However, the provider does not remain without liability. As a processor, they must secure the data, follow the company's instructions, engage other processors only with its permission, and report security breaches to it. If they breach these obligations, the authority can impose a fine, and they are liable for damages to the affected individuals (Art. 82). If they use the data for their own purposes, such as training their model, the regulation considers them a controller for this processing (Art. 28(10)). However, this does not relieve the company of liability for selecting a provider without sufficient guarantees.

Towards customers and business partners, the company is liable for the assistant's outputs just as it would be for an employee's work. If the assistant prepares an incorrect offer or inserts wrong data into a contract, the company cannot defend itself by claiming the text was written by software. What matters is who approved and sent the output. The contracting partner deals with the company, not its tool, and will claim damages against it.

An employee who uses the assistant incorrectly has only limited liability to the company. Under Czech legislation, in the event of damage caused by negligence, the employer can demand a maximum of four and a half times the employee's average monthly earnings. This limitation does not apply if the employee caused the damage intentionally, while intoxicated, or under the influence of other addictive substances. If the company also contributed to the damage, for example by launching the assistant without rules, the employee will only compensate a proportional part. The company will thus bear most of the loss from leaked data.

This rule stems from the Czech Labor Code (Section 257) and in practice means that prevention is cheaper than subsequent enforcement. Whether the company recovers anything from the employee depends on whether they breached a work duty, acted culpably, and whether the damage was caused precisely by that breach. Internal guidelines, training, and technical access restrictions therefore reduce the risk of damage that the company cannot recover from anyone.

What a Contract with an AI Tool Provider Must Contain

The contract with the provider must meet the mandatory requirements of a data processing agreement (DPA) under the GDPR. The provider may process personal data only on documented instructions from the company and must commit its personnel to confidentiality. It may engage other processors only with prior authorization. Upon termination of the service, it must delete or return the data and allow the company to conduct audits (Art. 28(3)). The status of the provider is determined not by the title of the contract, but by who actually decides on the purpose and means of processing.

For an AI assistant, signing a standard data processing addendum without modifications is not enough. The contract should explicitly state whether the provider is allowed to use company inputs and outputs to train or improve its models. The law does not prescribe such a prohibition, but it is prudent to agree on it for confidential company data. Any permitted use for the provider's own purposes requires a separate legal assessment. The contract should also specify where the data is stored, from where the provider accesses it, and how long it retains query history and assistant activity logs.

The second area is the list of sub-processors. Large AI tool providers commonly use cloud providers and their own language model providers. The company should have the right to object to a change of sub-processor and, in extreme cases, terminate the contract. Under a general authorization, the provider must inform the company of any intended changes in advance (Art. 28(2)). For data transferred outside the European Economic Area, the legal basis for such a transfer must also be verified.

The third area is the provider's liability and its limitation. AI tool providers often limit liability for damages to the amount paid over a certain period. Such a limitation cannot apply to damage caused intentionally or through gross negligence. A court will disregard such a provision. The company should therefore negotiate a separate, higher limit for data leaks and breaches of confidentiality, as that is where the greatest damage occurs.

The boundary for limiting liability stems from the Czech Civil Code (Section 2898). It applies to B2B relationships, and the parties cannot deviate from it. It is advisable to supplement the contract with the provider with an obligation to report security incidents without undue delay, adequate liability insurance, and rules for data export and service termination.

From Pilot to Production: The Sequence of Steps

Implementing an assistant begins with an inventory of what it should have access to. The company identifies the systems, types of data, and groups of employees who will use the tool. It often turns out that the assistant needs a much smaller scope of data to work than what the provider offers by default. This inventory also serves as the basis for risk assessment and the contract with the provider.

The second step is assessing the risks of personal data processing. The company must verify whether the processing, given its nature, scope, context, and purposes, is likely to result in a high risk to the rights of individuals. If so, it must carry out a Data Protection Impact Assessment (DPIA) before launching: a written analysis describing the processing, its necessity, risks, and measures (Art. 35). For an assistant with broad access to personnel files or sensitive data, this will typically be necessary. For a tool limited to routine operational data, the obligation may not arise.

The third step is a pilot with a limited group of users and restricted access. During the pilot, the company monitors what data the assistant actually reads and what mistakes it makes. Only then does it decide on expansion. How such a pilot was conducted in a law firm, where data is subject to professional secrecy, is described in the article on our experience with implementing artificial intelligence at ARROWS.

The fourth step consists of internal guidelines and employee training. The guidelines specify which systems the assistant can access, what information employees must not input, and who reviews outputs before they are sent externally. Training also helps the company fulfill its obligation under the AI Act, which requires companies to take measures to promote AI literacy among personnel working with artificial intelligence.

After launch, the scope of access must be regularly reviewed, as providers add new connectors and features that are enabled automatically. What scope of access and what controls are appropriate for a specific assistant depends on which data it can access and whether its outputs go directly to customers. Therefore, the Czech legal team at ARROWS law firm assesses this individually for each deployment.

What Providers Commonly Offer and What Constitutes a Red Flag

Enterprise plans for AI tools usually include a data processing agreement and a commitment that the provider does not train on customer data. The difference between the consumer and enterprise versions of the same tool often lies precisely in these points. The company should therefore not allow employees to use private accounts for work purposes, even if it is the same product.

A red flag is a contract that only allows data training to be turned off. If the default state is consent and the company must actively opt-out in the settings, a single mistake by the account administrator is enough for data to be sent to the provider. Equally suspicious is a contract that refers to a list of sub-processors on a website but does not grant the company the right to object to changes.

Another signal is an unclear data retention period. Providers often retain conversation history and assistant activity logs for security and abuse detection. This may be justified, but the contract must state how long and who has access to these logs. If the provider does not answer this question in writing, the company has no way to demonstrate compliance with the storage limitation principle.

Companies that succeed in deployment separate the assistant's access rights from the user's rights. The assistant does not automatically get everything the employee sees, but only selected folders and systems. Actions that modify something, such as sending an email or editing a CRM record, must be approved by a human. This approach reduces the impact of an error as well as the impact of potential connector abuse by an attacker.

Where the Law Sets Boundaries: Personal Data, Artificial Intelligence, and Cybersecurity

The highest penalties apply to breaches of personal data protection. For violating the obligations of the controller and processor, which include the data processing agreement, security, and impact assessment, a fine of up to EUR 10 million or 2% of the global annual turnover can be imposed. For violating basic principles and the legal basis of processing, the ceiling is EUR 20 million or 4% of turnover, whichever is higher (Art. 83 of the GDPR).

A data leak via an AI assistant is a security breach that the company must report to the authority. The controller must report it to the Office for Personal Data Protection (ÚOOÚ) without undue delay and, where feasible, not later than 72 hours after having become aware of it. An exception is made if the breach is unlikely to result in a risk to the affected individuals (Art. 33). The provider must report the breach to the company without undue delay, which is why it is advisable to specify this obligation in the contract.

The AI Act

A company using an assistant is a deployer under the AI Act, meaning a user of the system, not its provider. From February 2025, they must take measures to ensure AI literacy among their employees (Art. 4). An amendment from 2026 explicitly states that the company does not have to guarantee a specific level of knowledge for every individual. A standard office assistant typically does not fall under high-risk systems. It can become one if the company uses it for purposes listed in Annex III, such as screening job applicants or evaluating employee performance.

The deadlines for high-risk systems were postponed by Regulation (EU) 2026/1744, the so-called Digital Omnibus, which entered into force on July 27, 2026. The obligations of deployers for systems in Annex III, such as human oversight and logging, will therefore apply from December 2, 2027. Classification depends on the specific intended use and the exceptions in Art. 6(3), such as for narrow procedural tasks. Violations carry a fine of up to EUR 15 million or 3% of turnover, with the lower of the two values applying to SMEs (Art. 99).

The relationship between the AI Act and personal data protection is discussed in more detail in the article on compliance with the AI Act and GDPR. If the assistant generates texts or images intended for the public, the obligation to label AI-generated content also comes into play. This obligation applies to public-facing content, not internal document work.

Cybersecurity

A company providing a regulated service under the Czech Cybersecurity Act must select providers and include security measure requirements in contracts with them if it implements or executes these measures through them (Section 13(5)). The Act is effective from November 1, 2025, and primarily affects medium and large enterprises in designated sectors, such as energy, manufacturing, or transport.

The mere connection of an AI assistant to systems that provide a regulated service does not automatically mean its provider is a supplier under this provision. However, if the assistant works with assets that the company has included in its cybersecurity management, it must include it in asset and risk management. Whether the company implements security measures through its provider depends on which systems the assistant has access to and what role these systems play in providing the service. This is assessed by the Prague-based legal team at ARROWS law firm before the company signs the contract with the provider.

Trade Secrets in the Hands of an AI Assistant

Trade secret protection is not automatic. Under Czech legislation, trade secrets consist only of information whose confidentiality the owner appropriately ensures (Section 504 of the Czech Civil Code). If a company allows price calculations, technical documentation, or customer lists into an AI tool without rules, it weakens this very characteristic. In a potential dispute with a competitor, the opposing party may then argue that the company itself failed to protect the information.

Courts assess confidentiality based on what the company actually does. The Czech Supreme Court, in ruling 23 Cdo 2736/2024, reiterated that a business must ensure confidentiality effectively, using both organizational and technical measures. In a dispute over design documentation, a company succeeded because it had guidelines with rules for borrowing and copying documentation. For an AI assistant, this same role is fulfilled by internal guidelines, access right restrictions, and a contractual prohibition on data training.

The company should therefore determine which categories of information do not belong in the assistant at all and which belong only in a tool with an enterprise contract. The list should be short and clear so that employees actually follow it. It should be supplemented by technical restrictions, such as excluding folders with manufacturing documentation from the reach of connectors. The combination of a rule and a technical measure is the best evidence in a subsequent dispute that the company protected its secret.

Five Mistakes Repeated When Implementing AI Assistants

The first mistake is launching the assistant with blanket access to all systems. The default settings of many tools copy user permissions, so the director's assistant sees the entire company. A single poorly phrased question is then enough for salaries or confidential meetings to appear in the output. Remedying an incident costs more than restricting access at the beginning.

The second mistake is using an employee's private account for company work. Consumer versions of tools are generally not covered by a data processing agreement, and the provider may use the data to improve its models. The company then loses control over the data and has no way to prove where it went. The solution is to provide employees with an enterprise tool and explicitly prohibit private accounts for work.

The third mistake is the lack of a risk assessment. Companies often postpone it until the deployment is complete, and if a DPIA was mandatory, they retroactively try to justify why they launched the processing without it. During an authority inspection, this looks like an admission that no one assessed the risks beforehand. The fourth mistake is accepting the provider's contract without checking the clauses on training and sub-processors.

The fifth mistake is sending the assistant's output externally without human review. An assistant can prepare an offer, a response to a complaint, or a contract summary in an instant. However, an error in such a document binds the company just as if it had been made by an employee. Which outputs must be reviewed by a human before sending and which can be sent automatically depends on whether they create an obligation towards a third party. Therefore, the Czech legal team at ARROWS law firm defines this boundary based on the company's specific processes.

Risks of an AI Assistant for a Company and How to Mitigate Them

Key Takeaways — Final Summary

An AI assistant connected to company systems poses a different risk than a regular chat tool because it searches for data on its own. The company that deployed it is primarily responsible for the purpose and manner of processing, the assistant's outputs, and any data leaks. The provider, as a processor, is responsible for its own obligations, and if it uses the data for itself, it becomes a controller for that processing. Legal protection therefore relies on the contract with the provider, risk assessment, and internal rules.

For management, the sequence of steps is crucial: first the contract and risk assessment, only then the blanket launch. A company that enables the assistant first and writes the rules retroactively cannot prove where the data went. During an authority inspection or in a dispute with a competitor, it will have no way to prove that it protected its data and trade secrets. Postponing these steps increases the risk of fines and damages that the company cannot recover from anyone.

Management should therefore decide on three things: which systems and data the assistant is allowed to read, which provider will meet the requirements of a data processing agreement without training on company data, and who in the company reviews outputs sent externally. Without these decisions, deploying the assistant remains an experiment on live data.

The Prague-based legal team at ARROWS law firm will review the contract with the AI tool provider and negotiate any missing points. We will assess processing risks and prepare a DPIA, internal guidelines for working with the assistant, and employee training. Contact us at consultation@arws.cz or explore our service IT and Software Law, Cybersecurity.