AI Governance Frameworks

Personal data taxonomies differentiate between different categories of personal data. ISO/IEC 19441 (2017) distinguishes five categories, or "states," of data identifiability:

• Identified data:  data that can be unambiguously associated with a specific person because they contain personally identifiable information
• Pseudonymized data:  data for which aliases substitute all personal identifiers. The alias assignment is such that it cannot be reversed by reasonable efforts except for the party that performed the assignment
• Unlinked pseudonymized data:  data for which aliases irreversibly erase or substitute all personal identifiers; linkage cannot be re-established by reasonable efforts, including by the party that performed the assignment
• Anonymized data:  data that are not linked to attributes that can be altered (i.e., attributes' values are randomized or generalized) in such a way that there is a reasonable level of confidence that a person cannot be identified, directly or indirectly, by the data alone or in combination with other data
• Aggregated data:  statistical data that do not contain individual-level entries and are combined with information about enough different persons that individual-level attributes are not identifiable

Different AI models can exhibit different degrees of transparency and explainability. Among other things, this entails determining whether meaningful and easy-to-understand information is made available to:

• Make stakeholders aware of their interactions with AI systems, including in the workplace
• Enable those affected by an AI system to understand and challenge the outcome and how it was produced by the AI model (e.g., by setting the weights of the AI model's components)

Data appropriateness (or qualification) involves defining criteria to ensure that the data are appropriate for use in a project, fit for purpose, and relevant to the system or process following standard practice in the industry sector. For example, in clinical trials to evaluate drug efficiency, criteria for using patient data must include patients' clinical history – previous treatments, surgery, etc. Data quality also plays a key role in AI systems, as do the standards and procedures to manage data quality and appropriateness.

An AI application or system applies standard criteria or industry-defined criteria to assess:

• Data appropriateness:  data are appropriate for the purpose for which they are to be used, following standard practice in the industry sector
• Sample representativeness:  selected variables and training or evaluation data accurately depict/reflect the population in the AI system environment
• Adequate sample size:  sample size displays an appropriate level of granularity, coverage, and sufficiency of data
• Completeness and coherence of sample:  sample is complete, with minimal missing or partial values; outliers must not affect the quality of data
• Low data "noise":  data is infrequently incorrect, corrupted, or distorted (e.g., intentional or unintentional mistakes in survey data, data from defective sensors)

The following list draws on the data provenance categorization made by Abrams (Abrams, 2014[16]) and the OECD (OECD, 2019[15]) of data collected with decreasing levels of awareness. It should be noted that these categories can overlap, and most systems will combine data from different sources. Here, we broaden the original categorization that focused on personal data to also cover expert input and non-personal data, as well as synthetically generated data.

• Expert input:  human knowledge that is codified into rules and structures such as ontologies (concepts and properties), knowledge graphs, and analytical functions (e.g., the objective function or rewards an AI model will optimize for)
• Provided data:  data that originate from actions by individuals or organizations that are aware of the data being provided; they include "initiated" (e.g., a license application), "transactional" (e.g., bills paid), and "posted" (e.g., social networking posts) data
• Observed data:  collected through human observation of a behavior or activity or using automated instruments or sensors; examples include website visitor provenance and browsing patterns observed by a website administrator; observed data include sounds, scents, temperature, GPS position, and soil acidity; observed data about individuals can be "engaged" (e.g., voluntarily accepting cookie tracking on a website), "unanticipated" (e.g., the tracking of seconds spent looking at a specific image online), or "passive" (e.g., CCTV images of individuals)
• Synthetic data:  usually generated by computer simulations, including data collected through reinforcement learning; synthetic data allow for the simulation of scenarios that are difficult to observe or replicate in real life (e.g., a car accident) or are otherwise too expensive to collect at scale (e.g., millions of miles of driving time for self-driving cars); they include most applications of physical modeling, such as music synthesizers or flight simulators; AI system output of synthetic data approximates reality but is generated algorithmically
• Derived data:  data taken from other data to become a new data element; derived data include computational (e.g., a credit score) and categorical data (e.g., age group of a buyer); they can be inferred (e.g., the product of a probability-based analytic process such as a fraud score or risk of accident) or aggregated (e.g., abstracted from more fine-grained data); proprietary data are often characterized as derived data

• Valid and reliable (e.g., p. 27)
• Accountable and transparent (e.g., p. 27)
• Fair (e.g., p. 28)
• Safe (e.g., p. 32)
• Secure and resilient (e.g., p. 34)
• Privacy-enhanced (e.g., p. 38)
• Explainable and interpretable (e.g., p. 43)

A fair amount of detail is given to mitigating risks associated with data, such as bias, data privacy, and transparency. Other risks, such as to well-being and society as covered under People & Planet have far less detail.

Even among the most detailed practices outlined, relatively little of this would be immediately usable to mitigate risks. The content is more descriptive than procedural.

• Data Storage & Operations (e.g., p. 36)
• Data Security (e.g., p. 38)
• Data Quality (e.g., p. 39)
• Data Integration & Interoperability (e.g., p. 40)
• Data Modeling & Design (e.g., p. 40)
• Metadata (e.g., p. 41)

For each characteristic under Data & Input, many elements and key terms are identified with details. However, the amount of detail varies widely.

Responsibilities related to data collection and checking Data Quality are practical, but most other practices are more descriptive than procedural.

Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues.

• GOVERN 6.1:  policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights
• GOVERN 6.2:  contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk

Impacts on individuals, groups, communities, organizations, and society are characterized.

• MAP 5.1:  likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented
• MAP 5.2:  practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented

Mechanisms for tracking identified AI risks over time are in place.

• MEASURE 3.1:  approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts
• MEASURE 3.2:  risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available
• MEASURE 3.3:  feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metric

AI risks based on assessments and other analytical output from the MAP and MEASURE functions are prioritized, responded to, and managed.

• MANAGE 1.1:  a determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed
• MANAGE 1.2:  treatment of documented AI risks is prioritized based on impact, likelihood, and available resources or methods
• MANAGE 1.3:  responses to the AI risks deemed high priority, as identified by the MAP function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting
• MANAGE 1.4:  negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented

• Valid and reliable (i.e., p. 13)
• Safe (e.g., p. 14)
• Secure and resilient (e.g., p. 15)
• Accountable and transparent (e.g., p. 15)
• Explainable and interpretable (e.g., p. 16)
• Privacy-enhanced (e.g., p. 17)
• Fair (e.g., p. 18)

Includes an introduction to the scope of each risk with key terms, roles, and responsibilities. Actions and outcomes for four core functions are outlined in sequence.

A thorough range of actions and outcomes in a clear, logical sequence is provided for each function, but their lack of detail limits their direct implementability. The AI RMF Playbook is an especially useful supplementary resource for this purpose.¹²

• Data Quality (e.g., p. 27)
• Data Security (e.g., p. 30)

There is minimal explicit focus on Data Management practices, although Data Quality and Data Security practices are implied in relation to specific risks.

Most of the relevant guidance offered is in the overview for risks rather than as a practice in the four core functions.

Where explainability cannot be practicably achieved given the state of technology, organizations can consider documenting the repeatability of results produced by the AI model. Repeatability refers to the ability to consistently perform an action or make a decision, given the same scenario. While repeatability (of results) is not equivalent to explainability (of algorithm), some degree of assurance of consistency in performance could provide AI users with a larger degree of confidence.

Helpful practices include:

• Conducting repeatability assessments for commercial deployments in live environments to ensure that deployments are repeatable
• Performing counterfactual fairness testing; counterfactual fairness testing ensures that a model's decisions are the same in both the real world and in a counterfactual world where attributes deemed sensitive (such as race or gender) are altered
• Assessing how exceptions can be identified and handled when decisions are not repeatable, e.g., when randomness has been introduced by design
• Ensuring exception handling is in line with organization's policies; in this regard, it may be helpful to use AI models that can recognize when a given set of facts contains new variables not previously considered and can highlight these new variables to a human
• Identifying and accounting for changes over time to ensure that models trained on time-sensitive data remain relevant

An AI model is considered to be traceable if (a) its decisions and (b) the datasets and processes that yield the AI model's decision – including those of data gathering, data labeling, and the algorithms used – are documented in an easily understandable way. The former refers to the traceability of AI-augmented decisions, while the latter refers to traceability in model training. Traceability facilitates transparency and explainability and is also helpful for other reasons.

First, the information might also be useful for troubleshooting or investigating how the model was functioning or why a particular prediction was made. Second, the traceability record (in the form of an audit log) can be a source of input data that can be used as a training dataset in the future.

Practices that organizations may consider to promote traceability include:

• Building an audit trail to document the model training and AI-augmented decision
• Implementing a black box recorder that captures all input data streams;for example, a black box recorder in a self-driving car tracks the vehicle's position and records when and where the self-driving system takes control of the vehicle, suffers a technical problem, or requests the driver to take over the control of the vehicle
• Ensuring that data relevant to traceability are stored appropriately to avoid degradation or alteration and retained for durations relevant to the industry

Organizations are encouraged to understand and address factors that may affect the quality of data, such as:

• The accuracy of the dataset, in terms of how well the values in the dataset match the true characteristics of the entities described by the dataset
• The completeness of the dataset, both in terms of attributes and items
• The veracity of the dataset, which refers to how credible the data is, including whether the data originated from a reliable source
• How recently the dataset was compiled or updated
• The relevance of the dataset and the context for data collection, as it may affect the interpretation of and reliance on the data for the intended purpose
• The integrity of the dataset that has been joined from multiple datasets which refers to how well extraction and transformation have been performed
• The usability of the dataset, including how well the dataset is structured in a machine-understandable form
• Human interventions (e.g., if any human has filtered, applied labels, or edited the data)

• Fair (e.g., p. 38)
• Explainable and interpretable (e.g., p. 44)
• Valid and reliable (e.g., p. 46)
• Secure and resilient (e.g., p. 47)
• Accountable and transparent (e.g., p. 48)

Trustworthy AI features are introduced with moderate levels of detail on average but with high variance between them; explainability has more than twice as much coverage as robustness.

Some specific actions or steps are included for most of the trustworthiness features covered. A brief real-world case study on Pymetrics managing bias and guidance on using the probability-severity of harm matrix are also offered.

• Data Quality (e.g., p. 38)

Moderate coverage of Data Quality considerations is offered, such as data lineage, keeping a data provenance record, and reviewing dataset quality.

Guidance is largely given within the context of model development and is descriptive rather than procedural. However, the Data Quality considerations covered would likely apply to AI deployment and operation.

In machine learning, a model's accuracy is the proportion of examples for which it generates a correct output. This performance measure is sometimes characterized conversely as an error rate or the fraction of cases for which the model produces an incorrect output.

As a performance metric, accuracy should be a central component to establishing and enhancing the approach to safe AI. Specifying a reasonable performance level for the system may also often require refining or exchanging the measure of accuracy. For instance, if certain errors are more significant or costly than others, a metric for total cost can be integrated into the model so that the cost of one class of errors can be weighed against that of another.

The transparency of AI systems can refer to several features, including their inner workings and behaviors and the systems and processes that support them. An AI system is transparent when it is possible to determine how it was designed, developed, and deployed.

This can include, among other things, a record of the data used to train the system or the parameters of the model that transform the input (e.g., an image) into an output (e.g., a description of the objects in the image). However, it can also refer to broader processes, such as whether there are legal barriers that prevent individuals from accessing information that may be necessary to understand fully how the system functions (e.g., intellectual property restrictions).

Effective bias mitigation begins at the commencement of data extraction and collection processes. Both the sources and instruments of measurement may introduce discriminatory factors into a dataset. When incorporated as inputs in the training data, biased prior human decisions and judgments – such as prejudiced scoring, ranking, interview data, or evaluation – will become the 'ground truth' of the model and replicate the bias in the outputs of the system in order to secure discriminatory non-harm, as well as ensuring that the data sample has optimal source integrity. This involves securing or confirming that the data-gathering processes involve suitable, reliable, and impartial sources of measurement and sound methods of collection.

Responsible Data Management ensures that the team has been trained on managing data responsibly and securely, identifying possible risks and threats to the system, and assigning roles and responsibilities for how to deal with these risks if they were to occur. Policies on data storage and public dissemination of results should be discussed within the team and with stakeholders and clearly documented.

Each Party shall provide that the controller, and, where applicable, the processor, takes appropriate security measures against risks such as accidental or unauthorized access to, destruction, loss, use, modification, or disclosure of personal data. Each Party shall provide that the controller notifies, without delay, at least the competent supervisory authority within the meaning of Article 15 of this Convention of those data breaches which may seriously interfere with the rights and fundamental freedoms of data subjects.

Each Party shall provide that data processing can be carried out based on the free, specific, informed, and unambiguous consent of the data subject or some other legitimate basis laid down by law. The data subject must be informed of risks that could arise in the absence of appropriate safeguards. Such consent must represent the free expression of an intentional choice, given either by a statement – which can be written, including by electronic means, or oral – or by a clear affirmative action that clearly indicates in this specific context the acceptance of the proposed processing of personal data. Therefore, silence, inactivity, or pre-validated forms or boxes should not constitute consent.

No undue influence or pressure – which can be of an economic or other nature – whether direct or indirect, may be exercised on the data subject, and consent should not be regarded as freely given where the data subject has no genuine or free choice or is unable to refuse or withdraw consent without prejudice. The data subject has the right to withdraw their consent at any time (which is to be distinguished from the separate right to object to processing).

• Safe (e.g., p. 284)
• Fair (e.g., p. 285)
• Explainable and interpretable (e.g., p. 286)
• Valid and reliable (e.g., p. 285)
• Secure and resilient (e.g., p. 284)
• Accountable and transparent (e.g., p. 285)
• Privacy-enhanced (e.g., p. 288)

Substantial depth is offered on what human rights, democracy, and rule of law specifically entail (e.g., p. 23-46) and how potential adverse impacts (risks) can be identified, assessed, and generally mitigated (e.g., p. 238-250). However, no guidance is given on how specific risks may be mitigated on the basis that 'specifying the goals [of an assurance case for mitigating risks] and operationalizing the relevant properties is highly contextual.'

Extensive step-by-step instructions, corresponding resources, and illustrative examples are offered to identify, evaluate, and mitigate AI risks. Although this guidance thoroughly supports businesses in conducting their own risk assessments, the lack of detailed guidance on practices or risk mitigation significantly undermines the degree to which businesses can directly use this framework to mitigate risks in practice.

• Data Quality (e.g., p. 287)
• Data Security (e.g., p. 288)

Although Data Management practices are referred to or implied throughout the framework, most explicit Data Management practices are only explored briefly as goals for the framework.

The most practical guidance offered is for identifying risks over the data lifecycle as part of a preliminary context-based based analysis for which there is a step-by-step template (e.g., p. 106). Most of the guidance associated with Data Quality and Data Security practices isn't focused on actions.

Design the system, including, when possible, the system UX, features, reporting functions, and educational materials, so that stakeholders identified in requirement T1.1 can:

• Understand the system's intended uses
• Interpret relevant system behavior effectively, i.e., in a way that supports informed decision-making
• Remain aware of the possible tendency to over-rely on the system's outputs ("automation bias")

Publish information for customers about: 

• Identified demographic groups for which performance may not meet any target minimum performance level
• Any remaining performance disparities between identified demographic groups that may exceed the target maximum
• Any justifiable factors that account for these performance levels and differences
• When the system is a platform service made available to external customers or partners, include this information in the required Transparency Note.

For each case of a predictable failure likely to have an adverse impact on a stakeholder, document the failure management approach:

• When possible, design and build the system to avoid this failure; describe the design solution; estimate the time range for resolving predictable failures for each designed solution or indicate that the design will prevent the failure
• When a failure cannot be prevented by design, build a fallback option that may be used when this failure occurs; describe the fallback option and document the estimated time required to invoke and use the fallback option
• Provide training and documentation for stakeholders accountable for system oversight that supports their resolution of the failure; describe the documentation and training

Microsoft AI systems are subject to appropriate Data Governance and Management practices.

• A4.1 Define and document data requirements with respect to the system's intended uses, stakeholders, and the geographic areas where the system will be deployed. Document these requirements in the Impact Assessment.
• A4.2 Define and document procedures for collecting and processing data, including annotation, labeling, cleaning, enrichment, and aggregation, where relevant.
• A4.3 If you plan to use existing data sets to train the system, assess the quantity and suitability of available data sets the system will need in relation to the data requirements defined in A4.1. Document this assessment in the Impact Assessment.
• A4.4 Define and document methods for evaluating data to be used by the system against the requirements defined in A4.1.
• A4.5 Evaluate all data sets using the methods defined in requirement A4.4. Document the results of the evaluation.

• Safe (e.g., p. 21)
• Fair (e.g., p. 13)
• Explainable and interpretable (e.g., p. 9)
• Valid and reliable (e.g., p. 24)
• Secure and resilient (e.g., p. 23)
• Accountable and transparent (e.g., p. 9)

Several pages of instructions related to most risks covered, including several goals for which a series of requirements, tools, and practices are identified. However, much of this specifically relates to model training and testing rather than deployment or operation, and very little guidance is offered on understanding risks themselves.

The format of guidance is nearly entirely practice-focused, with specific targets and actions being outlined in sequence.

• Data Governance (e.g., p. 7)
• Data Quality (e.g., p. 13)

Nearly all references to data explicitly relate to model training or testing. Some guidance on Data Governance is relevant across the AI lifecycle.

The relevant guidance on Data Governance offers actionable, though brief, instructions on governing data across the AI lifecycle.

Continuously monitor and evaluate the three critical components of your workloads:

• The Input:  because models often require vast amounts of data for training and analysis, you need to validate that the type of data ingested is aligned to the model's goals and outcomes; establish audit mechanisms to understand adherence to the established control framework
• The Model:  certify that the users understand the acceptable usage of AI in alignment with organizational policies; implement policies and controls to validate that the organization understands where it is appropriate to use AI and where it is not; establish audit mechanisms to identify how the model uses data and where AI capabilities are used within the organization
• The Output:  establish acceptable usage criteria for the output, paying attention to where the data may be reused or reintroduced to additional AI models; establish discovery or audit mechanisms to review output data to validate that generated data cannot be used to infer or recreate sensitive or regulated data; create mechanisms for validating the authenticity and origin of the output where trustworthiness is paramount, such as medical diagnoses

Embed explainability by design into your AI lifecycle where possible and establish practices to recognize and discover both intended and unintended biases. Consider using the right tools to help you monitor the status quo and inform risk. Use best practices that enable a culture of responsible use of AI and build or use systems to enable your teams to inspect these factors. While this cost accumulates before the algorithms reach the production state, it pays off in the mid-term by mitigating damage.

Especially when you are planning to build, tune, or use a foundation model, inform yourself about new emerging concerns such as hallucinations, copyright infringement, model data leakage, and model jailbreaks. Ask if and how the original vendor or supplier has taken an RAI approach to the development, as this trickles down directly into your business case.

Automate data flows for AI development. As data is a first-level citizen of any AI strategy and development process, data engineering becomes significantly more important and cannot be an afterthought but a readily available capability within your organization and teams.

As data is used to actively shape the behavior of an AI system, engineering it properly is decisive. Data preparation tools are an essential part of the development process. While the practice itself is not changing fundamentally, its importance and need for continuous evolution are rising. Consider integrating your data pipelines and practice directly into your AI development process and model training through streamlined and seamless pre-processing. Consider transitioning from traditional Extraction, Transformation, and Load (ETL) processes to a zero-ETL approach.

With such an approach to data engineering, you reduce the friction between your data and AI practices. Enable and empower your AI team to combine data from multiple sources into a unified view as a self-service capability. Couple this with visualization tools and techniques that help your AI and data teams explore and understand their data visually.

When possible, focus on making your data accurate, complete, and reliable. Design data models or transformations as part of your workflows, specifically for machine learning – normalized, consistent, and well-documented – to facilitate efficient data handling and processing. This significantly improves the performance of your AI applications and reduces friction in the development process.

As data movement is becoming more important for AI systems, harden your architecture for data-movement requirements:

• Inside-Out:  data initially aggregates in the data lake from various sources – structured like databases and well-structured spreadsheets or unstructured like media and text; a subset is then moved to specialized stores for dedicated analytics, such as search analytics or building knowledge graphs
• Outside-In:  data starts in specialized stores suited to specific applications; for example, to support a game running in the cloud, the application might use a specific store to maintain game states and leaderboards; this data is later moved into a data lake where more comprehensive analytics can be conducted to enhance gaming experiences
• Around the Perimeter:  this involves moving data between specialized data stores, such as from a relational database to a NoSQL database, to serve specific needs such as reporting dashboards

• Fair (e.g., p. 39)
• Explainable and interpretable (e.g., p. 28)
• Valid and reliable (e.g., p. 37)
• Secure and resilient (e.g., p. 40)
• Accountable and transparent (e.g., p. 42)
• Privacy-enhanced (e.g., p. 42)

Under the Security perspective, considerable detail is offered on various risks. However, this detail is dominantly relevant to model training. Outside of this, detailed coverage is very limited.

Guidance under the Security perspective is highly practical, but, as corresponding with our assessment of depth, guidance outside of this is largely limited to basic references and descriptions.

• Data Quality (e.g., p. 26)
• Metadata (e.g., p. 26)
• Data Storage & Operations (e.g., p. 32)
• Data Architecture (e.g., p. 33)
• Data Warehousing & Business Intelligence (e.g., p. 34)
• Data Modeling & Design (e.g., 36)
• Data Integration & Interoperability (e.g., p. 36)
• Data Security (e.g., p. 44)

Although the amount of detail offered on any one area of Data Management varies greatly, much of the content from the Governance, Platform, and Security sections explains how Data Management connects to AI with a high level of specificity.

There's a mix of descriptive and procedural guidance. The document is not formatted with direct practical application in mind but nonetheless specifies many actions that can be taken.

Develop an understanding of threats that matter for AI usage scenarios, the types of AI used, etc. Organizations that use AI systems must understand the threats relevant to their specific AI usage scenarios. This includes understanding the types of AI they use, the data they use to train AI systems, and the potential consequences of a security breach. By taking these steps, organizations can help protect their AI systems from attack.

Prepare to respond to attacks against AI and issues raised by AI output. Organizations that use AI systems must have a plan for detecting and responding to security incidents and mitigating the risks of AI systems making harmful or biased decisions. By taking these steps, organizations can help protect their AI systems and users from harm.

Specifically focusing on AI output for gen AI prepare to enforce content safety policies. Gen AI is a powerful tool for creating a variety of content, from text to images to videos. However, this power also comes with the potential for abuse. For example, gen AI could be used to create harmful content, such as hate speech or violent images. To mitigate these risks, it is important to prepare to enforce content safety policies.

Adjust your abuse policy and incident response processes to AI-specific incident types, such as malicious content creation or AI privacy violations. As AI systems become more complex and pervasive, it is important to adjust your abuse policy to deal with abuse cases and adjust your incident response processes to account for AI-specific incident types. These types of incidents can include malicious content creation, AI privacy violations, AI bias, and general abuse of the system.

Conduct Red Team exercises to improve safety and security for AI-powered products and capabilities. Red Team exercises are a security testing method where a team of ethical hackers attempts to exploit vulnerabilities in an organization's systems and applications. This can help organizations identify and mitigate security risks in their AI systems before malicious actors can exploit them.

Stay on top of novel attacks, including prompt injection, data poisoning, and evasion attacks. These attacks can exploit vulnerabilities in AI systems to cause harm, such as leaking sensitive data, making incorrect predictions, or disrupting operations. By staying up-to-date on the latest attack methods, organizations can take steps to mitigate these risks.

Identify the list of AI security capabilities focused on securing AI systems, training data pipelines, etc. AI security technologies can protect AI systems from a variety of threats, including data breaches, malicious content creation, and AI bias. Some of these technologies include traditional data encryption, access control, and auditing, which can be augmented with AI and newer technologies that can perform training data protection, as well as model protection.

Use AI defenses to counter AI threats, but keep humans in the loop for decisions when necessary. AI can be used to detect and respond to AI threats, such as data breaches, malicious content creation, and AI bias. However, humans must remain in the loop for important decisions, such as determining what constitutes a threat and how to respond. This is because AI systems can be biased or make mistakes, and human oversight is necessary to ensure that AI systems are used ethically and responsibly.

Use AI to automate time-consuming tasks, reduce toil, and speed up defensive mechanisms. Although it seems like a more simplistic point in light of the uses of AI, using AI to speed up time-consuming tasks will ultimately lead to faster outcomes. For example, it can be time-consuming to reverse engineer a malware binary. However, AI can quickly review the relevant code and provide an analyst with actionable information. Using this information, the analyst could then ask the system to generate a YARA rule looking for these actions. In this example, there is an immediate reduction of toil and faster output for the defensive posture.

• Safe (e.g., p. 6)
• Secure and resilient (e.g., p. 4)
• Privacy-enhanced (e.g., p. 5)

Guidance for secure and resilient AI is offered in moderate to high depth. Various other risks, however, are mentioned only as examples or in a single substantive sentence.

The guidance related to secure and resilient AI is action-focused, but much of it is generic, and there's no clear sequence of actions.

• Data Governance (e.g., p. 5)
• Data Quality (e.g., p. 287)
• Data Security (e.g., p. 5)

The primary guidance on Data Management relates to an overview of Data Governance for training data. Very limited guidance is otherwise offered.

The guidance on Data Governance is largely descriptive. Only one action-based piece of guidance for Data Security is offered.

• NIST:  GOVERN 6
• NIST:  MAP 5
• NIST:  MEASURE 3
• NIST:  MANAGE 1

• Microsoft:  failures and remediations
• AWS:  security assurance
• Google:  extend detection and response
• Google:  adjust controls
• Google:  automate defenses

• OECD:  model transparency and explainability
• Singapore:  repeatability
• ATI:  transparency
• Microsoft:  system intelligibility for decision-making
• AWS:  responsible use of AI

• Singapore:  repeatability
• ATI:  accuracy and performance metrics
• Microsoft:  system intelligibility for decision-making
• AWS:  security assurance

• OECD:  model transparency and explainability
• Singapore:  traceability
• ATI:  transparency
• Microsoft:  quality of service

• OECD:  identifiability of personal data
• Microsoft:  system intelligibility for decision-making
• AWS:  security assurance

• ATI:  source integrity and measurement accuracy
• Microsoft:  system intelligibility for decision-making
• AWS:  responsible use of AI

• Microsoft:  failures and remediations

• ATI:  responsible Data Management

• OECD:  Data Quality and appropriateness
• OECD:  the provenance of data and input
• Singapore:  Ensuring Data Quality
• AWS:  Data Engineering

• ATI:  Data Security
• ATI:  consent (or legitimate basis) for processing

• OECD:  the provenance of data and input

• Microsoft:  Data Governance and management

• AWS:  Data Engineering

• AWS:  Data Engineering

• AWS:  Data Architecture