Article 3 AI Act definitions: which role decides what you owe
Article 3 of Regulation (EU) 2024/1689 defines the terms that decide which obligations apply to your organization, so the first task for a compliance lead is to decide, for each AI system, whether you are a provider, a deployer or another kind of operator. Until that role is settled, no duty under the Act can be scoped, budgeted or assigned. The definitions are read together: an *AI system* is defined in Article 3(1) as a machine-based system with varying levels of autonomy that infers from its input how to generate outputs such as predictions, content, recommendations or decisions. Article 3(3) makes a provider anyone who develops a system or general-purpose model, or has one developed, and places it on the market or puts it into service under its own name or trademark, free or paid. Article 3(4) makes a deployer anyone using a system under its authority outside a personal non-professional activity, and Article 3(8) groups providers, product manufacturers, deployers, authorised representatives, importers and distributors as operators.
Three other terms change the analysis once the role is known. *Placing on the market* and *putting into service* determine when a provider's duties begin, and *intended purpose* (the use the provider specifies) fixes the scope against which risk is assessed. Under Article 3(23), a *substantial modification* is a post-market change not foreseen in the initial conformity assessment that affects high-risk compliance or changes the intended purpose, and it can turn a deployer that alters a system into its provider. Article 3(49) defines a *serious incident* by its effects, including death or serious harm to health, serious and irreversible disruption of critical infrastructure, and infringement of fundamental rights obligations under Union law. The Article has 70 numbered definitions after Regulation (EU) 2026/1744 added SME and small mid-cap enterprise definitions and amended the safety component definition, so confirm the current wording in the consolidated text before relying on any single point.
Role confusion is the usual hard part because an organization often holds several roles at once: it buys a vendor model, fine-tunes it, wraps it in its own interface and uses it for hiring or credit decisions. Each role carries separate duties, and the substantial modification test can shift the balance. Create a written role determination for each system in your inventory, record the intended purpose and the modifications made, and have legal review any case where a vendor's documentation and your own use do not match. The non-binding Commission guidelines on the AI system definition, published on 6 February 2025, help decide whether software in scope is an AI system at all, and that answer should be documented before the role question is tackled.
Which systems and teams the definitions catch
Article 3 decides scope before any obligation applies. The cards below cover the questions that most often change who owes what: whether software is an AI system at all, which role the organization holds, whether it has put a system into service, and where reach extends beyond the EU.
Does the software meet the AI system test
Article 3(1) asks whether a machine-based system runs with some autonomy, may adapt after deployment, and infers from its input how to produce outputs such as predictions, content, recommendations or decisions. Rule-based automation that only executes fixed logic usually falls outside the definition. Check each system against all of these elements, and record the reasoning, because the Commission's non-binding guidelines on the AI system definition, published on 6 February 2025, are the reference point an assessor will expect you to use.
Built, commissioned or only used
Article 3(3) makes a provider anyone who develops a system or model, or has one developed, and then places it on the market or puts it into service under its own name or trademark. Commissioning a vendor build under your brand can make you the provider even though a third party wrote the code. A team that only configures and runs a purchased product usually sits in the deployer role instead. Confirm, for each system, who wrote it, whose name appears on it, and who first put it into use.
Placing on the market or putting into service
Placing on the market means making a system available to the EU market for the first time. Putting into service covers supplying it for first use, or using it internally for your own purposes. An internal tool built and used by your own staff is still a placed or serviced system, so the provider route can apply even when nothing is sold. Document the date and the entity that first made the system available or in use, because that date and entity anchor the obligations that follow.
Personal non-professional use exclusion
Article 3(4) excludes use of an AI system in a personal non-professional activity from the deployer definition. This exclusion protects individuals, not organizations. A tool an employee uses for team work, a customer-facing assistant, or an internal screening model all fall in professional activity, however informal they feel. Do not rely on this exclusion for any business tool without a written analysis that names the activity and the person using it.
Substantial modification can change the role
Under Article 3(23), a substantial modification is a change made after placing on the market that was not foreseen in the initial conformity assessment and that affects high-risk compliance or changes the intended purpose. A deployer that retrains, repurposes or materially alters a vendor system can therefore take on provider duties. Track changes to model, data, purpose and user population against the vendor's documented intended purpose, and get the vendor's written position before you modify anything.
Non-EU firms reached through Article 2
Article 2 applies the Act to non-EU providers placing systems or models on the EU market, and to non-EU providers and deployers whose AI output is used in the EU. A company headquartered outside the Union can therefore owe obligations if its system's output reaches EU users or decisions. Map where outputs are consumed, not only where the company or servers sit, and confirm with counsel how Article 2 applies to your specific offering.
How an assessor tests role decisions
This table compares each Article 3 decision an assessor examines, the test applied, the records requested and the findings that most often lead to a reclassification. Read each row as a question: does the written role match how the system is built, bought, controlled and named in practice?
| Decision | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| AI system (Article 3(1)) | Whether the system is machine-based, works with varying autonomy, infers outputs from inputs, and can influence environments, read against the Commission's guidelines of 6 February 2025 | System description, architecture and inference logic, documented reasoning for the definition decision, and any rules-based alternatives considered | Scope decisions that rely on the label rather than the technical reasoning, or conventional software classed as AI without analysis |
| Provider role (Article 3(3)) | Whether the organization develops the system or has it developed, and places it on the market or puts it into service under its own name or trademark | Contracts with developers, product naming and branding records, release and go-live records, and the entity named in documentation | A vendor product rebranded internally but treated as a deployer, or a customization that makes the company the provider without recognition |
| Deployer role (Article 3(4)) | Whether the organization uses a system under its authority outside a personal non-professional activity | Owner assignments, usage policies, configuration records and the internal approval trail for each use | Shadow use by business units that the central register does not show, or deployers who assume the vendor carries all duties |
| Operator grouping (Article 3(8)) | Whether every entity in the chain (provider, product manufacturer, deployer, authorized representative, importer, distributor) is identified and its duties assigned | Supply chain map, role matrix per system, and the contractual allocation of duties between parties | Importers or distributors not recognized as such, or no single owner for duties that span two operators |
| Substantial modification (Article 3(23)) | Whether a change after market placement affects high-risk compliance or alters the intended purpose assessed, and whether the role changed as a result | Change log, impact assessments for each material change, re-assessment decisions and sign-off by the accountable owner | Model retraining, new data sources or new use cases recorded as routine maintenance without a documented decision |
| Serious incident (Article 3(49)) | Whether the organization applies the four harm categories in the definition consistently when it reviews malfunctions and reports them | Incident register, triage criteria, severity decisions with reasons, and records of escalations to the relevant authority | Incidents closed as minor without a documented test against the definition, or no link between incident records and the role decision |
| Intended purpose link | Whether the stated intended purpose matches the actual use, marketing claims and instructions for use that the organization issued | Intended purpose statement, product literature, user instructions and records of uses outside the stated purpose | Purpose statements drafted narrowly to avoid high-risk status while the system is sold or used for broader decisions |
| Decision record quality | Whether each role and definition decision is dated, owned, reviewed and linked to the facts it relies on | Decision memos with named approver, review date, facts relied on and the version of the system assessed | Undated or unsigned classifications, decisions that predate the system they describe, or no reassessment after change |
How to build a defensible role and system classification
This sequence turns the Article 3 definitions into a written record that shows, for each AI system, whether it is an AI system at all, who holds which role, what its intended purpose is, when a change counts as substantial, and what counts as a serious incident. Each step produces an artifact an assessor can read.
Inventory candidate AI systems
List every software, model or service that might fall under the Article 3(1) definition, including vendor products, internal builds and tools embedded in other applications. Use your existing asset records as a starting point, such as a CMDB or an inventory export from GLPI or Wazuh, then add the AI components those tools do not show. Output: a candidate register with one row per system, owner and location. Done when every system the business runs or plans to run has a row, including ones marked as out of scope for now.
Test each candidate against the Article 3(1) elements
For each row, record whether it is machine-based, designed to operate with varying levels of autonomy, able to adapt after deployment, and infers from its input how to generate outputs that can influence environments. Mark each element as met, not met or unclear, with the reasoning. Use the Commission's non-binding guidelines on the AI system definition as the reference for borderline cases, and have legal or compliance sign off on any system marked unclear. Output: a signed definition test per system, which is the document that shows why a tool was or was not treated as an AI system.
Record who develops, places on the market or uses each system
For each system that passes the definition test, document the actors: who developed it or had it developed, under whose name or trademark it is placed on the market or put into service, and who uses it under their authority. Note whether the organization builds, buys, customizes, or hosts the system, and whether any non-EU party is involved. Output: an actor map per system that lists the developer, the placing party and the user, with contract references for each relationship. Confirm these facts with procurement and engineering, since they drive the role assignment in the next step.
Map each system to a provider, deployer or other operator role
Apply the Article 3 role definitions to the actor map. A provider develops or has developed a system and places it on the market or puts it into service under its own name or trademark. A deployer uses it under its authority, except in a personal non-professional activity. Other operators include product manufacturers, authorised representatives, importers and distributors. An organization can hold more than one role for the same system, such as a deployer of a vendor tool that it has customized under its own name. Output: a role assignment with the legal reasoning, reviewed against the actor map and the contracts.
Document the intended purpose as the provider states it
Obtain and record the intended purpose the provider documents in its instructions for use, technical documentation or contract, including the context and conditions of use. Compare that statement with how your teams actually use the system. Where the internal use differs from the documented purpose, flag it for review, because the purpose the system is put to can change which obligations apply. Output: an intended purpose record per system with its source document and version, plus a list of any gaps between documented and actual use.
Set substantial modification triggers
Define in writing which changes after placing on the market would count as a substantial modification under Article 3(23): a change not foreseen in the initial conformity assessment that affects compliance with the high-risk requirements or changes the assessed intended purpose. Translate that into internal triggers such as model replacement, retraining on new data, new use cases, new user populations or changes to human oversight. Output: a change-control rule per system that routes each proposed change to a classification review before release.
Adopt a serious incident definition the team can apply
Write an internal test based on Article 3(49): an incident or malfunction that leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, or serious harm to property or the environment. Add the escalation owner, the first-hour checklist and the evidence to preserve, such as traces, logs and version identifiers. Test the definition against two or three past incidents or tabletop scenarios, marked as illustrative, to confirm that staff classify them consistently. Output: an approved incident definition and a short decision tree that the on-call team can use.
Approve and version the classification record
Bring the candidate register, definition tests, actor maps, role assignments, intended purposes, modification triggers and incident definition into one approved record. Assign an owner, record the approver and the date, and set a review trigger tied to changes in the system, the contracts or the Act itself. Output: a versioned classification record that an internal auditor, a market surveillance authority or an independent assessor can follow from each system back to its source evidence. Confirm with counsel whether the record should also be reviewed against the 2026 amendments for the systems in scope.
Evidence that shows the role decisions hold
What records prove an AI system is classified correctly under Article 3?
The core record is a system inventory with an Article 3(1) assessment for each entry, showing why each tool or model does or does not meet the definition of an AI system. Each assessment should name the system, its owner, the date of review, the inputs it takes, and the reasoning against the definition's elements: machine-based operation, varying autonomy, adaptation after deployment, and inference from input to outputs that can influence environments. Keep the reasoning short but specific enough that a reviewer can disagree with a point and find the place to push back. Where a system is judged out of scope, record that conclusion as deliberately as an in-scope one, because a rule-based tool wrongly treated as an AI system or the reverse both create compliance gaps. Review entries when a system's architecture, vendor or use changes, and at least at each planned audit cycle. The organization owns this inventory and its conclusions. An independent auditor tests whether the reasoning is sound and whether the inventory is complete, but does not make the classification for you.
How should an organization keep a role register for AI providers and deployers?
A role register records, for each AI system, which operator roles the organization holds under Article 3, such as provider, deployer, importer, distributor or authorised representative, and the basis for that conclusion. The provider test turns on developing or having developed a system and placing it on the market or putting it into service under your own name or trademark, so the register should state who built the system, who sold or released it, and under whose name it runs. The deployer test turns on using a system under your authority outside personal non-professional use, so the register should note who controls its use. Record cases where one organization holds two roles, such as a company that fine-tunes a vendor model and then offers it to customers. Store the register in a controlled location with a named owner, and update it when contracts, vendors or product branding change. Ask your auditor or counsel to confirm how the roles apply to your own arrangements, since the register only holds the decisions, not the legal opinion behind them.
What should an intended purpose statement contain for an AI system?
An intended purpose statement describes the use the provider designed the system for, as set out in the provider's documentation, instructions and marketing. Article 3 links intended purpose to the high-risk analysis and to the question of whether a later change counts as a substantial modification, so the statement must be specific. Include the task the system performs, the users it is meant for, the populations and settings it is meant for, the decisions or outputs it supports, and the uses it is not meant for. Vague wording such as general business support gives an assessor nothing to test. Keep the statement in version control alongside the technical documentation, and link each version to the conformity assessment or internal review that relied on it. When a deployer uses a system for a purpose the provider excluded, record that as a separate finding rather than editing the statement to fit. Confirm with your legal or quality team how the provider's stated purpose and your own deployment interact before you rely on either.
How do you keep a substantial modification log current?
A substantial modification log records each change made to an AI system after it was placed on the market, with an assessment of whether the change is a substantial modification under Article 3(23). That definition covers a change not foreseen in the initial conformity assessment that either affects compliance with the high-risk requirements or changes the intended purpose assessed. For each entry, record the date, the change, who approved it, the requirements it could touch, the intended purpose it could alter, and the decision with its reasoning. Routine updates such as security patches still need a line in the log, even when the conclusion is that they are not substantial. Connect the log to your change management tooling so that model retraining, prompt changes, new data sources and new integrations trigger a review. Keep the log for the life of the system and make it available to an auditor. The organization decides and documents each change; the auditor samples entries and checks whether the reasoning matches the system's actual behavior.
What criteria should a serious incident note contain under Article 3(49)?
A serious incident criteria note sets out how your organization will recognize a serious incident as defined in Article 3(49), so that staff do not have to interpret the definition during an event. The definition covers an incident or malfunction that leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, or serious harm to property or the environment. The note should map each category to the systems in your inventory, list the signals that would prompt escalation, name who decides whether an event qualifies, and state the timing and recipients for reporting internally and to the relevant authorities. Test the note through tabletop exercises and record the results. Legal counsel should confirm the reporting obligations that apply to your roles, because the note itself only documents how your team reaches the decision. Review it after each real incident and after any change to your role register.
What records show which Commission guidelines an organization used?
Records of the Commission guidelines show which non-binding interpretive material your organization relied on when making its definition decisions. The Commission published guidelines on the AI system definition on 6 February 2025, alongside its guidelines on prohibited AI practices. Keep a register listing each guideline document you used, its version and publication date as you accessed it, the decisions it informed, and the person who reviewed it. Note where your reading differs from the guidelines and explain why, since an auditor will expect a reasoned position rather than silent divergence. Because guidance can be updated and the Act itself was amended in 2026, store copies of the versions you relied on and check for later updates at each review cycle. Keep in mind that guidelines are not binding law, so the record should show your interpretation of the Act's text. Ask counsel to confirm which guidance is current before each audit.
Who owns these role records, and what does an independent auditor test?
Your organization owns every record in this set: the inventory, role register, intended purpose statements, modification log, incident criteria note and guideline register. The people accountable for each decision should be named in the records and should keep them current between audits. An implementation partner such as DeployOpen can help design the templates, set up the storage and workflows, and prepare evidence from your systems, but the partner does not decide your role classifications or sign off on them. An independent auditor or assessor tests whether the records exist, whether they are complete, whether the reasoning holds against the Act's text and your actual systems, and whether the change and review processes operate as described. Ask any consultant to show how each record is kept current and who signs off on it, and confirm with your auditor which of these records they will sample before the engagement starts.
What classifying AI systems under Article 3 costs
This table compares the cost components of deciding which Article 3 roles and definitions apply to each AI system, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for requesting quotes: no figures are given because none were supplied, so ask each provider to price every row separately.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it and how to reduce it |
|---|---|---|---|
| Internal legal and compliance time | Your legal, compliance and product staff, who test each system against the Article 3 definitions and record the role held | One-time for the first inventory, then recurring with each new system | Number of systems and unclear product boundaries drive it up. Reduce it by agreeing one written role test before reviewing systems. |
| Engineering time to document system behavior | Your engineers or platform team, who describe autonomy, adaptation, inputs and outputs against the Article 3(1) definition | One-time per system, recurring when behavior changes | Model count, undocumented third-party components and weak logging drive it up. Reduce it with existing architecture diagrams and trace data. |
| Inventory tooling | Software licences or self-hosted tool operation, plus staff who maintain the asset records | Often recurring (licences or hosting), with a one-time setup | Vendor dependence and the depth of asset data drive it up. Ask whether the tool captures AI components or only general assets, and whether it is self-hosted. |
| External legal or consultant review | External counsel or a consultant who reviews role decisions, especially for provider versus deployer questions | Usually one-time per review, sometimes recurring for retained advice | Number of borderline cases and the need for a written opinion drive it up. Limit external review to disputed systems and get the scope in writing. |
| Upkeep when systems change | Your product, engineering and compliance teams, who reassess role and substantial modification after updates | Recurring | Change rate, frequency of model swaps and new markets drive it up. Reduce it with a change trigger in the release process that prompts reclassification. |
| Documentation and record keeping | Your compliance team, who keep the classification record, rationale and dates for each system | Recurring | Audit requests and the number of systems drive it up. Reduce it by storing one standard record template per system. |
Which open-source tools produce inventory and runtime evidence
GLPI's Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in manually or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. For AI Act work, the useful part is a maintained register of the infrastructure that hosts or runs AI systems, linked to owners, locations and installed software. It does not record whether a workload is an AI system under Article 3(1), and it does not know who develops, places on the market or uses that system.
- Hosts and devices: servers, GPU nodes and edge devices that run model-serving or decision-support software.
- Software records: installed packages and versions that can be matched to the AI systems you have classified.
- Ownership fields: the team or legal entity responsible for each asset, which you must set and keep current.
- Manual entries: AI services bought as SaaS or from third parties, which will not appear through agent inventory.
- Licensing: GLPI is licensed under GPL-3.0-or-later, so confirm your obligations if you modify and redistribute it.
Before relying on this data, check with your team which fields you will use as evidence and how often the agent reports.
Langfuse (MIT) captures traces of each request in an LLM application, including model calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. These traces show how a system behaves in operation and who or what invoked it, which supports the factual record behind a purpose, change or incident review. Traces do not determine whether the application is an AI system, what its intended purpose is, or whether an operator is a provider or deployer. Those decisions require documented analysis by the organization.
- Operation records: each step of a request, so you can reconstruct what the system did for a given input.
- Version and configuration metadata: tag traces with model and prompt versions so changes can be compared over time.
- Usage data: token counts and timing that help show how the system was used in practice.
- Data handling: inputs and outputs may contain personal data, so define retention and access before enabling capture.
- Self-hosting: confirm the deployment options and license terms that apply to your version.
Check that traces are retained long enough for your incident and change records, and that your team can export them.
The Wazuh Syscollector module collects hardware details, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. It stores this data in the Wazuh indexer and presents inventory views and reports in the dashboard. This gives you a verifiable view of the machines where AI software runs, including local models, notebooks and agents on workstations. It does not classify software as AI, identify the organization's role for any system, or decide whether a deployment changes an AI system's intended purpose.
- Installed software: lists packages on endpoints, which helps find unregistered AI tools.
- Processes and services: shows which AI runtimes are active on a given host.
- Users and groups: supports the link between a person and the systems they can operate.
- Reporting: inventory views you can export as evidence for an assessor.
- Licensing: Wazuh is licensed under GPL-2.0-only, so confirm obligations that apply to your distribution and modifications.
Confirm which endpoints are in scope and how often inventory is collected, since gaps in coverage will appear as gaps in your evidence.
Where organizations misclassify their role
Most misclassification under the AI Act starts with a role that was assumed rather than checked. The gaps below are the ones that most often leave an organization without the duties it actually owes, and each card names the check that closes it.
Treating the model as the system
Article 3(1) defines the AI system as the machine-based system that infers outputs, not the underlying model. A vendor's model is one component; the system includes the surrounding logic, data flows, tools and interface that produce decisions or content. Map each deployed system as a whole, then record which parts come from a third party. Confirm with the vendor which parts of the system they supply and which you build.
Missing the customizing deployer
A deployer that fine-tunes, re-prompts or wraps a provider's system for a new use may take on provider duties if that changes the intended purpose. Article 3(3) makes a provider anyone who develops a system or has one developed and places it on the market or puts it into service under its own name or trademark. Review every internal customization against the vendor's documented intended purpose, and record the decision that you remain a deployer or have become a provider.
Assuming free tools are exempt
Article 3(3) expressly covers systems provided free of charge, so the absence of a fee does not take a system outside the provider definition. Teams often assume that an internal prototype or a free-tier release is out of scope. Check whether the system was made available to others, placed on the market or put into service, and who is named on it. Confirm the legal position with counsel before relying on any exclusion.
Unrecorded substantial modifications
Article 3(23) defines a substantial modification as a post-market change not foreseen in the initial conformity assessment that affects high-risk compliance or changes the intended purpose assessed. Retraining, new data sources, new integrations and new user groups can each trigger it. Keep a change log for every system that tracks model updates, purpose changes and their assessment, so you can show whether a change was substantial before a regulator asks.
Leaving shadow AI out
An AI system used by staff outside the approved inventory still creates deployer duties if it is used under the organization's authority. Browser tools, embedded vendor features and developer-built agents often sit outside formal records. Build the inventory from several sources: procurement and expense records, SaaS and network discovery, and asset data from your existing tools. Then assign an owner and a role to each entry. Confirm each use case with its business owner.
Questions buyers ask about Article 3 role decisions
How long does an Article 3 role review take?
The duration depends on how many AI systems are in scope, how many parties sit in each supply chain, and how much technical documentation already exists. A review of a few systems built on one vendor's product is far shorter than a review of systems that mix vendor components, in-house fine-tuning and third-party hosting. The effort rises when the team must trace who developed a model, who placed it on the market or put it into service, and whether a change after launch counts as a substantial modification under Article 3(23). Ask any provider for a written scope that lists the systems, the questions answered for each one, the people who must be interviewed, and the deliverables. Do not accept a duration that is not tied to that scope.
Can our own team determine provider or deployer roles in-house?
Many teams can complete a first pass in-house, provided someone knows the systems well and reads the definitions in Article 3 closely. The provider definition in Article 3(3) turns on who develops or has an AI system developed and who places it on the market or puts it into service under its own name or trademark. The deployer definition in Article 3(4) turns on who uses the system under its authority outside a personal, non-professional activity. Teams struggle when a vendor product is rebranded, when an internal team substantially customizes a third-party model, or when a system is supplied free of charge. In those cases, the role decision needs a documented rationale that an assessor can follow, so the first pass should be checked by someone with legal and technical authority.
What does a role review need from legal and engineering teams?
Legal teams interpret the terms that decide roles: placing on the market, putting into service, use under authority, intended purpose and the chain of contracts between suppliers and customers. Engineering teams supply the facts those terms depend on, including the model lineage, the versions deployed, the training and fine-tuning steps, the hosting arrangement, the logs that show who operates the system, and the change history. Engineering also documents the intended purpose as the system is actually used, which often differs from the marketing description. The Commission's non-binding guidelines on the AI system definition, published on 6 February 2025, help engineering decide whether a system is an AI system at all. The two teams should agree on a shared record of facts before legal reaches a conclusion.
Can an implementation partner make the provider or deployer determination for us?
A partner can gather the technical facts, map the systems and supply chain, prepare the record of evidence, and run a structured analysis against the Article 3 definitions. The role determination itself is a legal judgment that the organization owns, so it should be signed off by the organization's counsel. DeployOpen implements, documents and supports self-hosted open-source platforms inside a client's own infrastructure, and it prepares systems and evidence for compliance work. It does not issue legal opinions, audit reports or certifications. Independent auditors and certification bodies issue those outputs when they are required. Any engagement should state in writing who decides each role and who reviews the decision.
Is a consultant worth the cost for a small AI inventory?
A small inventory usually lowers the effort, so the question is whether the fee buys reduced risk that justifies the spend. The cost has three parts: the external fee, the internal time of engineers and legal staff, and any follow-up work when the first decision is challenged. A small set of systems is faster to review, but a single misclassified role can carry significant exposure. Article 99 sets maximum fines of EUR 15 million or 3% of worldwide annual turnover, whichever is higher, for most operator obligations. Ask for a fixed-scope quote that lists each system, the deliverables and the points where your staff must review the output. Compare that quote with the internal hours you would otherwise spend, including the hours counsel must spend to review the result.
What changes for Article 3 definitions after the 2026 amendment?
Regulation (EU) 2026/1744, the Digital Omnibus on AI, inserted definitions of SME at point 14a and small mid-cap enterprise, or SMC, at point 14b, and amended the definition of safety component at point 14. Article 3 now has 70 numbered definitions. The core role definitions for providers, deployers and operators, along with the definitions of substantial modification and serious incident, should be checked against the consolidated text before you rely on them, because the amendment's wording controls. Confirm each citation against the current consolidated version and record which version your role decisions used. Organizations with SME or SMC status should also check how those definitions affect the obligations they carry, with counsel.
How DeployOpen prepares Article 3 role evidence
DeployOpen prepares the records that let your team and an outside assessor test your Article 3 role determinations, and it does so under a fixed-scope engagement agreed in writing before any work starts. The written scope names the AI systems in view, the business units and cloud accounts or data centers where they run, the deliverables and the timeline. In practice, DeployOpen helps build the AI system inventory, records each system's intended purpose, and maps each system to the provider, deployer or other operator role your organization has decided applies. Where a system is built on a third-party model or component, the technical records capture who developed it, who placed it on the market or put it into service under its own name, and which configuration changes your team made afterward, since those changes bear on whether a substantial modification under Article 3(23) has occurred. Ask any implementation partner to show you the inventory template and the change log fields before you sign.
DeployOpen does not issue audit reports, attestations or certifications, and it does not make the legal role determination for your organization. That determination belongs to your legal and compliance function, which should document the reasoning, and it may be challenged by a market surveillance authority. DeployOpen's role is to prepare the systems, controls and evidence that support the decision and to hand them to the independent assessor or certification body you choose. Before engaging anyone, confirm with counsel which decisions remain internal, which evidence the assessor will request, and who signs off on the intended purpose statement and the serious incident criteria under Article 3(49). Keeping those responsibilities clearly separated protects both the quality of your evidence and your accountability.
