An employee uses AI to draft an internal update. The first version arrives in seconds, reads well, and looks ready to send. Then a reviewer spots a policy that does not exist. Another employee asks whether the information entered into the tool was approved for sharing.
This is a hypothetical scenario, but it captures the leadership challenge: AI can make work easier while introducing risks that are difficult to see in a polished answer. The opportunity is real. So is the need for control.
Artificial intelligence includes technologies for prediction, classification, and other tasks. This article focuses primarily on generative AI: systems that produce text, images, audio, and other content. For business leaders, the practical question is not simply whether these tools are powerful. It is whether a specific application can deliver useful results without creating unacceptable exposure.
Start with a bounded business problem, define the controls, and require evidence before expanding.
Start With a Business Problem, Not a Tool
“We need an AI strategy” is not a useful project brief. “We want to reduce the effort required to draft internal FAQs from approved reference material” is a starting point.
A good first pilot has a narrow purpose, an accountable owner, and an output someone can evaluate. Favor work where errors are detectable and reversible. Drafting an internal document for review is a different risk proposition from allowing a system to send customer communications or change financial records.
Consider a team preparing employee guidance from public product documentation. AI could produce a draft, organize recurring questions, and suggest clearer language. The pilot should not automatically expand into interpreting contracts, accessing personnel files, or answering questions beyond those sources.
Before choosing a tool, document:
- The task: What specific work should improve?
- The inputs: What information may the system use?
- The output: What will it produce, and who will use it?
- The boundary: What decisions or actions remain outside its authority?
- The success criteria: What evidence would justify keeping it?
Turn Governance Into Operational Questions
Governance should help a team make decisions, not merely generate policy documents. NIST’s voluntary AI Risk Management Framework organizes risk management around Govern, Map, Measure, and Manage. Leaders can translate those functions into practical questions:
- Govern: Who owns the use case, approves changes, and accepts the remaining risk?
- Map: What does the system do, who could be affected, and where could it fail?
- Measure: How will the team evaluate accuracy, security, and business value?
- Manage: What happens when results fall short or an incident occurs?
These are ongoing responsibilities, not boxes checked once at launch. A tool connected to a new document repository may have a different risk profile from the same tool used only with public information. Changes in access, purpose, or autonomy should trigger another review.
Set Data Boundaries Before Employees Begin
The most important AI security decision may happen before a prompt is submitted: whether that information belongs in the service at all.
Employees need clear guidance on approved tools, permitted information, prohibited inputs, and whom to contact when uncertain. “Use good judgment” is not enough when people cannot see how a service stores prompts, processes uploaded files, or shares information through integrations.
For an initial pilot, approved public or non-sensitive material can reduce exposure. Confidential business information, personal data, credentials, and regulated records require controls appropriate to their sensitivity and applicable obligations. Removing a name alone does not necessarily make a document safe.
Joint guidance from NSA, CISA, FBI, and international partners addresses data security throughout AI development and operation. It covers protections such as encryption, secure storage, access controls, and provenance tracking, alongside threats including poisoned data and data drift.
The leadership takeaway is straightforward: protect the entire information path, not just the chatbot interface. Know where source material comes from, who can access it, where outputs are stored, and how information is removed when it is no longer needed.
Evaluate the Actual Service and Configuration
A “business” or “enterprise” label is not a substitute for due diligence. Protections can differ by service, contract, feature, and configuration. Evaluate the arrangement your organization will actually use.
Ask the vendor and your internal technology team:
- Are prompts, files, and outputs used to train models? What settings or contractual terms govern that use?
- How long is information retained, and what does deletion cover?
- Which administrators, service providers, or other parties can access the data?
- Can access be restricted by role and removed when someone leaves?
- What information becomes available through connected applications and repositories?
- What logging, incident notification, and investigation support are available?
Connected data deserves particular attention. If an assistant searches internal documents, confirm that it respects the requesting user’s permissions. A convenient search experience should not become a shortcut around existing access controls.
Also distinguish a drafting assistant from a system authorized to act. Sending messages, modifying records, or executing transactions introduces consequences beyond generating text. For a first pilot, keep those permissions off unless they are essential and separately evaluated.
Make Verification Someone’s Responsibility
Fluent language is not evidence of correctness. NIST’s Generative AI Profile identifies confabulation: false or erroneous content presented confidently. A plausible explanation can still contain invented facts, misleading conclusions, or nonexistent references.
Assign a named reviewer with the expertise, time, and authority to challenge the output. “A human will check it” is not a control if nobody knows what to check or feels able to reject the result.
Separate Drafting From Approval
For the internal FAQ example, the reviewer should compare factual claims with the approved source documents, check that exceptions have not disappeared during summarization, and remove unsupported answers. Permission to generate a draft should not confer permission to publish it.
Verification should match the consequences. A writing suggestion may need editorial review. A statement about legal obligations, security configuration, or financial decisions may require a qualified specialist and independent supporting evidence.
Test Failure Cases, Not Just Demonstrations
Include incomplete source material, ambiguous questions, conflicting documents, and requests outside the pilot’s scope. Test whether the system acknowledges missing information rather than filling gaps with convincing language.
If the tool retrieves external content, assess how it handles embedded instructions that attempt to redirect its behavior. Define how reviewers report suspicious outputs, pause the workflow, and escalate possible data exposure. NIST’s generative AI guidance supports pre-deployment testing, defined oversight, and incident processes; none of these eliminates every risk.
Measure Whether the Pilot Is Worth Keeping
Usage is evidence of activity, not necessarily value. Establish a baseline for the existing process, then compare representative work using agreed quality criteria.
Track:
- Total task time: Include prompting, review, correction, and rework.
- Output quality: Assess accuracy, completeness, relevance, and consistency.
- Total cost: Include subscriptions, integration, administration, training, and oversight.
- Risk signals: Record policy violations, inappropriate disclosures, near misses, and incidents.
If drafting becomes faster but verification becomes substantially harder, the workflow may not have improved. Agree on expansion and stopping criteria before enthusiasm for the tool influences the assessment.
A Practical 30-Day Plan
The following is an implementation suggestion, not a government-prescribed timetable. Adjust it to the complexity and risk of the workflow.
- Week 1: Inventory existing AI use and select one bounded task. Establish the current process and baseline.
- Week 2: Assign ownership, evaluate the service, and document data-handling and approval rules.
- Week 3: Test representative tasks and failure cases. Record errors, review effort, and security concerns.
- Week 4: Compare results with the baseline. Decide whether to expand, revise, or stop.
Before-Launch Checklist
- The workflow has a named business owner.
- Approved tools and data boundaries are documented.
- Retention, training use, permissions, and integrations have been reviewed.
- A qualified reviewer controls publication or consequential action.
- Success criteria and failure tests are defined.
- The team knows how to report an incident and pause the pilot.
Build Confidence Through Evidence
Responsible AI adoption is neither unrestricted experimentation nor indefinite delay. It is disciplined implementation: a clear purpose, appropriate access, accountable review, and measurable results.
Choose one workflow and put an owner against it. Establish its data boundaries, test how it fails, and measure the full cost of producing a usable result. Expand only when the evidence supports that decision. That is how leaders turn AI from an interesting demonstration into a capability the business can trust.