A few things to settle
so you can use it freely

What this part covers

This is not an argument against using AI. It is about drawing a line between what you can use freely and what deserves a second thought. A clear line makes people more willing to use it, not less.

6.1Deciding what not to submit

The most reliable approach is not to submit it at all. Most work can be done without identifying information.

Basic principles

How to mask

In most cases replacing names with labels is enough. It is rare that the name itself is needed for the judgment.

6.2The Playground and your data

Even with the same model, where you use it changes how your data is handled. This distinction matters.

6.3Looking after your API key

An API key is a key that lets someone send requests as you. If others learn it, your credits can be spent.

import os

api_key = os.environ["UPSTAGE_API_KEY"]   # the value stays in an environment variable

6.4How far to trust the output

AI output is a draft and a reference. It helps to decide in advance where you can use it as is and where you must check.

Making checks easier

• Require the reasoning. Asking for "one sentence of justification" or "the page it came from" makes verification quick.
• Let it say it does not know. Add "if it is not in the material, say 'not found'".
• Add a "needs check" verdict. Ambiguous cases then route to a person automatically.

6.5Guiding a class

When using this with students, it helps to set out a few things before you begin.

6.6[Activity] Write a policy

Working alone, your own judgment is enough. Working together, it needs writing down. One page will do.

A. Blank template

# AI use policy for [organization] (one page)

## 1. Where we use it
- Permitted tasks:
- Owner:

## 2. Material we do not submit
-
-
-

## 3. Material we mask before submitting
- What:
- How:

## 4. Where we use it
- Real material: API / Studio
- Feature testing: Playground (sample material only)

## 5. What a person always checks
- Fields:
- Who checks:

## 6. API keys
- Issued per person or shared:
- Where they are kept:
- What to do if one leaks:

## 7. If something goes wrong
- Contact:
- What to record:

## 8. When we revisit this
- Review interval:
- Owner:

B. A worked example — a nonprofit

# AI use policy for [Foundation] (one page)

## 1. Where we use it
- Permitted tasks: checking expense receipts, reviewing funding calls, tidying meeting notes
- Owner: Operations team, [name]

## 2. Material we do not submit
- Donor lists (where names, contacts, and amounts appear together)
- Case notes containing beneficiary personal data
- Documents containing bank account numbers

## 3. Material we mask before submitting
- What: applicant names and contact details in applications
- How: replace with "Applicant A" and similar labels

## 4. Where we use it
- Real material: Studio (agent links shared internally only)
- Feature testing: Playground (blank form templates, not real applications)

## 5. What a person always checks
- Fields: amounts, organization names, submission deadlines
- Who checks: the officer responsible for that programme

## 6. API keys
- Issued per person
- Kept in each person's environment variables, never in shared documents
- If one leaks: delete it in the console immediately, reissue, and tell the team lead

## 7. If something goes wrong
- Contact: Operations team, [name]
- What to record: when, what material, what symptom

## 8. When we revisit this
- Review interval: every six months, or whenever we add a new task
- Owner: Operations team

C. Checklist

• Material you will not submit is described specifically — by document name, not "personal data".
• You wrote how material will be masked.
• You separated Playground use from real work.
• You named the fields a person checks and who checks them.
• You decided how API keys are managed.
• You wrote down who to contact when something goes wrong.
• You set a date to revisit this.

That is everything

You have been through setup, real use, and safe practice. Well done.