/ THE SHORT ANSWER
Start with an inventory of AI systems and intended uses, then determine the organisation’s role for each system, the people affected, the likely risk category, applicable transparency duties, and the documentation available from suppliers. Assign an owner and review triggers. Do not begin with a generic policy alone: classification and obligations depend on the actual use, sector, role, and deployment context.
- 01Inventory systems by intended use, not vendor marketing category.
- 02Clarify provider, deployer, importer, and distributor roles where relevant.
- 03Record classification, transparency, oversight, documentation, and review decisions.
/ dotSuper point of view
Regulatory readiness starts with knowing what the system does, where it acts, who is affected, and who holds each obligation. An “AI-powered” procurement label is not a compliance classification.
What the evidence says
The European Commission describes the AI Act as a risk-based framework with different obligations for prohibited, high-risk, transparency-risk, and minimal-risk uses.
The Commission’s current implementation material emphasises risk assessment, data quality, logging, documentation, deployer information, human oversight, robustness, cybersecurity, and accuracy for high-risk systems, with phased application dates.
A practical decision framework
The following framework is dotSuper’s operating synthesis of the cited guidance. It is designed to make the decision inspectable, not to imitate a platform ranking formula, certification checklist, or legal test.
- System inventory: purpose, users, affected people, territory, supplier, and owner.
- Role and risk screen: provider/deployer status, prohibited use, high-risk area, or transparency case.
- Evidence file: instructions, limitations, logs, data information, oversight, testing, and incidents.
- Review triggers: use change, model change, supplier update, geography, new users, or new consequence.
| Step | Decision to record |
|---|---|
| 01 | System inventory: purpose, users, affected people, territory, supplier, and owner. |
| 02 | Role and risk screen: provider/deployer status, prohibited use, high-risk area, or transparency case. |
| 03 | Evidence file: instructions, limitations, logs, data information, oversight, testing, and incidents. |
| 04 | Review triggers: use change, model change, supplier update, geography, new users, or new consequence. |
How to put it into practice
Create a register that separates the business workflow from the model or vendor name. The same underlying model can support uses with very different risk and obligations.
Ask suppliers for a documented intended purpose, limitations, deployment instructions, material updates, and evidence needed for your own role. Escalate legal interpretation to qualified counsel.
- Name the accountable owner and the decision this work must enable.
- Record the current evidence, assumptions, exclusions, and next review trigger.
- Measure a useful outcome rather than treating publication or deployment as success.
What this page cannot conclude
- 01This is not legal advice and the AI Act’s application depends on facts, roles, sector, and evolving guidance.
- 02Organisations must also consider data protection, product safety, employment, consumer, cybersecurity, and other applicable law.
- 03Publication, technical eligibility, or good practice cannot guarantee ranking, referral traffic, citation, adoption, or a business outcome.
Sources
Test the workflow before funding the solution.
The AI Readiness Sprint turns one operational constraint into a ranked decision, an accountable owner, and an implementation-ready first move.
Explore the readiness sprint