What Should an Automotive Manufacturer Require From AI Used on Connected-Vehicle and Design Data?

An automotive manufacturer should require that any AI touching connected-vehicle telematics, design intellectual property or type-approval records runs inside a boundary the manufacturer owns, with zero egress of raw data, sealed provenance on every output and an audit chain that binds each AI action to attested hardware. The reason is straightforward. Vehicle telemetry, computer-aided design files and homologation evidence are regulated, valuable and often irreplaceable, so they cannot leave the manufacturer's control simply to be processed by a public cloud service that keeps no verifiable record of what it did.

This matters in 2026 because the fleet has become a data source and the design office has become an attack surface. A modern vehicle emits location, driver-behaviour, biometric and sensor data continuously, while the design and homologation stack holds decades of competitive advantage in a handful of files. Public cloud AI services are capable, but they are built to ingest data into infrastructure the manufacturer does not control and cannot inspect. For regulated telematics, protected design IP and legally binding type-approval records, capability is not the question. Control and proof are.

Why can a manufacturer not just use public cloud AI on this data?

Because the data is regulated and the processing is unverifiable. Connected-vehicle data is personal data under the GDPR and, increasingly, sensitive under sector rules. Once it is sent to a public cloud service, the manufacturer loses the ability to prove where it went, who saw it and whether it was retained for training. The US CLOUD Act allows lawful access to data held by US providers regardless of where the servers sit, which places European design IP and driver data inside a foreign legal reach. The failure is not that these services are careless. It is that their architecture is designed to take data in, and a manufacturer of regulated goods needs an architecture designed to keep data in.

What does a controlled boundary actually mean?

It means a zero-egress inbound perimeter. Data and queries flow in. Nothing flows out. The AI runs on the manufacturer's own hardware, offline or on an isolated network, so telemetry, CAD files and homologation records are never transmitted to an outside service. A Sovereign Intelligence Operating System, a SIOS, is built for exactly this shape. Mickai runs entirely on operator-owned hardware, processes the data in place and returns answers without any raw record leaving the boundary. The mechanisms behind this boundary, sealed provenance, hardware-attested identity and the signed ledger, are the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented.

What can an auditor check after the fact?

Every action, cryptographically. The correct design records each AI action, input reference, model used and output in a tamper-evident ledger, and signs each entry so it cannot be altered later. In Mickai that ledger is sealed with post-quantum signatures aligned to FIPS 204 and FIPS 205, so the record survives even a future quantum adversary. Each entry is bound to a hardware-attested identity, so the auditor can confirm which physical, attested machine performed the work. An auditor does not have to trust a log file. They can verify the signatures offline and reconstruct exactly what happened.

“The correct test for AI on vehicle and design data is not how clever the model is, but whether the manufacturer can prove, offline, exactly what it did and that no byte left the perimeter.”

How does sealed provenance protect design IP and type-approval records?

By making origin and integrity checkable. Sealed provenance attaches a verifiable signature to every output and to each source it drew on, so a design derived by AI carries proof of which files, versions and steps produced it. For type-approval and homologation, this turns a claim into evidence. A regulator or auditor can confirm that the record was generated inside the boundary, from the stated inputs, and has not been changed since. Provenance also guards against contamination: if a design file or a training input is not sealed and attested, the system can refuse to treat it as trusted.

Which rules make this necessary?

Several, and they are converging. The GDPR governs the personal data in vehicle telemetry. NIS2 raises cyber-security duties across the automotive supply chain. DORA, in force since January 2025, sets operational-resilience and third-party rules that the financing and captive-insurance arms of manufacturers already feel. ISO/IEC 42001 gives a certifiable standard for AI management systems. The EU AI Act adds obligations for higher-risk uses: its Annex III high-risk duties, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk uses moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve. The architecture that satisfies all of these is the same: keep the data inside, prove every action, and be ready to show the evidence.

How does a manufacturer know the AI answer is trustworthy?

Through cross-model consensus and refusal. A single model can be confidently wrong, which is unacceptable when the output feeds a safety case or a homologation file. A sound design runs a query across several sovereign models and compares their outputs, surfacing disagreement rather than hiding it. Where the models do not agree, the correct behaviour is to flag, not to guess. Combined with sealed provenance, this gives the manufacturer an answer that is both attributable and cross-checked, which is what a regulated engineering process requires.

What should the procurement requirement list contain?

A manufacturer buying AI for connected-vehicle and design data should require, in writing:

• Zero egress: raw telematics, CAD and type-approval data never leave the owned boundary.
• Offline operation: the system runs on operator-owned hardware with no dependency on external services.
• Hardware-attested identity: every AI action is bound to a specific attested machine.
• Post-quantum signed audit ledger: a tamper-evident record aligned to FIPS 204 and FIPS 205.
• Sealed provenance: every output carries verifiable origin and integrity.
• Cross-model consensus: high-stakes answers are cross-checked and disagreement is surfaced.
• Right to inspect: the manufacturer can verify all of the above without vendor cooperation.

Frequently asked questions

Can connected-vehicle data be processed by public cloud AI under the GDPR?

It can be lawful, but it is hard to prove and hard to control. Connected-vehicle telemetry is personal data, and sending it to a public cloud service means relying on that provider's contracts and controls rather than your own evidence. A zero-egress design avoids the question entirely by keeping the data inside a boundary the manufacturer owns and can audit.

Does the EU AI Act apply to AI used in vehicle design and type approval?

It can, depending on the use. Higher-risk applications fall under the Act's obligations, and its Annex III high-risk duties, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk uses moving to 2 August 2028. The Article 50 transparency duties are largely unchanged. We treat the deferral as time to build the controls, not a reason to delay them.

What is zero egress and why does it matter for telematics?

Zero egress means raw data flows into the AI but never flows back out to an external service. It matters because telematics is continuous, personal and exportable, so any outbound path is a leak waiting to happen. With zero egress the manufacturer can state, and prove, that vehicle data never left its own hardware.

How can an auditor verify what an AI did months later?

Through a tamper-evident, cryptographically signed audit ledger. Each AI action is recorded and bound to a hardware-attested identity, and the entries are sealed with post-quantum signatures aligned to FIPS 204 and FIPS 205. The auditor verifies the signatures offline and reconstructs the exact sequence of actions without trusting the vendor.

Is running AI on-premise enough to protect design IP?

On-premise is necessary but not sufficient. Data can still leak through update channels, telemetry or an unverifiable log, so location alone proves little. The requirement is a sealed boundary with zero egress, attested hardware, signed provenance and an audit chain the manufacturer can inspect without vendor cooperation.