AIGP Sample Questions & Answers

This statement is false. The 'GOVERN' function is a cross-cutting function that applies throughout the AI lifecycle. It is about cultivating a risk management culture, establishing processes, and providing the overarching structure for risk management. Post-deployment monitoring and measurement are primarily addressed within the 'MANAGE' and 'MEASURE' functions of the NIST AI RMF.

This is an example of post-hoc explainability. The AI model itself is a 'black box' (a complex deep learning system). Techniques like SHAP or LIME are applied after the model makes a prediction to approximate and explain its behavior for a specific instance. Intrinsic explainability, by contrast, comes from using models that are inherently simple and understandable, such as linear regression or decision trees. Global explainability describes the model's overall behavior, while local explainability (which SHAP provides) explains individual predictions.

While all options are considerations, the most significant governance risk is data privacy. Customer service transcripts are rich with PII (names, addresses, account numbers). Fine-tuning on this data creates a high risk that the model will 'memorize' this sensitive information and could potentially reveal it in responses to other users' queries. This is a major privacy breach and liability issue. Increased cost is a business concern, model collapse is a technical risk, and vendor lock-in is a strategic risk, but the PII disclosure risk is the most acute and immediate governance failure.

The risk mitigation hierarchy, a standard concept in safety and risk management, prioritizes controls from most to least effective. The highest priority is always elimination—designing the system so the hazard cannot occur in the first place. If elimination is not possible, the next steps are substitution, engineering controls, administrative controls, and finally, personal protective equipment (or its equivalent). Therefore, the first consideration should be if the risk can be designed out of the system entirely.

According to Annex III of the EU AI Act, AI systems intended to be used as safety components in the management and operation of road traffic are classified as high-risk. Optimizing traffic light timing directly impacts road safety, and therefore falls into this category. It is not prohibited (like social scoring), does not merely have transparency obligations (limited-risk), and is not considered minimal risk due to its direct impact on public safety.

The EU AI Act (Article 11 and Annex IV) specifies detailed requirements for technical documentation. These include descriptions of the AI system, its data, performance metrics, risk management system, and instructions for use. However, it does not mandate the inclusion of personal information like the CVs of the development team. The focus is on the system's characteristics and governance, not the personal qualifications of the individuals who built it.

Robustness refers to an AI system's ability to maintain its level of performance and safety under a variety of circumstances, including unexpected or adversarial inputs. The 'red team's' discovery of a crafted input that causes harmful output is a classic example of a lack of robustness against adversarial attacks. While accuracy (correctness on normal inputs) and interpretability (understanding decisions) are important, this specific failure mode directly relates to the model's inability to handle malicious inputs safely.

Meeting the 'right to an explanation' requires a multi-faceted approach. Using intrinsically interpretable models is the most direct way to ensure decisions can be explained. For complex 'black box' models, implementing post-hoc explanation techniques (like LIME/SHAP) and training staff to translate those technical outputs into meaningful, human-understandable language is essential. Simply providing raw data or source code does not constitute a meaningful explanation. Relying solely on data subject consent may not be sufficient if the explanation itself cannot be provided upon request.

Meeting the 'right to an explanation' requires a multi-faceted approach. Using intrinsically interpretable models is the most direct way to ensure decisions can be explained. For complex 'black box' models, implementing post-hoc explanation techniques (like LIME/SHAP) and training staff to translate those technical outputs into meaningful, human-understandable language is essential. Simply providing raw data or source code does not constitute a meaningful explanation. Relying solely on data subject consent may not be sufficient if the explanation itself cannot be provided upon request.

This scenario is a textbook example of data drift. Data drift occurs when the statistical properties of the input data to the model change over time, making the original patterns learned during training less relevant. The new marketing campaign changed the input data distribution (the type of customer). Concept drift, in contrast, is when the relationship between the input data and the target variable changes (e.g., the reasons why customers churn change). Overfitting is a training-time issue, not a post-deployment one.

For an internal tool in an agile environment, the most effective and lightweight first step is to establish clear rules and empower the users. An AUP sets the boundaries for use, while practical training ensures developers understand the risks (like generating insecure code) and their non-negotiable duty to act as the human-in-the-loop, validating all outputs. This addresses the primary risks through administrative controls and user empowerment, which is less bureaucratic than immediately procuring new tools, less theoretical than a long training course, and more foundational than creating a complex monitoring dashboard before usage patterns are even established.