# AI Technology for Lawyers: Model vs. System > When lawyers discuss AI, they often conflate the model with the deployed system, creating analytical errors. Canonical URL: http://modelmonster.ai/blog/ai-technology-for-lawyers-model-vs-system/ ## Article Metadata - Author: Van Lindberg - Published: 2026-01-22 - Category: AI Governance - Reading time: 5 min - Tags: AI governance *Note: This article is part of* ***AI Technology for Lawyers***, *a series explaining the technical foundations of AI for legal professionals. *[*Start with the series introduction*](/blog/ai-technology-for-lawyers-a-technical-foundation/)*.* ### The Critical Distinction When lawyers discuss AI, they often conflate two distinct concepts: the model and the system. This conflation creates analytical errors. The **model** is the trained artifact: the weights and architecture that process inputs to produce outputs. When you download Llama or access GPT-4 through an API, you are using a model. The **AI system** is everything: the model plus all the components that make it work in production. This includes: - System prompts that frame the model's behavior - Guardrails that filter harmful inputs or outputs - Retrieval systems that ground outputs in documents - Tool integrations that enable real-world actions - Connectors that access enterprise data - Human oversight mechanisms This distinction matters because regulatory obligations attach to the deployed system, not just the underlying model. The EU AI Act, for example, categorizes risk based on how the "AI system" is used. The same foundation model can be low-risk or high-risk depending on its configuration and application. Two companies using identical models might have completely different risk profiles based on their system architecture. ### The CORE Framework To analyze any AI system, use the mnemonic CORE: Components, Operations, Resources, and Execution. **Components** are the functional elements that comprise the system. These include the foundation model, any fine-tuned adapters, guardrail models that check for safety issues, vector databases storing embeddings for retrieval, connectors pulling data from enterprise systems, and human review steps. Each component has properties relevant to governance: its provider, the operations it performs, the resources it accesses, and how it transforms data flowing through it. **Operations** are what each component does. A model might summarize, classify, or generate. A guardrail might filter or flag. A connector might read from SharePoint or write to a CRM. Understanding operations tells you what the system can do, and therefore what can go wrong. **Resources** are external assets the system accesses but does not control. Your company's document repository. A customer database. The public internet. Understanding resources tells you about data exposure: if the system can access confidential documents, those documents might appear in outputs. **Execution** is the dataflow connecting components from input to output. How does a user's query flow through the system? Multiple execution paths may exist based on routing logic. If a query seems sensitive, it might route through additional human review. Documenting execution paths is needed for privacy-by-design compliance and for understanding what actually happened when something goes wrong. For high-stakes systems, you want an AI Bill of Materials, sometimes called an AIBOM, documenting all components, their versions, and their interactions. This is analogous to an Software Bill of Materials (SBOM) for software supply chain security. ### System Prompts and Instruction Hierarchy System prompts are instructions provided to the model that frame its role, capabilities, and constraints. They are typically hidden from end users but fundamentally shape model behavior. Think of them as operational policy implemented in natural language. A system prompt might say: "You are a helpful assistant for Acme Corporation. You should never discuss competitor products. If asked about legal advice, recommend consulting with the legal department." The model will attempt to follow these instructions, though it can sometimes be manipulated into ignoring them. There is an instruction hierarchy: a priority order determining which instructions the model follows when multiple sources conflict. Typical precedence in many LLM orchestration patterns is: 1. System prompt (highest priority) 2. Developer instructions 3. User prompt 4. Retrieved content or tool outputs (lowest priority) This hierarchy is not inherent to the model itself. It is implemented by the orchestration layer that assembles the prompt. The orchestration layer is the software that sits between the user and the model, assembling prompts, managing context, routing requests, and coordinating tool calls. The orchestrator decides what text is injected as "system," "developer," "user," or "retrieved" content, and the model sees only the assembled prompt. Different orchestration frameworks implement different hierarchies, and some allow configuration. Understanding this hierarchy matters for security and governance. System prompts often contain confidential business logic, like what the product does, how it should behave, what it should refuse. If attackers can extract system prompts through clever questioning, they learn your operational parameters. If users can override system prompts, your safety controls become suggestions rather than constraints. This is also where prompt injection attacks target: adversarial inputs designed to make the model ignore its intended instructions. We address this further in [Article 6](/blog/ai-technology-for-lawyers-agentic-ai/). ### Open Weights vs. Closed Services A final distinction in system architecture matters for legal analysis: whether you access AI through a vendor's API or host open-weight models on your own infrastructure. With closed services (OpenAI, Anthropic, Google), you send data to the vendor's servers. The vendor controls the model, the infrastructure, and the data handling practices. Your leverage comes from contract negotiation and the vendor's published policies. "Training on your data" is a vendor risk. You must trust their representations about data use. With open-weight or open source models (Llama, Mistral, DeepSeek), you download the model weights and run inference on infrastructure you control. Data never leaves your environment. "Training on your data" becomes an internal choice, not a vendor risk. You control logging, retention, and access, but you also bear responsibility for security, compliance, and operational reliability. The liability profiles differ substantially. Closed services shift operational risk to the vendor but create data exposure and dependency. Open-weight deployments eliminate vendor data risk but internalize operational responsibility. Many enterprises use both: closed services for general productivity tools, open-weight models for sensitive workflows where data control is paramount. When reviewing AI deployments, ask: Where does inference happen? Who controls the infrastructure? What are the data flows? The same model can have very different risk characteristics depending on whether it runs on a vendor's cloud or your own secure environment. ***Continue here to the next article in the series:***[***Retrieval and Grounding***](/blog/ai-technology-for-lawyers-retrieval-and-grounding/)