A bank's compliance team is building an internal document-review tool in Microsoft Foundry and needs to inspect the model's architecture directly, retrain it on-premises with sensitive financial data, and avoid ongoing per-token API charges once it is deployed. Which choice from the Foundry model catalog best fits these requirements?
Select an answer to reveal the explanation.
Short Explanation
When a team says they need to look inside a model, retrain it themselves on their own servers with sensitive data, and stop paying per use, that's really a question about licensing and where the model can live, not about how creative or careful its answers sound. Some models in a catalog are offered only as a locked box you call over the internet and pay for by usage, while others come with their weights published so you can download them, examine how they work, and retrain them entirely within your own walls. For a compliance team handling sensitive financial records, that second kind is the only option that actually satisfies the requirement to inspect, retrain locally, and avoid recurring API costs. Turning up variability in the wording or tightening what content gets blocked doesn't touch any of those three requirements, those levers live somewhere else entirely. The decision here comes down to whether the model's internals and hosting location are open to the team or locked behind someone else's service.
Full Explanation
The correct answer is D. Open-weight models publish their weights under licenses that allow downloading, inspecting, and modifying the model, which lets the compliance team retrain it on their own infrastructure with sensitive data and avoid per-token charges from a hosted API, satisfying both the inspection requirement and the cost and data-residency concerns. Option A is incorrect because a large proprietary hosted model, even if highly accurate, is typically accessed only through an API with weights kept private, so it cannot be inspected internally or retrained on-premises and still incurs per-token usage costs. Option B is incorrect because temperature is a generation parameter affecting output variety, it has no bearing on whether the team can access model internals, retrain locally, or eliminate API fees. Option C is incorrect because content-filtering strictness controls what kinds of generated text are blocked, it does not change the licensing terms, hosting location, or cost structure of the underlying model. Given the team's need for internal inspection, local retraining, and cost control, the licensing and deployment model of the chosen catalog entry is what matters, making the open-weight option the fit.