Most staff AI use is not high-risk

Annex III names the uses the Act treats as high-risk, and employment is one of the areas on it: recruitment screening, task allocation, and decisions affecting promotion or termination.

An employee pasting a draft into an assistant to rewrite it is not any of those. A system that scores candidates, or that ranks staff for progression, is a different matter and brings the heavier obligations with it.

Not legal advice. The classification turns on what the system is used for in your organisation, and that determination belongs to your counsel rather than to a vendor.

Article 4 asks providers and deployers to ensure a sufficient level of AI literacy among the people operating these systems, taking account of their technical knowledge and the context of use. In practice that is training and a policy, not a control.

Article 50 covers transparency: where a person is interacting with an AI system, or where content is generated by one, that should be apparent. For most internal use this is a disclosure question rather than an engineering one.

Neither obligation is satisfied by a tool. They are satisfied by what your organisation tells its people, which is why the policy does more work here than the technology does.

A prompt carrying personal data is a processing operation and, where the provider is outside the EEA, a transfer. Both were true before the Act and remain the sharper obligation for day-to-day use.

Monitoring staff for that behaviour is itself processing, with its own lawful basis to establish and its own proportionality test. Both sides of that are where most of the actual work is.

The deployer and provider distinction is usually presented as fixed, and for most organisations it is. There is a boundary worth knowing about, because crossing it is easy to do without a decision.

Using an assistant as supplied leaves you a deployer. Putting a system on the market under your own name makes you a provider. The uncertain ground is in between: substantially modifying a system, or deploying one under your own branding, can shift obligations toward you. A team that fine-tunes a model on internal data and exposes it to customers as a product feature has done something materially different from switching on an assistant, and may not have framed it that way internally.

Where a product team is doing this, the determination belongs with counsel before launch rather than after, and the input they will ask for is specific: what the base model is, what it was trained on further, what it is exposed to, and who sees the output. Worth settling while it is still a project rather than a release.

Whatever the obligations turn out to be for a given organisation, they all start from the same place: knowing which AI systems are in use, by whom, and for what. Almost nobody has that list, and almost every assessment asks for it.

A workable register records the system and its provider, the business purpose, who uses it, what categories of data reach it, whether any decision affecting a person depends on its output, and the contractual basis. The last column is where the register earns its keep, because it exposes the systems in use under no contract at all.

Building it from a survey produces a tidy document that is wrong. People forget tools, omit the ones they suspect are not approved, and have no idea which of their existing software has shipped an assistant since it was bought. Building it from what the fleet actually does produces a longer and more uncomfortable list, which is the one an assessor is asking for. We can supply the second kind; the business purpose and the decision column are yours to fill in.

The reason organisations are slow on this is rarely that the obligations are hard. It is that they do not belong to anybody in particular.

The register is an inventory problem, which is IT. The literacy duty is training, which is HR or the business. Transparency to staff is an employment communication. The risk determination is legal. Keeping any of it current depends on knowing what tools are actually in use, which is security. Five owners means no owner, and the usual result is a workshop that produces a slide rather than a register.

The pattern that works is a named owner for the register specifically, because it is the artefact everything else depends on, with legal owning the risk determination for anything near a decision about a person. Everything else can follow from those two. What does not work is assigning the whole thing to whoever raised it, which is usually somebody in security with no authority over training or employment communication.