Reviewed quarterly
Limit AI use.
Nobody should be able to paste a customer file into a prompt just because the limit was never written down. The written limit covers what can go in, what stays out, who reads the output before it leaves, and what we log. This page is that limit, kept where you can read it.
Section 1 of 5
What we will put into an AI tool.
- Public marketing copy, drafts of posts, headline variants, and any text that is already published on conversionsystem.com or on another public surface we run.
- Our own internal documentation, notes on how we work, the brand voice guidelines, and any content we have explicitly tagged as internal-only or as public.
- Aggregated analytics with the identities removed: traffic by source, conversion rates, lead scoring outputs, and how a post performed.
- Our own code may go in, which means the repositories we maintain plus the engineering artifacts that live with them: tests, schemas, configuration, and deployment scripts.
- Client work product only when that client has authorized AI processing in writing, and only inside the engagement. That authorization ends when the engagement ends.
Section 2 of 5
What we keep out of an AI tool.
- Personal identifying information for a customer or a prospect: names, emails, phone numbers, addresses, and anything else that resolves to a real human outside our team.
- Money records stay out of every prompt. That bar covers credit card numbers, bank account information, our internal financials, client billing data, and payment processor tokens.
- Anything covered by an NDA, a mutual confidentiality agreement, or a client-specific clause about how data is handled. When you are not sure, the answer is no.
- Secrets never go into a prompt. The list is API keys, passwords, tokens, webhook secrets, and JWT secrets. The bar holds in development, and it holds when someone calls the paste "just for testing." The
loggerutility redacts these from logs. A prompt does not receive that same protection by default. - Regulatory data: anything covered by HIPAA, PCI, GDPR, CCPA, or an industry rule that governs a business we work with.
Section 3 of 5
Who reads the output before it leaves.
- The named owner of the workflow reads every output before it ships to anyone outside the company. That is one person, and their name is on the deliverable, rather than a group that never opens the file.
- Public-facing copy, including posts, landing pages, emails, and social posts, is read by the named author for voice, accuracy, and brand compliance, and that read includes banned words and any number that names a result.
- Generated code faces the same bar as code a person wrote. That bar is TypeScript strict, tests required, and the brand and security anti-patterns enforced. CLAUDE.md holds the anti-pattern list, and that list is the floor.
- Work we hand a client, including plans, blueprints, and sprint reports, is read by the engagement owner before it leaves our system. A claim in that work carries a name, a number, and a date.
Section 4 of 5
What we write down about each run.
- Which AI tool ran, what kind of task it was, who ran it, and when. That record is part of ordinary session telemetry under
~/.gstack/analytics/for internal sessions. - The prompt itself is not logged word for word, because a prompt can carry a client snippet that confidentiality covers. We log a hash and a category instead.
- Server-side logs use the redacting
loggerinsrc/utils, which strips any field whose key matches/api[_-]?key|secret|token|password|authorization|webhook[_-]?secret|bearer/ibefore the line is written. - Lead capture, including the plan form, benchmark submissions, and contact forms, logs only the data that crosses the form boundary. That path runs through
processLeadSafelyand is tagged with attribution the person consented to.
Section 5 of 5
How the policy stays current.
- We review it every quarter, in the same meeting where we review security policy. That review either confirms that nothing changed or amends the policy, and either way the date at the top moves.
- Tool selection includes this policy. We do not buy a new AI tool without a written check against it. The check names the data the tool will see, the person who owns the workflow, and the criteria that would make us stop using it within 90 days.
- Onboarding names this policy. Day one for a new hire includes reading it and signing that the read happened. When a sentence on this page does not make sense to that hire, we treat the sentence as a defect and we fix the policy.
- The policy stays reachable at
/ai-policyfor as long as we keep operating. The git history ofsrc/routes/pages/ai-policy.tsis the public revision log.
Related pages
Where the same rules show up in the work.
Get your free Systems Plan
Use the plan when you need to decide which job a system should run, which data it can touch, and where a person still has to review the output.
Open thisSystems for one job.
Each system is planned around one job, a review step, and a handoff you can see, before anything a customer would read leaves the system.
Open thisConversion Skills
The library a build runs on is free by request. It holds the patterns we use for search, research, proof, and the handoff of a job.
Open thisThe readiness check.
Ten questions about how the week is done today, so you can see which jobs are still by hand before you decide a system is worth building.
Open thisNext step
Want to write your own?
Take the readiness check, then write the limit in your own words. You can copy the structure of this policy, which is what can go in, what stays out, who reviews the output, what gets logged, and how the policy stays current. You cannot copy the answers, because the answers depend on your data and on your clients.