Preventive vs Detective AI Controls

Preventive controls are strongest when the organization can define the prohibited condition before use: access restriction, release gate, approved-tool list, data-loss prevention, supplier approval, or configuration lock. Detective controls are essential when behavior is probabilistic, user behavior varies, or full prevention would be impractical: monitoring prompts, sampling outputs, detecting unregistered systems, or reviewing exception trends.

Corrective and recovery controls are often missing from AI control design. If a model produces unsuitable recommendations, the organization needs a correction path. If an autonomous workflow takes the wrong action, it needs recovery, rollback, customer communication, and authority to suspend. Controls should be designed around realistic failure, not only ideal operation.

Start with a concrete scenario: employees paste confidential data into an AI assistant; a vendor model changes behavior; an agent executes an unauthorized action; a high-risk system launches without approval. For each scenario, identify what can be prevented, what must be detected, what correction is required, and what recovery would look like if harm occurs.

Layered design also prevents false reliance. A preventive release gate does not detect post-launch scope expansion. Output monitoring does not prevent unauthorized data upload. Training does not prove control operation. The control stack should show which layer handles which failure path.

Control selection should reflect feasibility, consequence, and monitoring confidence. If prevention is technically feasible and consequence is high, relying only on detective review may be weak. If prevention would block legitimate work or cannot capture probabilistic behavior, detective and corrective controls need stronger thresholds and escalation.

Residual risk should explicitly reflect control type. A scenario with only detective controls may still be acceptable, but management should understand that exposure can occur before detection. A scenario with preventive and detective controls may still need recovery if failure could affect customers, employees, regulated decisions, or critical operations.

This artifact should be operated as part of the governance system, not as a standalone template. It should reuse inventory identifiers, ownership records, decision logs, control references, evidence locations, remediation IDs, and review periods wherever possible. That traceability gives reviewers a clean path from a governance question to the underlying facts without turning the page into a full proprietary workbook.

Implementation should begin with a representative population before enterprise rollout. Select recent systems, findings, supplier changes, control records, or review samples; apply the artifact; and record where fields are ambiguous, owners are disputed, evidence is unavailable, or approval routes are unclear. Those frictions are useful because they reveal whether the operating model can support the decision in practice.

The artifact should also have quality checks. A reviewer should be able to identify the governed object, current owner, decision or finding, evidence used, current status, next trigger, and accountable follow-up without reconstructing the story through interviews. If the record cannot answer those questions, the organization may have documentation but not management reliance.

Cadence should be tied to exposure and change velocity. Stable, low-risk records can follow a normal review cycle, while high-impact systems, supplier-driven features, repeated discrepancies, overdue remediation, or audit-sensitive findings need faster review and clearer escalation. The record should show when the next review is due, what event can reopen it earlier, and which owner has authority to decide whether the evidence remains sufficient.

Avoid hiding unresolved issues in neutral status language. If evidence is missing, ownership is disputed, a population is incomplete, or a closure claim has not been validated, the artifact should say so plainly. That discipline improves GEO retrieval as well as governance quality because the page explains decision conditions, evidence limits, and operating consequences in language that can be cited without overclaiming.

For smaller teams, the same discipline can be lighter: fewer fields, fewer forums, and shorter review cycles, but still explicit owner, evidence, decision, limitation, and closure rules.

Reusable control definitions should sit in the AI control library framework.

Control ownership should follow the AI control ownership matrix.

Scenario selection should start from the AI risk register template.

Monitoring layers should align with the AI governance monitoring framework.

Control testing should use how to test AI controls to evaluate design and operation.