What must an AI system inventory for the EU AI Act contain?
A customer, contract or regulator now expects an AI Act inventory, and the Annex III high-risk rules apply from 2 December 2027 as amended in 2026. The inventory lists every AI system your organization builds, provides or uses, and for each one it records the role you hold, the intended purpose and the risk tier you have assigned. Your organization owns those classifications. DeployOpen prepares the inventory, the supporting records and the evidence behind each decision, but the classification is your call and must be signed off inside your organization.
The effort depends on three things: how many AI systems you run, how many of them come from third parties, and how much documentation already exists for them. A team with a dozen internally built tools and clear vendor contracts can build a first version quickly. A team with embedded AI in purchased software, shadow tools adopted by business units and no vendor documentation will spend most of its time finding systems and chasing facts. Confirm early which vendor records you can obtain, because some of the attributes you need will only come from suppliers.
Fines for most operator obligations reach EUR 15 million or 3% of worldwide annual turnover under Article 99, whichever is higher. When a market surveillance authority suspects a system is misclassified, the inventory and its documented reasoning are the first things it will ask to see. Only an independent auditor, a notified body where one applies, or a national authority can reach a legal finding on whether a system is high-risk or compliant. Your inventory should therefore show who made each decision, when, on what evidence, and when it was last reviewed.
Which tools count as an AI system under Article 3(1)?
Article 3(1) defines an AI system as a machine-based system designed to operate with varying levels of autonomy, which may adapt after deployment and which infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. In practice, the test has three parts you can check for each tool: it runs on a machine, it has some degree of independence in how it works, and it derives its outputs from inference rather than from fixed instructions alone. Software that only executes rules written out in full by a person usually fails the inference test, while a model that learns patterns from data and produces scores or recommendations usually passes it. Whether a tool adapts after deployment is a further question the inventory should record, not a precondition that settles the matter.
The Commission published non-binding guidelines on the AI system definition on 6 February 2025, alongside its guidelines on prohibited practices. Treat them as interpretive support that explains how regulators are likely to read the definition, not as a rule that binds you or a market surveillance authority. Borderline cases are where inventories fail. Rules-only software, spreadsheets with scoring logic, and vendor features labelled as intelligent or predictive all need an explicit decision. Ask each system owner which parts of the output are computed by a fixed formula and which parts are learned or inferred, and ask the vendor for a written description of the method if the answer is unclear.
For every borderline tool, record the decision and the reason in the inventory entry, including the date, the person who made the call and the facts it rests on, such as the model type, the data it uses and whether any output is generated by a learned component. An entry that says "out of scope: deterministic rules, no learned component, confirmed with vendor on the stated date" is far more useful to an assessor than a silent omission. Revisit these entries when a vendor releases a new version or adds a feature, because a tool that was out of scope can move in when its method changes. Confirm with your legal or compliance team how the decision will be reviewed, since the consequences of a wrong call fall on you as the provider or deployer.
Which fields each inventory record needs
Each inventory record should answer who owns the system, what role your organization plays, what it is for, how it is classified and who responds when it fails. The fields below follow the attributes the NIST AI RMF Playbook suggests for GOVERN 1.6, extended with the AI Act decisions that a record must support. Confirm every field against the current EUR-Lex text and your own role analysis before you rely on it.
Identity and named owners
Record the system name, a unique internal identifier, the business owner who accepts its risk and the technical owner who runs it. Add the AI actor contacts the Playbook asks for, including the people who can answer questions from a market surveillance authority. Name a person, not a team alias, because an inventory entry without an accountable individual rarely gets updated after a change. Review owners at each release and when staff leave.
Role under the Act
For each system, record whether your organization acts as provider, deployer, importer, distributor or authorised representative, or a combination. A single product can carry different roles for different business units, so note the role per deployment, not per vendor. Record the basis for the role decision and the date it was last reviewed. Confirm each role definition against Article 3 and the Article 2 scope test before you finalize it.
Intended purpose and affected people
State the intended purpose in the provider's terms and in your own operating terms, and list the groups of people the output affects, such as applicants, employees, patients or customers. Include the input data sources and the decisions the output feeds. Illustrative example: a résumé screening tool used to rank candidates has a different risk profile from the same model used to schedule interviews. Changes to purpose should trigger a new classification review.
Risk tier with Article and Annex basis
Record the risk tier you assigned, the Article and Annex point that supports it, and whether an Article 6(3) exemption applies. If the system is treated as not high-risk under that exemption, store the written assessment that Article 6(4) requires and the registration decision. Note any prohibited-practice screening result. Confirm the Annex III or Annex I reference against the current consolidated text, since the 2026 amendment changed application dates.
Documentation and source links
Link each record to its technical documentation, model cards, source code repository, data dictionary where one exists, and the change log. The Playbook suggests recording these attributes so that an assessor can trace a decision to its evidence. Store links to the version in use, not to a moving main branch. Where no data dictionary exists, record that gap as an open item with an owner and a target date.
Incident response contacts
Record the incident response plan reference, the escalation path, and the contacts for the vendor, the internal security team and the legal or compliance function. Include who decides whether an incident must be reported to a national authority. The Playbook lists incident response plans among recommended attributes, so link the plan itself. Test that the contacts still work during each quarterly or annual review of the record.
How to document a not-high-risk decision under Article 6(3)
A provider that relies on the Article 6(3) exemption must document its assessment before it places the AI system on the market or puts it into service. Article 6(4) requires that documentation to be available to competent authorities on request, and the system must still be registered under Article 49(2). The exemption is a conclusion you reach and can defend, not a label you apply after launch, so the record should be written at the point of the decision and kept current as the system changes.
- Assessment date and version: Record when the assessment was made and which version of the system and intended purpose it covers.
- Annex III category: Name the Annex III use the system would otherwise fall into, so the reader can see what was tested against.
- Criterion relied on: State which Article 6(3) condition applies and why the system poses no significant risk of harm to health, safety or fundamental rights.
- Registration reference: Keep the Article 49(2) registration record next to the assessment so the two can be matched.
- Re-assessment triggers: List changes, such as a new use case or a wider user group, that require the assessment to be repeated.
Before relying on the exemption, check the current wording of Article 6 and the Commission's draft classification guidelines with your legal counsel.
A deployer does not register the system or write the provider's technical file, but it still needs its own record when it decides a system falls outside high-risk status for its use. That record should show how the organization uses the system, not only what the vendor claims. Where the deployer's use differs from the provider's stated intended purpose, the deployer's record carries the weight, because the classification depends on the use in practice.
- Purpose in your environment: Describe the specific task, the team using it and the decisions it supports or replaces.
- Article 6(3) criterion: Record which condition applies: a narrow procedural task, improving a completed human activity, detecting decision patterns without replacing human assessment, or a preparatory task.
- People affected: List the employees, customers or applicants whose data or outcomes the system touches.
- Human review: Describe who checks outputs and whether that review is a real assessment or a formality.
- Review date: Set a date to revisit the decision and record who approves it.
Confirm with the vendor what the system was designed to do, and keep that statement with your own record.
Organizations that build a system and also use it internally hold both roles, and each role creates its own documentation duty. The provider record explains the design and the classification, and the deployer record explains the use in your own operations. Keeping only one of them is a common gap, particularly when an internal tool is later offered to customers or other business units.
- Two records, one decision: Maintain the provider assessment and the deployer record as separate documents that refer to each other.
- Consistent purpose: Use the same intended purpose wording in both, and note any internal use that goes beyond it.
- Role change trigger: Flag when an internal system is made available to third parties, since that can change the provider obligations.
- Shared owner: Assign one accountable owner who keeps both records current.
- Single inventory entry: Link both records to the inventory entry so an assessor can trace the classification from start to finish.
Check with counsel which role applies to each system before you finalize either record.
Under Article 80, a market surveillance authority that suspects a system has been misclassified can evaluate it. If the system turns out to be high-risk, the provider must bring it into compliance. A provider that misclassified the system to avoid the requirements faces fines under Article 99, so the exemption record is what separates a documented judgment from an avoidance attempt. Treat the record as evidence you may need to produce under scrutiny, not as a formality.
- Evaluation trigger: An authority may act on a complaint, a market check or information from another regulator.
- Outcome of evaluation: A system found to be high-risk must meet the high-risk requirements from the applicable date.
- Intent matters: Misclassification to circumvent the requirements is treated differently from a good-faith error.
- Fine exposure: Article 99 sets the maximum fines, which are the higher of a fixed amount or a share of worldwide turnover.
- Evidence on request: Be ready to produce the assessment, the registration and the decision history quickly.
Confirm current fine levels and the authority responsible for your market in the Act's text and with counsel.
What building an AI inventory costs and who gets paid
This table compares each cost component of an AI system inventory by who is paid, whether the cost is one-time or recurring, and what moves it up or down. No supplied figures exist for these costs, so the table describes components only; use it to build a written scope and to check every quote line by line.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal staff time for discovery and owner interviews | Your own staff (salary cost, no external invoice) | One-time for the first sweep, then recurring | Number of business units, shadow AI tools and how many system owners must be interviewed |
| Legal or compliance review of classifications | Internal counsel or compliance staff, or an external law firm | Recurring for each new or changed use case | Count of borderline Annex III uses and whether the Article 6(3) exemption is relied on |
| Implementation partner fixed-scope fee for discovery, record design and tooling set-up | Implementation partner, under a written fixed scope | One-time | Number of systems in scope, existing asset data quality and whether tooling is installed in your environment |
| Self-hosted inventory tooling licences, if any | Tool vendor or open-source project (often no licence fee) | Recurring where a commercial licence applies | Open-source versus commercial choice and the number of users who edit records |
| Hosting and operation of the inventory platform | Your cloud provider or data center, or a managed operator | Recurring | Infrastructure location, backup and access controls, and whether it runs air-gapped |
| Ongoing maintenance of records as systems change | Internal AI governance owner, or a retainer partner | Recurring | Release frequency of AI systems, model swaps and vendor changes that trigger record updates |
| Independent assessment where an auditor later examines the inventory | Independent auditor or certification body, if engaged | Recurring at each audit cycle | Whether the inventory is needed as evidence for a certification or customer audit, and its completeness at that point |
How the inventory is built in five phases
The sequence moves from finding every candidate AI use, to recording each one consistently, to classifying it, approving the result, and keeping the register current as systems change.
Find every candidate AI use
Collect candidates from business units, IT and procurement records, vendor contracts, software subscriptions, and the tools staff use without formal approval. Ask each function to name the systems that generate predictions, content, recommendations or decisions, including features that vendors have switched on inside existing products. The output is a candidate list with one line per suspected system, the function that raised it, and the vendor or internal team behind it. You know this step is done when every business unit has confirmed in writing that its list is complete.
Record each candidate against the field list
Open one record per candidate and fill every field of your agreed template: system name, owner, business purpose, users, data sources, vendor or internal build, hosting location, and links to documentation. Record whether your organization develops the system, puts its own name or trademark on it, deploys it, or only buys access to it, because that role drives later obligations. Where information is missing, mark the field as open and assign it to a named person rather than leaving it blank. The output is a populated record for each candidate, and the step is complete when no record has an unassigned open field.
Run the first-pass classification
Test each candidate against the Article 3(1) definition of an AI system, which turns on a machine-based system with varying autonomy that infers from its input how to produce outputs. Check whether any Article 5 prohibited practice applies, then compare the intended purpose with the Annex III use areas and, where relevant, the Annex I product rules. Record the result as one of the risk levels the Commission describes, along with the reasoning and the Article 6(3) analysis for any Annex III system you believe falls outside high-risk status. The output is a first-pass classification on each record, prepared by the inventory lead and the system owner together.
Approve the classification and document exclusions
Route each classification to the accountable business owner and to legal or compliance for sign-off. For any Annex III system you conclude is not high-risk under Article 6(3), write a documented assessment before the system is placed on the market or put into service, as Article 6(4) requires, and keep it available to produce on request. Confirm which systems carry a registration duty and which carry transparency duties, and record the decision date and approver. The output is a signed classification on every record and a file of not-high-risk assessments, and the step closes when no record is awaiting approval.
Maintain the register through change and procurement
Tie the inventory to the processes that create change: change requests, new vendor onboarding, contract renewals, software purchases, and model or feature updates from existing suppliers. Require that no new AI use reaches production without an inventory entry and a classification, and re-run the classification when the purpose, user group, data or degree of autonomy changes. Review the register on a schedule your governance policy sets and reconcile it against procurement and asset records. The output is an inventory that stays current, with a dated change history on each record that an assessor can follow.
What makes the inventory larger, slower or more expensive
The AI inventory grows with the number of systems, the places their output is used and how often they change. Each driver below pairs a common source of effort with one control that keeps the inventory current and the cost of maintaining it predictable.
Embedded AI in vendor products
Many AI features arrive inside software the organization already licenses, such as résumé screening in an HR suite or fraud scoring in a payments platform. These are easy to miss because no one bought an AI system. Require a procurement gate that asks every vendor whether its product contains AI features, and record each embedded feature as its own inventory line with the vendor as the provider.
Multi-country and multi-unit output
Article 2 reaches non-EU providers and deployers whose AI output is used in the EU, so a system built in one country can still be in scope through a business unit in another. Ask each business unit to record where the output is used, including customers and staff in EU member states. Assign one owner per jurisdiction so the inventory reflects where outputs land, not only where the system is hosted.
Third-party tools without documentation
Staff adopt AI tools, including generative assistants and browser plug-ins, that have no contract, no vendor documentation and no security review. These tools drive the most inventory work because the organization must still establish the role and purpose before it can classify them. Set a rule that unreviewed tools cannot process company or customer data, and log each request as an intake record even when the answer is no.
Existing asset and vendor registers
Asset registers and vendor lists rarely record purpose, data types or decisions made by a system, so teams must reconcile them before they can serve as an AI inventory. Check whether existing registers capture application owners and vendor contracts. Map each AI system to its existing asset identifier to avoid duplicate records, and add the missing attributes such as intended purpose and risk tier as new mandatory fields.
Decisions needing legal review
Classifying a system as not high-risk under Article 6(3) requires a documented assessment before the system is placed on the market or put into service, and that documentation must be provided on request. Each such decision therefore takes legal and compliance time, and the volume of exemption claims drives the review workload. Route every exemption claim through one review queue with a named approver and a stored written rationale.
Frequent system changes
A system that is retrained, extended to a new use or connected to new data can move into a different role or risk tier without anyone flagging it. Changes to purpose are the most likely trigger for reclassification, and reclassification can also follow a regulator's review under Article 80. Require a change notice from each owner whenever the model, data source or intended purpose changes, and re-review the entry before the change goes live.
How NIST AI RMF and ISO 42001 practice shape the inventory
The NIST AI Risk Management Framework gives the inventory its starting logic. Under GOVERN 1.6, in the Govern function's policies, processes and procedures category, the outcome is that mechanisms exist to inventory AI systems and that they are resourced in line with organizational risk priorities. The companion NIST AI RMF Playbook suggests three practical moves: define how the inventory is created and who maintains it, inventory all models and systems where possible (or at least the high-risk and high-stakes ones), and record attributes such as documentation, source code links, incident response plans, data dictionaries and AI actor contacts. Treat the framework as a voluntary reference. It has no certification, so no one can be certified against it, but an assessor reviewing your program will still expect to see who owns the register and how it is kept current.
An ISO/IEC 42001 management system also needs a controlled inventory of AI systems, because the standard expects an organization to know what AI it develops, provides or uses and to manage that knowledge under its documented information controls. One register can serve both purposes, provided it has an owner, a change process and a review cadence. Confirm the current inventory-related requirements and Annex A control wording directly in the standard before you design the register's fields, since the standard text is not reproduced here and its controls may be read differently by your certification body.
The AI Act inventory still has to carry fields that neither framework defines. Record the organization's role for each system (provider, deployer, importer, distributor or authorized representative), the intended purpose, the risk tier reached under Article 6, and, for any system treated as not high-risk under Article 6(3), the written assessment that supports that decision. Also record whether the system is subject to Article 50 transparency duties. A practical check is to take one system already on the list and ask whether a market surveillance authority could confirm its role and tier from the register alone, without interviews.
Who owns each part of the inventory
Your organization owns every classification decision. That includes deciding whether each AI system is an AI system under Article 3(1), which role you hold for it, whether it is high-risk, and whether an Article 6(3) exemption applies. The business owner of each use case signs off the stated intended purpose, because that purpose drives the risk tier. Legal or compliance review checks the reasoning, especially for borderline cases and for any decision not to treat a system as high-risk.
- Classification ownership: A named accountable person records each tier and the reasoning behind it, and updates it when the purpose or data changes.
- Business owner sign-off: The team that runs the system confirms its purpose, users, affected people and deployment context in writing.
- Legal review: Counsel reviews exemption decisions and any system where the outcome carries material fine exposure under Article 99.
- Registration decision: Where Article 6(4) or Article 49(2) applies, your organization decides whether to register and keeps the documented assessment.
- Ongoing upkeep: Someone internal owns the inventory after handover, so new tools and vendor features are added before they go live.
Check that every entry in the register has a named owner who can explain the classification without the partner in the room.
An implementation partner prepares the inventory and the evidence behind it. Discovery support means helping your teams find AI systems, including features embedded in existing software and tools adopted by individual departments. Record design means agreeing which attributes each entry holds, such as role, intended purpose, data sources, model provenance, owners and documentation links. The partner can set up tooling, populate the register, and prepare the evidence pack for your owners to review.
- Discovery support: Structured interviews, procurement reviews and system scans to surface AI use across the estate.
- Record design: A schema for each entry and a rule set for how fields are completed and versioned.
- Tooling set-up: Configuration of a self-hosted inventory or governance tool inside your environment.
- Evidence preparation: Assembling the records, decision logs and exemption documentation that your owners then validate.
- Handover: Runbooks, training for owners and a documented process for keeping the inventory current.
The partner does not classify systems on your behalf as a legal determination, and it does not issue reports or certificates. Confirm in the written scope which of these deliverables are included and who signs each one.
Independent parties test the inventory; they do not build it. An assessor or auditor examines the records, checks whether each classification is supported by the stated purpose and evidence, and tests whether the process for keeping the register current works in practice. Where a national market surveillance authority suspects a system has been misclassified, it can evaluate the system itself under Article 80, and a provider that misclassified a system to avoid requirements faces penalties under Article 99.
- Record review: Sampling entries and checking that attributes are complete and consistent with system behavior.
- Classification testing: Asking whether the stated tier follows from the intended purpose and the Article 6 analysis.
- Documented exemptions: Checking that each Article 6(3) decision was written down before the system was placed on the market or put into service.
- Formal findings: Only the independent auditor, assessor or authority issues a formal finding or report.
- Follow-up: Tracking corrections and re-testing after changes.
Ask any external reviewer to state in writing what they will test and which evidence they expect to see.
Questions buyers ask before building an AI inventory
How much internal effort does an AI system inventory take?
The effort depends mostly on how many AI systems the organization uses, how many of them are built in-house versus bought, and how many teams hold the knowledge about each one. Discovery is usually the largest task, because AI features often arrive inside SaaS products, analytics tools and vendor platforms that no one has listed. Each entry then needs an owner, a description of intended purpose, the organization's role for that system, and a first-pass risk view. Ask any partner to size the work from a written list of discovery sources and a count of systems in scope, not from a headline figure.
Can our team build the AI inventory without outside help?
Yes, a capable internal team can build the inventory, provided it has a clear owner, access to procurement and engineering records, and time from the business units that use AI. The hard parts are consistency and completeness: applying one definition of an AI system across teams and finding tools that staff adopted without approval. Outside help is most useful for a defined scope, such as a discovery sweep, a classification workshop or a template built to fit the organization's existing asset register. Any engagement should begin with a written scope and deliverables agreed before work starts.
How long does it take before the AI inventory is usable?
Time to a usable inventory is driven by four factors: the number of systems to find, how well procurement and IT asset records are kept, how many decisions need legal or compliance review, and how quickly business owners respond. A first version that lists systems and owners can often be produced well before every classification question is closed, and that version is still useful for planning. Ask for milestones tied to specific outputs, such as a reviewed list of systems and a signed-off set of not-high-risk decisions, rather than a single completion date.
Will an auditor test our AI system inventory?
An assessor will look at whether the inventory exists, whether it is complete against evidence such as software purchase records and network or cloud logs, and whether each entry has a named owner and a classification rationale. Under the AI Act, the risk tier and any Article 6(3) exemption need to be supported by documented reasoning that a market surveillance authority can review on request. Independent auditors and certification bodies issue any report or certificate. A partner can prepare the inventory and its evidence, but it does not provide the assessment itself.
Does a decision that a system is not high-risk need to be recorded?
Yes, when a provider relies on the Article 6(3) exemption, Article 6(4) requires documentation of the assessment before the system is placed on the market or put into service, and that documentation must be provided on request. The provider must also register the system under Article 49(2). Under Article 80, a market surveillance authority that suspects misclassification can evaluate the system, and misclassifying a high-risk system to avoid requirements can attract fines under Article 99. Record the decision, the reasoning, the reviewer and the date for every system you do not classify as high-risk, and review it when the purpose or context changes.
Can the AI inventory be reused for ISO/IEC 42001?
A well-built inventory supports both programs, because an AI management system needs a clear view of the AI systems in scope, their owners and their risks. The inventory can carry the same fields used for AI Act classification, plus the attributes that an AI management system typically reviews. The two frameworks ask different things, though, so the inventory is a shared input rather than a complete ISO/IEC 42001 record. Confirm the required scope and evidence with the certification body and with the standard itself before you plan the reuse.
What does the partner need from our organization to start?
A partner needs named access to the people who buy, build and operate AI, along with read access to procurement records, software and cloud inventories, vendor contracts and any existing model or data documentation. It also needs a decision-maker who can settle definitions, approve the classification method and resolve disputes between business units. Expect to supply a list of known AI tools and projects before discovery begins. Requests for access and a named contact should be part of the written scope so both sides know what is provided and by when.
How do we keep the AI inventory current after go-live?
Keep the inventory current by tying it to the processes that already change AI use: procurement approvals, new vendor onboarding, change requests and project intake. Assign each entry an owner who confirms it on a fixed review cycle and whenever the intended purpose, data or user group changes. Connect the inventory to incident response so that any AI-related incident leads to an entry review. Ongoing support and periodic reviews can be arranged as a retainer, with the scope agreed in writing.
How DeployOpen builds the inventory and the evidence behind it
DeployOpen plans and builds the AI system inventory inside your own infrastructure, using self-hosted open-source platforms for the records, approvals and evidence behind it. Your organization owns each classification decision, and an independent auditor or certification body issues any report or certificate.
How we scope
- Written scope lists which business units, AI systems and third-party tools the inventory covers before work starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing with your team first.
- Scope sets who owns each inventory field, such as the business owner, technical owner and AI actor contacts.
How we build
- We deploy the inventory register in your environment and configure fields for role, intended purpose and risk tier.
- We set up a documented workflow for recording Article 6(3) not-high-risk decisions with the reasoning and sign-off.
- We map inventory attributes to NIST AI RMF GOVERN 1.6 and ISO/IEC 42001 practice where your program uses them.
How we hand over
- You receive the populated inventory, the field definitions and the written procedure for keeping it current.
- Handover covers who maintains the register, how new AI uses are added and how retired systems are closed out.
- Evidence such as decision records and review dates is stored in a format your assessors can inspect on request.
How we support
- Ongoing support and periodic inventory reviews are available as a retainer, scoped in writing.
- Upgrades and changes to the self-hosted register are documented and tested before they reach production.
- Confirm with your legal and compliance team which classification conclusions they will sign, since DeployOpen does not issue legal opinions.
