{"id":5118,"date":"2026-09-01T09:00:00","date_gmt":"2026-09-01T07:00:00","guid":{"rendered":"https:\/\/www.lablogic.pl\/?p=5118"},"modified":"2026-09-13T22:48:12","modified_gmt":"2026-09-13T20:48:12","slug":"what-should-an-ai-use-register-contain","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/what-should-an-ai-use-register-contain\/","title":{"rendered":"What should an AI use register contain?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for DPOs and compliance teams \u2022 published September 1, 2026 \u2022 updated September 12, 2026 \u2022 9 min read<\/p>\n\n\n\n

\n
\n
\n\n\n\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Short answer<\/h2>\n\n\n\n

The AI Act does not require a register of AI use cases. What it does impose are three obligations for which a central inventory is a practical and evidentially strong tool. Those are the AI literacy duty in Article 4, the ban on prohibited practices in Article 5 and the transparency obligations in Article 50. Without it, demonstrating compliance is materially harder and riskier. The scope of the register therefore follows from those obligations rather than from a ready-made template. The same list will serve the obligations in Articles 25 and 26 once they start to bind in December 2027.<\/p>\n<\/div>\n\n\n\n

Why the question comes up at all<\/h2>\n\n\n\n

The record of processing activities has its basis in Article 30 GDPR and nobody asks whether to keep one. For artificial intelligence there is no such provision. The question about a register therefore looks like a question about good practice. It looks that way until the first time a client or an auditor asks where AI is at work in the organisation.<\/p>\n\n\n\n

The second reason is organisational. Artificial intelligence entered the organisation by several routes at once. Some tools were bought deliberately. Some appeared as a new feature in software used for years, and some were built by teams on general-purpose models. None of those routes ends with an entry in any list.<\/p>\n\n\n\n

The third reason concerns evidence. The regulation does not speak of a register. It does speak of informing, of oversight and of assessment. Each of those activities requires knowing what it applies to.<\/p>\n\n\n\n

\n\n

Remember<\/p>\n\n\n\n

An organisation that does not know where it has AI will not perform any AI Act obligation in a way that can be checked.<\/p>\n\n<\/div>\n\n\n\n

What to establish before deciding<\/h2>\n\n\n\n

Three obligations that already bind<\/h3>\n\n\n\n

This is the core of the answer about scope. The register should hold exactly what makes it possible to perform the obligations that apply today.<\/p>\n\n\n\n

AI literacy, Article 4, since 2 February 2025.<\/strong> Providers and deployers take measures supporting the development of AI literacy among their staff and other persons dealing with the operation and use of the systems on their behalf. The provision states expressly that the duty does not mean guaranteeing a particular level of AI literacy in individual people. It is therefore a duty of care rather than of result.<\/p>\n\n\n\n

Performing it requires knowing who uses which tool and in what role. Without that knowledge, training reaches either everyone or nobody.<\/p>\n\n\n\n

Prohibited practices, Article 5, since 2 February 2025.<\/strong> The prohibition does not depend on the risk classification or on the organisation’s role. It depends on what the system does. The register therefore has to describe the intended purpose and the manner of use precisely enough to be set against the list of prohibitions. Two new prohibitions take effect on 2 December 2026.<\/p>\n\n\n\n

Transparency, Article 50, since 2 August 2026.<\/strong> The obligations divide according to role. The provider ensures that a system interacting directly with a person informs that person of the contact with AI. It is also responsible for marking synthetic content in a machine-readable format. The deployer informs people about emotion recognition and biometric categorisation, and discloses deep fakes and published text.<\/p>\n\n\n\n

In the register this comes down to three questions for each use case. Does the system talk to people? Does it generate content? Does it process biometric data or recognise emotions?<\/p>\n\n\n\n

What to add now, so the register is not built twice<\/h3>\n\n\n\n

The obligations in Articles 25 and 26 sit in Chapter III Section 3 and start to apply on 2 December 2027 for systems under Annex III and on 2 August 2028 for systems under Annex I. They do not bind yet.<\/p>\n\n\n\n

That is not a reason to leave them out of the register. The fields they will call for are already known. Filling them in after the fact costs more than entering them straight away.<\/p>\n\n\n\n

Article 25 calls for knowledge of three things. It has to be known whose name the system runs under, whether it has been modified and whether its intended purpose has changed. These answers have to be known at the moment of the change, not a year later.<\/p>\n\n\n\n

Article 26 adds elements worth knowing well before December 2027.<\/p>\n\n\n\n