Mitigating in Layers: Four Places to Intervene

Why one mitigation is never enough

When a learner first hears that a generative model can produce harmful output, the instinct is to reach for a single fix — a filter, a stricter prompt, a better model. Microsoft's responsible AI guidance rejects that framing. Mitigation is described as an iterative, layered activity, and the guidance names four distinct layers where you can intervene: the model, the safety system, the application, and the positioning. This slice is about what each layer can and cannot do, and why a harm usually needs treatment at more than one.

The layers are worth memorising in order, because they run from the least controllable to the most controllable. You have almost no influence over the model's internals and almost total influence over what you tell your users.

Layer one: the model

At the model level, mitigation means choosing well and understanding what you chose. The guidance asks you to review which base model actually suits the system you are building, and to educate yourself about its capabilities, limitations, and the steps its developers took to reduce risk — for example, the reinforcement learning methods used to align a model toward its designers' intended goals. System cards published by the model developer are named as the reference for this, alongside the Transparency Note.

The practical instruction is to experiment across model versions, including through red teaming and measurement, because harms present differently from one version to the next. That is the part learners skip. A model upgrade is a risk event, not just a capability upgrade.

Layer two: the safety system

The safety system layer is the platform-level machinery that sits between your application and the model — in Microsoft Foundry, the guardrails that were previously called content filters. Their job is to help block harmful content from reaching the user. Your responsibility at this layer is not to build the classifiers but to identify what the platform offers and evaluate how effective it is against the specific harms on your prioritised list.

The word "help" is doing real work in that description. A safety system reduces the rate of harmful output; it does not reduce it to zero, and it knows nothing about harms outside its categories.

Layer three: the application

This is the layer application developers own, and it splits in two. The first half is prompt engineering, particularly the metaprompt — also called the system message or system prompt. Metaprompts are the instructions you give the model to guide its behaviour, and the guidance describes their use as making a critical difference in keeping a system behaving as you expect.

The second half is user-centred design, and it is the half most engineering teams under-invest in. The specific interventions listed are concrete enough to design against: build the experience so people review and edit AI-generated output before accepting it; highlight potential inaccuracies both at first run and during ongoing use, and mark the kinds of content your measurements showed to be weak; remind people that they remain accountable for the final content; disclose that the user is interacting with an AI system, and where appropriate that content was AI-generated; reduce anthropomorphising outputs that imply the system is human; cite the sources a response was drawn from; limit the length, structure, and rate of inputs and outputs; prepare predetermined responses for queries that would otherwise invite an inappropriate answer; and restrict automated posting of generated content to external sites.

Notice how many of these are not about blocking anything. They are about calibrating reliance — helping a user form an accurate picture of how much to trust what they are reading.

Layer four: positioning

The outermost layer is how the system is presented to the people who use it or are affected by it. Three actions are named: be appropriately transparent so people can make informed decisions about using the system; provide system documentation that explains capabilities and limitations, for instance as a "learn more" page reachable from the product; and publish user guidelines and best practices, ideally woven into the experience rather than buried in a help centre.

Positioning is cheap and often decisive. A capable system used with unwarranted confidence causes more harm than a weaker one used with appropriate scepticism.

The loop that closes it

The guidance is careful to say that not every mitigation is appropriate for every scenario, and that these mitigations may be insufficient for some scenarios. That is why layering is paired with measurement: after implementing mitigations you repeat the measurements from the measure stage to test whether they actually worked, document the results, and use them to improve the system.

Common mistakes

The first is treating the safety-system layer as the whole answer, which leaves grounding, overreliance, and misuse untouched. The second is writing a metaprompt and never testing it against adversarial inputs. The third is calling the loop closed after one pass — mitigation is defined by repetition, not by a single deployment.

How this connects to the principles

The layers make the abstract principles operational. Transparency lives at the positioning layer and in disclosure. Accountability lives in review-and-edit design and the reminder that the human owns the final content. Reliability and safety are split across all four, which is the point: no single layer can deliver a principle by itself.