Begin with facts about the deployment.
Ask what the system is intended to do, where it operates, who uses it and whose interests may be affected. Identify the organisation's role in supplying or using it. A supplier's description is an input to the review, not a substitute for understanding the actual business process.
Record uncertainty early. If the owner cannot explain whether an output influences a decision about a person, route that question to someone who understands the workflow before selecting a category.
Separate different regulatory questions.
Scope, prohibited practices, high-risk classification and transparency are separate questions. Article 6 links high-risk status to specified product and use-case criteria, including relevant exceptions. A generic severity score alone cannot establish the legal category.
Use a structured review to connect each conclusion to the facts considered, evidence checked and reviewer responsible. Where interpretation is uncertain, document the question and obtain the appropriate specialist input rather than defaulting to a reassuring label.
Keep conditions and open questions with the decision.
A review may approve a limited use, require additional evidence, restrict particular inputs or block a proposed deployment. Make those conditions specific enough for an operational owner to follow. Identify who can accept residual business risk and who must be consulted when the proposal changes.
- The version and intended use reviewed.
- The rationale and supporting references.
- Conditions, restrictions and unresolved questions.
- The responsible reviewer and reassessment trigger.
Revisit the decision when its assumptions change.
A new customer group, expanded purpose, different model or additional data source can change the review context. Connect change requests to the earlier decision so reviewers can see what has changed rather than repeating the entire assessment without direction.
An EUAIC engagement can define intake questions, escalation routes and decision records for your organisation. The result should make accountability clearer; it should not imply that software has issued a binding legal classification or removed the need for competent review.