AI and law – what companies need to know?

Implementing AI in a company increasingly means entering the area of specific legal requirements, rather than merely product “innovation”. The key risks relate to whether a given system falls within the scope of the AI Act at all, which risk class it belongs to, and whether it processes personal data in line with the GDPR. In practice, the greatest difficulties arise where AI really affects people: in recruitment, customer scoring, fraud detection or decision automation. At the same time, the importance of transparency is growing (e.g. chatbots and synthetic content) as is security, because AI opens up new attack vectors such as prompt injection or leaks via prompts. In this article, you get a structured map of the obligations and actions worth planning so you can present evidence of compliance during an inspection, audit or dispute. Read on if you want to translate regulation into concrete steps on the product, IT, legal and compliance side.

EU regulations and AI risk classification: what does the AI Act mean for your company?

The AI Act means that a company must determine whether the system it uses is “AI” within the meaning of the rules and which risk class it belongs to. The Act covers systems that generate outputs (e.g. forecasts, recommendations, content) influencing decisions or the environment, even when the AI is “wrapped” in a standard application. If you use LLMs (e.g. GPT-4/4.1, Claude, Mistral) to assess candidates, score customers, detect fraud or automate decisions, in practice you will most often fall within the scope of the AI Act. It is this risk classification that determines whether you are dealing with prohibited practices, a high-risk system, transparency obligations, or minimal risk.

The most important thing is to quickly distinguish high-risk cases from uses where transparency obligations dominate. A tool for CV pre-screening in recruitment will usually be “high risk”, while a chatbot for FAQs on a website most often requires informing the user that they are talking to AI. If the system is high risk, you must treat it like compliance for a regulated product: requirements, tests, an audit trail and model update procedures. Practical requirements include, among other things, risk management, data quality, technical documentation, event logging, control over input/output data, human oversight and testing.

The AI Act also prohibits certain practices, including some forms of manipulation, exploiting users’ vulnerabilities and selected biometric scenarios, depending on the context and the exceptions provided for by law. If marketing or the product is based on “hidden” influence over decisions in a way that may lead to significant harm, the function needs to be redesigned or robust safeguards and reliable evidence of compliance need to be implemented. Synthetic content is a separate category. The user often has the right to know that they are interacting with AI, as well as that they are viewing or listening to a deepfake. If you generate a voiceover or video “to a human standard”, it is worth considering labels, metadata and publication policies to reduce the risk of misleading people and violating personal rights.

When you use general-purpose models (GPAI) as a service (e.g. Azure OpenAI, Google Vertex AI, Anthropic), the provider takes over some of the obligations, but you remain responsible for ensuring the implementation complies with the law (e.g. GDPR, employment law, consumer law). In practice, it is sensible to expect clear information from the provider about the model’s limitations, testing and intended purpose, as well as to establish who maintains logging and who handles incident response. The AI Act provides for high administrative fines, including up to EUR 35 million or 7% of global turnover for breaches related to prohibited practices, and lower thresholds for other obligations (e.g. EUR 15 million or 3%). The board should be able to answer questions about the risk profile, the evidence of compliance collected and the ability to switch off a function within 24 hours if the regulator or the market requires it.

• Start with an inventory of AI uses and risk classification (prohibited / high risk / transparency / minimal risk).
• For high-risk systems, plan a process covering: risk management, data quality, documentation, logging, human oversight and testing, as well as model change procedures.
• Implement transparency obligations where the user interacts with AI or consumes synthetic content (e.g. deepfakes).
• Establish the division of roles with the GPAI model provider. Include information about limitations, logging and incident response, while maintaining responsibility on the implementation side.

1. 01Is it AI?Generates outputs affecting decisions.
2. 02Risk classKey to obligations.
3. 03LLMs and decisionsOften fall within the Act.
4. 04Risk levelsProhibited, High, Transparent.
5. 05DistinctionHigh risk vs. Transparency.

The key is to quickly understand the risk classification in order to determine the level of obligations and avoid prohibited practices.

Data protection and privacy: what actions are required in AI projects?

AI projects require actions that ensure data processing complies with the GDPR, from the appropriate legal basis, through risk assessment, to security and the exercise of data subjects’ rights. Consent is not always the best solution. Often, a more suitable basis is a contract (Article 6(1)(b)) or legitimate interests (Article 6(1)(f)) after a balancing test, especially where the user does not have any real freedom to refuse (e.g. an employee). If the model uses data concerning health, opinions, biometrics or origin, you enter special categories of data (Article 9 GDPR) and need exceptions and strong safeguards. Equally important is profiling and the risk of breaching Article 22 GDPR when AI makes fully automated decisions with significant effects.

DPIA (impact assessment) is usually necessary when AI is associated with a high risk to individuals’ rights and freedoms, for example in monitoring, scoring, recruitment, customer behaviour analysis or when combining multiple data sources. In a DPIA, you describe data flows, scenarios of potential harm (e.g. discrimination, breach, incorrect refusal of service), risk-mitigating measures, and a plan for testing and monitoring after deployment. If you cannot clearly state where the data comes from, how long you retain it and how you minimise harm, that usually means the project is not yet ready for an audit or inspection. GDPR also requires data minimisation: you need to be able to justify every feature and every dataset, because AI pipelines tend to “devour” everything that is in the system.

In practice, retention rules and supplier control are key: set retention periods for prompt logs and outputs (e.g. 30–90 days), and for training data keep a register of sources and versions so that you can delete or disable data in the event of an objection or a detected error. If you transfer personal data to a model supplier (SaaS/API), in most cases it acts as a processor and you need a data processing agreement (DPA) with instructions, a list of subprocessors, information about data location and security measures. Companies should ask directly whether prompt data is used for training, whether it is logged, how long it is retained, and how deletion requests are handled. If data is sent outside the EEA (e.g. to the USA), you need a transfer mechanism under Chapter V of the GDPR (e.g. SCCs) and a Transfer Impact Assessment, especially in the case of sensitive data.

AI security requires additional controls because vectors such as data leaks via prompts, prompt injection, uncontrolled plugins and retrieval from unverified sources (RAG) appear. A sensible minimum is data masking (e.g. PII redaction), restricting permissions, encryption (TLS 1.2+), as well as security testing specific to LLMs (e.g. jailbreak and data extraction scenarios). Users may also request access, deletion or rectification of data and ask “why did the model assess me like that?”, so you need a response procedure and the technical capability to act at least on source data, logs and RAG indexes. When the model was trained on personal data, handling requests is more difficult — which is why limiting such training, segmenting datasets and the ability to retrain or apply unlearning mechanisms where feasible are crucial.

Intellectual property and AI-generated content: what do you need to know?

In AI projects, it is worth establishing the rules for using sources straight away, as well as who “owns” the output of the model and on what basis. Mere “public availability” of material does not mean it can be used for training. Copyright, licences (e.g. CC-BY, CC-BY-SA, GPL) and website terms and conditions must be checked. In the EU, TDM (text and data mining) exceptions exist, but they can be subject to conditions, and rights holders may apply opt-outs. That is why you need a process for verifying sources and collecting evidence of lawful use. In practice, IP risk rises fastest where AI generates marketing content, graphics or code “for production”.

The rights to AI output depend on the human creative contribution and local copyright rules, so it is not worth assuming in advance that “everything is ours”. Pure generation without a creative element may not be protected as a “work”, which is why companies often secure this contractually (e.g. through assignment of rights from employees and contractors to derivative works and through rules for using the tools). At the same time, you need to watch for similarity to third-party materials, because generative models can produce fragments similar to existing content, especially in code and graphics. The most sensible approach is to treat AI as support, not as an “automated rights factory”, and to build in similarity checks and clear rules on responsibility for publication.

• Verify the legality of training sources (rights, licences, website terms, opt-out) and archive evidence of the verification carried out.
• Implement plagiarism and similarity checks: for text (e.g. Copyscape), for code (e.g. GitHub Advanced Security + licence scanning, FOSSA/Black Duck), for images. reverse image search and control of asset sources.
• Set rules for AI-generated code: the same review as for human-written code and automatic licence and component scanning before deployment, to reduce copyleft risk (e.g. GPL).
• Protect the brand and image: treat a generated “logo” as a draft and carry out a design and conflict search (e.g. in EUIPO) before use.

IP risks also include trade secrets and NDAs, because pasting non-public documents, customer data or a roadmap into prompts may mean losing control over the information. The company policy should clearly indicate which data classes are prohibited in prompts, while also preferring tools with a “no training/no retention” mode and tenant isolation (e.g. Microsoft Copilot with the appropriate settings). Deepfake and voice generation are a separate area. impersonating “a known person” may infringe personality rights and personal rights, and in the case of recordings. neighbouring rights of performers. If you use an AI voice-over artist, make sure you have a licence for the voice model, the required consents and labels where the recipient could otherwise be misled.

1. 01Source and licence verificationCheck copyright, licences and terms. Public availability is not consent.
2. 02TDM exceptions in the EU (opt-out)Text & data mining with conditions, possible objection (opt-out) by rights holders.
3. 03Ownership of output and human inputRights depend on the level of creative human involvement in the process.

IP risk requires a proactive process for verifying sources and defining rights to the output of the AI model.

Product liability and security: how do you ensure compliance of AI systems?

Compliance of AI systems is built by combining oversight of decisions, auditability, and quality and safety tests carried out throughout the product life cycle. When AI makes a mistake (e.g. an incorrect credit assessment, a false fraud accusation, poor medical advice), the customer will usually speak to your organisation, not the model provider, so you need clear rules on usage limits and complaint handling. Disclaimers can also help where they are permitted, but they will not replace control over the process. Design AI so that the decision can be corrected quickly, and the function can be safely restricted, before an error turns into a legal or reputational incident.

In practice, auditability means you can demonstrate: which model and version, which input data, which security rules and which tests were performed. Keep a change log (model/versioning), quality metrics (e.g. precision/recall for fraud detection) and logs of prompts and responses, in a manner compliant with the GDPR and the adopted retention period. Quality is not fixed once and for all — you need to monitor bias (e.g. uneven error rates across groups) and drift (a decline in quality over time), as well as carry out pre-deployment and periodic tests. For LLMs, red-teaming is additionally used to test for jailbreak, prompt injection and data exfiltration from context.

“Human-in-the-loop” is a genuine operational requirement wherever a decision materially affects an individual (e.g. refusal of a service, dismissal, reduction in salary). The human in the loop must not be a façade — they must have the competence and the real ability to change the outcome, and the workflow should show the rationale, data sources and level of confidence. From an IT security perspective, the key question is whether the model can carry out an unauthorised action — it can, if the agent has access to tools (e.g. sending emails, transfers, CRM). Therefore, restrict permissions (principle of least privilege), add validation and action limits, and in RAG filter sources to avoid malicious instructions being injected into the knowledge base.

Evidence of due care is also strengthened by standards and frameworks such as ISO/IEC 42001, ISO/IEC 23894 and NIST AI RMF, which help structure AI risk management (although they are not a “legal requirement”). At the same time, you need an incident response plan: data disclosure in the model’s output, generation of discriminatory content or unauthorised action performed by an agent. Such a plan includes immediate restriction of the function (kill switch), securing logs, assessing a GDPR breach (72h to notify the UODO, if applicable), and communication to customers plus corrective actions. In regulated sectors, additional rules apply (e.g. banking, health), and for critical processes you must also take into account NIS2/DORA-type requirements on cyber resilience, incident reporting and vendor management.

Contracts with AI providers and employment law: how to negotiate and implement AI?

AI is safest to deploy when, already at the contract stage with the provider and in HR policies, you clearly define roles, responsibilities and usage restrictions. In practice, what often proves decisive is whether the LLM provider processes data solely on your instructions, or also uses it for its own purposes, because this affects the classification of roles (processor vs controller/joint controller) and the scope of information obligations. At the same time, it is worth assuming that a service outage may halt customer support or sales processes, so operational terms have a direct business impact. This section is about translating “AI in the product” into concrete clauses and procedures on the procurement, legal, IT and HR sides.

In contracts with LLM providers, consistently negotiate a ban on using your data for training, log retention (e.g. 0–30 days), place of processing, list of sub-processors, and the right to audit or reports (SOC 2 Type II/ISO 27001). In addition, agree SLAs for availability and incident response times, because without them it is difficult to control operational and reputational risk. On the GDPR side, start with a map of roles and processing purposes, so you do not make the typical mistake of treating the provider as a processor when in fact it acts as a controller or joint controller. Such a map determines not only the documents, but also who is liable towards the data subjects and the regulator.

In employment law, AI requires transparency when it supports recruitment, performance assessment or employee monitoring. Candidates and employees will ask about the criteria and the possibility of appeal, so you need control over AI’s influence on decisions and a way to verify the results. Ensure compliance with the Labour Code (including monitoring rules and information duties), as well as minimising the processing of “excessive” data. A red flag example is emotion analysis from video without a solid legal basis and justification.

To limit “shadow AI”, introduce internal regulations and policies: a list of approved tools, classification of data for prompts, and a requirement for anonymisation/PII redaction. Without such a framework, employees may paste customer data into public chatbots, increasing the risk of breaches and loss of trade secrets. It is also good practice to provide training on prompt injection and the safe use of RAG, because these are real vectors for mistakes and leaks when working with LLMs. Such a deployment should work in day-to-day operations: it should clearly indicate what is allowed, who approves exceptions, and how to report incidents or concerns.

1. 01Clearly define roles and HR rulesDefine responsibilities and restrictions
2. 02Qualification of data processing rolesDetermine the controller and processor
3. 03Warn against using your dataNegotiate a ban on training the provider’s models
4. 04Take operational conditions into accountSafeguard continuity of service

Deploy AI safely: The key is clear contracts, precise HR rules and protecting your own data.

How to prepare your organisation for the AI Act timetable?

It is best to prepare the organisation for the AI Act timetable in advance by creating an inventory of AI use cases, a risk classification and a plan to close gaps in compliance evidence. The most common mistake is leaving it until the “last minute”, because then there is no time to organise data, documentation, tests and owner responsibilities. This is not only about formally meeting obligations, but also about being able to show exactly what is working in the product, how it is supervised and how the company responds to risk. Such a plan should cover both product deployments and the use of generative tools in marketing, sales or HR.

The minimum set of actions to start with is an inventory of AI systems and a risk analysis, including an assessment of the impact on individuals. The next step is a generative AI usage policy, which standardises practices across teams and limits ad hoc use of tools without oversight. At the same time, it is worth planning an “evidence pack” for key deployments: documentation, tests, logs and contracts. It is this complete set of elements that most often determines whether an organisation passes an inspection or audit without firefighting.

Preparing for the AI Act also means assigning owners and carrying out periodic reviews so that risk is managed as a process, not a one-off project. In practice, it is a good idea to decide straight away which deployments are business-critical and which gaps need to be closed first, rather than trying to “describe everything at once”. This order also makes it easier to work with model and tool providers, because you know in advance what information and commitments you need in order to keep the deployment compliant. As a result, the regulatory timetable translates into a real work plan for product, IT, legal and compliance.

What are the penalties and financial risks associated with the AI Act?

Penalties and financial risks under the AI Act stem primarily from administrative fines depending on the type of infringement. For breaches related to prohibited AI practices, the AI Act provides for fines of up to EUR 35 million or 7% of global turnover. Lower thresholds are предусмотрены for other obligations, for example EUR 15 million or 3%. In practice, this means that the same AI function may carry radically different financial exposure depending on the risk class and the implementation method.

From a board perspective, the key question is whether the company can provide evidence of compliance and switch off the function within 24 hours if the regulator or the market requires it. This shifts the emphasis from “do we have AI” to “do we control it”: the risk profile, documented decisions, response process and the mechanism for rapidly restricting the system’s operation. In practice, a lack of such readiness increases not only the risk of a fine, but also the operating costs associated with emergency product redesign and incident handling.

AI security: how do you protect data and manage risk?

AI security is based on combining data controls, restricting permissions and dedicated LLM testing, because these models open up new attack vectors. The minimum standard is data masking (e.g. PII redaction), privilege reduction, encryption (TLS 1.2+) and tests for resistance to jailbreaks and data extraction. It is also worth taking account of threats such as prompt injection, uncontrolled plugins or retrieving content from unverified sources in RAG. In practice, security is not limited to “encryption” alone, but covers the entire workflow: from input data to publishing the response.

If an LLM agent has access to tools (e.g. sending emails, transfers or CRM), restrict permissions in line with the principle of least privilege and add validation and action limits. In RAG solutions, filter sources so that malicious instructions cannot be injected into the knowledge base and then “carried over” into the model’s response. On the model provider side, establish whether prompt data is logged, how long it is retained and whether it can be used for training, because these parameters affect both risk and the company’s obligations.

Risk management also requires a ready incident procedure for cases where AI discloses data in a response, generates discriminatory content or performs an unauthorised action. The response plan should include immediate restriction of the function (kill switch), securing logs and assessing whether a GDPR breach has occurred (if necessary, reporting to UODO within 72 hours). In practice, it is crucial to establish in advance who is responsible for logging and who leads corrective actions, especially when you use models as a service. This approach combines IT security, privacy requirements and operational continuity into one process.