Usage Policy and Safe Deployment

Access to the API is conditional on the Usage Policy. It is not legal boilerplate you can ignore; it defines what you may build, what extra safeguards certain products need, and what gets an organisation's access suspended. The exam asks you to apply the policy to scenarios, so you need its structure more than its exact wording, which changes over time and should be read from the current policy on Anthropic's site.

The structure of the policy

The Usage Policy has three layers:

1. Universal prohibitions that apply to every use: child safety violations, weapons capable of mass casualties, critical infrastructure attacks, malicious code and cyber-attacks, violent extremism, fraud and deception, election interference, harassment and abuse, privacy violations, and circumventing the safety systems of the model itself.
2. High-risk use cases that are allowed only with additional safeguards: domains where errors cause serious harm to people, such as healthcare decisions, legal and financial advice, insurance, employment and housing decisions, and anything affecting access to essential services.
3. Deployment-specific requirements, notably for consumer-facing products, products used by minors, and products that generate content at scale.

Anthropic may also publish supplemental policies for particular surfaces or industries; those sit on top of the main policy.

What high-risk deployments require

If your product falls into a high-risk category, the policy expects you to have:

• A qualified human in the loop who reviews or can override the model's output before it affects a person.
• Disclosure to end users that they are interacting with an AI and where it is used in decisions about them.
• Fitness for purpose: evaluate the system for the specific domain and population, and do not present it as a substitute for a licensed professional.

In code, this means the model produces a recommendation and a reason, a human approves, and your system records both. It is the same approval gate used against prompt injection (lesson 7-2), applied for a different reason.

Consumer-facing products

Products available to the general public, especially chat-style ones, must make clear that users are talking to an AI, must not impersonate humans deceptively, and must not be targeted at or accessible to minors unless designed and safeguarded for them with appropriate age controls. Anthropic also expects you to maintain your own abuse detection, which is why metadata.user_id exists and why your own moderation layer (lesson 7-3) is expected rather than optional.

Your obligations as the operator

• Enforce the policy on your users. You are responsible for how your deployment is used, so you need terms of service, monitoring and the ability to remove abusive accounts.
• Do not circumvent safeguards. Jailbreak prompts, fine-tuned bypasses and automated rephrasing loops to defeat refusals are themselves violations.
• Respect privacy and law. Collect only the data you need, honour data protection law for the regions you serve, and never use the API to scrape or profile people without a lawful basis.
• Secure your keys and systems, because misuse of a leaked key is still misuse under your organisation.
• Keep records of evaluations, safeguards and incidents; they are what you will show if Anthropic or a regulator asks.

Data handling and retention

Anthropic's commercial terms state that inputs and outputs sent through the API are not used to train models. Retention periods for API data are documented in the privacy and data policies; some features (such as the Files API or batch results) hold data for defined windows, and organisations with qualifying needs can request zero data retention, with the caveat that some models and features are unavailable under it. Design your own retention to match: do not keep transcripts longer than you need, and tell users what you keep.

Responsible deployment checklist

• Classify the use case against the three layers before writing code.
• Add disclosure text and an AI label to any user-facing surface.
• Build the human approval gate for high-risk outputs and log the decision.
• Run domain-specific evals, including failure modes that could harm users, and keep the results.
• Deploy input and output moderation tuned to your product.
• Publish terms of service that mirror the Usage Policy for your users.
• Set up an abuse reporting route and monitor metadata.user_id patterns.
• Review the policy on each major release; it is updated as new risks emerge.

Exam focus

• The Usage Policy has universal prohibitions, high-risk use cases requiring safeguards, and deployment-specific requirements; read the current version rather than relying on memory.
• High-risk domains (medical, legal, financial, employment, housing and similar) require a qualified human in the loop and disclosure to affected people.
• Consumer-facing products must disclose that users are interacting with an AI and must not deceptively impersonate humans.
• Operators are responsible for their users' behaviour and must not circumvent the model's safeguards.
• API inputs and outputs are not used for training under commercial terms; retention windows and zero-retention options are documented and should inform your own data policy.
• Evidence of evaluation, safeguards and monitoring is part of compliant deployment, not an afterthought.