Summary: Before you write the next AI policy, you need to know how AI is actually used in your organisation. An AI inventory – a register of systems, use cases, owners, data and risk – is the foundation for risk management, GDPR compliance and risk classification under the AI Act alike. Start by making shadow AI visible, distinguish between tools and use cases, and connect the inventory to the registers and processes you already have.
“We use Microsoft Copilot.” Good. But does the organisation also use:
- ChatGPT in the browser?
- Gemini in Google Workspace?
- Claude or other assistants in individual teams?
- AI features in CRM, HR and finance systems?
- meeting transcription and automatic summaries?
- AI support in recruitment and screening?
- AI-based development tools?
- AI that vendors have switched on in existing SaaS services – without anyone asking for it?
Many organisations answer the AI question by writing an AI policy. That is not wrong – but it is the wrong order. A policy written before you know how AI is actually used ends up either too general to govern anything, or too restrictive for anyone to follow.
Start with an inventory instead.
The Swedish FSA is asking exactly these questions
On 3 September 2026 the Swedish Financial Supervisory Authority (Finansinspektionen) launched a survey of how financial firms use AI and manage the technology’s opportunities, risks and challenges. It is run as a questionnaire to banks, credit institutions, insurers, fund managers, payment institutions and securities firms, among others, and is also meant to show how firms consider themselves affected by the EU AI Act. The questions are not about policies but about actual use – and anyone without an inventory cannot answer.
This is not limited to the financial sector. The same questions are coming – from boards, customers, auditors, supervisory authorities and data protection officers – regardless of industry. And “we have an AI policy” is not an answer to the question “how do you use AI?”.
What should an AI register contain?
A useful AI register does not need to be complicated, but it does need to capture the right things per use case:
- System or service – which tool or AI feature is involved, including AI embedded in existing systems.
- Use case – what the AI is used for in practice, and in which process.
- Owner – who in the business is responsible for the use.
- Vendor – who provides the model or service, where it is hosted and which sub-processors are involved.
- Data – what information is fed in, and whether it is used to train the model.
- Personal data – whether and which personal data is processed, the legal basis, and whether an impact assessment is needed.
- Information classification – how the information is classified and whether the tool is approved for that level.
- Integrations – which systems the AI is connected to and which data it can reach.
- Human oversight – whether the AI makes suggestions, makes decisions or acts autonomously, and how a human reviews the outcome.
- Impact – who is affected by the result: employees, customers, applicants, patients, citizens.
- Regulatory assessment – risk class under the AI Act, GDPR status and any sector-specific requirements.
The register does not need to be perfect from day one. A simple spreadsheet with the right columns beats a sophisticated platform nobody fills in.
Distinguish between tools and use cases
A common mistake is to inventory tools – “we use Copilot” – and stop there. The risk sits in the use case.
Copilot summarising an internal meeting is one thing. Copilot drawing conclusions about individual customers’ creditworthiness or ranking job applications is something else entirely – even though it is the same tool. The same model can be low risk in one use case and high risk in another.
That is why the inventory should treat the use case, not the tool, as its smallest unit.
The AI Act makes risk classification more important
The EU’s AI Regulation (the AI Act) applies in stages. The prohibitions on certain AI practices have applied since February 2025, and since 2 August 2026 the transparency obligations in Article 50 apply – for example, that people must be informed when they interact with an AI system, that deepfakes must be disclosed and that AI-generated content must be marked in a machine-readable way. The so-called Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026) did not change this, with one exception: systems already on the market before 2 August 2026 have until 2 December 2026 to implement the machine-readable marking. The requirements for high-risk systems, by contrast, were postponed – to 2 December 2027 for systems under Annex III and 2 August 2028 for AI in products under Annex I.
To know which requirements affect you, you first need to know which systems you have, what they are used for and who is affected. Without an inventory, risk classification is a guess – and an AI policy that refers to the AI Act without knowing which use cases are affected is just words.
Connect the inventory to what you already do
The AI inventory should not become yet another isolated register. It connects to things most organisations already have:
- the record of processing activities
- the system inventory or CMDB
- the supplier register and third-party risk management
- information classification
- the risk register
- the DPIA process
- the change and procurement process
- business continuity plans
- training and awareness programmes
Four examples of what the connection looks like in practice:
- An AI tool that processes personal data must appear in the record of processing activities and may need a data protection impact assessment (DPIA).
- An AI vendor is a third-party supplier and should be assessed as one within your third-party risk management.
- AI features switched on in an existing system are a change and should go through the change process.
- An AI system that supports a critical process affects continuity planning and operational resilience.
Shadow AI may be the biggest problem at the start
The AI use nobody decided on is the hardest to inventory – and often the one that carries the greatest risk. Employees paste customer data into public chatbots, upload documents for summarising, or let an AI service read their entire inbox. Not out of malice, but because it is efficient and because no approved alternative exists.
Banning it rarely helps. A practical model rests instead on five parts:
- an approved alternative that is good enough to actually be used
- a simple way to report a new use case and have it assessed
- clear rules on which information may be used in which tools
- technical visibility – for example through logs, DLP and SaaS monitoring – into what is actually in use
- a culture where it is acceptable to say that you use AI
The goal is not to find scapegoats but to get the full picture. Only then can you govern.
How Kristensson i Skåne can help
We help organisations move from an AI policy on paper to working AI governance. Depending on your needs, we can contribute with:
- AI inventory and building an AI register
- risk-based classification of use cases
- AI Act readiness and risk classification
- assessment of information security risks in AI use
- data protection and DPIAs for AI processing
- vendor assessment of AI services
- an AI policy based on actual use
- a governance model with roles, responsibilities and decision paths
- training for management and staff
- ongoing follow-up as usage changes
By all means write the AI policy. But write it after the inventory – not instead of it.
Want to get control of your AI use? Read more about our AI Act and AI governance services or contact us for an informal conversation.
Sources: Regulation (EU) 2024/1689 (the AI Act), Article 50 on transparency obligations, applicable from 2 August 2026; Regulation (EU) 2026/1744 (the Digital Omnibus on AI) on the amended application dates; the Swedish Financial Supervisory Authority (Finansinspektionen), “FI kartlägger användningen av AI inom finanssektorn”, news item of 3 September 2026; General Data Protection Regulation (GDPR), Article 30 on records of processing activities and Article 35 on impact assessments.
This text is general information and does not constitute legal advice in an individual matter.

