Does the EU AI Act apply to our organization and our AI systems?
Article 2 sets the scope of the EU AI Act by role, by place of establishment and by where the AI output is used. If you are a compliance lead or CTO, this is the first question to answer, because every later obligation depends on it. The Act reaches providers that place AI systems or general-purpose AI models on the EU market, wherever they are established, and deployers that are established or located in the EU. It also reaches non-EU providers and deployers when the output of the AI system is used in the EU, so a firm based outside the Union can still be in scope. The same provision names importers, distributors, product manufacturers that place an AI system on the market under their own name with their product, authorised representatives of non-EU providers, and affected persons located in the EU. Map each system you run against these roles and write down the role you hold for each one, since a single organization can be a provider for one system and a deployer for another.
The exclusions matter as much as the reach. The Act does not cover AI placed on the market, put into service or used exclusively for military, defence or national security purposes, whatever kind of entity runs it. It also excludes AI developed and put into service solely for scientific research, and research, testing and development before a system is placed on the market, although real-world testing is not covered by that exclusion. Natural persons using AI in a purely personal, non-professional activity fall outside the deployer duties. Free and open-source systems are excluded unless they are placed on the market as high-risk systems or fall under Article 5 or Article 50. Confirm each exclusion against the written purpose and licence of your system, not against how the team describes it internally. Note also that Article 2(2) narrows the high-risk rules for certain Annex I Section B products, which the Digital Omnibus extended to the Machinery Regulation, so check the product regime before assuming the full set of duties applies.
The scope decision is the first document an assessor or a customer's due diligence team asks for, because it fixes which obligations, dates and fines apply to each system. Record the decision in a dated memo that lists each AI system, its provider or deployer role, the EU link (market placement, establishment or output use), any exclusion relied on, and the reviewer who signed it off. Revisit the memo whenever a system changes purpose, market or licence, and when the Commission's guidance or the amended text changes a boundary. If the answer is unclear for a high-value system, bring in a qualified legal adviser before the classification work starts, because an incorrect scope decision propagates into every later control.
Which roles, systems and exclusions change the scope decision
Article 2 turns on a short list of questions: what role you hold, where the system is placed or used, and whether an exclusion applies. Each card below is a decision point that changes which obligations you carry, so settle them in writing before you map controls or budget for work.
Provider or deployer
The provider is the party that develops an AI system or general-purpose model, or has it developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority. One organization can hold both roles for different systems, and the role decides which chapter of obligations applies. Check whether you build, fine-tune or rebrand the system, because customizing a third-party system can move you into the provider role.
EU establishment or EU output use
The Act reaches providers placing systems on the EU market wherever they are established, and deployers established or located in the EU. It also reaches non-EU providers and deployers when the system's output is used in the EU. A US or Asian company serving EU customers can therefore be in scope even with no EU entity. Map where outputs such as scores, decisions or content are actually consumed, not only where servers sit.
Importers, distributors and authorised representatives
Importers bring a non-EU provider's system into the EU market, and distributors make it available without changing it. Both carry duties of their own, and Article 2 names them alongside authorised representatives appointed by non-EU providers. Confirm in each supplier contract who holds the authorised representative role and who keeps the technical documentation, since a missing appointment can leave an importer exposed.
Product manufacturers using their own name
A manufacturer that places an AI system on the market together with its product, under the manufacturer's own name or trademark, falls within Article 2. This matters for embedded AI in machinery, medical devices and other regulated products. Check whether the AI is a safety component or the product's own function, because that determines the product route to high-risk status and the sectoral law that also applies.
Military, defense and national security exclusion
Article 2(3) excludes AI systems placed on the market, put into service or used exclusively for military, defense or national security purposes, whatever kind of entity operates them. The word exclusively is the test. A system that serves both civilian and defense users, or a dual-use deployment, is not covered by this exclusion and needs its own scope analysis. Document the exclusive purpose and its boundaries.
Research exclusion and real-world testing
Article 2 excludes AI developed and put into service solely for scientific research, and AI used for research, testing or development before it is placed on the market. The exclusion does not cover testing in real-world conditions. A pilot that exposes real users or real decisions to a system is outside the exclusion, so treat any live trial as in scope and confirm the boundary with counsel before it starts.
Personal non-professional use
Article 2 excludes the deployer obligations of natural persons who use AI in a purely personal, non-professional activity. The exclusion covers individuals, not businesses. An employee who uses an AI tool for work, or a sole trader using it for client services, is not acting in a purely personal capacity, so employer and business duties still apply. Confirm the use is private before relying on this exclusion.
Free and open-source carve-backs
Article 2(12) excludes AI systems released under free and open-source licenses. The exclusion does not apply when the system is placed on the market or put into service as a high-risk system, or when it falls under Article 5 (prohibited practices) or Article 50 (transparency). Open-source licensing does not remove scope for a self-hosted system used for hiring, credit or other high-risk purposes. Check the license terms and the intended use together.
How to run a documented Article 2 scoping decision
This sequence turns the Article 2 scope question into a written record: which AI systems and general-purpose models the business touches, which operator role it holds for each, which EU touchpoint triggers the Act, and which exclusions apply on documented facts. It ends with a review trigger so the decision stays current as products change.
Build the AI system and model inventory
Compile a list of every AI system and general-purpose AI model the business builds, buys, embeds, fine-tunes, resells or uses, including tools that vendors bundle into other products. Business owners, product teams and procurement should contribute, since shadow use often sits outside IT. The output is an inventory register with one row per system, listing its name, owner, purpose, supplier and where it runs. You know this step is done when each system in the register has a named owner and a description specific enough to test against the Act's definitions.
Assign each system an operator role
For each inventory row, record whether the organization acts as provider, deployer, importer, distributor, product manufacturer placing a system under its own name, or authorised representative. Base the choice on who develops the system or has it developed, who places it on the market or puts it into service under its own name, and who uses it under its own authority. The output is a role register that can be read alongside the inventory. The step is complete when every row has one role or a documented reason for a dual role, and legal or compliance staff have reviewed the assignments.
Map each system to an EU touchpoint
For each system, record the link to the Union that brings it into scope under Article 2(1). Note whether the provider places the system on the market in the EU, whether the deployer is established or located in the EU, and whether the output is used in the EU even if the provider and deployer are outside it. Also note affected persons located in the EU. The output is a touchpoint map with a short statement of the fact behind each link, such as where users sit or where outputs are consumed. The step is done when every system either has a documented EU touchpoint or is marked out of scope on that basis, with the evidence cited.
Test each exclusion against documented facts
Work through the exclusions in Article 2 for each system that has an EU touchpoint: military, defense or national security use; scientific research and pre-market research, testing or development; purely personal non-professional use by a natural person; and free and open-source licensed systems. Check each against records such as contracts, product specifications, user lists and license files. Remember that real-world testing is not covered by the research exclusion, and that open-source systems lose the exclusion when they are placed on the market as high-risk or fall under Article 5 or Article 50. The output is an exclusion record per system showing each test, the evidence used and the result. Legal reviewers should sign off where the facts are close.
Record the scope decision with its reasoning
Write a scope memo for each system or group of similar systems. It should state the system, the role, the EU touchpoint, each exclusion considered and its outcome, and the reasoning that links the facts to the conclusion. Name the person who approved the decision and the date. Where the answer depends on a fact the organization has not yet confirmed, say so and assign an owner to confirm it. The output is a signed scope memo held with the inventory. You know the step is complete when an outside reader could follow the reasoning from the memo to the evidence without asking the author.
Set review triggers for scope changes
Define the events that reopen a scope decision: a change in intended purpose, a new market or user group, a new distribution channel, a substantial modification, a move from internal use to supply, a change of license for an open-source component, or a new supplier. Assign owners for watching each trigger, and link the triggers to change management and procurement workflows so they are caught when they happen. The output is a trigger list attached to the inventory and a log of reviews performed. The step is complete when each trigger has an owner and a recorded review schedule agreed internally.
How an assessor tests the Article 2 scope position
This table compares each scope question an assessor or market surveillance authority is likely to ask about Article 2, the evidence to prepare, and the gaps that most often appear. Read it as a checklist for the scope memo: the organization owns its position, and an independent reviewer tests whether that position holds up against the Act's text and the facts.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Role determination for each system | Written role analysis per AI system naming the provider, deployer, importer, distributor or product manufacturer, with the contract or product record behind each role | Roles assumed from the team that built or bought a system, with no check against who places it on the market or puts it into service |
| EU nexus test for non-EU firms | Record of where output is used in the EU, including customers, users, affected persons and the authorised representative appointment where one is required | Firms assume that a US or Asia-based hosting location removes EU reach, without checking where outputs reach EU users |
| Military, defense or national security exclusion | Documented purpose statement, intended use, and the contractual or mandate basis showing the system is used exclusively for those purposes | Dual-use systems excluded on the basis of one customer, while the same system is also used for civilian or commercial purposes |
| Research and development exclusion | Evidence of scientific research or pre-market testing purpose, with limits on use and a record of any real-world testing | Pilot programs with paying or live customers presented as research, which the exclusion does not cover |
| Personal, non-professional use exclusion | Description of the natural person's activity and proof that the use has no professional or commercial purpose | Individuals using AI in business roles, or small firms that treat the exclusion as covering staff use |
| Open-source exclusion and its carve-backs | License terms for each component, a check that the system is not placed on the market as high-risk, prohibited or transparency-relevant, and a Article 5 and Article 50 review | Open-source license treated as a full exclusion, with no test for high-risk use, prohibited practices or chatbot and synthetic content duties |
| Consistency between scope memo and system inventory | Matching entries in the scope memo and the AI system inventory for role, purpose, jurisdiction and exclusion, with dated version history | Inventory lists a system as in scope while the memo claims an exclusion, or the memo predates a new feature or deployment |
Why the open-source exclusion rarely covers a commercial deployment
Article 2(12) removes most AI systems released under free and open-source licenses from the Act, but the exclusion stops applying the moment the system is placed on the market or put into service as a high-risk system, or when it falls under the Article 5 prohibitions or the Article 50 transparency duties. For a team that self-hosts an open-source model inside a product, the question is rarely whether the code is open source. The question is whether the way the organization uses and sells the system takes it outside the exclusion. A license that permits commercial use does not, on its own, answer the AI Act question.
In practice, a commercial deployment usually triggers one of those exits. A customer-facing chatbot built on an open-weight model falls under the Article 50 duty to tell people they are interacting with an AI system, whatever the license says. A tool that scores job applicants or makes credit decisions can be high-risk under Annex III, and once it is put into service for that purpose, the open-source carve-out no longer protects it. Organizations should map each self-hosted model to its intended purpose, its customers and its decision-making role, then record which exit, if any, applies. Confirm with counsel whether the license permits the commercial use planned, whether any model weights or derivative works carry separate terms, and whether the organization is the provider, deployer or both.
Several facts need confirmation before anyone relies on the exclusion. Ask counsel to review the exact license text of each model and each component, the terms for derivative works and fine-tuned versions, and any acceptable-use restrictions that bind the deployment. Ask the technical team to document the intended purpose, the deployment environment and whether the system is sold, licensed or made available to third parties. The answers determine whether the organization can treat the system as outside the Act or must plan for provider obligations, and an implementation partner can prepare the inventory and records that counsel and the auditor will need, but the legal conclusion stays with the organization and its advisers.
Evidence that shows the scope decision holds up
An Article 2 scope decision is only as strong as the records behind it. The artifacts below connect the legal reasoning to the systems, markets and open-source components an assessor or market surveillance authority will ask about. Each one needs an owner and a review date, because the scope decision changes whenever a new use, market or dependency appears.
Signed scope memo
A dated, versioned memo that states which AI systems and general-purpose models the organization assessed, which Article 2 limbs apply to each, and who approved the conclusion. Record the reason for every system that is in scope and every one that is excluded. Review it at least annually and whenever the AI Act's dates or amendments change the analysis, including the 2026 amendments to Article 2. Keep prior versions so you can show what was believed at each point in time.
AI system and model register
A register listing each AI system and general-purpose model, its provider or deployer role, its intended purpose, the market or service where it is used, and its supplier. This register is the first thing to check when a new tool appears. Link every entry to the role it plays, since the same tool may create provider duties for one team and deployer duties for another. Confirm the register is fed by procurement and by engineering, not only by the compliance team.
EU nexus record
A record that explains why a non-EU organization, or an EU organization with systems hosted abroad, falls within Article 2. It should name each EU touchpoint: EU establishment, EU deployers, output used in the EU, or EU importers and distributors. Note who in the EU receives the output and how. Update the record when a customer, region or data flow changes, because a single new EU user can change the scope conclusion.
Exclusion files with supporting facts
One file per exclusion claimed, covering military and defense use, scientific research, testing before market placement, purely personal use and free and open-source release. Each file should record the facts that support the exclusion and the conditions that would end it. Research and testing exclusions do not extend to testing in real-world conditions, and open-source release does not cover systems placed on the market as high-risk or systems under Article 5 or Article 50. Check each file against those limits before relying on it.
Open-source license register
An inventory of open-source components in each AI system, with license identifiers, versions and the team that approved each dependency. Use it to show which components rely on the free and open-source release exclusion and which do not. A component that is part of a system placed on the market as high-risk falls outside that exclusion. Generate the first version from a software inventory and have engineering confirm the licenses of models and datasets, which may carry separate terms.
Change log for new use and new markets
A dated log of each change that could move a system into or out of scope: a new use case, a new country, a new customer type, a new model version or a substantial modification. Each entry should cite the scope memo version it affected and record whether the scope conclusion was re-run. Tie the log to change management tickets so reviewers can trace the decision. Without this log, an assessor cannot tell whether the scope memo still describes the systems in production.
What a scope determination costs in effort and money
The main cost of an Article 2 scope determination is internal time, not an invoice. Legal and product staff must decide, for each AI system, whether the Act reaches the organization at all, and that decision depends on facts only the business can supply: where the provider is established, where the output is used, whether the system is placed on the market under the organization's name, and whether any use falls under the military, research or personal-use exclusions. Counsel review adds a second layer, usually on the borderline calls. An external scoping workshop is optional. It can speed up a first pass across a large portfolio, but the organization still owns the conclusions and must record them. Ask any firm for a written scope listing the systems covered, the workshop deliverables and whether counsel review is included, because these items vary widely between quotes.
Scoping is mostly one-time work, but it recurs whenever a system changes. A new vendor model, a new EU customer base, a new deployment in an EU office or a change to the product's name on the market can each move a system into or out of scope. Plan a standing review tied to change management rather than a periodic audit of the whole inventory. Also confirm the dates that govern the effort: the Act's application dates were amended in 2026, so a scope note written against earlier timelines should be reread. The Commission's AI Act overview and the consolidated text are the starting points for confirming current dates with counsel.
Four drivers raise or lower the effort: the number of AI systems in the inventory, the number of jurisdictions in which outputs are used, the extent to which systems rely on third-party models, and how many components are open-source. Each system that uses a third-party model requires the team to establish who is the provider, who is the deployer and whether any modification changes that role, which takes longer than a system built wholly in-house. Open-source components raise questions about the Article 2(12) exclusion, which applies only where no high-risk, Article 5 or Article 50 role exists. Self-hosted inventory tools such as GLPI or Wazuh can reduce the time spent finding software and hosts, which supports the inventory but does not decide scope, and they remove no licensing obligations. Confirm current license terms directly with each vendor before relying on them.
Who owns the scope decision and who prepares the evidence
Your legal and compliance team owns the scope position. It decides whether the organization is a provider, deployer, importer, distributor, product manufacturer or authorised representative for each AI system, whether the system reaches the EU market or EU users under Article 2(1), and whether any exclusion in Article 2 applies. That decision is a legal judgment, and it should be written down, dated and signed by an accountable person, with the reasoning kept on file.
- Role mapping: Record which role your organization holds for each system and why, including cases where a non-EU entity's output is used in the EU.
- Exclusion review: Test any claim to the military, research, personal use or free and open-source exclusions against the exact conditions in the text, including the carve-outs for real-world testing and for high-risk or prohibited systems.
- Sign-off record: Keep a signed scope memo that names the decision owner and states the facts it relies on.
- Change control: Reopen the position when a system is substantially modified, its intended purpose changes or the amended dates move.
- Counsel input: Ask outside counsel to review borderline cases, and confirm which EU Member State authority you will deal with.
Check that every scope conclusion can be traced to a named owner, a written rationale and a current system description.
An implementation partner such as DeployOpen prepares the material the scope decision depends on. That work includes building the system inventory, documenting how each AI system is built, hosted and used, collecting technical records, and assembling the evidence folder that the legal team and any assessor will read. The partner gathers facts and organizes them. It does not decide the legal role, does not sign the scope position and does not issue any determination of conformity or compliance.
- System inventory: Map each AI system, its components, data sources, hosting location and the people or organizations that operate it.
- Technical records: Document architecture, model sources, deployment settings and change history so the facts behind the scope position can be checked.
- Evidence folder: Organize logs, configuration exports and version records under the scope memo.
- Gap notes: Flag facts that are missing or contradictory and send them back to the owner for a decision.
- Independence line: The partner's output is an input. Its staff should not write the legal conclusion or present themselves as an authority.
Ask any partner to state in writing which tasks it performs and which remain with your organization, and confirm that its scope is fixed before work begins.
Independent parties test the position after the fact. National market surveillance authorities enforce the Act for AI systems, and an independent auditor or certification body may be engaged for voluntary assurance or for systems that need third-party conformity assessment. These parties review your documented reasoning, check the facts against the system as it runs and can challenge a classification or a claimed exclusion. Neither an implementation partner nor your own staff can stand in for them.
- Document review: Expect the scope memo, inventory and evidence folder to be requested and compared with what the system actually does.
- Fact testing: Assessors may check logs, configurations and deployment records against the stated role and intended purpose.
- Challenge rights: Market surveillance authorities can contest a classification, so the reasoning must hold up when questioned.
- Reports: Only the independent body issues an audit report, certificate or decision. Your partner prepares material for it but does not issue any of these.
- Authority mapping: Confirm which authority supervises your systems, since general-purpose AI model rules and some platform cases sit with the AI Office.
Confirm with your chosen auditor which evidence they expect and whether they will accept a scope memo built on the inventory you prepared.
Where scope decisions usually break down
Most scope errors under Article 2 come from asking the wrong unit of analysis: the whole company, a product name, or a one-time decision. The cards below cover the gaps we see most often, each with the check that closes it.
Scoping the whole company
Article 2 applies to AI systems and general-purpose AI models, not to an organization as a whole. A bank may have one credit-scoring model that matters greatly under the Act and a dozen internal analytics tools that may not. Build the scope from a system inventory, record each system's role and intended purpose, and decide the applicability question per system.
Missing non-EU output reach
Article 2(1) reaches non-EU providers and deployers when the output of an AI system is used in the EU. A US vendor scoring applicants for a French subsidiary can fall in scope even with no EU office. Ask where outputs are consumed, not only where the company or servers sit, and document the answer for each EU-facing system.
Assuming open source is exempt
Article 2(12) excludes AI systems released under free and open-source licenses, but only up to a point. The exclusion does not hold where the system is placed on the market or put into service as high-risk, or where Article 5 or Article 50 applies. A permissive license on a model does not settle the question for the deployment built on it.
Confusing testing with real-world use
Article 2(8) excludes research, testing and development before a system is placed on the market, but testing in real-world conditions is not covered by that exclusion. Internal evaluations and red teaming in a lab may sit outside scope, while a pilot that makes decisions about real people may not. Log which environment each test ran in and who was affected.
Missing a change of purpose
A system scoped as a low-stakes internal tool can become high-risk when its intended purpose changes, for example when a support-ticket classifier is repurposed to rank job applicants. Scope is a snapshot of one purpose. Re-run the assessment whenever the use case, user group or decision it informs changes, and treat that re-run as a formal change control step.
Not recording why an exclusion applies
A decision that a system falls outside Article 2, or is exempt under a carve-out, is only as strong as its written reasoning. Military, research, personal use and open-source conclusions all need a dated record naming the facts relied on and the person who approved them. An assessor or market surveillance authority will ask for that record first.
Questions buyers ask about Article 2 scope
Does the EU AI Act apply to a company based outside the EU?
Yes, it can. Article 2 reaches non-EU providers that place AI systems or general-purpose AI models on the EU market, and non-EU providers and deployers where the output of the AI system is used in the EU. The trigger is where the output is used, not where the company or its servers sit. A non-EU provider whose system is placed on the EU market also needs an authorised representative in the Union. Whether a particular arrangement falls inside the Act depends on facts such as who the customer is, where users are located and how the output is used, so confirm the position with EU counsel before relying on an offshore structure. The Act applies in stages: Chapters I and II have applied since 2 February 2025, and the rest of the Act from 2 August 2026 under Article 113 as published. The 2026 amendment moved the high-risk rules to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems.
How long does an Article 2 scoping exercise take, and what drives the effort?
The effort depends mainly on how many AI systems the organization operates, how many of them touch EU users or EU outputs, and how well documented they are. A single internal tool with clear ownership is a short exercise. A group with many vendor-supplied features, shadow tools and several legal entities is a longer one. Other drivers include whether the organization is a provider, deployer, importer, distributor or product manufacturer for each system, and whether legal review of each role is needed. Ask any consultant or partner for a written scope listing the systems, business units, jurisdictions and deliverables covered, and whether counsel review is included or left to you. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so the quote follows from that scope rather than from a generic estimate.
Do open-source AI models escape the EU AI Act?
Not automatically. Article 2(12) excludes AI systems released under free and open-source licenses, but the exclusion does not apply where the system is placed on the market or put into service as a high-risk system, or where it falls under Article 5 (prohibited practices) or Article 50 (transparency duties). A license alone does not settle the question. Organizations that take an open-source model and deploy it in a hiring, credit or other Annex III use case can still carry deployer obligations, and a party that commercializes or puts a system into service may take on provider duties. General-purpose AI model rules are a separate chapter, so check that analysis too. Confirm the license terms, intended purpose and commercial arrangements with counsel before concluding the exclusion applies.
Is a research pilot exempt from the EU AI Act?
Only part of it. Article 2(6) and 2(8) exclude AI developed and put into service solely for scientific research, and AI used for research, testing or development before it is placed on the market. The exclusion is narrow. Testing in real-world conditions is not covered by it, so a pilot that exposes real users, customers or employees to the system may fall outside the exemption. A pilot that is a commercial trial, or that feeds a product later sold in the EU, also deserves a close look. Record the purpose, the participants, the duration and the exit plan in writing, and have counsel decide whether the exclusion holds for each phase. Regulatory sandboxes are a separate route covered elsewhere in this guide set.
Who must sign the Article 2 scope memo?
The organization signs it, and the signatory should be someone with authority over the AI systems and the legal entities involved. In practice that is often a general counsel or compliance lead, with sign-off from the business owners of each system and the security or technology lead who holds the inventory. Legal conclusions about roles and exclusions should be reviewed by qualified EU counsel, and the memo should say which parts counsel reviewed. An implementation partner can draft the memo and record the technical facts, but the decision and the accountability stay with the organization. Keep the memo versioned, dated and linked to the system inventory so it can be updated when a system, use or market changes.
Can an implementation partner make the Article 2 determination for us?
A partner can prepare the evidence, but it cannot make the legal determination or certify the result. The organization owns the scope decision. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, and can help build the AI system inventory, record technical facts such as hosting location, user population and output flows, and prepare the documentation counsel needs. DeployOpen does not issue legal opinions, audit reports or certifications. Ask a partner to state in writing which parts of the scope it prepares, which parts counsel must confirm, and what the deliverables and timeline are before work begins.
How DeployOpen prepares the scope evidence
DeployOpen works on fixed-scope engagements, so the boundary of the AI Act analysis is agreed in writing before any work starts. That written scope names the AI systems, the roles the organization holds for each one (provider, deployer, importer, distributor, product manufacturer or authorised representative), the EU touchpoints that bring a system into reach, and any exclusion the organization intends to rely on, such as military use, scientific research, personal use or a free and open-source release. Inside the client's own cloud accounts, data centers or air-gapped networks, DeployOpen then builds the AI system inventory and the technical records that show where each system runs, what data it touches and who operates it. Tools such as GLPI and Wazuh can help capture the hosts and software involved, and Langfuse traces can show how an LLM-based system is used in practice. Your counsel should confirm that each inventory entry matches the legal definitions in the Act.
DeployOpen then assembles the evidence folder for the client's counsel and auditors: the signed scope statement, the inventory, dated configuration and inventory exports, and a record of each exclusion claim with the facts behind it. Where an exclusion depends on a judgment, such as whether a system is used solely for research or whether a deployer acts in a purely personal capacity, the folder records the facts and the question, not the answer. DeployOpen does not issue legal opinions, determinations of scope, classifications or certificates. Those decisions belong to the organization and its legal advisers, and any formal assessment or report comes from an independent auditor or the relevant authority. Ask any implementation partner to confirm this division of roles in the statement of work.
