If you run an insurance company, a financial services firm, or a healthcare organisation in the DACH region, you already know the refrain: "We'd love to use AI, but our industry is too regulated."
It is a reasonable concern. And it is the wrong conclusion.
Regulated industries are not less ready for AI. In many respects they are more ready — because the compliance muscle is already developed, the data is already catalogued (even if it is not cleanly structured), and the processes are already documented (because the supervisor requires it). What you face is not a readiness deficit. It is an additional readiness dimension: regulatory capacity. Handled correctly, that dimension becomes an accelerator rather than a blocker.
The regulatory landscape for AI in DACH
Three layers of regulation shape AI readiness for a regulated DACH company, and the practical move is to map your specific workflow against all three before you write a line of code.
The DSGVO is the floor, and the DPIA is the critical path. Almost every AI workflow in insurance, finance and healthcare processes personal data, which puts it squarely under the GDPR. The instrument that matters most is the Data Protection Impact Assessment. Under Article 35, a DPIA is mandatory before processing begins whenever the processing is "likely to result in a high risk to the rights and freedoms of natural persons" — and the regulation explicitly names systematic, extensive automated evaluation of individuals, including profiling, as one of the triggers. That description fits most underwriting, pricing, scoring and claims-triage use cases almost word for word. A DPIA requires a systematic description of the processing, an assessment of its necessity and proportionality, a risk assessment of the rights of data subjects, and the measures that address those risks. If your Data Protection Officer has run DPIAs for other digital initiatives, they already hold the methodology. AI does not invent a new one; it just makes the existing one non-optional.
The EU AI Act adds a risk classification on top. The Act classifies certain uses as high-risk under Annex III, and two of its categories land directly in regulated financial services: AI systems used "to evaluate the creditworthiness of natural persons or establish their credit score" (Annex III, point 5(b), with an exception for fraud detection), and AI systems used "for risk assessment and pricing in relation to natural persons in the case of life and health insurance" (point 5(c)). High-risk classification triggers concrete, well-defined obligations — a conformity assessment, technical documentation, a quality and risk-management system, human oversight, logging, and post-market monitoring. The obligations are demanding, but they are not ambiguous; the Act tells you what is required. One timing nuance matters for planning: under the Digital Omnibus package the Commission proposed on 19 November 2025, the application date for stand-alone Annex III high-risk obligations is being deferred from 2 August 2026 to 2 December 2027. That is breathing room, not a reprieve — and it only takes legal effect once the Omnibus is formally adopted and published. Treat the obligations as coming, and design for them now.
Sector supervision sits above both. For banks and insurers, BaFin published its Guidance on ICT Risks in the Use of Artificial Intelligence at Financial Entities in early 2026. Its central message is a useful tell for the whole sector: AI is no longer framed primarily as an innovation or ethics question but as part of ICT risk management under DORA. In BaFin's framing, an AI system must be governed, secured and monitored across its entire lifecycle — from data acquisition through to decommissioning — inside the institution's existing ICT risk-management framework, underpinned by a management-approved AI strategy and clear responsibilities. In healthcare, the gating question is whether your system meets the definition of a medical device. Under the Medical Device Regulation (MDR 2017/745), software with a medical intended purpose — diagnosis, prediction, monitoring — is regulated as Software as a Medical Device, and under Rule 11 most clinical-decision-support software lands in Class IIa or higher, which means a notified body and a conformity assessment before it reaches a clinical setting. For many AI products in this space, both the MDR and the AI Act apply at once. These sector layers add complexity. They do not add impossibility.
Why a strong compliance posture accelerates readiness
Here is the counterintuitive part. For regulated companies, a mature compliance function does not slow AI readiness down — it front-loads most of the groundwork that unregulated companies have to build from scratch.
Documentation discipline is the first advantage. Regulated companies document their processes because they must, which means the workflows that are candidates for automation are already described, measured and monitored. In a lightly regulated company, the opening move of any AI initiative is "figure out what the process actually does." In a regulated one, that map already exists.
Risk-assessment capability is the second. Regulated firms run risk functions that evaluate new systems against regulatory requirements as routine. The team that already assesses a new claims platform against its supervisory obligations can assess an AI-assisted claims-triage system using the same machinery — and, as BaFin's guidance makes explicit, the expectation now is precisely to fold AI into the established ICT risk framework rather than treat it as a special case.
Audit readiness is the third. Regulated companies maintain audit trails because supervisors require them, and AI systems need audit trails of their own — over model decisions, data access and human overrides. The infrastructure and the organisational habit are already in place. The EU AI Act's own logging requirement for high-risk systems fits comfortably into that existing discipline rather than inventing a new one.
Governance scaffolding is the fourth. Approval workflows, change management, oversight committees — these can feel slow, but they are exactly the structures an AI initiative needs to deploy responsibly and to survive contact with a supervisor. The companies that struggle most are not the heavily regulated ones; they are the lightly regulated ones with no documentation, no risk function and no governance, who have to assemble all of it under deadline pressure.
Run the DPIA as a design tool, not a legal checkpoint
The single most mismanaged element of AI readiness in regulated industries is the sequencing of the DPIA. Companies treat it as something the lawyers produce after the technical team has built the system. That sequence guarantees delay, rework and frustration — and it is also a misreading of the regulation, which requires the assessment prior to processing, not after the build.
Start the DPIA in week one, alongside technical scoping, and let it shape architecture rather than review it. Done this way, it forces four questions that make the deployment better, not slower. The data-minimisation question — what personal data do you actually need? — imposes a discipline most technical teams skip, and trims engineering complexity and storage in the process. The lawful-basis question prevents the catastrophic month-four discovery that you have no legal basis for processing you have already built. The risk question surfaces failure modes — biased outputs, leakage, wrong decisions — that the technical team ought to be testing for anyway. And the human-oversight question defines your human-in-the-loop architecture before the system exists, rather than bolting it on afterwards. The DPIA stops being a gate and becomes a specification. This is the same capacity-based logic that separates useful assessments from useless ones.
How Remote Native builds for regulated industries by default
Our approach is not to add a compliance module on request. It is default-strict: we build every deployment as if it will be audited, whether or not the client is regulated. In practice that means processing on EU-based infrastructure so there are no transatlantic transfers to justify; scoping every workflow to the minimum data categories required, because data minimisation reduces engineering risk as much as it satisfies the DSGVO; logging every model decision, data access and human override with timestamps and attribution from day one, as a core architectural component rather than an add-on; producing human-readable explanations alongside any output that affects an individual — a claim, a credit decision, a price — to meet the Act's transparency and human-oversight expectations; and keeping a human in the loop on first deployments, because review builds organisational confidence and aligns with supervisory expectations while the system earns trust.
The point of default-strict is economic as well as technical: a regulated company does not pay a "compliance premium" for its first deployment, because compliance is already inside the standard build. The realistic added cost of working in a regulated sector is not a separate project — it is the DPIA and, where the use case is high-risk, the conformity and sector documentation. For a single, well-scoped first workflow, that is a matter of weeks of additional elapsed work running in parallel with the build, not a separate twelve-month legal programme. The honest variable is not whether it is achievable but which classification you land in: a back-office summarisation workflow and a life-insurance pricing model sit on very different sides of Annex III, and the right first move is to pick a use case whose compliance path you can see clearly from the start.
That is also why the most common failure mode in this sector is not regulatory — it is choosing a first workflow whose risk classification you have not actually checked. Map the workflow against the DSGVO, the EU AI Act and your sector's supervisor before you scope the build, and the compliance dimension stops being the thing that blocks you and becomes the thing that proves you can be trusted to scale.
A Fit Call maps your specific workflow against the DSGVO, the EU AI Act and your sector's supervisory requirements — in 20 minutes, not 30 pages — so you know whether the compliance path is clear before you commit budget.
References: Regulation (EU) 2016/679 (GDPR), Art. 35 — Data Protection Impact Assessment, https://gdpr-info.eu/art-35-gdpr/; EU AI Act, Annex III (high-risk systems), https://artificialintelligenceact.eu/annex/3/; European Commission, Digital Omnibus on AI (proposed 19 November 2025) — deferral of Annex III high-risk obligations, https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/; BaFin, "Guidance on ICT Risks in the Use of Artificial Intelligence at Financial Entities" (2026), https://www.bafin.de/SharedDocs/Veroeffentlichungen/EN/Meldung/2025/meldung_2025_12_18_orientierungshilfe_ikt_risiken_en.html; Regulation (EU) 2017/745 (MDR), software-as-a-medical-device classification, https://decomplix.com/ai-medical-device-software-eu-mdr-ivdr/.