The Encryption Gap in Your AI Pipeline, and How OpenText and Utimaco Close It

Enterprises are building AI pipelines on top of sensitive data at speed. The encryption controls protecting that data often have not kept pace. Here is what the gap looks like, and what a hardware-rooted solution does about it.

According to the Ponemon Institute's 2024 Cost of a Data Breach report, the average breach now costs $4.88 million; a ten percent increase year-on-year and the highest figure since the pandemic. Forty percent of those breaches involved data across multiple environments: cloud, on-premises, and hybrid. That number is not a coincidence. It reflects a structural problem in how organisations manage sensitive data as it moves between systems. AI adoption is making this structural problem harder to ignore. Every new AI pipeline is, at its core, a new data movement pattern: data flows from source systems into feature stores, training environments, and inference endpoints. If sensitive fields are not protected at the data level before that journey begins, each new pipeline expands the exposure surface.

Transport-layer encryption protects data in motion. Disk encryption protects data at rest. Neither protects data while it is being processed, which is exactly when an AI model reads it.

The real gap: encryption that disappears at the point of use

Most organisations have TLS in place and encrypt databases at rest. Both protections are necessary. But both have the same limitation: they are removed the moment an application reads data into memory to process it. For traditional batch workloads, this window is narrow and controlled. For AI pipelines, which ingest, transform and recombine data across multiple systems continuously, the unprotected window is structural, not incidental. The answer is field-level encryption: protecting individual data fields at the point of capture so that a customer name, a payment card number, or a healthcare record remains a protected value as it moves through every downstream system. An AI model training on tokenized PAN values never sees the original card numbers. An analytics pipeline running on encrypted PHI fields never has cleartext patient data in memory. OpenText Data Privacy and Protection (DPP) implements this using NIST-approved AES FF1 Format-Preserving Encryption (FPE). FPE is significant because it protects data without changing its shape: a 16-digit card number remains 16 digits after encryption, passing Luhn validation and fitting existing database schemas unchanged. Applications and AI pipelines consume protected data without modification. The encryption gap closes without re-engineering the systems built on top of it.

Why format matters for AI pipelines 
Traditional encryption changes data structure, breaking downstream schemas, validation logic, and model features. AES FF1 Format Preserving Encryption keeps protected data structurally identical to the original, so it flows through databases, data lakes, and AI training jobs without breaking anything. Protection is applied once, at the source; every downstream system benefits automatically.

Why key management is the harder problem

Field-level encryption solves the exposure problem, but only if the keys are genuinely secure. This is where many implementations fall short. Keys stored in software key management systems, cloud KMS services with exportable key material, or  more often than anyone admits  in configuration files and environment variables represent an architectural weakness that policy controls cannot close. 

OpenText DPP uses a stateless key derivation architecture: instead of storing a unique key per record, the system derives keys on demand from a small number of root secrets. There is no key database to breach, no backup tapes to audit, and no rotation event that requires touching millions of encrypted records. This is how DPP scales field-level encryption to the data volumes that AI workloads require. 

The remaining question is where those root secrets live. OpenText DPP integrates with certified HSMs via the standard PKCS#11 interface, making the HSM the single hardware authority for all key operations. The Utimaco u.trust General Purpose HSM Se-Series, now validated to FIPS 140-3 Level 3, provides that hardware anchor. 

Keys are generated inside the HSM and configured as non-exportable. Every encryption and decryption operation executes within the tamper-proof hardware boundary. There is no software path, no administrative bypass, and no cloud API through which key material can be retrieved. The root secrets that govern every field-level protection operation across the entire data estate never leave the device.

When the HSM holds the root secrets and keys are non-exportable, an attacker who compromises every other layer of the infrastructure still cannot decrypt the data. That is what hardware-rooted security means in practice.

The quantum dimension: why the migration window is open now

Utimaco estimates that a cryptanalytically relevant quantum computer capable of breaking RSA and ECC is expected by 2030. For organisations encrypting sensitive data today, this creates a concrete near-term risk: harvest now, decrypt later. Adversaries capture encrypted data today and hold it until quantum computing makes classical encryption reversible. Data with long retention requirements, like health records, financial history and legal documents, is already in scope for this threat. 

In April 2025, Utimaco launched Quantum Protect, a field-activatable firmware package for the u.trust GP HSM Se Series. It adds NIST-standardized ML-KEM and ML-DSA algorithms, plus stateful hash-based signature schemes LMS and XMSS, to the existing HSM without hardware replacement. 

Organisations that have centralised key management in Utimaco hardware can upgrade their cryptographic posture at the firmware layer, leaving every application above it unchanged. Organisations that have not centralised key management face a more complex migration: every system that holds or uses key material must be individually assessed and updated. The architectural decision to use hardware-rooted key management pays forward into the quantum transition.

OpenText DPP + Utimaco u.trust GP HSM: how it works together

OpenText DPP provides the data protection layer: field-level AES FF1 encryption and tokenization applied to PII, PAN, and PHI across databases, payment hosts, data lakes, and cloud platforms including AWS, Azure, GCP, Snowflake, and on-premises environments. Security districts define consistent protection policies across heterogeneous infrastructure, so the same encryption rules apply whether data resides in a mainframe, a cloud data warehouse, or a SaaS platform. 

The Utimaco u.trust GP HSM Se-Series provides the key management anchor. DPP master keys are generated and stored inside the HSM via PKCS#11. Stateless session keys are derived from those roots on demand and never persist outside the hardware boundary. The complete cryptographic chain, from key generation through field-level encryption to tokenization, executes with hardware-level assurance.
 
 

What this means for compliance 

PCI DSS cardholder data environment scope shrinks materially when PAN values are tokenized before entering any system. GDPR pseudonymisation requirements are met at the data layer rather than at the application layer. HIPAA technical safeguard controls are satisfied by hardware certification. The joint solution addresses the compliance requirements of financial services, healthcare, public sector, and retail environments through a single, certified architecture.
 

GP HSM Simulator | Quantum Protect Simulator | Contact Sales
 

About the Author

Amani Karchoud

Product Marketing Manager, Utimaco