Can a control be partly technical and partly operational?

Yes. An automated alert and the team's response procedure work together but perform different functions.

Does encryption solve every AI privacy problem?

No. It protects information in specified states and contexts; it does not establish that every authorized use is appropriate.

Who owns a technical control?

Ownership should be assigned explicitly, including responsibility for maintenance, testing, and response to failures.

AI Glossary / Governance, ethics and safety / Advanced

Technical control

Definition

A technical control is a safeguard implemented primarily through a system's hardware, software, or firmware. In security terminology, it helps protect the system and its information. In AI risk management, the same general idea applies to mechanisms that constrain, detect, or respond to undesirable system behavior. The defining feature is how the safeguard operates, not whether it uses machine learning.

What it means

A policy may say that an assistant must not retrieve documents a user cannot access. A technical control enforces that requirement through permission checks at the retrieval boundary. Staff training explains the rule; software execution makes the check part of the workflow.
Technical controls still depend on human decisions about requirements, configuration, ownership, and acceptable residual risk. Installing a feature is not equivalent to demonstrating that it works. The control needs a defined objective and evidence that its behavior supports that objective under relevant conditions.

How it works

Start with the unwanted event and the point where it can be prevented, detected, or limited. Specify what the control examines, what action it takes, and what happens when it cannot complete its check. For access control, OWASP recommends least privilege, permission validation on every request, and denial by default.
A technical control might block an unauthorized operation, record a suspicious event, or limit resource use. Those functions are different: a log entry does not undo an action, and an alert needs a response process.
Test the actual enforcement path, including integration failures and alternative routes. Monitor whether the control remains enabled and correctly configured after changes. NIST's AI risk management guidance places risk treatment within continuing assessment and monitoring rather than treating an initial implementation as the end of the work.

Three practical examples

A document assistant checks the requesting user's permissions before adding a retrieved file to its context. The permission mechanism is a technical control; a written confidentiality policy alone is not that mechanism.
An AI service applies a configured request quota to limit resource consumption. The quota does not establish answer accuracy, but it can constrain a specific operational risk.
A workflow prevents an AI-generated update from being committed until an authorized reviewer approves it. Software enforces the approval gate, while the quality of the review depends on the human process.

Think of it this way

A rule asking staff to keep a storage room secure is different from a lock that checks an access credential. The lock implements part of the rule, but someone must decide who receives access, maintain the mechanism, and respond when it fails. An AI safeguard has the same combination of technical and organizational responsibilities.

Worked example

Consider an invented test of an assistant's document access control. Reviewers prepare 100 requests that should be denied and 100 that should be allowed, using independently verified permissions.
The control blocks 96 of the unauthorized requests but incorrectly permits four. It allows 98 authorized requests and incorrectly blocks two. Its unauthorized-request blocking rate is 96 / 100 = 96%, while its false-block rate among authorized requests is 2 / 100 = 2%.
Across all 200 test cases, 194 decisions are correct, giving 97% overall correctness. That aggregate can sound reassuring while hiding four unauthorized disclosures. The business significance depends on what those requests exposed and the stated security requirement; the average alone is insufficient.
Suppose investigation finds that one integration route omitted the check. After repair, the same tests all pass. This is evidence that the observed defect was corrected for those cases, not proof that every possible route and condition is covered. Additional tests should target the previously missed boundary and relevant variations rather than merely repeating the same headline percentage.

Illustrative case study

Fictional company CedarAnswers adds an AI assistant to its knowledge base. The team instructs the model to respect document permissions, but initially supplies retrieved content before checking the user's entitlement to each document.
A review identifies the misplaced enforcement point. The company changes the retrieval service so permission checks occur before content reaches the assistant. It tests users with different access rights, checks what happens when permission information is unavailable, and verifies that the same rule applies across interfaces.
The team retains clear instructions for the assistant, but evaluates those separately from the access boundary. This fictional case illustrates why a safeguard's location and enforcement matter. It does not claim that one permission check addresses every confidentiality risk in an AI service.

Common misconceptions and mistakes

“A technical control must use AI.” Ordinary software checks can be essential controls around an AI model.
“A policy document is a technical control.” The document can define a requirement, while implementation provides enforcement.
“A warning is the same as prevention.” A warning informs; a preventive mechanism blocks or limits an action.
“More controls always mean less risk.” Poorly coordinated mechanisms can create gaps, conflicting behavior, or operational burden.
“A prompt is equivalent to an authorization boundary.” Model instructions should not substitute for independently enforced permissions.

Business use

Describe each control in terms of the risk addressed, enforcement point, responsible owner, and evidence of effectiveness. Ask what remains possible if the control fails and what other safeguards or response processes apply.
Review both missed violations and unnecessary restrictions. A control that blocks useful work can create pressure for workarounds, while an apparently convenient setting may weaken protection. Decisions about configuration should be documented and tested against the actual workflow, not inferred from the presence of a product feature.

Check your understanding

Why report the four unauthorized permissions separately from overall correctness?

Answer: Their consequences may be material despite a high aggregate score.

What distinguishes a review policy from an enforced review gate?

Answer: The gate technically prevents progression until the required approval occurs.

Why test alternative integration routes?

Answer: A control on one path may not apply on another.

Related terms

Access Control
Least privilege
Defense in depth (computing)
Security control
safeguard
monitoring
defense in depth
residual risk
human oversight

Learn next

Choose one AI workflow requirement. Identify where it should be enforced, how to test permitted and prohibited behavior, and what should happen if the checking mechanism is unavailable.

Sources

NIST CSRC Glossary, technical controls, definitions attributed to FIPS 200 and related publications: https://csrc.nist.gov/glossary/term/Technical_Controls OWASP, Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html NIST, AI RMF Playbook, Manage: https://airc.nist.gov/airmf-resources/playbook/manage/

Previous: Teacher forcing Next: Technological singularity