New signups are temporarily closed.Existing customers can still sign in. Contact us to be notified when we reopen.
Skip to main content
Documentation

EU AI Act

Registering your systems

The system inventory is the foundation of the platform. Every risk classification, checklist, document and piece of evidence attaches to a registered system, so an incomplete inventory produces a confident-looking but incomplete compliance picture. The inventory covers both AI systems and conventional IT systems, since both carry obligations under GDPR and the operational-resilience frameworks.

Transcript

Every AI system, and every conventional IT system touching personal data, is registered in your inventory. Let's add one.

An inventory is not bookkeeping. GDPR Article 30 requires a written record of processing activities, and the AI Act's Article 11 documentation duty cannot be discharged for a system nobody has written down.

The first question is whether this is an AI system at all. The AI Act's Article 3, paragraph 1 turns on inference: a system that infers from its input how to generate predictions, content, recommendations or decisions.

A recommendation engine or a language model infers. A CRM database or a spreadsheet does not. Choosing correctly decides whether the AI Act applies to this system at all.

Name the system, then name an owner. Assigning an accountable person is what makes the AI Act's Article 26 deployer obligations enforceable inside your organisation.

Intended purpose is the most consequential field on this form. Risk classification under the AI Act's Article 6 turns on what the system is used for, not how it was built, so a vague purpose produces a meaningless classification.

Record the data it processes, including categories of personal data. This feeds both the AI Act's Article 10 data governance duties and your GDPR record of processing.

If it processes personal data, the same form captures the lawful basis, retention period, data categories, storage location, and whether data crosses the UK or EEA border. This is exactly what later fills your GDPR record of processing, not a separate exercise.

On save, the system joins your inventory and becomes the anchor every assessment, checklist, document and piece of evidence attaches to.

Résumé Screening Assistant is now in the inventory, which is the thing every other module reads from. Nothing else in the platform can act on a system it hasn't been told about.

Every framework you've enabled recalculates against the full inventory, so this one registration moves your AI Act and GDPR scores at the same time.

The registration itself becomes evidence. This entry is what you hand an assessor when they ask how a system entered your inventory, not just that it did.

Why this is required

Two separate legal duties converge on the inventory. GDPR Article 30 requires controllers to maintain a written record of processing activities and to make it available to the supervisory authority on request. The AI Act's Article 11 technical documentation duty simply cannot be discharged for a system nobody has written down.

The AI Act also draws a bright line that determines whether it applies at all. Article 3(1) defines an AI system by inference: a machine-based system that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations or decisions influencing physical or virtual environments.

That distinction does real work. A recommendation engine, a fraud model or a language model infers. A CRM database, an accounting package or a static website does not. Getting this answer wrong in either direction is costly: classify a genuine AI system as ordinary IT and you miss the entire AI Act obligation set; classify your invoicing software as AI and you generate a large amount of work the law never asked for.

Conventional IT systems still belong in the inventory, because GDPR Article 30 and DORA's ICT asset requirements do not care whether a system uses machine learning. They are simply tracked under a different obligation set.

What EuroCompliant does

Registration begins by asking explicitly whether the system is an AI system, with the AI Act's Article 3(1) definition and worked examples on the page, rather than inferring it from the product name.

Each registered system gets a System Card: owner, vendor, intended purpose, data processed, deployment status, version and risk owner. For AI systems this is the record that later becomes the general description required by the AI Act's Annex IV; for conventional systems it feeds your GDPR record of processing and operational-resilience registers.

The system detail page is the per-system workspace, with tabs for risk assessment, compliance checklist, generated documents, post-market monitoring, incidents and the fundamental rights assessment. Non-AI systems skip the AI-specific tabs and carry their GDPR and operational obligations instead.

Bulk import accepts CSV or JSON for organisations onboarding a large existing estate.

Walking through it

1

Register every system, AI or not

Add each AI system and each conventional IT system that processes personal data or matters for operational resilience. The platform tracks both; the AI Act's Article 3(1) inference test decides which AI-specific obligations a given system carries.

Open /systems/new →
2

Decide whether it is an AI system

Apply the Article 3(1) inference test. If the system produces outputs by inferring from input data rather than by executing rules a person wrote out in full, it is in scope.

Open /systems/new →
3

Name an owner and a risk owner

The owner runs the system day to day. The risk owner is accountable for its risk posture; the AI Act's Article 9(3) assumes a named accountable person for high-risk systems.

4

Write the intended purpose precisely

This is the single most consequential field. The AI Act's Article 6 classification turns on what the system is used for, not how it was built, so 'improves customer experience' produces a meaningless classification while 'ranks job applicants for shortlisting' produces a correct one.

5

Record the data it processes

Including the categories of personal data. This feeds both the AI Act's Article 10 data governance obligations and your GDPR record of processing.

6

Record vendor and version

For third-party models, capture the vendor's model version. The AI Act's Article 12 traceability and vendor change management both depend on knowing which version was running when.

The law

Frequently asked

Is a chatbot built on a third-party model our responsibility?

Yes. Using a vendor's model does not remove your obligations: as the deployer you carry Article 26 duties, and if you put the system on the market under your own name or substantially modify it, you may be a provider of it under Article 25.

Should we register systems still in development?

Yes, with the deployment status set accordingly. Article 11 requires technical documentation to exist before the system is placed on the market, so documentation work needs to start during development, not after.

What about a spreadsheet with a forecasting formula?

Almost certainly not an AI system. Recital 12 excludes systems based on rules defined solely by natural persons to automatically execute operations. A regression a person specified is rules; a model that learned its own parameters is inference.

Related guides

Try it on your own systems

Everything in this guide runs in the live product. Start a free trial and follow along with your own data.

Start free trial