AIGP - Understanding how to govern AI deployment and use (27% of the exam) - Section 4.6

Document incidents and post-market monitoring plans, forecast and reduce secondary and downstream harms, establish external communication plans, and implement policies to deactivate or localise an AI system.

Document incidents and post-market monitoring plans, forecast secondary and downstream harms, and establish external communication plans for stakeholders. Design policies to deactivate or localise an AI system when risks exceed acceptable thresholds.

downstream harmsAI deactivation policypost-market monitoringexternal communication

Practice question for this objective

Free sampleUnderstanding how to govern AI deployment and usehard

A bank deploys an agentic AI system that autonomously negotiates and finalises small-business loan terms by calling internal pricing and approval tools. A governance analyst forecasts that, beyond the borrowers it touches directly, the system could steadily tighten credit for a whole sector if it learns to favour one risk profile, harming suppliers and employees downstream. Which action most directly reduces this forecast secondary and downstream harm before it materialises?

AAdd a post-incident review step that examines sector-level credit effects only after a complaint about reduced lending is received from an affected industry body.
BDisclose in the customer terms that an AI system sets the loan conditions, so borrowers understand a system rather than a person made the offer.
CInstrument sector-level lending distribution metrics with thresholds that trigger review, so concentration shifts that disadvantage an industry are detected and corrected early. Correct
DRestrict the agent's tool permissions so it cannot finalise terms above a set value, routing larger deals to human credit officers for sign-off.

Reducing forecast secondary and downstream harms requires monitoring the aggregate, population-level effects they would produce, not only controls aimed at individual transactions. Secondary and downstream harms are diffuse effects beyond the people a system directly touches, so reducing them means measuring the aggregate pattern that signals the harm is forming. Instrumenting sector-level distribution metrics with review thresholds surfaces concentration shifts early, whereas per-deal caps, individual disclosure and post-complaint review do not detect or pre-empt the population-level drift.

Why A is wrong: Post-incident review is a real control, but waiting for a complaint means the downstream harm has already accrued, which fails the aim of reducing a forecast harm before it materialises.

Why B is wrong: Transparency to the borrower is a genuine obligation and tempting to choose, but informing individual applicants does nothing to detect or constrain the sector-wide credit-tightening that the analyst forecast.

Why C is correct: Forecast secondary and downstream harms are reduced by measuring the aggregate effect they would produce, so instrumenting sector-level distribution metrics with thresholds detects the credit-tightening pattern early and lets the bank intervene before it harms suppliers and employees.

Why D is wrong: Tool-permission limits are a sound agentic control and reduce single-deal exposure, but a value cap on individual deals does not address aggregate, sector-level distributional drift, which is the secondary harm in question.

See more AIGP practice questions, answers explained.

Exam traps in Understanding how to govern AI deployment and use

Answers that look right on this material and are not. Each one is a distractor from a different question in the AIGP bank for this domain.

A downstream harm is any harm that occurs after the AI system has been formally retired from service, whereas a direct harm is one that arises only while the system is still actively in production.
Why it is wrong: This is tempting because timing feels like a natural dividing line, but the distinction turns on who is affected and through what chain of effects, not on whether the system is still running when the harm appears.
Submit the system for a fresh third-party conformity assessment every twelve months regardless of whether the system or its data have materially changed since deployment.
Why it is wrong: It is tempting because high-risk systems do undergo conformity assessment, but post-market monitoring is an ongoing data-collection and analysis duty, not a fixed annual re-certification, so this misstates the Article 72 obligation.
It must record the malfunction in its internal post-market monitoring logs and address it at the next scheduled review cycle, since continuous monitoring already covers performance issues.
Why it is wrong: Logging within the post-market monitoring system is required for ordinary performance issues and feels sufficient, but an event of this severity escalates beyond routine monitoring to a distinct mandatory reporting duty that a scheduled review cannot satisfy.

Examworthy is not affiliated with or endorsed by IAPP. Original, blueprint-aligned practice material only.