Write the boundary in ordinary language
Describe the task, intended users and permitted information. State what the pilot must not do. “Draft a proposed response using approved reference documents” is different from “send the response to a customer.” If the test does not require sending, keep sending outside its permissions.
Specify where the pilot runs and who can change it. Record the model or service, connected tools and configuration version. A useful boundary also names the human owner who can stop the trial and the team responsible for unexpected behavior. Avoid shared ownership that leaves no one able to act.
Review data before uploading it
Use approved non-sensitive or synthetic examples where they can answer the pilot question. Synthetic examples are not proof of performance on real data, so record that limitation. If real data is necessary, confirm the permitted purpose, access, retention and handling arrangements through the organization's existing review process.
Do not assume a provider's product label determines whether your specific use is acceptable. Review the actual service configuration and relevant terms. This website cannot establish whether a particular data transfer meets your contracts, policy or legal obligations.
Separate suggestion from execution
For any connected action, identify the resource, permitted operation and scope. Read-only access can still expose information, while write access can alter it. Give only the access needed for the test. Where an action has meaningful consequences, define the review point before execution and what evidence the reviewer must see.
- Data: Which sources and fields are allowed?
- Actions: What may be read, changed or sent?
- Approval: Who authorizes consequential steps?
- Visibility: Which events and failures are recorded?
- Stop: Who can disable access and restore the ordinary workflow?
Test the boundary, not only the happy path
Use authorized, controlled test cases to check how the workflow handles missing sources, conflicting instructions and out-of-scope requests. If a document contains text that asks the system to disregard its task, that content should not become authority to change permissions. A prompt alone is not a substitute for access controls.
Review what happens when the model is uncertain, a tool fails or the human reviewer is unavailable. The fallback should be explicit, such as returning to the existing manual workflow, rather than silently proceeding. These exercises expose control gaps; they do not prove the system can withstand every attack.
Make stopping ordinary
A stop condition should describe observable behavior. Examples include access to an unapproved source, an action without the required approval or a material failure that cannot be safely contained. Agree on these conditions before launch. Pause the experiment when a condition is met, preserve appropriate evidence and use the organization's incident process when needed.
Record your boundaries →