What supervised institutions in Switzerland and the EU must be able to prove when AI accelerates their software delivery – and how to design gates, evidence, and vendor governance so the next audit is a formality. Written from delivery practice, not from the sidelines.
The question is not whether AI is allowed. It is what you must be able to show. Switzerland has no AI-specific banking law — deliberately. FINMA's Guidance 08/2024 makes the existing technology-neutral, principle-based requirements explicit for AI: keep an inventory of AI applications, classify their risks, assign responsibilities to named roles, ensure data quality, test and monitor continuously, document, and make critical systems independently reviewable. FINMA also noted that most institutions are still early in building these structures — which makes governance maturity, right now, a visible differentiator.
Around the Swiss core, three regimes reach in. DORA binds EU financial entities — and travels contractually to their ICT providers, so Swiss suppliers to EU institutions inherit obligations on resilience, incident reporting, and audit rights. The EU AI Act is largely relevant for Swiss banks with EU exposure through clients, subsidiaries, or outsourced functions; most SDLC uses of AI sit outside the high-risk categories, but transparency and inventory duties still apply. The revFADP governs what leaves your perimeter when a tool sends code context to a model — source code carries personal data and protected business logic more often than teams assume.
And realistically: much does not apply. An internal coding assistant is not a high-risk AI system under the AI Act; a documentation generator does not trigger model-risk regimes built for credit decisioning. Over-compliance wastes budget as reliably as under-compliance creates findings — classify first, then control proportionally.
future articles on this sub-topic will be linked here
The audit conversation about AI in your SDLC has converged on a stable chain of five questions. One — inventory: which AI tools, in which versions, touch your delivery pipeline, including the ones a team adopted informally last quarter? Two — attribution: for any change in production, can you show which parts were AI-suggested and which human hands authored or accepted them? Three — gates: where does a human review sit between AI output and anything consequential, and can you prove the gate was exercised, not merely configured? Four — data path: what left your perimeter into a third-party model, where is it retained, and is training on your data excluded contractually and technically? Five — reproducibility: when an incident traces to an AI-assisted change from months ago, can you reconstruct the review that approved it?
The failure mode is answering audit questions with demo answers. "Our tool has an approval feature" is a demo answer; the audit answer is a log export showing named reviewers, timestamps, and decisions for a sample of real merges. "The vendor says they don't train on our data" is a demo answer; the audit answer is the signed clause plus the configuration screenshot plus the verification test. The gap between the two is exactly what this guide's companion asset — the Audit Readiness Checklist — makes you close before an examiner does.
future articles on this sub-topic will be linked here
Regulators ask for "human oversight." Auditors ask for something sharper: oversight that would survive cross-examination. A defensible gate records four elements — the identity of the reviewer (a named person, not a team alias), their competence for this class of change (a junior rubber-stamping a security-relevant refactor fails the test), the time and object of review, and the basis of decision (what was checked, what was waived, why). Remove any one element and "a human clicked approve" collapses into ceremony.
Placement follows autonomy. Where AI merely suggests, the ordinary code-review regime carries the load — provided AI-assisted changes are tagged so reviewers know what they are reviewing. Where AI executes, gates must be technically enforced: branch protection that cannot be bypassed, pipeline rules that block unreviewed AI changes from promotion, batch checkpoints with defined sampling where full review is impractical. The principle that keeps the design honest: gate strength must rise with autonomy, and gate evidence must be producible without heroics. Our Modernization Framework is the worked example — every AI-executed change held at a technically enforced gate, every approval recorded against a commit SHA.
future articles on this sub-topic will be linked here
Evidence is a supply chain: it either runs unbroken from the first analysis to the production commit, or it doesn't exist when you need it. The links, in order: commit-SHA linkage — every AI-assisted change resolvable to which tool and version proposed it, who approved it, under which policy. Retention policy for prompts and responses — defined, documented, and deliberately bounded: you retain enough to reconstruct decisions, not a shadow archive of your codebase inside chat logs; the privacy tension is real, so resolve it by policy, not by accident. Architecture decisions as evidence — retrieval-only model access, meaning client code is never training material, is a control you can demonstrate, not just assert. Consumable artifacts — versioned analysis reports (our framework's system report runs to ~194 pages for a mid-size estate) and an exportable audit package an examiner can walk without a workshop.
Retention horizons should follow your existing incident-and-audit windows rather than inventing AI-specific ones — if your organization can investigate a production incident from three years ago, your AI evidence must reach as far. And log deliberately, not maximally: every artifact you retain is also an artifact you must protect, disclose, and eventually delete.
future articles on this sub-topic will be linked here
Data residency is an architecture property, not a paragraph in a vendor's FAQ. For Swiss supervised institutions the workable options are concrete: CH/EU-region processing for model traffic, contractual and technical exclusion of training on your data, and defined retention for anything the provider touches. The clauses that actually matter in model-provider agreements are a short list: training exclusion (verified — a configuration you can screenshot, not a marketing page), retention and deletion (what is cached, where, for how long), sub-processor transparency (who else sees traffic, under which jurisdiction), and — where DORA reaches you through EU clients — audit and exit rights that let you leave with your evidence intact.
Then the honest sentence most vendor decks omit: the regulated stack carries a cost premium. CH/EU residency, dedicated capacity, extended logging, and contractual audit rights cost more than the default hyperscaler path — visibly so. Budget the premium explicitly and defend it as what it is: the price of answering the regulator with configuration exports instead of apologies. It is far cheaper than the alternative — discovering mid-audit that your delivery pipeline routes client code through an untracked sub-processor.
future articles on this sub-topic will be linked here
Governance fails in the seams between roles, so draw the seams deliberately. A working split: engineering owns the controls' implementation — gates, tagging, evidence generation — because controls bolted on from outside get bypassed under deadline pressure. The CISO owns the control catalogue and its verification: which gates must exist, how they are tested, what the sampling regime is. Risk/compliance owns classification and the regulator interface: which applications carry which risk class, what gets reported, what the audit narrative is. Vendors and delivery partners owe evidence in your format, contractually — their attestation is an input to your file, never a substitute for it.
Give the system a cadence or it decays: quarterly evidence refresh (inventory, clauses, configurations re-verified), periodic gate-log sampling by someone who did not build the gates, and a standing slot where engineering and compliance review upcoming AI-tool changes before adoption instead of after discovery. That last ritual is also how compliance escapes the department-of-No trap — involved early, it shapes; involved late, it can only block. The end state this guide argues for: compliance is a delivery feature. Build for audits, not just for demos — and the audit becomes a formality instead of a project.
future articles on this sub-topic will be linked here
Yes — as a provability question, not a permission question. Swiss regulation is technology-neutral: FINMA expects governance, documentation, and reviewability, not abstinence. If you can show who reviewed each AI-assisted change, where the approval is recorded, and that your data never trains third-party models (chapters 3–4), the answer is yes. If you can’t, the problem isn’t the AI.
Directly, no — DORA binds EU financial entities. Practically, yes: their obligations reach you through contracts, as requirements on resilience, incident cooperation, audit rights, and exit support. If your clients are EU-supervised institutions, expect DORA-shaped clauses and be able to satisfy them (chapter 1).
Less than the panic suggests. A coding assistant used as a development tool is not a high-risk AI system under the Act’s classification; what remains are transparency and inventory duties, and everything your own governance already requires. The sober move is classification before controls — over-compliance burns budget that real controls need (chapter 1).