Large language models have moved quickly from research demos to production systems, and technology teams in regulated industries are now being asked to put them to work. The underlying technology is genuinely useful, but it behaves very differently from the systems most of us are used to architecting and building. A model does not read from a database; it does not follow a fixed set of rules, and it will sometimes produce an answer that is fluent, confident, and wrong. In a regulated industry, those traits change how you design the system around the model.
This article walks through the ideas you need to reason about these systems clearly – what a language model actually is, the difference between a workflow and an agent, how retrieval keeps the model grounded, and where AWS services like Amazon Bedrock and frameworks like LangChain fit. It ends with a reference architecture that can serve as a starting point and be adapted as needed.
A Language Model Is a Component, Not a Brain
The most useful way to think about a large language model (LLM) is as a very capable text-prediction engine. It has been trained on a large amount of text, and it predicts the most likely next words given the text you provide. That is powerful, but it comes with three properties that matter greatly in a regulated setting.
Stateless – The model does not remember your previous request. Any information it needs has to be supplied with each call to the model (Prompt).
Non-deterministic – The same question can produce different answers. Your testing approach cannot assume a single correct output every time.
Hallucination – When the model does not know something, it may still produce a confident, well-written answer that is simply incorrect. In regulated industries like financial services, a plausible wrong answer about a business rule is more dangerous than an obvious error, because people are more likely to trust it.
Once you accept that the LLM model is a capable but unreliable component, the rest of the design becomes clearer. As an engineer and architect, our job is to apply architectural techniques to ensure system characteristics like security and trust are built around the LLM with the right guardrails.
Workflows and Agents Are Not the Same Thing
I have quite often found that these two words get used interchangeably, and the confusion causes real problems. The difference is worth being precise about.
A workflow is a system where the developer defines the steps. The model is called at specific points to do specific tasks, but the application decides what happens next. The model helps with the steps in the workflow; however, it does not steer.
An agent works differently. You give the model a goal and a set of tools, and the model decides which tools to use, in what order, and when the job is done. The sequence of steps is not written by you in advance; it is chosen by the model at runtime i.e. the workflow is orchestrated by the LLM model itself.
Agents are well suited to open-ended problems. They are also harder to test, harder to keep within limits, and harder to explain, because the path through the system is decided by a component that is non-deterministic by nature. In regulated environments, most tasks that get labeled “agentic” are actually a better fit for a workflow. If the task is “read this scenario, find the relevant rules, and draft a response,” it does not need a model deciding its own plan. It needs a pre-defined pipeline (or workflow) which is cheaper, faster, and far easier to explain later.
A general rule of thumb is to start with a fixed workflow, especially for use cases within the regulated industry. If needed, allow the model to choose from a small, approved set of actions that are deterministic and explanatory. Not all the use cases need an agentic system orchestrating the workflow, which is hard to reason about and explain.
Retrieval-Augmented Generation Keeps the Model Grounded
Retrieval-Augmented Generation, or RAG, is the technique that does the most to keep an LLM honest. The idea is to answer questions using your own trusted documents rather than the model’s memory of its training data.
It works in a few steps. The proprietary data is split into small chunks, and each chunk is converted into an embedding, which is a list of numbers that represents its meaning, and these are stored in a vector database. When a user asks a question, you convert the question into an embedding too, find the chunks whose meaning is closest to it, and pass those chunks to the model with an instruction to answer using only the provided material and to cite its sources.
Instead of trusting what the model happens to remember, which is undated and hard to verify, you ask the model to read and summarize documents you control. The answer can be traced back to a source. When a policy changes, you can re-ingest the updated document and the system is current, with no retraining. And when nothing relevant is found, a well-built RAG system can respond with a message letting the user know that the information is not available, exactly the kind of behavior required in a regulated industry.
RAG is not perfect. Poor chunking or weak retrieval can still lead to bad answers. But it turns an unverifiable memory problem into a search problem you can inspect and improve, which is an acceptable trade-off.
Amazon Bedrock: The Model Layer
Running a large model yourself is expensive and complicated. A managed service such as Amazon Bedrock gives access to several foundation models through a single API, which matters because choosing a model is a real decision – cost, speed, and quality vary, and you will want the freedom to switch.
For use cases within a regulated industry like financial services, healthcare etc., the platform guarantees often matter more than the models themselves. With Bedrock, your prompts and data are not used to train the underlying models; inference can run inside your private network, and it works with the same identity and encryption controls (IAM and KMS on AWS) you already use. It also includes a guardrails feature that can filter content and remove sensitive data.
LangChain: The Orchestration Glue
There are many moving parts, and something has to connect these pieces – the vector database, the prompts, the retrieval step, the model call. Frameworks like LangChain provide that plumbing, along with templates and building blocks that let you move from idea to working pipeline quickly. Frameworks like LangChain hide a lot of detail, and in a regulated system you need to know what is happening beneath each convenience. It is very important to be able to explain how the system arrived at an output by tracing the steps executed by the model.
A Reference Architecture
Reference architecture for a grounded LLM system in a regulated industry comprises an offline ingestion flow that builds a vector store from trusted documents, and an online query flow that retrieves context, assembles a grounded prompt, calls the model through Amazon Bedrock, and applies guardrails before returning a cited answer. Governance controls wrap the whole system.
The first flow runs offline. You take your trusted documents, split and embed them, and load them into a vector store. This is your knowledge base, and you refresh it whenever the source material changes.
The second flow runs when a user asks a question. The request enters an orchestration layer, which retrieves the most relevant chunks from the vector store, assembles a prompt that includes those chunks and asks for citations, sends it to the model through Bedrock, and passes the result through a guardrails step before returning the answer with its sources.
The controls around these flows are what make the system suitable for a regulated industry. Every model interaction is logged so any answer can be reconstructed later. Sensitive data is removed before it reaches the model and filtered on the way out. Actions with real consequences are drafted by the system but confirmed by a person. And an evaluation step measures the quality of retrieval and the faithfulness of answers against a fixed set of test questions before anything is released.
Where to Start
The most reliable way to bring this technology into a regulated business is to build the simplest version that works – a grounded workflow that answers from trusted documents, keeps a person in the loop for important decisions, and measures its own quality from the start. Get that running, observable, and trusted. Then look for the specific, well-bounded places where more autonomy is worth the added effort and risk.
The teams that succeed with LLMs in regulated industries like financial services, healthcare etc. will not be the ones who deployed the most independent agents first. It’s more about making an unpredictable technology dependable enough and put to use for the right business use cases. That is an architecture problem more than a model problem, and it is solvable with the right architectural principles.
asardana.com 