An critical assessment of the concepts used by Raji et al. (2020) and the derived hypotheses
Introduction
The second approach, ECCOLA from Vakkuri et al. (2021), is an iterative add-on process for the entire development process, with the goal of increasing ethical awareness during the development process and documenting it.
First concept: Operationalizing Principles through Atomic Aspects ECCOLA essentially operationalises seven principles by breaking the principles down into fine-grained subcategories, also referred to as atomic aspects (e.g., fairness is broken down in âaccessibilityâ and âstakeholder participationâ), and presenting the individual subcategories as cards. Every card in the resulting set of 21 cards is further subdivided into four parts, namely motivation, how to tackle the issue, a practical example, and a space for documentation purposes (leading to a trail of documentation, as explained in (PC 2)). Arguably, the most essential of the four parts is the âhow to tackle the issueâ, which is a set of questions with the goal of increasing ethical awareness by empowering the developer team to consider ethical issues through thinking about and answering the questions.
Evaluation Regarding the First Challenge: Time Pressure
- It is likely that important principles and sub-aspects of principles are missed. This is because there is not one true definition of one principle, e.g., fairness, but various contexts require an adjusted definition. Therefore, a different set of atomic aspects and open-ended questions are required to embrace the various contexts of the principles. A possible non-perception of aspects may lead to subsequent changes and, thus, to a disproportionate time effort, as in the âchange something, change everythingâ concept.
- This argument is further supported by the fact that this concept lacks methodological guidance. This means that, even if the principles, the atomic aspects, and the questions cover all the relevant ethical aspects, the lack of methodological guidance may still cause an incomplete implementation of the principles and, thus, lead to time-consuming changes later on.
- However, the low degree of methodological guidance also allows a certain degree of flexibility for developers regarding the effort for the project since developers are free to choose which principles to consider and in which granularity. This decreases the unavoidable time effort to a self-chosen minimum while increasing the autonomy of the developers.
Evaluation Regarding the Second Challenge: Conflicting Approaches
- The operationalisation of principles with open-ended questions aims to facilitate intra-team discussions. While this will certainly improve the ethical awareness of the team (Vakkuri et al., 2021), it does not correspond to the straightforward and explicit problem-solving approach preferred by developers and will likely cause frustration.
Evaluation Regarding the Third Challenge: Mushy Stuff
- Breaking principles down into subcategories makes them manageable through the associated reduction in complexity. However, translating subcategories into open-ended questions does not support an attempt to remove the abstract nature since this procedure does not consider the conflicting and context-specific nature of principles. Consequently, this approach remains at an open-ended and still relatively abstract level and increases the implementation effort for developers.
Hypothesis Derivation
To conclude this evaluation, it is evident that this concept does not support developer teams in all three challenges. This is mainly because of the inherent approach of using only a fixed set of principles, subcategories, and open-ended questions and the lack of methodological guidance, which is likely to result in a lack of specificity and a clash with the preferred working style of developer teams. Consequently, this thesis hypothesises that (H3) operationalising ethical principles using atomic aspects and open-ended questions is generally not perceived as useful for developing AI systems.
Second Concept: Model Agnostic Add-On Process The ECCOLA method is also considered agnostic in the sense that it can be deployed to any existing development method through an iterative add-on design that follows three steps. The developer teams choose all relevant cards from the set of 21 cards for the iterations (âprepareâ). In the second step (âreviewâ), the chosen cards are kept on hand to increase awareness and document the actions taken by the team to implement a specific ethical issue. Thus, in this step, potential ethical issues are pointed out without the provision of mitigation strategies, which further detaches ECCOLA from one particular mitigation method and emphasises the modelâs agnostic nature. In the last step (âevaluateâ), the conducted actions are evaluated to ensure that all necessary actions were taken. These three steps are performed during every iteration until the project is completed.
Evaluation Regarding the First Challenge: Time Pressure
- The abstract nature leads to a streamlining effort if developer teams aim to implement the method to the primary development process as frictionless as possible, meaning that as many synergy effects as possible are leveraged between the primary method and the model-agnostic method.
- However, the implementation effort is likely to be low since this concept can be used directly and does not need any adaption.
Evaluation Regarding the Second Challenge: Conflicting Approaches
- The method must necessarily be designed iteratively to be model agnostic. This not only correlates with AI system development, but also with the experience of developer teams by being a known concept that matches the training of developers. However, designing a process as an âadd-onâ could potentially tempt developer teams to omit the associated tasks under time pressure. This is specially concerning in the AI development context, in which time pressure is a factor (Beckert, 2021).
Hypothesis Derivation
To conclude this evaluation, the concept does support developer teams with the first two challenges, because of the low implementation effort and the iterative and, thus, matching working style of developers. However, the concept is limited since it may be fundamentally prone to being omitted due to time pressure. The simplicity of omitting these tasks is particularly disadvantageous for high-risk projects, due to the associated possibly harmful outcome. Consequently, this thesis hypothesises that (H4) using a model-agnostic process designed as an iterative add-on process is generally not perceived as useful for developing AI projects.