Assessment workflow

Use this workflow for each named AI system.

Before starting

Confirm:

• Correct tenant, workspace and system.
• Current system intake and intended purpose.
• Known provider, deployer and supply-chain entities.
• Current legal snapshot.
• Assessment authority and access to relevant evidence.
• A boundary that includes models, orchestration, data, tools, people and affected decisions.

Step 1: select the system

The assessment header must show the named AI system being assessed. If you change systems, Gamut loads that system’s assessment record and clears AI analysis from the previous system.

Do not use a workspace-wide narrative as the basis for a system conclusion.

Step 2: complete the structured legal intake

Record:

• EU nexus and exclusions.
• AI-system definition.
• Intended purpose and deployed use.
• Operator roles.
• Article 5 facts.
• Annex I and Annex III facts.
• Article 6 exception and profiling.
• Public-body/public-service and FRIA triggers.
• Article 50 behaviours.
• GPAI role and systemic-risk facts.
• Applicable market-placement and application dates.

Use free text to explain facts, not to replace required structured fields.

Step 3: review the authoritative route

Review all eleven route cards. For each, confirm:

• Applicable, not applicable, incomplete or future status.
• Legal basis.
• Triggering system facts.
• Role.
• Current-law application date.
• Any contradiction or missing fact.

If a route looks wrong, correct the intake. Do not force the answer inside an assessment item.

Step 4: resolve Article 5 first

Work through all eight prohibited-practice checks before relying on broader readiness scores.

If a check is potential or confirmed:

• Stop deployment or expansion according to organisational governance.
• Preserve the relevant facts and evidence.
• Escalate to legal, compliance and accountable leadership.
• Do not use N/A to bypass uncertainty.
• Do not confirm the assessment until the issue is resolved.

Step 5: validate high-risk classification

Assess:

1. Annex I product and conformity conditions.
2. All eight Annex III points.
3. Article 6(3) exception factors.
4. Profiling override.
5. Provider documentation and registration where an Annex III system is concluded not high-risk.

Record both the classification conclusion and its factual/legal basis.

Step 6: validate roles and downstream categories

For each entity in the value chain, determine applicable duties. Pay particular attention to:

• Provider/deployer overlap.
• Product manufacturer.
• Third-country authorised representative.
• Importer and distributor gates.
• Rebranding or substantial modification.
• GPAI model provider versus downstream system provider.

Step 7: assess every routed atomic item

Open each requirement and read:

• Legal basis and effective date.
• Role and applicability.
• Assessment question.
• Layer-specific auditor advisory.
• Evidence to inspect.
• Bounded audit test.
• Implementation notes.
• Cross-framework references.

For parent items with children, assess every child. A parent-level narrative does not complete the atomic items.

Step 8: choose the legal answer

Compliant

Select only where the applicable obligation is implemented. Then assign the assurance depth that the evidence, testing and findings support.

Non-compliant

Select where the obligation is absent, materially incomplete, ineffective or contradicted.

Record:

• Precise condition.
• Legal and operational consequence.
• Finding and owner.
• Interim restriction or compensating control.
• Target date and retest.

N/A

Select only after establishing that the trigger does not apply. Complete the governed N/A decision; otherwise it remains unresolved and is not excluded from scope.

Step 9: assign assurance depth

Use:

• 3 — Assured
• 2 — Supported/Partial
• 1 — Asserted
• 0 — Gap

The answer says whether the legal requirement is met. Depth says how strongly that claim is demonstrated. See Scoring, assurance and conclusions.

Step 10: link evidence

Evidence must belong to:

• The selected system.
• The relevant atomic item.
• The applicable organisation and role.
• The current version and period.

Review and accept evidence; upload count alone is not assurance.

Step 11: perform bounded tests

Use the item-specific audit test as a starting point. Record objective, scope, sample, steps, pass criteria, safety constraints, result, exceptions and retest.

Legal-document checks may use inspection and traceability tests. Technical duties require appropriate operating-effectiveness tests.

Step 12: raise and link findings

Raise a finding for:

• Non-compliance.
• Failed test.
• Rejected or stale evidence.
• Role or classification contradiction.
• Unsupported N/A.
• Missing authority, notification or escalation process.
• Open issue that contradicts a compliant claim.

Step 13: use AI Assist

Choose:

• Whole-system analysis; or
• One atomic requirement.

Before applying any suggestion, confirm the displayed system, route basis, evidence scope and legal snapshot. AI output is advisory.

Step 14: complete the human conclusion

Required fields include:

Field	Required content
Assessment owner	Accountable named person
Confidence	Low, Medium or High
Residual risk	Remaining exposure, gaps, uncertainty and restrictions
Review date	Date proportionate to change and legal timing
Conclusion	At least 80 characters; system-specific and legally bounded
Reassessment triggers	At least 30 characters; observable changes or events

Separate:

• Current-law compliance conclusion.
• Future-readiness position.
• Proposed-change intelligence.

Step 15: confirm

Confirmation is validation-gated. For every applicable, in-force atomic item claimed compliant, the record must support depth 3 with:

• Accepted/reviewed evidence.
• A passing system-scoped test.
• No failed test.
• No unresolved adverse finding.

Applicable items may instead have a fully approved N/A where legally valid. Missing scope facts, contradictions, potential prohibited practices or incomplete assurance block confirmation.

Returning to the main assessment

When working in an atomic assessment, use Back to return to the main EU AI Act view. The selected system and saved record remain in context.

Reassessment triggers

Reassess after:

• Intended-purpose or user-population change.
• New EU market or output nexus.
• New or transferred operator role.
• Model, supplier or GPAI status change.
• Substantial modification, rebranding or fine-tuning.
• New Annex I/III use.
• Added profiling, biometrics, emotion recognition or synthetic-content behaviour.
• Changed autonomy, tools, data or decision effect.
• Serious incident or regulatory request.
• Failed test or material finding.
• Evidence expiry.
• New binding law, guidance or application date.

Final quality checklist

• Correct system and legal snapshot.
• Structured route complete and contradiction-free.
• Article 5 clear.
• Annex I, Annex III, exception and profiling reviewed.
• Roles and role transfers evidenced.
• All applicable atomic items answered.
• N/A decisions approved.
• Depth matches evidence and tests.
• Failed tests and findings reflected.
• Current law separated from future readiness.
• Owner, confidence, residual risk, review and triggers complete.