Co-Creation and Sourcing Intro

Abstract

AIoT-enabling a product or solution usually requires quite a number of different technical components, infrastructures and resources. Very few companies will be able to source all of this completely internally, so naturally sourcing plays an important role in most AIoT initiatives. Furthermore, there is often an opportunity to partner with other companies, e.g., because of complementary market access, brands, or product components and capabilities. Going from traditional customer/supplier relationships towards a partnership can have many benefits but obviously many risks as well. In many cases, one will see both in the context of an AIoT initiative, e.g., traditional sourcing for commodity components and resources, and a more partner/co-creation oriented approach in other areas. This chapter will first look at co-creation in the context of AIoT before discussing the more traditional sourcing approach.

AIoT-enabling a product or solution usually requires quite a number of different technical components, infrastructures and resources. Very few companies will be able to source all of this completely internally, so naturally sourcing plays an important role in most AIoT initiatives. Furthermore, there is often an opportunity to partner with other companies, e.g., because of complementary market access, brands, or product components and capabilities. Going from traditional customer/supplier relationships towards a partnership can have many benefits but obviously many risks as well. In many cases, one will see both in the context of an AIoT initiative, e.g., traditional sourcing for commodity components and resources, and a more partner/co-creation oriented approach in other areas. This chapter will first look at co-creation in the context of AIoT before discussing the more traditional sourcing approach.

1 Co-Creation

Co-creation between different companies can be an attractive alternative to the more traditional buyer/supplier relationships. This chapter examines different co-creation models, specifically from an AIoT perspective, before bringing in expert opinions from different perspectives, including enterprise, start-ups and venture capital (Fig. 14.1).

Fig. 14.1

Co-creation

1.1 Why AIoT & Co-Creation?

What are reasons for co-creation and partnering in an AIoT initiative? On the more strategic level, branding, access to an existing customer base, the exiting global footprint of a partner, access to physical assets or outlets (e.g. repair stations), or domain know-how and existing applications can be good reasons.

Since data are the foundation of any AI-based business model, this can play another key role. Often, data-related co-creation is about the federation of data from two domains, with the expectation that the sum here is larger than the parts. For example, co-creation partners can federate IoT-generated data from multiple machines in a manufacturing setting to support a more holistic OEE perspective for the end-customer.

The development of AI/ML algorithms can also be an interesting area for co-creation. Of course, this will often also be closely tied to the data side of things. For example, the massive costs of develo** AI for autonomous driving make some OEMs consider a co-creation/strategic partnership approach in this area.

The need to combine different, highly specialized technologies in the context of AIoT can be another reason for co-creation and partnerships. This can be the combination of different IT enabling technologies, or the combination of IT and OT technologies. Especially with IT/OT, it is often the case that the required expertise is not found in a single company.

Platforms are another interesting area for co-creation. Especially in the area of platforms that need to combine know-how from different industry domains, or provide some kind of data federation, this can make sense. Co-creation here is not limited to technical co-creation. For example, if partners decide to create a platform as a joint venture because they want to pool data, this can also be seen as a form of co-creation (Fig. 14.2).

Fig. 14.2

Why AIoT & co-creation?

1.2 AIoT Co-Creation Options

Because many people have a different understanding of what co-creation actually means, the following provides a short discussion of common patterns.

In some cases, companies that are actually in a traditional buyer/seller relationship will extend this relationship, e.g., by creating a press release about a “strategic development partnership”. Or, they will apply value-based pricing, i.e., the seller is participating in the business success of the buyer. In the case of smaller suppliers, it is also common that the buyer insists on a source-code escrow to have access to the sources in a worst-case scenario or even insists on a stock right of first refusal. These are examples that we would NOT consider to be co-creation, because they are too close to a traditional sourcing relationship.

Co-creation can be more technical or more focused on joint Go-to-Market (GTM). Technical co-creation usually means that – at least – two companies are combining their Intellectual Property (IP) in order to create something new. For example, this could be a company with deep industrial domain know-how partnering with another company that has deep AI experience. Another form of co-creation is focused more on combining two existing offerings into a new offering, but without a deep technical integration. This could mean truly combining two existing offerings or actually selling one company’s offering via the channels of the other. Of course both approaches can be combined.

This does not have to be limited to 1:1 partnerships but can also lead to multiparty ecosystems.

Platforms are another area for co-creation. A partner platform will allow partners in a closed ecosystem to work together. For example, a platform for an industrial robot could allow partners of the robot manufacturer to submit applications, which are then operated in a semi-sandboxed environment. Because all the partners are well known and trusted, this approach will be possible without a fully secure execution sandbox. This makes sense, especially if the cost for develo** a sully secure sandbox is prohibitive or technically impossible. A fully open platform will have made the investment to develop a secure sandbox, which will enable onboarding of unknown and per se untrusted partners. This will be even more important if apps are deployed not only in the cloud but also on physical assets. In an AIoT scenario, the sandbox will need to provide execution capabilities for code as well as AI/ML algorithms (Fig. 14.3).

Fig. 14.3

AIoT co-creation options

1.3 Expert Opinions

The following interview provides insights on AIoT and co-creation from different perspectives, including large enterprises, venture capital, and research. The experts are:

• Jean-Louis Stasi, Senior Vice President, Strategic Partnerships with Startups, Schneider Electric

• Dennis Boecker, Global IoT Innovation Lead at Bosch

• Ken Forster, Executive Director at Momenta (VC)

• Prof. Heiner Lasi, Director Ferdinand-Steinbeis-Institute

• Dirk Slama: Jean-Louis, how is Schneider Electric managing co-creation?

• Jean-Louis Stasi: Schneider Electric has twenty lines of business in different areas of energy management and automation – each one roughly with revenues of a billion Euros. Each has its own market environment and its own R&D roadmap. Each is facing different regulatory requirements, which has a huge impact on innovation as well. Take the highly regulated electricity grid market versus fast moving areas such as data centers. Each business has its individual set of conditions in which they are operating, and that is nothing new. However, this defines the appetite for co-creation for each business differently and the different ecosystems they are focusing on. The starting point is always the same: what is the problem that the business is trying to solve? They see the opportunity and the value of the market, but they do not have the required skills and resources internally. They understand that this is going to happen in the next two to three years – so they know they have to move fast. Cyber-security is a good example. That is the next big thing for every industry customer in the world. If I do it myself, it will take me six, seven years. The alternative is to find a start-up as a partner and then scale up together. Of course, going into such a partnership mode is a structural and strategic decision.

• DS: So the main rationale for co-creation is time-to-market?

• JLS: No, not necessarily. There are other factors, such as a better understanding of market cycles or specific use cases. Another aspect is the management of business model evolution vs. technological game changes. So I do not want to emphasize time-to-market only, but the point is it has to solve a real-life problem. It has to solve a big problem and has to happen in the next three to five years. Those are the three key conditions.

• DS: Dennis, what is your take on this from the Bosch perspective?

• Dennis Boecker: I agree in general with what has been said already. What I would probably emphasize more is that we’re coming from our strategic search fields. Many of these strategic search fields are cross-divisional topics, because major trends such as mobility, construction and building technologies cannot be limited to a single line of business. The strategic search fields agree with the executive management, and are aligned with the different lines of business. The interesting question then is how you address the different strategic search fields. We have identified four different ways of doing this: Corporate Product Innovation, Strategic Partnerships, M&A, and Start-up Co-Creation. Corporate Product Innovation is an internal approach in which we focus on building up our own Intellectual Property (IP) and capabilities. Strategic Partnerships are for big projects, taking more a consortial approach. M&A for us is the enhancement of our own IP and our core capabilities. Finally, Start-up Co-Creation focuses on very concrete portfolio elements, or very specific problems we need to solve. Here, time-to-market is usually more important than IP. Say, for example, we are involved in a large bid ourselves, where we have identified a gap in our own portfolio. A start-up is able to address this very quickly. We can even work on several portfolio elements with different start-ups. This is a good way of creating an ecosystem. You share a problem, and then you start working on concrete projects, either in a more strategic partnership, with start-ups, or even a combination thereof. Co-creation for me is not a one-to-one model, where two companies work together to create a specific piece of IP. We truly want to build open ecosystems around our strategic search fields, including multiple partners. And then applying any of the four collaboration models which I just explained, depending on the situation.

• JLS: Interesting. Schneider Electric has a very decentralized model of control. Each line of business is pretty much autonomous in their selection of partnership models and specific partners. So there is no centralization of this element. At the end it produces a central result, where each business has its own iteration on that. An important element is the intuition between a start-up and the larger structure. A start-up is not necessarily three guys in a garage. It can already be scaled by a team of 200 engineers, which have already scaled to a certain level of product-market fit. As we grow more confident in the potential for scaling their business, they become an M&A target for us. However, this is a continuous process, and it is not decided in the early stages. It takes some time for a partnership to evolve into something more, before it becomes strategically impactful for us at large and we are prepared to make a move in the direction of M&A. Another important aspect in this is the geographical footprint. Because what we see is of course markets are evolving at a different speed, depending on where the innovation is happening. Is it US? Is it Europe? Is it China? And each market also has its own way to do things. So we also have this dimension that we need to integrate into our model because as you develop that globally, there is no one way to do that things. Each kind of region has its own specifics, depending on the maturity and culture.

• DB: I agree with you on the necessary evolution of partnerships. There is definitely a chance that the portfolio approach and the respective relationships with the ecosystem develop from one quadrant into the other. But in the very beginning, I think you need to be very clear if this is something to share with the ecosystem or if it is rather something that you want to own the IP ultimately yourself. That is something that you need to be very clear about.

• DS: Let us switch the perspective from the enterprise side to the start-up side. Ken, Momenta is an investment fund that specifically focuses on AIoT companies. What are you telling the companies in your portfolio: look for a buyer-seller relationship with large enterprises, or focus on strategic partnerships?

• Ken Forster: We see it as an ecosystem of many-to-many, with many actors contributing to the overall value of solutions. Let me first outline the actors and then I can reflect on the role Venture Capital plays. I will generalize four key actors in the AIoT ecosystem: incubators, innovators, incumbents, and the implementers. As investors, we broadly operate as an incubator working to grow young companies that are often innovators. The large strategic Operational Technology (OT) players are generally incumbents. Finally, we have the end users, implementers, those leveraging our collective technologies and tools to create business outcomes. Between these actors, Venture Capital sit at the intersection of innovators, incumbents and implementers accelerating the velocity of innovation. Early stage companies often do not have the resources or experience to dance with the elephants of industry, so we bridge the gap, investing behind the innovators to accelerate their capabilities to play in the larger ecosystem. While our initial value is in providing seed to later-stage capital, the larger value is often the acceleration we bring via our AIoT ecosystem networks. As an example, we organized a consortium of four of our portfolio companies last year to demonstrate an intermodal container location and condition monitoring demonstration for the U.S. Department of Defense. The pilot demonstrated the use of AIoT technologies to track the location of containers through the full journey of shipment while recording the condition of the cargo within those containers, including security. This was truly a team effort with each portfolio company providing a critical piece of the solution. The DOD in this case was the implementer actor, our portfolio companies the innovators with Momenta acting as the incubator. Of course, once product-market fit is demonstrated, the incumbents will often play the strongest role: providing the ‘voice of the customer’ backed by their own size and momentum to scale up these innovations to the enterprise scale. In summary, we operate at the Venn of innovation – bridging the innovation of startups with the enterprise scale of large industrials. Our tools are capital, securing key leadership and teams, and activating partnerships early and often with companies such as Bosch, Schneider Electric and other market leaders.

• DS: Thanks. Now let us look beyond AIoT-enabling technologies for a moment. Heiner, another key ingredient to AIoT is data. In your research, you are focusing on ecosystems for data sharing to support different AIoT use cases. Care to explain?

• Heiner Lasi: As you said, an AIoT use case needs data to operate on. If these data are created and processed within a single company, everything is fine. However, in many cases, you will need to cross these boundaries. Either because you need to combine data from different IoT-objects/companies, or because companies need to access data from other IoT-objects/companies in order to create business value. Let us take a logistics company that is running a fleet of forklifts. The initial IoT business cases here were very much about operational efficiency. This was all internal. But now we are seeing “… as a service” business cases. This means that logistics companies and forklift manufacturers must share operational data. In addition, insurance and finance companies are becoming involved in these business cases. On the technical level, emerging concepts such as cooperative Data Spaces can help here. However, the issue here is not technical integration but rather the creation of a partner ecosystem that is develo** the required levels of trust to share operational data between the partners. This is not about technical trust; this is about trust on the business and even the human level. Transparency is important. This is what we are trying to address with our concept of data coops. These data coops are a manifestation of a data-centric ecosystem, with clearly defined rules of engagement, and a data space as the underlying technical platform. The rules of engagement must address how – for example – the logistics companies, the forklift manufacturers, and the financial companies are providing and accessing data, and how the benefits are shared. While AIoT is an important technical enabler in all of this, it really comes down to creating an ecosystem of partners who trust each other. And it takes time to develop the required level of trust.

• JLS: This is an extremely critical point. What we are seeing at Schneider Electric is that there is a very strong relationship between the time you connect an asset with a sensor, and the time you get tangible business value out of it. Time-to-value is of the essence. I think we – all the industrial companies – have a long list of IoT use cases which have created zero value. Anything beyond three months, you lose the momentum, you lose the sponsorship. If you are thinking too broad, try to integrate too many stakeholders, things get too complicated. Every factory you talk to is adding new requirement. The conditions in the factories are different. The cloud infrastructure is different. The level of knowledge is different. It never ends. And suddenly you are caught in the “pilot dead end”.

  To Heiner’s point about the data: the challenge is to ensure that these data are turned into a tangible benefit for the customer in a very short amount of time. To achieve this, you have to maintain OT leadership in the team. You must give them the value, which means you also must give them the leadership. If you give the leadership to the IT guys, it is finished. That is our experience.

• HL: I agree. However, this is not only about IT vs OT. This is also about creating a link between business experts from different industry domains, such as OT and financial services, e.g., to enable “as a service” business models. In this example, you need to combine the experience of running the OT side with the experience of understanding the inherent financial risks.

• JLS: Let us take supply chain visibility, e.g., in the food and beverage industry. This is a good example where we need to unify data to obtain increased visibility. It took them years to realize that yes, it makes sense to share data, because we have the same suppliers and we want to make sure that this food product truly is coming from the right place. It took perhaps five years to reach this level of trust in this ecosystem. But then we are coming back to time-to-value: People do not have five years to get to the outcome. They have to create value in the next six months. So there is this big tension in the AIoT space regarding the time it takes to build trust. Maybe eventually there will be a technology such as blockchain to intermediate the trust, but I think thus far this has not yet scaled beyond one or two verticals. I want to reiterate this, because I think AIoT has been failing in many, many cases because of this lack of value in a given time frame. In addition, I think we are still on this journey where it takes more value creation to justify a vertical integration, end-to-end.

• DS: Does this only apply to what we have been calling the long tail of AIoT, or are we also talking about the short tail of AIoT here?

• DB: Even for the high-impact products on the AIoT short tail, you need to ensure that you are delivering value creation along the way. If you have this huge AIoT short tail opportunity which you know will take you three to five years to deliver, you better make sure that every couple of months on the way to it you show tangible value creation. This is what I was referring to earlier on regarding portfolio achievements and strategic partnerships. On this level, it will take a longer time, and you cannot expect to get the full outcome in three months, because it’s just too much and too complex. However, you need those complementary, smaller items along the way to show that AIoT makes sense. Admittedly, with physical products involved, finding a stable Minimum Viable Product is much more difficult, but still…

• KF: In the past, AIoT products often required full stack solution development. As an example, Nest had to develop the full stack of software, hardware and connectivity to build a smart thermostat. Today, this development is more horizontal allowing solution developers to choose from best of breed components leveraging standards. In this momentum from highly vertical development toward more horizontal solutions, there is even more opportunity to work with an ecosystem of companies that are aligned around domain specific use cases.

• HL: We see a similar trend for data coops. Usually, they are initially clustered around domain-specific use cases. Therefore, the data coop with the underlying data space is the platform, with the different use cases representing long tail opportunities. Because there is an upfront investment in setting up the initial platform, it is key to immediately show value creation with the first use cases.

• JLS: If you are talking about high-impact products such as the first iPhone, I agree. They take significantly more time and higher investments. Even if we are talking about IT/OT integration, it is important to understand if you are talking about the device manufacturer, or the implementer. If you are talking about the manufacturer of a new AIoT-enabled device, I agree with your characterization. However, if you are talking about the implementation side, where you are addressing many factories in different locations, you need to do this in a very consistent and predictable way. You will need a very simple and easy way, so that every operational team can implement this in less than three months. Than you can reach massive scale because you are making things so simple. Then, it becomes like the SaaS (Software-as-a-Service) model. This is where AIoT today starts to become relevant for industrial companies, because end users are able to scale this up themselves.

• DS: Thank you all!

1.4 Tradeoffs

To conclude the discussion on co-creation and strategic partnerships, let us take a short look at the pros and cons. For example, some of the risks and drawbacks include:

• Technical, legal and commercial complexity, as well as generally increased stakeholder complexity leads to a significant increase in project risks

• Colliding interests can lead to failure or at least unbalanced partnerships

• Limited visibility and lack of transparency can impose significant risks

Some of the benefits include:

• Significant business and technical synergies

• Unlocking creative potentials that would not be possible within a single company

• Access to markets otherwise not easily accessible

• Combining speed and agility of startups with global reach and execution capabilities of incumbents

Before making a decision on co-creation vs. traditional sourcing, these factors need to be carefully weighed.

2 Sourcing

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) (Fig. 14.4).

Fig. 14.4

Sourcing

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.

2.1 Challenges

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.

2.2 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 (Fig. 14.5).

Fig. 14.5

AIoT sourcing process

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.

2.3 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.

2.3.1 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 (Fig. 14.6).

Fig. 14.6

AIoT sourcing options

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 (Fig. 14.7).

Fig. 14.7

Sourcing strategy decision

2.3.2 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.

2.3.3 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. Figure 14.8 shows the key elements and stakeholders of the ACME Smart Shuttle system.

Fig. 14.8

Example: supply chain of our shuttle bus 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. Figure 14.9 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.

Fig. 14.9

Solution architecture as the starting point for BOM breakdown

2.3.4 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. (Fig. 14.10).

Fig. 14.10

AIoT sourcing BOM: creation

2.3.5 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. Fig. 14.11 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.

Fig. 14.11

Sourcing BOM with different sourcing scenarios

2.3.6 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 Fig. 14.12.

Fig. 14.12

Outsourcing AI?

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.

2.3.7 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 (Fig. 14.13).

Fig. 14.13

AIoT sourcing BOM: refinement

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.

2.3.7.1 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

2.3.7.2 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

2.3.8 Schedule Alignment

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

Figure 14.14 highlights the potential dependencies between the agile development schedule and the sourcing schedule.

Fig. 14.14

Schedule alignment

2.4 General Considerations

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.

2.4.1 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

Figure 14.15 shows some examples where this is applied to an AIoT Solution.

Fig. 14.15

Sourcing BOM SLAs

2.4.2 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. Figure 14.16 provides an overview.

Fig. 14.16

ACME smart shuttle SLAs for AI components

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.

2.4.3 Pricing Models

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.

2.4.4 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.?

Figure 14.17 shows an example of a spreadsheet containing key selection criteria.

Fig. 14.17

AIoT sourcing criteria

2.5 RFP Management

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.

2.5.1 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

• Budget

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 (Fig. 14.18).

Fig. 14.18

RFP document creation

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.

2.5.2 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.

2.5.3 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. Develo** 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.

2.6 Legal Perspective

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 (Fig. 14.19).

• 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?

• Philipp: I would say that is pretty straight forward. You offer your services most of the time via an app and for that app you need terms of use. We have standards that we are using for all different kinds of apps. And that platform provider has to comply with the relevant consumer protection laws that give very detailed requirements and that are renewed very often. In this year in Europe, we have some new consumer protection laws. You can also think about EULA’s (End User License Agreements). You can use that in addition to the terms of use. So the terms of use cover the usage of the service itself, and the EULA is for the software. I do not think that it’s necessary to use both.

• 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.

Fig. 14.19

Legal perspective – shuttle bus example