AI Technologies and Controls

Security technologies and controls for AI systems: AI security architecture and design, security across the AI life cycle, data management controls, privacy, ethical, trust and safety controls, and security controls and monitoring.

5 minutes 5 Questions

In Advanced AI Security Management, 'AI Technologies and Controls' refers to understanding the core technical building blocks of AI systems and the safeguards needed to secure them across their lifecycle. Key AI technologies include machine learning (supervised, unsupervised, reinforcement learnin…

Concepts covered
Robustness and Reliability ControlsSecurity Architecture Patterns for AI ApplicationsSecure Deployment: Cloud, On-Premises and Edge AIMLOps and LLMOps Security ControlsFairness and Bias Testing ControlsPre-Deployment Security Testing of AI ModelsSecuring AI Agents, Tools and PluginsEthical Review and Responsible AI AssessmentMaintenance, Retraining and Drift ResponseRisk-Based Human Oversight of AI Inputs and OutputsData Access Controls and Segregation for AI PipelinesSecure Training Environments and PipelinesSecuring LLM Applications and RAG PipelinesModel Versioning, Change Management and RollbackPreventive, Detective and Corrective Controls for AICross-Border Data Transfer and Residency for AIModel Validation, Testing and Acceptance CriteriaExplainability and Interpretability ControlsData Classification and Handling for AIData Leakage Prevention for AI Inputs and OutputsAI Development Life Cycle Security TouchpointsMapping Security Controls to AI RiskControl Testing, Assurance and Continuous ValidationSecure Deployment and Release of AI ModelsModel Selection: Build, Buy, Fine-Tune or PromptMonitoring Model Behavior and Anomaly DetectionKill Switches, Circuit Breakers and Fallback ModesAI Architecture Within Enterprise ArchitectureContent Safety Filters and GuardrailsSynthetic Data and Its Security ImplicationsAI System Components and Attack SurfaceModel Decommissioning and Secure RetirementOutput Filtering, Moderation and ValidationData Minimization, Anonymization and PseudonymizationDetection and Response Integration for AI SystemsFine-Tuning and Prompt Engineering SecurityEncryption of AI Data at Rest, in Transit and in UsePrivacy by Design for AI SystemsSecurity by Design and Threat-Informed RequirementsData Provenance, Lineage and Labeling ControlsRate Limiting, Quotas and Abuse PreventionTraining Data Security and Integrity ControlsTransparency, Disclosure and User NotificationModel Cards, Datasheets and AI DocumentationZero Trust and Segmentation for AI WorkloadsAPI Security for AI ServicesSecrets, Keys and Model Artifact ProtectionArchitecture Review and Security Sign-Off for AILogging, Auditing and Traceability of AI InteractionsIdentity and Access Management for Models and DataData Retention, Deletion and Unlearning RequestsTrust and Safety Operations for Generative AIInput Validation and Prompt Filtering ControlsPrivacy-Enhancing Technologies for AISecurity Metrics and Dashboards for AI ControlsData Quality, Integrity and Validation Controls
Test mode:
Start practice test

AAISM - AI Technologies and Controls Example Questions

Test your knowledge of AI Technologies and Controls

Question 1

An enterprise tags regulated customer tables as in-country only. Its MLOps scheduler blocks any training job that reads tagged data from running in a foreign region. A review finds a model trained abroad on a feature set built from those tables. Scheduler logs show that the policy evaluated every job and that no exception was raised. What is the MOST likely cause of this residency violation?

Correct Answer: Derived datasets lacked the residency tag carried by the source

The scheduler evaluated every job correctly, but it only blocks jobs that read tagged data. A feature set derived from the regulated tables that did not inherit their residency tag looked unrestricted, so the training job passed the check.
Scoping region pinning to compute rather than storage does not fit, because the scheduler already controls where compute runs, and that is exactly where it failed to act. Treating feature engineering as taking data out of scope would be a legal judgment, not something that explains a policy engine silently passing the job. An unlogged exception is contradicted by the logs, which show full evaluation and no exception.
Key concept: data lineage and tag propagation to derived artifacts.

Question 2

An enterprise's public LLM API enforces per-key requests-per-minute limits and daily request quotas. A billing review finds that a few keys stay within both limits but still drive disproportionate compute cost. They submit very long context inputs and prompts crafted to force maximum-length responses. Which safeguard would MOST effectively address this abuse?

Correct Answer: Cap input and output tokens per request

Capping input and output tokens per request directly limits the compute each call can consume. That neutralizes the oversized contexts and prompts engineered for maximum-length output, which drive cost even when request counts stay low.
Lowering the requests-per-minute limit misses the problem, because these keys already comply with it and their cost comes from the size of each request, not how often they arrive. Alerting on request count spikes would never fire, since request volume is normal. Reducing the daily request quota still lets every allowed request be as expensive as possible.
Key concept: resource consumption controls must meter tokens and compute, not just request counts, to prevent model denial-of-service and cost-exhaustion abuse.

Question 3

Which of the following BEST describes how the defense-in-depth principle is applied when reviewing the security architecture of an LLM-based application?

Correct Answer: Layering independent controls at input, model, output and tool stages

Defense in depth means stacking independent, overlapping controls across the whole LLM pipeline: input filtering, model alignment and system-prompt hardening, output validation, and least-privilege tool or agent permissions. If one layer fails, such as a prompt injection slipping past input screening, another layer can still catch or contain it.
Putting all screening in one hardened gateway creates a single point of failure, which is the opposite of layering. Encrypting weights, prompts and outputs protects data confidentiality but does nothing against prompt injection or unsafe outputs. Assigning stage owners for risk acceptance is a governance and accountability practice, not a set of technical controls.
Key concept: defense in depth as multiple independent control layers across the LLM pipeline.

More AI Technologies and Controls questions
1173 questions (total)
Practice 100 questions
One session at a time, always new questions