Which region drove the increase in sales?

How did that compare with last year?

Which products contributed most to the change?

What started as a simple question about a dashboard has become a deeper analytical exploration. But traditionally, answering that next question can mean searching through other report pages, finding a different dashboard or asking an analyst or report designer to create an entirely new view of the data.

That creates a gap between curiosity and insight.

For business users viewing reports in SAS^® Visual Analytics, SAS^® Viya^® Copilot helps close that gap. Instead of being limited to the questions a report was originally designed to answer, users can ask their own questions about the underlying data and explore the answers instantly.

Let's explore how Viya Copilot helps report viewers move beyond the dashboard and discover the insights that matter to them.

When the dashboard sparks curiosity

Reports and dashboards are designed to answer important business questions. They bring together the right data, metrics and visualizations to help users understand what is happening. In fact, the most useful dashboards should lead to new questions.

A dashboard might show overall sales performance, but a user might want to understand how sales changed in a particular region. A report might show profit by product, but the next question could be how those products performed over time. Or a user might want to see a familiar measure broken down by a category that isn't currently displayed.

Traditionally, answering these questions requires another step. Users might need to search through the report for an existing visual, navigate to another dashboard or ask another team to create a new report.

Viya Copilot introduces a more direct path.

When the next answer isn’t already in the report

When viewing a report, users can ask Viya Copilot questions about the underlying data using natural language. Copilot interprets the question, queries the available data and returns the result as a visualization.

For example, a user might ask:

• "Show me sales for the Northeast region."
• "How did revenue change over the last 12 months?"
• "Break profit down by product category."
• "Which regions had the highest sales last quarter?"

Copilot can use existing measures and columns from the report's data to answer these questions, applying the appropriate categories, measures, filters or ranks based on what the user asked.

This means users no longer have to search through report pages for the right chart or wait for another team to build a new view.

They can ask the question and explore the answer immediately.

From predefined views to self-service exploration

A report author's job is to create a focused analytical experience. That often means selecting the most important metrics, dimensions and visualizations for a particular audience.

But no report can anticipate every question a user might have. And it shouldn’t have to.

That's where conversational analytics can extend the value of a report.

With Viya Copilot, users aren't limited to the views that were originally included in the report. They can describe what they want to see and Copilot can create a new visualization to help answer the question.

This gives report viewers more room to explore without requiring report authors to build every possible analysis in advance. Business users can explore beyond the predefined dashboard while still working within the report's analytical context.

The result is a more dynamic experience: the report provides the starting point, and the user's questions determine where the analysis goes next.

Understanding how Copilot answered your question

Natural-language questions make analytics more accessible, but users also need to understand how their questions were translated into analytical results.

Viya Copilot provides transparency into how it interpreted a question and built the resulting visualization. By expanding the information pop-up, users can see which categories and measures Copilot selected from the available data, as well as the filters or ranks applied based on the question.

This transparency is especially important when a question requires a calculation that doesn't already exist in the report. Copilot can generate new expressions on the fly to create ad-hoc measures, such as aggregated or periodic calculations. For example, a report might contain sales and profit, but a user might want to understand profit margin. Or they might want to compare a measure across time using a periodic calculation.

When Copilot creates a new calculation, the expression logic is available alongside the visualization, allowing users to validate how the result was calculated.

Whether Copilot uses existing measures and columns or generates a new expression, users can see how their question translates into the analytical result. This helps make conversational analytics not only more accessible but also more transparent and trustworthy.

More freedom to ask, without giving up control

Self-service exploration doesn't mean giving users ungoverned access to data.

Governance remains part of that experience. The ability to explore beyond predefined views still operates within boundaries established by the report designer.

The report designer determines which data Viya Copilot can access when responding to a user's questions about the report. By default, only data items assigned to objects in the report are available to the viewer.

From there, report designers can choose to allow viewers to access any data item in the report's data source, even when that data item is not explicitly used in the report. Or they can disable the SAS Viya Copilot pane completely for report viewers.

That creates an important balance: viewers gain more freedom to follow their questions, while report designers and organizations retain control over the data available to Copilot.

From report viewing to insight discovery

A dashboard doesn’t have to anticipate every question its viewers might ask. It can provide the context, trusted data and starting point, while giving users room to follow the questions that emerge.

Business users can move from consuming the analysis created for them to exploring the questions that matter to them, while remaining within the analytical and governance boundaries established by the report designer.

With SAS Viya Copilot, the report becomes less of a fixed destination and more of a starting point for exploration. The dashboard provides the starting point. The questions users ask determine where the analysis goes next.

Learn more about how SAS Viya unifies data, analytics and governance in one platform, so teams can deliver transparent, trustworthy insights at scale.

The post Beyond the dashboard: how SAS Viya Copilot lets curiosity lead the analysis appeared first on The SAS Data Science Blog.

In an earlier series on multimodal transformers, I introduced zero-shot transformer models and highlighted two standout examples: GLiNER for named entity recognition and SAM for image segmentation. A follow-up post made the case for Small Language Models as a practical middle ground between traditional NLP and full-scale LLMs and ended with a prediction: the future of enterprise AI would be built on top of smaller, locally deployed models. That prediction seems to be coming to fruition faster than I expected.

The goal of this post, and of the four that follow it, is to cut through the noise. Rather than one sprawling field guide, I have broken the material into a series of shorter, focused installments meant to familiarize a practitioner with emerging technologies and techniques: the model zoo (this post), the autonomy spectrum and the plumbing that supports it, the retrieval architectures used to ground models in enterprise data, and the shifting economics of inference. And lastly, to take a look at how SAS is putting all of it into practice. Taken together, they are meant to serve as a field guide for analytics practitioners navigating this rapidly evolving terrain.

In just a few months, the AI landscape has undergone what can only be described as a technological and terminological explosion. New standards, new architectural patterns, new product categories, and an avalanche of acronyms have emerged at a pace that makes even seasoned practitioners feel like they need a glossary just to follow the conversation. As Andrej Karpathy quipped in 2023, "the hottest new programming language is English." Three years later, he was only half right. English is still part of the equation, but the real engineering has moved far beyond crafting the perfect prompt.

Different Types of Models

We begin where most confusion starts: with the models themselves. One of the first sources of confusion in the current AI landscape is the sheer variety of model types. You will hear people throw around terms like LLM, SLM, VLM, reasoning model, and diffusion model almost interchangeably, but they refer to meaningfully different tools with distinct strengths. See Table 1 for an overall summary.

Large Language Models (LLMs) are the headline-grabbers. These are text-centric models with parameter counts ranging from tens of billions to trillions. GPT-5, Claude Opus, and Gemini Pro all fall into this category. They excel at general-purpose reasoning, open-ended generation, and complex multi-step tasks. They are also expensive to run, typically costing between $2 and $30 per million tokens, and they generally require significant compute infrastructure. Think of LLMs as the senior architects of the AI world: brilliant generalists who can tackle almost anything, but whose time is expensive and best reserved for tasks that genuinely require their breadth.

Small Language Models (SLMs) range from a few million to roughly 10 billion parameters. Key examples include Microsoft's Phi-4 Mini (3.8B parameters), Meta's LLaMA 3.2 (1B and 3B variants), NVIDIA's Nemotron Nano, and the GLiNER family I discussed in the previous series. SLM inference costs are 5 to 20 times lower than LLMs. A June 2025 NVIDIA position paper, "Small Language Models are the Future of Agentic AI," argues that most agentic work (parsing commands, calling tools, producing structured output, summarizing, routing) is repetitive and narrow, making SLMs the natural fit. They can be fine-tuned to strict output formats, run on local consumer-grade hardware, and deliver real-time latency without heavy parallelization. Think of them as a junior employee or intern who can consistently accomplish a well-defined task.

SLMs also play an increasingly critical role in AI safety and governance. Because they are fast and cheap to run, they are ideal for implementing computationally efficient guardrails within a larger agentic process: scanning inputs for prompt injection or jailbreak attempts, detecting toxic or harmful content in model outputs, and enforcing content policy compliance, all in real time and without the latency or cost penalty of routing every safety check through a full-scale LLM. In an agentic workflow where a single user request might trigger dozens of model calls, having lightweight SLM sentinels standing guard at each step is far more practical than asking the expensive orchestrator to police itself. If LLMs are the architects, SLMs are the skilled tradespeople: fast, efficient, and excellent at executing well-defined tasks, including keeping the rest of the system honest.

Vision Language Models (VLMs) fuse a vision encoder with a language decoder, enabling the model to process images and text jointly. They span sizes from compact (Qwen2.5-VL at 7B parameters) to frontier scale. The key distinction is multimodal input: whereas LLMs and SLMs can accept only text as input, a VLM can accept both text and images. This enables them to look at scanned PDFs, photographs, charts, or diagrams and understand what they see in context. This makes VLMs invaluable for document understanding, visual question answering, and any task where layout or visual structure of information matters as much as the words themselves.

Reasoning Models are a more recent designation given to frontier LLMs. Standard LLMs generate responses token-by-token in a single forward pass, essentially "thinking out loud" as they write. Reasoning models, by contrast, are trained to perform an explicit chain of thought before producing a final answer. They allocate additional compute at inference time, working through a problem step by step internally before committing to a response.

It’s akin to a model performing “Type II thinking” from Daniel Kahneman’s book, “Thinking Fast and Slow”. Most frontier LLM models now include a thinking parameter that can be toggled to influence the amount of effort (and tokens) that should be spent in “thinking” mode. The trade-off is straightforward: reasoning models are slower and more expensive per query (that extra thinking consumes tokens), but they dramatically outperform standard models on tasks requiring multi-step logic, mathematical proof, code debugging, and complex analytical reasoning. For straightforward generation tasks like summarization or translation, a standard LLM is faster and cheaper. For complex tasks where getting the answer right matters more than getting it fast, reasoning models are increasingly the tool of choice.

Diffusion Models operate on an entirely different principle from the language models above. Rather than predicting the next token in a sequence, diffusion models learn to generate data by gradually reversing a noise-addition process. During training, the model learns how to take pure noise and iteratively refine it into coherent output. This approach has proven spectacularly effective for image generation (Stable Diffusion, DALL-E 3, Midjourney), video generation (Sora, Runway), audio synthesis, and even molecular design.

More recently, diffusion-based architectures have begun appearing in code generation and structured data synthesis, blurring the line between generative media and traditional AI tasks. For enterprise applications, diffusion models are most relevant in scenarios involving synthetic data generation, visual content creation, and augmenting training data sets where real-world data is scarce or sensitive.

Table 1: Different Language Model Variants

The key takeaway is that these are not competing alternatives. They are complementary tools designed for different jobs, and the most effective AI systems use them in thoughtfully designed combinations. An agentic workflow might use a reasoning model to plan a complex task, delegate extraction work to an SLM, hand visual document processing to a VLM, and generate synthetic training data with a diffusion model, all orchestrated by a reasoning LLM acting as the coordinator.

Generative vs. Discriminative: A Foundational Distinction

Underneath all the terminology above is a more fundamental split that predates the current wave of generative AI entirely: the difference between discriminative (deterministic) models and generative models. Traditional predictive analytics — credit scoring, fraud detection, churn prediction — is built almost exclusively on discriminative models. Given a set of inputs, a discriminative model learns the boundary or mapping to a specific output: a class label, a probability, a risk score. Feed it the same inputs twice, and it returns the same answer every time. That determinism is precisely why these models have been the backbone of regulated industries for decades: their behavior is reproducible, auditable, and explainable through reason codes, variable importance analysis, or heuristics.

Generative models — including every model type discussed above work differently. Rather than learning a fixed mapping from input to output, they learn the data's underlying distribution and then sample from that distribution to produce new content. Feed a generative model the same inputs and, even with the temperature set to zero, you will get different (though hopefully equally valid) answers. That is a feature, not a bug, when the goal is creative or open-ended output, but it is also exactly why generative AI introduces governance challenges that classical discriminative models never had to contend with: hallucination, output variability, and prompt-level attack surfaces.

Hallucination means a model can state a plausible-sounding falsehood with complete confidence; output variability means the same input can yield inconsistent decisions over time, which complicates audit trails and reproducibility; and prompt-level attack surfaces mean a carefully crafted input can manipulate the model’s behavior in ways a static scoring algorithm was never exposed to. Each is a new class of risk that governance frameworks built for discriminative models were never designed to catch.

Both are AI models, but the distinction has important implications for use case suitability. See Table 2 for a summary of these subtleties.

Table 2: Discriminative vs. Generative Models

This is not an either/or choice. The most mature AI programs pair the two. A discriminative model handles the deterministic decision that must be defensible in an audit (approve or decline, flag or clear), while a generative model handles the surrounding tasks that benefit from flexibility (summarizing the case for a reviewer, drafting an explanation letter, or extracting unstructured details that feed the discriminative model’s inputs).
The ideal setup for an enterprise use case might involve using deterministic analytic models upstream.  Then feeding the model artifacts to a downstream generative model. This can assist with understanding the outputs and providing human reviewers with guidance on how to interpret and act on the results.

Ultimately, knowing which category a given model belongs to is the first step in knowing what kind of governance, monitoring, and validation are required to convert a prototype into a vetted, production-ready solution.

Coming Up Next

Knowing which kinds of models exist is only half of the picture. Ultimately, choosing well also means understanding the systems we build around them. The next post in this series moves up a level of abstraction to look at the autonomy spectrum, the meaningful differences between a chatbot, a copilot, and an agent, and the plumbing that makes agentic behavior possible: Skills, the Model Context Protocol, and the harness that turns a capable model into a reliable system.

The post The Model Zoo: LLMs, SLMs, and VLMs, Oh My! appeared first on The SAS Data Science Blog.

Highly trained nurses and clinicians spend hours navigating fragmented medical records: scrolling through PDFs, interpreting handwritten notes and cross-referencing guidelines; not because the work requires their expertise, but because the information they need isn’t readily accessible. The real challenge isn’t clinical complexity. It’s operational friction.

As workforce shortages continue to strain health care systems, much of the conversation has focused on forecasting demand and optimizing staffing levels. But there is another, often overlooked lever: how efficiently existing clinical resources are actually used.

Before asking how many reviewers are needed, it’s worth asking a simpler question: how much of their time is truly spent reviewing?

The operational reality behind prior authorization

In prior authorization and medical necessity review, decisions must be evidence-based, consistent, and auditable. But the path to get there is anything but efficient.

Clinical documentation arrives in fragmented formats, from scanned PDFs, faxes, discharge summaries, and operative notes, each with its own structure, or lack thereof. Reviewers must determine the appropriate policy, locate relevant evidence within the record, and document a defensible rationale.

The work is meticulous, but much of it is not clinical. It is administrative navigation disguised as clinical review.

This creates a bottleneck. Throughput slows, turnaround times increase, and highly specialized clinicians spend the majority of their effort on tasks that do not require their level of training. In a constrained workforce environment, this is not sustainable.

From documents to intelligence

Addressing this challenge begins with transforming unstructured medical records into something usable.

Traditional approaches stop at digitization, simply converting images into text. But in healthcare, text alone is not enough. What matters is meaning.

SAS® Document Analysis for Health Record Review extracts clinically relevant concepts directly from medical records, including diagnoses, procedures, medications, lab values, and timelines, and organizes them into structured, analytically ready formats. Each extracted element is linked back to its original source, preserving the traceability required in regulated environments. This creates a foundation where clinical data is no longer buried in documents, but accessible and ready to be used for downstream analytics.

The real shift, however, happens when that intelligence is embedded directly into decision workflows.

Embedding intelligence into review

Once clinical data is structured, it can be aligned directly to policy criteria within the review process.

In practice, I’ve leveraged SAS® Retrieval Agent Manager to retrieve relevant clinical evidence, map it to discrete policy requirements, and return a structured response such as met, not met, or unknown, along with traceable citations tied to specific pages in the medical record.

Instead of asking reviewers to interpret both the guideline and the medical record simultaneously, the system presents a structured, evidence-backed view, turning what was once a manual search into a guided validation process.

For example, in a knee replacement use case for a patient, rather than manually searching for documentation of prior conservative treatment, the system surfaces relevant evidence, such as physical therapy duration or imaging results directly within the checklist, with links back to the exact page in her medical record where the information was identified.

At the core of this approach is guideline-locked AI. Rather than allowing models to generalize across multiple sources, the system anchors every evaluation to a single, deterministic policy, ensuring decisions remain consistent, explainable, and aligned to clinical and regulatory expectations.

Governance before generation

Equally important is what happens before any AI-driven reasoning occurs.

The process is orchestrated through a governed decision flow, implemented through SAS Intelligent Decisioning, where policy mapping, provider validation and routing logic are enforced deterministically with automated business rules before any evaluation takes place.

This ensures the correct policy is selected, providers are validated, and exceptions are routed appropriately. Only then is structured clinical data passed into the AI-driven evaluation layer.

The result is not open-ended automation, but a bounded system where AI operates within clearly defined clinical and regulatory constraints.

Shifting how clinical time is spent

The impact of this shift is not just technical, it is operational.

For the reviewer, the experience changes entirely. Instead of navigating fragmented documentation, they enter through a centralized interface where cases are triaged and contextualized within SAS® Visual Analytics.

Drilling into a case reveals a structured checklist of clinical criteria, supporting evidence, and direct links back to the original medical record. Reviewers can jump directly to the exact page where evidence was identified, eliminating manual search. If there are additional needs to further triage the data and case, the reviewer can directly ask questions based on the patient’s specific medical records and policy guidelines.

What was once a time-consuming process becomes a focused review centered on validation and decision-making.

Building trust through transparency

In healthcare, automation without transparency is not an option.

Black-box outputs are difficult to trust and even harder to defend. By contrast, an evidence-based framework ensures that every decision can be traced back to both the policy and the underlying medical record.

Reviewers are not asked to trust the system. They are enabled to verify it instantly.

This is where automation and auditability converge.

Extending beyond prior authorization

While prior authorization is a natural starting point, the implications extend further.

The same approach can be applied to pre-payment claims review, post-service medical necessity validation, and broader payment integrity workflows. Anywhere clinical decisions depend on unstructured documentation the opportunity exists to reduce friction and improve consistency.

A more practical path to resource optimization

By transforming unstructured data into structured intelligence and embedding it into governed decision workflows, organizations can unlock capacity within existing teams. Not by asking more of clinicians, but by removing the barriers that slow them down.

In that sense, AI-driven medical record intelligence is not just a technology investment. It is a practical way to extend the impact of a limited workforce while improving the experience of the people at the center of it.

Learn more

• Scaling submission automation with SAS Clinical Acceleration on Viya
• Detecting Alzheimer's earlier with AI
• How to build predictive health care AI from data to decision
• A Digital Assistant for Medical Record Review

The post Optimizing clinical and operational resources through AI-driven medical record intelligence appeared first on The SAS Data Science Blog.

The SAS Viya MCP Server addresses that challenge by exposing SAS data, analytics, models and decisioning capabilities as standardized MCP tools that AI assistants such as Claude Cowork and other MCP-compatible clients can securely consume. Rather than executing the analytical work itself, the AI assistant becomes an orchestration interface, while SAS Viya remains the trusted execution layer behind the workflow.

This post highlights a credit evaluation use case and the architectural components behind it. The centerpiece is a 10-minute demo of SAS Viya MCP Server and Claude Cowork. Watch it now, or keep reading for a closer look at the architecture behind it.

Beyond tool calling: MCP for enterprise analytics

Large language models (LLMs) excel at understanding language and reasoning over information, but they have no inherent awareness of enterprise data, analytical assets or business processes. MCP provides a standardized way for AI assistants to discover and invoke enterprise capabilities.

The SAS Viya MCP Server extends that concept by exposing trusted SAS assets as governed tools. Available as an open-source project on GitHub, the SAS Viya MCP Server currently includes more than 40 capabilities spanning data governance, data access, AutoML, model management, reporting and interaction with deployed models and decisions.

This makes it possible to orchestrate analytical workflows through natural language while execution, governance and lifecycle management remain within SAS Viya. Existing analytical investments including models, decision flows, governance frameworks and domain expertise can be reused rather than recreated inside LLM applications.

Banking use case: Credit evaluation

In the banking demo, Claude Cowork orchestrates creating a credit classification model designed to predict whether an applicant represents a good or bad credit risk. Using a recently released data set from Santander AI Lab to augment a well-known German credit data set, a natural language request coordinates multiple activities across SAS Viya:

• Data ingestion
• Data profiling and governance review
• Automated machine learning
• Model evaluation and comparison
• Model publication
• Operational scoring

The value is not that an AI assistant can build a model. The value is that the assistant can coordinate a governed analytical workflow while trusted SAS services perform the underlying analytical work. The result is a more efficient path from data to insight without sacrificing transparency or control.

Governance is built into the architecture

Many agentic AI demonstrations focus on automation. Regulated industries such as banking require more than automation. They need workflows that can be reviewed, explained and controlled.

In this workflow, analytics and model management remain within SAS Viya. Users can examine profiling results, review model pipelines, validate outputs and understand how results were generated rather than relying on a black-box process.

Human approval also remains part of the model life cycle. Models generated through the workflow are not automatically deployed; stakeholders review and approve assets before deployment. That distinction matters in banking and other regulated environments where oversight, validation and approval are mandatory.

What technical teams should notice

Pay attention to several architectural patterns in the demo:

• SAS capabilities are exposed as standardized MCP tools, rather than through custom integrations.
• Analytical execution remains inside SAS Viya while the AI assistant orchestrates activity.
• Governance, auditability and access controls remain enforced through existing SAS capabilities.
• Enterprise platform details and internal SAS endpoints are not exposed directly to the underlying LLM.
• Human approval remains part of the model lifecycle before deployment.
• Existing SAS assets, models and analytical workflows can be reused rather than rebuilt for each AI assistant experience.

These patterns are applicable well beyond credit modeling and can be extended to fraud detection, marketing optimization, customer intelligence, anti-money laundering and other analytics-driven business processes.

Take the next step

If you're ready to move from concept to hands-on practice, dive into these resources:

1. Free Hands-On Lab: Agentic AI - How To with SAS Viya

Use SAS Agentic AI Accelerator to:

• Register, publish, and deploy proprietary and open source LLMs.
• Build decision workflows that combine LLM judgment with deterministic models.
• Deploy AI-driven decisions into Azure AI Assistants.
• Monitor model cost, performance, and sentiment.
• Gain practical experience with AI governance in a real-world environment.

2. Training: SAS Decisioning Learning Subscription

A new SAS Viya MCP Server chapter will teach you how to:

• Connect Claude Cowork to SAS Viya.
• Connect GitHub Copilot to a governed SAS Viya environment.
• Work within enterprise-grade governance and decisioning frameworks.

The post Building a governed banking workflow with SAS® Viya® MCP Server and Claude Cowork appeared first on The SAS Data Science Blog.

Health care organizations sit on enormous volumes of clinical, claims, and operational data. The challenge has never been collecting it. The challenge is turning it into something a care manager can act on before a patient's condition deteriorates, before a preventable ER visit occurs, or before a high-risk pregnancy goes unmonitored.

That's the problem SAS Health was built to solve, not by replacing clinical judgment, but by giving clinicians and analysts the signals they need at the moments they need them.

Why predictive modeling matters in health care right now

Value-based care models are pushing payers and providers to do more than report on what already happened. CMS quality measures, HEDIS scores, and state Medicaid program requirements all demand that organizations identify risk early and intervene before costly outcomes materialize.

But early identification at scale requires more than dashboards and descriptive statistics. It requires models that learn from historical patterns, including demographic, clinical, behavioral, and socioeconomic factors, to generate individual-level risk scores that drive targeted outreach.

SAS Health, built on the SAS Viya platform, provides the data foundation for this work, including an industry standard health data model to simplify health data management and accelerate analytic discovery to make decisions confidently.

On top of that foundation, SAS Viya delivers a full suite of machine learning and AI tools accessible to both coders and non-coders alike.

The technical foundation: from data ingestion to agentic AI

Let's walk through the end-to-end workflow that makes predictive modeling on SAS Health and SAS Viya practical, not theoretical.

1. Data integration and preparation (SAS Health)

SAS Health provides out-of-the-box (OOB) industry standard data models that help organizations unify clinical, claims, eligibility, and enrollment data in a single, governed data and AI environment. This gives teams a strong foundation for analytics without requiring them to build every data structure from scratch.

Just as important, the platform supports the ongoing preparation of new analytic-ready data assets beyond the initial ingestion layer. Using open source programming, SAS and SQL-based transformation, or no-code/low-code data preparation tools, teams can create additional curated datasets for ad hoc analytics, investigation, reporting, and model development. This gives organizations flexibility to extend the core data models with business-specific data products while preserving governance, repeatability, and alignment across analytic workflows.

And not every user preparing cohorts or exploring data has to be a data scientist. SAS Viya Copilot for Clinical Data Discovery uses AI-powered natural language search to let clinicians and researchers query health care data conversationally. Ask a question in plain language, get a report back, no code required. This accelerates the feedback loop between insight generation and clinical decision-making.

2. Predictive modeling: build your own or deploy industry accelerators (SAS Viya)

With the data loaded and available to analytic teams, SAS Viya gives you two paths to predictive modeling. You can either build custom models from scratch that are tailored to your population or deploy industry accelerators that are purpose-built for health care. Most organizations will use both.

Build your own with Model Studio

The SAS Viya platform provides a drag-and-drop interface for constructing full model pipelines, from preprocessing through supervised learning to post-processing, without requiring a single line of code.

A typical pipeline might look like this:

• Preprocessing: Imputation of missing values, transformation of skewed variables (e.g., BMI, weight gain), variable selection, and feature engineering.
• Supervised learning: Choose from gradient boosting, random forests, neural networks, logistic regression, support vector machines, and more.
• Post-processing: Ensemble methods that take a weighted vote or weighted average across multiple models for a final, more robust prediction.

You can build multiple pipelines side by side. For example, one pipeline might focus on tree-based models with variable transformations, while another uses regression models that require imputation and stepwise variable selection. SAS Viya lets you compare them head-to-head using metrics like the K-S statistic, ROC curves, or your own custom assessment criteria.

And if you are a coder? You can bring your existing Python or R models directly into the workflow and score them against SAS-native models in the same project.

Deploy industry accelerators

For common health care use cases, SAS also offers industry accelerators that can be used by customers to train models more efficiently:

• Medication Adherence Risk: Medication adherence has long been a measure of patient health outcomes and a key factor in regulatory quality assessments — including quality ratings for Medicare Advantage, Medicaid, and Exchange plans. SAS Medication Adherence Risk enables managed care organizations to identify where resources are needed for timely and targeted intervention, resulting in enhanced patient engagement, better health outcomes, improved quality metrics, lower health care costs, and a significant ROI.
• Document Analysis for Health Records: Automates the ingestion and analysis of unstructured health records to extract clinically relevant information quickly and accurately. Advanced OCR converts scanned documents and digitized medical records into structured, tabular data with optional annotated PDFs for review. An intuitive workflow standardizes the identification of key medical findings, improving consistency across reviews and reducing manual effort and variability.
• AI-Driven Entity Resolution: Streamlines decision-making and boosts operational efficiency by accurately identifying and consolidating entities across various datasets — including in health care, insurance, and public sector. This model pipeline offers robust data preparation, flexible fuzzy matching, and scoring to eliminate duplicates and inconsistencies, ensuring a single, accurate view of each entity.

3. Bias detection and explainability (SAS Viya)

Health care data carries inherent biases. Historical disparities in access, diagnosis patterns, and social factors are all embedded in the data your models learn from. SAS Viya helps you gain understandable and defensible insights with AI that deliver plain-language explanations of data, models and predictions, built-in bias monitoring and full auditability. The built-in bias detection capabilities let you flag variables for monitoring throughout the modeling lifecycle. This helps your models be accurate as well as equitable across all patient populations. SAS Viya helps you gain understandable and defensible insights with AI that deliver plain-language explanations of data, models and predictions, built-in bias monitoring and full auditability.

4. Model deployment and monitoring (SAS Viya)

Once you've identified your champion model, SAS Viya makes the path to production straightforward. You can publish and register a model at the push of a button, then Viya will help you monitor its performance over time and help you retrain it when you detect drift or bias. This operationalization step, which traditionally takes weeks of custom engineering, is built directly into the platform.

5. From predictive models to agentic AI

Predictive models generate risk scores, but a risk score sitting in a database doesn’t improve a patient’s outcome. The real impact comes from operationalizing those scores into automated, real-time decisions at scale.

SAS Viya provides the platform to make that possible. It enables organizations to combine predictive models, business rules, and large language model (LLM) capabilities into governed analytic and decisioning workflows that can execute at enterprise scale. Instead of handing a care manager a static list of high-risk patients, organizations can build logic that dynamically determines the right intervention, for the right patient, through the right channel, triggered automatically when a risk threshold is crossed.

With SAS Viya’s agentic AI capabilities, organizations can go even further by designing purpose-built AI agents that do more than score and flag. These agents can analyze context, recommend or initiate next steps, and support action across operational workflows by combining the rigor of deterministic analytics with the flexibility of large language models.

For health care, this means moving beyond dashboards and risk lists toward more autonomous, intelligent workflows, where the platform can help identify a high-risk patient, evaluate the appropriate intervention based on clinical rules and predictive scores, and support outreach through the right channel, all with built-in governance, explainability, and human oversight where needed.

SAS Viya’s approach to agentic AI is built on three core principles:

• Decisioning: Combine predictive models, business rules, and LLM reasoning into hybrid workflows that balance precision with adaptability.
• Human/AI balance: Configure the right level of autonomy for each task, from fully automated low-risk decisions to human-reviewed interventions where appropriate.
• Governance: Ensure outputs are explainable, auditable, and compliant, because in health care, trust is not optional.

This is what closes the loop. Data is integrated, prepared, modeled, deployed, and operationalized within SAS Viya allowing organizations to move from insight to action at scale, in real time, with the governance health care demands.

The bottom line

Predictive modeling and AI in health care isn't about replacing the expertise of clinicians and care managers. It's about equipping them with earlier, more precise signals so they can focus their attention where it matters most.

SAS Viya brings together the full analytics lifecycle on a single platform, from data ingestion and standardization, to model building and deployment, to real-time decisioning and agentic AI workflows that act at the point of care. It's a production-grade data and AI platform with the governance, scalability, and interoperability that health care demands.

If you're looking to move from retrospective reporting to prospective, model-driven care management, the platform is here. The data is waiting.

Learn more

• How is AI Transforming Clinical Data Programming?
• R and SAS Working Seamlessly Together: Unlocking PROC R in Viya for Life Sciences
• Enhancing Patient Outcomes: SAS AI Approach to Medication Adherence
• Introducing the SAS Agentic AI Accelerator: Build AI Agents Faster
• SAS Model Cards: Increasing Transparency and Trust in AI

The post How to build predictive health care AI from data to decision appeared first on The SAS Data Science Blog.

In this post, we introduce a conceptual, plug-and-play predictive maintenance framework for wind farm management that builds on a technical paper published in SAS Communities. For utility companies, reducing unplanned downtime remains a key operational challenge, making predictive maintenance a critical capability. By using SAS software, real-time monitoring, machine learning, and SAS Event Stream Processing, the framework shows how sensor measurements can be analyzed in real time to monitor turbine performance, generate explainable maintenance alerts, help reduce downtime, and improve operational efficiency. Although this discussion focuses on wind farms, organizations can extend the same framework to real-time monitoring and predictive maintenance for other industrial assets. To place the wind-farm application in context, we first consider the current landscape and the key challenges faced by wind farm operators.

Current landscape and key challenges in the wind industry

Wind energy has rapidly become the largest source of renewable electricity in the United States. According to the US Department of Energy report, over 10% of the electricity generated by utilities today comes from wind power. Looking ahead, this share will grow significantly, reaching 20% by 2030 and potentially 35% by 2050. The U.S. wind turbine data base reports nearly 76,000 turbines installed across the country. This reflects the scale and momentum of wind energy adoption.

Despite such a promising outlook, wind farm operators continue to face several critical operational challenges that impact both efficiency and reliability:

• Unplanned Downtime: Minimizing unexpected turbine failures remains the most pressing issue in wind farm management. Failure to prevent unplanned downtime can severely affect energy output and increase maintenance costs.
• Navigating Real-Time Data: Wind turbines generate vast volumes of data in real time. Analyzing these data sets and quickly transforming the results into actionable insights remain major challenges.
• Monitoring Performance at Scale: Many utility companies operate hundreds of turbines across vast geographic areas. Identifying underperforming turbines and diagnosing issues quickly are essential to minimizing energy losses and maintaining operational efficiency.
• Advanced Predictive Modeling Needs: Developing accurate predictive models to anticipate failures or inefficiencies requires advanced analytics techniques. These models must not only detect anomalies but also provide actionable insights into specific turbine sub-components that might be at risk.

These challenges highlight the need for a more proactive, data-driven approach to wind farm maintenance. To address them, this post presents a conceptual framework for wind farm analytics and predictive maintenance by using SAS software. The framework shows how advanced analytics, SAS Event Stream Processing, and machine learning could help operators. This includes:

• Identifying potential issues earlier
• Guiding field technicians toward relevant turbines and their components
• Focusing maintenance efforts where they are needed most.

What makes the SAS predictive maintenance framework useful for wind turbines

The SAS predictive maintenance conceptual framework is designed to show how predictive model development by using historical turbine data can be combined with real-time monitoring capabilities to support turbine performance, reliability, and operational efficiency.

• Historical Wind Farm Data Analysis: Historical wind farm data is analyzed through a robust offline training process to develop predictive models for anomaly detection and power prediction. By leveraging advanced analytics and ML, the framework illustrates three things:
  1. How hidden patterns in historical data can be uncovered
  2. How model performance can be assessed
  3. How insights can be generated through visualizations. These insights form the foundation for accurate and reliable real-time monitoring.
• Real-Time Monitoring with Power Curve Insights: Building on the trained models, the framework demonstrates how real-time monitoring can be achieved by continuously streaming data from a wide array of turbine sensors and introducing real-time power curve monitoring. This capability enables operators to continuously track turbine performance and detect deviations from expected output. This helps them identify units that underperform or behave abnormally.
• Accurate Power Prediction and Performance Explanation: The framework illustrates how predictive models can be used to predict wind power generation. It also helps explain performance variations. By highlighting the most influential factors affecting turbine output, it enables operators to understand the underlying drivers behind observed trends. In turn, they can now make informed operational decisions.
• Proactive Maintenance Alerts: The framework describes how maintenance alerts with contextual explanations and email notifications can guide field technicians toward issues that might require attention. This proactive approach could help reduce downtime and extend equipment life.
• Lightweight and Scalable Deployment: Within the proposed framework,
  SAS Viya or SAS Viya Workbench can support model training. An ESP-based workflow can integrate predictive capabilities into wind farm operations through 24/7 anomaly detection, power prediction, and alert generation. In practice, such a workflow could help wind farms minimize unplanned downtime and maintain operational continuity.

Having outlined the framework's key capabilities, we will now provide a high-level overview of how the proposed workflow implements them.

Framework overview

At a high level, the proposed framework operationalizes its predictive maintenance capabilities through two main stages. They are learning from historical data and monitoring turbine performance in real time. Model training and deployment & monitoring are shown in Figure 2.

In the first stage, historical data is used to develop predictive models for anomaly detection, power prediction, and local sensitivity analysis. In the second stage, these models are applied to streaming data to support ongoing monitoring and alert generation. Although model training comes first in the workflow, we discuss real-time monitoring first because it shows how the trained models are ultimately used in practice to generate alerts and support maintenance decisions.

Real-time monitoring

Building on the two-stage workflow described in Figure 2, the real-time monitoring phase illustrates how continuous analysis of turbine performance could be performed by using live data streams. In this stage, the trained models and their configuration files are packaged into a containerized deployment by using Docker. The entire pipeline, including the SAS Event Stream Processing workflow, is embedded within the container. In a real-world implementation, such capabilities would help operators identify issues earlier, respond more quickly, and focus maintenance efforts more effectively.

Figure 3 illustrates an overview of the real-time monitoring architecture. At its core, a real-time data pipeline built with SAS SAS Event Stream Processing continuously ingests streaming data from wind turbines and processes it as it arrives. As the data flows through the pipeline, it undergoes preprocessing, model scoring using ASTORE files, and post-processing to generate actionable outputs. Here, ASTORE refers to a binary analytical store that packages a trained model for use by the real-time monitoring workflow in scoring incoming turbine data.

During the proposed real-time monitoring workflow, the framework illustrates several operational capabilities that could support a real-world implementation:

• Alert Management: Shows how anomalies and performance deviations could be detected in real time and how alerts could be triggered when potential issues are identified.
• Explainability through Local Sensitivity Analysis: Illustrates how insights into the key factors contributing to each alert could help operators understand the underlying causes of performance issues.
• Automated Notifications: Demonstrates how real-time email alerts could be generated for field technicians to support faster response and targeted maintenance actions.
• Real-Time Data Summarization: Shows how incoming data could be continuously aggregated and summarized to support monitoring dashboards and reporting needs.

During real-time monitoring, the framework demonstrates how maintenance alerts can be generated through two primary mechanisms:

• Anomaly Detection: By applying a trained anomaly detection algorithm, the framework identifies turbines exhibiting unusual or abnormal behavior based on deviations from learned patterns.
• Power Prediction: ML models are used to predict expected wind power output and detect turbines generating below expected levels. Comparing actual and predicted values further supports a model performance monitoring concept that illustrates how the accuracy of a deployed power prediction model can be tracked over time and how performance degradation can be detected. When a decline is identified, an alert can be generated to recommend retraining the model, ensuring predictive capabilities remain accurate and reliable.

To support timely response and effective field operations, the framework demonstrates how the resulting alerts can be delivered through automated email notifications. These notifications are generated based on model outputs and predefined alert rules. They are sent directly to field technicians and operators. Each notification provides a consolidated view of the alert types triggered for a specific turbine on a given day. Also included are the corresponding values that exceed predefined threshold limits, enabling quick and informed decision-making.

Alert types in real-time monitoring

By applying anomaly detection and power prediction models to real-time data, the framework demonstrates how automated alerts and notifications can be generated. Figure 3 includes an example email notification on the lower right-hand side. The notification captures anomalous behavior, low power generation, and model performance alerts together. This example summarizes the three alert types supported within the framework:

• Alert Type 1 – Unusual Turbine Behavior: This alert is generated when a turbine behaves differently from what is expected while it is operating. This alert is based on an anomaly score that measures how unusual the turbine’s current behavior is, relative to its expected operating pattern (a higher score indicates deviation from normal behavior). In Figure 3, Turbine 2 is flagged on day 8 because its anomaly score exceeded a threshold derived under the assumption that only 1% of observations are anomalous. The anomaly score remained above this threshold for three continuous hours, spanning 18 consecutive 10-minute intervals. The unusual pattern begins about 10 hours and 40 minutes into the notification period, which suggests that the event is more than a brief, one-time spike. This tells operators that Turbine 2 might need attention because its behavior remained unusual for an extended period.
• Alert Type 2 – Low Power Generation: This type of alert is used when a turbine is producing less power than expected while it is running. In this context, low power generation means that the turbine’s actual power output is below the level expected for its operating conditions. In Figure 3, low-power generation is also detected for Turbine 2 on day 8. This is due to its output dropping below the expected level and staying low for three continuous hours, spanning 18 consecutive 10-minute intervals. The lower output begins about 3 hours and 20 minutes into the notification period. This indicates a sustained reduction rather than a short-lived dip. This suggests that Turbine 2 might require investigation because it is not generating as much power as expected.
• Alert Type 3 – Low Prediction Performance: This alert is generated when the predicted power output and the actual power output no longer match closely enough over time. In this context, prediction performance describes how well the model’s expected power output matches what the turbine produces. Lower performance means the model’s predictions are becoming less reliable. In the example, the prediction error rises above the expected limit and remains high for 23 continuous hours, spanning 138 consecutive 10-minute intervals. This points to a persistent mismatch rather than a brief one-time difference. The notification also notes when the power prediction model was last trained. Together, these details suggest that the model might no longer reflect current turbine behavior well and might need to be reviewed or retrained.

Explainability for field teams

When an alert is triggered, local sensitivity analysis can identify the key factors that contribute to the detected issue. These insights are further summarized into component-level tag groups. They include Environment, Blade, Hub, Rotor, Nacelle, Main Bearing, Gearbox, Generator, Transformer, Hydraulic Unit, and Tower. By aggregating model explanations into these component categories, the framework shows how operators could obtain a clearer view of the relative impact of each turbine subsystem.

Figure 4 illustrates an example of a low-power generation alert. This is where the component-level impacts are derived from a PROC GRADBOOST model that estimates expected turbine power and uses TreeSHAP values to quantify the contribution of each input variable to an individual prediction. In this example, the gearbox is identified as the component contributing most significantly to the alert with a total percentage impact (totalPercentImpact) of 89.112367. This indicates that approximately 89% of the explained contribution to the low-power generation alert is associated with gearbox-related sensor tags.

In practical terms, this does not prove that the gearbox is the root cause of the issue. Rather, it indicates that gearbox-related measurements account for the largest share of the model’s explanation for why Turbine 7 is producing less power than expected. This helps field technicians prioritize gearbox-related measurements or operating conditions when beginning their investigation. Such insights could help field technicians focus their investigation on the most relevant components, thereby improving maintenance efficiency.

The effectiveness of the monitoring workflow, including its anomaly detection and power prediction capabilities, depends on the ML models developed during the training phase,

Model training

In this phase of the predictive maintenance framework, historical wind farm data is analyzed to develop ML models and derive actionable insights. First, we access SAS Viya (cloud or on-premises) or SAS Viya Workbench (cloud). Once access is established, the system makes the SAS wind farm predictive maintenance macro catalog available within the environment. This catalog contains the pre-defined components required for the ML workflow, including data preprocessing, model training, and post-processing steps. Following this, the data sets are uploaded and preprocessed according to the required data template. These data sets typically capture a wide range of information. This would include turbine power generation, environmental conditions such as wind speed and ambient temperature, and sensor readings related to key turbine components like pressure and temperature.

In addition to operational data, the framework incorporates supporting inputs such as alert management rules and turbine specifications. These might include parameters such as blade length, rated power, rated wind speed, air density, and the operating wind speed range of each turbine. Together, these inputs provide important contextual information that enhances the quality and relevance of the analysis. Figure 5 provides an overview of the architecture of the model training components.

At the end of the training phase, the framework produces a range of outputs that support both historical data analysis and real-time monitoring. These outputs fall into three broad categories.

Analysis Results

Several structured output files summarize different aspects of turbine performance and model behavior. They include:

• anomaly scoring summaries
• power prediction and anomaly detection results
• model fit metrics
• important input variables
• turbine-level efficiency measures
• power curve summaries
• uncertainty estimates
• risk profiles of turbine operation across wind speed regions.

The framework further captures filtered turbine data, relationships among variables, principal component analysis (PCA) results, and aggregate turbine statistics. Together, these outputs provide a detailed view of how turbines are operating, how well the predictive models are performing, and which variables or operating conditions might be contributing to unusual behavior or lower-than-expected power generation.

Visualizations

Charts and graphical outputs generated during the model training phase help interpret ML model behavior and turbine performance through plots such as turbine clustering, efficiency trends, and other analytical charts that explain how different variables contribute to performance. Figure 6 presents the power curve with uncertainty quantification. It provides the Box-and-Whisker plots summarizing power distribution for eight selected turbines in a wind farm. It also shows how the PCA loading plots could be useful for identifying clusters among the many turbines in large wind farms.

The PCA-based output shown in Figure 6 was generated by using PROC MVP, a SAS procedure for multivariate process monitoring. PROC MVP uses PCA, an unsupervised machine learning technique, to summarize correlated process variables into a smaller set of principal components. The resulting loading plot helps reveal how turbines relate to the dominant patterns in the data. Turbines that appear close together exhibit similar multivariate behavior. Those that are farther apart might represent distinct operating patterns or groups that warrant further investigation.

Figure 7, on the other hand, shows scatter plots of true wind speed versus turbine power. The data points are classified as normal (blue) or anomalous (yellow) with color intensity indicating anomaly severity. For this anomaly visualization, we used PROC FOREST with the isolation forest option. This constructs a random forest for unsupervised anomaly detection rather than target prediction. The procedure generates anomaly scores, with larger values indicating observations that are more unusual relative to the observed data patterns. Figure 7 also provides a corresponding time-series plot. This further illustrates how anomaly scores vary over time and how they can help identify periods of abnormal turbine behavior.

Deployment-Oriented Assets

An ESP-based monitoring workflow can use packaged ASTORE files for trained turbine power prediction, anomaly score generation, and anomaly detection models. The package also contains configuration files that define asset and analytics parameters. During deployment and execution, the SAS Event Stream Processing runtime uses these files to run the application.

Software requirements

Implementing the SAS predictive maintenance framework for wind turbines requires several key components:

• SAS Viya or SAS Viya Workbench: These platforms provide the analytical environment for working with historical wind farm data and developing ML models that form the foundation for predictive insights and real-time monitoring.
• SAS Predictive Maintenance Compiled Macro Catalog: This includes a collection of pre-built macros that streamline the analytics workflow. It covers data preprocessing, model training, and post-processing steps. It helps standardize and accelerate the development process within the framework.
• SAS Predictive Maintenance Event Stream Processing Container: This component supports real-time data ingestion, model scoring, and alert generation within the monitoring workflow. It would enable continuous monitoring of streaming turbine data, anomaly detection and power prediction by using trained models, and generation of alerts with explainable insights.

Summary

The SAS predictive maintenance conceptual framework presents a practical approach for connecting historical wind farm analysis with real-time monitoring. By combining ML, SAS SAS Event Stream Processing, and explainable alerting, the framework illustrates how operators could:

• detect anomalies earlier
• better understand asset performance
• respond faster and more precisely to operational issues.

Although this example focuses on wind turbines, organizations can adopt the same approach to support predictive maintenance and real-time monitoring for other industrial assets.

The post Predictive maintenance for wind farm management with SAS: From real-time sensor data to maintenance alerts appeared first on The SAS Data Science Blog.

The DementAI team from Katalyze Data, a UK-based consultancy and long-time SAS Partner, was named the 2025 SAS Hackathon Grand Champion at SAS Innovate. Every year, the SAS Hackathon turns a month of collaboration into solutions for real problems.

Their system is designed to help flag Alzheimer's disease up to two years sooner than existing approaches not by replacing clinicians, but by surfacing the subtle patterns of decline already sitting in patients' clinical records - and long before a referral to a specialist.

We didn't build DementAI just to make predictions. We built it to buy patients’ time. Tamás Bosznay, Principal Consultant, Katalyze Data

That's the goal. What made it achievable in a month? The platform underneath it.

One platform, from raw data to real-world decision

What makes DementAI remarkable isn't a single, clever model. Rather, it's that the team took on the entire problem, end to end, without ever leaving SAS Viya.

All in one platform, the team:

• Built models on EEG data using RNNs and LSTMs in Python.
• Modeled tabular health records and applied natural language processing to unstructured clinical notes in Model Studio.
• Blended structured records, brain scans and physician notes, using synthetic data where appropriate to protect privacy.
• Registered everything in Model Manager as a central repository for comparison and monitoring and deployed it for inference - all in one governed environment.

No more stitching together half a dozen disconnected tools, and no data leaving the platform. By building on SAS Viya, the team was able to fully unify data, analytics and governance in a single place.

Governance isn't the price of speed. It's the source of it.

In a regulated industry, an AI model is only as valuable as it is trustworthy. The old assumption was that trust slows you down, but DementAI proves the opposite.

What stood out wasn't only the accuracy of the models, but how the team built them: using governed workflows and privacy-preserving techniques. In regulated environments, that foundation is exactly what makes the leap from prototype to real-world pilot possible.

Explainability, audit trails, bias reporting, ongoing monitoring, full data lineage: on SAS Viya, these aren't features you bolt on at the end. They're built in.

Bring your own language

The team moved fast for another reason: nobody had to abandon the tools they knew. SAS Viya lets users work in Python, R and SAS within the same governed environment.

A data scientist who lives in Python and a statistician who has spent a career in SAS can build toward the same trusted, deployable result.

Agentic AI is already in the workflow

The team wired their models into an agentic AI workflow in SAS Intelligent Decisioning, combining their own machine learning with large language models to transcribe audio, summarize patient history and generate reports. And it’s all kept on the rails by deterministic rules and a human in the loop.

That's not a future vision. It’s a working prototype, built in a month, on a platform designed to carry an idea from messy raw data all the way to governed decision support.

The stakes are too high for anything less

By 2050, the number of people living with Alzheimer’s is expected to reach 139 million. Behind each of those figures is a person, and the people who love them, watching for the small signs that something has changed.

DementAI is a remarkable achievement. But the real story is the opportunity it represents for any team, in any regulated industry, sitting on data that could help them see earlier. The platform to do it already exists.

The only variable is how quickly you choose to move.

Behind the scenes, these agentic workflows can be connected to trusted SAS analytics, models and decision services through SAS Viya MCP Server. This enables AI agents to move beyond conversation and securely execute governed business actions using the analytical capabilities already available in SAS Viya.

Learn more

• Agentic AI for Life Sciences with SAS Viya MCP Server and Claude Cowork
• SAS Agentic AI Accelerator | SAS Viya April and May 2026 Release
• Introducing the SAS Agentic AI Accelerator: Build AI Agents Seamlessly in SAS Viya
• How Agentic AI Accelerates SME Credit Decisions with SAS Viya
• Agentic AI for Workforce Analytics: Reducing attrition with personalized, LLM-powered guidance
• Modernizing user attendance center ticket handling with trusted agentic AI

The post Detecting Alzheimer's earlier with AI appeared first on The SAS Data Science Blog.

In a recent post, we demonstrated how Simulated Annealing (SA) can be used to solve the Traveling Salesman Problem (TSP) by using SAS Optimization. In this post, we extend that discussion by exploring how the Ant Colony Optimization (ACO) metaheuristic can be applied to the same problem by using SAS Optimization. We will showcase its ability to deliver competitive solutions for challenging combinatorial problems.

Solving large-scale, real-world optimization problems using traditional optimization algorithms is often challenging due to complex business constraints and dynamic environments. Metaheuristic algorithms often complement classical optimization techniques to overcome these limitations. Metaheuristics offer a flexible approach to exploring vast solution spaces, identifying promising regions, and generating high-quality initial solutions within practical computational limits. Traditional methods can further fine-tune these solutions to improve accuracy and performance.

Ant Colony Optimization (ACO)

One widely used metaheuristic is Ant Colony Optimization (ACO). This is a bio-inspired, population-based heuristic framework motivated by the foraging behavior of real ant colonies. In nature, ants collectively discover short paths between their nest and food sources by depositing pheromones along traveled routes. Over time, frequently used paths accumulate stronger pheromone trails. This reinforces good solutions through positive feedback. In the optimization context, artificial ants iteratively construct solutions by probabilistically selecting a solution based on:

1. Pheromone intensity, representing learned experience
2. Heuristic information, representing problem-specific knowledge (for TSP, inverse distance)

ACO has proven effective in tackling various combinatorial optimization problems, including routing, scheduling, and network design. ACO operates by simulating a colony of artificial ants that iteratively construct solutions. The algorithm balances exploration and exploitation: ants probabilistically choose paths influenced by pheromone intensity and problem-specific heuristics information. This balance enables ACO to efficiently navigate large combinatorial search spaces and avoid premature convergence to poor local optima. Over time, pheromone updates reinforce high-quality solutions, guiding the search toward near-optimal regions.

A key strength of ACO lies in its adaptability and robustness in handling large, complex search spaces. By leveraging collective learning and positive feedback, ACO can efficiently escape local optima and converge toward high-quality solutions.

Pseudocode of the algorithm

The pseudocode in this section summarizes the main logic of the ACO algorithm before translating it into PROC OPTMODEL code. Each iteration enables multiple artificial ants to construct feasible tours by using pheromone and heuristic information, identifies the best tour, updates pheromone levels to reinforce promising edges, and checks the stopping criteria. This outline provides context for the variables and equations used in the implementation.

• $\alpha$: Influence of pheromone trails
• $\beta$: Influence of heuristic information (inverse distance)
• $\rho$: Pheromone evaporation rate
• (i, j): the directed edge (arc) from node i to node j.
• distance (i, j): travel distance of edge (i,,j)
• $\tau_{ij}$: Pheromone level or pheromone trails on edge (i, j)
• $\eta_{ij}$: Heuristic desirability or heuristic information of edge (i, j), often set as 1 / distance (i, j))
• iter: Iteration number
• k: ant identifier
• best_ant: best ant in an iteration
• obj_step(iter,k): objective of that ACO iteration iter for ant k
• arc_selection_probability (i, j) = $(\tau_{ij})^\alpha \times (\eta_{ij})^\beta$, is the attraction score for edge (i, j)
• $\Delta\tau_{ij}$: pheromone contribution by best_ant in each iteration on edge (i, j)
• $\tau_\min$, $\tau_\max$: lower/upper bounds on pheromone levels
• Q: a constant (pheromone quantity)
• best_obj: best upper bound
• best_iter: iteration identifier corresponding to the best upper bound
• aco_cons_obj_count: number of iterations with the same best upper bound
• max_cons_obj: maximum allowable consecutive solutions
• ANTS: Number of ants per iteration
• ITERATIONS: Maximum number of iterations

Initialization step

• $\tau_{ij}$: constant for all edges (1)
• Set best_obj to a large value
• Initialize random number generator

Iterations:

Input data

To illustrate the ACO algorithm and its usefulness, we consider an example from the Traveling Salesman Tour of US Capital Cities. This problem seeks the shortest route that visits the capital city of every U.S. state (and the District of Columbia), excluding Alaska and Hawaii.

PROC OPTMODEL code

The model is coded and solved by using the OPTMODEL procedure in SAS Optimization. We start by defining the index sets and parameters for the TSP problem, then use a READ DATA statement to read data into them.

   proc optmodel;
 
      /* Declare parameters and read data */
      set <str,str> NODEPAIRS;
      set <str> NODES = union {<i,j> in NODEPAIRS} {i,j};
      set <str> NODES_TMP;
      num distance{NODEPAIRS};
      num node_id{NODES};
      num id init 1;
      read data CitiesDist (where=(upcase(city1) ne upcase(city2)))
         into NODEPAIRS=[city1 city2] distance;
      set <num> NUM_NODES = 1..CARD(NODES);
      for {n in NODES} do;
         node_id[n] = id;
         id = id + 1;
      end;

The next line calls a macro named aco_tsp_dec, which defines index sets and variables needed for the ACO algorithm:

     %aco_tsp_dec();

Followed by:

     %macro aco_tsp_dec(
     );
 
          /* Ant Colony optimization - index sets and variables */
          num alpha = 2.0;
          num beta = 7.5;
          num rho = 0.3;
          num max_ants = 20;
          num max_steps = 1000;
          set <num> ITERATIONS = 1..max_steps;
          set <num> ANTS = 1..max_ants;
          num init_pheromone_trail = 1;
          num pheromone_trail{NODEPAIRS} init init_pheromone_trail; /* Initialize the pheromone trail */
          num heuristic_info{<i,j> in NODEPAIRS} = 1/distance[i,j];
          num Q = 1000;
          num best_ant init 0;
          num best_iter init 0;
          num best_obj init 100000;
          num probabilities{NODEPAIRS};
          num temp_cum_prob;
          num min_pher = 0.001;
          num max_pher = 20;
          num aco_starttime;
          num aco_endtime;
          num aco_runtime init 0;
          num obj_step{ITERATIONS, ANTS};
          str aco_tsp_tour{ITERATIONS, NUM_NODES, ANTS};
          num best_obj_step{ITERATIONS};
          num node_total_probability;
          set <str,str> TSPEDGES init {};
          num next_i{i in NUM_NODES} = if i < card(NUM_NODES) then i+1 else 1;
          num rand_num;
          num delta_pheromone;
          str next_node;
          num aco_cons_obj_count init 0;
          num prev_best_obj;
          num dec_roundoff = 0.1;
          num max_cons_obj = 20;
          call streaminit(100);
 
     %mend aco_tsp_dec;

The following statements implement the main ACO loop, iterating over ACO iterations and, within each iteration, over all ants. The aco_ant_behavior macro is the core of the algorithm: each ant builds a complete tour by repeatedly selecting the next edge probabilistically using the attraction score arc_selection_probability(i,j) (as defined in the pseudocode). Each ant starts at node_id=1 and constructs a tour until all cities are visited. This behavior mimics how real ants lay down and follow pheromone trails. The objective value of each ant’s constructed tour is evaluated by using the aco_compute_obj macro. Finally, the tour objective value is compared with the incumbent best solution. The best objective (best_obj), best iteration (best_iter), and best ant (best_ant) variables are updated whenever an improved solution is found.

     aco_starttime = time();
 
     /* ACO iterations */
     for{iter in ITERATIONS} do;
        prev_best_obj = best_obj;
        for {k in ANTS} do;
           /* Construct paths for ants */
           %aco_ant_behavior();
 
           /* Evaluating objective function value */
           %aco_compute_obj();
 
           /* Updating best objective and best iteration variables
              - across all K ants */
           if (obj_step[iter,k] < best_obj) then do;
              best_obj = obj_step[iter,k];
              best_iter = iter;
              best_ant = k;
           end;
        end;
     end;

     %macro aco_ant_behavior();
 
     /* Compute raw attraction scores once per ant tour */
     for {<i,j> in NODEPAIRS}
        probabilities[i,j] = (pheromone_trail[i,j]**alpha) * (heuristic_info[i,j]**beta);
 
     NODES_TMP = NODES;
     for {n in NODES: node_id[n] = 1} do;
        aco_tsp_tour[iter, 1, k] = n;
        NODES_TMP = NODES_TMP diff {n};
     end;
 
     id = 1;
     do while (CARD(NODES_TMP) >= 1);
 
          /* Compute total probability */
          node_total_probability = sum{n1 in NODES_TMP}
             probabilities[aco_tsp_tour[iter, id, k], n1];
 
          /* Scale rand_num - Avoiding normalizing the probabilities array */
          rand_num = rand('UNIFORM') * node_total_probability;
          temp_cum_prob = 0;
          next_node = '';
 
          /* Running sum to pick next node */
          for {n1 in NODES_TMP} do;
             temp_cum_prob = temp_cum_prob
                + probabilities[aco_tsp_tour[iter, id, k], n1];
             if rand_num <= temp_cum_prob then do;
                next_node = n1;
                leave;
             end;
          end;
 
          id = id + 1;
          aco_tsp_tour[iter, id, k] = next_node;
          NODES_TMP = NODES_TMP diff {next_node};
     end;
 
     %mend aco_ant_behavior;

     %macro aco_compute_obj(
     );
 
     obj_step[iter,k] = sum{i in NUM_NODES} distance[aco_tsp_tour[iter, i,k],aco_tsp_tour[iter,next_i[i],k]];
 
     %mend aco_compute_obj;

The following statements update the pheromone levels on all edges by first applying evaporation and then depositing pheromone in proportion to the contribution of the best_ant (in each iteration) on the visited edges.

          /* Updating pheromone values - across all K ants */
          %aco_ant_pheromone();

     %macro aco_ant_pheromone (
     );
          /* Evaporation of current pheromone trail values on the edges */
          for {<i,j> in NODEPAIRS} pheromone_trail[i,j] = ((1-rho)*pheromone_trail[i,j]);
 
          TSPEDGES = union{i in NUM_NODES} {<aco_tsp_tour[iter,i,best_ant],aco_tsp_tour[iter,next_i[i],best_ant]>};
 
          for {<i,j> in NODEPAIRS} do;
             if <i,j> in TSPEDGES then delta_pheromone = Q/obj_step[iter,best_ant];
             else delta_pheromone = 0;
             pheromone_trail[i,j] = pheromone_trail[i,j] + delta_pheromone;
             pheromone_trail[i,j] = min(max_pher,max(min_pher,pheromone_trail[i,j]));
          end;
 
     %mend aco_ant_pheromone;

During the pheromone update, edges in higher-quality tours receive larger pheromone deposits. Consider an edge (i,j) with current pheromone level $\tau_{ij} = 0.40$, evaporation rate $\rho = 0.10$, and bounds $\tau_\min = 0.10$, and $\tau_\max = 1.00$, with $Q = 1$. Suppose two ants produce objective values of 250 and 200. Because the objective function is minimized, the ant with a value of 200 becomes the best_ant. The pheromone deposit is $\Delta\tau_{ij} = 1/200 = 0.005$. Compared to the other ant with the objective value of 250 (which would deposit 1/250 = 0.004), the best_ant deposits a larger amount of pheromone. As a result, edges belonging to the better tour (objective 200) receive stronger reinforcement and become more attractive in future iterations.

The algorithm then computes the number of consecutive iterations during which the incumbent best solution remains unchanged, compares this count with the maximum allowable threshold, and either resets the pheromone levels on all edges to their initial values or updates the counter tracking consecutive best solutions.

     /* Computing number of consecutive same best solution */
     if abs(best_obj - prev_best_obj) <= dec_roundoff then do;
        aco_cons_obj_count = aco_cons_obj_count + 1;
     end;
     else aco_cons_obj_count = 0;
     if aco_cons_obj_count > max_cons_obj then do;
        for {<i,j> in NODEPAIRS} pheromone_trail[i,j] = init_pheromone_trail;
     end;
 
     /* Reporting variables */
     best_obj_step[iter] = best_obj;
     put iter= best_obj= best_iter= best_ant= aco_cons_obj_count=;
 
     end;

The following statement extracts and outputs the best solution generated by the ACO algorithm:

     /* Run time of the ACO algorithm */
     aco_endtime = time();
     aco_runtime = intck('second',aco_starttime,aco_endtime );
     put aco_runtime=;
 
     /* Creating output table */
     TSPEDGES = union{i in NUM_NODES} {<aco_tsp_tour[best_iter, i,best_ant],aco_tsp_tour[best_iter,next_i[i],best_ant]>};
     create data TSPTourLinks from [city1 city2]=TSPEDGES distance;
     create data TSPACOIterations from [Iteration_no]=ITERATIONS best_obj_step;
 
quit;

We execute the ACO algorithm coded within PROC OPTMODEL using the input data. The optimal objective value of the problem is 10,635.09. The algorithm began with a solution with an objective function value of 12,657.15 and terminated with one of 10,977.56 (a gap of 3.22% from the optimal objective value). The algorithm took 143 seconds to run 1000 iterations with 20 ants per iteration. Snapshots of the iterations with starting solutions (first 20 iterations) and the final solution (last 20 iterations), from the TSPACOIterations table, are shown in Tables 1 and 2.

Table 1: Solutions of the ACO algorithm from the first 20 iterations

Table 2: Solutions of the ACO algorithm from the last 20 iterations

The performance and quality of solutions produced by the ACO algorithm are strongly influenced by the choice of runtime parameters, such as the influence of pheromone trails, the influence of heuristic information, the pheromone evaporation rate, the number of iterations, the number of ants per iteration, and the pheromone update rule. Extensive and careful tuning of these parameters enhances the robustness of the search process, leading to improved solution quality, greater diversity, and more effective exploration of complex optimization landscapes. Equally important is the solution construction mechanism in ACO: designing procedures that construct feasible solutions is a requirement for the algorithm, and a fundamental requirement for metaheuristic approaches in general.

Plots of solutions

The statements for producing a graphical display of the solution can be referred to in the example of the Traveling Salesman Tour of US Capital Cities. The early-stage ACO solution (iteration 1) produces scattered, inefficient routes with many unnecessary crossings and detours, as shown in Figure 1. Figure 2 shows the converged ACO solution (iteration 500), where the algorithm generates better-structured, geographically coherent routes that demonstrate improved optimization.

Figures 3 and 4 show the optimal solution and the best-cost tour of the capital cities obtained by the ACO algorithm. The best-cost ACO solution (Figure 4) represents a well-organized, near-optimal tour that efficiently connects all cities with minimal crossings and a reduced total travel distance.

In the northwest region (shown in Figures 5 and 6), the ACO solution matches the optimal route, capturing the same optimal tour in this part of the network.

We also observe differences in routes between the optimal solution and the best solution from the ACO algorithm, reflecting the heuristic nature of the search. Figures 7 and 8 present the optimal tour and the best ACO solution for the Northeast region. The ACO solution shows small local crossings and route overlaps in dense regions, reflecting inefficiencies in the search process. This highlights the importance of careful parameter tuning to enhance convergence and solution quality in ACO.

The following statements generate plots of the iterations and the progress of the best objective value.

     /* Progress of best objective */
     title 'Iterations vs best objective value';
     %let optimal = 10635;
     proc sgplot data=TSPACOIterations noautolegend;
        step x=Iteration_no y=best_obj_step / markers;
        refline &optimal.;
        xaxis label='Iteration';
        yaxis label='Objective Value' min=10500;
     run;

Figure 9 shows the plot of the best objective value found as a function of the number of iterations. The overall downward trend reflects the algorithm’s effectiveness in navigating the solution landscape towards near-optimality. Figure 9 also highlights the exploration–exploitation trade-off: rapid early gains from exploration, followed by slower convergence as the algorithm intensifies the search near high-quality solutions.

Conclusion

This post demonstrates how to implement an ACO metaheuristic algorithm in PROC OPTMODEL. It applies it to a TSP instance from the SAS documentation. The results illustrate the characteristic ACO search dynamics: solution construction guided by pheromone and heuristic information, progressive reinforcement of high-quality edges through pheromone updates, and gradual improvement in the best objective value over the course of the iterations.
Metaheuristics such as ACO are often most effective when used alongside exact or specialized algorithms. The ACO algorithm provides only an approximate solution to the problem, not a globally optimal one. However, it could be useful for obtaining a good, feasible solution to a wide variety of complex, real-world problems, serving as a warm start within a unified optimization workflow. Other applications of ACO include vehicle routing problems and extensions, multicommodity network design, and scheduling problems.

To explore further, SAS Optimization has specialized solvers for various graph theory, combinatorial optimization, and network analysis algorithms, including TSP.

The post Ant Colony Optimization metaheuristic in SAS Optimization appeared first on The SAS Data Science Blog.

Banks know a lot about their customers. They know how often someone logs in, what products they use, how they tend to spend or save, and even what they might need next. That level of insight has never been the problem. The problem is what happens next.

A customer might receive an email encouraging them to open a savings account. At the same time, they might see a message in their banking app about a credit product. If they call support, the conversation might go in a different direction. Each interaction makes sense on its own. But together, they feel disconnected.

From the customer’s point of view, the bank is not acting like one organization. It feels like a collection of systems making independent decisions. That is the challenge this article focuses on.

From Hackathon idea to real-world use case: Decision-led banking

This use case was originally developed by the Banco de Bogotá team as part of the 2025 SAS Hackathon. Their goal was to explore how banks can move from fragmented customer engagement to a more coordinated, decision-led approach—where decisions are made once and carried through consistently across channels.

The approach itself is straightforward. The bank started with basic information, such as demographics and preferences, to build an initial understanding. It then learned from customer behavior over time through transactions and interactions. As that picture became clearer, it continuously refined how customers were grouped and used that understanding to guide what the bank should say or do next.

This type of approach is often referred to as customer 360 or customer segmentation. It works well for understanding customers. But it still leaves a key question unanswered: How does the bank turn that understanding into one clear, consistent action?

Why consistency is so hard

In most banks, decisions are not made in one place. Marketing, digital, service, and product teams often manage their own channels, tools, and priorities. Even when they are working from the same customer data, they are not always acting on it in the same way. This is why customers receive mixed messages.

It is not a data problem. It is a coordination problem. And most banks are not structured to solve that problem centrally.

A different approach: decide once, act everywhere

Instead of letting every system decide what to do independently, a better approach is to make one decision and use it everywhere. That decision answers a simple question: What is the single most relevant action for this customer right now, and how do we make sure every channel delivers that same message?

This is where SAS Intelligent Decisioning comes into play. It allows banks to bring together data, models, and business rules in one place so decisions can be made consistently.

But there is still another challenge. Even when the bank knows the right action, it must explain why that action was chosen, communicate it clearly to the customer, and make sure the tone fits the situation.

This is where agentic AI becomes useful. It allows banks to support decision-making with AI in a controlled way, improving how decisions are communicated and understood without changing how they are made.

What an AI agent actually does in this context

An AI agent in banking is not a chatbot, and it is not replacing decisions. It acts more like a coordinator within the decisioning process, helping translate decisions into clear, consistent customer interactions.

It helps with two important things:

1. Turning decisions into clear communication
2. Turning technical reasoning into understandable explanations

For example, a model might indicate that a customer is likely to benefit from a savings product, while business rules confirm they are eligible and that the timing makes sense. The decisioning system selects that action, and the AI agent helps translate it into a message the customer can understand.

At that point, the AI agent helps draft a message that is clear and appropriate, translates technical reasoning into simple language, and ensures the communication aligns with the bank’s tone and policies.

The decision remains controlled and governed. The AI helps make that decision easier to understand and easier to deliver.

Where the SAS Agentic AI Accelerator fits in

Up to this point, the focus has been on making better decisions and keeping those decisions consistent. The next step is making those decisions easier to communicate and easier to understand. This is where the SAS Agentic AI Accelerator fits in.

The accelerator provides a structured way to introduce AI into existing decision workflows without disrupting how decisions are made. Instead of treating AI as a separate experiment, it becomes part of the system in a controlled and repeatable way.

In this example, the accelerator would be used to build an AI agent that sits alongside the decisioning process and helps with two key tasks.

First, it helps turn decisions into clear communication. Once a decision is made, the agent can generate customer-facing messages that are consistent in tone, aligned with policy, and tailored to the situation.

Second, it helps turn technical logic into understandable explanations. It can take model outputs and decision rules and translate them into simple language that can be used by customer support teams or even shared directly with customers when appropriate.

The important part is that the AI is not making the decision—it is supporting how that decision is delivered. By using the Agentic AI Accelerator, teams can build this capability once and reuse it across channels, instead of relying on separate teams or systems to interpret decisions in different ways.

Bringing it all together

The Banco de Bogotá use case shows how banks can better understand their customers over time. The next step is making sure that understanding leads to clear, consistent action.

By combining customer insight and segmentation, centralized decisioning, and agentic AI for communication and explanation, banks can move toward a model where customers receive fewer but more relevant messages, interactions feel more intentional, and decisions are easier to apply consistently and explain clearly.

This is not about adding more technology. It is about making existing capabilities work together more effectively.

Customers do not see systems, models, or channels. They experience conversations.
When those conversations are consistent, trust grows. When they are inconsistent, even strong insights lose their value. Agentic AI, used in the right way, helps bridge that gap—not by making decisions on its own, but by helping organizations act on their decisions more clearly and consistently.

This is where the Agentic AI Accelerator becomes practical. It provides the structure to build these agent-based capabilities in a way that is consistent, reusable, and aligned with how decisions are already managed in SAS Viya.

Explore the Agentic AI Accelerator

If this approach resonates, a good next step is to explore the SAS Agentic AI Accelerator on GitHub. The repository provides a practical starting point for building agent-based workflows in SAS Viya, including examples, reusable components, and guidance on how to bring together decisioning, AI, and orchestration in a structured way.

It is designed to help teams move beyond ideas and experiments and begin building real, governed solutions that can scale. Whether you are just starting to explore agentic AI or looking to expand existing decisioning workflows, it offers a clear path to begin testing, learning, and applying these concepts in your own environment.

From Hackathon idea to real-world use case

If you are interested in how this idea was developed, you can explore the team and their work on the SAS Hackathon platform: Banco de Bogotá – SAS Hackers Hub.

The SAS Hackathon provides a space for teams like this to take real business challenges, combine data, analytics, and AI, and build practical solutions in a short period of time. Many of the concepts explored in this article, including centralized decisioning and agentic AI, are being actively tested and refined through these hackathon projects.

This is a strong example of how innovation does not always start with large transformation programs. Sometimes it starts with a focused use case, a small team, and the right tools to connect insight to action.

Behind the scenes, these agentic workflows can be connected to trusted SAS analytics, models and decision services through SAS Viya MCP Server. This enables AI agents to move beyond conversation and securely execute governed business actions using the analytical capabilities already available in SAS Viya.

Learn more

• Agentic AI for Banking with SAS Viya MCP Server and Claude Cowork
• SAS Agentic AI Accelerator | SAS Viya April and May 2026 Release
• Introducing the SAS Agentic AI Accelerator: Build AI Agents Seamlessly in SAS Viya
• How Agentic AI Accelerates SME Credit Decisions with SAS Viya
• Agentic AI for Workforce Analytics: Reducing attrition with personalized, LLM-powered guidance
• Modernizing user attendance center ticket handling with trusted agentic AI

The post Agentic AI in banking: Turning customer insights into action appeared first on The SAS Data Science Blog.

A new model for submissions

For years, submission delivery has depended on a patchwork of code, spreadsheets, manual checks, and document assembly. That approach can work for a single study, but it becomes fragile when scaled across programs, therapeutic areas, vendors, and global regulatory timelines. SAS Clinical Acceleration on Viya addresses that problem by centralizing data, automating lineage tracking, and supporting collaborative analysis in a validated platform.

What makes this approach different is that it is not just a compute environment. It combines a secure clinical data repository with a statistical computing layer, built for regulated work and aligned to submission needs. The result is a more repeatable process for moving from raw clinical data to SDTM, ADaM, review-ready outputs, and regulatory packages.

Automated derivations at scale

One of the biggest gains comes from reducing repetitive derivation work. In a traditional setup, SAS programmers often rebuild similar SDTM and ADaM logic study after study, with variation introduced by local conventions, vendor differences, or late changes to specifications. SAS Clinical Acceleration supports reusable, standardized workflows so derivations can be applied consistently across studies and batches.

That matters for programming directors and study teams because it shifts effort from manual construction to controlled reuse. Instead of maintaining multiple isolated code streams, teams can run chained programs in batch, preserve traceability, and keep execution in one qualified environment. SAS Viya supports SAS, R, and Python in a governed setting, which helps open-source programmers contribute where appropriate without fragmenting compliance controls.

Validation built into workflow

Validation is often treated as a separate checkpoint, but in a scaled submission model it needs to be part of the workflow itself. SAS Clinical Acceleration includes validation capabilities, audit trails, electronic signatures, versioning, and role-based privileges to support compliance with 21 CFR Part 11 and CDISC-related standards.

That embedded control structure helps teams avoid late-stage surprises. Conformance checks, traceability reviews, and reproducibility controls can be applied as part of routine execution rather than as a manual end-of-line exercise. For compliance leaders, that means stronger inspection readiness; for programmers, it means fewer downstream reruns caused by missing checks or undocumented changes.

Submission-ready output generation

A major bottleneck in clinical development is not only analysis, but assembly. Final submissions require datasets, metadata, define.xml, documentation, and reviewer support materials to line up cleanly and consistently. SAS Clinical Acceleration is positioned to support that end-to-end flow by integrating analysis, validation, and submission preparation in the same environment.

That integrated model reduces the risk of version mismatch between outputs, metadata, and supporting documents. It also helps teams move faster because the final package is produced from the same governed source of truth used for derivations and review. In practice, this can shorten the path from database lock to submission-ready package while improving confidence in the final deliverables.

Why leadership should care

For directors of programming and IT, the business case is straightforward: less manual effort, fewer defects, faster cycle times, and more predictable delivery. SAS positions Clinical Acceleration as a cloud-native platform that helps manage, validate, analyze, and submit clinical research data more efficiently, with scalable analytics and collaborative workflows on Viya.

For compliance teams, the value is governance and traceability. For SAS programmers, it is reusable logic and a controlled execution framework. For open-source contributors, it is the ability to bring Python or R into a regulated workflow without losing oversight. That combination is important because modern clinical development increasingly depends on hybrid teams and hybrid methods.

Operating at enterprise scale

The real promise of Viya is scalability across studies and portfolios. Containerized, cloud-native execution supports broader deployment models, whether on-premises or in the cloud, while still preserving controlled access and auditability. SAS also highlights integrations with EDC, validation tools, and metadata repositories, which are essential for enterprise-scale clinical operations.

This matters when organizations need to run many studies in parallel, support external partners, and standardize submission practices across regions. Instead of treating automation as a point solution for one protocol, leaders can use Clinical Acceleration to establish a submission factory model: standardized inputs, governed derivations, automated checks, and packaged outputs ready for regulatory review.

Closing perspective

Scaling submission automation is no longer just an efficiency initiative; it is a strategic capability for modern clinical development. SAS Clinical Acceleration on Viya gives life sciences organizations a practical path to automate derivations, embed validation, and generate submission-ready output in a governed, reproducible way.

For leadership teams, the payoff is clearer timelines, better inspection readiness, and a stronger foundation for future innovation. In a landscape where speed and compliance must coexist, that combination is especially valuable.

Learn more

• The SAS Clinical Acceleration Repository: A Game Changer for Clinical Research
• Accelerating Clinical Analytics: Your Path from SAS LSAF or SAS 9 to SAS Clinical Acceleration
• Transforming Clinical Programming With SAS Clinical Acceleration
• Accelerating Clinical Trial Innovations With SAS Viya and Generative AI

The post Scaling submission automation with SAS Clinical Acceleration on Viya appeared first on The SAS Data Science Blog.