Before an engineering firm signs with an AI vendor in Europe, four things need answers: which AI Act risk class the vendor claims, what NIS2 makes you responsible for, where project data lives, and what your IT department will ask. Here are the questions, in one table. The regulatory picture below reflects spring 2026.
The context
A European engineering firm evaluating an AI tool answers to three regimes: the EU AI Act, the NIS2 cybersecurity rules that took legal force in Sweden in January 2026, and the procurement and confidentiality terms that follow public-sector clients into every subcontract. Add the sovereignty question, where your data lives and who can reach it, and the vendor conversation looks nothing like the demo.
The sovereignty question is not a side note. Sweco, one of Europe's largest architecture and engineering consultancies, put digital sovereignty on its list of technology trends for 2026. Staffan Willstrand, head of Sweco's Digital Services division in Sweden, summarised the year's mood:
Summerat är koll på system och data och möjligheten att ha den inom Europas gränser en fråga som fortsätter vara högaktuell under 2026.
The AI Act
That is the first question for your counsel, and the honest answer is: it depends on what the system does and how you use it. Regulation (EU) 2024/1689, the AI Act, sorts AI systems by risk. A few practices are banned outright, high-risk systems carry heavy obligations for providers and deployers, and most business software lands in the lighter transparency or minimal-risk tiers. The classification is not decided by the vendor's marketing; it is decided by the regulation's definitions, and obligations phase in stepwise through 2026 and 2027.
So do not settle for a one-line assurance. Ask the vendor which risk class it considers its system to fall under, and on what reasoning, in writing. Ask whether any of your intended uses could change that reading, for example if output feeds decisions about safety-critical infrastructure. Ask which general-purpose models run underneath and on what terms. Then hand all three answers to your counsel and let them test the logic. A vendor that has done its homework will not flinch.
NIS2
Possibly more than you think, and possibly through your clients rather than directly. Directive (EU) 2022/2555, NIS2, raises cybersecurity requirements across the EU. In Sweden it became national law as cybersäkerhetslagen (2025:1506), in force since 15 January 2026, covering far more sectors and organisations than the law it replaced, with requirements on risk management, incident reporting and management accountability.
The clause that matters most in a purchase decision concerns supply-chain security. Organisations in scope must manage security risks in their supplier relationships, which means the duty travels through contracts. A tool that reads your project documents is a supplier in your chain; your firm is a supplier in your clients' chains. Even if your own firm falls outside the law's direct scope, a covered client can be obliged to care about the tools you run its documents through. Ask where the vendor sits in that chain, which subcontractors touch the data, and how the vendor supports the incident-reporting deadlines that your obligations, or your clients', may impose.
Data and procurement
Two different questions, often collapsed into one. Residency is about where data is stored and processed: can it be confined to the EU or EEA, and which subprocessors are involved, in which countries. Jurisdiction is about legal reach: under which country's law can an authority compel access to the data, wherever the servers stand. Residency is easy to get in writing. Jurisdiction is harder, and in practice a gray zone shared by everyone building on the big cloud providers: worth understanding, not winning.
Then there is procurement. For firms working for public-sector clients there is a third layer: the contract. Framework agreements and tender documents from public clients often carry confidentiality clauses, and some project material is covered by secrecy rules. Whether those documents may be processed in a given cloud service is a contract question, project by project, before it is a technology question. The dullest failure mode in this whole field is a tool that passes every technical review and still cannot be used on the one project it was bought for.
The checklist
Print this, bring it to the first vendor meeting, and write the answers down. Every question has a dry, checkable answer; that is the point.
| Area | Question to ask | Why it matters |
|---|---|---|
| AI Act | Which risk class do you consider your system to fall under, and on what reasoning? In writing. | Classification drives obligations for both parties; your counsel should test the reasoning. |
| AI Act | Which general-purpose AI models run underneath, and on what terms? | Upstream model terms and obligations follow into your use. |
| NIS2 | Are you in scope of NIS2 or Swedish cybersäkerhetslagen, and how do you support our incident-reporting deadlines? | Reporting clocks are short; the tool's logs may become part of the record. |
| Supply chain | Which subcontractors touch our data, and in which countries? | Supply-chain security is a legal duty for covered organisations, not a preference. |
| Residency | Where is data stored and processed? Can it be confined to the EU/EEA? | Residency is a client requirement and a sovereignty question before it is a legal one. |
| Data flow | Where do the models run, and is our data sent to public AI APIs outside the EU? | A tool can store data in the EU and still send every query to a public API in the US. Two separate data flows. |
| Jurisdiction | Under which country's law can authorities compel access to our data? | Where the servers stand and who can reach the data are different questions. |
| Training | Is our material used to train models offered to other customers? Can we decline? | Project documents usually carry client confidentiality. |
| Procurement | Do our client contracts allow project documents in your service? What do we need from the client? | Public-sector contracts and secrecy rules can veto a technically flawless tool. |
| IT security | SSO, role-based access, encryption at rest and in transit, audit logging, retention, a recent third-party penetration test? | The standard security review; a mature vendor has the pack ready. |
| Exit | How do we export everything, and what is deleted, when, on termination? | An exit that exists only in the sales deck is not an exit. |
None of this is exotic. A vendor accustomed to European engineering work will have written answers to all eleven, and hesitation is also information. Take the table to your counsel and your IT department, and let them add rows.
Sources
The guide is written to be held against any vendor, us included. If you'd like to walk through the questions with Yesper as the example, we'll answer each one.
Book demoGet the next piece in your inbox. Unsubscribe anytime.
