If you cannot say, in writing, in one paragraph, with a citation, whether a given internal tool is an "AI system" under EU AI Act Article 3(1), you cannot do any of the rest of the work. Not the risk tiering. Not the Annex IV file. Not the Article 27 Fundamental Rights Impact Assessment. Not the Article 47 declaration that you, personally, will sign. The whole regulation hangs from this hook, and the hook is six lines long. This lesson is how you read those six lines like a regulator.

Why Article 3(1) Is the Load-Bearing Sentence in the Entire AI Act

Think of the EU AI Act as a building. Annex III is the eighth floor, the high-risk wing. Article 5 is the basement, the prohibited rooms nobody is allowed to enter. Article 50 is the lobby, where the transparency signs go on the wall. The Annex IV technical file is the building inspector's binder. The Article 47 declaration is the certificate of occupancy. But before any of that exists, before the inspector even shows up, there is a door at the front of the building, and over that door is one question: Is this thing an AI system?

If the answer is yes, you walk in and the whole regulation applies to you in proportion to the floor you end up on. If the answer is no, you do not walk in at all. You walk down the street to a different regulation (consumer law, product safety, data protection, sectoral rules) and the AI Act is silent about you. There is no middle door. There is no "AI-adjacent" status. The Article 3(1) definition is the bouncer, and the bouncer reads one sentence.

That is why every European Commission consultation, every IAPP AIGP exam item, every notified body Stage 1 review, and every Schellman / A-LIGN / BSI / KPMG audit opens at the same place: a list of in-scope systems, each one tagged with its Article 3(1) rationale. Get the list wrong and the rest of the program is built on sand. Get it right and the rest of the program inherits a stable foundation. This lesson teaches you how to write that list, defend it to a Big Four legal team, and update it when a vendor adds a feature that quietly puts a previously out-of-scope tool into scope on a Tuesday.

The Exact Definition, Read Slowly

Here is the canonical text of Article 3(1) of Regulation (EU) 2024/1689:

"AI system" means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.

That is a single sentence with seven joints. Most people read it once and decide, intuitively, that "well, an LLM clearly is and a spreadsheet clearly isn't." That intuition is correct on the obvious cases and useless on the edge cases, and the edge cases are the only ones that ever land on your desk. A keyword-based email router, an ETL pipeline with a learned regex, a Power BI model with a "smart insights" toggle, a spreadsheet macro that calls Azure OpenAI, a SaaS feature with "AI" in the marketing copy and a deterministic if-statement under the hood, every one of those is a Tuesday-morning question, and every one of those is a question Article 3(1) actually answers if you read it like an instrument rather than like prose.

The Commission's own AI Office guidance, the European AI Act Service Desk Q&A, and the OECD AI Principles definition (which Article 3(1) borrows from, with minor edits) all converge on a seven-part test. We will walk each part, build the test, and then run it against ten real systems.

The Seven Elements of the Article 3(1) Test

Element 1 - Machine-Based

"Machine-based" is the easy one and it is also a trap. Easy because every digital system runs on machines and therefore every digital system clears this bar. Trap because lawyers occasionally argue, especially in the early consultation rounds in 2024-2025, that purely process-based decision systems, a paper checklist, a human committee, a manual fraud-review queue, fall outside this element. They do. They also fall outside any digital regulation, so the point is academic. The practical takeaway: if the system runs on a CPU somewhere, this element is satisfied. Move on.

Watch out for the disguised version of this question: when an external vendor sells you a "human-in-the-loop AI system" and tries to argue that, because a human approves every output, the system is not really machine-based. Wrong. The machine-based element refers to the system itself, not to who approves its outputs. An algorithmic credit-scoring engine with a human reviewer at the end is still machine-based; the human is one component of the deployer's Article 14 human-oversight design, not a get-out-of-jail-free card on Article 3(1).

Element 2 - Designed to Operate with Varying Levels of Autonomy

This is the first joint with real bite. The phrase "varying levels of autonomy" is doing two pieces of work at once. First, it is contrasting with strictly user-controlled tools. A calculator does not operate with autonomy, every keystroke maps to a deterministic operation defined by the user in real time. A spell-checker that flags every red squiggle and waits for you to right-click and choose has, debatably, a sliver of autonomy. An LLM that takes "write me an email to legal about the indemnification clause" and decides which tone, which framing, which citations to use is operating with significant autonomy.

Second, and more importantly, "varying levels" is a deliberate inclusion. Some critics asked the Commission to limit the definition to highly autonomous systems. The Commission refused, and the European Parliament backed the refusal in trilogue. The result: even systems with very little autonomy are in scope as long as they have some. A rule-based chatbot that decides between three canned responses without asking the user has some autonomy. A fraud-detection model that proposes "review" / "approve" / "deny" without committing to a final decision has some autonomy. The "varying levels" wording is wide on purpose.

What does fall out of scope here? Pure look-up tables. Pure formula evaluation. Pure deterministic rules engines that a non-engineer could trivially trace to the same output every time. The classic edge case, a credit-scoring "model" that is just FICO score × five constants with a hard cutoff at 680, is genuinely on the line. Most regulators will say: if a non-expert reading the design document cannot predict the output for a given input without running the system, it operates with autonomy. If they can, it does not. We call this the "could the auditor predict the output on a Post-it note" test. Use it.

Element 3 - May Exhibit Adaptiveness After Deployment

"May exhibit", note the word, is the most quietly important phrase in the whole definition. It is permissive, not mandatory. A system does not have to actually adapt after deployment to be an AI system. It only has to be capable of adapting. This matters enormously because it sweeps in static models that could be retrained, fine-tuned, or updated on the basis of post-deployment data. Almost every modern model qualifies on this element by default.

What this element does exclude is strictly frozen, irreversibly compiled rule sets, systems where adaptiveness is not even architecturally possible. This is rare. It is most often invoked for ancient legacy systems, hard-coded decision trees that ship in a single binary with no update mechanism, or embedded firmware in industrial controllers. If you have a Python service hosted in your cloud and the team behind it has any path to update its weights, prompts, embeddings, retrieval index, or training data, adaptiveness is satisfied.

Tip for the policy author: do not waste argument here. Almost every conceivable enterprise system clears the adaptiveness bar. Spend your scope-defense budget on Elements 2, 4, and 5 instead.

Element 4 - For Explicit or Implicit Objectives

The system has to be doing something on purpose, but the purpose can be implicit. Explicit objectives are obvious: minimize loss on a validation set, maximize click-through, maximize fraud-detection F1 score, generate a response a user rates 4 or 5 stars. Implicit objectives are the harder case: a foundation model that is "just" trained to predict the next token has an explicit training objective (next-token prediction) and a vast cloud of implicit objectives (be helpful, be safe, be coherent, follow instructions) that emerged from the training data and RLHF rounds. Both count.

This element is almost always satisfied. It is on the test mostly to exclude pure noise generators, a random-number generator with no objective at all. As soon as the noise becomes biased toward any outcome, however, there is an implicit objective and Element 4 lights up. Practically: if anybody on the engineering team can describe what "good" looks like for this system, Element 4 is satisfied.

Element 5 - Infers From the Input It Receives

This is the joint where the regulator pushes hardest. "Infers" is doing the bulk of the work because it is the word that separates AI systems from traditional software. A traditional system applies pre-programmed rules to its input and emits a deterministic output. An AI system infers. It derives the output through a learned function, a probabilistic model, a learned mapping that was not hand-coded by an engineer.

The Commission's draft guidance and the European AI Board's commentary clarify that inference covers:

• Statistical learning: classical ML, regression, decision trees built from data, ensemble methods, gradient boosting
• Deep learning - neural networks of any depth and architecture
• Reinforcement learning: agents that learn policies from environment interaction
• Bayesian inference: probabilistic graphical models, MCMC chains, sequential Monte Carlo
• Symbolic learning: inductive logic programming, knowledge-graph completion, learned ontologies
• Hybrid approaches: neuro-symbolic systems, retrieval-augmented generation, agent stacks

What inference is not:

• Linear interpolation between known values: a financial calculator that linearly interpolates a yield curve between two market quotes is not inferring; it is computing a closed-form interpolation rule
• Pure rule-based expert systems: IF-THEN-ELSE trees authored by humans, even if hundreds of branches deep
• Optimization with known-good objective and constraints, solving a linear program with the simplex method is computation, not inference
• Database aggregation queries - SQL SUM / AVG / COUNT is computation
• Pattern matching with hand-coded patterns, a regex-based PII redactor authored by a privacy engineer is not inferring

The line gets fuzzy fast. The classic edge case: a regex authored by a human is computation, but a regex learned from data (training a small NER model and exporting it to a regex for performance) is inference. The label depends on provenance, not on the final code. If the rule was discovered from data, it is inferred. If it was authored from intuition, it is not. The provenance test is what notified bodies actually use in Stage 2 audits, and it is what you should use in your scope memo.

Element 6 - Outputs: Predictions, Content, Recommendations, or Decisions

The Article 3(1) list of output types is illustrative ("such as") and intentionally broad. The four named categories are the buckets every AI output falls into in practice:

• Predictions: forecasts, classifications, anomaly scores, risk scores, fraud probabilities, churn likelihoods, click-through rates, time-to-event estimates, demand forecasts. This is the largest bucket and covers most "classical" ML.
• Content: generated text, images, audio, video, code, synthetic data. The whole generative-AI surface lives here.
• Recommendations: ranked lists, next-best-action suggestions, retrieval results scored by learned relevance, conversational agent suggestions. The "agent suggests, human approves" autonomy tier maps here.
• Decisions: automated approvals, automated denials, automated routing, automated escalations. The "agent acts" autonomy tier maps here. Article 22 GDPR overlap lives here, too.

Whichever bucket the output falls into, Element 6 is satisfied. It is hard to fail this element if you have already cleared inference (Element 5). The two travel together.

Element 7 - That Can Influence Physical or Virtual Environments

The final joint sweeps in anything with a downstream effect. A chatbot reply influences a virtual environment (the user's screen, the user's belief state, the user's downstream actions). A fraud-detection score that auto-flags a transaction influences a virtual environment (the transaction's status in the database, the customer-experience funnel, the bank's risk register). An industrial control model that throttles a pump influences a physical environment (the pipe pressure, the downstream plant). A demand-forecasting model whose outputs feed a procurement workflow influences both.

What does this element exclude? Outputs that go nowhere: a model trained, evaluated, and shelved without ever being connected to a production environment. The instant the output reaches a user, a system, a process, or a decision, this element fires. The only outputs that fail Element 7 are outputs that nobody sees and nobody acts on. In practice, those are research artifacts, not enterprise AI systems.

Putting It Together - The Article 3(1) Checklist

Reading all seven elements as a conjunctive test, a system is in scope if and only if all seven are satisfied. In policy-author practice, we boil this to a five-question scope-memo template that an AI Governance Committee can apply to any candidate system in under five minutes:

1. Does it run on machines? (Almost always yes; default-pass)
2. Does it have some autonomy in how it generates its output? (Can a reader of the design document predict every output on a Post-it note? If no, autonomous.)
3. Is the system capable of being updated or retrained? (Almost always yes; default-pass)
4. Does the system infer outputs, was the mapping from input to output discovered from data, or authored by a human? (This is the load-bearing question.)
5. Do those outputs influence anything: a user, a system, a process, a decision? (Almost always yes if Element 5 is satisfied.)

Questions 1, 3, and 5 almost always pass. Questions 2 and 4 are where the rationale memo earns its keep.

The Ten-System Tour: Practicing the Test on Real Internal Tools

Here is the L1 deliverable in concrete form, a 10-row scope memo for a fictional but representative Fortune-500 enterprise. The columns are: System, In Scope?, Article 3(1) Rationale. Walk each one slowly; the muscle you build here is the same muscle you will use on your own portfolio next week.

System 1 - Customer Service Chatbot Powered by Anthropic Claude

In scope? Yes. Machine-based (cloud-hosted). Autonomous (generates novel replies, not from a fixed list). Adaptive (Anthropic updates the underlying model; your team updates the system prompt and retrieval index). Implicit objective (be helpful, be safe). Inference (a transformer LLM, the canonical example). Output: content and recommendations. Influences a virtual environment (the user's conversation, the user's downstream actions on a billing or support workflow). Add the disclosure obligation under Article 50(1).

System 2 - Spreadsheet Formula That Computes Monthly Sales Forecast Using a Three-Month Moving Average

Out of scope. Machine-based, yes. Autonomous, no, a non-expert reading the cell formula can predict every output exactly. Inference, no, the rule is human-authored arithmetic. Even if the rule was discovered through analysis, the artifact running in production is a fixed formula. Article 3(1) Element 5 fails. The system is computation, not AI.

System 3 - Power BI Dashboard With "Smart Insights" Toggle Enabled

In scope. The Smart Insights / Analyze feature in Power BI runs anomaly detection and trend decomposition under the hood (Power BI uses an autoregressive integrated moving-average plus learned anomaly detectors). The user does not author those rules; they are learned by Microsoft on a corpus and shipped to the tenant. The model adapts as Microsoft retrains. Inference: yes. Output: predictions (anomalies) and recommendations (explanations). Influences a virtual environment (the dashboard a director reads on Monday morning). This is the canonical "shadow AI" that procurement does not flag because nobody calls it AI on the contract.

System 4 - Custom Fraud-Detection Model (XGBoost) Trained on Internal Transaction History

In scope. Trained from data (inference), can be retrained, autonomous in scoring, output is a prediction (fraud probability), output influences the transaction queue (virtual environment). If used by a credit institution and the fraud signal feeds creditworthiness decisions, also potentially Annex III §5(b) high-risk. If used purely for back-office reconciliation with human review on every flagged item, possibly minimal-risk, but still in scope for Article 4 AI literacy and any other horizontal obligations.

System 5 - HR Screening Tool That Ranks Candidate Resumes Against a Job Description Using Cosine Similarity Over Sentence-Transformer Embeddings

In scope. Annex III §4 (employment) high-risk. Embeddings are learned from data (inference). Ranking is the output (recommendation). Cosine similarity is a deterministic post-processing step, but the embeddings themselves are inferred, so the upstream system is AI. The output influences a virtual environment (the recruiter's shortlist) and a physical environment (the candidates who get a callback). NYC LL 144 separately applies if the tool is used to make employment decisions in NYC. Article 27 FRIA required at scale.

System 6 - Marketing Segmentation Using k-Means Clustering Over CRM Behavioral Features

In scope. k-Means is classical ML: the cluster centroids are learned from data, the assignment rule is learned, and the segments are inferred. The marketing team treats this as a "data analytics" tool, but Article 3(1) is provenance-based, not branding-based. In scope. Most likely minimal-risk tier (no Annex III hit, no Article 5 prohibition, no Article 50 trigger unless the segments are used in deepfake content), but still inside the literacy and inventory perimeter.

System 7 - Email Router That Forwards Inbound Customer Email to "Billing," "Support," or "Sales" Based on a Keyword List Authored by the Customer Operations Team

Out of scope. The routing rule is hand-authored. The rule is fully traceable. A non-expert can predict the routing for any input email by reading the keyword list. Element 5 fails. This is computation, not inference. The system is a deterministic rules engine and falls under product / IT policy, not the AI Act.

System 8 - Spam Filter Built on a Naive Bayes Classifier Trained on the Last 18 Months of Mail Server Traffic

In scope. Same flow as Example 7, but the routing rule is now learned from data instead of hand-authored. Naive Bayes is statistical learning, qualifies as inference. Output is a prediction (spam vs ham). The fact that the system has been in production for a decade and runs on a small VM does not exempt it. The pattern: same business outcome, different provenance, different scope status. Provenance is the determining factor.

System 9 - Tax Calculation Engine That Computes VAT, Sales Tax, and Use Tax for E-Commerce Transactions Using IRS / HMRC / Local Authority Rate Tables Updated Quarterly

Out of scope. The rate tables are authoritative external data, not inferred. The arithmetic is closed-form. No learned function. No inference. Just a heavy data-engineering pipeline plus arithmetic. Out of scope for the AI Act; in scope for everything else (tax law, audit trail, financial reporting).

System 10 - Internal Coding Assistant Built on GitHub Copilot Enterprise for the Engineering Org

In scope. GPAI-deployer perimeter. Copilot is built on an OpenAI / GitHub foundation model, which under Article 3(63) is a GPAI model. Your organization is a deployer of an AI system that integrates a GPAI model. You inherit deployer obligations under Article 26 (use according to instructions, monitor for serious incidents, log inputs/outputs where in scope, ensure human oversight). You also inherit Article 4 literacy obligations for the engineering staff. You do not inherit the GPAI provider's Article 53 obligations unless you fine-tune the underlying model substantially (Article 25 transfer of obligations).

The Rationale Memo Template - What Auditors Actually Want to See

A scope memo is not a yes-or-no flag in a spreadsheet column. It is a defensible paragraph per system that an external reviewer can read in thirty seconds. The Schellman / A-LIGN / BSI / KPMG ISO 42001 audit playbook explicitly looks for the seven Article 3(1) elements addressed, with the load-bearing element (almost always Element 5) called out explicitly. Here is the template, written for the coding-assistant example above:

"Internal Coding Assistant (Acme.dev), In Scope. The Acme.dev IDE plug-in integrates GitHub Copilot Enterprise, which in turn is built on an OpenAI Codex-family foundation model (GPAI model per Article 3(63)). The system is machine-based (cloud-hosted by GitHub); operates with varying levels of autonomy (the model generates novel code suggestions without rule-based templates); is capable of adaptiveness (GitHub regularly updates the underlying model and Acme tunes the IDE-side ranking heuristics); pursues an implicit objective (be useful to a developer); infers outputs through a transformer LLM (the load-bearing element: outputs are not produced by hand-authored rules but by a learned function over a large code corpus); produces content (code suggestions) and recommendations (which suggestion to surface); and influences a virtual environment (the developer's working file, the production code repository, and downstream system behavior). Acme is a deployer of this AI system under Article 26 and a downstream user of a GPAI model. Owner: VP Engineering. Risk Tier (provisional): minimal-risk per Article 6 (no Annex III §1-§8 hit; coding assistance is not a high-risk category). FRIA: not required. Article 50: not triggered for human-to-machine code suggestions (Article 50(1) addresses human-machine interaction in a way intended to suggest the user is interacting with a human, which a deterministic IDE plug-in does not do). Article 4 literacy: in scope for the engineering org population. Review cadence: annual; reassess on substantial modification under Article 43."

Three things to notice. First, the paragraph names every Article 3(1) element by phrase ("machine-based," "varying levels of autonomy," "capable of adaptiveness," "implicit objective," "infers," "content / recommendations," "influences a virtual environment"). That makes the rationale auditable. Second, the load-bearing element ("the load-bearing element, outputs are not produced by hand-authored rules") is called out so the reviewer does not have to guess where the analysis turns. Third, the memo immediately maps onto adjacent obligations (Article 26, Article 50, Article 4, FRIA) so the downstream policy work has a starting point.

GPAI - The Article 3(63) Overlay

Article 3(63) defines a "general-purpose AI model" as one that "displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market." GPAI is not a different scope test. It is a further classification that triggers an additional obligation set under Articles 53 and 55. The flow is:

1. Article 3(1), Is this an AI system? (Bouncer at the front door.)
2. If yes, Article 3(63), Is the underlying model a GPAI model? (Side-of-the-house question for foundation models with broad capability.)
3. If a GPAI model, Article 51, Does it cross the systemic-risk threshold (10^25 cumulative FLOPs presumption, or a Commission discretionary designation under Annex XIII)? (Top-floor question for the largest foundation models.)

For your scope memo, every system that uses an LLM, a vision-language model, an audio foundation model, or a multimodal foundation model is downstream of a GPAI model. The GPAI provider (OpenAI, Anthropic, Google, Meta, Mistral, Cohere, etc.) has the Article 53 obligations; your organization, as a deployer, has the Article 26 obligations plus the documentation flow-down from Annex XII that the provider must give you. The GPAI label affects your vendor due diligence and your downstream documentation; it does not move the AI system in or out of scope.

Common Article 3(1) Mistakes - And How to Catch Them Before the Auditor Does

Mistake 1 - "But Our Brochure Doesn't Call It AI"

Marketing labels do not control Article 3(1). The Power BI Smart Insights example above is the canonical case. Plenty of enterprise tools (the "smart something" feature, the "intelligent assistant," the "advanced analytics" module) are AI systems regardless of how procurement classified them at purchase. Use the provenance test, not the brand label.

Mistake 2 - "But the Output Is Deterministic at Inference Time"

A system with a fixed temperature of 0 still produces outputs through an inferred function. Inference is about how the function was discovered, not whether it is deterministic at run-time. A trained model with greedy decoding is still inference. So is a decision tree compiled to C. So is a learned regex.

Mistake 3 - "But We Wrapped a Rules Engine Around the Model"

Wrapping a learned model in a hand-coded post-processing layer does not exempt the system. The system is still an AI system because the upstream signal is inferred. The rules wrapper is a downstream human-oversight measure (Article 14) and a guardrail against excessive agency (OWASP LLM06). It does not undo the scope status.

Mistake 4 - "But a Human Approves Every Output"

Human approval is an Article 14 oversight design, not an Article 3(1) exemption. The system is still an AI system. The human-in-the-loop choice may move the tool to a lower risk tier in practice, but it does not pull the tool out of scope. In fact, it triggers more Article 14 documentation, not less.

Mistake 5 - "But It's Just a Pilot"

Pilots are in scope the moment they touch real users, real customers, real production data, or real decisions that affect a natural person. Article 2(8) excludes systems "developed and put into service for the sole purpose of scientific research and development." Pilots running on synthetic data in a sandbox are out of scope. Pilots running on real candidates, real customers, or real transactions are in scope from day one.

Mistake 6 - "But the Vendor Is the Provider, Not Us"

This is true in some configurations and false in others. Article 25 transfers obligations to a downstream party that substantially modifies a system or puts its own trademark on it. Fine-tuning a foundation model on internal data with a published declaration of conformity is substantial modification. White-labeling a SaaS product as "Acme HR Insights" puts your trademark on it. In both cases, you inherit the provider obligation set. The vendor defense works in clean SaaS-as-a-service relationships and fails the moment your deployment substantially modifies or trademarks the system.

The Research, R&D, and Pre-Production Carve-Outs

Article 2 of the EU AI Act lays out the scope of the regulation as a whole and defines several exclusions that intersect with Article 3(1):

• Article 2(3): Systems used exclusively for military, defense, or national-security purposes are out of scope.
• Article 2(6): Free and open-source AI systems are largely out of scope unless they are placed on the market or put into service as high-risk AI systems, prohibited under Article 5, or fall within Article 50 transparency. The carve-out is narrower than commentators often assume.
• Article 2(8), Systems and outputs used "solely for the purpose of scientific research and development" are out of scope. The key word is solely. Mixed-use systems, research and operational use side by side, are in scope.
• Article 2(10), Personal, non-professional use by natural persons is out of scope. (This protects individuals running an LLM at home, not enterprises deploying tools to employees.)
• Article 6(3), A system that would fall within an Annex III category but does not pose a significant risk of harm to health, safety, or fundamental rights, because it performs a narrow procedural task, improves the result of a previously completed human activity, detects patterns without replacing human assessment, or does preparatory work, may be carved out of the high-risk tier. The provider self-assesses and documents the reasoning. (The carve-out narrows the high-risk tier; it does not undo the Article 3(1) scope status.)

For an enterprise deployer in 2026, the practical exclusions that ever matter are Article 2(8) (research-only systems) and Article 6(3) (narrow-task Annex III carve-out). Everything else is rare or sectoral.

What Changes When You Are Wrong

A scope-memo error in one direction is more painful than in the other. Under-scoping (deciding a system is out of scope when in fact it is in scope) means you build no governance for it. When the system fails, the regulator finds out, the scope memo is in the evidence file, and the Article 99 penalty framework lights up. Article 99(3) is up to €15 million or 3% of global annual turnover for most provider failures, including failure to provide accurate information to authorities (a Stage 2 audit finding that a system was misclassified by the deployer can roll up to the provider here through the upstream chain). Article 99(2) is up to €35 million or 7% for Article 5 prohibitions. Article 99(5) is up to €7.5 million or 1% for providing incorrect, incomplete, or misleading information to notified bodies and competent authorities.

Over-scoping (deciding a system is in scope when it is out of scope) wastes money. You build governance you did not need, you train staff that did not need training, you ask Procurement to renegotiate contracts that did not have to be renegotiated. This is recoverable. It is also the safer error in 2026 because the marginal cost of governing one extra spreadsheet is small, and the marginal cost of missing one production agent is enormous.

Pragmatic guidance to the AI Governance Committee: when the Article 3(1) test is genuinely ambiguous after a five-minute reading, default into scope and let the risk-tier classification carry the weight. The risk-tier work is cheap; the regulator-explanation work after an under-scoping error is expensive.

Aligning Your Scope Memo With ISO/IEC 42001 and NIST AI RMF

ISO/IEC 42001:2023 Annex A control A.6.1.1, AI impact assessment, explicitly requires the organization to identify the AI systems within its AIMS scope, document the rationale, and re-evaluate on change. Your Article 3(1) scope memo is the ISO 42001 A.6.1.1 artifact. NIST AI RMF 1.0 function Map 1 ("Context is established and understood") similarly requires the organization to identify AI systems and their context. The same memo satisfies both: name the system, name the elements, name the regulatory consequences, refresh on change.

This is the dual-citation pattern you will use across the whole L1 program: every artifact you produce against the EU AI Act is also evidence under ISO 42001 and under NIST AI RMF. The auditors converge on the same paragraph; you do not write three.

Refresh Cadence - When the Memo Goes Stale

A scope memo is a living document. The trigger events that should send a row back to the AI Governance Committee for re-evaluation:

• The vendor adds an "AI" feature to a previously non-AI tool (the Power BI Smart Insights toggle pattern)
• The internal team replaces a hand-coded rule with a learned model (the spam filter pattern)
• The internal team fine-tunes a foundation model (Article 25 transfer-of-obligations trigger)
• The deployer puts a trademark on a previously white-label system (Article 25 trigger)
• The system is moved from a research sandbox into a production environment (Article 2(8) carve-out collapses)
• An EU Commission interpretive note or AI Office Q&A clarifies an element in a way that changes a row's classification
• An Omnibus regulation or harmonized standard changes the boundary (the Omnibus VII timeline changes did not move Article 3(1) itself, but harmonized standards under Article 40 may yet clarify edge cases)

A quarterly review of the inventory plus a triggered-update protocol on the events above is what notified bodies look for and what Schellman / A-LIGN / BSI / KPMG audit against. The cadence is in your AIMS scope document under ISO 42001 A.2.

The Tuesday Test

One last test, because it captures what this lesson is really about. Imagine it is a Tuesday in late July 2026. The CFO forwards a contract from a hiring-tech vendor. The contract auto-renews on August 1. The CFO writes: "Two minutes: is this on our list, off our list, or do we need to do something? GPAI enforcement starts in three days."

The answer is in the scope memo if you wrote one. Open the row for the vendor. Read the rationale paragraph. If the system is in scope and lands in Annex III §4 (employment), the vendor is selling you a high-risk AI system and the contract needs deployer-obligation language under Article 26, an Article 50 candidate notice plan, and a place in the FRIA backlog. If the system is in scope but minimal-risk, the contract needs Article 4 literacy assurance and Article 26 logging. If the system is out of scope, the contract is a normal SaaS contract and you tell the CFO to sign.

Each of those answers is a five-line email. The scope memo turned the question from "What do we do?" into "Which row of the memo, and what does it already say?" That is the entire point of this lesson, to make Tuesday cheap. The AI Governance Lead who can answer that email in two minutes is the one who keeps their job in the run-up to Aug 2, 2026 and the audit committee meeting that follows. The one who has to dig through procurement to figure out what the tool even is does not.

Key Takeaways

• Article 3(1) is the bouncer. Every downstream obligation hangs from this scope test. Get it right and the rest of the program inherits a stable foundation; get it wrong and every dollar of compliance spend is built on sand.
• Seven elements, conjunctive. Machine-based, varying autonomy, capable of adaptiveness, explicit or implicit objective, inference (the load-bearing element), outputs (predictions, content, recommendations, or decisions), influence on a physical or virtual environment. All seven must be satisfied.
• The load-bearing element is "infers." Provenance is the test, was the rule discovered from data (inference) or authored by a human (computation)? Same business outcome, different provenance, different scope status.
• The brochure does not control scope. Smart Insights, Advanced Analytics, Intelligent Anything, provenance test, not branding test. The "shadow AI" the procurement team did not flag is the shadow AI the auditor will find first.
• The output of every scope decision is a defensible paragraph, not a yes/no cell. Name each Article 3(1) element by phrase, name the load-bearing element explicitly, and immediately map to adjacent obligations (Annex III tier, Article 27 FRIA, Article 50, Article 4, Article 26).
• GPAI is a side-of-the-house overlay, not a separate scope test. If your system uses a foundation model, the GPAI provider has the Article 53 obligations; you have the Article 26 deployer obligations plus the Annex XII documentation flow-down.
• Under-scoping is the expensive error. Default into scope when the test is genuinely ambiguous and let risk-tier classification do the work. The marginal governance cost of one extra spreadsheet is small; the cost of missing one production agent is enormous.
• The same memo satisfies three regulators. The EU AI Act Article 3(1) scope rationale is also your ISO/IEC 42001 A.6.1.1 evidence and your NIST AI RMF Map 1 artifact. Write it once, cite it three times.
• Memo is a living document. Quarterly review plus triggered-update protocol on vendor feature changes, model replacement, fine-tuning, trademark changes, and sandbox-to-production moves. The notified body will ask for the change log.
• Make Tuesday cheap. The whole point of the scope memo is to turn ad-hoc questions into row lookups. The Governance Lead who can answer a Tuesday-afternoon contract question in two minutes is the one who survives the Aug 2, 2026 forcing function with their job intact.