Thinking of building your own AI solution?

From a good idea to something you can trust.

Start with the benefits. Then involve the right colleagues in questions about quality, data and responsibilities.

1. What benefits are you aiming for?

   Choose a specific task and describe what should improve. Consider the whole process: preparation, AI support, review and corrections.

   One way to start

   If you want less follow-up paperwork, measure the time it takes today and compare it with a small-scale trial. A faster draft is only a benefit when it helps the whole workflow.

   Digg: start with your organisation's needs – practical guidance for public administration.

2. How do you know the result is accurate?

   Well-written text can contain errors or omit important information. Decide how to test the solution, who reviews the result and how errors are identified.

   What needs testing?

   Use representative test cases and check for omissions, dates and negations, for example. Set acceptance criteria in advance and repeat relevant tests when the model, instructions or workflow change.

   NIST: risk management for generative AI – methodological guidance, not Swedish law.

3. Where does the information go?

   Map storage, processing, logs, backups and support access. EU/EEA storage is one part of the picture; it does not, on its own, determine whether personal data is handled correctly.

   EU/EEA and access from elsewhere

   Access by a recipient outside the EU/EEA can also constitute a third-country transfer. Such transfers are not universally prohibited, but GDPR conditions must be met. Also establish the legal basis, confidentiality, permissions, processors and retention arrangements for your use.

   IMY: transfers to third countries.

4. What responsibilities come with the solution?

   The solution's intended purpose determines which product requirements may apply. Clarify early whether it is medical device software and which roles you hold under the AI Act.

   From using a tool to product responsibilities

   Not all healthcare software is a medical device. An MDR assessment starts with the intended purpose, followed by any applicable risk classification and evidence requirements. Human review alone does not settle the question. In-house manufacture in healthcare has specific conditions and is not an automatic exemption.

   MDCG guidance on medical device software · IVO: medical devices · European Commission: the AI Act.

5. Who looks after it after launch?

   Plan for updates, training, incidents and fallback procedures. Include the work of maintaining the solution when comparing an in-house build with an existing service.

   Responsibilities that need an owner

   Assign responsibility for monitoring quality, deciding on changes and pausing use. A supplier can handle product development and operations; the healthcare provider still needs to ensure safe use within its organisation.

   Swedish National Board of Health and Welfare: systematic quality management.