Using AI in Business in Compliance with the Law

The risk-based approach of the EU AI Act

The EU AI Act does not regulate “AI” as one uniform technology. The intended purpose, the specific use and the role of each party determine the obligations. Certain practices are prohibited. Subject to the statutory conditions, these include harmful manipulative uses, certain forms of social scoring and particular biometric practices. High-risk systems are subject to extensive requirements covering risk management, data quality, technical documentation, logging, human oversight, accuracy, robustness and cybersecurity.

A system cannot be classified from its product name alone. The AI Act identifies fields including employment, education, access to essential private or public services, critical infrastructure and certain biometric uses. A writing assistant used for internal drafts may fall outside those categories, while the same foundation model used as part of an automated candidate-screening process may trigger a much stricter classification. Each use case therefore needs its own description and assessment.

The company's role matters just as much. A business using a third-party system in accordance with its intended purpose will normally be a deployer. A company that places a system on the market under its own name, changes its intended purpose or makes a substantial modification may become a provider. Deployer controls are then no longer sufficient. White-label products, deep integrations and independently configured decision logic should be reviewed carefully against that boundary.

At the editorial cut-off on 21 July 2026, the timetable has to be described in two layers: the law currently in force and the amendment already adopted by the EU legislature. The AI Act was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. The general provisions, prohibited practices and Article 4 on AI literacy have applied since 2 February 2025. Governance rules and obligations for providers of general-purpose AI models have applied since 2 August 2025. Providers of such models placed on the market before that date generally have until 2 August 2027 to comply. Under the currently binding Article 113 AI Act, most remaining provisions, including the Article 50 transparency duties, apply from 2 August 2026. Under that version, the high-risk requirements for Annex III systems also start on that date, while Article 6(1) systems linked to regulated products in Annex I remain subject to the date of 2 August 2027.

The European Parliament and the Council have meanwhile adopted the Digital Omnibus on AI. The final text dated 8 July 2026 moves the high-risk requirements for Annex III systems to 2 December 2027 and those for product-related Annex I systems to 2 August 2028. It also gives providers of certain systems generating synthetic audio, image, video or text content that were already placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). The amendment becomes legally binding only on the third day after publication in the Official Journal. As of 21 July 2026, it had not yet been published there and had no final regulation number. Until it enters into force, the existing Article 113 remains the operative legal basis, although businesses may already take the adopted timetable into account for planning purposes.

Transparency does not operate in the same way for every AI-assisted output. Article 50 covers, among other matters, certain interactive systems and artificially generated or manipulated content. The European Commission published final guidelines on 20 July 2026. Businesses should derive notices and labelling from the relevant channel and their legal role rather than applying one generic label to every piece of AI-assisted content.

Data protection, copyright and trade secrets

The AI Act does not replace the GDPR. Whenever an AI system processes personal data, the company needs a valid legal basis and must comply with the principles in Article 5 GDPR. Purpose limitation, data minimisation, accuracy, storage limitation and security should be built into the use case. Special-category data, employee data and profiling require particular care. Where the system makes a decision based solely on automated processing that produces legal or similarly significant effects, Article 22 GDPR also needs to be assessed.

A data protection impact assessment is required under Article 35 GDPR where the planned processing is likely to result in a high risk to individuals' rights and freedoms. High-risk classification under the AI Act and a GDPR impact assessment are separate tests. A system that falls outside the AI Act's high-risk category may still require a DPIA. Conversely, meeting AI Act requirements does not create a lawful basis for processing personal data.

Generative AI raises copyright issues at several levels. For inputs, the company must determine whether protected text, images, software or databases may be processed. For outputs, the relevant questions include the level of human creative contribution, the provider's terms and possible infringement of third-party rights. A contractual statement that the customer may use the output is not a guarantee that no third-party rights are affected. External publication therefore requires substantive review and, for sensitive projects, legal review.

Trade secrets require separate safeguards. Under the German Trade Secrets Act, protection depends in part on reasonable secrecy measures. Entering internal calculations, source code, contract drafts or customer data into a public system without approval may make those measures harder to demonstrate. Whether protection is actually lost depends on the facts. A robust framework therefore combines technical settings, contractual confidentiality, graded data classifications and clear rules on which information may be entered into which system.

Third-party AI: contracts and allocation of roles

Most businesses obtain AI functions from external providers. That transfers part of the technical control, and responsibility for the company's own use remains with the business. Before contracting, the business should identify the product version, whether the system merely assists or prepares decisions, which data is transferred and whether the provider may unilaterally change the model, functionality or terms. For business-critical uses, advance notice of changes and access to a stable alternative version may be important.

The agreement should explain whether prompts, uploaded files, metadata and feedback are used for training, fine-tuning, abuse detection or product improvement. A “no training” commitment does not by itself answer how long data is retained, in which regions it is processed or which subprocessors can access it. Confidentiality, deletion, technical and organisational security measures, incident handling, audit information and support with regulator or data-subject requests belong in the same review.

Where the provider processes personal data on the company's behalf, an Article 28 GDPR agreement will generally be required. International transfers need a separate analysis. An EU server location does not necessarily exclude support or group access from third countries. The contract should also allocate responsibility for access requests, rectification, deletion and data export.

For AI Act compliance, deployers need information on the intended purpose, limitations, required inputs, performance characteristics and human-control options. High-risk uses require the statutory information and logs. Without adequate documentation, the business may be unable to satisfy its own monitoring and record-keeping duties. A marketing statement that a product is “AI Act compliant” is no substitute for use-case-specific documentation.

Liability should reflect the actual loss scenarios. These may include erroneous output, data protection breaches, third-party rights, downtime, unexpected model changes and discriminatory results. A broad provider disclaimer shifts those risks to the customer. Where standard terms are used, governing law and effective incorporation also need to be checked. For critical applications, indemnities, tiered caps, insurance evidence and exit support may be central points of negotiation.

A practical route to AI compliance

The process starts with a realistic inventory. It should capture centrally procured products, AI functions embedded in existing software and tools adopted informally by individual teams. For every use case, the business should record the purpose, users, input and output data, affected individuals, provider, integrations and the significance of the result for later decisions. Only that description allows a meaningful legal classification.

The next step is a proportionate assessment. Prohibited practices are excluded first, followed by the company's role and the system's risk category under the AI Act. Data protection, employment law, copyright, trade secrets and sector-specific rules are reviewed in parallel. A sensible approval process triggers deeper review for sensitive data, decisions about individuals and safety-related functions, while genuinely low-risk support tools can follow a lighter route.

An internal AI policy should not read as a collection of abstract prohibitions. It needs to state which systems are approved for which data classes, when results require professional review, how use is documented and where incidents are reported. Employees need examples from their own work and enough AI literacy to understand system limitations, possible errors and their continuing responsibility. Technical restrictions and access controls support these rules but do not replace them.

Finally, the framework needs ongoing review. Providers change models and terms, use cases expand beyond their initial purpose, and new guidance clarifies the AI Act. Periodic reviews, a documented change process and named owners keep the inventory and assessments current. Compliance can then develop with the technology rather than reacting only after an incident.