What should security teams do first when AI ethics is only documented on paper?

When AI ethics stays on paper, what should teams do first?

The first move is to find where ethics decisions are still being made by humans in meetings, tickets, or policy reviews, instead of at the point where the system actually acts. That gap is where risky data use slips through. Once you see those handoff points, you can convert the highest-risk approvals into runtime controls tied to the records, services, and agents that touch customer data.

Why paper-only ethics breaks down in real operations

Paper policies can describe intent, but they do not stop a model, workflow, or agent from using data in a way the business never meant to allow. The failure is usually not a lack of principles, it is a lack of enforcement at the execution layer. That is why the practical question is where the decision happens, who can override it, and whether the control is enforced before data is accessed or shared.

In practice, the risky pattern is a manual approval path that sits outside the live production flow. If a reviewer must remember a policy, interpret a request, and approve it later, the control is already weak. Where the subject is customer data, the more important control is not a broad ethics statement, but a bound decision that checks context, purpose, and authorization in the moment of use.

This is also where the distinction between governance and enforcement matters. Governance sets the rule; enforcement makes the rule real. A mature program should be able to show which decisions are advisory, which are mandatory, and which are impossible to bypass for sensitive records or agent actions.

How to move from policy language to runtime control

The shortest path is to inventory the decisions that currently depend on manual judgment, then rank them by exposure. Start with the flows that handle customer records, external sharing, privileged retrieval, and autonomous agent actions. Those are the places where an ethics principle becomes an access decision, a redaction decision, or a stop condition.

For those flows, convert the policy into controls that execute at request time, not after the fact. That may mean gating record access, restricting tool calls, forcing approval for high-impact actions, or preventing data from leaving an approved context. The control should be specific enough that you can test it against an actual request path, not just a written standard.

Where an AI system, assistant, or workflow has delegated authority, the first implementation target should be the action with the largest blast radius. If a single step can disclose customer data, change records, or trigger downstream processing, it deserves runtime enforcement before lower-risk use cases. That sequencing gives you the biggest risk reduction fastest, without waiting for a perfect enterprise-wide policy rollout.

NHIMG’s Agentic AI Security Policy Template is useful here because it links policy language to registration, oversight, tools, monitoring, and retirement decisions that can actually be enforced.

For teams also building the broader control stack, the AI Governance Guide helps separate committee-level intent from the operational approvals and ownership boundaries that have to exist before a runtime control can work.

What good looks like when the control is working

Good control design makes the risky action observable, bounded, and attributable. You should be able to tell which records were involved, which service or agent requested access, what condition triggered approval or denial, and who can override the decision. If you cannot reconstruct those facts, the control is still mostly documentary.

Teams should also look for the narrowest possible rule that blocks the worst misuse first. The goal is not to freeze every AI workflow, but to ensure that the most exposed paths cannot use customer data without a live policy decision. That usually means starting with high-value records, high-impact actions, and the least trusted integrations.

Runtime controls are stronger when they are paired with clear owner assignment and change management. If a policy change can be written, but no one is responsible for translating it into an enforced rule, the gap will persist. The practical benchmark is whether a policy exception results in a visible technical exception, not just a note in a document.

NHIMG’s AI Security Maturity Model is a useful companion for judging whether your program is still at documentation stage or has begun to enforce controls in production.

For teams securing the underlying runtime and data paths, the AI Security Posture Management (AI-SPM) Guide helps connect discovery, exposure analysis, and workload controls so the most sensitive flows can be governed where they run.

Risk and Threat Considerations

Paper-only ethics creates a control gap that attackers, insiders, and over-permissive automation can exploit. When the decision is outside the execution path, the system can process sensitive data before anyone has a chance to stop it, and the organisation may only discover the problem after exposure or misuse has already occurred.

Failure mechanism: Manual review is bypassed, delayed, or inconsistently applied, while the production workflow continues to process customer data under broader access than intended. In agentic or automated flows, the weak point is often an ungoverned approval step, a stale policy exception, or a tool permission that was never narrowed to the actual use case.

Impact: Uncontrolled data use can lead to privacy exposure, unauthorized disclosure, record corruption, and hard-to-trace downstream sharing. The longer the control stays documentary only, the larger the blast radius when a model, service, or agent is misused or compromised.

Practitioner Guidance

What to prioritise: Start with the single highest-risk flow where customer data can be read, copied, transformed, or sent onward without a runtime check. Do not begin with low-risk internal experiments; begin where a failure would create the most exposure.

What to verify: For each candidate control, verify that the decision is enforced in the live request path, that exceptions are logged, and that the rule applies to the exact record type, service, or agent that handles the data. If enforcement depends on people remembering the policy, it is not yet a control.

Decision rule: If a policy can materially change data use, access scope, or tool action, turn it into a live control before expanding adoption. If the control cannot be enforced yet, treat the flow as higher risk until the runtime check exists.

Practitioner takeaway: Treat AI ethics as a control-design problem, not a documentation problem, because the first meaningful improvement comes from moving the most dangerous decisions into the place where the system actually acts.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?