PettersonApps AI Course

AI at PettersonApps
Best Practices & Policy

A short course every team member takes — how we use AI to do better work, safely, and the policies we all follow.

~10 minutes 6 modules
What you'll learn

Six modules

01
Principleshow we think about AI
02
Sensitive datathe hard boundary
03
Tools & policywhat's allowed and what's not
04
Guardrailsmake the safe path the default
05
Coding with AIhow to ship responsibly
06
When things go wrongwhat to do next
If you remember one thing

Use AI freely to do better work.
But a human owns every output,
and client & confidential data
never touches an unapproved tool.

01
Principles
How we think about AI
01 · Principles

We use AI to speed up routine, data-heavy work
— and to amplify what people can do.

AI is a tool. It doesn't remove responsibility, and it never makes the final decision instead of a person.

01 · Principles

Assess the risk first

Before we build or ship anything that uses AI, we define what harm it could cause if things go wrong. The higher the risk, the more carefully we handle it — no skipping steps under pressure.

LOW

Internal helpers, drafts, tools that don't affect clients or money.

MEDIUM

Features clients see, and that influence their decisions.

HIGH

Anything touching money, safety, legal rights, large volumes of personal data, or many people at once.

The next three slides break each level down — examples plus how to use AI.

01 · Assess the risk

Low risk

Internal helpers and drafts that don't affect clients or money.

  • Internal throwaway scripts and one-off automation
  • Drafting a README, docs, or code comments
  • Brainstorming names, ideas, or approaches
  • Reformatting, renaming, or converting data
  • Summarizing an internal note or thread
  • Explaining an error or unfamiliar snippet
Using AI here

Green light — use AI freely. Standard review is enough; just don't paste anything sensitive.

01 · Assess the risk

Medium risk

Things clients see, and that influence their decisions.

  • Customer-facing UI copy and microcopy
  • A report or analysis a client will read
  • A recommendation, ranking, or suggestion feature
  • Content published under our name
  • A prototype shown to a client
  • Non-critical logic in a client-facing feature
Using AI here

Use, then verify — a human reviews everything before it reaches a client. Check facts, tone, and edge cases.

01 · Assess the risk

High risk

Money, safety, legal rights, bulk personal data, or many people at once.

  • Payment, billing, or checkout logic
  • Authentication and authorization
  • Health, legal, or financial outputs
  • Bulk processing of personal data (PII)
  • Anything deployed to many users unattended
  • Safety-critical or irreversible actions
Using AI here

AI assists, it never decides — mandatory expert review, extra testing, approved tools only. When in doubt, don't.

01 · Principles

Rules we never bend

1
Responsibility stays with people

A person with the right knowledge and authority makes the final call and signs off. Whoever ships the system owns the results — including what happens next.

2
Verify first, then trust

We don't take AI output on faith. Run and review the code, check the facts, confirm packages and sources exist. On medium and high risk, test how it behaves in unusual and adversarial conditions.

3
Data protection is the hard line

The one rule we never bend. Personal data, client secrets, and our own confidential information are protected by default: collect only what's needed, use it only for the stated purpose, and never send it to tools that can't guarantee the same protection.

01 · Principles

Rules we never bend

4
Minimum privileges for AI

Secrets and powerful capabilities are closed by default. Access is opened deliberately, temporarily, and only for the specific task. Agents and tools run with the smallest set of permissions possible.

5
The same (or higher) bar as human work

AI-produced code, text, analysis, or decisions go through the same reviews, tests, and security checks as if a person wrote them. On high risk the bar is higher — and we keep watching behaviour after release.

01 · Principles

We stay honest about AI's role

  • Say clearly where AI was used, what it did, and its known limits — inside the team and with clients.
  • Where it matters, keep records so a decision can be understood later.
  • Be open with the team when a significant part was AI-generated or heavily assisted — it tells reviewers to look closer and keeps our process honest.
  • Don't hide AI involvement from clients when it materially affects what we deliver.
01 · Principles

Putting it into practice

  • The maker owns it — whoever creates the work is responsible for its quality and for following these rules.
  • The reviewer shares it — whoever reviews and approves the work shares that responsibility.
  • Confirm project rules — especially for client and Restricted data, with the project lead.
  • When in doubt, ask — before using AI, not after.
  • Report incidents fast — tell the lead quickly. This is not about blame.
Note These principles guide everyday decisions — not heavy process.
02
Sensitive Data
The hard boundary
02 · Sensitive data

The golden rule

Assume it's kept

Anything you send to a public AI tool may be retained, logged, or used for training. Only approved tools with clear no-training and zero-retention terms are treated differently. When in doubt, treat it as public.

Current setup

Right now we use personal accounts (including paid ones). We treat them as public tools and use them with Public data only. For Confidential or Restricted data, don't use AI tools without additional approval.

Policy Client terms & NDAs always override this — check the project rules before sharing anything.
02 · Sensitive data

Can I put this into AI?

A five-second gut check before you paste anything. Work top to bottom — the first match wins.

Secrets — passwords, keys, tokens, .env?
Never
Client data under NDA, personal data (PII), payment or health data?
Written client OK only
Proprietary logic, architecture, or financials?
Approved tool · redact
Public — fine to publish (OSS, docs, marketing)?
Any approved tool
Anything else — internal & generic
Approved business tool
02 · Sensitive data

Public data

Already public — no harm if it's seen.

  • Open-source code and public libraries
  • Published docs, blog posts, marketing copy
  • Anything already on our site or public GitHub
  • General "how do I…" programming questions
Verdict

Any approved tool is fine.

02 · Sensitive data

Internal data

Generic, non-sensitive material that stays inside the company.

  • Generic internal snippets with no secrets
  • Boilerplate and scaffolding
  • Internal process notes without client specifics
  • Draft docs that stay in-house
Verdict

Approved business-tier tools, training off — not free tiers that train on inputs.

02 · Sensitive data

Confidential data

Proprietary to us — real damage if it leaks.

  • Proprietary logic and architecture
  • Financials, roadmaps, pricing
  • Non-public personnel or business data
  • Internal designs we wouldn't want leaked
Verdict

Approved enterprise tools only, minimized and redacted.

02 · Sensitive data

Restricted data

The hard line — never goes to an unapproved tool.

  • Client source or databases under NDA
  • Credentials, secrets, API keys, .env
  • Personal data (PII), payment or health data
  • Anything a contract says can't leave the client
Verdict

No AI unless the client approved the specific tool in writing.

02 · Sensitive data

Handle it safely

Never paste into AI

  • Passwords, API keys, tokens, .env files
  • Client source code or databases under NDA
  • Personal data (PII), payment or health data
  • Trade secrets & proprietary algorithms
  • Full production logs or real customer records
  • Screenshots or recordings containing any of the above

Do this instead

  • Keep secrets in a secret manager, referenced by env
  • Redact — placeholders for real names, keys, IDs
  • Reproduce bugs with minimal synthetic or anonymised data
  • Scan before commit with gitleaks
  • Unsure how to classify it? Ask a colleague or lead
Already pasted something sensitive?

Stop using that chat, don't continue the conversation, and follow the incident process — see Module 06 · When things go wrong.

03
Tools & Policy
What's allowed and what's not
03 · Tools & policy

What's allowed

CategoryExamplesStatus
Coding assistants (business tier)Claude / Claude Code, Copilot, CursorRecommended
Chat assistants (enterprise)Claude Team/Enterprise, ChatGPT TeamRecommended
Free consumer tiersFree chatbots, browser add-onsPublic data only
Unvetted tools / MCP serversUnknown plugins, "free GPT" sitesAvoid
Any tool on Restricted data—Needs written OK
Policy Want to use a new tool? Get it vetted by AI Enablement before it touches any client or internal data.
04
Guardrails
Make the safe path the default
04 · Guardrails

Don't rely on memory — enforce it

The best safety rules are the ones the tool enforces. We put guardrails into the dev environment, committed to the repo, so every engineer and every AI session inherits them automatically.

1
Permissions

Declaratively block the AI from reading sensitive files — .env, keys, secrets/**.

2
Hooks

Stop risky actions before they run, and scan changes for secrets after they're made.

// .claude/settings.json
"permissions": {
  "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
}
▶ Video guide — coming soon
Any tool Cursor, Copilot, internal agents — configure them so unsafe actions are blocked by default.
04 · Guardrails

What we enforce

✓
Block secret access

The AI can't read or print .env files, keys, tokens, or secret folders.

✓
Block destructive commands

No rm -rf on important directories, no force-push to main, no overwriting critical config.

✓
Scan on every edit

After the AI writes code, we scan for secrets (e.g. gitleaks). If something is found, the change is stopped.

✓
Least privilege for agents & MCP

Agents and tools only get the permissions they actually need for the task. Everything else stays closed.

✓
Limit outbound risk

Prevent the AI from sending sensitive data to external services unless it's explicitly allowed.

Why Safety becomes "the tool won't let you," not "everyone has to remember the rules."
04 · Guardrails

Catch leaks before they ship

A secret scanner reads your diff for things that look like keys, tokens, and credentials — and stops them reaching git history. Run it at more than one layer.

1
Pre-commit

Blocks the commit locally if a secret pattern is found — the earliest, cheapest catch.

2
CI / server-side

A pipeline job re-scans every push, so nothing slips through a skipped local hook.

3
After every AI edit

A PostToolUse hook runs the scanner right after the model writes code.

Leaked anyway? Rotate first — see Module 06.
05
Coding With AI
How to ship responsibly
05 · Coding with AI

AI writes the first draft.
You are the engineer.

The moment you commit it, it's your code. It carries the same responsibility, the same review, and the same standard as if you had written every line yourself.

05 · Coding with AI

Non-negotiables

  • Understand before you commit — if you can't explain it, don't ship it.
  • Review for security — injection, broken access control, unsafe defaults, secrets in code, and other common vulnerabilities.
  • Verify dependencies are real — AI invents package names; attackers register them.
  • Own the tests — never let the model be the only one checking its own work.
  • Same PR review — AI-generated changes get no fast lane or special treatment.
  • Watch the blind spots — error handling, edge cases, and unnecessary complexity.
05 · Coding with AI

How to review AI output

AI can sound confident even when it's wrong. Review with that in mind.

For code

  • Read the full diff, not just the summary
  • Check error handling, edge cases, and assumptions
  • Look for over-complicated or unnecessary code
  • Make sure you can explain every important part

For text, analysis & recommendations

  • Verify key facts and sources
  • Check tone and claims fit the audience
  • Remove anything you can't stand behind
Simple test If you wouldn't be comfortable explaining it to a client or in a post-mortem, don't ship it yet.
05 · Coding with AI

Where to lean in — and hold back

Strong fit

  • Boilerplate, scaffolding, and migrations
  • Test drafts, docstrings, and READMEs
  • Refactors on code you already understand
  • Explaining errors and unfamiliar code
  • Exploring alternatives — you still choose

Keep human-led

  • Core architecture and design decisions
  • Security-critical logic, auth, and payments
  • Anything that touches Restricted data
  • Performance-critical or highly concurrent code
  • Final sign-off on correctness and readiness
Simple rule Use AI to move faster on work you already understand; keep full human control where mistakes are expensive or hard to catch.
06
When Things Go Wrong
What to do next
06 · When things go wrong
Rotate, don't just delete

Once a secret reaches a remote system, a log, or any external tool (including AI), treat it as compromised — assume it was copied almost immediately. Deleting the file or rewriting git history does not make it safe again. You must rotate it. Cleanup only stops further exposure.

06 · When things go wrong

The runbook, in order

1
Contain

Disable or tightly scope the credential right away; revoke active sessions if you can.

2
Rotate at source

Create the new secret first, deploy it, then revoke the old one — don't take prod down.

3
Assess exposure

Check provider audit logs & billing for unauthorized use. If it was a client's, involve the right people early.

4
Clean up

Remove it from code, logs, and chat history. Rewriting git history (filter-repo / BFG + force-push) is sometimes needed — do it carefully and coordinate.

5
Report

Tell your lead or security contact promptly. Not a blame event — fast reporting beats perfection.

6
Prevent

Strengthen the basics: .gitignore, secret scanning, deny-lists + hooks, a proper secret manager.

06 · When things go wrong

Special case: secret pasted into an AI tool

Pasted a secret into ChatGPT, Claude, Cursor, or similar? Treat it exactly like a public leak.

  • Treat it as compromised — same as any public leak.
  • Stop using that chat.
  • Rotate the secret.
  • Delete the conversation if the tool allows it.
  • Follow the runbook from step 1.
Remember Not every leak is equal — a test key isn't a prod DB credential or an NDA client secret. When in doubt, rotate and report.
The whole policy, one screen

Do / Don't

Do

  • Own, review, and verify every output
  • Use only approved tools — training & retention off
  • Redact sensitive data; use the secret manager
  • Check the specific client & project rules before you start
  • Rotate secrets and report leaks immediately

Don't

  • Paste secrets or .env files into any AI tool
  • Feed NDA client code to unapproved tools
  • Ship code you don't understand
  • Trust facts, sources, or packages blindly
  • Blame the AI — you remain accountable for what you ship
Before you start using AI

Your setup checklist

  • Approved AI tools on your company account training & history off
  • Shared guardrails & secret scanning enabled deny-lists, hooks, pre-commit checks
  • Secret-manager access verified so you never hard-code or paste secrets
  • Project AI rules confirmed with your lead what's allowed and what's off-limits
  • You know what counts as Restricted data here the project's hard no-AI boundary
  • Security contact saved rotate & report fast if something leaks
Tip Re-check this list every time you join a new project.
That's the course

Use AI boldly.
Verify carefully.
Guard the data.

PettersonApps · AI Best Practices & Policy Questions → AI Enablement
PMs — continue with Claude for PMs · practice, not policy →
← → navigate · F fullscreen · P print
Start