Every financial institution running AI pilots faces the same structural problem. The engineering team wants to feed real transaction data, real credit files, real KYC records into the model — that is where the useful signal lives. The compliance and legal teams say no, and their reasons are not arbitrary. They have specific obligations under FISC guidelines, APPI, and internal data governance policies that make running a large language model on live customer data an unsolved problem given current cloud architectures.
This is not a risk appetite conversation. It is an architectural one. And the path forward is not looser compliance interpretation — it is a different technical approach to where and how computation happens.
What Compliance Teams Are Actually Worried About
When a bank's compliance officer objects to running an AI workload on a public cloud, the concern is usually framed around data residency or third-party access. But the deeper technical problem is this: in a standard cloud compute environment, the cloud provider's infrastructure — their hypervisor, their management plane, their privileged OS-level access — has the ability to observe memory during execution. Even if the provider has contractual obligations not to look, the technical pathway exists.
Data encrypted at rest on a storage volume is unreadable to the provider. Data traversing a TLS connection is encrypted. But data being processed by an inference workload — sitting in RAM, being operated on by the CPU — is in cleartext. The encryption stops at the boundary of the computation.
FISC Security Guidelines for financial institutions (the Center for Financial Industry Information Systems guidelines that Japanese banks are expected to follow) address cloud outsourcing with requirements around auditability of processing and control over data access pathways. A cloud provider having theoretical read access to live transaction data during computation is precisely the kind of configuration that raises flags in a FISC compliance review. APPI's requirements on handling of personal information by third-party processors compound this: the bank remains responsible for ensuring appropriate handling even when a third party (the cloud provider) touches the data.
So the compliance team's "no" is well-founded. The question is whether the engineering team's request has a legitimate answer.
Why De-identification Doesn't Solve It
The common workaround is de-identification: strip names, account numbers, and explicit identifiers before feeding data to the model. This works for some use cases and fails for others. For transaction anomaly detection — one of the higher-value AI applications in banking — de-identification systematically degrades the model's ability to do its job. The pattern that indicates a compromised account often involves the intersection of merchant category, amount, time, and account behavioral history. Strip the account linkage and you lose the longitudinal signal. Aggregate to cohort level and you lose the anomaly.
For credit risk models trained on real applicant behavior, de-identification faces a similar problem: re-identification risk from quasi-identifiers means that even supposedly stripped data may retain regulatory exposure, while the practical quality of stripped data is lower. The compliance team often rejects the de-identified dataset anyway because they cannot verify it is actually de-identified to the standard required.
We are not saying de-identification is always inadequate — for some training workloads on historical data it is entirely appropriate. We are saying that for real-time inference on live individual records, de-identification trades away the value proposition of the AI without reliably satisfying the compliance constraint it is meant to address.
The Enclave Architecture: What Changes
Confidential computing hardware — specifically Intel TDX or AMD SEV-SNP — creates a hardware-enforced memory boundary around a workload. Inside that boundary, the CPU guarantees that no external entity, including the host OS and the cloud provider's hypervisor, can read the contents. Data decrypts only inside the boundary and re-encrypts before leaving it.
For a banking AI workload, this changes the architecture as follows. The inference model is packaged and cryptographically measured before deployment — the measurement hash is fixed and registered. Transaction records enter the enclave encrypted with a key that only exists inside the hardware boundary. The inference runs on real data. The result exits along with an attestation report: a hardware-signed certificate asserting exactly which code version ran, in which hardware environment, at which timestamp.
The cloud provider's infrastructure handles compute scheduling and networking. But the inference layer — the code and data — is behind a hardware boundary the provider cannot cross. Their operational exposure is structurally equivalent to colocating a server in a third-party data center: they manage the facility, they do not touch what's inside.
What the Compliance Team Gets
The value to the compliance function is not just that data is protected during processing — it is that protection is verifiable and auditable rather than promised.
Consider a synthetic scenario: a growing bank's AI team deploys an enclave-based inference pipeline for transaction monitoring. The compliance team receives, per inference run: a timestamped attestation report from the CPU firmware, identifying the exact measurement hash of the running code; a key derivation log showing that the decryption key was generated inside the enclave and never exported; and a hash of the input and output records. Each execution is documented with cryptographic evidence tying the data handled to the specific code version approved in the internal review process.
That documentation changes the nature of the FISC audit conversation. Instead of presenting a contractual data processing agreement and asking an auditor to trust that the provider didn't access the data, the compliance team presents hardware-generated evidence that the only code that touched the data was the approved, measured build. The argument moves from trust to verification.
The Remaining Friction Points
Enclave-based inference is not yet zero-friction to deploy. Workload packaging — ensuring the inference code runs correctly inside a TEE without assuming access to the full host OS — requires upfront engineering work. Key management inside the enclave needs careful design: keys must be sealed to the enclave measurement so they cannot be extracted to a different code version, but rotation and emergency access procedures need to be thought through. And attestation verification needs to be integrated into whatever compliance evidence workflow the bank is operating.
Performance overhead is a real consideration too. Memory encryption introduces a latency penalty, typically in the range of 5–15% for compute-bound workloads depending on hardware generation. For batch inference that overhead is generally acceptable. For real-time decisioning systems with tight SLA requirements, the architecture needs benchmarking before deployment commitments are made.
None of these are showstoppers, but they are genuine engineering tasks rather than checkbox items. The banks that get to production fastest are the ones that scope the pilot around a specific inference workload — not "all AI" but "the transaction anomaly model, running on live data from the past 24 hours, with these specific attestation requirements" — rather than trying to redesign the full data platform in one step.
The Practical Question
If you are an engineering lead at a financial institution that has been told "no" by compliance on an AI pilot, the question worth asking is whether the objection is about the data sensitivity itself or about the architecture that currently handles that data. If the compliance team's concern is that a third party can see the data during computation, that is an architectural problem with a hardware solution. The path forward is not to convince compliance to accept more risk — it is to show them a pipeline design where the risk they identified does not exist.