Sourcing and Procurement
The acquisition of the required technologies and resources is probably one of the most critical parts of most AIoT projects. Many project leaders -- and many procurement departments -- do not have much experience in this space, which is why this part of the book aims to provide a structured approach to the problem (in combination with a set of useful templates).
The approach described here covers typical sourcing challenges, introduces a generalized sourcing process for AIoT products/solutions, discusses make vs. buy vs. partner, introduces the concept of an AIoT Sourcing BOM, helps define vendor selection criteria, covers RFP document creation and management, and finally looks at vendor selection.
- 1 Challenges
- 2 AIoT Sourcing Process
- 3 AIoT Sourcing Strategy
- 3.1 Strategic Options: Make vs. Buy vs. Partner
- 3.2 The AIoT Bill of Materials
- 3.3 Example: ACME Smart Shuttle
- 3.4 Creating the AIoT BOM
- 3.5 Make vs. Buy Breakdown
- 3.6 ACME Smart Shuttle: Outsourcing AI?
- 3.7 AIoT Sourcing BOM
- 3.8 Schedule Alignment
- 4 General Considerations
- 5 RFP Management
- 6 Legal Perspective
- 7 Authors and Contributors
Before looking at the details of the sourcing strategy and process, we must first understand the challenges associated with AIoT sourcing and procurement. An AIoT project is often a complex undertaking. On the business side, many different stakeholders must be aligned, contradicting requirements must often be managed, and existing business processes will have to be re-engineered. On the technology side, a multitude of new technologies and methodologies must be made to work together. In the case of a line-fit solution, existing or new manufacturing capabilities must be aligned with the needs of the AIoT solution. Finally, the solution roll-out and service operations must be prepared and managed.
So what can go wrong? A lot, especially if project management does not pay close attention to the digital supply chain. Selecting the wrong vendor or the wrong technology for all or parts of an AIoT solution can have ripple effects that put the entire project in danger.
The same applies to over-specifying or underspecifying what is needed. Poor implementation services or badly defined SLAs (Service Level Agreements) can lead to bad user experience and stability problems. If these problems are only determined after the roll-out, this can put the entire business at danger. The list of sourcing-related challenges also includes issues with adapting to change, allowing poor quality for lower costs, ignoring the costs of time, ill-defined sourcing and procurement processes with unclear responsibilities, project management issues, complex organizational dependencies, and loopholes in contracts.
Especially for industrial companies, dealing with AIoT-related topics from a sourcing point of view can be challenging:
- How can agile development be supported with a matching pricing model and contracts?
- How can we deal with new paradigms such as AI and the required SLAs?
- Can AI-based solutions be treated like software-based solutions from a sourcing point of view, or do they need a different approach?
- How can dependencies between different suppliers be managed, e.g., for hardware and software?
- How can vendor lock-in be avoided due to 'accidental' technical dependencies?
RFPs (Request for Proposals) play an important role in many sourcing projects. Depending on the chosen sourcing strategy, a number of different RPFs will be required, especially if different technologies and resources will be acquired from different suppliers. One should not underestimate how unpredictable and difficult to manage RFP projects can be and how often they miss their deadlines. Carefully aligning the required RFP projects with your development plans will be a key success criterion for your project. One aspect here simply is the timelines for running the RFP and securing suitable vendors. Especially in larger enterprises, another aspect is the complexities of sourcing decisions in complex political environments.
AIoT Sourcing Process
The first important step towards successful technology and resource acquisition is to define a high-level process, which needs to be aligned with all key stakeholders: AIoT project team, procurement, legal, and often senior management. The process proposed here is based on the assumption that it will be centered around a Request for Proposal (RFP), and has five main elements: sourcing strategy and planning, RFI (optional), RFP creation, RFP distribution, and AIoT vendor selection.
Procurement strategy and planning need to look at the most important aspects of the AIoT solution (including stakeholders, scope, and requirements), as well as the implementation project (timeline, key milestones, and budget). As part of the sourcing strategy, the make vs. buy question must be addressed. Depending on the outcome of this decision, the creation of a specialized Sourcing BOM (a breakdown of all required elements of the solution) should be considered. Furthermore, vendor profiles, sourcing criteria, and the actual sourcing process (including timelines) should be defined.
During the RFP creation phase, a concise RFP document must be created, reviewed with all internal stakeholders, and often formally approved.
After completion of the RFP document, it will be distributed to the target vendors. In some cases, it will also be made publicly available. Managing the RFP process will usually involve a structured Q&A process with all interested suppliers.
Finally, the vendor responses must be evaluated. Often, vendors are invited for individual vendor presentations. Based on this information, a first set of vendors can be preselected. In some cases, smaller Proof-of-Concept projects are done with these vendors. Based on the outcomes of the PoCs, a short-list can be created. Often, the last few vendors are then asked to do a more extensive pilot project. Based on the technical and functional evaluation, as well as extensive price negotiations, the final selection is then done.
AIoT Sourcing Strategy
Defining the sourcing strategy is an important first step. This section will cover strategic sourcing options (make vs. buy. vs partner), the AIoT Bill of Materials, the AIoT Sourcing BOM, and finally the alignment with the development schedule.
Strategic Options: Make vs. Buy vs. Partner
The decision for a specific sourcing strategy is fundamental and will shape your AIoT-enabled business for the years to come. Giving up too much control over the production process for a strategic product can be as problematic as investing too many own resources in the development of commodity technologies and failing to build truly differentiating features on top.
So what are the options? For the purpose of our discussion, we have identified three strategic sourcing options:
- Internal Development: This option basically assumes that only commodity technology such as middleware or standard hardware components will be externally sourced, but all custom development (including software and hardware) will be done internally.
- Acquire & Integrate: This option assumes that only the high-level design and component integration will be done internally, while all subcomponents (hardware, software) will be acquired from external sources.
- Turnkey Solution: This option assumes that an external provider will be selected to provide a complete solution or product, based on the requirements defined by the ordering organization. This can either be a complete custom development, or the customization of a standard solution/Commercial-Off-the-Shelf product. Typically, in this case, the supplier is responsible not only for the implementation, but also for the design.
These three options are only examples. Other options, such as co-innovation or Build-Operate-Transfer, can also be interesting. However, these three examples should provide a good starting point for the discussion in the following.
So how to decide for the right sourcing option? One key factor is the strategic relevance of the AIoT-based product or solution. An auxiliary system with little direct impact on the business could probably best be acquired as a turnkey solution. A strategic product that will be responsible for a large part of future revenue will most likely require much more control over the product's design and value chain, and thus lend itself to the custom development option. The same could hold true for an AIoT solution that controls parts of an enterprise's core processes.
Other factors that must be taken into consideration include the following:
- Organizational capabilities: Does your organization have a proven track record in hardware and/or software development? And how about AI and Data Science?
- Resource availability: Do you have the required resources available for the required time period? And is it the best use of these resources?
- Could you build it fast enough?
- Could you build it good enough?
- Need for control: How much control does your organization need over the design and value chain?
- Would building it internally allow cost reduction (e.g., by utilizing own manufacturing lines)?
- Do you want to keep building/maintaining it yourself after the launch/SOP?
- How mature is the supplier market?
- Is there an opportunity for a strategic partnership here?
- Is a well-known supplier brand a potential differentiator?
In many cases, the Make/Buy/Partner question cannot be answered for the entire product or solution but needs to be broken down to different components (see discussion on the Sourcing BOM below). To answer the Make/Buy/Partner question for a complex AIoT solution, it is often important to first understand the complete breakdown of the solution. This is examined in the discussion of the AIoT Sourcing BOM below.
The AIoT Bill of Materials
In manufacturing, the bill of materials (BOM) is used for planning the purchasing of materials, cost estimation, and inventory management. A BOM is a list of every item required to build a product, including raw materials, subassemblies, intermediate assemblies, subcomponents, and parts. It usually also includes information about the required quantities of every item.
There are usually different, specialized BOM-types, including:
- Engineering BOM: developed during the product design phase, often based on Computer-Aided Design (CAD) data. Lists the parts and assemblies in the product as designed by the engineering team
- Manufacturing BOM: includes all the parts and assemblies required to build the finished product. Used as input for the business systems involved in ordering parts and building the product, e.g. ERP (Enterprise Resource Planning), MRP (Materials Resource Planning), MES (Manufacturing Execution System)
- Sales BOM: used during the sales phase, provides details of a finished product prior to its assembly
Given the potential complexity of an AIoT project, we propose the creation of a Sourcing BOM as the foundation for the sourcing process. In the following, we start with a discussion of a generic AIoT BOM, followed by the introduction of the Sourcing BOM.
Example: ACME Smart Shuttle
To provide a meaningful discussion of the BOM concept for an AIoT product, we use the ACME Smart Shuttle example. ACME Smart Shuttle Inc. is a fictitious company offering a platform to manage shuttle services for schools. Instead of using a fixed bus network and fixed bus schedule, ACME Shuttle utilize AIoT to offer much more on-demand service to students. Instead of using fixed bus stops, virtual bus stops are introduced that can change during the day, depending on demand. Students are using a smartphone app to request a ride to and from the school. These requests are then matched against the virtual bus stop system, potentially resulting in the ad-hoc creation of new, virtual bus stops. Shuttle buses are equipped with an on-board unit to provide bus tracking and AI-based in-vehicle monitoring. The platform in the backend utilizes AI to optimize the pick-up order and routing of the shuttle buses. The figure following shows the key elements and stakeholders of the ACME Smart Shuttle system.
To return to the BOM discussion, the starting point for the creation of a basic BOM structure for an AIoT product or solution is usually an analysis of the architecture design. The figure below shows an example of the high-level architecture design of the ACME Smart Shuttle solution. Additionally, listed are examples of resources required for implementing key elements of the system.
Creating the AIoT BOM
A BOM is typically a hierarchical structure; in our case, the 3-5 high-level areas of the solution architecture should form the first hierarchy level of the BOM. Note that this BOM will include not only hardware, but also software elements, as well as network infrastructure. In reality, the BOM for such a project might be comprised of multiple, specialized BOMs. The example below indicates how a high-level architecture design -- such as the one for the ACME Smart Shuttle example from before -- can be mapped to the initial BOM.
Thinking about required resources in terms of a BOM will be unusual for people from the software world. However, the benefit of including not only hardware and physical elements in the BOM structure but also software and virtual elements is that the BOM provides a holistic view of the entire system. This can be used not only for the Sourcing BOM but also from the point of view of dependency management, tracing of BOM elements from a security point of view, etc.
Make vs. Buy Breakdown
For most AIoT systems, the make vs. buy (vs. partner) decision cannot be applied to the entire system. Instead, it must be applied to different entries in the AIoT BOM. The figure below shows four different scenarios:
- Scenario A is a manufacturer working on a strategic new core AIoT product. In this case, most BOM items will be custom made internally. Only some items such as Edge Platform, WAN, cloud infrastructure and EAI middleware, will be sourced externally.
- Scenario B is a manufacturer working on a time-to-market driven project. In this case, only hardware-centric BOM items will be sourced internally.
- Scenario C is a software company that takes nearly the inverse position to scenario B.
- Finally, scenario D assumes an auxiliary AIoT system, which will be sourced as a turnkey solution. Only the preparation of existing applications for integration with the new system will be done internally.
ACME Smart Shuttle: Outsourcing AI?
ACME Smart Shuttle, Inc. sees AI as a key enabler to build highly differentiated product features with a strong customer appeal. Consequently, the team has performed an assessment of the best uses of AI in the system design. The most promising AI use cases have been discussed with the procurement team as part of the BOM creation. A summary of the make vs. buy vs. partner decisions that have been made is summarized in the table below.
Three AI-enabled components have been identified as particularly important to the system: Shuttle routing, shuttle ETA forecasting and driver shift planning. Ideally, these three components should be developed in-house to retain full control and ensure constant optimization. However, the analysis has shown that the engineering management team has no experience hiring and managing a team with the required AI skills; furthermore, the required AI experts are not easily available in the market. Consequently, the decision was made to opt for a build-operate-transfer model: the development and operations support for these components will initially be outsourced. Medium- to long-term, ACME Smart Shuttle will then take over the team from the external supplier to become part of the in-house organization.
For AI-enabled in-vehicle surveillance and vehicle maintenance, the decision was made to buy these components because they are not strong product differentiators and commodity solutions should be available with potentially one exception: the automatic detection of violence between students or even vandalism. For this particular feature, a co-creation model could be envisioned, assuming that there would be a market for such a feature beyond the business scope of ACME Smart Shuttle.
AIoT Sourcing BOM
The next step is to turn the generic AIoT BOM into an AIoT Sourcing BOM. The first thing that needs to be looked at in more detail are the required quantities:
- For hardware components deployed on the assets, the required quantities will depend on the number of assets to be supported. This again will depend on the business plan. This means most likely the correct strategy here will have to foresee different options, like a minimum and a maximum amount required. This will have to be mapped to different contractual options with the suppliers.
- Additionally, for software licenses, the number of clients often plays an important role. In the case of AIoT, clients can either be human users or assets. Again, this will depend on the business plan and require some flexibility to be built into the sourcing contracts.
- Finally, for custom developed software, the Sourcing BOM will sometimes have to include an estimation of the required development resources (number of developers, availability). Alternatively, this is an estimation that can come from suppliers, based on the requirements.
Next, for each item in the Sourcing BOM, a sourcing decision will have to be made. Sourcing options typically include internal development, management consultancies (e.g., for project management), System Integrators, Commercial Off-the-Shelf Software Vendors, Cloud infrastructure providers, engineering companies, manufacturers, and telecommunication companies.
A key decision for each element in the Sourcing BOM is the make vs. buy (or partner) decision. This decision will depend on a number of different factors:
- Strategic importance of AIoT Solution as a whole and the contribution of each BOM item individually
- Internal capabilities: is this something your company can realistically do itself?
- Availability of internal resources
- Timing: who can deliver within the required time frame?
- Brand considerations: will having a certain brand for a specific subcomponent improve the overall value of the product?
- Overall partner strategy: does it make sense to utilize some companies not only as suppliers, but also as potential additional sales channels?
Once quantity and sourcing strategy information has been added to the Sourcing BOM, the schedule perspective needs to be added as well. This needs to be carefully aligned with the development schedule to avoid roadblocks on the development side.
Finally, it is important to note that in a complex AIoT project, not all required solution elements may be known from the beginning (or they might be subject to change). Agile development methodologies are designed to address volatile requirements and solution designs. However, from a sourcing point of view, this is obviously very problematic. Frequent changes to the Sourcing BOM will result in loss of time and potentially even spending money on the wrong things.
The following provides some examples of typical elements of an AIoT Sourcing BOM specifically from the point of view of AI- and IoT-related components.
AI-specific Sourcing BOM elements
The following are some examples of typical, AI-specific elements of an AIoT BOM:
- AI platform, including AI-specific hardware and middleware - for use in the cloud/on-premises backend, or the EDGE layer
- Functional components requiring resources with AI-specific skills, including the AI engineer, data scientist and AI DevOps engineer
- Outsourced data labeling services, e.g., for manual image classification; beware that transferring images with personalized data to other countries for such processing services can be prohibited by local regulations.
- AI-specific QA, testing and validation services
IoT-specific Sourcing BOM Elements
The following are some examples of typical, IoT-specific BOM elements:
- IoT-related cloud infrastructure
- EDGE infrastructure (hardware, software)
- Resources with IoT-specific skills, e.g., embedded hardware or software development, AIoT project management, etc.
- Telecommunications services, e.g., a global IoT network from a telco carrier or an MVNO
- Security-related infrastructure, testing services, operations services and skilled resources
- Operations services and support
Aligning the agile development schedule with the sourcing schedule will probably be one of the key challenges in any project. This is critical to the success. Final sourcing and supplier decisions are often a prerequisite for:
- Achieving architectural stability: For example, the selection of a specific cloud or middleware platform can have a significant impact on the solution architecture
- Availability of development tools and environments: Similarly, the setup of development tools and environments will usually be supplier-specific, and will require an early decision in the project
- Developer availability: The availability of both hardware and software developers typically also depends on the chosen technology
- Infrastructure setup: Additional infrastructure such as an AI environment or a security framework will again depend on the final sourcing decision
- Hardware development: Finally, any hardware-specific development will also require sourcing decisions, e.g., for processors, boards, or communication modules
The figure below highlights the potential dependencies between the agile development schedule and the sourcing schedule.
Before starting the RFP process, a number of other general considerations must be made, including the required SLAs and Warranties, pricing models, and vendor selection criteria.
SLAs and Warranties
A critical decision in the procurement process is the type of contract that is aimed for, especially for any kind of custom development:
- Service contract: Typically, time and material
- Contract work: Typically, includes SLAs, maintenance commitments, warranties, etc.
In many situations, the latter will be particularly important for an AIoT solution. Warranties typically ensure that a service will perform in accordance with its functional, technical and business specifications. Service Level Agreements (SLAs) offer performance metrics and details on the specific consequences of a provider who is failing to meet those standards.
Typical SLAs in IT projects include:
- Service availability: Specifies the amount of time a service is available, e.g. 99,99% (which would imply ~88 hours of average annual downtime)
- Defect rates: Quantification of allowed error rates in a service
- Defect resolution: Addresses the speed by which problems are addressed
- Security: Addresses the security of the service
- Business results: Address the business perspective, e.g., as business process metrics
The table following shows some examples where this is applied to an AIoT Solution.
ACME Smart Shuttle: SLAs for AI?
The ACME Smart Shuttle had previously identified three key components for the system, which utilize AI. The decision was made to apply a build-operate-transfer model as the sourcing strategy for these three components. This means that component development will initially be sourced externally, with the goal to then in-source the team over time. To ensure that the external team meets the requirements, a set of SLAs have been defined. These SLAs differentiate between functional and nonfunctional aspects. The functional SLAs are specific to the individual components, while the nonfunctional SLAs in this case apply to all three components. The figure following provides an overview.
A key issue with SLAs for AI-based components is that AI models usually decay over time, due to changes in the input data. Take, for example, the ETA prediction function for shuttle buses: this function will heavily depend on map and traffic data. If the actual layout of the street grid is changing (e.g., due to construction sites), this will probably require the ETA models to be retrained with the updated map data. This will have to be reflected in the contract as well: The SLA definitions can only apply to models that are regularly retrained.
Another important factor in the sourcing process is the pricing model. In many situations, the customer will define the required pricing model as part of the RFP. However, in some cases, the pricing model can also be defined by the supplier.
In IT development projects, the most common pricing models are Fixed Price and Time and Material. A key prerequisite for a Fixed Price project is a stable, complete and sufficiently detailed requirements specification and Service Level Agreements. If this cannot be provided, then Time and Material might be the only real alternative. Variations of the Time and Material approach are the Dedicated Team approach, as well as Agile Pricing. In Agile Pricing, often a base price is agreed upon, combined with incentives related to the achievement of individual sprint goals. Another pricing option is a model where the supplier participates in the business success of the customer, e.g., revenue sharing ('Outcome-based pricing'). However, getting both sides to agree to a fair sharing of risks and rewards can be a difficult undertaking.
Other elements of the AIoT Sourcing BOM will again require completely different pricing models. For example, the pricing for telecommunications services will often depend on data volumes and other factors. The pricing for custom hardware is likely to depend on individual component prices, as well as volume commitments.
AIoT Vendor Selection Criteria
Once it is decided which items from the AIoT Sourcing BOM should be externally acquired, it is important to create a set of clearly defined selection criteria. The Digital Playbook proposes a spreadsheet that includes the AIoT solution in general, nonfunctional requirements, functional requirements, and finally the operations and maintenance requirements. Each of these criteria should be individually weighted, so that later an overall score can be derived for each offer.
In this context, a number of key questions will have to be answered, including the following:
- How important is cost relative to the other areas?
- How important is the ratio between functional and non-functional requirements?
- How important is the vendor evaluation, including strategic fit, financial stability, long-term maintenance capabilities, etc.
The figure below shows an example for a spreadsheet containing key selection criteria.
Finally, once the internal alignment is completed, the RFP process starts. This includes RFP document creation, RFP document distribution and Q&A process, and eventually AIoT vendor selection.
RFP Document Creation
The creation of the actual RFP document(s) is a critical part of the sourcing process. It is key that an RFP document is as concise as possible, with sufficient detail for any contractual agreement based on it. Any gap or inconsistency in the RFP can be used further down the path by a supplier for re-negotiation or costly change requests. Consequently, the RFP should be written specifically for the situation at hand and not a repurposed, generic document. Typical elements in an RFP include:
- Company name, project name, proposal due date
- Project overview
- Scope of work
- Functional requirements
- Non-functional requirements
- Quality criteria
- Submission requirements and process
In many cases, it can also make sense to be transparent about the following:
- Evaluation metrics and criteria
For the Scope of Work part, it makes sense to reuse many of the Solution Architecture design artifacts, e.g. the solution sketch, data domain model, component design, etc. However, two key questions must be looked at here:
How many details from the business plan to reveal in the RFP? It can be advantageous to share some details of the business plan with potential suppliers to allow them to get a better understanding of the business potential and thus to make better offers. However, many companies would feel reluctant to share too many details in a document shared with many external stakeholders.
How detailed should the solution design be? Providing a solution design to potential suppliers can be a good way to ensure consistent offers from different contenders, which closely match the requirements. However, it can also be limiting in terms of obtaining different solution proposals with different strengths and weaknesses.
The Industrial Internet Consortium (IIC) has developed an online tool for creating an RFP for Industrial Internet solutions. While currently lacking the AI perspective, this can still be an interesting tool for anybody creating an AIoT RFP document, at least for the IoT parts.
RFP Document Distribution and Q&A Process
After completion as well as internal review and approval, the RFP document is distributed to relevant supplier candidates. In some cases, the RFP might also be publicly made available, if this is an internal requirement.
If the process permits this, the receivers of the RFP are likely to come back with questions. First, almost any RFP will leave some room for interpretation. Second, most suppliers are likely to seek close, personal contact with the acquiring company and the sourcing team. It is important that to run a transparent and fair selection process, the questions from all potential suppliers are collected, and the answers are shared as an update to the RFP with all contestants. This will also help increase the quality and comparability of the offers.
AIoT Vendor Selection
As part of the selection process, vendors are invited for individual vendor presentations. Based on this information, a first set of vendors can be preselected. Reference calls can provide valuable insights from other customers of the different vendors. In some cases, smaller Proof-of-Concept projects are done with these vendors. Based on the outcomes of the PoCs, a short list can be created. Often, the last 2-3 vendors are then asked to do a more extensive pilot project. Based on the technical and functional evaluation, as well as extensive price negotiations, the final selection is then done.
The selection process is often overseen by an evaluation committee, which evaluates the recommendation by the operational sourcing team. The evaluation committee usually includes stakeholders from senior management, business and technology experts, as well as representatives from procurement and legal. Members of the evaluation committee ideally review the final proposals independently using an evaluation spreadsheet as described above. Depending on the complexity and criticality of the project, they might also be asked to provide written statements.
Finally, the results will have to be communicated to the contenders. Depending on the internal processes of the buyer, different policies might apply here. For example, it can make sense to communicate not only the result but also some decisions such as the evaluation criteria matrix. This will help suppliers to improve their offers in the future. However, it can also lead to unwanted discussions. Developing a good (but of course also compliance-rules obeying) relationship to high-quality suppliers can be a strategic advantage and might warrant additional effort in the communication of the selection results.
The legal perspective of an AIoT initiative is often closely related to sourcing activities because customer/supplier relationships need a solid legal foundation. The following interview with Philipp Haas (head of the Expert Group for Digital and New Businesses at Bosch`s legal department) provides some insights on the level perspective, building on the ACME Smart Shuttle example we introduced earlier.
Dirk: Thanks for joining us today. Tell us a little bit about what you do at Bosch. What's your role?
Philipp: I have been a consultant in the legal department of Bosch for 10 years now, and I am currently responsible for the central department for digital and new businesses. This includes consulting various smaller legal entities and central departments within Bosch. In addition, I'm also heading the expert team for IT law. We are also supporting the other colleagues in the legal department with respect to digital businesses.
Dirk: Thank you for supporting us with the Digital playbook. When we started our discussions, we learned that the different legal aspects around AIoT are quite complex. That is why we said the best way to get a 360-degree view of the legal aspects would be to discuss this based on a realistic use case. So from a legal point of view, what are the key issues that we need to consider in our ACME Smart Shuttle example?
Philipp: I think the most important role is that of the platform operator because they sit in the middle of everything and offer the AIoT-enabled product. They have contractual relationships to many parties.
Dirk: Good point. Let's get started with the relationship between the platform operator and the OEM. What does the platform operator have to look out for from a legal perspective?
Philipp: In our scenario, the ACME Smart Shuttle is operating a fleet of shuttle buses, which need to be purchased or leased from the OEM. What is very important for our platform provider is that he's not only getting access to the vehicles, but that he is also having access to the data in the vehicles. Otherwise it will be more difficult to offer data-based services, which is a key assumption in this example. So there needs to be an additional agreement for the data generated by the vehicles. This means we need a data sharing contract. If the fleet is large enough, this could be an individually negotiated contract; alternatively, the platform provider has to agree to the standard offerings, which some OEMs already have out there. For example, BMW offers connected drive services, which include access to car data.
Dirk: Thanks. So that is our main supplier. What about the other suppliers, anything specific to look out for?
Philipp: Almost all IoT use cases today require a cloud provider, typically from the US or China. Cloud services are essential for the platform provider because they provide the infrastructure for running the software and the AI algorithms. Depending on the setting, you choose between software-as-a-service or infrastructure-as-a-service, if you need more control. Many of these cloud services are highly standardized today, and there will be little room for negotiating individual contracts. So selection of a cloud infrastructure player will not only be a technical choice but also requires you to look at costs and standard legal terms and conditions.
Dirk: And what about the counterpart to the cloud, the edge side of things. For example, in our Shuttle Bus example, we are assuming that there will be custom edge nodes embedded into the buses. What are the relevant aspects from a legal point of view with respect to the edge component provider?
Philipp: If the platform operator purchases devices that are responsible for the connectivity - for example, to his back-end - it might be necessary to have an agreement regarding the transport of the data. Such devices typically have a SIM card, either as a regular SIM or a built-in SIM card. It makes a difference who is responsible for the activation of this card. Therefore, if the device supplier is activating the card, it might be necessary that the supplier register as a telecommunication provider. The alternative would be, that the platform provider might have to conclude an additional contract with a responsible telecommunication provider directly. This might also be the case if the supplier is just delivering the hardware with a SIM card and the platform operator is responsible for activating the hardware (and the SIM). If the platform operator is responsible for activating the hardware, we have to examine his role. He then might become a telecommunication provider if he is responsible for the transport of data to his contract partners, but in our use case I do not think this will be the case for the platform provider.
Dirk: Talking about data in our Shuttle Bus scenario, one option that we have been discussing is for the bus operator to out-source the development and training of the AI algorithms. This would require the platform operator to make all the required data available to a third-party IT development firm. Are there any specifics that he has to look out for, in particular with respect to the ownership of his data?
Philipp: Yes, this is a very typical scenario. You are using the wording “his data”, so the first question would be what exactly is "his data"? Does the data we are talking about truly belong to him? Legally there is no data ownership. If you're talking about data, there are two key aspects. The first key aspect is, are we talking about personal data? Because personal data within Europe are subject to the GDPR (General Data Protection Regulation), in addition to other international data protection laws. It typically means that you are only allowed to process the data -- including handing it over to a third party for development -- if you have a legal basis for that. The second key aspect for processing or transferring data are the relevant contracts. For example, the contracts that apply when receiving data might limit your ability to make these data available to a third party for further processing. So you're only allowed to transfer the data within these boundaries. If that is possible, usually there is no other legal protection for the data. In some very limited cases, data might also be protected by IP rights.
Dirk: In our scenario, the IT supplier of the ACME Smart Shuttle uses data from different sources, including data from the ACME Smart Shuttle, data from schools (e.g., school time tables), and data from third parties (e.g., traffic data). From these data, they derive new data via AI, e.g., bus schedules and routes. Does the AI and the new data created by the AI automatically belong to the ACME Smart Shuttle, because they are paying for it?
Philipp: No. It is highly recommended -- I would say even absolutely necessary -- to have a clear agreement with the IT supplier regarding the results that are created with the data. That is one of the topics I mentioned before, where it is legally not easy to determine who contributed to the results and who is the owner with respect to the results. That is why it is essential to have an explicit agreement on that. In joint development projects, you always have clauses regarding the rights to the development results. You also have clauses regarding software, so that, that is quite standard. In the newer contracts, we see clauses that explicitly refer to data, the right to data, maybe distinguishing between test data and productive data, and also with respect to work results that have been created using such data.
Dirk: I do understand the differentiation between software and data. But what about the trained AI models - are they data or software, from a legal point of view?
Philipp: An AI model will usually fall in the category of software. Software is defined in copyright law, and it is a program for computers that shows the computer what the next steps are. A trained AI model usually runs within a software environment. Maybe it is not a software on its own, it is just part of a software but also parts of software are considered as software under the copyright act. So I think it will be protected by copyright law, which means that it is possible to have an agreement on the usage rights and you can transfer that to the platform provider. And the platform provider will, of course try to do that because as you mentioned, he paid for it. However, this is not always possible because sometimes, if you have very large suppliers who argue that they are also using pre-existing works for their work results, it might be not easy to get all exclusive usage rights. There might be an individual agreement on who is allowed to do what with the work results.
Dirk: OK, let us assume we got all this sorted out, and we now have our platform up and running. What about our relationship to the end customer, the students of the school?
Dirk: Another important group of stakeholders in our example are the drivers...
Philipp: In our example, the drivers are employed at platform operators. There might also be a service contract with them if they're independent, but then you have to make sure that they are truly independent and not "by-accident" employees, because this could cause major risks for the platform operator for example regarding tax law. The employment contract itself, I would say that is also quite standardized but we have this special case here that we need to have an agreement regarding the usage of the data from the shuttle buses. Because data that we get out of the vehicles could be contributed by the driver, it means that they are personnel related and that is why we need to have an agreement on the usage. This is legally not trivial because the platform operator has to obtain free and voluntary consent from his employee. I think in our use case, there is also a good justification for the platform provider because the usage of the data is an essential requirement for his business use case. He cannot operate the platform without that. So the request is absolutely reasonable.
Dirk: Thanks. Anything else that we have to look out for from the perspective of the Shuttle Bus platform operator regarding legal aspects?
Philipp: We looked at the contractual relationships and I mentioned new legal developments regarding consumer protection laws. The same applies for digital business in general. There are many laws that either recently came into force or are still in development. I mentioned the telecommunications act that is currently revised on the European level. There are various legal drafts regarding platform regulation, and already existing platform regulations. The Data Governance Act will contain requirements if you want to share data via a platform. The Digital Content Directive has already been transformed into German law and such new regulations as of January 1, 2022. It makes various requirements for digital offers, which also includes software as a service or apps. For example, it contains an obligation to make regular security updates during the lifetime of the service. And on the horizon, we also see a regulation for AI. There is a first draft from the European Union. This is a very interesting regulation from a legal perspective. From the operator’s perspective, it could lead to some new obligations, such as checking the data that he is using for the training of the AI models. According to the draft, the data have to be free of errors. There is an obligation to document the data usage. You have to document the results of the AI system so that you can track back exactly why a certain decision has been made by the AI. For nearly all AIoT products that are considered “high risk”, this AI regulation will play a large role in the future.
Dirk: And do you see something similar coming up in USA and China as well?
Philipp: In the US, I recently read a statement from the US Department of Commerce regarding the AI Regulation, and it did not sound like they want to follow us. They seem to have a different approach and are looking with a skeptical eye on our regulation and do not think that it is helpful. So no, I don't expect a similar regulation from the US at the moment. In China, the situation is different. There are new security laws put into place and they also regulate the usage of the data. AI regulations are not for protecting the individual but more for protecting the interests of the government and the country. There will be a definition of categories for data that fall under these new security laws, but I read that vehicle data will be considered as one of the critical data categories. So I think in the future operating such a platform for China might be only possible within China.
Dirk: Last question. Looking at this from the perspective of the project manager, when in the lifetime of their project should they involve legal expertise? And what's the best way to actually embed this legal expertise in the project?
Philipp: Okay, this question is very simple to answer: As early as possible. Because there are many legal considerations and I would also say many traps.
Dirk: So depending on whether the operator operates from within a large organization or actually as a startup, how does he go about this? Does he really make legal experts part of his team or how does he get access to this expertise?
Philipp: This is a case by case decision. The legal counsel can become part of the project team, which has the advantage that he has deep knowledge about the technical and business considerations of such an offering. For a startup it might be too costly to involve external counsel as part of your project team and let them participate in every discussion. You might take a leaner approach and discuss it with the counsel and work out a plan at the beginning so that it is clear what has to be considered. And then you can go ahead and have regular meetings, discussions with the legal counsel, but not directly include him into every discussion.
Dirk: Great. That was super interesting, thank you very much.
Authors and Contributors