EmberHound AI Act Workspace
Turn every AI system into a clear action plan.
Register the AI your organisation uses, complete a guided assessment, and understand its likely classification, obligations, risks, and next actions. EmberHound keeps your answers, evidence, and decisions together as your AI estate changes.
- Guided, save-and-resume assessments
- Explainable, rules-based results
- Actions, evidence, and review in one workspace
- Complete assessment history
The problem
AI adoption moves faster than governance spreadsheets.
Most organisations know AI is being used. Very few can produce a reliable record of what each system does and who is answerable for it. The questions arrive from a supplier, a customer's security review, or an internal audit, and answering them means starting from scratch each time.
What each system does, and who owns it
Which tools are in use, what business purpose they serve, who inside the organisation is responsible, and where they run.
Which role you're in
Whether you're a provider, deployer, importer, or distributor for a given system changes what applies. It's rarely written down.
What's still unanswered
A spreadsheet records answers. It doesn't record which questions nobody could answer, or which of those actually mattered.
The workflow
Register, assess, act, review, repeat.
- 01
Register an AI system
Add it by hand, import a list, or work through prompts about what your teams actually do.
- 02
Complete initial screening
Seven questions sort systems into no indicators, needs a full assessment, or possible prohibited use.
- 03
Work through the assessment
Conditional questions across seven modules. Save your progress and come back to it.
- 04
Review the result
Likely classification, confidence, the rules that fired, and what stayed unresolved.
- 05
Manage obligations and actions
Applicable requirements become a tracked list, tied to the assessment that produced them.
- 06
Collect or request evidence
Upload it, link it, or ask the supplier for what you're missing.
- 07
Review and decide
Nominated reviewers work a queue and record decisions that can't be quietly rewritten.
- 08
Reassess when things change
A new assessment supersedes the old one. Both stay readable.
Inventory
Start with the AI your organisation actually uses.
Each system is recorded separately, with the detail that later drives its assessment. You add systems yourself, import a list, or work through activity prompts that describe everyday tasks rather than regulatory categories.
EmberHound does not scan your network for AI. There is no automated technical discovery, and we'd rather say so than imply otherwise.
- Name, supplier, and the business purpose it serves
- The person or team inside your organisation who owns it
- System type, capability tags, and deployment contexts
- Categories of data it handles
- Lifecycle status, and when it was first put into service
- Free-text notes, and the date its next review falls due
Guided assessment
Answer practical questions, not pages of legislation.
Questions are conditional, so you only see what applies to the system in front of you. Every answer carries how sure you are about it, and progress saves as you go, so you can stop and pick it up again when the system owner replies.
What the assessment works through
Seven modules, in a fixed order:
- Organisational role
- Territorial applicability
- Prohibited practices
- Annex I
- Annex III and Article 6(3)
- Transparency
- GPAI relevance
Roles it can establish
One system can hold more than one:
- Provider
- Deployer
- Importer
- Distributor
- Authorised representative
- Downstream provider
- GPAI model provider
These are risk and applicability indicators that require appropriate human review. EmberHound supports AI discovery, assessment, documentation, and governance. It does not provide legal advice or guarantee compliance. Organisations should obtain specialist advice where an AI system presents significant regulatory, safety, or fundamental-rights risks.
Explainable results
See the result, and how EmberHound reached it.
The engine is rules-based and deterministic. Each result carries the answers it used, the specific rules that fired, the ruleset version and its status, and the engine version, so a conclusion can be reconstructed months later.
Incomplete information never becomes reassurance. If material questions are unanswered or marked unsure, or the use falls in an area the ruleset does not yet model in full, the result becomes unable to determine rather than no high-risk indicators, and a review case opens. A gap in our coverage is reported as a gap in our coverage.
- Likely classification, with a confidence level of high, medium, or low
- The answers used, and how certain you said you were about each
- The specific rules that fired, by key and version
- The ruleset version and whether that ruleset is draft or active
- Outstanding uncertainty and coverage gaps, named rather than absorbed
- Full assessment history, with superseded results kept readable
Obligations and actions
Turn the assessment into manageable work.
An accepted result materialises the requirements that apply to that system, each carrying the rules and trace it came from. Obligations track their own status, timing basis, and due date, and are superseded rather than deleted when a reassessment changes the picture.
- See what needs attention, per system and across the estate
- Track outstanding work separately from what's done
- Every obligation stays tied to the assessment that produced it
Evidence
Keep the evidence beside the decision.
Upload a file, link an external document, or record an attestation. Versions are immutable, and each is linked to a specific obligation or action rather than filed loosely against the organisation.
- Documents, records, external links, and attestations
- Review scoped to the purpose the evidence was linked for
- Carried forward across reassessment where it still applies
Vendor information
Request the information your suppliers haven't provided.
Most gaps in an assessment aren't yours to fill. Raise a request against the supplier of a specific system, record what you asked for, and track whether they answered. The request stays attached to the system, the assessment, and the review case that prompted it.
- Raise a request tied to a system and the gap that prompted it
- List the specific items you need, with a due date
- Record the response and whether it resolved the gap
Human review
Decisions that can't be quietly rewritten.
Where the engine can't reach a safe conclusion on its own, it opens a review case rather than guessing. Cases carry a type, a priority, and a reason, and only the people you nominate can decide them. Decision history is append-only, so a superseded decision stays visible alongside the one that replaced it.
Cases the workspace opens
Seven types, each with its own permitted outcomes:
- Possible prohibited use
- Regulatory coverage
- Article 6(3)
- Assessment uncertainty
- Operational readiness
- Evidence escalation
- Stale assessment
Decisions a reviewer can record
Which are available depends on the case type:
- Reviewed, no change
- Proceed with conditions
- Additional information required
- Escalate to legal
- Stop use
- Exception not supported
Operational review and formal decision are separate things. Anyone with compliance write access can do the day-to-day work: add systems, answer questions, upload evidence, progress actions. Recording a decision on a review case, or reopening one that was closed, needs the reviewer permission, which sits with administrators and privacy officers only. The reviewer's identity and the time are taken from the server, never from the browser.
Risk register
Manage the risks behind the classification.
A classification tells you which rules apply. It does not tell you what could go wrong with a particular system in your organisation, or what you decided to do about it. Risks are recorded against the AI system they belong to, so the two stay connected rather than living in separate documents.
Score it twice
Likelihood and impact on a labelled five-point scale, before treatment and again after it, so the effect of the work is visible. The product shows the arithmetic - likelihood times impact, and the band it falls in - rather than inventing a percentage.
Say what you're doing about it
A treatment, a rationale, a plan, and a date. Choosing to avoid a risk requires a written reason.
- Mitigate
- Accept
- Avoid
- Transfer
- Monitor
Reviewing a risk and accepting one are different acts
This is the distinction most registers blur, and blurring it is how a risk quietly becomes somebody's problem without anybody agreeing to it. Keeping an eye on a risk is analyst work. Deciding your organisation will live with it is not.
Operational review - anyone with compliance write access
- Continue treatment
- Continue monitoring
- Increase treatment
Moves the treatment along. Does not change your formal position on the risk.
Governance decision - administrators and privacy officers
- Accept residual risk
- Close risk
- Reopen
Commits the organisation. Accepted and closed cannot be reached any other way - not by editing the record, not by changing its status.
Linked, not duplicated
A risk links to the compliance actions and evidence that already exist elsewhere in the workspace. There is no second task list and no second file store to keep in step.
Attaching evidence does not move the score or the status. That is deliberate. Evidence supports a decision somebody makes; it does not make the decision.
History that holds
Every decision is appended, never overwritten, with the rationale, who made it, and the residual score at the time. Two people acting at once cannot overwrite each other, and a decision that failed to take effect is identifiable as one rather than sitting in the record looking like it worked.
Ongoing governance
Keep the record current as your AI changes.
A questionnaire completed once describes the day it was completed. When a system's use changes, reassess it: the new assessment supersedes the old one, obligations and evidence carry forward where they still apply, and both versions stay readable.
Reassessment and history
Superseded assessments, obligations, and review cases are retained and linked to whatever replaced them. Systems whose assessment has gone stale are flagged.
Governance queue
One place for reviewers to see what's waiting on them across every system, ordered by priority.
Readiness view
Per system: what's outstanding, what's been confirmed, and what's waiting on somebody outside your organisation.
Security and trust
Your governance record stays yours.
The workspace holds sensitive commercial and legal judgements about the tools your organisation runs. It's built on the same tenant isolation and audit model as the rest of EmberHound.
Read the Trust Centre for the full architecture and data-handling detail.
- Organisation-level isolation enforced in the database as well as the application
- Role-based access, with review permissions held separately from everyday write access
- Reviewer identity and timestamps derived on the server
- Evidence files held in private storage, not public buckets
- Append-only decision and answer history
- Every AI Act record removed when an organisation is deleted
Why act now
The high-risk obligations arrive in stages.
The AI Act has applied generally since August 2026, and the obligations that attach to high-risk systems phase in after that. The next milestone is December 2026. The work that takes time is not the paperwork at the end. It's establishing which systems you have, what each one does, and which role you're in for each - and that is worth starting before a deadline makes it urgent.
Read the EU AI Act guide for the full timetable, the risk tiers, and what each role has to do, with links to the source texts.
Frequently asked questions
Tell us about your AI estate.
Tell us what you're running and what's prompting the work, and we'll take you through how the workspace handles it.