Embedded AI contracts are not standard software agreements, and standard contracts will not protect you adequately. If you are building or selling an embedded AI solution, the layered nature of your product creates a layered set of legal obligations. Get the contract structure wrong and you expose yourself to uncapped liability, unenforceable IP claims, export control violations, and customers who can walk away with your trade secrets.
This article breaks down what a well-structured embedded AI contract looks like, layer by layer.
Why Embedded AI Requires a Mixed Contract Structure
Most embedded AI offerings combine at least three layers: a physical hardware component, one or more software components, and a model and data layer. Many add a fourth: ongoing services such as support, maintenance, or consulting.
Each layer is treated differently under the law:
- Hardware is governed by sales or leasing rules (or hardware-as-a-service arrangements)
- Software is typically licensed, though firmware on a purchased device may be sold outright
- Models and data are neither pure software nor goods. They are information and weights, often containing sensitive customer data or provider trade secrets
- Services are governed by service or mandate agreements
A single set of general terms cannot adequately cover all four. Embedded AI contracts therefore require a mixed contract structure that reflects the actual business model: one document or a coordinated set of documents addressing each layer on its own terms.
The most common mistake we see in practice: the service provider accepts the customer’s standard purchase terms. Corporate customers often push their own general terms, which are drafted for procurement of goods and not for complex AI service relationships. Accepting them without review creates gaps, misallocates risk, and may waive protections you did not even know you had. Always review and negotiate.
Hardware: Logistics, Maintenance, and Supply Chain Obligations
For the physical layer, contracts must address what happens before, during, and long after delivery.
At the point of shipment, clarify responsibility for customs clearance, import duties, logistics delays, and damaged goods. The standard tool here is Incoterms, the internationally recognised framework that defines who bears transport costs, insurance obligations, and the transfer of risk at each stage of a shipment. The differences between Incoterms variants are significant in practice. Choose the right one for your logistics model and make sure your team understands what it commits you to.
Upon delivery, inspection duties and defect notice obligations become relevant. Customers typically have a defined window to inspect goods and raise defects. Miss that window and claims may be forfeited, or conversely, you may be left holding liability for issues the customer failed to flag in time.
Over the long term, hardware providers face obligations that are easy to underestimate: component substitutions, end-of-life part supply, and supplier changes. If you have a contractual obligation to provide spare parts for ten years, you need to verify that your supply chain can actually deliver on that promise. Flow hardware obligations down to your contract manufacturers and suppliers of critical components. Do not accept customer-facing obligations you cannot enforce further up the chain.
Software, Models, and Data: IP, Open Source, Privacy, and the EU Data Act
The software and data layers introduce a different category of risk: intellectual property, open source licence compliance, and data regulation.
On IP, be precise about who owns what. Clarify rights to data inputs and outputs. As a service provider, you should ensure you can reuse aggregated, anonymised, and annotated datasets to improve your offering across customers, without inadvertently granting customers ownership of improvements derived from their data.
On open source, embedded AI systems frequently incorporate open source components at the firmware, software, and model layers. Each open source licence carries its own obligations. GPL and LGPL licences, for example, may require you to disclose source code under certain distribution scenarios — an obligation that can conflict with your IP protection strategy if not managed proactively. Maintain a software bill of materials (SBOM) for your product, understand the licence terms of every component, and ensure your contracts with customers and suppliers allocate open source compliance obligations clearly.
On software obligations, define support boundaries, reaction times, and service levels clearly. For firmware in particular, think carefully about end-of-life rules: are you obliged to continue supporting old hardware versions? If updates and maintenance are not delivered over-the-air, you will also need a contractual right of access to devices located on customer premises. Additionally, the EU Cyber Resilience Act (Regulation (EU) 2024/2847) introduces mandatory security update and patch obligations for products with digital elements — including firmware on connected devices. The CRA entered into force in December 2024. Incident reporting obligations apply from September 2026, and full compliance is required by December 2027. If you are selling connected embedded AI systems into the EU market, you should be designing for CRA compliance now.
On data regulation, two instruments are essential for any embedded AI contract with an EU dimension:
- Data Processing Agreement (DPA): Required whenever your embedded system processes personal data on behalf of a customer. The DPA governs sub-processor changes (sub-processors are the third-party vendors your platform relies on to process data), audit rights, and data security obligations. A poorly drafted DPA can give customers a veto over your sub-processor stack, locking you into infrastructure choices long after they made commercial sense.
- EU Data Act addendum: The EU Data Act (Regulation (EU) 2023/2854) imposes data access and portability obligations on providers of connected products and data processing services, with provisions applicable from September 2025. For the cloud and SaaS components of your embedded AI offering, Article 25 of the Data Act requires that customers can initiate a switch to another provider on no more than two months’ notice. For the connected product components, the Data Act grants users rights to access and port the data generated by their devices. Within both sets of obligations, there is a trade secret carve-out that can be used to limit exposure of aggregated datasets and model weights — but this protection must be actively designed into your contracts. A contractual addendum addressing your obligations under the EU Data Act should be part of every commercial agreement with an EU customer.
Key Red Lines for Every Embedded AI Contract
Beyond the layer-specific issues, four red lines apply to virtually every embedded AI contract.
Right to modify your services. You must retain the right to exchange hardware, update software features, and change sub-processors without requiring individual customer consent for each change. A single customer should not be able to veto a security patch or a necessary infrastructure migration. Build modification rights in from the start.
Liability caps. Under Swiss law, liability is uncapped by default. For embedded AI service providers, this creates an existential risk: a single incident could expose you to damages far exceeding the contract value. Standard practice is to cap liability at 1x the annual contract value. Equally important is excluding liability for issues outside your control, specifically the customer’s own IT environment, integrations with third-party software you do not control, and use of the device for unsupported use cases.
Governing law and jurisdiction. For contracts sold across borders the choice of governing law and dispute resolution forum is a material commercial decision. Agree on governing law and jurisdiction explicitly, and verify enforceability in the customer’s home jurisdiction before signing.
Export control classification. Many embedded AI systems, or components within them, qualify as dual-use goods: products, software, or technology that can be used for both civil and military purposes. Dual-use goods are subject to export control regulations in Switzerland, the EU, and the US. Switzerland updated its rules in 2025 to bring AI and semiconductor technologies explicitly under dual-use export controls. Swiss-based embedded AI providers should verify whether their products now require an export licence under the revised control lists. Before any cross-border transfer or sale, classify your embedded system against the applicable dual-use control lists. Exercise particular caution when delivering to the United States, the Middle East, or Ukraine, where additional licensing requirements or restrictions may apply. Export control compliance is not optional, and getting it wrong carries serious legal consequences.
Interested in EU regulatory compliance for robotics and embedded AI?
Once the contracts are in place, the next question is regulatory compliance. Session 3 of our webinar series covers how GDPR, the AI Act, the Data Act, and the Cyber Resilience Act apply in practice to robotics, autonomous systems, and connected devices.
Join our session on Thursday, 11 June, 13:00 to 13:45 CEST. : Sessions 3/3: Designing AI Products for the EU Market: Regulatory Compliance from Day One · Luma
What to Do Next
Embedded AI contracts are not a one-size-fits-all exercise. The right structure depends on your hardware model, your software delivery architecture, how you handle customer data, and where you sell.
If you are building or scaling an embedded AI product, the time to get the contract structure right is before you sign your first major customer, not after a dispute has already started.
Schedule a consultation with LEXR to review your embedded AI contracts and make sure your legal structure matches the product you are actually selling.
