Keep company data safer in an AI pilot by limiting the use case, defining exactly what data may enter and leave the system, enforcing existing permissions in the application, and testing the controls before users rely on it. A pilot is not secure just because a vendor describes a service as enterprise-ready: its data flows, configuration, contract, and operating procedures all matter.
Start with a bounded use case
Decide what workflow the pilot will improve before choosing a model or opening access. A specific task, defined user group, and clear measure of benefit make it possible to evaluate both value and risk. Avoid open-ended experiments that invite employees to submit whatever information they have.
Write a short charter that records:
- The workflow and intended users.
- The decision or task the AI supports, and what remains a human responsibility.
- The expected benefit and how it will be measured.
- What is explicitly out of scope.
- Who approves the pilot, who operates it, and who can pause or stop it.
NIST’s AI Risk Management Framework (AI RMF) is voluntary and use-case-agnostic; its Generative AI Profile applies the framework’s risk-management approach to generative AI. NIST says the AI RMF is being revised, so check the current framework and any applicable sector-specific requirements. NIST AI Risk Management Framework and NIST AI 600-1: Generative Artificial Intelligence Profile.
Map the data and trust boundaries
Trace the full path: user prompt, application, retrieval system or connected tools, model provider, logs, and response. For each step, identify what information is present, which party handles it, and what controls apply. Include data sent to external services and data returned to users.
Recommended Free Tools
#1 Best Overall
Define what may be submitted
Inventory the information the workflow could encounter, including confidential business material, personal or regulated data, customer and employee information, intellectual property, and third-party content. Set permitted sources and prohibited inputs in terms employees can follow. If a task does not need sensitive data, exclude it rather than relying on a warning to users.
Verify provider and contract terms
For the exact service and configuration, verify whether prompts, outputs, and uploaded or retrieved content may be retained, used beyond providing the service, or handled by subprocessors. Confirm deletion and backup behavior, processing locations, encryption, contractual protections, incident duties, and any geographic or regulatory constraints. Do not infer these details from general marketing language; consult current service documentation and the contract.
Rank #2
Third-party generative AI can introduce privacy, intellectual-property, and information-security risks. NIST recommends due diligence and use of standard risk controls when working with third-party GAI. NIST AI 600-1.
Enforce permissions in retrieval
If the pilot retrieves internal documents, authorization must be checked when retrieval happens—not only when documents are added to an index. Keep the user’s identity and document permissions connected to each query, and use metadata filters or an equivalent authorization mechanism so a user cannot retrieve content they are not allowed to see. Restrict who can write to or change indexes, and provide source attribution where the product supports it.
Treat user prompts, retrieved documents, memory, and tool results as untrusted input: they may contain misleading or malicious instructions. Separate system instructions from retrieved text and test whether hostile content can bypass the intended controls. Microsoft’s implementation guidance discusses these patterns; verify capabilities for the specific product and configuration. Microsoft: Security considerations for AI workloads.
Assign owners and put controls around the pilot
Make accountability explicit across governance and risk, security architecture, product engineering, privacy and legal, and operations. Apply existing procurement, privacy, and cybersecurity processes where they fit. Review the provider, service terms, security evidence, data flows, subprocessors, and incident responsibilities before enabling access. Microsoft frames AI risk management as part of broader organizational risk, cybersecurity, and privacy governance. Microsoft: Security for AI.
Rank #4
Limit access and actions
- Give users, service identities, tools, and data only the permissions needed for the pilot.
- Constrain connected tools and actions to the defined purpose; require human approval for consequential or externally visible actions.
- Use an acceptable-use policy and a clear approval path, including a named person or team authorized to stop the pilot.
- Keep system instructions distinct from untrusted retrieved content, and apply authorization checks to every relevant data path.
Keep useful, proportionate records
Decide what to log in light of privacy, access, and retention requirements. Depending on the use case, useful records may include the user, model and version, references to retrieved context, tool calls, decisions, outputs, errors, and approvals. Restrict log access and set retention and deletion rules; logs can themselves contain sensitive information. Preserve enough evidence to investigate an incident and understand what happened without collecting data indiscriminately. NIST recommends risk management across the AI lifecycle, including documented practices for third-party GAI. NIST AI 600-1.
Test before exposing the pilot to users
Establish a baseline and an evaluation set drawn from representative pilot tasks, using privacy-safe or otherwise approved data. Test with people and scenarios that reflect the intended users and operating conditions. Document the test plan, results, observed failures, mitigations, and approvals.
Include checks for:
- Task quality and consistency against the baseline.
- Whether access controls prevent retrieval or disclosure of content across users and permission groups.
- Prompt injection through user input and retrieved material.
- Exposure of sensitive information in responses, logs, or tool results.
- Unsafe or unauthorized tool use.
- Malformed, ambiguous, and adversarial inputs.
Testing is not a one-time launch gate. NIST recommends early, iterative, documented testing, evaluation, validation, and verification (TEVV) throughout the AI lifecycle. Repeat relevant checks after material changes to the model, provider, connected data, tools, or user population. NIST AI 600-1.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Monitor the pilot and set expansion gates
Track use, quality, failures, complaints, and security events against the pilot charter. Make it clear how users report problems, who assesses them, and how operators can disable access or recover from an incident. Define in advance what evidence is needed to continue, change, or stop the pilot.
Expand only when the intended benefit is demonstrated and quality, privacy, security, and operational controls meet criteria set for this use case. There is no universal NIST numerical threshold for expansion. Reassess risk when the model or provider changes, new data sources or tools are connected, the user population grows, or the use case shifts. NIST’s framework supports lifecycle-wide risk management; Microsoft’s guidance also emphasizes governance, assurance, monitoring, and response. NIST AI Risk Management Framework and Microsoft: Security for AI.
Compare options against the same boundaries
If you have more than one viable architecture or provider, compare the exact service and configuration rather than relying on a generic “enterprise-ready” label. The following are decision criteria, not claims that any particular vendor meets them:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute| Area | What to verify |
|---|---|
| Data handling | Provider use and retention terms, deletion, regional processing, encryption, and contractual protections for the specific service and configuration. |
| Authorization | Identity integration, document-level access enforcement, permission-aware retrieval, and controls against cross-user exposure. |
| Control and audit | Logging, incident response, tool permissions, human approvals, deployment isolation, and evidence available to your organization. |
| Evaluation | Support for representative tests, red-team exercises, recording model and version changes, and monitoring behavior after launch. |
| Operational fit | Integration effort, reliability, ownership, cost, exit path, and whether your team can maintain the controls. |
Confirm provider-specific claims in current primary documentation and contractual terms; security and data-handling details vary by service and configuration.
Quick Recap
A practical go/no-go checklist
- The task, intended users, benefit, and out-of-scope uses are documented.
- Allowed and prohibited data, data flows, access rules, retention, deletion, and incident responsibilities are defined.
- Provider terms and the exact configuration have been reviewed by the relevant teams.
- Retrieval and connected tools enforce the user’s permissions, and actions are appropriately constrained.
- Representative tests cover quality, security, privacy, and misuse, with results and mitigations recorded.
- Owners, monitoring, reporting, shutdown, and recovery paths are clear.
- Expansion criteria are explicit, and material changes trigger a fresh risk review.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
