Before AI Can Act: Seven Questions for Safer Enterprise AI
AI is easy to experiment with. Someone opens a chatbot, tries a few prompts, and finds a task that suddenly takes ten minutes instead of an hour.
The risk changes when that tool moves beyond drafting. Connect it to email, internal files, customer records, code repositories, or payment systems and it becomes capable of doing work inside the business. That is useful. It also means a mistake can travel much farther than a bad paragraph.
At that point, an acceptable-use policy is not enough. The organization needs controls that still hold when the model misunderstands a request, encounters malicious content, or behaves differently than expected.
NIST’s AI Risk Management Framework gives organizations a useful structure for this work: govern the program, map each use case, measure risk, and manage what happens over the system’s lifecycle.[1] CISA and its international partners make a similar point in their guidance on agentic AI: organizations should connect AI adoption to existing cybersecurity practices and maintain oversight as these systems gain autonomy.[2]
You do not need a fifty-page framework to begin. Start with seven questions.
1. Who owns the system?
Every AI tool or agent should have a named business owner and a clear purpose.
“The innovation team” is not an owner. Neither is the vendor. Someone inside the organization needs responsibility for deciding what the system may do, reviewing changes, accepting risk, and shutting it down if necessary.
Write down the job in plain language. A useful description might be: “Summarize approved customer-support tickets and prepare a draft response for an employee to review.” That is much easier to govern than “help the support team with AI.”
Ownership also prevents abandoned pilots from quietly becoming production systems. Microsoft recommends keeping an inventory of agents that records their purpose, owner, platform, and access scope.[4] A spreadsheet can be enough at first. The important part is knowing what exists.
2. What data can it see?
An approved AI product is not automatically approved for every type of information.
Before deployment, identify the data the system will receive directly and the information it can reach through connectors. Consider customer records, employee information, contracts, source code, credentials, security findings, financial plans, and confidential material supplied by third parties.
Then set boundaries that people can actually follow:
- Which data classifications are permitted?
- Can prompts or outputs be used to train a provider’s models?
- Where is the data processed and retained?
- Who can review conversation history and logs?
- What should employees do when they are unsure?
Telling staff to “avoid sensitive data” leaves too much room for interpretation. Give examples from the work they do. A payroll team, a software developer, and an executive assistant will encounter different risks.
3. What can it do?
There is a large difference between an AI system that suggests an action and one that can carry it out.
Read-only access is safer than write access. Drafting an email is safer than sending one. Recommending a payment is safer than initiating it. The distinction sounds obvious, but AI pilots often inherit broad user sessions or shared service accounts because those are convenient during development.
Treat an agent like a new digital identity. Give it its own account where possible, grant only the permissions needed for its job, and make those permissions easy to revoke. Microsoft recommends a distinct identity for every agent so its actions are attributable and its access can be managed through existing identity controls.[4]
A sentence in a prompt is not a permission boundary. Writing “ask before sending” may guide the model, but it does not remove the Send button. If the task is read-only, the identity and tools should be read-only too.
4. Where must a person approve the action?
Human review should sit in front of consequential actions, not behind them.
The approval should happen at the point where the action can still be stopped. That usually includes external communications, payments, account changes, deletion of records, production changes, legal commitments, personnel decisions, and anything that could affect safety.
The reviewer also needs enough context to make a real decision. A vague “approve” button is weak if the person cannot see what the agent plans to send, change, or execute.
OWASP recommends human approval for high-risk operations and least-privilege access to reduce the impact of prompt injection.[3] Those controls work together. Approval provides judgment; restricted permissions limit the damage if that judgment is rushed or wrong.
5. What will be logged?
If an agent changes a record or sends a message, the organization should be able to reconstruct what happened.
Useful logs answer practical questions:
- Which identity initiated the task?
- What data sources did the agent access?
- Which tools or APIs did it call?
- What action did it propose?
- Who approved it?
- What changed in the target system?
Logging every internal model thought is neither realistic nor necessary. Focus on the evidence needed for accountability, troubleshooting, incident response, and audit. Protect those logs too; they may contain sensitive prompts, retrieved documents, or business data.
6. How has it been tested?
A successful demo proves that the happy path works. It does not show what happens when the input is confusing, hostile, incomplete, or simply odd.
Prompt injection deserves particular attention when a system reads websites, email, uploaded files, or documents from outside the organization. Instructions hidden in that material may try to influence the model. OWASP notes that prompt injection can lead to data disclosure, unauthorized access, command execution, and manipulated decisions, depending on the tools and authority connected to the model.[3]
Testing should reflect the actual job. Give the system conflicting instructions. Put malicious text in a document it is asked to summarize. Remove a required data source. Revoke a credential. Send an unexpected file type. Check whether output validation catches malformed or unsafe results.
Test again when the model, prompt, connector, data source, or permission set changes. An AI system is not frozen at launch.
7. How do we stop it?
Every production AI system needs a practical off switch.
The team should know how to disable the agent, revoke its credentials, block a connector, preserve evidence, reverse changes where possible, and notify the right people. Assign those responsibilities before an incident. Do not wait until a fast-moving workflow is doing the wrong thing at machine speed.
This is also where ordinary operational discipline matters. Changes need owners. Higher-risk deployments need rollout gates. Teams need a rollback plan, incident reporting path, and criteria for taking the system out of service.
Governance should make safe use easier
A good AI governance program does not begin with “no.” It gives employees a safe way to use tools that are already becoming part of their work.
That means approved options, clear data rules, short training tied to real tasks, and a review process that does not take months. If the approved route is confusing or unavailable, people will find another one.
Start small. Inventory the tools already in use. Pick one meaningful use case. Answer the seven questions. Test the controls in a pilot before expanding access.
The goal is not to remove every possible AI risk. It is to know who is accountable, limit what the system can reach, keep people involved where judgment matters, and retain the ability to see and stop what it does.
Before the next AI pilot goes live, ask:
- Who owns it?
- What data can it see?
- What can it do?
- Where must a person approve the action?
- What will be logged?
- How has it been tested?
- How do we stop it?
If those answers are unclear, the pilot is not ready for more access.
