Question 1

What is regulation10.com?

Accepted Answer

regulation10.com is the compliance plane for firms governed by the EU AI Act. Register each AI system, run the checks, and keep audit-ready proof, with tenant data resident in Sweden Central (EU data boundary).

Question 2

How much does regulation10.com cost?

Accepted Answer

regulation10.com has four annual tiers: Starter (1 AI system, 1 seat included.), Professional (5 AI systems, 5 seats included, more at 299 US dollars per seat per year.), Enterprise (25 AI systems, 5 seats included, more at 299 US dollars per seat per year.), Sovereign (unlimited AI systems, 5 seats included, more at 299 US dollars per seat per year.). Public pricing is being finalised ahead of launch; use the plan configurator at /configure to see which tier fits, or sign up to be notified.

Question 3

Where is my data stored?

Accepted Answer

Tenant data for regulation10.com is resident in Sweden Central (EU data boundary).

Question 4

Which compliance frameworks does regulation10.com cover?

Accepted Answer

regulation10.com covers EU AI Act, ISO 42001, NIST AI RMF.

Question 5

How do I register an AI system?

Accepted Answer

To register an AI system, open the AI Systems page and click Register a system (or Add system). The form asks for a name, an owner, a purpose, and a lifecycle stage, and then asks you to classify the system's risk. When you save, the system joins your inventory and becomes the subject you run compliance work against.

Each field earns its place. The name identifies the system in reports and exports, so pick the name your organisation actually uses for it internally. The owner is the person accountable for the system's compliance record; they are who a reviewer will ask when something in the record needs explaining. The purpose is a short statement of what the system does and for whom. Under the EU AI Act, purpose matters more than technology: the same model can be low risk in one use and high risk in another, so write the purpose as the intended use, not as a description of the underlying model.

The lifecycle stage records whether the system is planned, in development, in production, or retired. Regulators care about this distinction. A system in production carries live obligations now; a planned system gives you time to build its record before deployment. Keeping the stage current also keeps your inventory honest, which is the point of having one.

Risk classification is the step that drives everything downstream. The classification you record determines which compliance modules the platform surfaces for the system and what an eventual evidence export is expected to contain. The platform guides the classification with structured questions, but it records your answer rather than deciding your legal position for you. If the classification is contested or unclear, record your current view, note the open question in the system record, and confirm the position with a qualified adviser.

Why maintain a formal inventory at all? Because an inventory is the starting condition for any credible AI governance programme. You cannot assess, document, or answer for systems you have not listed. An inventory also converts an abstract obligation into a bounded piece of work: once the list exists, the remaining effort is a known number of assessments rather than an open question.

You can register as many systems as your tier allows. Each system keeps its own module runs, attached documents, and audit trail, fully separated from its siblings. That separation is deliberate: when you later export a record for one system, it contains that system's history and nothing else, which is what an external reviewer wants to see.

A registered system is not locked. You can edit the name, owner, purpose, lifecycle stage, and classification later, and every edit is written to the audit trail with who changed what and when. If a system is decommissioned, set its stage to retired rather than deleting it; the record of a retired system is still part of your compliance history.

The practical habit that makes the feature work: register a system when it is planned, not when it ships. The earlier the record exists, the more of the system's life your audit trail covers.

To change the owner of an AI system — or edit any of its other details — open AI Systems, click the system you want, then click Edit. The edit form opens with the system's current values; set or change the Owner field to the person accountable for that system and click Save changes.

The same form is where you correct the name, purpose, description, vendor, modality, lifecycle stage, and the jurisdictions the system is deployed into. Edit is available on any system that has not been retired, including one still in draft.

Saving re-runs the classification modules immediately, so the register reflects the new details straight away. If something you changed affects the system's classification, the evidence locked under the previous record is marked superseded rather than left to silently disagree with the new one. Every edit is written to the audit log against the person who made it, which is why the change has to be made by a signed-in user rather than on their behalf.

You need a role that may write to the register — Admin or ASO. A Viewer or DPO role can read the system but the edit is refused, so if the Edit form will not save for you, your role is the first thing to check.

Two different things are called owner, and it is worth keeping them apart. The system owner is the person accountable for one AI system's compliance record — it is a governance field on the system, and naming someone there grants them no access. An in-app role (ASO, Admin, DPO, Viewer) is what actually controls who can sign in and change things, and you manage that under Team in settings.

Question 6

How do I run a compliance module and get a report?

Accepted Answer

To run a compliance module, open a registered AI system, pick a module from the module list, and start a run. The module asks you a structured set of questions about the system. You can save at any point and resume later. When you finish, the engine scores your responses and produces a report with findings, gaps, and recommended remediations.

A module is a structured assessment of one compliance topic, built from the requirements of the regulatory framework your workspace runs. One module might cover risk management, another data governance, another human oversight. Working topic by topic keeps each run short enough to finish and makes the output specific enough to act on. The list of modules you see for a system depends on the system's risk classification, so a lower-risk system shows a shorter list than a high-risk one.

The questions are written for the people who actually know the system: the product owner, the engineers, the person who manages the data. You do not need a legal background to answer them. Where a question uses a regulatory term, the module explains it in plain language first. Answer from what your organisation actually does today, not from what it intends to do, because the value of the report depends entirely on the honesty of the input.

Save-and-resume matters in practice because a module run is rarely one sitting. Typically one person starts a run, discovers that three answers belong to a colleague, and parks it. The run keeps its partial state until someone finishes it. Nothing is scored or reported until the run is complete, so a parked run never produces a misleading half-report.

The report has three parts. Findings state what the assessment established, both where you meet the requirement and where you do not. Gaps are the specific points where your current practice falls short of what the framework asks. Remediations are concrete recommended actions to close each gap. The report links every finding back to the answers that produced it, so a reviewer can see the reasoning, not just the conclusion.

Each run is versioned and stored against the system permanently. This is the feature that turns a one-off assessment into a compliance history. When you fix a gap and run the module again, the previous run is not overwritten; both runs sit in the record, and the difference between them is your documented progress. Regulators and auditors respond well to that shape of evidence, because it shows a working process rather than a snapshot prepared for the audit.

Completed runs feed directly into the system's evidence export, so there is no separate step where you re-describe the work for an external audience. The run you did is the evidence.

Two practical recommendations. Run your first module on your most important production system rather than an easy one; the gaps you find there are the ones worth finding early. And schedule re-runs after remediation work rather than leaving the last run as the record, because a report that ends on open gaps understates work you have since done.

Question 7

How do I generate an evidence pack and share it with a notified body?

Accepted Answer

To produce an evidence pack, open the AI system and click Generate evidence pack. The platform assembles the system's completed module runs, technical documentation, and a tamper-evident audit trail into a single export suitable for a conformity assessment. You can then share it with a notified body or a market surveillance authority through a time-limited, access-controlled share link, or download it and send it directly.

The EU AI Act makes this kind of export necessary rather than optional for high-risk systems. Providers of high-risk AI systems must draw up technical documentation (Article 11 and Annex IV), keep records, and be able to demonstrate conformity when a notified body assesses the system or a market surveillance authority asks. The obligation is not just to do the work but to produce it on request in an examinable form. The pack is the platform's answer to that production problem.

What the export contains is the system's actual record: each completed module run with findings and scores, the technical documentation and files you attached, and the audit trail showing who did what and when. Nothing is drafted specially for the reviewer. If your record is incomplete, the pack shows it as incomplete. This is intentional. An assessment body reads many submissions, and a record with honest gaps and visible remediation history is more credible than one that appears finished everywhere the reviewer happens to look.

The audit trail is tamper-evident, so a reviewer can verify that entries were not edited after the fact. For conformity work this converts your history from an assertion into something checkable, which is what the assessment process is for.

Generating a pack discloses nothing by itself. Sharing is a separate step, taken from the evidence page when you decide to disclose. A share link is a bearer credential: anyone who obtains the URL can open the room, so send it the way you would send a password. It lapses on the date you set, it is scoped to the systems you name, you can revoke it at any time, and every access is written to your audit log. If the receiving body requires files through its own channel, download the pack and submit it there; the content is identical.

Every generation and every share is written to the audit log. That gives you a precise record of what was disclosed, to whom, and when. If a market surveillance authority later asks what a notified body had before it at a particular date, you can answer from the log rather than from memory.

Packs are point-in-time. An export reflects the record at generation, and work done afterwards does not alter a pack already shared. When the record moves on, generate a new pack.

A working rhythm that suits conformity preparation: complete the module runs the system's classification calls for, generate a pack, review it internally as though you were the notified body, fix what you find, and only then share. Issues found in your own read-through cost you an afternoon. The same issues found during the assessment cost you the assessment timeline.

Ownership of the rhythm matters as much as the mechanics. The compliance lead usually decides when a pack is generated and reviewed, while each system owner supplies whatever the internal read-through shows to be missing. Running that review as one working session, with both people present, closes gaps in hours that an email thread would stretch across weeks.

Question 8

How do I manage team members and their in-app roles?

Accepted Answer

To manage your team, open Team (or Members) in settings. Invite a colleague by email and assign an in-app role: Owner, Admin, Member, or Viewer. You can change a person's role or remove them at any time, and every change is written to the audit log.

The four roles map to how compliance work is actually distributed in an organisation. An Owner has full control, including billing and the ability to manage other Owners; this is the person answerable for the workspace itself, usually whoever set it up or the budget holder. An Admin manages systems, module runs, and evidence, but not billing; this fits the compliance lead or programme manager running the day-to-day work. A Member works on the systems assigned to them, answering module questions and attaching documents; this fits engineers, product owners, and data specialists who hold the facts a module asks about. A Viewer has read-only access; this fits internal audit, legal reviewers, and senior stakeholders who need to see the state of the work without the ability to alter it.

Assigning the narrowest role that lets a person do their job is worth the small effort. It follows the least-privilege principle that underlies most security standards, and it keeps your audit trail meaningful: when a record shows who changed a classification, the role model is what makes 'and they were authorised to' part of the same answer. A governance record maintained in a workspace where everyone can edit everything is weaker evidence than the same record with enforced separation.

Invitations work by email. The colleague receives a link, creates their account or signs in, and lands in your workspace with the role you set. Until they accept, the invitation is pending and grants nothing. The number of seats available depends on your subscription tier.

Role changes take effect on the person's next request. There is no delay you need to plan around, and no session where someone keeps yesterday's permissions. Removal works the same way: a removed person loses access at once, while everything they did remains in the record attributed to them. Work history is never rewritten by a departure, which is exactly what an auditor expects.

Two rules protect the workspace from lockout and privilege mistakes. Only an Owner can manage billing, so a compromised or mistaken Admin account cannot change your plan. And only an Owner can promote, demote, or remove other Owners, so control of the workspace cannot drift downward by accident.

A practical suggestion for first setup: create one Owner, make your compliance lead an Admin, add the people who hold system knowledge as Members, and add internal audit as Viewers. Review the list periodically, because access reviews are themselves a control most frameworks expect, and the audit log gives you the change history to support one.

When someone leaves the organisation, remove them the same day their access elsewhere is revoked, and reassign any AI systems they owned so each record keeps a live, answerable owner. An inventory whose owners have all moved on is a common audit finding, and it is entirely avoidable with a leaver step that takes under a minute.

Question 9

How do I manage billing, invoices and my plan?

Accepted Answer

Billing lives on the Billing page, which only the workspace Owner can see. From there you can check your current subscription tier, upgrade or downgrade your plan, update payment details, and download invoices. If you cannot see the page, you are not the Owner; ask the person who set up the workspace.

Restricting billing to the Owner is a deliberate control, not an inconvenience. Plan changes have financial consequences and change what the whole workspace can do, so they belong with the single accountable role rather than with anyone who happens to have access. It also means your finance team has one named person to talk to about the subscription.

The page shows your tier and what it currently allows: the number of AI systems you can hold, the seats you can fill, and the modules unlocked. Upgrades apply immediately. The moment an upgrade payment is confirmed, the higher limits are live, with no migration and no downtime, so you can raise your tier on the day you actually need the capacity rather than in advance. Downgrades are scheduled for your next renewal instead of applying at once. This protects you from losing access to records mid-cycle, and it gives you time to archive systems if your inventory exceeds the lower tier's limit.

Invoices are available on the page as downloads, so your finance team can pull what they need without asking you to forward emails. Each invoice reflects the plan and period it covers. Paid invoices unlock the corresponding tier features automatically; there is no manual activation step after payment.

If you pay by card, activation follows the payment provider's confirmation, which is usually immediate. If you pay by bank transfer, your plan activates once the payment is marked paid, which depends on the transfer arriving and being reconciled. If a transfer has been sent but the plan has not activated, the payment is most likely still pending reconciliation rather than lost.

Updating payment details is done from the same page. Do this before a card expires rather than after a renewal fails, because a failed renewal can interrupt access for everyone in the workspace, and the interruption always lands at an inconvenient time.

For a billing question the assistant cannot resolve, such as a reconciliation query, a correction to invoice details, or a question about a specific charge, an Owner can request follow-up from the Billing page and the team behind the platform will respond. Include the invoice number and the date of the transaction; those two details resolve most billing questions in one exchange.

One habit worth adopting: when your compliance programme grows, review your tier against your actual inventory rather than waiting for the hard limit. Hitting a system cap in the middle of onboarding a new AI system is avoidable friction, and the upgrade that fixes it takes effect the moment you make it.

If ownership of the workspace needs to move, for example when the person who set it up changes role or leaves, transfer the Owner role before they go rather than after. A workspace whose only Owner has left cannot change its own plan or payment details until access is restored, and that recovery takes longer than a handover would have.

Question 10

How do I set up two-factor authentication?

Accepted Answer

To set up two-factor authentication (2FA), go to Account, then Security, and enrol an authenticator app. Scan the QR code with the app, enter the 6-digit code it shows to confirm the pairing, and save the one-time recovery codes you are given somewhere safe. From then on, signing in takes your password plus a current code from your app.

The reason to do this is blunt: passwords leak. They are phished, reused across services, and exposed in third-party breaches, and none of that is within your control. A second factor means a leaked password alone is not enough to open your account. For a workspace that holds your organisation's compliance record, regulatory assessments, and evidence about your AI systems, the account is worth more to an attacker than most, and the few seconds a code costs at sign-in is the cheapest control you can buy.

Any standard authenticator app works: the platform uses time-based one-time codes, which is the widely supported open standard rather than anything proprietary. The app generates a fresh 6-digit code every 30 seconds on your device. The code never travels to you over email or SMS, which removes the interception routes those channels carry.

The recovery codes deserve more respect than they usually get. They are single-use codes that let you sign in when your device is lost, broken, or reset. Treat them like cash: store them in a password manager or printed in a genuinely secure place, and never in the same place as the device they are meant to rescue you from. Each code works once and is then spent.

If you lose your device, sign in with a recovery code, then go straight to Security and enrol a new authenticator. Enrolling the new device invalidates the old pairing, so a lost phone stops being a key to your account the moment you re-enrol. If you have used most of your recovery codes, generate a fresh set at the same time.

If you are locked out with no device and no recovery codes, you are not permanently stranded, but the path is intentionally harder: a workspace Owner or the platform team can help restore access after verifying who you are. The friction there is the security working as designed. An easy bypass for you would be an easy bypass for an attacker.

There is also a compliance angle. Access control questions appear in security reviews, vendor assessments, and most governance frameworks, and 'is multi-factor authentication enforced for accounts holding sensitive records' is a standard line item. Enrolling 2FA on the accounts that manage your AI compliance record is one of those controls that costs minutes and answers a question you will certainly be asked.

The practical order for a team: the workspace Owner enrols first, because that account can change billing and membership, then Admins, then everyone else. Do it on a calm day, not during an incident. Pair the rollout with a shared note on where recovery codes belong, so nobody improvises their own storage, and check completion in your next access review. A partially protected workspace gives a false sense of cover, because an attacker only needs the one account that skipped the step.

Question 11

What EU AI Act coverage does the platform provide?

Accepted Answer

Your workspace runs in the EU AI Act regime. In practice this means the platform serves EU AI Act corpus, modules, and terminology throughout, rather than the DIFC Regulation 10 set that other deployments use. Everything you register, assess, and export is framed against the obligations of Regulation (EU) 2024/1689, the EU's cross-sector law on artificial intelligence.

Concretely, the regime shapes four things you will notice. The assessment modules offered for a system follow the EU AI Act's structure, covering areas such as risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy. The risk language matches the Act's own categories, including the Annex III high-risk list. The reference content the assistant cites is the EU corpus. And evidence exports are shaped for the EU's reviewers, meaning notified bodies and market surveillance authorities rather than DIFC institutions.

The regime also has a data consequence: your workspace data resides in the EU region tied to this deployment. Where your compliance record is stored is itself a question European buyers and reviewers ask, so the answer is fixed at the platform level rather than left to configuration.

Why does the platform bind a workspace to one regime instead of letting you toggle between frameworks? Because the two regimes disagree in ways that matter. Risk categories, documentation expectations, reviewer institutions, and timelines all differ between the EU AI Act and DIFC Regulation 10. A workspace that blended them could produce records that satisfy neither, and worse, could let guidance from one regime leak into an assessment made under the other. Fixing the regime at provisioning removes a whole class of cross-contamination errors, and it means every entry in your audit trail was made under a known framework.

You therefore do not switch regimes inside the product. The regime is set when the workspace is provisioned and stays fixed for its life. If your organisation also needs the DIFC regime, for example because you operate in both jurisdictions, the platform team sets that up as a separate deployment with its own workspace, its own data residency, and its own record. Two clean records beat one mixed one, and reviewers on each side only ever see the record built for their framework.

What this asks of you is small: work in the regime your workspace was built for, and read the platform's terminology as EU AI Act terminology. When you see a reference to a high-risk classification, an obligation, or an evidence export, it carries the EU meaning. If you are ever unsure whether a concept you have met elsewhere applies here, ask the assistant, which will answer from the EU corpus and cite its source.

The regime binding is one of the quiet features you stop noticing quickly, and that is the intended outcome. The framework is fixed so your attention can go to the systems being assessed rather than to which rulebook applies.

If you inherit a workspace and are unsure which regime it runs, the answer is visible in the product itself: the corpus the assistant cites, the module names, and the reviewer institutions named in the evidence flow all identify the framework. You never have to guess, and nothing you do inside the workspace can change it by accident. 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.

Question 12

What does an Annex III high-risk classification mean in practice?

Accepted Answer

When a system is classified high-risk under Annex III, the platform unlocks the fuller high-risk obligation set for it. The modules covering risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy and robustness become applicable, and the system's evidence export is expected to cover them. In plain terms: more modules to run, more documentation to attach, and a fuller record to maintain than a minimal-risk system needs.

Annex III is the EU AI Act's list of use areas the legislator judged high-risk. It covers, among others, biometric systems, critical infrastructure management, education and vocational training, employment and worker management, access to certain public and private services including creditworthiness assessment, law enforcement, migration and border control, and the administration of justice. What puts a system on the list is its intended use, not the sophistication of its technology. A simple model screening job applications sits in Annex III territory; a complex model writing marketing copy does not.

The obligation set that follows tracks the Act's requirements for high-risk systems. Risk management means an ongoing, documented process across the system's lifecycle, not a one-off review. Data governance addresses the quality and handling of training, validation, and testing data. Technical documentation is the written record that lets an assessor understand what the system is and how it meets the requirements. Record-keeping covers the logs the system must produce. Transparency here means giving deployers the information they need to use the system properly. Human oversight means the system is designed so people can actually supervise and intervene. Accuracy and robustness cover the system performing reliably and resisting error and misuse. Each of these maps to a module on the platform, so the abstract list becomes a concrete sequence of assessments with findings and gaps.

Operationally, plan for the difference in workload. A high-risk classification typically means involving more people, because the data governance answers live with your data team, the oversight answers with the product owner, and the documentation with engineering. The platform's save-and-resume runs and per-system audit trail are built for exactly that multi-person reality. The sensible response to a high-risk flag is to sequence the modules and assign owners, not to treat the list as one person's task.

One boundary matters and is worth stating plainly. The platform flags the classification on the system and reflects it in your obligation status, and its structured questions help you reason about the position, but it does not decide your legal classification for you. Edge cases exist, the Act contains carve-outs and conditions, and the cost of misclassifying in either direction is real: too low and you build an inadequate record for a regulated use; too high and you spend effort you did not owe. Record your view, keep your reasoning in the system record, and confirm contested classifications with a qualified adviser before you rely on them.

The reasoning you keep matters later. If a supervisory authority ever questions the position you took, a contemporaneous note of why the system was classified as it was, held in the same record as the assessments that followed, is far stronger ground than a reconstruction assembled after the question arrives. 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.

Question 13

What are the EU AI Act applicability dates and my compliance runway?

Accepted Answer

The EU AI Act phases in on a runway of dates rather than arriving all at once, and the platform tracks those dates for you instead of treating every obligation as due today. General-purpose AI and transparency obligations reached their applicability date on 2 August 2026. The Annex III high-risk obligations apply from 2 December 2027. So if you hold high-risk systems, you have runway to that date to close your evidence, which is a planning horizon, not an excuse.

The staggering is deliberate on the legislator's part. The Act's duties differ enormously in how much preparation they demand. Transparency duties, such as telling people they are interacting with an AI system, can be implemented quickly. The high-risk obligation set, with its documentation, risk management, and conformity work, takes sustained effort across several teams, and the later date reflects that. Reading the runway correctly therefore starts with knowing which of your systems fall on which track, which is what your risk classifications in the inventory determine.

Your obligation status view shows the distinction directly: it marks which items are already applicable now and which are still on the runway. That split is the practical planning input. Items already applicable deserve immediate attention, because for them the runway has ended. Items on the runway are where you choose your pace, and the record you build before the date is what makes the date a non-event.

How much runway is actually left is the question to keep asking, because evidence-building has lead times that are easy to underestimate. A full high-risk record means module runs across risk management, data governance, documentation, oversight, and more, each needing input from people with other jobs. Remediation of the gaps those runs find takes longer than the runs themselves. And if a conformity assessment involving a notified body is in your future, that process has its own duration you do not control. Working backwards from 2 December 2027 through those stages consumes the runway faster than the calendar suggests.

The platform's contribution is to keep the timeline attached to the work. Dates are tracked against your actual systems and obligations rather than in a memo nobody reopens, so the question 'what must be ready, and by when' always has a current answer drawn from your own record.

Treat the dates as planning milestones, and hold them lightly enough to re-verify. Applicability questions can turn on specifics: what you place on the market, when, in what role, and legislative timelines themselves can move. The platform reflects the dates as it understands them, and your obligation view reflects your position against them, but before you commit budgets or make representations that hinge on a date, confirm the current position with a qualified adviser. The runway is real; the discipline is using it to finish early rather than to start late.

A simple way to make the horizon concrete: take your highest-risk production system, list its outstanding items from the status view, and estimate the people-weeks each needs. Multiply across the inventory and the remaining calendar stops being abstract. Most organisations that do this exercise conclude they should start sooner than they had assumed, which is precisely the value of doing it. 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.

Run the EU AI Act on every AI system you operate.

Why this is hard

How it works

Know the risk class before you build

Turn the work into evidence

Watch it while it runs

The sectors this is built for

Why you can rely on it

Where your data lives

Customer references

Assess your AI system