AI Compliance Under DORA and GDPR: A Practical Guide

Why regulated data stays locked, and what DORA means for your AI program.

A financial institution’s most valuable AI training data is usually the data its legal team has locked down. Transaction histories, behavioral signals, credit records: the datasets that would improve fraud detection, refine credit risk models, and deepen customer analytics are the same ones compliance, legal, and cybersecurity teams have placed off-limits for AI workloads.

The barrier is not the model. It is not compute. It is what gaining data access costs.

Healthcare organizations, insurance companies, and government agencies face similar constraints. But for financial institutions, the pressure is compounding. DORA and GDPR do not just create compliance overhead; they create a specific architecture problem that most AI platforms were not designed to solve.

Why Organizations Are Blocking AI Projects

Legal, compliance, and cybersecurity teams are raising the same concerns across industries: most AI platforms require data to be exposed during training, inference, or processing. Once sensitive information enters a traditional AI workflow, organizations face:

• Insider threats and unauthorized access
• Third-party vendor visibility into raw records
• Cross-border data transfer complications
• Data residency violations
• Breach notification exposure if a vendor is compromised

These are not theoretical risks. DORA and GDPR require organizations to demonstrate that personal and sensitive information is protected throughout its lifecycle, including while it is being processed, not just at rest but also in transit. Likewise, SOC 2 requires strong controls around confidentiality, access management, and incident response.

The result: most organizations limit AI access to heavily sanitized datasets, restrict use cases entirely, or delay deployment until governance questions can be resolved.

AI Adoption Is Now a Regulatory Pressure Point

For financial institutions, AI is no longer an innovation experiment. It is a core operational dependency. And regulators know it.

DORA’s ICT third-party risk requirements began to apply on 17 January 2025. Supervisory authorities are now actively assessing how regulated entities manage AI vendor relationships, model risk, and data handling practices. Organizations that cannot demonstrate AI governance, not just AI capability, face supervisory scrutiny.

The question facing executives is no longer whether AI should be adopted. It is whether their organization can deploy AI in a way that satisfies regulators, customers, auditors, and internal governance teams simultaneously.

Why Traditional AI Approaches Create Compliance Challenges

Most AI platforms were designed around a simple assumption: data must be accessible to be useful.

That assumption is where the compliance problem lives.

When sensitive information is processed in plaintext, organizations must place substantial trust in cloud providers, AI vendors, contractors, and administrators, a trust assumption no policy control can fully eliminate. Security teams must account for insider threats, vendor exposure, and supply chain attacks.

This is the structural problem. Centralized key custody means any party in the processing chain could, in principle, access the underlying data. Policy controls can reduce that risk; they cannot eliminate it. Organizations that have tried to satisfy DORA Art. 9(2) and Art. 6 requirements with policy-based controls alone have found that auditors increasingly ask whether those controls are cryptographically enforced.

Regulators formally require organizations to demonstrate:

• Least-privilege access controls
• Data minimization aligned with purpose limitation
• Protection of data during processing, not just at rest and in transit
• Comprehensive audit trails for every data interaction
• Effective segregation of duties
• Third-party risk management with documented controls

Traditional AI architectures cannot satisfy these requirements without either significant operational complexity or a meaningful reduction in the usefulness of the underlying data.

Running AI on Encrypted Data

Until recently, the only practical way to protect sensitive data during AI processing was to not process it at all, or to process a heavily anonymized proxy that had already lost much of its predictive signal. Homomorphic encryption (FHE) promised a third option, but real-world latency (4 to 24 hours for typical workloads) kept it out of production.

That is no longer true.

Encryption already protects two of the three states that matter. The gap is the third:

• At rest. Traditional AI: encrypted. Blind Insight: encrypted.
• In transit. Traditional AI: encrypted. Blind Insight: encrypted.
• In use, during training and inference. Traditional AI: exposed in plaintext. Blind Insight: encrypted, and the proxy cannot decrypt.

The compliance question is not “can we train a model?” It is “can we train a model without ever decrypting the underlying records?”

It is not the question most AI vendors were built to answer.

What This Looks Like for Fraud Detection

Consider a mid-sized European bank running supervised fraud detection over the past 24 months of card transactions. The data scientists know the features that matter (merchant category, transaction velocity, geographic deltas, device fingerprint), but every one of those columns is regulated personal data under GDPR Art. 4 and sits squarely in the data-in-use scope DORA’s encryption standards address. The conventional path is a six-month negotiation between data science, legal, and security to produce a pseudonymized training set, by which point the model is learning fraud patterns that are already months out of date.

With BlindML, the same team trains the model directly on the encrypted production records. The classifier sees only ciphertext. The orchestrator sees only ciphertext. Blind Insight sees only ciphertext. The model trains to the same statistical accuracy it would have on plaintext, in minutes rather than the hours a homomorphic-encryption pipeline would take, and the audit trail shows every training run as a cryptographically attested operation rather than a chain of policy approvals. The same architecture supports LLM inference on encrypted records when investigators need to query case narratives. The model provider never sees the underlying transactions.

How This Maps to DORA, GDPR, and SOC 2

This is the architecture problem that DORA, GDPR, and SOC 2 are converging on. The three subsections below cover what that means in practice for each framework.

Supporting DORA Requirements

Under DORA Art. 9(2), the regulatory technical standards on ICT risk management require financial entities to maintain an encryption policy covering data at rest, in transit, and — where necessary — in use. Encryption in use is the hard case: the standards explicitly let entities fall back to a “separated and protected environment” or equivalent measures, precisely because encrypting data during processing has been impractical. Most platforms satisfy at rest and in transit; data in use remains the gap.

For financial institutions, this is the requirement that matters most for AI workloads. Blind Insight closes it directly: because the proxy cannot read plaintext, data in use is encrypted end to end — the same cryptographic guarantee that protects data at rest, with no fallback environment required.

Zero trust as it is meant to work: enforced by math, not by policy.

Blind Insight supports DORA requirements through:

• Cryptographic enforcement of data-in-use protection (Art. 9(2)): auditors see a guarantee, not a promise
• Fine-grained access controls aligned with Art. 6 ICT risk management obligations: every data interaction is bounded and documented
• Comprehensive audit logging for AI-driven data interactions: supervisory review is supported without manual reconstruction of events
• Secure third-party collaboration without centralized plaintext exposure: AI vendors cannot access underlying data, even if their systems are compromised
• Decentralized architecture that limits the blast radius of any single compromise

Rather than centralizing sensitive information into larger risk pools, organizations maintain cryptographic control over how data is accessed, processed, and shared, even with external AI vendors.

Strengthening GDPR Compliance

Blind Insight supports key GDPR Art. 32 principles: data minimization, integrity and confidentiality, data protection by design and by default, and security of processing.

Art. 32 requires “appropriate technical and organisational measures” to ensure data security. Cryptographic enforcement of access controls is a substantially stronger technical measure than policy-based access management alone: the distinction auditors and Data Protection Authorities increasingly draw when evaluating AI deployments on personal data.

Because data never leaves its encrypted state, the information footprint crossing borders stays minimal, which eases Chapter V transfer obligations and strengthens Data Protection Impact Assessment outcomes. (A DPIA is the formal risk review regulators require before high-risk processing begins; a smaller data footprint means a shorter, simpler assessment.)

Enhancing SOC 2 Readiness

Blind Insight is SOC 2 Type II certified. The platform uses FIPS-compliant AES-GCM-256 encryption throughout.

The architecture strengthens key SOC 2 Trust Services Criteria related to confidentiality, security, access control, risk management, and monitoring. Auditors reviewing the Blind Insight vendor relationship have no plaintext to find, because the architecture ensures there is none to expose. That is a shorter and more credible conversation than explaining why policy controls are sufficient.

How Blind Insight Enables AI on Sensitive Data

So how does an organization actually run AI and train models on regulated data without ever decrypting it? Blind Insight was designed specifically to answer that question.

Invisible Technologies manages sensitive operational data for enterprise clients across regulated industries.

I’ve been looking for something that lets me grant data access without granting data exposure. That’s what Blind Insight does.

The core of the Blind Insight approach: your keys stay on your side. The orchestrator never sees plaintext. The proxy cannot decrypt your data. Architecturally, not just by policy.

This is not a configuration choice or a contractual commitment. It is how the system is built. There is no key to misconfigure, no administrator account to compromise, no vendor-side storage of plaintext. The separation is enforced by the architecture.

In practice, this means organizations can run AI workloads, including training and inference, on sensitive data without exposing that data to the AI platform, the cloud provider, or Blind Insight itself. BlindML completes a Naïve Bayes model on one million records (6 features → 1 target) in approximately 50 seconds. The same workload takes 4 to 24 hours with fully homomorphic encryption. The performance is measured on real workloads, not synthetic benchmarks.

The Organizations That Win Will Use the Data They Already Have

The organizations that will lead the next decade are not the ones that acquire more data. They are the ones that can use the sensitive, regulated data they already possess, without ever decrypting it.

The AI projects blocked today are not blocked by model capability or compute cost. They are blocked because the architecture required to move sensitive data into an AI workflow creates compliance obligations that the workflow was not designed to satisfy.

That architecture problem is now solvable. The organizations that recognize this first, and build AI programs on cryptographic data protection rather than policy-based access management, will be running AI on data their competitors are still locking away.

See the Architecture

The organizations moving first on regulated AI are not doing it by relaxing their data controls. They are doing it by changing what their architecture requires.

See the Blind Insight platform: key custody, proxy design, and compliance enforcement walked through end to end.

Ready to evaluate it on your own data? Schedule a 30-minute scoping conversation: fifteen minutes on your schema, a clear yes or no on whether Blind Insight fits.