AI Compliance & Audit | Certifiable Rust Architecture | Lexiane

Compliance requirements applicable to artificial intelligence systems are tightening. IEC 62304 Ed. 2, ISO 26262, DORA, NIS2, GDPR, AI Act: frameworks are accumulating, their scopes overlap, and deadlines are narrowing. Most organizations seeking to deploy AI in regulated environments face the same reality: available solutions were designed for other contexts, and compliance is treated as a layer to add after the fact — a documentary process on a system that does not make it possible by nature.

Lexiane is designed in the reverse order. Compliance is not a feature. It is the direct consequence of a set of architectural decisions made from the very first lines of code.

---

Regulated AI: what your auditors will look for — and what most systems cannot provide them

An auditor working on an AI system in a regulated environment invariably asks the same fundamental questions.

Traceability. Who decided what, on what basis, at what time? For a document processing or response generation system, this means: which document was ingested, through which pipeline, with what parameters? Which filtering decision was applied, to which data? Which response was produced, from which sources?

Isolation of third-party components. In the IEC 62304 and ISO 26262 frameworks, a software component whose source code is not entirely controlled by the manufacturer is classified as SOUP — Software of Unknown Provenance. SOUP must be identified, documented, and its interface with the certified system must be explicitly delimited. On a typical Python system, this boundary is structurally impossible to trace: libraries import each other, transitive dependencies are numerous, and the line between controlled code and SOUP code is inherently blurry.

Determinism and absence of undefined behavior. A certified system must behave predictably. A garbage collector that triggers a pause at a critical moment, a bug masked by Python’s dynamic typing, an implicit dependency between two modules — each of these phenomena is a source of non-deterministic behavior that an auditor cannot accept without compensation.

Data sovereignty. In regulated environments — defense, healthcare, finance, public sector — the question of data localization is not a preference. It is a regulatory or operational requirement whose non-compliance exposes the organization to penalties, liabilities, or sovereign risks.

Lexiane was designed to respond to these four requirements — not by declaration, but through mechanisms verifiable by inspection of the code and architecture.

---

An architecture whose compliance properties are proven at compilation

The certified perimeter: a kernel without compromise

Lexiane’s core — vectrant-core — is subject to an absolute constraint: #![forbid(unsafe_code)]. This directive is not a development convention or a code review rule. It is enforced by the Rust compiler itself. No developer can introduce an unverified memory operation in the certified perimeter, even inadvertently, even under pressure — the compiler rejects the code before the binary exists.

Within this perimeter, the following properties are mechanically guaranteed:

• No null pointers: optional values are expressed via Option<T>, whose handling is exhaustive and verified at compilation.
• No memory leaks or use-after-free: Rust’s ownership system eliminates these bug categories by design — without a garbage collector, without additional runtime.
• No ignored error paths: the #[must_use] marker is applied to all results. An unhandled error path is a compilation error, not a bug discovered in acceptance testing or production.
• No unwrap(), expect(), or panic!() in production code: verified by an automated test in continuous integration. Any regression is detected immediately.

What this represents for an auditor: a perimeter whose security properties are proven at compilation, independently of individual developers’ practices.

SOUP isolation: an architectural boundary, not a documentary one

Lexiane is structured according to a strict hexagonal architecture. The certified core communicates with the outside world exclusively via 25 typed abstraction interfaces — explicit interface contracts, statically verified. No external dependency can penetrate the kernel without passing through one of these interfaces.

Third-party components — language models, vector databases, document parsers, cloud APIs — are adapters that implement these interfaces. They are entirely classifiable as SOUP, with a clear and verifiable architectural boundary: the list of interfaces. What is inside is controlled. What is outside is documented and isolated.

A complementary constraint reinforces this separation: the certified kernel contains zero vendor dependencies — verified by an automated test that fails at compilation if an external dependency is introduced. This test is part of the continuous integration suite: regression is impossible without being immediately detected.

Static validation of dependencies between components

Lexiane’s pipeline validates its internal dependencies at assembly, before any execution. Each stage declares the data it consumes and the data it produces. The assembler statically verifies that all dependencies are satisfied before the pipeline starts.

For an auditor, this means that a configuration error — a missing stage, an unsatisfied dependency, a misconnected component — is not a bug that appears at runtime on real data. It is an assembly error detected before the system processes a single document.

---

GDPR compliance: data protection by architecture

Data residency as a physical property

GDPR requires localization of personal data under conditions that the data controller can control and document. Most cloud AI solutions satisfy this requirement by contract: a clause stipulates that data remains in a defined geographic zone. Compliance rests on trust in the vendor’s respect for this contract.

Lexiane offers a fundamentally different alternative: in its air-gapped configuration, data does not leave your perimeter because the architecture makes it physically impossible — not because a contract prohibits it. There is no network call to monitor, no flow to audit: the binary has no active network interface toward the outside. No document, no fragment, no embedding can exit your infrastructure.

For a data protection officer, the difference is fundamental: this is an architectural guarantee, not a contractual one.

PII filtering: before the data, not after

Lexiane’s personal data filter operates upstream of the pipeline — before any vectorization, any indexing, any language model call. Detected categories cover the most common personal data in professional document corpora: email addresses, phone numbers, IBAN, social security numbers, IP addresses.

Three processing policies are available and configurable by data category:

• Typed masking — the value is replaced with a semantic placeholder ([EMAIL], [IBAN], [SSN]). The data type remains readable for semantic processing. The value is inaccessible.
• Deletion — the value is removed from the fragment before any pipeline transmission.
• Hashing — the value is replaced with its cryptographic fingerprint. Referential consistency is preserved without exposing the data in plaintext.

GDPR compliance is not treated as a post-production step. It is inscribed in the processing flow as a prerequisite to any sensitive operation.

The audit trail as a processing register

GDPR requires data controllers to maintain a register of processing activities and to demonstrate the compliance of their processing on request from a regulator. Lexiane’s cryptographic audit trail constitutes a technical register of every operation performed on every document: document identity, timestamp, operations applied, filtering policies activated, user accesses.

This register is not a log file. It is a SHA-256 chain: each entry is signed by the hash of the previous one. Any retrospective modification of a record is mathematically detectable. Compliance proof is in the chain itself — not in a declaration.

---

Sector regulations: what Lexiane makes possible

Healthcare and medical devices — IEC 62304 Ed. 2

The revision of IEC 62304, whose publication is expected for August 2026, will introduce for the first time explicit requirements on software embedding artificial intelligence and machine learning components. For medical device manufacturers who are today developing or integrating AI-based documentary systems, this deadline is not distant: a certification cycle is measured in years, not months.

Lexiane is the only RAG engine designed from its foundations to respond to this framework:

• Certified perimeter with #![forbid(unsafe_code)] — security properties are verifiable at compilation
• Explicit SOUP isolation via hexagonal architecture — third-party dependencies are documented and delimited by typed interfaces
• SHA-256 audit trail on every pipeline decision — traceability is structural, not optional
• Compatibility with Ferrocene — the Rust compiler qualified for IEC 62304 and ISO 26262 (see below)
• Absence of undefined behavior guaranteed by the type system — bug categories classified as risks in IEC 62304 are eliminated by design

For a medical device manufacturer, this means that the qualification dossier for the AI software component can rely on mechanical evidence — not only on declared processes.

Automotive and embedded systems — ISO 26262

The integration of AI in automotive embedded systems raises functional safety questions that ISO 26262 cannot ignore. A system that processes vehicle information — technical manuals, diagnostics, product knowledge bases — must satisfy determinism and auditability requirements incompatible with the structural characteristics of Python frameworks.

Lexiane responds to these requirements through two fundamental properties:

No garbage collector. Rust manages memory statically, without an automatic collection mechanism. There is no unpredictable GC pause liable to violate a real-time constraint. The system’s temporal behavior is deterministic by design — a property that Python or JVM runtimes cannot offer.

The standalone static binary. Lexiane compiles into a single binary with no dynamic dependencies. It requires no interpreter, no virtual machine, no package manager. In an embedded environment without permanent network connectivity, this property is essential: the system operates as qualified, without dependency on an external runtime environment liable to evolve.

Compilable with Ferrocene, Lexiane can be integrated into an ASIL D qualification dossier — the most demanding level of ISO 26262.

Finance — DORA and prudential requirements

The DORA regulation (Digital Operational Resilience Act), applicable since January 2025, imposes on financial entities reinforced requirements for digital operational resilience, third-party risk management, and traceability of critical systems.

For a financial institution deploying an AI system on internal data — risk reports, regulatory documentation, operational procedures — Lexiane brings directly relevant guarantees:

• Independence from third parties: each Lexiane component is interchangeable via its abstraction interfaces. Dependency on a single LLM or embeddings provider is eliminated by architecture. If a provider becomes unavailable or changes its terms, migration does not touch the pipeline or indexed data.
• Decision traceability: the SHA-256 audit trail documents every data access, every produced response and its sources. For a supervisor or internal auditor, every system decision is reconstructible.
• Total on-premise deployment: sensitive financial data does not transit through third-party infrastructure. Localization is controllable and documentable.

Public sector — GDPR, NIS2, and digital sovereignty

Public administrations face a dual structural constraint: processing growing volumes of regulatory and administrative documentation, while ensuring that citizen data and sensitive information remain under sovereign control.

NIS2, GDPR, and growing orientations toward SecNumCloud-qualified solutions make data residency and AI system auditability unavoidable. Lexiane offers an architectural answer here: air-gapped deployment structurally excludes any data transfer to a third-party provider, regardless of their location or contractual commitments.

---

Ferrocene: when the compiler itself is part of the qualification dossier

The chain of trust of a certified system does not stop at the source code. It includes the tool that transforms this code into an executable binary. This is the challenge of compiler qualification.

Ferrocene is the qualified version of the Rust compiler, developed by Ferrous Systems. It is qualified ISO 26262 up to ASIL D level (automotive systems) and IEC 61508 SIL 4 (industrial functional safety). The IEC 62304 Ed. 2 qualification, which will incorporate explicit requirements on AI/ML systems, is anticipated to accompany the standard’s publication in 2026.

Ferrocene provides its users with evidence packages — structured documentary sets that allow auditors to verify that the compiler itself satisfies the requirements of the target framework. The chain of trust is complete: from source code, to the compiler, to the binary deployed in production.

Lexiane is designed to be compiled with Ferrocene. For a medical device manufacturer, an automotive equipment supplier, or a defense integrator, this means there is no missing link in the qualification dossier.

No Python RAG framework can offer such a guarantee. Not due to any lack of care from its developers — but because Python does not have an equivalent qualified compiler, and the totality of its runtime dependencies would constitute a volume of SOUP that no certification framework can reasonably absorb.

---

What your auditors obtain concretely

A qualification dossier or compliance audit on an AI system requires evidence — not declarations. Here is what Lexiane makes available:

Delimited and verifiable certified perimeter The certified kernel is an autonomous compilation module (vectrant-core), with no vendor dependencies, whose security properties are enforced by the compiler. Its boundary is the list of its 25 abstraction interfaces. It is precise, stable, and inspectable.

Exportable SHA-256 audit trail Every pipeline action is recorded in a cryptographic chain whose integrity is mathematically verifiable. The register is exportable and consultable independently of the production system.

Automated test suite in continuous integration 1,254 tests run continuously. No test is disabled for convenience — the 39 ignored tests are explicitly so because they require external infrastructure (Qdrant instance, API key, downloaded model), and this disabling is documented. The distinction between unit tests, integration tests, and tests requiring infrastructure is explicit in the project structure.

Static pipeline configuration validation at assembly Pipeline configuration errors are detected at assembly, before execution. A misconfigured pipeline cannot start. This property reduces the surface of undefined behavior in production.

SOUP isolation documentation The 25 abstraction interfaces constitute the complete list of contact points between the certified kernel and third-party components. Each interface is documented, typed, and tested. All external dependencies are adapters implementing these interfaces — their SOUP status is delimited by architecture.

---

Frequently asked questions from compliance officers

Our framework requires compiler qualification. Is Rust/Ferrocene recognized? Ferrocene is qualified ISO 26262 ASIL D and IEC 61508 SIL 4. IEC 62304 qualification is under development to accompany the standard revision. For other frameworks, Ferrous Systems provides evidence packages that enable engaging dialogue with your certification body.

We must document all SOUP components. How does Lexiane facilitate this? Lexiane’s hexagonal architecture delimits SOUP by design: every external component implements a typed abstraction interface. The list of interfaces is the complete list of SOUP boundaries. Transitive dependencies of each adapter are isolated in their own compilation module, with no access to the certified kernel.

Our auditor wants to inspect the system code. How do we access it? Lexiane is distributed under the Apache 2.0 license — the source code is fully available and inspectable. There is no closed component, no opaque binary module, no functionality whose behavior cannot be verified in the code.

We must demonstrate that personal data does not leave our perimeter. How do we provide proof? In air-gapped configuration, Lexiane has no active network interface toward the outside. The proof is not contractual — it is architectural. An auditor can verify, by inspection of the binary and its configuration, that no outbound network call is possible. This is a fundamentally different property from a vendor confidentiality commitment.

We are considering certification in 18 months. Where do we start? Anticipation is precisely what Lexiane enables. Its design for certification means that the required properties are present from deployment — they do not have to be added retrospectively. We offer an exchange on your target framework, your scope, and the stages of your qualification process.

---

Start the conversation about your regulatory context.

Every certification framework poses its own requirements. Every sector has its own reading of AI compliance. We do not offer generic responses.

We offer an exchange with someone who knows the constraints of regulated environments, the challenges of software certification, and what Lexiane’s architecture concretely enables in your context.

What you can expect from this exchange:

• A response within 48 business hours
• A technical contact who knows IEC 62304, ISO 26262, DORA, and GDPR in their relationship to AI
• An honest assessment of the fit between Lexiane and your certification requirements — including if additional developments are necessary

→ Contact us