Wafer inspection images contain more than defect data. They encode process fingerprints: the exact etch profile, the metal fill pattern, the overlay registration quality, the characteristic defect signature of every piece of equipment in the process flow. A high-quality inspection image from a 7nm production wafer, analyzed by a knowledgeable process engineer, reveals information about the process recipe, the tool set, and the product design that took years and hundreds of millions of dollars to develop.
This is why the question of where inspection software runs — cloud, on-premises, or hybrid — is not primarily a cost optimization question. It is an IP protection question, and for most fabs it has a clear answer: inspection image data does not leave the fab perimeter without explicit legal framework and technical controls.
What the Data Actually Contains
To understand the IP risk, it helps to be specific about what inspection datasets contain. A typical production inspection step generates per-wafer image tiles (individual field-of-view captures), composite wafer maps, defect coordinate lists, and classification metadata. The per-wafer image tiles, at typical brightfield resolutions of 0.2–0.5 µm/pixel, contain high-fidelity representations of the surface topology and optical characteristics of every layer inspected.
For a fab running a proprietary device structure — a custom SRAM cell, a novel gate stack, a unique BEOL interconnect scheme — those images contain the geometric signature of the proprietary structure at a level of detail that design database protection alone does not address. The GDS files are protected; the optical images of the fabricated device are often treated as operational data rather than IP, and end up with weaker protection controls.
A historical precedent: certain export control regimes applicable to semiconductor manufacturing equipment classify inspection image data from advanced-node production as controlled technical data because of what it reveals about manufacturing process capability. This is not hypothetical regulation — it is an established compliance consideration for fabs operating in export-controlled environments.
The Cloud Deployment Risk Model
The argument for cloud deployment of inspection software is familiar from other domains: lower infrastructure cost, elastic compute for inference workloads, faster model updates. These are real advantages. The risk argument is equally real.
Cloud deployment of inspection software means that wafer image data transits a network to an external service and is processed on infrastructure not under fab control. The risk surface includes: data in transit (mitigated by TLS, but not eliminated), data at rest in cloud storage (governed by the vendor's data handling agreement, not fab IT policy), model training pipelines that might ingest fab data as training examples, and vendor access for support and debugging that creates a legal pathway for data disclosure.
We are not arguing that cloud infrastructure is inherently insecure — cloud providers maintain extensive security certifications and controls. The issue is not the absolute security level but the control model. A fab CISO can define and enforce data handling policy for on-premises infrastructure. Enforcing equivalent policy for cloud-processed data requires contractual controls, audit rights, and a level of vendor diligence that most SaaS inspection products are not designed to accommodate.
For fabs with contractual obligations to their customers regarding process data confidentiality — a common term in fab services agreements — cloud processing of inspection images may require explicit customer consent that is practically impossible to obtain at production scale.
On-Premises Architecture Requirements
On-premises deployment of inspection software has its own complexity. The compute requirements for running real-time inference on inspection image streams at production throughput are non-trivial. A 300mm fab running 30 wafers per hour through an inspection step, at full-field image capture with tile sizes in the range of 2,000 × 2,000 pixels, generates image data at rates in the hundreds of megabytes per minute. Classification inference on that stream requires dedicated GPU compute or high-performance CPU clusters co-located with the inspection tool.
This compute infrastructure needs to be planned as part of the inspection tool procurement, not treated as an afterthought. A common failure mode: inspection software is procured assuming the existing fab IT server infrastructure can handle the inference workload, only to discover during commissioning that the servers are CPU-only and the inference latency is 10× the required production throughput rate. GPU co-location with the inspection tool workstation is the typical resolution, which adds a hardware procurement item that was not in the original project budget.
Network architecture also matters. On-premises does not mean air-gapped — inspection software typically needs to communicate with the MES for recipe management and results reporting, with the yield management system for defect data, and with centralized model management for classifier updates. The network segmentation design should isolate inspection image data from any path that could reach external networks, while still permitting the legitimate internal communications that make the system useful.
Hybrid Deployment: Where It Makes Sense
A hybrid model — on-premises inference for production wafer processing, cloud-based for model training and development — can capture some cloud benefits while maintaining production data protection. In this architecture, production wafer images never leave the fab. Synthetic training data (generated by the fab's process simulation tooling) and anonymized aggregate statistics (defect count distributions, not image content) can flow to cloud-based model development infrastructure without IP risk.
The line between what is safe to process externally and what is not requires legal review specific to the fab's customer contracts, export control obligations, and internal IP classification policy. The technical architecture should be designed to enforce that line mechanically — not just rely on policy compliance — by structuring data flows so that image-level data physically cannot route to external endpoints.
Practical Checklist for Deployment Architecture Review
When evaluating inspection software deployment architecture, the questions that matter most for IP protection:
- Where does inference run, and what data leaves the fab perimeter to make it run?
- Does the vendor's support process require access to production image data, and if so, what is the legal framework governing that access?
- Is the model training pipeline designed to ingest production image data, and does the vendor's terms of service include any data usage rights that extend beyond service delivery?
- What is the data retention policy for any image data processed in or transmitted to vendor infrastructure?
- Does the deployment architecture pass review under the fab's applicable export control obligations?
On-premises deployment answers most of these questions favorably by design. Cloud or SaaS deployments need to answer them explicitly through contract and architecture review. The question is not cloud versus on-premises as a matter of preference — it is which architecture gives the fab's legal and security teams the control they need to fulfill obligations to customers and regulators. For most production inspection applications handling advanced-node wafer data, that architecture is on-premises.