1. Which workflow are you improving?
Describe what happens today: who starts the task, which systems they use, what slows them down and what a completed task looks like. “Use AI” is a technology choice. “Help staff find approved answers to common service questions” is a workflow that can be evaluated.
Choose one repeatable task for the first pilot. Record a baseline, such as time spent finding an answer or the proportion of requests that require rework. A narrower scope makes it easier to understand whether the application helps.
2. What information may the application use?
List the approved sources and their owners. Separate public material from internal records, customer information and credentials. Decide whether a prototype can run on sample or de-identified information before giving it access to production data.
Review the proposed provider's data handling, retention, access controls and contractual terms. A model that produces a convincing answer does not establish that the data flow is appropriate. Keep secrets out of prompts and define who can approve additional sources.
3. What is the application allowed to do?
Separate answering a question from taking an action. Reading an approved help article carries different consequences from changing an account, sending a message or approving a transaction. Give a pilot the smallest set of permissions needed for its task.
Write down prohibited actions and an escalation path. If a request falls outside the approved scope, the application should direct the user to a person or an existing process. Tool integrations need their own authorization checks; instructions in a prompt alone are not an access-control system.
4. When does a person need to review the result?
Identify the consequences of a wrong or incomplete answer. Decide which outputs can be shown as a draft, which require approval and which should never be generated for the use case. Tell users when they are interacting with AI and how to reach a person.
For a customer-facing assistant, define the information it can discuss, the topics it must escalate and how visitors can contact your team. Human review should be part of the workflow, with a named owner, rather than an assumption that someone will notice a problem.
5. How will you test usefulness and boundaries?
Build a small set of representative questions before launching. Include straightforward requests, unclear requests, missing information and questions outside the approved scope. Write down what an acceptable response looks like for each example.
Test attempts to extract restricted information, override instructions or misuse an integration. Review factual accuracy, appropriate refusal and whether the user can complete the task. Repeat the relevant checks after changes to the model, prompt, data sources or permissions.
6. Who owns operations after launch?
Assign responsibility for access, content updates, error review, costs and incident handling. Decide what telemetry is necessary and avoid collecting information simply because the platform makes it available. Define retention and permissions for any stored logs.
Plan a fallback if the model or a connected service is unavailable. Set a usage budget and alerting appropriate to the pilot. A successful demonstration needs an operating plan before it becomes a service that customers depend on.
7. What decision will the pilot support?
Choose a limited audience, a review date and success criteria before the pilot starts. Compare results with the baseline and record both useful outcomes and failures. Decide what would justify expanding the scope, changing the approach or stopping the project.
Expansion should follow evidence. Adding more users, private data or automated actions changes the risk and operating requirements. Review those changes separately rather than carrying the pilot's assumptions forward.
A simple brief to bring to your first consultation
- The workflow and people involved.
- The business outcome and current baseline.
- Approved information sources and data restrictions.
- Actions the application may take and required human approvals.
- Test examples, success criteria and known failure cases.
- The owner, budget boundaries and target review date.
You can describe these at a high level without sharing confidential records. Blue Scorpion Labs offers AI development consulting and security testing consulting to help businesses plan an appropriate scope.
Discuss your AI project