Over the previous four posts in this series, we have covered a lot of conceptual ground: the model zoo and the generative-versus-discriminative divide; the autonomy spectrum from chatbots to agents; the plumbing of Skills, MCP, and harnesses; the retrieval architectures that ground models in enterprise data; and the economics that increasingly shape all of those decisions.

Concepts are only useful if someone builds with them. This final post looks at how SAS has translated these ideas into shipping products, and at the design philosophy behind them. Indeed, the pace of development over the past year has been so brisk that several of the offerings described below didn't exist when I wrote the first post in this series.

A fair question at this point is why an analytics vendor belongs in this space at all, given how much of the agentic tooling ecosystem is open source and freely available. The answer is that the hard part of enterprise AI was never the model. It is everything around the model and requires knowing which data a given user is permitted to see. Also, it means being able to reconstruct, after the fact, why a system produced the output it did. Lastly, it means being able to hand an auditor something more substantial than a chat transcript. Those are the problems SAS has spent decades solving for regulated industries. And they transfer directly to agentic systems.

Every offering described below pairs a generative capability with the governance apparatus that regulated industries already expect from their analytical models. That is a deliberate choice. In an environment where many AI products ship as ungoverned chat interfaces bolted onto an existing UI, it is the thing most worth paying attention to.

With the landscape clarified, you may be wondering how SAS is putting these concepts into practice. The pace of development here has been remarkable, and it reflects a deliberate strategy. Meet practitioners where they are, fuse established analytical rigor with emerging AI capabilities, and never sacrifice governance for speed.

SAS Viya Copilot

At SAS Innovate 2026, SAS unveiled a comprehensive expansion of its agentic AI capabilities. At the center is SAS Viya Copilot, a family of governed, conversational AI assistants embedded directly into the SAS Viya platform at no additional cost.

What distinguishes SAS Viya Copilot from many horizontal AI assistants is its domain awareness. Rather than relying solely on pretrained LLM knowledge, it executes analytics tasks grounded in industry data models, terminology, and best practices. It integrates Microsoft Foundry to operate within analytics workflows rather than as a standalone chat interface. Current capabilities span general Q&A across core SAS Viya applications, AI-generated SAS and Python code with documentation and explanations, intelligent model pipeline recommendations, conversational dashboarding, and AI-assisted investigation with automated case narratives.

SAS has also released industry-specific copilots: the SAS Asset and Liability Management (ALM) Copilot for financial risk scenario analysis and the SAS Health Clinical Data Discovery Copilot for accelerating clinical data exploration and cohort creation, with plans to expand into financial crime prevention and supply chain optimization.

The SAS Viya MCP Server

In a move that directly connects to the MCP discussion in Part 2 of this series, SAS announced the SAS Viya MCP Server, which provides a standardized way to expose SAS analytics, models, and decisioning capabilities to external AI agents by using the open Model Context Protocol. Organizations can now embed SAS' trusted analytics and governance into their own agents, from various LLM interfaces, without duplicating logic or bypassing enterprise controls. This enables users to leverage SAS Viya functionality through conversational language, lowers adoption barriers, and unlocks the power of SAS analytics for a wider audience.

SAS Retrieval Agent Manager (RAM)

For organizations looking to implement RAG-based solutions, SAS released the SAS Retrieval Agent Manager (RAM): a no-code platform that transforms unstructured enterprise data into context-aware AI responses. RAM supports plug-and-play LLMs and vector databases, adds an agentic AI layer for complex workflows, and critically, does not use enterprise data to train or fine-tune any LLM. Industry use cases already include insurance claims adjudication and clinical decision support. If you need to reason against existing documentation within your organization, RAM is likely what you’re looking for.

SAS Agentic AI Accelerator and AI Navigator

The SAS Agentic AI Accelerator provides code, components, and best practices for teams across all skill levels (no-code, low-code, and developer) to design and operationalize AI agents with governance and trust baked in from the start. Complementing it, SAS AI Navigator, a SaaS governance tool available on Microsoft Azure Marketplace in Q3 2026, provides a centralized system for inventorying and monitoring AI use cases across the enterprise.

This governance emphasis is not incidental. When an agent simultaneously processes untrusted input, accesses sensitive data, and can modify state, a security incident is a matter of when, not if. SAS is building exactly the guardrails that the industry's leading researchers say are essential.

Table 1 summarizes the current SAS AI Agentic offerings.

Table 1: SAS Agentic AI offerings -- Use cases and differentiators

Mapping the Offerings Back to the Concepts

These offerings connect directly to concepts introduced earlier in the series. SAS Viya Copilot and the industry-specific copilots occupy the copilot end of Part 2’s autonomy spectrum: the model proposes actions, and a human executes them. The SAS Viya MCP Server is the plumbing layer. It exposes SAS capabilities through an open protocol so agents built elsewhere can reach them without reimplementing the analytics or routing around access controls. Retrieval Agent Manager is the retrieval layer from Part 3. It's packaged so that a team can stand up a governed RAG application without first assembling a vector database, an embedding pipeline, and an orchestration framework of their own. The Agentic AI Accelerator and AI Navigator address the harness and the governance layer, respectively. The pieces are deliberately separable, which matters, because most organizations will already have committed to some of these choices and will want to adopt the remainder incrementally.

Additional Agentic Offerings

Within SAS, the Applied AI and Modeling (AAIM) division has been at the forefront of translating these technologies into practical, domain-specific solutions:

• SAS Document Analysis, developed by my team, applies OCR, Document Intelligence, and agentic extraction pipelines to transform unstructured documents into structured, actionable data at scale.
• SAS Supply Chain Agent, announced at Innovate 2026 and currently in private preview, automates supply and operations planning (S&OP) by continuously balancing demand, supply, and operations in near real time, replacing traditional multi-day spreadsheet-driven processes with conversational scenario analysis.
• SAS Data Mapper Agent uses LLMs to automate column mapping between existing data environments and AI model schemas, reducing data integration timelines from weeks to minutes through automatic schema mapping and virtual views.

The SAS HuggingFace Repository

Finally, our division has recently collaborated with the SAS Office of Open Source to establish the official SAS HuggingFace model repository at huggingface.co/sassoftware. This curated hub hosts models that have been thoroughly scanned and vetted for enterprise usage. It currently includes the GliClass & GLiNER family of zero-shot classification and NER models across three tiers: edge, base, and large. These models tie directly back to the GLiNER lineage discussed in the earlier multimodal transformers series. It is now enterprise-ready and SAS-vetted. Keep an eye on this space as we plan to expand the offering to include more optimized open-source models and fine-tuned, domain-specific variants in the near future, including a family of Vision Language models based on the Gemma4 architecture.

An Exciting Time to Be a Practitioner

I believe we are at an inflection point. The tools have caught up to the vision. The explosion in terminology and tooling can be overwhelming, but the underlying pattern is clear: the industry is converging on architectures that pair the reasoning power of large models with the efficiency and reliability of small, specialized ones, connected by open standards like MCP, governed by well-designed harnesses, and grounded in enterprise data through retrieval approaches tailored to the task at hand.

For analytics practitioners, the message is encouraging. The role of human expertise is not being diminished. It is being elevated. The practitioners who understand both the classical toolkit (optimization, forecasting, statistical modeling, experimental design) and the emerging AI toolkit (agentic patterns, retrieval architectures, model orchestration) will have an outsized impact. The abstraction level is rising, but as I have discussed, rigor does not disappear. It relocates to wherever human judgment matters most.

SAS' philosophy reflects this conviction. Fuse established, reliable analytical techniques with emerging AI capabilities to accelerate human productivity. Don’t replace human judgment but amplify it. Don’t chase every shiny new acronym, but integrate the techniques that help to deliver real, governed, tangible value in production.
It is an exciting time to work in this space. The pace of change is breathtaking, but the destination is increasingly clear. AI systems that are powerful, practical, trustworthy, and firmly under human direction.
Stay tuned as there are undoubtedly many more developments to come in this space.

Additional Resources

• SAS Viya Copilot
• SAS Retrieval Agent Manager (RAM)
• SAS HuggingFace Repository
• SAS Innovate 2026 Press Release: Governed AI Assistants and Agentic AI

Blog Series:

• Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
• Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It
• Part 3: Modern Retrieval Approaches: RAG, Knowledge Graphs, and PageIndex
• Part 4: Emerging Economics: Token Pricing and the Case for Local Inference
• Part 5: SAS in the Agentic AI Space

The post SAS in the Agentic AI Space appeared first on The SAS Data Science Blog.

Synthetic data helps organizations address privacy concerns, expand limited datasets and accelerate model development. But for many data scientists, generating realistic data is only part of the challenge. The real question is:

What if you need specific data?

Maybe you're building a fraud detection model and need more examples of fraudulent transactions. Perhaps you're testing a credit risk model and want a balanced population of loan approvals and denials. Or maybe you're evaluating how a model performs under conditions that rarely appear in historical data.

Traditionally, meeting these needs often requires filtering datasets, oversampling rare classes or performing extensive post-processing after data is generated. Conditional generation takes a different approach. Instead of generating data first and manipulating it later, users define the characteristics they want before generation begins. This makes it possible to create synthetic data tailored to a specific analytical objective while maintaining many of the statistical patterns learned from the original dataset.

What makes conditional generation different?

Think of a GPS. Once it learns the road network, you can request different routes based on your goals without rebuilding the map. Conditional generation works similarly. A synthetic data generator is trained once on the original data, and users can then generate different populations by specifying conditions at generation time. The result is greater flexibility. One generator can support many use cases without requiring multiple versions trained on different subsets of data.

Balancing underrepresented groups

Consider a healthcare dataset with the following distribution:

 
A data scientist may want a balanced dataset with 1,500 observations from each group. With conditional generation, the desired distribution can be specified directly. The value is not simply changing the counts. Depending on the generation approach used, the synthetic data can retain important relationships learned from the original dataset, such as connections between demographics, diagnoses, treatments and outcomes. Without those relationships, balancing categories would be easy, but the resulting data would be far less useful for analysis and machine learning.

Creating more examples of rare events

One of the most compelling use cases is fraud detection. Imagine a dataset where only 0.5% of transactions are fraudulent. This creates a common machine learning challenge because models may have too few examples to learn meaningful fraud patterns. Using conditional generation, a data scientist could request:

Generate a dataset where fraudulent transactions represent 10% of all observations.

The resulting synthetic dataset contains more fraud examples while preserving many of the characteristics associated with fraudulent behavior. This supports:

• Rare-event modeling
• Class imbalance challenges
• Model testing
• Algorithm comparison
• Feature engineering experiments

Unlike traditional oversampling approaches that reuse existing records, conditional generation can create entirely new synthetic observations while targeting a desired distribution.

Creating targeted populations

Conditional generation is not limited to balancing classes. A retailer may want to analyze a larger population of self-employed customers. A bank may want more observations representing customers with incomes between $150,000 and $250,000. Rather than filtering existing data and potentially ending up with too few records, analysts can generate synthetic populations that satisfy those conditions while preserving relevant relationships with variables such as spending behavior, savings balances or product ownership. This enables organizations to explore targeted scenarios without collecting additional real-world data.

Stress-testing AI before deployment

Perhaps the most strategic application is model stress testing. Organizations often need to understand how AI systems will behave under conditions that are rare, emerging or not yet represented in historical datasets, such as:

• Economic downturns
• Emerging fraud patterns
• Rare medical conditions
• High-risk operational scenarios

Conditional generation can create larger representations of these edge cases and allow teams to evaluate model performance before those conditions occur in production. Rather than waiting for rare events to expose weaknesses, organizations can proactively identify vulnerabilities, understand performance degradation and improve confidence before deployment. In this way, synthetic data becomes more than a privacy tool. It becomes a tool for model governance, validation and risk management.

Why it matters for Trustworthy AI

Trustworthy AI requires more than protecting sensitive information. Models must also be fair, reliable, robust and well tested. Conditional generation can support those goals by helping teams:

• Explore underrepresented populations
• Investigate potential bias across groups
• Evaluate performance under rare conditions
• Accelerate experimentation and model validation

For example, teams can assess whether prediction accuracy changes across demographic groups or under unusual operating conditions before deployment.

The bigger picture

Synthetic data is often viewed primarily as a privacy technology. Privacy is important, but it is only part of the story. The real power of synthetic data lies in its ability to support realistic, controlled experimentation. Conditional generation extends that capability by allowing teams to shape the scenarios they want to study rather than simply accepting the distributions found in historical data.

As AI systems increasingly support decisions, recommendations and automation, the ability to create realistic data for targeted testing may become just as important as the ability to create synthetic data itself. Conditional generation doesn't just help organizations create more data. It helps them create the right data for the questions they're trying to answer.

Learn more

• Webinar: Beyond Accuracy: Identifying, Measuring and Mitigating AI Bias
• Solution: SAS AI Navigator
• Communities: SAS AI Navigator

The post Beyond balancing data: How conditional generation makes synthetic data more useful appeared first on The SAS Data Science Blog.

The previous three posts in this series covered what the models are, how much autonomy to grant them, and how to ground them in your data. This one covers the constraint that quietly governs all three decisions: cost.

For the first few years of the generative AI era, cost was mostly an afterthought. Providers competed for adoption with flat-rate subscriptions and steadily falling per-token prices. Most organizations assumed inference would keep getting cheaper. Pilot projects were budgeted accordingly. In other words, they were often barely budgeted at all. A proof of concept that burned through a few dollars of tokens a day did not warrant a conversation with finance.

That assumption is now being tested. Low-end prices have indeed collapsed, but high-end capacity has not kept pace with demand. Providers are beginning to restructure how they charge. For organizations moving from experimentation into daily production workloads, the difference between those two trends is the difference between a rounding error and a line item that shows up in the quarterly review.

What follows is a look at where pricing actually stands today, what the recent shifts signal about where it is heading, and why a growing number of teams are taking a serious look at running models on their own hardware.

One factor accelerating the adoption of agentic AI, and simultaneously reshaping how organizations think about deployment, is the shifting landscape when it comes to inference costs.

Where Pricing Stands Today

When GPT-4 launched in March 2023, API pricing was $30 per million input tokens and $60 per million output tokens. Fast-forward to 2026, and the pricing structure looks radically different. Budget-tier models like GPT-5.4 Nano run at $0.20 per million input tokens. Google's Gemini 3.1 Flash-Lite costs $0.25. The pricing floor has dropped roughly 300 times since GPT-4's launch. Even flagship models have become dramatically more affordable. See Table 1 for a summary of some of these prices.

Table 1: LLM-as-a-Service pricing

The End of the Subsidized Era

But here is where the story gets more nuanced. While per-token prices for legacy and mid-tier models have fallen dramatically, demand for compute using the latest and most capable models continues to outpace supply. The AI labs and hyperscalers are beginning to revisit their pricing strategies in ways that signal a shift away from the generously subsidized flat-rate offerings that fueled early adoption.

The most visible example of this is GitHub Copilot’s recent shift from flat-rate subscriptions to usage-based billing tied to actual token consumption. Under the old model, a quick chat question and a multi-hour autonomous coding session cost the same flat fee. Under the new model, each interaction is metered by tokens consumed, with per-model multipliers that determine how fast credits drain. The impact was stark. Claude Opus 4.7, one of the most capable models available in Copilot, went from a 7.5x multiplier to 27x. This means a user's monthly credit allocation could be exhausted in as few as three premium requests.

As a result, some companies are suddenly blowing past AI inference budgets by orders of magnitude. In engineering departments, inference costs are approaching 10% of total headcount costs. The developer community reacted sharply, noting that the new system forces conscious model-selection trade-offs that did not previously exist.

Anthropic has experienced similar growing pains on the supply side. Heavy demand for Claude's most capable models has led to periodic compute constraints, with users encountering rate limits and throttling during peak usage periods. When millions of developers and enterprise customers compete for the same GPU clusters, even well-provisioned infrastructure hits ceilings. These constraints remind us that raw cost per token is only part of the equation. The availability and reliability of that compute matter just as much.

As AI usage matures from experimentation into daily production workloads, providers will increasingly push consumers to bear the full cost of usage on a per-token basis. They are likely to roll back the generous flat-rate pricing that characterized the land-grab phase of AI adoption. The early "all you can eat" era was likely a customer acquisition strategy, not a sustainable business model. Organizations that plan their AI infrastructure around the assumption of perpetually cheap, unlimited cloud inference may suddenly find themselves caught off guard and facing ballooning IT costs.

Spending Tokens Where They Count

One solution is to encourage developers to be judicious about which models they use for certain tasks. We need to emphasize that not every request requires top-tier frontier model intelligence. This is by no means meant to be an authoritative guide. However, recent research points to a more cost-effective approach. Top-tier models can handle initial planning and help create detailed implementation specifications. Mid-tier models can then execute against those specifications, often producing high-quality results at a lower cost than relying on a single model offering. Table 2 summarizes a typical approach to managing this hybrid approach.

Table 2: Matching model tier to task type

The Case for Local Inference

The trend in rising per-token costs is also driving a growing interest in local and on-premises inference, powered by four converging forces:

• Cost predictability: Local inference decouples your AI costs from external providers' pricing decisions. Once the hardware is in place, your per-token cost is fixed and under your control, regardless of upstream multiplier changes or rate-limit adjustments.
• Data sovereignty: Local processing eliminates cross-border data transfers, automatically satisfying GDPR data residency and HIPAA constraints. Data never leaves organizational infrastructure.
• Latency and availability: On-premises inference eliminates network round-trips and, crucially, eliminates your dependence on a provider's capacity constraints. Your models are available when you need them, not when the provider's GPU cluster has headroom.
• Regulatory pressure: The EU AI Act and sector-specific standards increasingly favor architectures where organizations maintain full control over their AI processing pipeline.

The local inference ecosystem has matured rapidly to support this shift. This shift is driven less by any single runtime and more by a wave of open-source techniques that shrink the compute and memory footprint required to host a model locally. Three are worth understanding in particular, because they attack different bottlenecks and compose well with one another.

Local Inference Optimizations

Model quantization is one of the most widely used techniques for making AI models smaller, faster, and less expensive to run. AI models normally store billions of numerical values (called weights) using 16 or 32 bits of precision. Quantization reduces this precision to 8 bits, 4 bits, or even fewer. This significantly reduces memory requirements while preserving most of the model's capabilities. Think of it like compressing a high-resolution photograph. By reducing subtle color variations that are barely noticeable, we can create a much smaller file without significantly affecting image quality.

Quantization applies a similar principle to AI models. It simplifies how numerical values are stored while preserving the most important information. Modern techniques carefully identify which values require greater precision or allow the model to adapt during training, helping minimize accuracy loss. The benefits can be substantial. A 7-billion-parameter model requiring approximately 14 GB of memory at 16-bit precision might need only around 4 GB when quantized to 4 bits. This can make the difference between requiring an expensive data center GPU and running the model on a consumer GPU or capable laptop. Quantization can also improve processing speed by reducing the amount of data that must move through memory when generating responses. However, actual performance gains depend on the hardware and software.

TurboQuant and similar newer quantization techniques take compression a step further by finding smarter ways to represent numerical values using even less memory. Traditional quantization reduces precision using relatively simple rules. These newer approaches adapt to the data's patterns and distribution to preserve more information. Think of it like packing a suitcase. Instead of forcing everything into identical-sized compartments, you arrange items by shape and size, giving delicate or unusually large items special treatment while packing everything else more tightly. Similarly, TurboQuant mathematically reorganizes numerical data before compressing it. This helps preserve important information while reducing storage requirements.

One particularly valuable application is compressing the key-value cache (KV cache). This acts as the model's short-term memory during conversations and grows as it processes more text. By shrinking this cache, AI systems can handle longer conversations or more simultaneous requests without requiring additional GPU memory. These techniques make extremely compact 3–4-bit representations increasingly practical. However, pushing compression too far can come at a cost. Below about 4 bits, some models may experience noticeable reductions in accuracy or processing speed. This is especially true for handling lengthy documents or complex reasoning tasks.

Multi-Token Prediction (MTP) attacks a different bottleneck entirely. Think of it like meta-prediction or predicting the prediction. Standard autoregressive decoding emits exactly one token per forward pass. So generating a 500-token answer means 500 sequential trips through the entire model. That is inherently serial, leaving much of the available compute idle while the hardware waits on memory.

MTP trains the model with additional prediction heads so that a single pass proposes several future tokens at once. It then verifies those extra tokens in one batched pass and accepts them when they match what ordinary decoding would have produced. This cuts the number of sequential steps without changing the output. Fewer passes mean lower latency and lower compute cost for the same volume of generated text. MTP is a training objective rather than a post-processing step, so it can also improve model quality as a side effect. By predicting several tokens ahead, the model is forced to plan beyond the very next word.

Together, these open-source advances mean a well-quantized model using MTP-style decoding can now deliver latency and throughput on commodity hardware that would have required a full data center GPU just a couple of years ago. And the SLM thesis from the earlier series makes local deployment particularly attractive. A 3 billion parameter model running on a laptop is a very different proposition than self-hosting a 70 billion parameter behemoth. For many of the specialized tasks within an agentic workflow (extraction, classification, guardrail checks, structured output generation), a well-tuned local SLM can match or exceed the performance of a cloud-hosted LLM at a fraction of the cost and with none of the supply constraints.

None of this means cloud APIs are going away. For frontier reasoning tasks, agentic coding harnesses, and organizations early in their AI journey, cloud inference often remains the most practical starting point. But the writing is on the wall. Organizations that want to run AI at scale, reliably and affordably, may need a hybrid strategy that pairs cloud APIs for tasks that demand frontier-scale models with local inference for the high-volume, specialized work that does not. These core concepts are summarized in Table 3.

Table 3: Local inference and hybrid strategy

For most organizations, the practical next step is not a wholesale migration but an inventory. Which of your current AI workloads are high-volume, narrow, and well-specified? And which genuinely require frontier-scale reasoning? That question is answerable today, and the answer often surprises people. A large share of production token spend goes to classification, extraction, routing, and formatting work. This is exactly the category where a well-tuned local SLM performs as well as a frontier model at a small fraction of the cost. Quantifying that share is what turns a hybrid strategy from an architectural aspiration into a budget line you can actually defend. It is worth doing before the next round of pricing changes, not after.

Coming Up Next

That covers the concepts: models, autonomy, plumbing, retrieval, and economics. The final post in this series shifts from theory to practice and shows how SAS is putting these ideas to work through Viya Copilot, the SAS Viya MCP Server, Retrieval Agent Manager, the Agentic AI Accelerator, and AI Navigator, with governance built in rather than bolted on.

Additional Resources

• NVIDIA: Small Language Models are the Future of Agentic AI
• DiffusionGemma: 4X Faster Text Generation

Blog Series:

• Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
• Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It
• Part 3: Modern Retrieval Approaches: RAG, Knowledge Graphs, and PageIndex
• Part 4: Emerging Economics: Token Pricing and the Case for Local Inference
• Part 5: SAS in the Agentic AI Space

The post Emerging Economics: Token Pricing and the Case for Local Inference appeared first on The SAS Data Science Blog.

Part 1 of this series covered the models themselves, and Part 2 covered the autonomy and plumbing that turn a model into an agent. This post addresses the question that determines whether any of it produces trustworthy output. Where does the model get its facts?

A foundation model knows a great deal about the world in general. However, it says nothing specifically about your organization. It has never seen your policy library, your claims history, your regulatory filings, or last quarter's numbers. Left to its own devices, it will answer confidently anyway. This is precisely the failure mode that makes generative AI difficult to deploy in regulated settings. Grounding the model in your own data is not an optimization; it is the difference between a demo and a production system.

A reasonable first question is whether retrieval is needed at all. Context windows have grown dramatically, and for a modest corpus it is often simpler and more accurate to place the relevant material directly into the prompt than to build an indexing pipeline around it. Retrieval earns its complexity when the body of knowledge is too large to fit, too volatile to freeze into a prompt, or too sensitive to expose in its entirety on every query. If none of those apply, the simplest architecture is usually right.

When retrieval is warranted, there are broadly three ways to go about it. The choice matters more than most teams expect. Get it right and the model answers from your documents with citations you can audit. Get it wrong, and you have built an expensive, slower search engine that occasionally invents things or omits critical context. The three approaches differ in setup cost, query latency, and infrastructure requirements. But most importantly, they differ in the kinds of questions they can answer well.

If you have spent any time evaluating how to connect AI systems to enterprise data, you have almost certainly encountered the term RAG (Retrieval-Augmented Generation). But RAG is just one approach in a rapidly expanding toolkit. Knowing when to reach for each option can save significant time and frustration.

RAG (Retrieval-Augmented Generation)

RAG is the most established approach. It remains the go-to solution for a common enterprise challenge: supporting large knowledge bases where the full body of detailed information simply cannot fit into a model's context window and cannot be adequately summarized or distilled without losing critical nuance.

Think of an organization's complete policy library, years of technical documentation, or a regulatory corpus spanning thousands of pages. No model can hold all of that in memory at once. No summary can capture every detail a user might need. RAG solves this by splitting documents into chunks, embedding them into vectors, and storing them in a vector database. At query time, it retrieves the most semantically relevant chunks and passes them to an LLM as context for generation. In theory, this means the model gets precisely the information it needs for the question at hand, drawn from a knowledge base of virtually unlimited size. It is relatively easy to set up, delivers responsive results, and works well for single-hop factual lookups such as, "What is our refund policy?" or "What were Q3 revenue figures?"

However, RAG has its weaknesses. There is always the possibility that the retrieval algorithm fails to return the relevant chunk to the AI agent. This means the underlying LLM is “blind” to that information when generating its response. Another weakness of RAG is that many failures trace back to the ingestion and chunking layer - splitting documents into fixed-size chunks destroys table structure, cross-references, and reading order. Finally, multi-hop reasoning (questions that require connecting information across multiple documents) is also a known weakness and is often challenging to solve in an elegant and generalized manner. In practice, this means critical context that should be provided to the LLM may get lost, so the model is effectively “blind” to it. The result is a model that might invent untrue facts or report that such info doesn’t exist, when in fact it does.

Knowledge Graphs and GraphRAG

Knowledge graphs take a fundamentally different approach. Instead of chunking text into vectors, they extract entities and relationships and store them as a structured graph. Graph-based approaches excel at multi-hop reasoning. When a question requires following chains of relationships across documents (e.g., "Which suppliers are connected to the subsidiaries involved in flagged transactions?"), graph traversal dramatically outperforms vector similarity search.

The downsides, however, are significant. Knowledge graph construction is extremely compute-intensive. Indexing with GraphRAG requires six to eight times more tokens than flat RAG because every document must be processed by an LLM to extract entities and relationships, and engineering setup takes weeks rather than days.

Second, knowledge graphs require defined ontologies. You need to decide up front what entities and relationships matter for your domain. Designing a good ontology is non-trivial and demands deep domain expertise. Get the ontology wrong, and the graph either misses critical connections or drowns in noise.

Third, and perhaps most underappreciated, knowledge graphs require ongoing entity resolution maintenance. The same real-world entity often appears under different names, abbreviations, or misspellings across documents ("JPMorgan Chase," "JP Morgan," "JPMC," "J.P. Morgan & Co."). Without continuous entity resolution to merge these variants, the graph fragments into disconnected clusters and the multi-hop reasoning advantage erodes. This maintenance burden grows with the size and diversity of the corpus, making knowledge graphs a serious long-term operational commitment rather than just a quick one-time setup.

PageIndex Retrieval

PageIndex is a newer approach that sidesteps both the chunking problem and the need for vector databases entirely. Instead of embedding text fragments, PageIndex first distills documentation into a hierarchical knowledge base. It then uses LLM reasoning to navigate that hierarchy at query time. The process mirrors how a human actually reads a reference document. You open the table of contents, find the relevant chapter, flip to that section, scan its subheadings, and read the specific paragraph you need. You don’t read the entire book, flip to random pages, or map out all entities before answering the question.

The approach works in two phases. During indexing, an LLM processes the source documents and identifies natural structural boundaries (chapter headings, section breaks, topic transitions) rather than splitting at arbitrary token counts. It then builds a tree: the root node represents the document, intermediate nodes represent chapters and sections (each with an LLM-generated summary describing its content), and leaf nodes contain the actual page-level text. This entire structure is stored as a lightweight JSON tree in a standard relational database, not a vector store.

At query time, the LLM receives the question along with a document reference lookup table containing a hierarchical map of node summaries. It reads the top-level summaries, classifies each as relevant or irrelevant, descends only into relevant branches, and repeats until it reaches the leaf nodes containing the actual text it needs. The result is intent-aware retrieval: the model can distinguish a casual mention of a term from its formal definition because it is reasoning about structural context, not just measuring vector proximity. It can also follow cross-references like "See Appendix G" that vector similarity search simply cannot resolve. Answers are returned with node citations tracing exactly which sections were consulted, providing built-in explainability.

PageIndex is best suited for documents with natural hierarchical structure (financial reports, legal contracts, policy documents, technical manuals). For large volumes of short, unstructured text like emails and chat logs, the hierarchical overhead adds complexity without much benefit, and traditional RAG remains the better choice.

Table 1 summarizes the relative strengths of these different approaches.

Table 1: When to Use Which Retrieval Strategy

The practical rule: start with RAG for broad knowledge base coverage. Add graph retrieval when multi-hop reasoning failures are measurable. Consider PageIndex when you are working with long, structured documents where accuracy matters more than per-query speed and where the natural hierarchy of the content can be leveraged. And before building any of it, ask whether structured queries against existing data plus basic LLM reasoning can solve the problem. In many cases, it can.

Measure Before You Migrate

Whichever approach you choose, the most useful thing to build alongside it is an evaluation set. A few dozen real questions from real users, each paired with a known-correct answer and the source passage that supports it. Retrieval quality is very difficult to assess by intuition. The failure modes described above (a relevant chunk that never gets retrieved, an entity fragmented across four spellings, a chunk boundary that severed a table from the caption explaining it, etc.) are all invisible unless you are measuring against something. Teams that assess retrieval accuracy early often discover that their problem lives in the ingestion layer rather than in the model, which is both cheaper and faster to fix than swapping architectures. It is also the only reliable way to know whether moving from RAG to a graph or hierarchical approach actually provided significant improvements.

Coming Up Next

Retrieval determines what your model knows. The next post looks at what it costs. Part 4 covers the shifting economics of inference. First, why per-token pricing is being restructured across the industry. Second, what that means for organizations planning AI budgets. And lastly, why quantization, TurboQuant, and Multi-Token Prediction are turning local inference into a serious option rather than a hobbyist experiment.

Additional Resources

• Microsoft GraphRAG on GitHub
• SAS Retrieval Agent Manager (RAM)

Blog Series:

• Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
• Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It
• Part 3: Modern Retrieval Approaches: RAG, Knowledge Graphs, and PageIndex
• Part 4: Emerging Economics: Token Pricing and the Case for Local Inference
• Part 5: SAS in the Agentic AI Space

The post Modern Retrieval Approaches: RAG, Knowledge Graphs, and PageIndex appeared first on The SAS Data Science Blog.

These technologies are changing how clinical teams work, helping them analyze information more quickly, automate processes and make decisions with greater confidence.

The potential is significant. If we can reduce the time it takes to design studies, understand emerging results and make decisions, we can ultimately shorten the journey from discovery to patient impact.

But there is a part of that journey that receives considerably less attention.

The time it takes to get the data ready.

This may not sound like the most exciting part of clinical development, but it is becoming increasingly important. Before teams can analyze data, share it with decision-makers or use it to support AI-enabled workflows, they need to bring it together, standardize it and understand it. Teams need to understand its provenance, trust its quality and trace the transformations it has undergone.

That has always been true. What has changed is the scale and complexity of the problem.

A modern clinical study can draw information from electronic data capture systems, laboratories, imaging platforms, wearables, external data providers and real-world data sources. Each brings potentially valuable information, but each can also introduce different structures, standards and requirements.

Bringing those sources together is not simply a matter of moving data from one system to another. It involves understanding what the data means, applying appropriate standards, maintaining its lineage and ensuring teams can ultimately use it with confidence.

And as the volume and variety of clinical data increase, so does the effort required to prepare it.

The AI conversation brings the issue into sharper focus

The growing interest in AI has made this challenge harder to ignore.

Organizations are understandably exploring how generative AI and other forms of AI can help improve productivity, automate repetitive activities, surface insights and support decision-making across the clinical development life cycle. Some of these applications could profoundly change how teams conduct clinical research.

But AI does not remove the fundamental need for good data. In many respects, it makes that need more visible.

AI can process and interpret information at a scale that would be difficult for people alone. But its usefulness still depends on the information people give it and the context surrounding that information. In clinical development, inconsistently defined, poorly structured or difficult-to-trace data can limit how confidently teams can use those capabilities.

That is why organizations increasingly need to consider AI readiness alongside data readiness.

The issue isn’t simply whether an organization has access to AI technology. It is whether the organization sufficiently trusts, standardizes and governs the data underneath the technology to support the decisions that people will ask AI to help them make.

This is an important shift in perspective. Organizations have traditionally viewed data preparation as an operational activity that happens before the more interesting work of analysis begins. But as clinical development becomes more data-intensive and more AI-enabled, that foundation increasingly determines how quickly everything built on top of it can move.

A process designed for a different era

The traditional approach to clinical data transformation has served the industry well. Teams collect, standardize, transform and review data before eventually preparing it for analysis or submission. Given the regulatory environment in which clinical research operates, there are good reasons for the discipline and control that the process requires.

The problem is that the environment around it has changed.

Clinical teams are working with more data sources, more complex studies and a wider range of analytical requirements. Teams may now need data they once prepared for a particular downstream purpose to support multiple analyses, different teams and new forms of automation. Organizations increasingly want to reuse data rather than repeatedly prepare it for individual projects.

That creates an interesting question.

Instead of continually asking how to prepare a particular data set for the next stage of a study, what if we asked how to build a clinical data foundation ready to support whatever comes next?

That is a subtle difference, but an important one.

It moves data transformation away from occurring at specific points in a process and toward becoming a capability that continuously supports the process.

From data preparation to data readiness

There are practical benefits to making that shift.

When teams consistently standardize and govern clinical data, they can spend less time resolving inconsistencies and preparing information for individual activities. Analysts can begin their work sooner. Teams can reuse data more easily. Traceability becomes part of the process rather than **something teams have to reconstruct later.

It can also make collaboration easier.

Clinical, statistical, data management and other teams often need to work with the same underlying information, but may approach it from different perspectives. A trusted and consistently governed data foundation provides a common point of reference.

The value, therefore, extends beyond efficiency. It is about creating greater confidence in the information teams use throughout the development life cycle.

That becomes particularly important as organizations introduce more AI and automation into clinical workflows. The more technology participates in interpreting information and supporting decisions, the more important it becomes to understand and trust the data underneath it.

In that sense, data transformation isn’t just preparation for analysis anymore. It is preparation for a much broader clinical development ecosystem.

Rethinking where clinical acceleration begins

Much of the conversation around clinical acceleration has focused on what happens once teams have prepared the data.

How quickly can we analyze it? How quickly can we generate insights? How quickly can we make decisions?

Those questions remain important. But there is another opportunity that sits earlier in the process.

How quickly can we turn the data generated by a study into information we can trust, reuse and apply to support those activities?

If the answer to that question remains measured in weeks or months of manual preparation and repeated transformation, then accelerating everything downstream will only take us so far.

Therefore, clinical acceleration needs to start earlier. Organizations need to connect data transformation, standardization and governance more closely to the subsequent analysis and regulatory activities. Instead of repeatedly preparing data for each downstream use, teams can work from a common, trusted foundation that supports the clinical development process more broadly.

This approach to clinical data transformation shifts the focus from repeatedly preparing data for individual tasks toward keeping data ready for reuse across clinical workflows.

That shift becomes increasingly important as clinical development moves toward more connected and AI-enabled workflows.

The foundation may determine how far we can go

There is every reason to be excited about what AI, automation and advanced analytics could bring to clinical research. They have the potential to change not only how quickly organizations work, but how they work.

But technology alone will not determine who benefits most from those advances.

Organizations also need to consider the less visible infrastructure underneath them: the standards, governance, lineage and processes that make clinical data trustworthy and reusable.

The industry has spent years finding ways to speed up analytics. The next opportunity is to look further upstream and reduce the time and effort required to prepare clinical data so teams can actually use those capabilities.

Because ultimately, the speed of the analysis is only part of the equation.

If we want to accelerate clinical development, we also need to accelerate the journey to trusted, reusable data.

The post The clinical data foundation wasn’t designed for the AI era appeared first on The SAS Data Science Blog.

What happens when a healthcare organization wants to improve operational performance, evaluate process changes before implementing them, and develop computer vision models without relying on large collections of real-world image data? A recent collaboration between SAS and a Danish medical sterilization center explored exactly that question. The project combined process analytics, simulation, digital twin technology, computer vision, and synthetic data generation within a single workflow. What began as an effort to better understand sterilization operations ultimately demonstrated how a digital twin built with Unreal Engine can support both operational decision-making and AI model development. The work was featured at SAS Innovate 2026.

Why sterilization operations matter

Every surgical procedure depends on having the right sterile instruments available at the right time. Even a single delayed instrument tray can result in 10 to 15 minutes of operating room downtime per case. These delays are costly. Operating room downtime is estimated to cost between $20 and $100 per minute. This creates significant operational and financial impact for hospitals. Beyond efficiency, sterilization directly affects patient safety. Failures in sterile processing have been linked to surgical site infections, making process reliability essential.

The Sterile Central facility involved in this project processes surgical instruments for multiple hospitals. The facility is large and primarily automated, but it still relies on human technicians for several critical tasks. Figure 1 provides a generic representation of a sterile central environment, illustrating the types of workflows and equipment interactions involved in such facilities. It currently serves regional hospitals in the capital region and is planning to expand coverage to additional hospitals.

That growth raises an important question: can the existing process handle additional demand as operations scale? Although the full workflow spans multiple floors, the pilot phase focused on the floor where most cleaning and processing took place.

Healthcare organizations are therefore under constant pressure to improve instrument availability, optimize workflows, and maintain high sterilization standards. As the organization plans for future growth, it faces familiar operational questions:

• Can the current process support additional demand?
• Where are the true bottlenecks in the system?
• How should staffing change as workloads shift?
• What operational improvements can be evaluated before making changes in the real facility?

Answering these questions requires more than intuition. It requires a detailed understanding of how materials, equipment, and people interact throughout the process. This is where digital twins and simulation become very valuable. In this blog post, we focus on developing a high-fidelity digital twin to help achieve these goals.

A roadmap for the digital twin journey

We begin by analyzing sterilization-process data, studying the workflow, and identifying important key performance indicators (KPIs) such as subprocess duration, resource utilization, inventory accumulation, and operational bottlenecks. Using these insights, we then build a high-fidelity digital twin of the sterilization facility in Unreal Engine. This virtual environment accurately represents the physical process and serves as a sandbox for experimentation and analysis.

Once the digital twin is built, it becomes the foundation for a second use case: computer vision model development. By leveraging the realistic virtual environment, we can generate synthetic data to train and validate AI models for PPE detection. Together, these use cases demonstrate how a single digital twin can create value across multiple domains, from operational optimization and process improvement to AI model development and workplace safety.

Figure 2 summarizes this project roadmap, showing how process analytics supports digital twin development and how the resulting virtual environment enables synthetic data generation for computer vision.

Building a digital twin starts with data

Before developing the digital twin, we first analyzed historical process data to understand how the facility operated. At a high level, every instrument tray moves through four main steps: unpack, pre-wash, wash, and pack. Each tray arrives from the buffer lift in a container. After unpacking, trays and containers follow separate routes until both are sterilized and a packing robot brings them back together at the end of the process flow. Instrument trays, containers, wash racks, conveyors, and automated guided vehicles interact throughout the process, creating a system that is simple to describe but complex to model.

To build an accurate model, the analysis combined information from two data sources:

• Process-scan records that tracked how trays and containers moved through the facility.
• Equipment activity records that captured utilization and operational behavior of key resources

Together, these sources created a detailed picture of both material flow and equipment performance. The analysis focused on the following four questions, as outlined in Figure 3:

1. How long does each subprocess take?
2. How are trays and containers routed through the facility?
3. Where does inventory accumulate?
4. How do staffing requirements change under different operating conditions?

The insights gathered from answering these questions ultimately provided the parameter estimates and behavioral assumptions required for the digital twin.

Finding the real bottleneck

One of the most interesting findings involved identifying the bottleneck. At first glance, washing seemed like the obvious constraint because washing cycles consumed the most processing time. However, long duration alone does not necessarily indicate a bottleneck.

To understand where congestion forms, we first checked whether a system-level Little’s Law estimate matched a historical flow-balance estimate based on cumulative arrivals and departures. We obtained the historical estimate directly from the process-scan records by tracking how inventory changed as trays entered and left the system over time. In parallel, we calculated the Little’s Law estimate at the overall system level by combining the average arrival rate with the average time trays spent in the process. The two estimates differed by only 0.8%, increasing confidence that Little’s Law reasonably approximated the observed system behavior. Once we confirmed this relationship at the system level, we extended the Little’s Law analysis to each major process step, combining arrival rates with the average time trays spent in each stage.

This step-level view let us determine where work-in-process was accumulating, rather than relying only on activity duration: Inventory was not building up ahead of the washing stations as expected. Instead, it concentrated downstream between washing and packing. In fact, the stage between the washing machine and packing table accounted for about 65% of total expected system inventory, underscoring the distinction between the longest activity and the true flow constraint.

Figure 4 shows the expected share of long-run inventory associated with each step in the process flow. Each bar corresponds to one process segment, with the horizontal axis showing that segment’s percentage contribution to total expected inventory. The result makes the downstream accumulation visible: Step 7, which represents the flow between the washing machine and packing table, accounts for the largest share of expected inventory. This visual comparison reinforces why the bottleneck assessment focused on where work was accumulating, not simply on which activity had the longest processing time. This distinction was important because it shifted attention from individual processing times to how inventory moved through the full system.

Traditional process reviews often focus on the longest activity. The analysis demonstrated that understanding flow behavior requires examining inventory, routing patterns, and staffing simultaneously. In this case, the evidence suggested that staffing allocation and downstream workflow management may have greater impact on throughput than additional washing capacity.

Insights like these become especially valuable as inputs to a digital twin environment designed to support the future testing of operational alternatives.

Creating a high-fidelity digital twin

The next step was to transform the operational analysis into a digital twin built in Unreal Engine. The resulting virtual environment reproduces the physical sterilization facility in extraordinary detail. The level of visual realism was important for two reasons. First, it helped stakeholders recognize the real workflow in the virtual environment. Second, it made the later computer-vision work possible. Visual realism enabled comparison with real footage of people working in the facility and used the virtual environment as a realistic setting for generating synthetic data.

Instrument trays move through conveyors. Washing stations operate according to observed processing characteristics. Personnel interact with equipment throughout the workflow. To make the virtual environment operationally grounded, the digital twin required more than a visual model. It also needed data-driven parameters, including distributions of processing times, conveyor speeds, washing-machine cycle times, equipment failure behavior, and locations where inventory accumulated in the flow. The operational analysis described earlier, which examined the issues summarized in Figure 3, provided these inputs, allowing the digital twin to reflect both the physical layout and the key observed patterns in the facility’s operations.

While photorealistic visualization attracts immediate attention, the most important aspect of the digital twin is not only what people see, but what they can test. The longer-term value lies in creating a virtual experimentation environment that can support future what-if analysis. This would include exploring alternative staffing policies, studying the potential impact of equipment downtime, investigating future capacity needs, and assessing operational changes before implementing them in the real facility. In this way, the digital twin becomes a decision-making sandbox. Compared with a stand-alone simulation model, the digital twin adds value by connecting process logic to a realistic visual representation of the facility. This makes operational scenarios easier to communicate to stakeholders and enables the same environment to support synthetic image and label generation for computer vision model development.

A second use case emerges: Synthetic image data generation

Once the digital twin was built, the project expanded beyond operational analysis. This raised a new question: Could the same digital twin generate synthetic data for computer vision model development? The answer was yes.

We selected a healthcare-specific personal protective equipment (PPE) detection use case. The objective was to determine whether personnel entering controlled sterilization areas were wearing required protective equipment, including medical gowns, masks, and hair nets. Figure 5 shows an example of a MetaHuman wearing medical PPE in the high-fidelity digital twin environment.

Traditionally, developing such models requires collecting real-world images, manually labeling thousands of observations, addressing privacy concerns, and managing data access restrictions. The digital twin offered a different approach. Using Unreal Engine, synthetic workers could be generated automatically with varying appearances, PPE configurations, camera angles, camera mounting positions, fields of view, lighting conditions, and environmental settings. Because the simulation environment already knows the location of every object, it can automatically generate corresponding labels and annotations. This eliminated one of the most time-consuming aspects of computer vision development.

Figure 6 shows a metahuman entering the sterilization zone from the target camera perspective, wearing different combinations of medical PPE. The bounding box coordinates and labels shown are produced automatically by the digital twin application.

Training models without real-world images

Perhaps the most striking aspect of the project is that the computer vision model demonstrated during the project was trained exclusively on synthetic imagery. The model never saw a real-world training image. Instead, automated scenario creation generated thousands of annotated synthetic images. We used these images to train PPE detection models. We then evaluated them against real-world footage from the customer environment. This is shown in Figure 7.

The real-world footage initially indicated that the model trained on synthetic data could successfully generalize to the customer setting, although a more detailed evaluation would require a clearly defined ground-truth labeling process and quantitative performance metrics.

The approach highlights several advantages:

• Reduced dependence on customer data.
• Fewer privacy and security concerns for customers.
• Faster, automated generation of high-quality labeled data.
• Greater ability to include selected rare scenarios, edge cases, and class-balance conditions in the synthetic data generation process.
• Increased dataset variation through controlled changes in scenes and camera perspectives.
• Improved portability of trained models across different customer environments.

Rather than repeatedly collecting and labeling new image datasets for every deployment, organizations can create digital environments that produce training data on demand.

Looking beyond healthcare

Although this project focused on sterilization operations, the broader lessons extend well beyond healthcare. The same digital twin framework can support manufacturing operations, logistics networks, warehouse environments, transportation systems, supply chains, and industrial safety monitoring applications.

The project also illustrates a larger trend in analytics and AI development. Digital twins are evolving beyond visualization tools. Increasingly, they serve as decision-support environments, experimentation platforms, and synthetic data generators. In many situations, the digital twin itself becomes a bridge between physical operations and AI development.

Final thoughts

This project demonstrated the power of combining process analytics, simulation, digital twins, and AI within a single framework. The operational analysis helped identify opportunities for improving sterilization workflows. The digital twin created a realistic environment for experimentation. The same virtual environment then enabled the development of computer vision models using synthetic data rather than manually labeled images. As a foundation for future work, the project also identified clear next steps. This includes expanded scenario testing, more formal what-if analysis, and quantitative evaluation of computer vision performance on real-world footage.

What began as an operational improvement initiative evolved into a demonstration of how modern digital twins can support both decision intelligence and AI innovation. As digital twin technology continues to mature, organizations may discover that the most valuable output is not the virtual model itself, but the insights, experiments, and AI capabilities it enables.

To learn more about related SAS work, readers can explore additional resources on industrial safety applications, synthetic image data and model development, and digital twins for manufacturing. Together, these resources provide broader context for how the concepts discussed in this blog apply across industries.

The post Building a healthcare digital twin for operations and AI innovation appeared first on The SAS Data Science Blog.

Connecting Claude to Viya

The starting point was the Model Context Protocol, or MCP, which exposes a set of tools that let Claude talk directly to a running Viya environment: submitting SAS code for execution, listing and downloading files, querying CAS tables, and checking on compute sessions and jobs. In practice, this meant Claude could act as a developer with real hands on the environment — writing a SAS program, running it, reading the log, and iterating — the same loop a person would go through in SAS Studio, but conversational.

That connection mattered for a design decision made early on: rather than building a separate web server, the app itself would be hosted inside Viya's own Files Service. Every file — the HTML page, its stylesheet, its JavaScript — lives as a file object in Viya and is served back over the same domain the browser is already talking to. That "same-origin" trick avoids a whole category of cross-origin (CORS) headaches that show up the moment a web app tries to call a separate API server, and it means there's nothing extra to deploy or maintain outside of Viya.

Designing the app itself

The interface itself is intentionally plain: a single order screen. One panel lets a customer pick beer styles, pack sizes, and quantities; the other collects delivery details — address, customer type, and a delivery time window. Submitting an order pushes it into the browser's local memory and, behind the scenes, syncs it to CAS tables in Viya. Below is an "Operations" section with two buttons: one to run the routing optimization, one to reset everything and start over. Once routing has run, a Results panel appears showing the solved routes.

Keeping this to plain HTML, CSS, and JavaScript — no framework, no build step — was a deliberate choice. It keeps the whole thing inspectable as a handful of files sitting in Viya's Files Service, and it means the app can be updated by simply replacing those files' contents, which is exactly the loop Claude used throughout development: write the code to create the web app and integrate it to SAS Viya, deploy it as a file update, verify it downloaded correctly, and check the result live in the browser.

Talking to CAS

The mechanism for getting order data into SAS is simple by design. Rather than building an API layer, the browser submits a small SAS program directly to a Viya compute session through the Compute service's REST endpoints. That program embeds the order data as inline SAS DATALINES, reads it into two tables — one for customers, one for order line items — and saves them into CASUSER with promote=yes, so the tables are immediately visible to any other session on the server, not just the browser's own. Before every push, the app first drops any existing versions of those two tables, so each "Submit order" and each "Reset" leaves CAS in a clean, predictable state rather than accumulating stale data. As the web app can be used by many users at the same time, all data is saved in CASUSER, so each user sees its own orders, routings and maps.

Running the routing solver

Once orders are collected, clicking "Simulate the optimal routing" submits a second, larger SAS program to that same compute session. After re-pushing the current orders, it uses %include to run the existing VRPTW solver program unchanged — the app doesn't reimplement any optimization logic, it just triggers the program that already exists on the server's file system, pointed at the CAS tables that were just populated. That program does the real work: building the network model, applying time-window lower and upper constraints, average speed, time to load and unload the goods, vehicle capacity, and produces an optimized route assignment as a CAS table, VRP_SOLUTION, along with an interactive route map written out as an HTML file with all itineraries.

Getting the results back to the browser

This is the part that took the most iteration. A compute session's REST API doesn't hand back a table as a tidy JSON payload by default — the practical channel is the session's own log. So, the SAS code sorts the solution table by route and stop sequence, then writes each row out as a specially tagged log line (ROWCSV:) that the JavaScript on the other end knows to scan for and parse into rows for the on-screen table, complete with arrival and departure times, service windows, and travel times for each stop.

The route map took a similar approach but needed an extra trick. Viya's log has a fixed line-length limit, and the map file — a self-contained Leaflet-based HTML page with an embedded route — has plenty of lines longer than that. The fix was to have SAS chunk every line into short pieces tagged so the browser could stitch them back into an exact reconstruction of the original file, rather than losing anything to truncation.

The bigger point

What made this workable wasn't any single clever trick, but the tight loop of writing code, deploying it, and verifying it against the live environment, with a person steering priorities and approving each change along the way. It's a pattern that will generalize well beyond the vehicle routing problem with time window showed here: any existing SAS program for optimization, forecasting, econometrics, or even predictive modeling can gain a lightweight, purpose-built front end this way, hosted entirely inside Viya, with no separate infrastructure to manage. This front end can be seen as an excellent approach to simulate and visualize SAS programs outcomes in a very interactive and user friendly fashion.

The division of labor is what made that loop fast. The optimization model, the business rules and the final say stayed with the person who owns them. Claude took on the development that usually slows down projects like this: REST calls, security tokens, deployment scripts, and all the checks that confirm each change was actually comitted. Nothing runs against Viya without the code and the reasoning being shown first, and most important, approved. This keeps the entire work very transparent. And the best part: each obstacle along the way became a documented pattern, ready for the next project or application.

There is still room to grow, as always. The model could re-optimize as new orders arrive during the day, combining pickups and deliveries, or size the fleet from typical demand. None of this requires rethinking the architecture, only modifications to the SAS program and eventually a few more fields and checks to the web application.

The broader takeaway is that the front end no longer has to be the expensive part of putting a model in front of the people who use it. Many organizations already own SAS programs that answer important  business questions but only reach whoever can run the code. With Claude connected to SAS Viya through SAS Viya MCP Server, and a person approving each step, those programs can become purpose-built apps in days rather than months, hosted where the data and models already live.

Learn more

• SAS Viya MCP Server
• GitHub: SAS MCP Server
• Ask the Expert webinar: Claude the Programmer
• Latitude, Longitude, and SAS: The Many Ways to Geocode Data in SAS Viya
• How Much Farther? Calculating Distance in SAS

The post Building a vehicle routing problem app on SAS Viya with Claude as the developer in the loop appeared first on The SAS Data Science Blog.

Understanding where programs are already making an impact is one part of the picture. The next step is looking ahead to where additional outreach and resources could make a difference. For our analytics initiative supporting the Kay Yow Cancer Fund, we brought together public health data from various sources to identify locations for community outreach, education and cancer screening programs.

The data came in many formats from different federal health agencies: Excel files, flat files, ZIP archives, downloadable CSVs and REST APIs. Each source had its own structure, update cycle, and technical requirements. Luckily, all sources published their data at the county level, so we had a common key to bring them together.

Individually, these datasets provide valuable insights. Together, they can reveal something more useful: where cancer burden, social vulnerability, screening access and existing resources intersect. Simply downloading and integrating these diverse data types can quickly overwhelm organizations, especially those without a dedicated data engineer or someone experienced with data.

For this project, we used SAS^® Viya^® to integrate multiple sources for analysis and visualization.

The public health data challenge

Many health datasets are publicly available, but their formats vary. We incorporated several sources for this project. Each source provides a different view into overall community health.

• U.S. Census Bureau American Community Survey (ACS), which provides demographic data through a REST API in JSON format.
• The CDC Social Determinants of Health (SDOH) datasets in Excel files.
• The National Cancer Institute (NCI), which provides cancer incidence and mortality rates in CSV files.
• The FDA provides mammography screening facility data in a TXT file within a ZIP folder.

ACS data helps quantify population characteristics and demographics. CDC SDOH data highlights factors such as economic conditions, education, transportation and health care access. NCI data show where cancer incidence and mortality rates are high and increasing or falling. The FDA mammography facility provides physical screening locations to help address breast cancer prevention needs and identify service gaps. We also leveraged data on Kay Yow grant recipients to show where community investments already exist.

No single dataset can tell the Fund where outreach is needed most. Looking at them together, however, begins to show where high cancer burden may overlap with social vulnerability, lower screening rates and gaps in access to care.

For the Kay Yow Cancer Fund, we set out to create an analytical and interactive dashboard to identify counties with high rates of different types of cancer, high levels of social vulnerability and low rates of cancer screening and prevention to plan EmPOWERment Tours. The Tours provide communities with cancer education, screening awareness and access to local health resources.

The dashboard provides the Fund with another way to identify communities where outreach, education and screening resources could have the greatest impact.

Connecting data across formats

Answering that question first required us to bring very different types of data into the same environment.

For this project, we used several techniques to ingest the data:

• We downloaded and processed Census API data using PROC HTTP.
• We retrieved CDC datasets directly from downloadable CSV endpoints.
• We read ZIP archives published by the FDA and other Federal Agencies.
• We loaded all datasets into SAS Viya for scalable analytics and visualization.

The code and scripts are relatively straightforward because SAS provides the capabilities needed to interact with modern data sources, such as REST APIs and less modern but still valuable ones, such as flat files.

What I love the most about SAS is that, as a data analyst, I can develop a script that reads in these data sources directly into the platform for integration, analysis and visualization. I don’t have to download a file, upload it to a server and then import it to SAS. All I need to do is save my script program file and I can rerun the code if I change environments or the data refreshes.

As a bonus, I can keep all my scripts in a single GitHub repository that integrates with SAS Data and AI Studio – my personal preference for a SAS programming IDE – and with VS Code.

Back to the coding techniques I used in this project.

PROC HTTP lets me interact directly with web APIs and data services without requiring additional tools. It supports standard HTTP methods, including GET and POST, and lets me access REST APIs and web services directly from SAS programs.

After more than 15 years of programming in SAS, I think PROC HTTP may be my favorite PROC.

The following shows how to access the Census ACS data in JSON format as an example. SAS has a purpose-built access engine that reads JSON files and presents them like a traditional SAS table.

The code uses the following SAS procedures and statements:

• FILENAME statement
• PROC HTTP
• LIBNAME statement with the JSON engine
• DATA step

ACS data is very wide, with non-descriptive variable names, so after this initial ingest step, we need to perform post-processing and apply variable labels. Luckily, the JSON library also includes descriptive variable labels for each variable code, making it a convenient one-stop shop!

Similarly, federal agencies sometimes publish compressed files. SAS provides FILENAME ZIP functionality that allows programs to inspect and extract ZIP contents programmatically within SAS workflows. This blog post by Chris Hemedinger provides an excellent example of using FILENAME ZIP to access data files stored in ZIP archives without relying on external utilities. I used his approach to develop the script below for reading FDA mammography facility data.

The following code demonstrates how to download a compressed file from the FDA and use the SAS ZIP filename method to read mammography facility data directly from the archive.

The code uses the following SAS procedures and statements:

• Macro variables and functions
• FILENAME statement
• PROC HTTP
• DATA step
• INFILE and INPUT statements
• INFORMAT, FORMAT and LABEL statements

These capabilities allow data engineers and analysts like me to spend less time wrestling with file formats and more time understanding what the data can tell us.

Creating a common geographic language

Bringing the datasets into one environment solved one problem. Making them speak the same geographic language created another.

Every data source can describe geography differently. One data set may contain county names. Another may contain five-digit ZIP Codes. A third may provide latitude and longitude coordinates. Others may use state and county FIPS codes.

Without standardization, we can’t accurately combine the datasets.

In this project, we chose the county FIPS code as our common key. We then used text functions to concatenate the state and county FIPS codes to create our key codes and a unique geographic identifier.

That common identifier helped us to analyze demographic data, social determinants, metrics, health care access information and Kay Yow Cancer Fund grant recipient information together at the county level.

Now we could move beyond isolated statistics and see how different conditions overlap within the same community.

Bringing it all together with mapping and visualization

After we connected the datasets, we could look at demographic indicators, social determinants, health care resources and the Fund’s existing investments together.

That’s where the data starts becoming useful for the Fund.

Rather than reviewing cancer rates, screening access, social vulnerability and existing investments separately, the Fund can ask how those factors intersect within individual communities.

For example:

• Which counties have elevated social risk indicators, high cancer incidence rates and low cancer screening rates?
• Do those counties have local or mobile mammography facilities?
• Which communities with low cancer screening rates sit near Kay Yow Cancer Fund grantees?
• Where might additional outreach programs have the greatest impact?

Those questions shift the analysis from understanding individual datasets to understanding communities.

The bigger opportunity

While this example focuses on the Kay Yow Cancer Fund’s mission to improve cancer screening and community outreach, the underlying lesson applies much more broadly.

Important questions rarely live in one single data set.

Understanding where a community needs support may require organizations to consider health outcomes alongside demographics, economic conditions and access to existing services and resources. Any one of those factors provides only part of the picture.

For the Kay Yow Cancer Fund, bringing them together creates a stronger understanding of where programs already make an impact and where future community outreach efforts might provide the greatest benefit.

That's also how this work builds on what came before it. Measuring impact helps us understand what programs have already accomplished. Connecting that evidence with the conditions communities face can help inform what happens next.

The goal is not simply to collect more data. The goal is to connect the right data so organizations can see what they couldn’t before and make better decisions as a result.

Support the Kay Yow Cancer Fund

Help advance the Kay Yow Cancer Fund’s mission to improve outcomes for women facing cancer through research, education and access to care.

Learn more about the Kay Yow Cancer Fund →

Hear more perspectives on health care

Join us for The Health Pulse podcast as we explore fresh perspectives on digital transformation, data and innovation across health care and life sciences.

References

• Chris Hemedinger, Using FILENAME ZIP to unzip and read data files in SAS (May 11, 2015) https://blogs.sas.com/content/sasdummy/2015/05/11/using-filename-zip-to-unzip-and-read-data-files-in-sas/
• SAS Documentation, Overview: PROC HTTP : https://documentation.sas.com/doc/en/pgmsascdc/v_078/proc/n0t7v16eitluu2n15ffpfeafqszs.htm

The post Can data show where cancer outreach is needed most? appeared first on The SAS Data Science Blog.

In Part 1 of this series, we toured the model zoo. We covered what separates LLMs, SLMs, VLMs, reasoning models, and diffusion models, and the deeper split between discriminative and generative approaches. Knowing which model to reach for is a good start. But a model on its own is inert. It answers when spoken to, and that is the whole of the interaction.

This post covers the two layers that sit on top of the model and largely determine what an AI system can actually accomplish. The first is autonomy: how much initiative the system takes, what it is permitted to touch, and how much human oversight it requires. The second is the plumbing: the standards and structures, namely Skills, the Model Context Protocol, and the agent harness, that let a model reach beyond its own context window and take action in the world.

Both layers are where much of the recent terminology explosion has landed, and both are where the distinctions matter most in practice.

The Autonomy Spectrum: Chatbots, Copilots, and Agents

Another area ripe for confusion is the spectrum of AI autonomy. The terms chatbot, copilot, and agent get used loosely, but they describe meaningfully different levels of capability and independence.

Chatbots are the most familiar. They are reactive, conversational interfaces that wait for a prompt and generate a text response. No tool access, no persistent state beyond the current conversation window, no ability to take action in the world. Ask a chatbot a question, and it answers. That is the extent of the interaction. Most consumer-facing AI assistants still operate at this level.

Copilots represent a step up. A copilot augments human work by suggesting actions: code completions, document edits, analytical next steps, dashboard configurations. The critical distinction is that the human remains in control. The model proposes; the human takes action. GitHub Copilot suggests code completions, SAS Viya Copilot recommends model pipeline configurations, and an AI assistant drafting an email for your review are all copilot-level interactions. Copilots accelerate human productivity without removing human judgment or approval from the process.

Agents are where the real paradigm shift occurs. An agent operates autonomously in a loop: it plans, takes action by invoking tools, observes the results, and decides what to do next. The critical differentiator between a copilot and an agent is autonomy plus tools. Instead of proposing the next step for a human to accept, an agent executes its own plan against external systems. That said, autonomy does not mean unchecked capabilities. It is often wise and prudent to design agents so that any potentially destructive or irreversible actions, such as deleting data, sending communications, modifying production systems, or committing financial transactions, are gated behind explicit human review and approval. Only after an agent has proven itself reliable should these gates be relaxed, and even then, only in a very controlled and observable way.

The best agent architectures make this easy by design, enabling routine read-only and low-risk operations to flow freely while surfacing high-stakes decisions to a human for confirmation. The goal is not to hobble the agent but to ensure that the speed and scale of automation never outrun human judgment on the actions that matter most.

To paraphrase Andrej Karpathy, from his YouTube clip, “[With AI] we can outsource intelligence, but we cannot outsource our understanding or responsibility.” Table 1 compares and contrasts these tools.

Table 1: The Autonomy Spectrum -- Chatbots, Copilots, and Agents

The Plumbing: MCP, Skills, and Harnesses

If model architecture and autonomy define what an AI system can do, the plumbing defines how it does it. Three concepts have emerged as the foundational building blocks of modern agentic systems, and understanding the distinction between them is essential.

Skills

Skills are reusable, file-based definitions of repeatable workflows. Typically, a skill is simply a Markdown file with natural language instructions. Whereas a tool is a single function (call an API, run a query), a skill can encapsulate an entire workflow: search relevant documents, summarize them, format the output, and present it to the user. If tools are functions, skills are modules composed of multiple functions that an AI agent can understand and follow.

Model Context Protocol (MCP)

MCP is an open standard introduced by Anthropic and has been widely described as "the USB-C of AI" because it standardizes how agents connect to external tools, data sources, and services.

Before MCP, every tool integration was bespoke. Connecting an agent to Slack required custom code. But connecting it to a database required different custom code. Connecting it to a file system required even more custom code. MCP eliminates this fragmentation. Build an MCP server on the tool side once, and every AI client that supports the protocol (Claude, ChatGPT, VS Code, etc.) can connect the same way.

At its core, MCP is a combination of workflows, tools, and reference documentation. However, it lets you to easily connect your AI agent to 3rd-party tooling and APIs without having to know how to call them programmatically. The LLM handles that aspect.

Skills vs. MCP: When to Use Which

Because skills and MCP both extend what an agent can do, it is natural to wonder when to reach for one versus the other.

Use skills when you have a repeatable process or tightly scoped workflow that you want to codify and reuse. "Analyze a clinical trial data set, flag anomalies, and generate a summary report" is a skill. So is "run the quarterly compliance check against these five data sources and produce a formatted findings document." Skills encapsulate business logic, sequencing, and output formatting into a self-contained unit that can be invoked reliably every time. They are well suited for local execution where security and authentication are not primary concerns: file manipulation, text processing, data transformation, or any workflow that operates on data already within the agent's environment.

Use MCP when you want to enable users to interact with your tools or APIs via conversational natural language instead of programmatic commands, and you want to do so across different environments. This is the key shift MCP unlocks. Rather than requiring a user to know the right API endpoint, construct a query, or navigate a CLI, they simply describe what they need in plain English.

The agent then translates that intent into the appropriate tool calls through MCP. "Show me last quarter's revenue by region" becomes a natural language request that MCP routes to the right database query, analytics API, or reporting service behind the scenes. MCP is designed for remote tool calling across authenticated gateways, handling the handshake with external services, managing credentials, and respecting access controls, making it the right choice when the agent needs to reach beyond its local sandbox into enterprise systems, third-party APIs, or cloud services that require governed authentication.

That doesn't mean the two are mutually exclusive. A skill might orchestrate several MCP tool calls under the hood, or an MCP server might utilize embedded skills. The line is blurry, but generally, skills define the workflow while MCP provides the integration. Table 2 provides more context and differentiation.

Table 2: Skills vs. MCP -- When to Use Which

Harnesses

Another term you may have heard thrown about is “harness”. A harness is the complete runtime infrastructure wrapping an AI model: the orchestration loop, tool dispatch, memory management, context assembly, error handling, and guardrails. Martin Fowler and Birgitta Böckeler of ThoughtWorks crystallized this with a simple formula: Agent = Model + Harness. The model provides the intelligence; the harness provides the structure that makes that intelligence reliable and useful.

A useful way to think about this is with a car analogy. The model is the engine, but the harness is the rest of the vehicle. An engine by itself sits on a shop floor and spins. It takes a chassis, steering, brakes, a transmission, and a dashboard to turn that raw power into something that actually gets you where you need to go safely. The harness provides the steering (context assembly and tool routing), the brakes (guardrails and human-in-the-loop gates), the transmission (memory and state management), and the dashboard (observability and logging). Swap in a more powerful engine and the car gets faster, but without the rest of the vehicle, horsepower is just noise. And crucially, good harness design is modular: as models improve, components of the harness that compensate for model weaknesses can be removed. Table 3 spells out this analogy explicitly.

Table 3: The Harness as a Car Analogy

An excellent blog post by the author of bits-bytes-nn, titled "From Prompts to Harnesses: Four Years of AI Agentic Patterns," traces the evolution of AI engineering rigor over the past few years across three distinct eras:

•  Prompt Engineering (2022-2024): "What should I say?" The industry believed instruction quality was the sole determinant of AI response success.
• Context Engineering (2024-2026): "What information should I provide?" The realization that what fills the context window and is available to the AI agent matters more than the prompt itself.
• Harness Engineering (2026+): "What system should I build?" The acceptance that the design of the entire system is the real problem to be solved. And that intelligent systems can make up for inadequate models.

The core thesis is compelling. As agentic AI proliferates within software development, engineering rigor does not disappear. Rather, it relocates to a higher level of abstraction. This covers writing code, curating context, and designing the environment in which agents operate. For analytics and data science practitioners, this pattern is familiar. It mirrors the evolution from hand-coding statistical models to configuring automated pipelines to designing governed analytical ecosystems. The abstraction level rises, but the need for rigor remains. Table 4 summarizes this recent history.

Table 4: Three Eras of AI Engineering

Coming Up Next

Autonomy and plumbing determine what an agent can do. The next question is what it knows. Part 3 turns to retrieval: how to ground a model in your own enterprise data, and how standard RAG, knowledge graphs, and the newer PageIndex approach compare when you need answers that are accurate, traceable, and defensible.

Additional Resources

• Anthropic: Building Effective Agents
• Anthropic: Harness Design for Long-Running Application Development
• From Prompts to Harnesses: Four Years of AI Agentic Patterns
• Martin Fowler / Birgitta Böckeler: Harness Engineering
• Andrew Ng: Agentic AI Design Patterns
• Model Context Protocol (MCP)

Blog Series:

• Part 1: The Model Zoo: LLMs, SLMs, and VLMs, Oh My!
• Part 2: From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It
• Part 3: Modern Retrieval Approaches: RAG, Knowledge Graphs, and PageIndex
• Part 4: Emerging Economics: Token Pricing and the Case for Local Inference
• Part 5: SAS in the Agentic AI Space

The post From Chatbots to Agents: The Autonomy Spectrum and the Plumbing Beneath It appeared first on The SAS Data Science Blog.

As technology continues to evolve rapidly, ethically centered model design is becoming increasingly important. In this post, we provide a brief overview of SAS Models and describe how all SAS models are built using SAS’ core principles for responsible innovation.

The SAS Applied AI and Modeling division is focused on designing and building trustworthy, industry-focused models. Drawing on decades of SAS expertise, these models help organizations solve complex business challenges with proven approaches. Examples of business problems addressed include:

• Credit Card Fraud
• Payment Integrity for Food Assistance
• Entity Resolution
• Medication Adherence
• Supply Chain Optimization
• Industry Safety
• Document Analysis

Challenges around building ethical AI models

Currently, no single global standard exists for designing ethical AI models. When organizations fail to clearly document assumptions and risks, AI models often become opaque, difficult to explain, and hard for users to trust. Given these challenges, the SAS Model development group collaborates with industry experts, consults the SAS Ethics Committee, and applies the SAS core principles for responsible innovation when developing our models.

SAS core principles for responsible innovation

The SAS core principles for responsible innovation include human-centricity, inclusivity, accountability, privacy and security, robustness, and transparency. SAS incorporates these principles into the selection, design, and function of all SAS Models. Over the next few sections, we will highlight each core principle and provide examples of how our models take into account each of these principles during design and implementation.

Human centricity: Promote human well-being, human agency and equity

SAS puts people first by developing models that improve well-being. For example, we have built models to support worker safety in the manufacturing industry, medication adherence risk in the health care industry, and payment integrity in the public sector. Each of these models focuses on using data to improve the human condition or help ensure services reach the right people.

Additionally, SAS designs its models with end users in mind. Model pipelines allow end users to control and review the data used to train and develop models. This helps ensure the model reflects their specific population, use case, and business use case.

Lastly, SAS Models are also designed to help eliminate bias and promote equity. For instance, the medication adherence risk model incorporates SAS procedures that assess the model for bias across sensitive variables such as race and gender. By incorporating bias assessments into model design, we enable end users to examine and control for equity during model deployment.

Inclusivity: Ensure accessibility and include diverse perspectives and experiences

Inclusivity is a feature of our model development, both in the selection of models to build and in the models themselves. We include diverse stakeholder feedback throughout model development to capture diverse perspectives. By including diverse stakeholder feedback, we help ensure our models reflect real-world complexities and help prevent bias. Before beginning work on a new model, our development group collaborates with several divisions across SAS and external stakeholders to review model design. Throughout model development, we set up regular touchpoints with stakeholders to review model design and output. Additionally, SAS ensures accessible model design by internationalizing our models for use in many languages. Lastly, to ensure all reports are accessible to everyone, SAS Visual Analytics reports are designed using accessible color palettes.

Accountability: Proactively identify and mitigate adverse impacts

To help ensure accountability in all our models, we proactively identify and mitigate risks and potential biases throughout the model lifespan. Examples of ways we mitigate bias include: thoughtful data procurement, extensive model testing, and documenting appropriate model applications. All SAS Models come with extensive documentation highlighting known risks. The documentation includes clear intended-use statements to help prevent inadvertent use of the model for purposes that deviate from the original design. To help mitigate and control bias, model designers carefully select data that accurately represents trends and associations found in the target population. Furthermore, SAS Models include procedures to check for missing variables and outliers that may skew model results.

Privacy and security: Protect the use and application of an individual's data

From model development to model deployment, we focus on preserving privacy and providing model security. SAS ensures privacy when developing models by using de-identified, synthetic data, or digital twin data to develop models. To prevent external access, SAS compiles the code for all SAS Models. Licensing checks also ensure only authorized users can access them.

Beyond development, our SAS Viya models leverage the privacy and security features built into SAS Viya. This includes features like automatic detection of sensitive data and data lineage tracking. SAS has prioritized the security and compliance of SAS products, with certifications from many regulatory and compliance organizations, including FEDRAMP and NIST. Learn more about SAS certifications.

Robustness: Operate reliably and safely, while managing potential risks throughout a life cycle

The SAS Modeling group uses several approaches to ensure models perform consistently and accurately across environments. First, SAS Model pipelines use champion model analysis to identify the best-fitting model based on the end user’s data. Champion model analysis deploys several model types to identify which performs best on the end user’s data. Second, our models include model-fit statistics that give end users tools to monitor model and concept drift. Third, we run all models through extensive above-the-line and below-the-line testing before deployment. Lastly, all our models leverage our own CI/CD pipeline to update and version models with the latest security and dependency updates available from SAS.

Transparency: Openly communicate intended use, risks, and how decisions are made

Transparency ensures that all end users clearly understand the model and how it arrived at its results. To support transparency, all SAS Model documentation includes detailed information about the model. SAS includes model assumptions, data requirements, potential risks, modeling decisions, and intended use statements in all model documentation. Furthermore, all our models are designed to clearly show how decisions are made and empower users with the ability to monitor the model for concept or model drift. For example, to help monitor concept drift, model pipelines include output tables such as variable importance and Shapley values to support interpretation.

Responsible AI is a team practice

Incorporating AI ethics into our modeling process helps us build better, safer, and more trustworthy models. For SAS Model developers, responsible design means asking hard questions early, documenting decisions clearly, involving the right stakeholders, and collaborating with customers to review model performance over time.

READ MORE | Trustworthy AI at SAS

LEARN MORE | SAS Responsible Innovation and Trustworthy AI Online Course

The post AI ethics and SAS Models: Designing models with trust, transparency, and accountability appeared first on The SAS Data Science Blog.