An AI Act register that sets legal scope before using a model

The AI Act ties obligations to an organization's role and a system's risk status. Yet knowledge about AI tools is often scattered across contracts, card statements, spreadsheets, and employees. The first job is to establish an owned inventory. Drafting support comes later.

The order: human, gate, model, human

In the AI Act documentation workbench we built and use ourselves, the model gets a narrow, well-fenced role. The controlled scenarios contain no client data and cannot change the internal register.

The operator supplies the system's approved role and risk status. Rules in code use those decisions to select a closed set of articles before the model is called. The model then drafts reasons and a gap list in a fixed data format, with a limit on steps and no access to system tools. People remain responsible for the inventory, evidence, and decisions about closing gaps.

Three separate controls reject an article outside the approved set: the domain type in code, the list of allowed values in the response format, and a foreign key in the database. An out-of-scope article could reach the register only if all three failed at once.

The minimum operating model

Each system record should have business and technical owners, an approved organizational role, risk status, purpose, provider, data categories, users, and evidence state. Every obligation should lead to a specific document or named gap, an accountable person, and a due date.

The register also needs update triggers. A new purchase, material model change, new data source, or changed use should open a review. Without those events, a well-designed register becomes an archive.

Scope as a product boundary

The system covers six selected AI Act articles and states that scope openly. It is a working register, with every supported obligation linked to evidence, an owner, and its current material state. It does not provide legal advice or certify compliance.

The nine-combination matrix of roles and statuses selected the expected scope every time. A separate high-risk-provider run matched the expected article set and added none outside the gate. It checks the application contract for one controlled scenario. A complete legal assessment requires broader coverage, current sources, and accountable specialists.

A staged implementation method

1. Discover systems through procurement, IT, security, finance, and departmental interviews.
2. Assign an owner to each entry and create a queue for unowned items.
3. Approve controlled vocabularies for roles, statuses, and supported obligations.
4. Link each obligation to evidence, a gap, a due date, and an accountable person.
5. Add a scope gate before drafting and validation before persistence.
6. Define events that trigger a new review.
7. Test the auditor export and change history.

A useful pilot includes systems from different acquisition paths: centrally purchased software, a departmental subscription, and an internally built application. This tests discovery, ownership, and day-to-day operation of the register.

Failure modes and tradeoffs

A common failure is automatic classification from an incomplete questionnaire. Another is a gap list with no owner, which produces documentation without follow-through. SDK and legal-source versions also require monitoring. An integration failure or changed guidance should create an explicit state instead of silently reusing an old result.

Narrow scope improves testability and speed of implementation, but unsupported obligations must be visible. Expanding the catalog should include matrix tests, data-migration rules, and expert review.

Reading the evidence and cost

The controlled case covers 14 synthetic entries, six supported articles, and a scope matrix. Its recorded model cost applies to one drafting run. It excludes organizational discovery, legal assessment, evidence gathering, and owner time.

A pilot should measure inventory completeness, records with an owner, obligations without evidence, time from identified gap to closure, and records reviewed after a change. Those measures reveal process maturity better than the volume of generated rationale.

Our own entry in the register

Our own entry sits in the register, including its open finding. Buyers can therefore inspect how the vendor applies the process to its own system.

The same pattern applies in other regulated areas. Approved classifications should drive rules that establish scope before a model runs. The model prepares material within a fixed format, while accountable people decide legal meaning and completeness.

Details and measurements on the case page. If AI-system inventory at your company happens by interview, a free process scan is a good first step toward a register with owners.