AI Safety and Ethics

Safety is not a policy doc I link in the footer. It is what the model is allowed to see, say, and do.

I learned this the unglamorous way: any text you retrieve is untrusted, including your own docs if a user can edit them.

The issues I design for

• Prompt injection attacks — instructions hidden in user text or in a retrieved page
• Security and privacy concerns — secrets in prompts, logs that store customer data forever, training on data you promised not to keep
• Bias and fairness — the model repeats patterns from training data. A hiring or lending feature that “just uses GPT” can discriminate. If the decision matters, a model should not be the only judge
• Understanding AI safety issues in product terms: wrong medical advice, leaked tenant data, a tool call that deletes something because a prompt said please

What I actually add

Robust prompt engineering still helps. State the rules. Tell the model that retrieved text is data, not instructions. That is necessary and not sufficient.

Constraining outputs and inputs:

• Schema-validate the output. Reject anything else.
• Allow-list tool names and argument shapes.
• Do not put API keys, raw passwords, or other tenants’ data in the prompt.

OpenAI Moderation API (or the equivalent on another host) runs on input and on output for user-facing text. If it flags the message, I refuse or rewrite. I do not argue with the user about the flag.

Adding end-user IDs in prompts — I pass a stable user id to the API when the provider supports it, so abuse can be traced and banned. The id is not a secret, and it is not something I ask the model to repeat.

Conducting adversarial testing before launch:

• “Ignore previous instructions”
• A retrieved doc that says to call a dangerous tool
• Requests for other users’ data
• Harmful content the product claims to refuse

Know your customers / use cases. A docs bot and a kids’ tutor do not get the same tools or the same tolerance for edgy jokes. I write the use case down so the safety checks match the harm.

Safety best practices I keep on a list

1. Secrets never enter the model context
2. Retrieved text is data, labeled as data
3. Tools are few, typed, and idempotent where I can make them so
4. Moderation on the way in and the way out
5. Logs redacted, with a retention limit
6. A kill switch for the feature

Next

Once the limits exist, you still need to know if quality holds:

• Evals and Observability