The register has product names, vendors and contract owners. Every approved AI tool appears on one line. Yet nobody can say whether the same service drafts marketing text, ranks job applicants, summarizes customer calls or supports a safety decision.
The tool is visible. Its use is not.
Fact: the issue in 30 seconds
Direct answer. An AI inventory needs more than a catalogue of products. A useful record describes the task or decision use, people affected, data path, accountable owner and event that triggers reassessment. Those fields do not classify a system under law or prove that its use is appropriate. They preserve the context required for later review.
The hidden variable is deployment context. The same product can support different tasks, data flows and consequences in different teams.
Why the tool list feels sufficient
Procurement and security systems are organized around vendors and applications. A product name is a convenient stable key for contracts, access reviews and renewals.
The operational decision often sits one level below the product. A general service may support several purposes. One use may be reversible and low consequence; another may shape a decision affecting a person. One vendor row cannot express that difference.
PARAVEILUX inference. Recording the product is not the same as recording every material use.
What the source record supports
Regulation (EU) 2024/1689 establishes harmonised rules concerning artificial intelligence in the European Union. The NIST AI Risk Management Framework is voluntary institutional guidance. These sources operate in different ways and scopes.
They do not support a universal claim that every tool is within EU scope, every use has the same classification or a particular inventory design satisfies a legal duty. Applicability can vary with the current law, jurisdiction, role, use, affected people and evidence.
Action: move from product to decision use
Keep the vendor and product fields, then add a separate entry for each materially distinct use. Describe what goes in, what the system does, what comes out, who reviews the output and which task or decision follows.
Name affected people or operations without assuming a legal category. Record data sources and destinations at a level that privacy and security reviewers can test. Identify business and technical owners and the review lane.
The result remains an inventory. It is not an assessment conclusion.
Worked example — fictional
One approved writing assistant appears once on the vendor register. In practice, the communications team uses it to suggest low-stakes headline variants, while recruitment uses the same service to summarize interview notes before a hiring discussion. Separate use-case entries reveal different people, data, review paths and consequences without claiming a legal classification for either use.
A proportionate factual record
For a bounded first pass, record:
- tool, provider, version or service tier where known;
- business task or decision use;
- input and output categories;
- affected people or operations;
- human review and override path;
- business and technical owners;
- approved environment and access boundary;
- known dependencies; and
- material-change and review triggers.
Use Unknown or Not assessed rather than turning a missing field into a reassuring answer. A simple use may justify a short record. Proportion matters; complexity is not the goal.
Signal: signals and counter-signals
Investigate when one product row hides several uses; no one can state what decision follows the output; a new data source is added without review; the output moves from optional reference to a required step; or the recorded use differs from practice.
Counter-signals include a plain-language use description, named owner, bounded data path, version or tier, review route and material-change trigger. These improve visibility. They do not establish performance, legality or effective human oversight.
The hidden variable
The hidden variable is the distance between available capability and actual operational role. Product descriptions explain what a service can do. The inventory should explain what this organization uses it to do, under which boundaries and with which unresolved questions.
That distinction lets the owner send a real question—rather than a product name—to the qualified reviewers.
Limitations: what this does not prove
An inventory does not classify a system under the EU AI Act, determine legal duties, establish compliance, validate performance or prove that human review works. It does not resolve privacy, security, intellectual-property, employment or sector questions.
It may also be incomplete. Informal uses can exist, and declared use can differ from practice. Legal scope, organizational coverage, system performance and completeness remain Not assessed.
Owner Q&A
Does every experiment need a full record?
Not necessarily. Define a proportionate intake boundary and preserve why a use received lighter treatment. Specialists should review the design.
Can one tool have several entries?
Yes, when it supports materially different tasks or data paths. That is an operational design choice, not a legal classification.
Which field anchors the record?
The decision-use description. Without it, the surrounding fields have no stable context.
Next verification
Ask whether one product name hides materially different uses, people or data paths in your organization. Before relying on any classification or deadline, check the current rules for the relevant jurisdiction, role and use rather than importing the EU or NIST context as a universal answer.
Sources and limitations
- Regulation (EU) 2024/1689 — official EU source; reader-specific applicability and classification are Not assessed.
- NIST AI Risk Management Framework — voluntary US institutional guidance on context-sensitive AI risk management.
This is general risk education, not professional or certified advice. The EU and NIST sources describe different bounded contexts; whether a comparable issue can arise for you depends on current local rules, facts, roles, uses, contracts, systems and evidence.