> For the complete documentation index, see [llms.txt](https://docs.themspkb.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.themspkb.com/ai-for-msps/foundational-ai-concepts/foundation-models.md). # Foundation Models ### Summary **Foundation model** is the term coined in a 2021 Stanford report (*On the Opportunities and Risks of Foundation Models*) for a model that is **trained on broad data at scale and then adapted to a wide range of downstream tasks**. [BERT](/ai-for-msps/foundational-ai-concepts/bert.md) and [GPT-3](/ai-for-msps/foundational-ai-concepts/large-language-models.md) are the canonical examples. The report's contribution is not a new model but a new *lens*: it names the category, identifies two defining properties — **emergence** and **homogenization** — and argues that as more of the world's software comes to depend on a handful of these base models, their flaws, biases, and failure modes get inherited by everything built on top. It is the most **cautionary** of the five papers in this section. ### In plain terms A foundation model is a single, general-purpose base that many different applications are built from. Instead of building a bespoke model per task, you adapt one powerful model — by [fine-tuning](/ai-for-msps/foundational-ai-concepts/pretraining-and-fine-tuning.md), by [prompting](/ai-for-msps/foundational-ai-concepts/in-context-learning.md), or by [alignment](/ai-for-msps/foundational-ai-concepts/rlhf-and-alignment.md). The report highlights two properties: * **Emergence.** Capabilities appear that were never explicitly programmed and are hard to predict — they *emerge* from scale. This is powerful but also means behavior isn't fully understood, even by the model's creators. * **Homogenization.** Because so many systems are built on the *same* few base models, they all share the same strengths — and the same weaknesses. A flaw or bias in one foundation model propagates to every application that depends on it: a single point of failure at civilizational scale. The report is deliberately balanced — it catalogs opportunities *and* risks across capabilities, applications, technology, and society — but its lasting message is caution about concentrated dependence. ### Why it matters for MSPs * **It names the thing MSPs actually depend on.** The AI features in your PSA, RMM, documentation, and security tools are, overwhelmingly, thin layers over a small number of foundation models from a few providers. Understanding this concentration is the starting point for supply-chain and continuity risk assessment. * **Homogenization = concentrated vendor risk.** If most of your AI-enabled tools sit on the same underlying model, an outage, price change, policy shift, or newly discovered bias at that provider hits all of them at once. This is the technical backbone of the **vendor lock-in** and **portability** concerns raised in [What It Can't Do Yet](/ai-for-msps/ai-in-the-msp-stack/what-it-cant-do-yet.md) and [Where We're Going](/ai-for-msps/ai-in-the-msp-stack/where-were-going.md). * **Emergence = unpredictability you must govern.** Because capabilities (and failures) emerge rather than being specified, you cannot assume a foundation model will behave the same after every update. That unpredictability is exactly why the [Operational Safeguards & Oversight](/ai-for-msps/ai-security/operational-safeguards-and-oversight.md) and [Governance & Acceptable Use](/ai-for-msps/ai-security/ai-governance-and-acceptable-use-policies.md) controls exist. * **It anticipated the regulation.** The report's risk framing foreshadows the compliance pressures (EU AI Act, right to explanation) tracked in [Where We're Going](/ai-for-msps/ai-in-the-msp-stack/where-were-going.md). ### Related concepts [Large Language Models](/ai-for-msps/foundational-ai-concepts/large-language-models.md) · [BERT](/ai-for-msps/foundational-ai-concepts/bert.md) · [Transformer Architecture](/ai-for-msps/foundational-ai-concepts/transformer.md) · [Pretraining and Fine-Tuning](/ai-for-msps/foundational-ai-concepts/pretraining-and-fine-tuning.md) · [RLHF and Alignment](/ai-for-msps/foundational-ai-concepts/rlhf-and-alignment.md) **In the MSP KB:** [AI Security](/ai-for-msps/ai-security.md) · [Where We're Going](/ai-for-msps/ai-in-the-msp-stack/where-were-going.md) · [Risks & Guardrails](/ai-for-msps/ai-security/risks-and-guardrails-for-ai-in-msp-environments.md) ### Contradictions & debates * **Risk-first vs. capability-first framing.** The [GPT-3](/ai-for-msps/foundational-ai-concepts/large-language-models.md) paper celebrates broad capability as an achievement. The foundation models report reframes that *same* generality as a source of concentrated, hard-to-govern risk. They do not dispute the facts — they disagree on emphasis, and that difference of emphasis is exactly the debate MSPs sit inside when weighing AI adoption against accountability. * **Is the term even a good idea?** The report's naming of "foundation models" was itself contested — some researchers argued it overstated the novelty or lent marketing weight to a few large labs. The debate matters for MSPs mainly as a caution: a category name is not a capability guarantee, and the [AI vs. Automation](/ai-for-msps/ai-in-the-msp-stack/ai-vs.-automation.md) discipline of separating claim from reality still applies. * **Homogenization: efficiency vs. fragility.** Building everything on one base model is efficient (the upside GPT-3 shows) *and* fragile (the downside this report stresses). The same fact reads as a feature or a bug depending on whether you are optimizing for cost or for resilience — a live trade-off in MSP tool selection. ### Source paper Bommasani et al. (2021), *On the Opportunities and Risks of Foundation Models* (Stanford CRFM) — *** **Key terms**: *foundation model*, *emergence*, *homogenization*, *single point of failure*, *downstream adaptation*, *concentration risk*. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.themspkb.com/ai-for-msps/foundational-ai-concepts/foundation-models.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.