Free Advanced in AI Security Management (AAISM) practice test: 30 questions with answers

A threat and impact analysis considers data, model behaviour, misuse and the effect on affected individuals, which is what credit decisions require. Branding, server counts and feature counts do not identify the risks.

The NIST AI Risk Management Framework organises AI risk management into Govern, Map, Measure and Manage. The other NIST documents cover different topics such as controlled information or general cybersecurity functions.

Model drift is the change in performance as real-world data shifts from the training data, and it can affect some groups more than others. Vendor dependence, licence expiry and network latency are different categories of risk.

A rising count of incidents, near-misses or monitoring threshold breaches is a leading indicator that AI risk is growing. Conference talks, job adverts and other activity counts say nothing about risk exposure.

Contract terms, data processing agreements and technical limits on what data is sent address the risk at source and make responsibilities enforceable. Sending everything, ignoring terms and relying on marketing claims all leave the data exposed.

A high likelihood and high impact risk should be treated with controls that reduce it, and the residual risk should be monitored. Accepting it without treatment, hiding it in documentation or deleting it from the register leave the organisation exposed.

Reassessing when the model, its data or its use changes keeps the risk picture current. A one-off assessment, self-assessment alone and a purely technical view each miss changes and the views of affected people.

Risk tolerance is a business decision approved by governance that sets how much risk the organisation accepts. It is not set by the model, it varies by impact, and it is not a technical setting.

An inventory of components with their sources and versions, and integrity checks before use, reduce supply-chain risk. Unverified sources, unchecked licences and trusting names without provenance each expose the system to tampered or unsuitable components.

Mitigation with additional controls and transfer through insurance or contracts are valid treatment options. Hiding a risk, accepting every risk and ignoring residual risk are not valid treatments, because they leave the exposure unmanaged.

A common AI policy and an accountable governance body with defined decision rights create consistent rules across the units. Case-by-case purchases, unit-by-unit rules and blanket bans each leave the organisation without a coherent control set.

ISO/IEC 42001 specifies requirements for an AI management system and can be certified against. NIST SP 800-53, PCI DSS and ITIL are valuable references but do not provide a certifiable AI management system standard.

A KPI tied to objectives, such as the share of AI systems with approved risk assessments, shows progress toward the programme's goals. Tool counts, email volumes and slide counts measure activity rather than outcomes.

A business owner accountable for the outcome, supported by risk, legal and security input, is the right owner for a high-impact deployment decision. Developers, scanning analysts and vendor account managers each have a role but not the accountability for the decision.

An AI policy approved by senior leadership sets principles, roles and boundaries for responsible AI use across the organisation. A penetration report, invoice schedule and marketing brochure serve different purposes.

Mapping objectives to business goals and reviewing them with leadership keeps the programme aligned as strategy changes. Fixed objectives, vendor-set direction and technical-only measurement each drift from the business.

Due diligence on security practices, data handling, model documentation and audit rights gives the buyer evidence and leverage before committing. Discounts, contracts with no audit clauses and self-assessment alone leave the risk unchecked.

Classifying by impact on people and the organisation sets the level of oversight, testing and approval each system needs. Age, user count and developer reputation are weak indicators of the harm a system could cause.

A RACI matrix names owners for each AI system, so accountability is explicit and reviewable. A shared mailbox, informal understanding and self-accountability by the system each leave decisions without a responsible person.

A governance committee approves risk tolerance for high-impact systems and decides on policy exceptions. It does not write model code, choose interface colours or delete systems automatically.

Evasion through adversarially altered inputs is a specific AI risk that changes model outputs while looking normal to people. Duplicate records, slow dashboards and printer firmware are general IT issues rather than AI-specific risks.

Recording and providing the main factors behind the decision, in understandable terms, supports the customer's ability to contest it and supports auditability. Hiding logic, giving bare scores and demanding acceptance each prevent meaningful explanation.

A model card documents the intended use, limitations, training data and evaluation results, which helps users and governance judge fit and risk. Marketing claims, passwords and invoices are not model card content.

Grounding answers in approved sources reduces invented content, and human review for high-impact answers catches the errors that remain. Removing review, publishing unchecked output and raising temperature each increase the chance of confident errors reaching customers.

Segmentation and least privilege limit what a compromised model can reach, and a known-good rollback restores service quickly. Administrator rights, public weights and disabled logs each widen the impact or hide it.

Tracking accuracy and drift against thresholds, logging inputs, outputs and decisions, and alerting on fairness or safety breaches are core monitoring controls. Watching only CPU usage and switching monitoring off after acceptance each leave behaviour unobserved.

Containment with evidence preservation and notification to affected parties and regulators as required are core incident response activities. Ignoring outputs, deleting logs and restarting without review each make the incident harder to contain or explain.

Change management with approval, version control and an audit trail makes every change authorised and traceable. Direct production edits, shared-drive overwrites and frequent renaming each allow unauthorised or untraceable changes.

Separating trusted instructions from untrusted retrieved content, and limiting the actions the model can take, reduces the effect of injected instructions. Trusting pages, following embedded instructions and removing access controls each give attackers the means to direct the model.

Scoped permissions, approval for high-impact actions and logging limit what a manipulated agent can do and make misuse visible. Full access, self-created tools and disabled logs each widen the damage.