allclouds.pl

How much can an overly permissive AI policy cost?

How much can an overly permissive AI policy cost?

Let us start with a scenario familiar from the market. An employer wants to avoid the cost of corporate licences, so it allows employees to use private AI tools, provided they sign a statement that they do so “at their own risk”. The document goes into the personnel file and everyone feels safe.

Now consider what happens when that arrangement is put to the test. To speed up the preparation of a proposal, an employee pastes a client's contract and its attachments into a private chatbot. Personal data and commercial terms protected as trade secrets reach the provider's servers, where a consumer account may, by default, allow them to be used for model training. Several months later, the client learns about this following a security incident at the provider and brings a damages claim against the company. The President of Poland's Personal Data Protection Office asks about the legal basis for processing, while the certification body asks about the scope of the management system. The problem is that the signed statement is essentially ineffective under every relevant liability regime. In an unfavourable scenario, it can even work against the employer: it records the employer's knowledge and deliberate organisational decision to allow uncontrolled tools into the work process.

Under the Polish Labour Code, such a clause cannot be made effective

In relation to third parties, Article 120 § 1 of the Polish Labour Code applies. It provides that the employer alone is liable for damage caused by an employee in the performance of their employment duties. An injured client or business partner is not a party to the statement and is not bound by its terms. The employer is left with a claim for recovery against the employee, which, in cases of unintentional fault, is limited to three months' remuneration under Article 119. Consequently, where damage from a client data leak runs into hundreds of thousands of zlotys, the company covers the difference.

The internal relationship offers no better protection. A clause extending an employee's liability beyond the regime established by Articles 114–122 of the Labour Code is invalid under Article 18 § 2 because it is less favourable than employment law. The statutory provisions apply instead. This reflects the mandatory nature of the rules governing employees' financial liability, established in the case law of the Polish Supreme Court. There is also the principle that the employing entity bears the risks of its business: if the employer permits private tools precisely to avoid licence costs, it is making an organisational decision within its own economic and technical risk. Shifting the consequences of that decision to the employee undermines the structure of the employment relationship itself.

What the statement can actually provide is evidential and procedural value. It confirms that the employee knew the rules of use, which may influence the assessment of fault in a recovery claim or support disciplinary action or termination. Its limits still matter: dismissing an employee does not repair the damage; it is a sanction, not a safeguard. For contractors working under B2B arrangements, the Labour Code argument does not apply at all. That does not, however, remove the other parts of the calculation: the AI Act, GDPR and ISO standards apply to the organisation regardless of the form of engagement.

Under criminal law, the statement can evidence awareness of the risk

Criminal liability is personal and cannot be transferred by a civil-law statement. Where the conduct involves disclosure of confidential information under Article 266 of the Polish Criminal Code, infringement of a trade secret under Article 23 of the Act on Combating Unfair Competition, or unlawful personal data processing under Article 107 of the Personal Data Protection Act, liability falls on the person whose conduct fulfils the elements of the offence. Nor is the statement neutral for management. In extreme cases, organising work in a way that knowingly permits protected data to be entered into uncontrolled tools may be considered an omission by a person responsible for protecting secrets entrusted to the company. A document in which the employer “permits” this and requires a signature shifting responsibility may then serve as evidence that the risk was anticipated.

Under the AI Act, the employer is the deployer, not the employee

Under the AI Act, the statement provides no protective effect. The deployer is the entity using an AI system under its authority in a professional activity; the exclusion concerns personal, non-professional use only, under Article 3(4). If an employee uses a tool to perform work for the employer and with its consent, the employer is the deployer, regardless of whose name is on the account or who pays the subscription. The statement also confirms a constituent element of that status: formal authorisation to use the tool. Rather than removing responsibility, it establishes its basis. The “sign that you use it at your own risk” model also cannot replace the obligation to support staff AI literacy; the document itself may therefore become evidence of a failure to fulfil that obligation.

GDPR completes the picture

The employer remains the controller of personal data processed by employees in the employment context. Entering data into a private AI tool most often amounts to unauthorised disclosure without a legal basis or a data processing agreement under Article 28 GDPR, while also breaching the security requirements of Article 32. An employee's statement does not change the allocation of roles between controller and processor.

Organisational knowledge leaks quietly

There is another cost, perhaps the most important one, that no legal proceeding will fully capture: the systematic outflow of organisational knowledge into individual AI tools. The literature already has a name for this phenomenon: shadow AI, the unsanctioned use of AI tools outside organisational oversight (Silic, Silic, Kind-Trüller, 2025). Every prompt contains a fragment of know-how: how a proposal is priced, how a contract is structured, the arguments used in a dispute, or the description of an internal process. That knowledge accumulates in conversation histories on private accounts, beyond the organisation's reach. It cannot be searched, audited or handed over to a successor. When the employee leaves, the account leaves with them, along with months of accumulated context and organisational knowledge. Nor can anyone guarantee that the knowledge will be deleted from the tool: the service contract is between the provider and the employee who purchased the subscription, rather than the organisation. The organisation therefore has no contractual claim to deletion, audit rights, or even information about what is happening to its data.

The mechanism also works in the other direction. A private tool has no access to the organisation's full context: documentation, previous projects, standards and agreed arrangements. Each employee therefore builds their own partial context from scratch and maintains it independently. AI-assisted work becomes difficult to compare across employees and impossible to improve as an organisational process. The organisation pays twice: knowledge flows out, while internal synergy fails to develop. In a corporate environment, the relationship is reversed: shared organisational context supports everyone's work, and knowledge created through interactions with AI remains a company asset.

This model conflicts with ISO 27001 and ISO 42001

For a certified organisation, the effect is twofold. Both standards, based on the same harmonised structure, require the organisation to exercise control over externally provided processes, products and services relevant to its management system. An employee's private AI tool is precisely such an external service, but one that, by definition in this scenario, remains outside any oversight. The operating model itself therefore creates the nonconformity before specific controls are considered.

Under ISO/IEC 27001, a private AI tool is a cloud service processing organisational information entirely outside the information security management system: outside the asset inventory, without a contract with the provider or supplier security requirements, without cloud-service lifecycle management from acquisition to exit, and without control over information transfer. The employee's statement is neither a security control within the meaning of the standard nor an acceptance of residual risk. The latter requires the organisation's risk owner to approve the risk treatment plan. The statement instead records a risk that has been identified but not addressed. Rules for using tools do have a place in the standard as acceptable-use rules for assets, but they complement technical controls, such as data leakage prevention and event logging; they do not replace them. From an auditor's perspective, this can be a systemic nonconformity: an information-processing activity deliberately placed outside the system's scope.

The situation is similar under ISO/IEC 42001. The standard calls for AI systems within the management system to be documented, subject to impact assessment, used for their intended purpose within defined processes, and supervised, including oversight of suppliers, with assigned accountability and event recording during use. In the scenario described, a private tool meets none of those requirements: it is undocumented, has not undergone an impact assessment, has no assigned owner, and its logs remain on the employee's account, beyond the organisation's reach. The AI policy required by the standard can allow external tools, but this must be an organisational decision reflected in the management system and a risk treatment plan approved by designated management. It cannot be replaced by an employee's signature that simply takes the issue off the table. The “at your own risk” model contradicts the very purpose of an AI management system. In practice, the organisation risks a major nonconformity at its next surveillance audit and, if it is not resolved within the required period, suspension of its certificate. For clients contractually promised continued certification, this may also mean a breach of contract.

The calculation

On the “savings” side sits the cost of a corporate tool licence. On the risk side, the largest item is one that no penalty table captures: organisational know-how scattered across private accounts. Knowledge that could accumulate and work within the organisation's AI tool—proposal pricing methods, contract structures and arguments in disputes—leaves the organisation every day and can be lost permanently when an employee departs. Added to this are the loss of protection for trade secrets that are no longer confidential, compensation owed to business partners and litigation costs. Administrative penalties under the AI Act and GDPR complete the list. Comparing these items with the price of a licence makes clear that this is a deferred cost rather than a saving.

What to use instead of a liability statement

A statement can serve a useful purpose as part of an internal policy: instructions for use and a commitment to follow the rules, including categories of data that must not be entered. It cannot transfer to an employee responsibility that cannot be transferred under the regimes discussed above. Meaningful protection requires an architecture: a corporate tool instead of private tools, a layer controlling which data reaches which models, operation logging and measures supporting staff AI literacy under Article 4 of the AI Act. Rules without technical controls are a declaration; technical controls without rules lack direction. Both are needed together.

At allclouds.pl, we combine these elements. PROXY:AI controls data routing to models, while implementation is accompanied by documentation and AI Act-aligned training, within a management system certified, among other standards, to ISO/IEC 42001 and ISO/IEC 27001. Before someone in your organisation signs another “at your own risk” statement, let us discuss what it really means. If you are unsure where to start or how to use AI's full potential in your organisation, we also invite you to explore our training programmes.

Sources

Selected literature