Can Automotive Suppliers Use AI on OEM Design Data While Keeping TISAX Prototype Protection?

Yes, automotive suppliers can use AI on OEM design and prototype data and keep TISAX prototype protection, but only when the AI runs inside the supplier's own protected zone and the data never leaves it. Public cloud AI services break that condition, because uploading computer-aided design files or prototype specifications to a third party is exactly the uncontrolled sharing that prototype protection forbids. The compliant pattern is local inference on operator-owned hardware, where the model reads the data in place and nothing is transmitted outward. Keeping the compute inside the perimeter is what preserves the protection.

This matters in 2026 because the pressure to apply AI to engineering data is constant, and the easiest route is also the non-compliant one. A supplier that pastes a tolerance stack, a wiring harness diagram or an unreleased body-in-white geometry into a hosted assistant has already lost control of that data. The question is no longer whether suppliers want AI on this data, but whether they can prove it stayed put.

Why does cloud AI break TISAX prototype protection?

TISAX prototype protection, defined in the VDA Information Security Assessment, treats pre-series design data, prototype parts and test vehicles as high protection need information. The controls require restricted access, documented handling and a prohibition on sharing that information outside authorised parties. A public cloud AI service is, by definition, an outside party. When design data is sent to it for inference, it crosses the boundary of the protected zone and enters infrastructure the supplier does not control, where retention terms, sub-processors and the storage location are set by the provider. No data processing agreement changes where the bytes physically travel.

How does on-premises AI keep the data inside the protected zone?

The correct architecture inverts the flow: instead of sending design data out to a model, the model is brought to the data and runs on hardware the supplier owns. Mickai is a Sovereign Intelligence Operating System, a SIOS, built for exactly this. It runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so requests and data can enter the protected zone but nothing leaves it. Sovereign models perform inference locally, so the OEM's design and prototype data is read in place and never transmitted to any external service. There is no cloud endpoint and no outbound connection, because the compute happens where the data already sits.

What can a TISAX auditor actually check?

An auditor should be able to verify the claim, not just read a policy that asserts it. Every action inside the SIOS is cryptographically sealed into an append-only ledger, signed using the post-quantum digital signature standards FIPS 204 (ML-DSA) as the primary scheme, with FIPS 205 (SLH-DSA) available alongside it. Identity is hardware-attested and bound to the same chain, so the record shows which attested machine performed which action on which file. An assessor can confirm three things from the evidence: that inference ran locally, that no egress path existed, and that the log has not been altered since it was written.

“Prototype protection is not preserved by a promise that data stays inside the perimeter, but by an architecture in which it never had a way out.”

Which rules make this necessary?

TISAX prototype protection is the immediate driver, but it does not sit alone. GDPR governs any personal data caught up in engineering records. The US CLOUD Act lets US authorities compel US-headquartered providers to disclose data regardless of where it is stored, a direct concern for European suppliers using American cloud AI. DORA has been in force since 17 January 2025 for financial entities and their critical ICT providers, and NIS2 raises security duties for essential and important entities across the supply chain. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 frames AI governance in a way that maps cleanly onto an offline, auditable deployment.

How does a supplier prove the data never left?

Because the audit ledger is signed with post-quantum signatures and anchored to hardware-attested identity, its integrity can be checked without trusting any external server and without a live connection. The absence of an egress path is a tested property of the perimeter, not a setting that could be quietly changed. For higher-assurance decisions, cross-model consensus runs several sovereign models over the same input inside the zone and records their agreement, so a single model's error does not pass unchecked. The supplier can hand an OEM or an assessor a sealed record showing, action by action, that the design data was processed locally and never transmitted.

What can suppliers actually do with AI on this data?

The scope is wide once the data stays inside. Suppliers can summarise and cross-reference OEM specifications, check drawings against tolerance and material requirements, search historical programme documents, draft engineering change notes, and interrogate prototype test results in natural language. Because the model is local, none of this depends on an internet connection, and every query is logged and sealed. The underlying methods sit within a body of 104 filed UK patent applications covering approximately 2,340 claims, owned by Mickai LTD, and are patent pending.

Frequently asked questions

Does signing a DPA with a cloud AI provider satisfy TISAX prototype protection?

No. A data processing agreement sets contractual terms, but prototype protection is about controlling where high protection need data physically goes. A DPA does not stop the data leaving your protected zone, does not remove the provider's sub-processors, and does not override the US CLOUD Act. The compliant answer is to keep inference on hardware you own so the data never leaves in the first place.

Can suppliers use a private cloud tenant instead of on-premises hardware?

A private tenant still runs on infrastructure the supplier does not physically control, and data still transits to and is processed by the provider. For prototype protection, the safer position is local inference inside the assessed site, where you can demonstrate a zero-egress perimeter and produce an offline-verifiable log. If a hosted option is unavoidable, it needs to be evidenced against the same standard, which cloud AI services generally cannot meet.

How do we prove to an OEM that our AI use is compliant?

Demonstrate that inference runs on operator-owned hardware behind an inbound-only perimeter, and provide the cryptographically sealed audit ledger, signed with FIPS 204 and bound to hardware-attested identity, that records each action offline. An OEM or TISAX assessor can then verify locally that design data was processed inside the zone and never transmitted.

Is the EU AI Act deadline of 2 August 2026 still the one to plan around?

No. The Digital Omnibus deferred the high-risk Annex III obligations that were due on 2 August 2026 to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We treat this as extra time to build an auditable, offline foundation rather than a reason to delay, because TISAX, GDPR, DORA and NIS2 duties already apply now.

What is the difference between this and a normal on-premises server running a chatbot?

The difference is verifiability and the perimeter. A generic on-premises deployment can still open outbound connections and rarely produces evidence an auditor can trust. A SIOS runs offline behind a tested zero-egress inbound perimeter, binds every action to hardware-attested identity, and seals the audit ledger with post-quantum signatures so its integrity can be checked without any network. It is designed to be proven, not just asserted.