AI Stakeholders
INTRODUCTION
AI systems are much more complex than traditional software. The technology we develop, the systems we construct, the processes we use and the legal infrastructure we underpin it with must reflect this complexity.
The first stage in this process is providing a vocabulary to help describe the different parties involved. Only when we have the language to describe the key actors, do we have the tools to describe the ensemble system and the technical and legal relations between them.
AI COMPONENT AND ACTOR ANALYSIS
The following diagram illustrates the key actors in an AI system.
An AI system typically consists of multiple components, one or more of which might implement an AI algorithm. The AI algorithm(s) might have been invented by the AI system implementor or by a third party, the AI inventor. AI algorithms will typically either be implemented by the AI system implementor or by a third party, the AI component implementor. The implementation might be covered by copyright, subject to a software license, or other forms of intellectual property protection, such as patents (please see, for example, the recent court High Court ruling relating to patenting neural networks1).
Component: AI Algorithm
This is the abstract description of the algorithm that embodies the AI system. This potentially could both the training and operational algorithm if they can be considered separately.
The algorithm is usually defined abstractly. It could take the form of an academic paper, or possibly a patent.
Ideally the algorithm is described ins sufficient detail for an AI developer to implement a functioning system.
Actor: AI Algorithm inventor
This is the individual(s) who are the recognised originators of the algorithm
Component: AI Code
This is the code base or library that embodies the algorithm, created by the AI inventor.
This code base is usually in a single programming language and will often sit within a code repository (e.g. GitHub).
This code must be “compilable” into a functioning version of the AI algorithm.
Variants
The code base can be licensed under different terms. The most coarse-grained categories are:
- Open – free for commercial use: code is made available to developers under an open-source permissive licence.
- Open – close for commercial use: code is made available to developers under an open-source licence, which somehow restricts the commercial use of the code, or places undue obligations on the developer.
- Closed – cloud: the code is only available behind a cloud-based system. The code cannot be inspected or used locally by the developer.
- Closed – binary: the code can use used locally by the developer as a licensable binary.
- Closed – source available: the source code is available to the developer under commercial terms.
ACTOR: AI CORE DEVELOPER
This is the legal entity (company or individuals), that owns the copyright of the AI code that has been developed. Usually they will be the originating developer of the code.
Component (Data): AI Training Data
This is the physical data on which the AI code will be trained.
For many use cases there will be multiple data sets.
This data may be accessible on the cloud, or it may be a private data sets.
The ownership of this data and the rights the AI trainer has to use this data is a contentious issue.
Component (Data): AI Training Parameters
These are the configuration parameters that will be used to train the AI system.
They parameters the use of the algorithm, as it is applied to the training data. The training parameters will determine, under what criteria the training is to happen and when it is deemed complete.
Component (System): AI Training Machines
This is the physical machine (hardware) and base software (operating system and system management application) used to train the AI system.
This system could be self hosted (owned by the AI trainer) or more typically cloud hosted. If cloud hosted the AI trainer is essentially leasing hardware and software to train the system.
Usually there will be more than one physical machine involved in the training.
Actor: AI trainer
This is the legal entity (company or individuals), who take responsibility for training the AI system. Typically, this is an expensive process.
The result of the training process are the operations parameters. This can be many millions or billions of configurations (weights in the case of neural networks)
Component: AI Operational parameters
The AI Operational parameters are the reductive result of the training system. It is the operational configuration parameters.
Simplistically: AI params = AI Code ( AI training data, AI training parameters)
Component: AI trained system
The AI trained system is the holistic result of the training process.
Simplistically: AI Code + Operational Parameters + Operational Machines = Deterministic AI system
Component (Data): Validation data
Good AI practice requires a clean separation of training and validation data to avoid overtraining.
On many systems the data owner is the same as training data and the separation is weak. But for the purpose of this stakeholder analysis, we will assume a clear separation.
Actor: AI Validator
This is the legal entity (company or individuals), who take responsibility for validating the AI system. This is essential and approval process, that will happen before the public release of a new visions AI operational system
Component (data): AI validation metrics
These are a set of KPIs that measure the performance of the operational AI system, within the context of the validation data.
Component (system): Validated AI system
This is a trained AI system that has passed the validation criteria and presumably released as a stable version.
Actor: AI system owner
This is the legal entity (company or individuals), makes a versioned, approved AI system available for use (under any of the licence variants discussed earlier).
In the case of cloud-based AI systems, this will be the organisation that provides access to the core AI system and authenticates
Component (system): Released AI system
This is essentially one of the validated systems the system owner has decided to formally release.
Actor: AI application developer owner
This is the legal entity (company or individuals) that makes use of the API and creates user focused applications built on the AI systems capabilities.
The application may make use of many distinct AI systems to develop the entire application
Sometimes the AI system owner may release their own suite of AI applications.
Component (system): Released AI application
This is a system description of the full AI application that is made available to end users.
Ideally this description includes all critical dependencies.
Actor: AI user
This is the legal entity (company or individuals) that uses the AI application.
AI Legal Relations
The following provides a high level description of the primary legal relations that exist between the AI actors.
This is critical to understanding legal liability issues.
AI Inventor > AI Core Developer
The AI inventor may have asserted patents on his invention.
The AI core developer may be infringing these patents.
The AI inventor may commercially licence his IP to the AI developer.
(Note the AI core developer may also be infringing patents held by third parties, not the primary AI developer)
AI Core Developer > AI Trainer
The AI trainer will need to licence the code from the AI core developer.
This could be a commercial licence, or the core developer may have released his code under an open source licence.
This licence will come with defined rights and defined obligations, depending on the form of the licence
AI Machine owner > AI Trainer
The AI trainer will commercially licence the software/hardware from the machine owner.
AI Data owner > AI Trainer
The AI data owner should licence the training data to the AI trainer for a purpose.
Where no licence explicitly exists the trainer should be confident that an implicit licence exists.
The purpose is complex. The AI trainer’s initial purpose is probably to host a generic API capability. However multiple applications may make use of the API hence the relationship is transitive and one to many.
AI Trainer > AI Validator > AI System owner
In many cases these roles may be played by the same legal entity, but the roles are indeed different.
The process is essentially a controlled, quality assaulted versioned release process.
A legal relation may exist between these actors if they are different legal entities and a licence/service is provided.
The process is important legally as the “release version” is critical in unpicking the liabilities.
AI System owner > AI application developer
In many cases these roles may be played by the same legal entity, but the roles are indeed different.
The process is essentially a controlled, quality assaulted versioned release process.
A legal relation may exist between these actors if they are different legal entities and a licence/service is provided.
The process is important legally as the “release version” is critical in unpicking the liabilities.
AI application developer > AI user
Finally, a contractual agreement (a licence) will typically exist between the application developer and the AI user.
Notes
The above breakdown is indicative only. Real world scenarios can get more complex very quickly. For example, a real-world AI developer (e.g. mobile application developer), may have a publisher and this published game may be mediated through one or more app stores. Transitive legal relationships will exist at an even fine grain in these type scenarios. However, this course breakdown still helps in understanding the overarching relationships.