Knowledge base / regulation10.com product guide (EU AI Act)

EU onboarding and the EU AI Act identity fields

EU onboarding follows the same wizard as elsewhere, with extra EU-specific identity fields so your systems can be assessed correctly from the start. You record the role you act in for each AI system, your EU establishment or authorised representative details, and where the system is placed on the market or put into service. These fields exist because the EU AI Act does not impose one uniform set of duties on everyone; it assigns different obligations to different actors, and the platform needs to know which actor you are before it can show you the right work.

The role field is the most consequential. The Act distinguishes, among others, the provider, who develops an AI system or has it developed and places it on the market under their own name; the deployer, who uses an AI system under their own authority; the importer, who places a third-country system on the EU market; and the distributor, who makes a system available further down the chain. The heaviest documentation and conformity duties sit with the provider, while deployers carry their own distinct set, including oversight and, in defined cases, a fundamental rights impact assessment. Your organisation can hold different roles for different systems, which is why the platform records the role per system rather than once for the workspace. A bank that builds one scoring system and buys another is a provider for the first and a deployer for the second, and the two records should not look the same.

The establishment details matter because the Act reaches beyond organisations headquartered in the EU. If you are established outside the Union but your system's output is used in the EU, an authorised representative inside the EU may be part of your compliance picture. Recording your establishment or representative details up front keeps that dimension visible in your record instead of surfacing late in a review.

The market-placement field records where and when the system is placed on the market or put into service. Timing and territory drive applicability: obligations attach around placement and use, and the Act's phased dates mean when a system reaches the market affects which duties are live for it. An accurate placement record lets the platform frame the system's assessment against the right point on the timeline.

Together the three fields decide which EU obligations the modules surface for a system. Getting them right is therefore worth a few minutes of care, and getting one wrong quietly skews everything downstream, because you would be answering a provider's questions when you owe a deployer's duties, or the reverse.

None of this is locked at onboarding. Roles genuinely change: organisations take products in-house, start reselling, or modify a bought system heavily enough to take on provider-like duties. You can update the fields later from the system's settings, the assessment updates accordingly, and the change lands in the audit trail. What the platform asks is that the fields reflect reality as it stands, because an assessment built on the wrong identity is effort spent answering the wrong question. This is informational only and not legal advice: the platform's regulatory content is a scaffold pending qualified-professional review, so confirm any obligation with a qualified adviser before you rely on it.