The operating problem: AI is already inside, but nobody sees the full picture
The team uses AI for meeting notes, proposal drafts, support-ticket classification and first-pass candidate screening. Some capabilities were purchased as standalone tools; others arrived inside the CRM, email or project-management subscription. There is often no shared list, no owner and no evidence of who reviewed the risk. That is the practical compliance problem for a small company: invisible use, not the absence of another generic policy.
The AI Act became broadly applicable on 2 August 2026, but not every requirement follows the same date. Prohibited practices and AI literacy have applied since 2 February 2025. Article 50 transparency obligations apply from 2 August 2026. Following the Digital Omnibus, the high-risk rules for Annex III use cases apply from 2 December 2027, while those for AI embedded in Annex I regulated products apply from 2 August 2028.
Do not use those later dates as a reason to postpone the inventory. Without a list of use cases, you cannot determine whether you are a deployer or provider, whether a prohibited practice, transparency duty, personal-data issue or potential high-risk scenario is present. The checklist below is an operational starting point, not legal advice. Bring in qualified counsel and the relevant authority for HR, biometrics, health, credit, critical infrastructure or disputed classifications.
Compliance starts with visibility: AI system + specific use case + owner + data + affected people + decision.
Determine the role first: deployer, provider or both
A deployer is an organisation using an AI system under its authority in a professional activity. Employees acting under the company's control are generally not separate deployers. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. An SME may be a deployer for a purchased meeting assistant and a provider for a white-label chatbot offered to customers as its own product.
Determine the role for each use case, not once for the entire company. Record the manufacturer, contract, branding, who controls the system, who sets its intended purpose and who receives the output. If you materially change the purpose or put the system under your own name, do not assume you remain only a deployer.
Article 50 also separates responsibilities. Providers of directly interactive AI systems must design the user notice, while providers of generative systems carry machine-readable marking duties. Deployers have specific obligations when they use emotion recognition, biometric categorisation, deepfakes, or AI-generated or manipulated public-interest text without human review or editorial control. For your own chatbot, check both roles with the vendor instead of assuming a sentence in the privacy notice covers every duty.
| Question | If the answer is yes | Next check |
|---|---|---|
| Do we use an off-the-shelf AI tool at work? | We are likely a deployer | Purpose, data, affected people and instructions for use |
| Do we offer the system under our own name or brand? | A provider role may apply | Contract, technical documentation, Article 50 and other provider duties |
| Have we changed the purpose or high-risk behaviour? | Our role may change | Legal and technical assessment before launch |
| Does AI interact directly with people or create public content? | There is a transparency trigger | Who gives notice, marks, reviews and keeps evidence |
| Does AI influence hiring, credit, access to a service or another sensitive process? | A high-risk use case may be present | Annex III triage and qualified review |
A seven-step checklist for an SME deployer
1. Build an AI inventory by use case
Record the tool and embedded AI features, owner, vendor, version or plan, purpose, input data, output, affected people, human decision and review date. Include personal accounts and browser extensions, but remove or govern unapproved use rather than merely documenting it.
2. Assign the role and applicable rules
Mark every row as deployer, possible provider or needs review. Run an initial screen for prohibited practices, transparency, potential high risk and other applicable regimes. Do not use a generic 'low risk' label without recording why.
3. Review data and the vendor
Map personal, confidential and client data; legal basis, retention, training use, sub-processors, hosting, export and deletion. GDPR continues to apply independently of the AI Act. Ask for contractual evidence and admin controls, not promises from a sales page.
4. Put human oversight where errors have a cost
Name the reviewer, acceptance criteria, override right and stop condition. A payment, rejection, publication, HR decision or change to a core record should not remain an irreversible autonomous step without a justified control.
5. Implement the transparency duty
Check whether people must be informed, whether content must be marked and whether the provider supplies the required machine-readable means. Keep the wording, screenshots, interface version and update owner as evidence.
6. Train people for their actual role
Article 4 retains the obligation for providers and deployers to support AI literacy, although the Omnibus no longer prescribes a particular 'sufficient' level. Training should differ for an everyday user, reviewer, system owner and technical administrator.
7. Maintain an evidence trail and review cadence
Keep inventory history, approvals, vendor evidence, training records, incidents, overrides and changes. The Commission does not require a special AI-literacy certificate; internal records of training and guidance can form part of the evidence. Review critical use cases quarterly and after a significant change.
Triage table: five common SME use cases
This table is an initial routing tool, not a final legal classification. The same product may carry different risk depending on context, people, data and the decision it supports. For a sensitive use case, do not launch solely because the vendor describes its product as compliant.
| Use case | Initial signal | Minimum control | Decision |
|---|---|---|---|
| Public customer chatbot | Direct interaction; establish who is the provider | Clear notice, human escalation, logs and vendor evidence | Launch after transparency and data review |
| Internal meeting summary | Often limited/minimal risk, but may involve personal or confidential data | Approved account, context-appropriate participant notice, retention and human correction | Controlled pilot |
| Candidate ranking | Employment is a sensitive Annex III area; high-risk rules apply later, but the risk is real now | Legal review, bias testing, human decision, applicant information and audit trail | Do not launch as an automated decision |
| AI marketing image or deepfake | Article 50 labelling may apply | Provider-marking check, visible label, brand/copyright/fact review | Publish only after documented review |
| Invoice-field extraction | Operational assistance; the business retains the financial risk | Confidence threshold, sample testing and approval before booking or payment | Suitable limited pilot |
Do not classify only the product. Classify its specific purpose, data, affected people and business decision.
What the minimum AI register looks like
Start with a controlled spreadsheet or database accessible to operations, IT/security, privacy and the relevant business owner. You do not need another governance product. You need consistent mandatory fields, an owner for changes and links to the evidence.
One row represents one use case. If the same model supports support triage and candidate screening, those are two rows because their purpose, data, affected people and risk differ. A field that only says 'ChatGPT' is not an inventory.
| Field | What to record | Evidence |
|---|---|---|
| System + use case | Name, feature, intended purpose and business process | URL, contract or configuration screenshot |
| Owner + role | Business owner, technical owner, deployer/provider triage | Approval and escalation contact |
| Data + people | Input data, personal data, affected groups and recipients | Data map, DPIA/LIA where applicable |
| Risk screen | Prohibited, transparency, potential high risk and other regulation | Short rationale and reviewer |
| Controls | Human review, access, logging, thresholds and fallback | Test results, SOP and screenshots |
| Training | Which roles were trained and on what | Attendance, materials and date |
| Lifecycle | Launch, last review, vendor/model change, next review and retirement | Change log and decision record |
A 30-day plan: from shadow AI to a controlled portfolio
Do not leave disputed systems running by inertia. Use three statuses: approved with controls, paused pending evidence and retired. Pausing one use case for five days is better than leaving it ownerless while a generic policy is drafted for the next quarter.
Connect the inventory to processes, not only the IT asset list. An AI meeting summariser may look like a productivity tool, but if its output changes the CRM and triggers a proposal, it participates in the customer process and the control must cover the full workflow.
| Period | Work | Definition of done |
|---|---|---|
| Days 1–5 | Find AI functions in the expense list, SSO/admin panels, browser extensions and team interviews | The list includes sanctioned and shadow-AI use cases |
| Days 6–10 | Group by purpose, data, affected people and decision impact | Every row has an owner and initial role |
| Days 11–15 | Run prohibited, transparency, high-risk and data screens | Unclear cases are paused or sent for specialist review |
| Days 16–20 | Add human review, access, logging, fallback and transparency controls | Each active system has a documented control owner |
| Days 21–25 | Run role-based training with real scenarios | Users understand allowed data, review and escalation |
| Days 26–30 | Test sample cases, close gaps and approve the review cadence | Management sign-off, evidence folder and next-review dates |
Worked example: a 25-person B2B service company
Consider a fictional but realistic 25-person company. Management believes it uses three AI tools: a shared chatbot, a meeting assistant and Canva. A five-day inventory finds nine use cases because the CRM includes AI email drafts, the ATS offers candidate ranking, the support inbox classifies tickets, and two employees use personal browser extensions.
The team does not buy a governance platform. It creates a nine-row register and assigns the operations lead as coordinator. Candidate ranking is paused for specialist review. Personal extensions are removed until an approved account and data controls exist. Meeting summaries remain in a pilot with retention, participant handling and human correction. Support classification stays active but cannot close a ticket or send a reply without a person.
The public chatbot receives a clear notice from the start of the interaction, human handoff and stored vendor evidence. Marketing adds review for synthetic visuals and labels where Article 50 requires them. Every user completes a short common module; HR, marketing and reviewers receive separate scenarios. After 30 days, the company does not hold a 'compliance certificate'. It has something more useful operationally: visible use cases, accountable people, a risky use paused and verifiable decisions.
The example does not establish a legal classification or outcome for a specific company. It shows how a small team can turn a broad regulation into consistent operational work.
The first 30-day goal is not a final compliance declaration. It is to leave no unknown AI use case without an owner and next decision.
What not to do
- Do not copy a generic AI policy and treat it as an inventory, risk assessment or training programme.
- Do not rely on a vendor's 'EU AI Act compliant' badge without checking your role, configuration and intended purpose.
- Do not assume human-in-the-loop is sufficient when the person lacks time, criteria, override authority or access to the source.
- Do not reduce AI literacy to one presentation. Train different roles on real systems, data and incidents.
- Do not wait for the high-risk deadline to discover that HR or another sensitive process already uses AI.
- Do not treat the AI Act as a substitute for GDPR, consumer protection, copyright, employment or sector law.
- Do not keep the register as a static file. Vendors, models, use cases and workflows change.
The next management decision
If you do not have a complete AI inventory, do not begin with 'are we compliant?'. Begin with a 90-minute working session: systems map, the mandatory register fields, owners and three statuses. By the end, you should know what remains active, what is paused and which cases need a specialist.
1→10 can include AI portfolio mapping in a Systems Audit: we connect use cases to processes and data, find shadow AI, define controls and organise a 30-day implementation backlog. Legal classification remains with your counsel or competent authority; our role is to turn the decisions into working systems, ownership and evidence.
Sources and further reading
Product capabilities change. The links below are primary or official sources reviewed when this guide was published.
- EUR-Lex: Regulation (EU) 2024/1689 — Artificial Intelligence Act
- European Commission: AI Act overview and application timeline
- European Commission: Guidelines on Article 50 transparency obligations
- European Commission: Article 50 transparency questions and answers
- European Commission: AI literacy questions and answers
- EDPB: Opinion on AI models and GDPR principles