The EU AI Act shapes how European businesses deploy AI systems in professional workflows. Small firms start by mapping who controls the system, what the workflow does, who sees the output, where a person must intervene, and what gets recorded. This guide turns that intake into practical questions and keeps legal advice boundaries explicit.
The EU AI Act assessment starts with the workflow: who controls the AI system, what it can do, who sees the output, where a human must intervene, and what evidence remains after an action.
Those questions determine whether the business needs to examine Article 50 transparency duties, high-risk deployer controls, provider instructions, or specialist advice. This guide turns that intake into an implementation map. It does not classify a business or provide legal advice.
For the underlying distinction between an AI model, an AI agent, and a business workflow, start with what is an AI agent. This guide focuses on the EU implementation questions that follow once a workflow is real.
How do you start with the workflow and your role?
An EU AI Act assessment starts with the system and the business relationship to it. “We use AI” is too broad to determine what the team should do next.
The European Commission's Article 50 FAQ defines a deployer as a natural or legal person, public authority, agency, or other body using an AI system under its authority, excluding personal non-professional activity. A freelancer using an AI system for regular professional work is a deployer under this definition. A legal person remains the deployer when contractors operate the system on its behalf and under its responsibility and control.
The role map should capture:
| Intake question | Evidence to record | Why it matters |
|---|---|---|
| Who operates the system? | Legal entity, team, contractor, or provider relationship | Separates personal experimentation from professional deployment |
| Under whose authority does the system run? | Account owner, contract, environment, and permissions | Establishes operational responsibility |
| What workflow does the system support? | Trigger, inputs, steps, outputs, and owner | Prevents a generic system label from hiding the real use |
| Who sees or receives the output? | Staff, customers, candidates, suppliers, or the public | Determines which transparency and risk questions need review |
| What may the system do? | Read, draft, route, write, send, delete, or approve | Defines the action boundary and possible harm |
| What happens when confidence is low? | Human review, escalation, pause, or fallback | Makes control operational rather than aspirational |
The map should name the existing tools. A workflow that reads Gmail, checks a CRM record, writes to Notion, and drafts a Slack notification has a different risk surface from a tool that answers a private question in a chat window. The model name alone does not describe the system.
The AI agent governance owner already explains permissions, change control, failure review, scope limits, and audit logs. This guide adds the EU source and role questions that should be answered before those controls are designed.
Which transparency questions does Article 50 create?
Article 50 is a set of specific transparency obligations, not a blanket rule that every internal AI document needs a label.
The European Commission published its Article 50 guidelines on 20 July 2026. The Commission states that the transparency obligations apply from 2 August 2026. The AI Act Service Desk and Commission FAQ describe several situations, including people interacting directly with an AI system, certain generated or manipulated content, and particular deployer uses involving biometric categorisation or emotion recognition.
The first compliance artifact is a workflow map.
The Article 50 intake should ask:
- Does a natural person interact directly with the system?
- Is the system clearly identified as AI at the first interaction or exposure?
- Does the system generate or manipulate audio, image, video, or text content?
- Is the content published to inform the public about a matter of public interest?
- Is the output a deepfake or another form of artificially generated content?
- Does a specific exception apply, such as human review and editorial responsibility?
- Is the obligation placed on the provider, the deployer, or both?
- What evidence shows how the business met the obligation?
The answer depends on the exact workflow. A private internal draft is not the same as a public article. A customer-facing agent is not the same as a background classification step. A generated image is not the same as a spreadsheet formula. The source text and current guidance must be read against the facts.
The AI Act Service Desk's Article 50 page contains a critical warning for anyone writing or relying on a summary. The page displays a Digital Omnibus disclaimer and says that its text has not yet been updated to reflect those amendments. The page locates the provision and its structure. It is not permission to publish an undated legal conclusion.
The Commission's Article 50 guidelines and Article 50 FAQ are the current practical starting point. The published page shows the retrieval date, links the official text, and identifies points that require a fresh check.
What separate control layer applies to high-risk deployers?
High-risk deployer duties are not interchangeable with Article 50 transparency questions. The workflow must first establish whether the relevant high-risk provisions apply.
The AI Act Service Desk's Article 26 summary describes high-risk deployer responsibilities including use according to instructions, competent human oversight, monitoring, input-data responsibilities, log retention, and risk or incident handling. The page also says its summary is not legally binding. The final legal baseline must therefore use the current official text and guidance.
The Article 26 intake should record:
| Control question | Practical implementation record |
|---|---|
| Who has competent human oversight? | Named person, authority, training, and review point |
| What instructions govern use? | Provider documentation, approved purpose, and local workflow rules |
| What input data does the deployer control? | Source systems, data owner, relevance check, and access boundary |
| How is operation monitored? | Quality sample, incident signal, review frequency, and owner |
| What happens when a risk appears? | Pause condition, provider notification, authority route, and internal escalation |
| What gets logged? | Input/output context, tool action, approval, change, error, and time |
| Who is affected at work? | Worker notice, representative process, or employment-specific review where relevant |
The how to stay in control of an AI agent owner covers the operating distinction between permissions, approval gates, and autonomy. The EU AI Act intake does not replace that design. It gives the design a current legal question to answer.
Human oversight does not mean asking a person to glance at every output while the system remains opaque. The person needs the competence, authority, support, and information to intervene. A review button that appears after an irreversible action is not meaningful oversight.
The same principle applies to monitoring. A green process status cannot prove that the output is correct. The team should define a baseline, sample outputs, record manual corrections, and pause when a serious failure appears. Is your AI agent actually working? describes the distinction between an agent that runs and one that produces an acceptable result.
How do you turn legal language into implementation controls?
Legal text becomes operational to an operator when every relevant question has an owner, a control, and a record.
A policy can say “use AI responsibly.” A deployer map identifies who can act, what the system can touch, what a person must review, and what gets logged.
The implementation map should connect the source questions to the actual workflow:
- Define the authority. Record the legal entity, provider relationship, account owner, environment, and contractor responsibilities.
- Define the workflow. Document the trigger, systems, inputs, steps, outputs, and intended business result.
- Define the action ceiling. Separate reading, drafting, routing, writing, sending, deleting, and approving. Give the agent only the access needed for the approved scope.
- Define the human point. Name who reviews, what they see, what authority they have, and which actions always wait for approval.
- Define the evidence. Record the source documentation, configuration, test cases, approvals, changes, exceptions, and incidents.
- Define the stop rule. State when the workflow pauses, who is notified, and how the team investigates before resuming.
This is where implementation work differs from a PDF policy. The system should enforce the important boundary. If the agent cannot send an external message until a person approves it, the integration and action path should block the send. The requirement should not live only in a prompt or an employee's memory.
The control map should cover the tools already in use. Gmail needs an access boundary. A CRM needs a field and write rule. Slack needs a channel and audience rule. Notion needs a workspace boundary. A model provider needs a data and retention review. Each control should answer what the system may do and who can change that scope.
The map should also capture the failure path. An ambiguous customer request, a missing CRM record, a duplicate write, or an unsafe instruction should not become a silent success. The system should flag the exception, preserve enough context for review, and stop the affected action when the blast radius is unclear.
When does the intake stop?
An implementation intake cannot determine every legal question. This guide names the stopping points rather than disguising uncertainty as a score.
Escalate for current legal or specialist review when:
- the workflow may fall into a high-risk use area;
- the system affects employment, access to essential services, or a person's rights;
- the business is unsure whether it is a provider, deployer, or another actor;
- an AI output is published to inform the public;
- biometric categorisation or emotion recognition is involved;
- the provider's instructions conflict with the planned use;
- the data contains sensitive personal information or unclear provenance;
- the business cannot assign a competent human overseer;
- a serious incident or material risk has occurred;
- the current official text or guidance has changed.
The guide never tells a founder that a low score means “compliant.” A low-friction intake reveals what the project knows, what it must verify, and where another professional needs to decide.
The what approval workflows do in an AI agent system owner explains how an action can wait for a human decision. Use that implementation owner for approval mechanics, then return to the legal source for the scope question. Internal links should clarify ownership rather than create a chain of generic references.
How do you keep the map current?
The EU AI Act map is a maintained project record, not a one-time checklist.
Keep these fields visible:
- publication date;
- last source review date;
- official sources consulted;
- the workflow scope covered;
- a visible legal-advice boundary;
- an owner for source review;
- the events that trigger a refresh.
Refresh the map when the Commission publishes new guidance, the AI Office changes an interpretation, the Regulation is amended, the provider changes its instructions, or the business changes the workflow. A change to the model is not the only reason to review. A new integration, output audience, data source, or approval path can change the operational question.
The Commission's current framework page says the AI Act became applicable on 2 August 2026. The same page records Article 50 transparency rules from that date and transition dates of 2 December 2027 for high-risk use cases in sensitive areas and 2 August 2028 for high-risk systems embedded in regulated products after the AI Omnibus. The Article 50 guidance was published on 20 July 2026. These dates belong in the research record, not in an evergreen sentence that will silently age.
An implementation partner maps systems, permissions, approvals, logging, and testing. A partner cannot turn a generic checklist into legal certainty. The responsible sequence is source review, workflow mapping, control design, specialist escalation where needed, and a measured launch.
Frequently asked questions
What is a deployer under the EU AI Act?
A deployer is a natural or legal person, public authority, agency, or other body using an AI system under its authority for professional activity. The applicable obligations depend on the system, use, role, and relevant part of the Act.
Does using an AI agent make a small business a provider?
Using an AI system under a business's authority raises deployer questions, but use does not automatically make every business a provider. The provider or deployer role depends on the system, the facts, and how the business operates or places it into service.
Does Article 50 apply to every internal AI-generated document?
No. Article 50 covers specific situations involving direct interaction, certain generated or manipulated content, and particular deployer uses. The current official text and guidance must be checked against the workflow and audience.
Is an EU AI Act checklist legal advice?
No. A checklist organizes implementation questions and evidence. It cannot determine legal classification, replace current official sources, or replace qualified legal advice.
Notes
- European Commission, AI Act regulatory framework, accessed August 10, 2026 and last updated August 3, 2026. Used for the current application timeline, risk framework, transition dates, and implementation context.
- European Commission, Guidelines on transparency obligations, published July 20, 2026. Used for the Article 50 scope and application date.
- European Commission, Article 50 FAQ, accessed August 10, 2026. Used for provider and deployer definitions and practical questions.
- AI Act Service Desk, Article 26, accessed August 10, 2026. Used for the deployer-duty summary and the official-text cross-check.
- AI Act Service Desk, Article 50, accessed August 10, 2026. Used for the article structure, transparency situations, exceptions, and Digital Omnibus disclaimer.
- The decision map, examples, implementation controls, and escalation boundaries in this draft are YardWork work-product. They are educational and must not be presented as legal advice or certification.