New article | AI leadership and cybersecurity
An employee uses an AI assistant to summarize a customer conversation. A manager tests it on a financial forecast. A support team connects it to an internal knowledge base. Each experiment may look small. Together, they raise a significant leadership question: Who is deciding where artificial intelligence belongs in the business—and what boundaries apply?
AI can help organizations draft, analyze, classify, and retrieve information. But useful capabilities do not eliminate familiar business obligations: protecting confidential information, validating decisions, controlling access, and assigning accountability.
The answer is neither unrestricted experimentation nor a blanket ban. It is a disciplined adoption process that makes responsible use easier than improvisation.
This article focuses primarily on generative AI: systems that produce content such as text, images, and code. The five guardrails below also offer a useful starting point for broader AI adoption. The central principle is straightforward: Manage AI as a business process, not simply a software purchase.
1. Give Every AI Use Case an Accountable Owner
“We are experimenting with AI” is not a business objective. “We are testing whether AI can draft internal meeting summaries that employees can verify before distribution” is a use case.
That distinction matters. A defined task gives you something to evaluate. An accountable owner gives someone responsibility for deciding whether the system is helping, creating risk, or operating outside its intended purpose.
Before introducing a tool into a workflow, document the task, intended users, approved information sources, expected output, and responsible manager. Establish who can approve changes and who can pause the activity.
NIST’s Generative AI Profile, published July 26, 2024, supports assigning responsibilities and managing risks throughout an AI system’s lifecycle. It is voluntary guidance, not a certification that makes a deployment safe by default.
Make accountability specific
Consider a hypothetical customer-service pilot. The service manager owns the workflow and quality standards. IT manages access and integrations. Security reviews information exposure. Employees check drafts before sending them. Leadership approves any proposed expansion into automated customer responses.
These responsibilities can sit with fewer people in a small organization. What matters is that they are explicit.
Buying an AI tool does not transfer accountability for the work it produces.
2. Set Information Boundaries Before Employees Start Sharing
A user may view a prompt as a question. The business should also view it as a potential transfer of information.
That transfer might contain customer records, employee details, confidential contracts, credentials, or proprietary plans. Before approving a service, understand how it handles that information.
Do not assume every AI provider retains prompts or uses them for training. Do not assume the opposite. Data handling can vary by product, contract, account type, and configuration. Review the terms and documentation that apply to your actual service.
NIST identifies data privacy and information security among generative AI’s risk areas. Translate those concerns into instructions employees can follow during an ordinary workday.
A practical information-sharing checklist
- Approved tools: Which services and account types may employees use for business work?
- Permitted information: Which categories of information may enter each tool?
- Restricted information: What requires additional approval, and what must never be submitted?
- Connected access: Which files, applications, or repositories may the system access?
- Escalation: Whom should employees contact when they are unsure or have shared something accidentally?
For example, an employee drafting a proposal could use an approved, sanitized outline rather than uploading an entire client agreement. However, removing a name does not necessarily make a document anonymous; other details may still identify the client.
Apply the same discipline to integrations. A tool that summarizes selected documents does not automatically need access to every shared drive. Give it the information and permissions required for the task—not everything available.
3. Verify Outputs Before They Influence Consequential Decisions
Generative AI can produce fluent answers that contain false statements, invented references, or unsupported conclusions. NIST calls this risk confabulation. A confident tone is not evidence of accuracy.
The practical response is to define what must be verified and who performs that verification. “A human will review it” is incomplete unless that person has the knowledge, time, and source material needed to identify mistakes.
Match review to the consequences
An internal brainstorming draft does not require the same controls as a customer commitment, financial recommendation, hiring decision, or security configuration change. Higher-consequence uses warrant more rigorous evaluation and appropriate specialist involvement.
Suppose a sales team uses AI to summarize contractual obligations. The reviewer should compare material claims against the actual agreement—not ask the same assistant whether its answer is correct. A second generated answer is not independent evidence.
- Check material facts, calculations, quotations, and references against original sources.
- Confirm that summaries preserve important exceptions and qualifications.
- Review recommendations for missing context and inappropriate assumptions.
- Require approval before consequential outputs are published or acted upon.
Separate drafting authority from execution authority. Permission to suggest a payment response should not automatically include permission to send money. Permission to propose a system change should not automatically include permission to deploy it.
Human review is one control, not a guarantee. Combine it with testing, limited permissions, and clear escalation rules.
4. Verify People, Not Just Convincing Voices
AI risk is not limited to the tools your organization buys. It also includes how attackers use the technology against your employees.
The Federal Trade Commission warns that scammers can clone a familiar voice from an audio clip. Its advice is practical: Contact the person using a number you already know belongs to them rather than trusting the incoming call.
That principle belongs in business procedures, particularly where urgency and authority can pressure someone to bypass normal checks.
Imagine a finance employee receiving a call that sounds like an executive requesting an immediate payment. The employee should not have to decide whether the voice sounds authentic. The process should require independent verification through an established channel and the usual payment approvals.
Apply the same approach to requests for password resets, sensitive files, bank-detail changes, and access exceptions. Do not use contact details supplied in the suspicious message as the verification channel.
A convincing voice can support a conversation. It should not replace an authorization process.
Train employees to recognize pressure to break procedure—not merely obvious technical flaws in a message. Make it clear that pausing an unusual request is responsible behavior, even when the requester appears senior.
5. Test a Bounded Workflow Before Expanding
A compelling demonstration shows what a system can do under selected conditions. A pilot should show how it behaves in your actual workflow, including when inputs are incomplete, ambiguous, or misleading.
Start with a narrowly defined task, limited users, approved data, and a clear review process. Establish how the work performs today so you can make a meaningful comparison.
NIST’s voluntary AI Risk Management Framework provides a foundation for evaluation, monitoring, and risk-management actions tailored to organizational goals and use cases. In practice, measure both benefits and failures.
Measure the whole job—not just generation speed
- Time: How long does the task take, including prompting, review, and correction?
- Quality: How often do outputs require material changes?
- Information handling: Are there inappropriate disclosures or attempts to use restricted data?
- Escalation: How often do users encounter situations that require additional help?
- Operational value: Does the workflow improve service or reduce rework after oversight costs are included?
These are suggested measures, not promised outcomes. Define pause conditions before the pilot begins, such as exposure of restricted information, repeated material errors, or actions outside approved permissions.
Test difficult cases as well as routine ones. For systems that read external documents, assess whether embedded instructions can redirect behavior beyond the authorized task. Reassess when the model, integration, permissions, or business purpose changes.
A One-Page AI Use-Case Worksheet
Before approving the next experiment, ask the owner to complete this worksheet:
- Task: What specific work will AI support, and what is outside scope?
- Ownership: Who owns the outcome and can pause the workflow?
- Information: What data may enter the tool, and what access is permitted?
- Verification: What must a person check before the output is used?
- Evaluation: How will benefits, errors, and review effort be measured?
- Stop conditions: What result would trigger a pause or additional approval?
If the team cannot answer these questions clearly, narrow the use case before proceeding.
Build Confidence Before You Scale
Responsible AI adoption is not about eliminating uncertainty. It is about making uncertainty visible, assigning responsibility, and preventing small experiments from quietly becoming uncontrolled business dependencies.
Choose one bounded workflow this week. Name its owner, set its information boundaries, define verification requirements, and agree on success and stop conditions. Then evaluate the complete process—not just the impressive output.
That is how AI becomes a managed business capability rather than an unmanaged business risk.