Scoping the Use Case: Where Responsible AI Starts

The decision that sets the ceiling

Most learners meet responsible AI as a list of six principles and assume the work happens late: build the application, then attach a filter. The Transparency Note for Azure OpenAI models pushes the other way. Its longest sections are not about configuration at all — they are about which uses a generative model is suited for and which it is not. That ordering is deliberate. The use case you choose sets a ceiling on how safe the finished system can be, and no runtime control raises that ceiling by much.

This slice covers that first decision: how Microsoft describes intended uses, the boundaries it asks you not to cross, and why an early "no" counts as a responsible-AI control in its own right.

Intended uses are narrow on purpose

The Transparency Note publishes a list of intended uses for text models, and reading it closely teaches far more than memorising it. Almost every entry carries a qualifier. Conversational agents are described as answering from trusted documents such as internal company or support documentation. Question answering and search are framed as retrieval over trusted source documents rather than open recall. Summarisation is scoped to predefined topics built into the application, explicitly not an open-ended summariser. Writing assistance is bounded to business content or predefined topics.

The pattern is that an intended use is a bounded use. Two applications can call the same model with identical parameters and land on opposite sides of the line: one summarises call-centre transcripts your organisation already owns, the other summarises whatever a stranger pastes into a box. Only the first sits inside the described envelope. When a scenario question appears on the exam, the giveaway is usually whether the input domain and the topic range are constrained.

The boundaries the document draws

Four cautions recur. Open-ended, unconstrained generation is called out because letting users generate on any topic raises the chance of offensive output, and longer generations make that worse. Scenarios that depend on up-to-date, factually accurate information are excluded unless human reviewers are in the loop or the system is searching your own verified documents — the service has no knowledge of events after its training date and may have gaps on some topics. Scenarios where use or misuse could cause significant physical or psychological injury, such as diagnosing patients or prescribing medication, are to be avoided. So are scenarios that bear on a person's legal status or their access to credit, education, employment, healthcare, housing, insurance, or social welfare benefits.

Two further considerations sit alongside those. High-stakes domains such as healthcare, finance, and legal deserve extra scrutiny even when the individual task looks harmless. And organisations must evaluate their own legal and regulatory obligations, because Foundry Tools are not designed for, and may not be used in, ways prohibited by applicable terms of service and relevant codes of conduct.

Human oversight is a mitigation, not a permit

The document repeatedly offers meaningful human review and oversight as a way to reduce risk in borderline scenarios. Learners often read that as a checkbox that unlocks anything. It is not. Review is meaningful only when the reviewer has the time, the context, and the authority to overrule the system, and when the interface makes disagreement easy. A confirmation button clicked a hundred times an hour is not oversight; it is a formality that transfers blame without reducing harm.

Model-specific boundaries stack on top

Different models carry different envelopes, so scoping happens per model, not once per service. Computer Use, which drives keyboard and mouse from screenshots, adds a warning against irreversible or highly consequential actions — sending an email to the wrong recipient, deleting files that matter, making financial transactions, sharing sensitive information publicly, or granting access to critical systems. It asks you to define action boundaries (which actions are allowed, prohibited, or need explicit authorisation) and domain boundaries (the operating environments it is designed for). Deep research models add a citation-checking duty, since web searches may pull copyrighted material into a report. Fine-tuning is described as a poor fit when you need out-of-domain knowledge, explainability, grounding, or data that changes frequently.

Common mistakes

The first is reading the cautions as legal boilerplate rather than a catalogue of observed failure modes; each one exists because something went wrong somewhere. The second is believing that content filtering substitutes for scoping — filtering classifies harm categories in text and images and has no opinion about whether an automated screening tool allocates opportunity fairly. The third is confusing capability with suitability: a model can certainly draft a loan rejection letter, and that is precisely the scenario the guidance warns against.

How this connects to the principles

Scoping is where several principles become concrete at once. Reliability and safety show up as a refusal to deploy where inaccuracy is expensive. Fairness shows up as declining to let a model allocate opportunity. Accountability shows up as a written, reviewed record of what the system is and is not for — the artefact you hand a compliance reviewer, and the baseline everything you build later is tested against.