The EU AI Act: what to check before using AI in your business

01Describe the actual use before classifying the risk

Create an inventory of the AI your business uses or supplies. Include purchased assistants, embedded software features, customer-facing tools, and internal experiments with business data. Record the purpose, users, affected people, inputs, outputs, supplier, version, and actions the system can take.

Under Article 2 of the AI Act, scope includes providers bringing systems or general-purpose models to the EU market, EU deployers, and certain non-EU providers and deployers where outputs are used in the EU. Location alone does not resolve the question.

The Commission's risk overview distinguishes prohibited practices, high-risk uses, transparency duties, and lower-risk applications. Employment and certain essential-service decisions are examples requiring careful classification. Neither the underlying model's brand nor a claim that a human approves the result determines the complete classification.

Compare two workflows using similar technology. Drafting a routine support response needs controls for accuracy, data, and publication. Using an output to evaluate applicants affects a different decision and different people. Keep this distinction in procurement: an approval for one purpose should not silently authorize every use the product technically supports.

Screen for prohibited practices first. Existing prohibitions already apply; additional prohibitions introduced by the Omnibus have their own application date. A project should not proceed because someone assumes a later high-risk deadline suspends every other rule. Record uncertain cases and obtain a reasoned assessment before deployment.

02Work out whether you use a system or provide one

A deployer uses an AI system under its authority. A provider develops, or has developed, a system or model and brings it to market or puts the system into service under its own name or trademark. Your company can have different roles for different products. A software supplier's involvement does not automatically settle your role.

Document who controls the intended purpose, branding, system design, and changes. A company integrating AI into its own product needs a more careful assessment than a team using an existing tool as instructed. Particular modifications or changes of purpose can create provider responsibilities, especially for high-risk systems. Review the actual arrangement before relying on the supplier's label.

Distinguish the general-purpose model from the application built around it. A model supplier's documentation does not describe every downstream workflow, permission, retrieval source, or decision your application introduces. Ask for the information relevant to your system and define what your implementation partner must supply.

Keep a responsibility record with the business owner, technical operator, supplier contact, and reviewer. Name who approves a new use, changes permissions, updates notices, investigates problems, and suspends operation. Contracts should support that practical arrangement rather than leaving each party to assume the other handles it.

03Use the amended dates and the correct transition

The high-risk dates above are enacted changes, confirmed in the Commission's Omnibus announcement and Regulation (EU) 2026/1744. They should not be described as a pending proposal or used to defer unrelated requirements.

Article 111(4) gives providers of generating systems placed on the market before 2 August 2026 until 2 December 2026 for Article 50(2). It is not a blanket grace period for transparency or deployers. The separate high-risk transition in Article 111(2) depends on prior placement and significant design changes; do not assume every existing system is permanently exempt.

Keep dates attached to a responsibility and task. A timeline without a classified system, role, and owner is difficult to act on. Review it when the law, system purpose, or implementation changes, and verify any transition before building a launch decision around it.

04Design transparency into the real interaction

The Commission's current transparency guidance separates provider and deployer duties. Providers handle direct-interaction information and machine-readable marking within the applicable provisions. Deployers have particular duties for emotion recognition, biometric categorization, deepfakes, and certain public-interest text. There are defined exceptions; this is not a rule to put the same label on every AI-assisted sentence.

For a customer assistant, check what a person sees at the actual point of interaction and whether the applicable duty and obviousness exception are addressed. Do not bury useful information in a distant policy page. Also explain the assistant's practical limits, how to reach a person, and which actions require confirmation.

For generated images, audio, video, and published text, review the intended content and distribution. Machine-readable marking by a provider and visible disclosure by a deployer are different tasks. Check whether editing, exporting, translation, or a platform upload removes information the chosen process depends on.

Article 50 includes a public-interest text exception involving human review or editorial control and editorial responsibility. Do not generalize that to every content duty. Review the specific paragraph, the finished asset, and the publishing workflow rather than assuming one human approval clears every transparency question.

05Support AI literacy with training people can use

The amended Article 4 requires providers and deployers to take measures supporting AI literacy for relevant staff and people acting on their behalf, considering knowledge and context. It does not require guaranteeing a specific level for each individual. Simplification does not abolish the duty.

Make training specific to the task. A support team needs to recognize invented answers, unsafe disclosure, escalation cases, and actions requiring review. A developer integrating a model needs to understand permissions, untrusted inputs, evaluation, and failure handling. Someone approving employment-related use needs the context of that decision and the review process.

Practice with realistic mistakes and exceptions. Show an answer that sounds convincing but is unsupported, a request containing confidential information, and a tool action that exceeds the intended permission. Ask staff to identify the correct response and whom to contact. A generic presentation is less useful than a short exercise tied to their daily work.

Keep a practical record of the measures, materials, roles, and follow-up. Update it when the system or task changes. Avoid treating a certificate as proof that every future decision will be correct. Give people a usable route to ask questions, report an error, and pause an uncertain action.

06Check data, supplier evidence, and meaningful oversight

Assess privacy separately. Where the GDPR applies, AI use does not remove requirements around lawful processing, purpose, minimization, security, and applicable safeguards. Other jurisdictions may impose different obligations. Map what enters prompts, retrieved documents, logs, and supplier services.

Ask what the supplier does with inputs and outputs, which retention and training settings are available, who can access the information, and what happens when you delete it. Review the agreement and the actual configuration. A product's general privacy page may not describe the plan, deployment, or subprocessor arrangement you are purchasing.

Request evidence relevant to the intended use: instructions and limits, version information, evaluation context, failure cases, monitoring, and change notifications. For a potentially high-risk system, obtain a specific legal and technical review of the applicable evidence and duties. Do not substitute a broad marketing declaration for a documented assessment.

Give a reviewer enough information, time, authority, and competence to reject or correct the result. A button marked approve can become a routine click when staff cannot inspect the relevant evidence. Define escalation and fallback behavior, including which actions stop when the model, retrieval source, or monitoring fails.

Limit consequential actions and sensitive access to the approved workflow. Our business AI agent guide covers the practical action boundary, while data security in custom software provides wider security context. Neither a legal classification nor a human review eliminates ordinary application risks.

07Turn the review into an operating process

1. Inventory the use. Record purpose, system, users, affected people, data, outputs, actions, and ownership.
2. Assess scope and role. Review EU connections, prohibited practices, classification, responsibilities, dates, and any claimed transition.
3. Verify the operation. Check supplier evidence, notices, data settings, review authority, permissions, staff preparation, and fallback behavior.
4. Approve and monitor. Document the approved purpose, unresolved limits, incident route, change controls, and the next review.

Begin with a use whose boundaries your team can explain and operate. Do not copy its approval to a new purpose without review. A manageable record of decisions is more useful than a policy that permits every tool broadly but gives nobody responsibility for a customer-facing error or an unapproved decision.

08Questions about the EU AI Act and business use