BLUF: Treat AI use-case intake as a versioned technical control, not a spreadsheet exercise. Before a team buys a model, connects data or starts a pilot, record the intended purpose, affected people, decision authority, model and supplier, data flows, process integration and accountable owner. Compile those facts into an applicability graph. Policy rules can then return a concrete control pack and block procurement or deployment when required evidence is missing.
This is an engineering pattern for repeatable evidence; it is not legal classification. The EU AI Act is risk-based and its obligations depend on the system, its intended purpose and the relevant actor. Article 3 supplies definitions; Article 6 and Annex III are important classification entry points for high-risk cases. The European Commission overview explains the risk-based framework and identifies high-risk use-case families. Counsel must decide the legal position for a specific case.
Why inventories fail once AI touches operations
A row reading “sales copilot — low risk” cannot answer what a reviewer, security engineer or procurement lead needs to know. Which version of which model is used? Does a vendor retain prompts? Which business process receives the output? Can it influence employment, credit, safety or access to a service? Who can stop it? A flat register also loses the relationship when one vendor supplies multiple models, or one model feeds several workflows with different affected groups and controls.
The answer is not a giant ontology project. Start with a small, versioned intake schema and make relationships first-class. The resulting graph supports a defensible “show me every use case affected by this vendor change” query. It also extends the operational discipline in structured LLM output as an API contract: an AI system needs explicit contracts at both the output boundary and the governance boundary.
The minimum intake schema
Use immutable IDs and version every submitted assessment. A practical first schema has six objects: UseCase, ModelDeployment, Supplier, DataAsset, BusinessProcess and AffectedGroup. Each object has an owner, lifecycle state and evidence references; edges carry meaning, not merely a foreign key.
UseCase: purpose statement, user role, decision/action authority, geography, lifecycle state and business owner.
ModelDeployment: model family/version, hosting region, modality, configuration, release ID and technical owner.
Supplier: contracting entity, service/subprocessor evidence, change-notification route and procurement owner.
DataAsset: classification, source, retention, personal-data flag, access policy and data owner.
BusinessProcess: process owner, downstream system, reversibility, human-approval point and outage fallback.
AffectedGroup: people potentially affected, impact type, scale and escalation contact.
Reference flow: intake to deployment gate
Diagram / lifecycle: Requester submits versioned intake → validation service checks required fields and evidence links → graph store resolves model, supplier, data, process and affected-group edges → policy engine evaluates purpose and signals → control-pack service assigns owners and due dates → procurement and CI/CD gates allow, hold or reject deployment → immutable assessment snapshot and audit event are stored.
The graph is not a prediction engine. It is a traceability system. Its key output is an explainable result: policy version, input facts, matched rules, evidence references, control owners, expiry date and decision. Store that snapshot append-only. If a policy changes later, rerun deliberately; never overwrite the historical assessment.
Policy-as-code: rules should return work, not only colours
A useful rule is declarative and testable. For example: if a use case has an employment-related purpose signal, an affected-person group and a model connected to an external supplier, return a “legal review + data protection review + human-oversight design + supplier evidence” pack. The rule does not declare the system high-risk; it detects facts that deserve review. Another rule can hold a deployment when the model version or supplier data-processing evidence is absent.
Keep legal conclusions separate from engineering state. “Annex III classification confirmed” should be a counsel-controlled assertion with source, date and scope. “No production release without assessment snapshot” is an engineering control. The distinction prevents an intake service from pretending to provide legal advice while still making missing evidence operationally visible.
Decision table: when the gate should stop deployment
| Signal | Policy result | Gate | Control owner |
|---|---|---|---|
| Model or supplier unknown | incomplete intake | block procurement and CI/CD promotion | product owner |
| Purpose affects employment, essential service or another Annex III-relevant area | classification review required | hold production release | legal/compliance lead |
| Personal or sensitive data with external processing | privacy/security review required | block connector credentials | data protection and security |
| Action can change a business record or decision | authority boundary required | require approval and rollback design | process owner |
| Evidence older than the defined re-assessment interval | assessment stale | block material model/configuration change | use-case owner |
Put gates where change actually happens
Procurement is the first gate: no purchase order, sandbox tenant or API key before a valid use-case ID and named supplier edge exist. CI/CD is the second: deployment manifests should reference the assessment snapshot, approved model deployment and current control-pack status. Runtime is the third: the service exposes the assessment ID, model release ID and policy decision in telemetry. This follows the same principle as an operating boundary for connected AI workflows: access and action must be constrained before scale, not reconstructed after an incident.
Do not force every experiment through a months-long committee. Use tiers. A local, non-production experiment with synthetic data can receive a short-lived sandbox pack. A system that handles personal data, changes records or reaches affected people should collect richer facts and expire sooner. Fast paths still need an owner, scope and automatic expiry.
Failure modes to test before rollout
False completeness: required fields are filled with generic text. Mitigation: make evidence typed and verifiable; reject “TBD” for release-critical facts.
Graph drift: a vendor changes a model or data-processing term but the use case still points to an old node. Mitigation: ingest supplier-change events, mark connected snapshots stale and require re-assessment.
Bypass through a sandbox: a team creates an API key outside procurement. Mitigation: centralise credentials and require an assessment ID in gateway policy.
Over-broad rules: every intake returns the same heavy pack. Mitigation: test rules against known cases, publish rationale and measure false holds.
Snapshot mutation: a reviewer cannot reconstruct the facts used for approval. Mitigation: append-only snapshots, policy version hashes and immutable evidence references.
What this does not solve
An applicability graph cannot by itself decide whether an AI system falls under a legal category, replace a fundamental-rights assessment, solve data-protection compliance or make a weak model safe. It also introduces maintenance cost: owners must update relationships, suppliers must be monitored and rules need regression tests. The engineering recommendation is to make these costs explicit and focus the first release on the decisions that currently cause delay or uncontrolled deployment. Legal interpretation and sector-specific obligations require qualified counsel.
A practical 30-day start
Pick ten live or proposed use cases. Define the six objects, five edge types and three release-blocking rules above. Import only authoritative source records, give every object an owner, and create one query: “which production use cases depend on this model, vendor or data asset?” Then wire the result into procurement and one deployment pipeline. A short architecture workshop can turn that pilot into a scoped graph, control-pack and evidence design.
Sources
Regulation (EU) 2024/1689 (AI Act): Articles 3 and 6; Annex III
