Generally safer to paste
Public information, generic drafts, synthetic examples, and non-confidential text already cleared for external sharing.
Module 3
Practical Controls
The central question remains the same: should this AI output be allowed to affect the real world without review?
The three control sections answer one verb each: what to check before you paste, before you trust, and before you automate.
Sub-Module 3.1: Before You Paste
Pasting information into an AI system is an action with consequences. What you put in may be stored, logged, used for training, or seen by others depending on the tool, account type, and organizational agreement.
Not safe without approval
Personal data, financial data, secrets, proprietary material, regulated data, legal filings, medical records, HR decisions, and compliance records.
Rule: If you would not post it in a public forum, do not paste it into an AI system until you understand the vendor, account type, data retention policy, and your organization's approved use.
Maintenance note: Vendor data-handling policies change. Verify current policy directly with your vendor before relying on any opt-out procedure.
How to verify: Look for the vendor’s privacy policy, data processing agreement, or help documentation. The answers change — these questions do not: Is my data used to train the model? How long are prompts and outputs retained? Who has access to them? Is there an opt-out, and where is it?
EU AI Act resources provide regulatory context on data handling obligations for organizations operating in or serving European markets. See the Appendix for the primary source and a readable summary.
Sub-Module 3.2: Before You Trust
An output can look correct and be wrong. It can cite sources that do not exist. It can omit the one fact that changes the answer.
- Identify the specific claim or output you are relying on.
- Identify the consequence if it is wrong.
- Check the claim against a primary source you already trust.
- Ask the AI what is uncertain, what assumptions were made, and what is missing.
- Run the same query with different wording and compare outputs.
- Record the human decision, not just the AI output.
Case Study: When Plausible Output Is Not Validated Output
I built an AI-assisted trading signal generator. Outputs looked coherent. The logic appeared sound. The formatting was professional.
When I backtested against historical data, the signals failed consistently. I tested multiple prompt variations and found that small changes in wording produced meaningfully different results — sometimes inverting the signal entirely. A model that described a risk control did not implement it correctly. The system was not ready for automation. It required human review at every step, a testing protocol I had not budgeted for, and a timeline that expanded as a result.
Plausible output is not validated output. In trading, that difference creates real loss. In business, it creates decisions made on bad information. Build your verification step before you build your automation — not after something breaks.
That lesson applies to any high-stakes use, not only trading.
- Did I run this prompt more than once, with variation?
- Did I check at least one specific claim against a primary source?
- Did I ask the AI what it might have missed or assumed?
- Is there a human reviewer before this output influences a decision or action?
- If I am wrong, what is the consequence?
Sub-Module 3.3: Before You Automate
Automation is where AI risk changes category. A bad draft can be corrected. A bad automated action can propagate before anyone notices.
Never paste credentials, API keys, or secrets into a chat interface.
Never give AI broad, unmonitored access to email, files, production systems, customer accounts, payment systems, trading platforms, or administrative tools.
Use vaults for secrets. Use scoped credentials. Build approval gates. Maintain logs. Define revocation procedures before you need them. Test in isolation before deploying to production.
No automation at Medium risk or above should be deployed without a documented rollback procedure executable in under five minutes.
What a rollback procedure looks like
Who executes it: Name the person responsible before deployment — not during an incident.
What step disables or reverts it: One specific, documented action. If this step requires more than one person or more than one action, the procedure is incomplete.
How you confirm it took effect: One observable outcome. If you cannot describe this before deploying, you are not ready to deploy.
| Control | Purpose |
|---|---|
| Human approval gate | Prevents AI from becoming the decision-maker. |
| Scoped permissions | Limits what the system can access or change. |
| Logging | Creates an audit trail for review and liability. |
| Revocation capability | Allows access to be shut off quickly. |
| Test environment | Prevents live damage during experimentation. |
| Error handling | Defines what happens when output is uncertain or wrong. |
| Escalation path | Identifies who decides when the system fails. |
| Documented rollback procedure | Ensures recovery is possible and fast. |
| Periodic retesting | Detects drift and degradation over time. |
Human-in-the-loop is mandatory at High and Critical risk levels. This is not a best practice. It is the rule.
OWASP LLM Top 10 documents the most common technical attack vectors for deployed AI systems. Reference it when building any production deployment. See the Appendix for the full citation.
Sub-Module 3.4: Building a Small AI Policy
A policy does not need to be long. Anyone in your organization should be able to answer three questions from it: what is allowed, what is not, and who decides.
| Policy Area | Required Decision |
|---|---|
| Approved tools | Which AI tools may be used, by whom, for what? |
| Data rules | What may never be pasted, regardless of tool or setting? |
| Review rules | Which outputs require human approval before action? |
| High-risk uses | Which uses are restricted or prohibited entirely? |
| Logging | What must be recorded, and where? |
| Incident response | What happens after a mistake, leak, or unsafe output? |
| Ownership | Who is accountable for AI-assisted work and its consequences? |
If this AI output disappeared or was proven wrong right now, what is the worst thing that would happen?
| Answer | Risk Level | Action |
|---|---|---|
| Minor inconvenience, easily corrected | Low | Proceed with standard review. |
| Disruption to a team or process, recoverable | Medium | Add a review step before output is acted on. |
| Professional, financial, or regulatory consequence | High | Verify with a qualified expert or primary source before acting. |
| Irreversible harm — financial loss, legal exposure, safety impact | Critical | Do not proceed without formal controls and documented human approval. |
If you cannot answer the question, that is itself an answer. Stop and clarify before proceeding.
Disclaimer: These templates are starting points for organizations without existing AI governance. They are not legal documents. Consult qualified legal counsel before implementing any policy.
NIST AI Risk Management Framework provides a rigorous governance foundation for organizations that need to scale beyond these starting points. See the Appendix for the full citation.
Put These Controls Into Practice
This guide gives you the framework. The Template Kit gives you the working documents — six formatted checklists and policy templates from Modules 1 through 3, ready to use in Word or PDF.
Get the Template Kit — $37