Most Swiss companies that introduce AI start from a tool, not an architecture. Someone tries an assistant, it works, it spreads to other teams — and only later does someone ask where the data actually ends up. By then, backtracking costs far more than starting with the right questions.
Seven points to verify before adopting an AI tool
- Data residency: does the vendor process and store data in Switzerland or the European Economic Area, or does it pass through infrastructure outside the EU?
- Use for training: is your input used to train the vendor's models, and through what opt-out mechanism?
- Legal basis for processing: for personal data belonging to customers or employees, what is the legal basis under the FADP and GDPR, and who is accountable for it?
- Data processing agreement (DPA): is there a contract governing roles and responsibilities between controller and vendor, with verifiable clauses?
- Traceability and audit: can you reconstruct, months later, which data was sent to which system and with what outcome?
- Right to erasure: if a data subject requests deletion of their data, can the vendor guarantee it on the model side too, not just the database side?
- Reversibility: if you switch vendors, can you take your data and the value you've built with you, or are you locked into a proprietary format?
Why FINMA changes the picture for the financial sector
For FINMA-regulated companies, these points are joined by outsourcing and operational risk management requirements: AI is not an exception to the existing control perimeter — it's a third-party vendor in every sense, and must be treated as such in risk governance.
Compliance as a starting point, not an obstacle
None of these checks prevent you from adopting AI: they help you choose the right architecture from the start, instead of discovering a compliance problem after a tool has already become part of daily processes. An architecture designed around these constraints from day one costs the same today and far less a year from now.