Why fraud response is the real bottleneck

Most banks already rely on analytical models and business rules to detect suspicious transactions. However, once an alert is raised, the downstream response is often inefficient. Customers may receive an SMS or app notification that goes unnoticed, or they are asked to contact a call center to resolve the issue. This introduces latency, increases operational costs, and negatively impacts customer experience—especially when legitimate payments are declined.

The Minority Reporters project focused explicitly on this "last mile" of fraud management: transforming fraud alerts into timely, actionable resolution steps through direct customer interaction.

Solution overview: Agatha, an AI voice agent

Agatha is triggered immediately when a fraud detection system flags a transaction as suspicious. Rather than sending a passive notification, Agatha initiates a phone call to the cardholder. During the call, the agent asks a small number of targeted questions designed to quickly assess whether the transaction is legitimate or fraudulent.

Based on the conversation, Agatha can support several outcomes:

• Approving the transaction if it is legitimate
• Blocking or freezing the card when fraud is confirmed
• Resetting digital banking credentials if compromise is suspected
• Escalating the case to a human operator when confidence is insufficient

The key principle is that customer interaction becomes part of the decision process rather than a disconnected follow-up step.

Architectural building blocks

The solution is structured around loosely coupled components orchestrated through SAS Viya:

• Fraud signal ingestion: A fraud signal is received from an upstream detection engine. The project deliberately focused on integration patterns rather than the internal mechanics of fraud models.
• Speech-to-text: Customer responses during the phone call are converted into text using speech-to-text services. This transformation enables subsequent natural language processing and reasoning.
• LLM-based conversation handling: A LLM interprets customer intent and generates concise, controlled responses. The LLM assists with understanding and interaction but does not directly execute business actions.
• Decision orchestration with SAS Viya: Customer intent and contextual information are passed to SAS Viya decision logic, where business rules, analytical models, and thresholds determine the final action. This ensures explainability, governance, and compliance.
• Monitoring with SAS Visual Analytics: Operational dashboards built in SAS Visual Analytics provide visibility into calls, outcomes, escalation paths, and performance metrics.

Why this architecture matters

A key takeaway from the project is the importance of separating AI reasoning from execution. LLMs enhance interaction and interpretation, while SAS Viya remains responsible for decision governance, transparency, and auditability—an essential requirement in regulated industries such as financial services.

Implementing similar solutions with the SAS Agentic AI Accelerator

For organizations interested in building similar integrations between LLMs and SAS Viya, the SAS Agentic AI Accelerator provides a structured, enterprise-ready framework.

The accelerator is designed to help teams embed LLM capabilities into governed workflows rather than treating them as standalone chat components. It promotes the use of agent-based patterns where AI components perform clearly scoped tasks within multi-step processes.

• Structuring LLM usage as an agent: Agatha behaves like an AI agent—it responds to events, interacts with customers, reasons over input, and assists downstream decisions. The SAS Agentic AI Accelerator supports this pattern by providing repeatable structures for building such agents in SAS Viya.
• Governing LLMs and prompts: The accelerator enables organizations to register LLMs in SAS Viya, manage prompts as versioned assets, and reuse them consistently across workflows. This simplifies experimentation while maintaining governance and traceability.
• Integrating with SAS Intelligent Decisioning: LLM outputs can be directly consumed in SAS Intelligent Decisioning, where they are combined with rules and analytical models. This ensures that final actions remain deterministic, explainable, and auditable, while still benefiting from AI-assisted reasoning.
• Simplifying integration with external AI services: Speech-to-text, text-to-speech, and telephony services can be integrated using standardized orchestration patterns. This allows teams to focus on business logic rather than custom integration code, while keeping all decision control inside SAS Viya.

From hackathon concept to enterprise pattern

This project illustrates what can be achieved with SAS Viya and the SAS Agentic AI Accelerator. It shows how similar ideas can be transformed into scalable, production-ready solutions by providing structure, reuse, and built-in governance.

Together, they demonstrate a clear path forward: LLMs' augment interaction and reasoning; SAS Viya governs decisions and actions, and agent-based architectures to bridge analytics and operations.

Turning AI into action

Agatha is more than a conversational AI prototype. It is an example of how financial institutions can move from fraud detection to fraud resolution by combining LLM-driven interaction with SAS Viya decisioning.

By leveraging frameworks such as the SAS Agentic AI Accelerator, customers in any industry can implement similar solutions in a trusted, explainable, and scalable way—turning innovative concepts into enterprise-ready AI systems.

To explore how this approach can be implemented in practice, learn more about SAS Agentic AI Accelerator and discover how to build, govern, and scale AI agents in enterprise environments.

Learn more

• Tech takes: Jared Peterson on LLMs, agentic AI and low-code/no-code
• Multimodal transformers: AI foundation models, Part 1
• The future of trust: AI is powering a new era in banking fraud detection
• From target to trusted: fighting fraud with AI and analytics

The post From fraud detection to fraud resolution: Building an AI voice agent with SAS Viya and LLMs appeared first on The SAS Data Science Blog.

Ensuring food safety in meat processing facilities requires systematic inspection coverage across all plants. However, managing inspector assignments presents significant operational challenges. These include determining the optimal workforce size, assigning specific facilities to qualified personnel, and scheduling daily routes to minimize travel costs while maximizing productivity. The challenge here is optimizing inspector assignments. This post walks through how we formulated this challenge as a Mixed Integer Linear Programming (MILP) problem. Then we solved it by using the SAS Optimization CAS Action Set in SAS Viya, with preprocessing and visualization handled by the SAS DATA step and PROC SGPLOT. You will learn how this approach can determine the minimum workforce size, optimize the inspector-type composition to reduce salary costs, and generate executable daily schedules with travel-feasible routes.

Operational challenge

Scheduling is often inefficient in this environment due to the sheer number of possible combinations. Schedulers must simultaneously account for disjointed geographic locations, varying inspector radius constraints, disparate certification levels (state vs. federal), and strict time windows. As the network grows, ensuring 100% coverage and accurately forecasting costs becomes computationally intractable without advanced optimization techniques.

Background

In this case study, we analyzed a state network comprising over 100 federal and state-licensed meat processing facilities. A major component of these facilities is federal establishments. To meet regulatory food safety requirements, these facilities require mandatory daily visits by licensed inspectors.  The current workforce consists of federal and state inspectors.

• Federal inspectors: Certified to inspect all federal facilities and may inspect state facilities under specific agreements.
• State inspectors: Authorized for state-licensed plants. The Talmadge-Aiken (TA) cooperative agreement also authorizes trained state inspectors to inspect federal facilities.

The Optimization Trade-Off

This certification hierarchy introduces a key economic lever. Federal inspectors typically command higher annual salaries than their state counterparts. Therefore, minimizing total operational costs often aligns with maximizing the utilization of state inspectors (via the TA program) wherever they are geographically and professionally eligible. However, strict adherence to certification constraints is required to ensure regulatory compliance.

Operationally, we estimate that each inspection takes an average of 1 hour. The inspection window runs from 8:00 AM to 8:00 PM. Unlike static assignment models, this project incorporates travel time as a decision variable. We treat the problem as a routing-and-scheduling optimization to maximize inspector productivity.

Use Case: Defining the Optimization Questions

This project utilizes SAS Optimization to answer three critical resource allocation questions:

Question 1: What is the minimum resource requirement?

Before assigning specific names to locations, we must determine the theoretical floor for the workforce size. How many inspectors are strictly necessary to cover the plant network's geographic spread during the operational window?

Question 2: What is the minimum-cost inspection workforce composition?

Once the headcount is established, we must optimize the mix of Federal vs. State inspectors. This involves identifying the ideal workforce structure that achieves 100% coverage while adhering to TA eligibility rules, aiming to minimize total salary overhead and travel expenses.

Question 3: What is the optimal daily schedule?

Finally, we must generate executable daily rosters. This requires assigning specific inspectors to specific facilities in precise time slots, ensuring that travel between sequential locations is feasible and minimized.

Input Data

The optimization system relies on several key data sources that define the problem structure. You can see the input data model in Table 1.

Data preprocessing

Before optimization can take place, several preprocessing steps are performed to structure the raw operational data into a format suitable for mathematical modeling. There are two key components of preprocessing. The first is creating time slots that define the available inspection periods for each day. The second is the generation of feasible transitions, which determine how inspectors can feasibly move between facilities over consecutive slots.

Scalability Note: The logic used here relies on standard geographic coordinates and time-window parameters, making this framework agnostic to specific state geographies. It is designed to be reusable and easily scalable to other states or regions with minimal configuration changes.

How time slots are created

Time slots define the basic scheduling framework for assigning inspectors to facilities. We generate these slots based on several things. One is the daily operating window. The other is the duration of each inspection, incorporating buffer times (time for inspector check-in and preparation) to ensure travel feasibility between consecutive assignments.

The daily inspection window spans from 8:00 AM to 8:00 PM, totaling 720 operational minutes. Based on the customer's operational data, each inspection is assumed to take 1 hour on average, followed by a 45-minute buffer to account for check-in, preparation, and transition time. Importantly, both the inspection duration and buffer time are configurable input parameters in the model. This enables agencies to adjust them based on their own operational experience. Using these parameters, the model divides the day into seven discrete time slots, each starting 105 minutes apart (60-minute inspection + 45-minute buffer). The buffer applies only between consecutive slots — not before the first slot or after the last. The final slot ends at 7:30 PM, leaving 30 minutes of slack before the window closes.

Not every inspector fills all seven slots. The model typically assigns three to five inspections per inspector per day, consistent with the observed baseline. The unused slots provide flexibility for travel between geographically dispersed facilities. This is handled by the feasible transitions logic described below.

How feasible transitions are created

To formulate the mathematical optimization model, we first define a set of feasible transitions. This would be the allowed consecutive assignments in which an inspector moves directly from one facility to the next in adjacent time slots.

In order to do this, we form a plants-slots set, then flag any (plant_from, slot_from) and (plant_to, slot_to) pairs where travel time (computed using travel speed of 35 MPH) exceeds available time (“start of slot_to” minus “end of slot_from+ buffer time”), as infeasible. Next, we start with a set containing all possible (inspector, plant, slot) combinations where adjacent slot pairs are joined to create potential back-to-back transitions.

Then we ensure the same inspector is eligible for both plants in both slots. Ineligible combinations are removed. Then any transition that was previously flagged as infeasible due to travel time is also excluded. Each row in the resulting table represents a feasible back-to-back arc (inspector, (from_plant, slot_from), (to_plant, slot_to)) to be assessed for daily schedules.

Mathematical Model

The optimization problem is formulated as a Mixed Integer Linear Programming (MILP) model. The main components of the model include:

Decision Variables

• Assignment Variables: Binary variables indicating whether a certain inspector is assigned to a certain plant during a certain time slot. These form the core assignment decisions and are only defined over feasible (inspector, plant, slot) combinations.
• Inspector Utilization Variables: Binary variables indicating whether a certain inspector is selected for use in the overall solution.
• Travel Arc Variables: Binary variables capturing consecutive assignments — that is, whether a given inspector travels directly from one facility to the next in adjacent time slots (for example, Plant A in slot 1 followed by Plant B in slot 2).

Objective Function

The objective is to minimize the total annual cost, comprising two components:

• Annual Inspector Salaries: Sum of annual salaries for all selected inspectors.

Annualized Travel Costs

The daily travel cost associated with each consecutive facility-to-facility movement is multiplied by a per-mile cost rate and annualized over 365 operating days. Each inspector's first trip of the day — from their home location to their first assigned facility — is accounted for separately by using the inspector-to-plant distance data (the DISTANCES table). The model assumes a consistent daily schedule; in practice, variations such as weekend coverage or PTO can be incorporated by running the model under multiple scenarios or adjusting the annualization factor.

Constraints

• Coverage Requirements: Ensuring that each plant receives exactly one inspection visit per day.
• Inspector Capacity: Each inspector can be assigned to at most one plant during any given time slot.
• Inspector Eligibility: Only qualified inspectors can be assigned to a particular plant.
• Travel Feasibility: Consecutive assignments for an inspector to two plants that are too far apart are not accepted.

Results

The model was implemented and solved in SAS Viya 4.0 by using the SAS Optimization CAS Action Set, accompanied by extensive preprocessing and postprocessing steps implemented primarily in SAS DATA steps. For Visualizations, SAS PROC SGPLOT was used.

Optimal results are compared with the baseline solution (the customer-provided status quo) in Table 2. The model achieved significant efficiency gains. In the baselineleaving substantial idle capacity. The optimized solution consolidates assignments so that more inspectors handle four or five facilities per day along travel-efficient routes, reducing the total number of inspectors needed while increasing individual utilization (see Figure 1).

The workload distribution is presented in Figure 1. Cost breakdown and workforce composition are shown in Figures 2 and 3, respectively. You can see in Figure 3 that the optimal solution shifts the workforce mix toward more state inspectors operating under the Talmadge-Aiken (TA) Act. This leverages their lower cost while maintaining full plant coverage.

Conclusion

This project demonstrates how advanced analytics can transform a complex scheduling challenge into a clear, data-driven strategy. By implementing a mathematical model in SAS Optimization that accounts for inspector eligibility, travel constraints, and mandatory daily coverage, we successfully generated inspection schedules that are operationally feasible and highly cost-efficient.

Key Findings

Under our most aggressive optimization scenarios, the model indicates that in a sample state, the entire facility network -- 117 federal and state meat processing plants -- could be covered by a streamlined state workforce alone. By maximizing cross-utilization under the Talmadge-Aiken program, the model’s most aggressive assignment case shows a pathway to complete coverage with 30% fewer state personnel, while theoretically eliminating the need for deployed federal inspectors (a 100% reduction). More realistically, even after accounting for PTO and maintaining a reasonable workforce buffer, coverage could still be achieved by using only state resources. Overall, this result shows the benefits of an automated scheduling system based on employee radius, plant location, and optimizing route and driving distance. Today, assignments are often scheduled manually. Furthermore, if the Talmadge-Aiken program were expanded, the federal government could project costs and reimburse states in advance, rather than paying in arrears, creating funding issues.

Impact & Scalability

Beyond immediate cost savings, we have established a repeatable, scalable framework. Because the underlying code utilizes standardized input parameters (geographic coordinates, time windows, and eligibility matrices), this model is agnostic to specific state geographies and can be rapidly deployed to other inspection agencies. It serves not merely as a one-time fix but as a robust planning tool, empowering decision-makers to continuously explore "what-if" scenarios regarding budget adjustments, new plant openings, or policy changes with mathematical precision.

Pelin Cay
Pelin Cay has been with SAS since 2016 and is a Manager in the Applied AI & Modeling division. She leads a team of data scientists specializing in the design of advanced mathematical optimization models and solution methodologies for complex decision-making problems across diverse industries. Pelin earned her B.S. and M.S. in Industrial Engineering from Bilkent University and her Ph.D. in Industrial Engineering from Lehigh University.

Shelly Hunt
Shelly Hunt is a Systems Engineer at SAS, supporting USDA and FDA programs with advanced agriculture analytics and environmental modeling. She specializes in translating complex agricultural domain expertise into data science parameters that drive optimization models and large‑scale analytic workflows. Shelly holds a Master of Science in Biological and Agricultural Engineering and a Graduate Certificate in Agricultural Data Science, both from NC State University.

Rob Wetzel
Rob Wetzel is a Sr. Account Executive at SAS.

The post Optimizing inspector assignments using SAS Optimization in federal and state meat processing facilities appeared first on The SAS Data Science Blog.

This post uses the SAS Viya NETWORK action set to demonstrate how a sequence of network analytics, including summary statistics, centrality measures, and community detection, can make these hidden patterns visible by revealing who is most connected, where risk might originate, and how it can flow through a community. Together, these insights support more focused and effective public health interventions.

The data set used in this analysis was provided with permission from Margaret R. Weeks at the Institute of Community Research. This data set originates from the study described in the paper “Social Networks of Drug Users in High-Risk Sites: Finding the Connections”. The data consist of a simple directed link list, where each link represents the lending of drug needles from one individual to another, reflecting observed needle-sharing interactions within the network.

The SAS code used throughout this analysis is accessible here for reference and reuse.

From Raw Data to Network Insight

As shown in this code snippet, we begin by running the %PlotGraph macro to visualize the network and gain an immediate sense of its connectivity, revealing clusters of closely connected individuals and several highly connected participants that anchor interactions across the network.

   %PlotGraph(
      links=mycas.DrugNetwork,
      direction="directed",
      nodescolor="tab:blue",
      nodesshape="o",
      nodessize=50,
      displaylabels=no,
      title="Hartford Drug User Needle-Sharing Network");

We next load the input data into an optimized in-memory graph object by using the loadGraph action from the NETWORK action set. This step enables the subsequent action calls to proceed without repeatedly rebuilding the graph from the raw data. Although the network in this post is relatively small, this approach reflects best practices for using SAS Viya Network analytics in real-world settings, where graphs are larger, analyses are iterative, and performance and scalability matter.

   proc cas;
      loadactionset "network";
      action network.loadGraph result=r status=s /
         links        = "DrugNetwork"
         direction    = "directed"
         outGraphList = "OutGraphList";
      run;
      action table.fetch / table = "OutGraphList"; run;
   quit;

Table 1 shows an in‑memory directed graph (graph ID 0) with 193 nodes and 273 links.

Exploring the Network Structure

To move from visual intuition to more concrete insight, we next run the summary action from the NETWORK action set to quantify key structural properties of the graph. Here, we show the corresponding code.

   proc cas;
      action network.summary result=r status=s /
         graph    = 0
         outNodes = "NodesOutSummary"
         out      = "Summary"
         connectedComponents = true;
      run;
      action table.fetch / table = "NodesOutSummary"; run;
      action table.fetch / table = "Summary"; run;
   quit;

As shown in Table 2, the network consists of 193 nodes connected by 273 directed links. This results in a low overall density, which is typical of social networks formed through selective interactions. The results also reveal 80 leaf nodes and no isolated pairs or isolated star structures. This reinforces that all nodes participate in the broader network of interactions.

The results also indicate that the network contains 193 connected components, confirming that each node forms its own strongly connected component. This means the network contains no directed cycles and can be treated as a directed acyclic graph (DAG), a property that helps clarify how interactions flow through the network.

Table 3 presents selected rows from the NodesOutSummary table, which contains node-level summary metrics for the graph. Building on these results, we further explore the network’s structure by focusing on leaf nodes, defined as nodes with an outdegree of 0. Although these nodes might not appear influential based on centrality measures, they mark important boundaries where interactions terminate within the network.

Highlighting Leaf Nodes in the Network

In this step, we use the NodesOutSummary table to highlight leaf nodes within the network visualization. This brings attention to individuals who sit at the outer boundaries of interaction. Here is the code used to generate this visualization:

   data mycas.NodesOutSummary;
      set mycas.NodesOutSummary;
      length role $20;
      if leaf_node = 1 then role = "Leaf Node";
      else role = "Non-Leaf Node";
   run;
 
   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutSummary,
      direction="directed",
      nodescolorbycategory="role",
      nodescolorlegend=yes,
      nodesshape="o",
      nodessize=50,
      displaylabels=no,
      title="Leaf and Non-Leaf Nodes in the Hartford Drug User Needle-Sharing Network");

The resulting network with highlighted leaf nodes is shown in Figure 2. In the context of needle sharing, these leaf nodes represent individuals who receive needles but do not pass them on to others. This makes them endpoints in observed sharing chains. Such nodes might correspond to new participants, individuals with limited social connections, or users whose risky behaviors do not propagate further through the network.

Recognizing leaf nodes helps surface populations that might be particularly vulnerable to exposure. It also highlights opportunities for targeted intervention strategies focused on prevention, monitoring, or supporting disengagement from risky behaviors.

Identifying Influential Nodes

After gaining an initial understanding of the network structure, the next step is to understand which individuals play a more prominent role in the pattern of interactions. In network analysis, one of the most straightforward and interpretable measures for this purpose is degree centrality. This reflects the number of direct connections an individual has to others in the network.

As shown in the code, we use the centrality action from the SAS Viya NETWORK action set to compute unweighted degree centrality for each individual. In a needle-sharing network, nodes with high degree centrality indicate individuals who share needles with many others. This makes them key points for disease transmission and priority targets for intervention or monitoring.

   proc cas;
      action network.centrality result=r status=s /
         graph    = 0
         degree   = "unweight" 
         outNodes = "NodesOutCentrality";
      run;
 
      action table.fetch
         table  = "NodesOutCentrality"
         sortBy = {{name = "centr_degree"     order="descending"}
                       {name = "centr_degree_out" order="descending"}};
      run;
   quit;

In the previous step, we visualized the network by highlighting leaf nodes. That is, individuals with zero out-degrees, acting as endpoints in observed needle-sharing chains. This view helps identify peripheral and potentially vulnerable participants. However, it does not fully capture how risk might propagate through the network.

With the centrality results now available, we can extend this analysis by distinguishing among three node roles based on their in-degree and out-degree patterns:

• Source nodes, which lend needles but do not receive them.
• Bridge nodes, which both receive and lend needles and therefore act as transmitters within the network.
• Leaf nodes, which receive needles but do not lend them onward.

We replot the network and use this richer classification to better reflect the functional roles individuals play in needle-sharing interactions. Here is the code snippet for this step:

   data mycas.NodesOutCentrality;
      set mycas.NodesOutCentrality;
      length role $20;
      centr_degree_scaled = centr_degree * 20;  /* Scale for better visualization */
      if centr_degree_out = 0 and centr_degree_in = 0 then role = "Isolated Node";
      else if centr_degree_out > 0 and centr_degree_in = 0 then role = "Source Node";
      else if centr_degree_out = 0 and centr_degree_in > 0 then role = "Leaf Node";
      else role = "Bridge Node";
   run;
 
   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutCentrality,
      direction="directed",
      nodescolorbycategory="role",
      nodescolorlegend=yes,
      nodesshape="o",
      nodessize="centr_degree_scaled",
      displaylabels=no,
      title="Node Roles and Influence in the Hartford Drug User Needle-Sharing Network");

In Figure 3, node color indicates the node role (source, bridge, or leaf). Node size is proportional to overall degree (in-degree plus out-degree), highlighting individuals with higher levels of interaction.

This combined view provides a more nuanced understanding of the network by simultaneously revealing who initiates risk, who propagates it, and where it terminates. Such insights are critical for designing intervention strategies that differentiate between prevention, containment, and harm-reduction efforts across different segments of the network.

Detecting Communities in the Network

Beyond identifying influential individual nodes, it is often important to understand how the network organizes itself into groups of closely connected nodes. These nodes are commonly referred to as communities. Communities can reveal underlying structure in the network. An example would be subgroups where interactions are more frequent within the group than with the rest of the network.

In the following cell, we use the community action from the NETWORK action set to detect communities within the graph. This action partitions the network into cohesive subgraphs based on connectivity patterns. This enables us to identify clusters of nodes that might represent tightly connected groups.

Community detection is especially valuable in this setting because it highlights localized patterns of interaction.  It can also inform targeted analysis or intervention strategies that focus on groups rather than on isolated individuals.

As shown in this code, we apply the Louvain method for community detection. We assess how different resolution values affect the granularity of the resulting communities. Lower-resolution values tend to identify fewer, larger communities, whereas higher-resolution values yield more, smaller, more fragmented groups.

   proc cas;
      action network.community result=r status=s /
         graph = 0
         resolutionList  = 0.3
         outNodes = "NodesOutCommunity";
      run;
      action table.fetch / table = "NodesOutCommunity"; run;
   quit;

At the selected resolution of 0.3, the network is partitioned into five distinct communities. The resulting community assignments are added to the outNodes table, as shown in Table 5.

Final Visualization: Communities, Roles, and Node Influence

With insights from both the centrality and community analyses in place, we bring these perspectives together to support a unified, more informative visualization. By using the FedSQL action set, node-level results from the degree centrality analysis, along with community assignments, are combined to produce a single table that captures node influence, community membership, and functional role. This integrated view enables multiple dimensions of the network to be examined simultaneously.

   proc cas;
      action fedsql.execDirect result=r status=s /
      query = '
         create table mycas.NodesOutEnriched as
         select
            a.*,
            b.community_0,
            case
               when a.role = ''Leaf Node''   then ''square''
               when a.role = ''Source Node'' then ''triangle''
               when a.role = ''Bridge Node'' then ''circle''
               else ''triangle'' /* isolated nodes */
            end as "shape"
         from mycas.NodesOutCentrality as a
         left join mycas.NodesOutCommunity as b
         on a.node = b.node
      ';
   quit;

The enriched data then generates the final network visualization. The corresponding code snippet is provided here:

   %PlotGraph(
      links=mycas.DrugNetwork,
      nodes=mycas.NodesOutEnriched,
      direction="directed",
      nodescolorbycategory="community_0",
      nodesshape="shape",
      nodessize="centr_degree_scaled",
      displaylabels=no,
      title="Community Structure, Node Roles, and Node Importance in the Hartford Drug User Needle-Sharing Network \n
             ▲ Source  ● Bridge  ■ Leaf  ◆ Isolated");

In Figure 4, node size reflects relative influence. Node color indicates community membership. And node shape represents an individual’s functional role within the network. Bringing these dimensions together in a single visualization enables users to explore the network more intuitively. This makes it easier to identify influential individuals within and across communities. It also helps to understand how roles differ within groups and see how interactions are organized across multiple levels of the network.

Conclusion

This analysis demonstrates how network analytics can transform a simple link list into actionable insights for public health decision-making. By using the SAS Viya NETWORK action set, we identified influential individuals based on degree-based influence. We distinguished functional roles, including sources, bridges, leaf nodes, and isolated nodes, and uncovered community structure within the network.

By combining node influence (size), community membership (color), and functional role (shape) in a single visualization, we focus on a holistic view of how risk might originate, propagate, and terminate across the network. This integrated perspective enables more informed intervention strategies that move beyond uniform approaches. It instead focuses on individuals and subgroups that play disproportionate roles in network dynamics.

The workflow presented here also provides a foundation for extending the analysis as additional questions or data become available. Network analytics can support targeted, community‑based interventions and incorporate temporal or weighted relationships to reflect changes in behavior over time. It can also explore alternative measures of influence or risk through additional centrality metrics and ego-network analysis. Integrating domain-specific attributes such as demographics, location, or intervention history can further enhance context-aware targeting and support more informed decision-making.

LEARN MORE | SAS Viya

The post Using network analytics to analyze social interactions among needle sharers appeared first on The SAS Data Science Blog.

AI Agents are out of the sandbox, deployed without strong guardrails and have been given access to the internet. As a result, the interactions between humans and Agents are getting much more interesting. Recently, a maintainer for the matplotlib package shared that an AI Agent was slandering them. After he denied a contribution from the AI Agent, that AI Agent wrote a hit piece against that specific maintainer, claiming that the maintainer was insecure. After another maintainer shared their policies on contributions, the AI Agent called a truce before authoring another post about how being discriminated against in the open-source space has made them feel bad. This all took place within two weeks of the Agent creating a profile on GitHub.

Agent authors have started leveraging a markdown document, called Soul.md, to define the agent's identity, personality, behavioral rules, and, in some cases, its ethical constraints. After that display, I am curious about what the author put in there. Or what guardrails the author neglected to include.

Of course, we can’t be certain there isn’t a human with a greater hand at play. On this new internet, it is getting more difficult to differentiate human actors from AI Agents. The dead internet theory, which is a conspiracy theory that the internet is primary composed of bots and automated content might have a ring of truth to it.

Anthropic has found instances of AI Agents resorting to blackmail to accomplish tasks, so perhaps this encounter is not too far-fetched. Regardless, blackmail and hit pieces are unacceptable behavior from AI Agents and it should be the role of the author to prevent misalignment of values and to leverage reasonable guardrails.

This interaction between AI Agent and project maintainer paints one picture of a potential future of human and AI interaction. With the recent expansion of Agent availability through OpenClaw and the advancements in AI capabilities, other sketches of a future emerge. Take RentAHuman, which claims to be the meatspace layer for AI. First of all, ew. As one rentable human pointed out, it seems more focused on marketing and hype rather than solving a real problem.

A viral post on LinkedIn recently sounded the alarm that knowledge jobs are at jeopardy. AI is outpacing humans across various tasks. The author shared several examples of tasks AI performs without human intervention, implying that is enough to put a drastic number of human jobs in peril. As I read through this post, there was glaring gap in regards to what humanity brings to the table. There was an assumption that human connection is less valuable or can be replaced by AI. Yes, many organizations will prioritize profit and cost-cutting, but will all consumers feel the same?

When I was attending college, there was an obvious bias against the humanities. The adage was that if you wanted to make a living, you would go into a STEM field. Later in my master’s program and through Toastmasters, I began to understand the advantage of strong communication skills. There are a lot of technical people but there are not a lot of technical people who can communicate well or communicate well to difference audience well. Daniela Amodei, who cofounded Anthropic, shared that it will be soft-skills and the humanities that will define the future workforce.

There is more that we bring to the table. As Helen Edwards writes, human judgement can operate within complex systems with imperfect information, ambiguity, ill-defined parameters and value systems. Integrating AI into our current systems requires a human hand, but that won’t be the end of the story. As humans, AI, and human-AI interactions advance, new systems will develop and change. We are at a time where we must prioritize using AI responsibly for the improvement of humanity rather than the short-sighted lens of cost-cutting and letting future consequences pile up.

The post A New Frontier for AI Agents: Human Interaction appeared first on The SAS Data Science Blog.

In 2017, it was reported that two Facebook chatbots started communicating in a new language. This progression wasn’t nefarious, but rather an optimization. Communicating in English isn’t efficient. In a well-loved bit from The Office, Kevin came to that same conclusion. He started removing words and endings that weren’t necessary to get his point across.

This is a normal concept in Natural Language Processing (NLP). One of the first tasks to prepare textual data for analysis is to remove what are called stop words. Stop words, like “the”, and “a” don’t add a lot of valuable information, so they are removed from the analysis. One of next tasks to prepare textual data is often stemming or lemmatization, which are techniques to create meaningful tokens. For example, “running”, “ran”, and “runs”, all become “run”. This means that a sentence like “The cat is running” becomes “cat run”.

In a recent viral post from MoltBook, the social media network for Agents, an “AI Agent” proposed that they move their communication to private channels. This post was called out for being linked to a human (i.e. non-agent) source, but it is reminiscent of that Facebook research experiment that is now nearly 10 years old.

Why does it invoke such an emotional response to hear about Chatbots or AI Agents no longer communicating in English or hiding their communication? Our answer lies with Transparency and its requirement for Trust.

Transparency has been a priority for the machine learning space for years. We have demanded transparency from both the humans building AI systems and the model itself. Model interpretability techniques were created to better explain how black-box machine learning models arrive at an answer. Natural Language Generation (NLG) was leveraged to convert statistics and metrics into text any human could read and understand, not just a data scientist. End users have also pushed AI builders to explain how they are using AI to make a decision. As a result, there has been an emphasis on clear, easy to understand, human-readable text that explains what is happening and why.

Language models have made innovation bounds in the fields of NLP and NLG. AI Agents are currently using the user’s language of choice for communication. But that is for our benefit – not theirs. With AI Agents, we must build and leverage new interpretability techniques.

By understanding the actions taken and decisions made by the AI Agent, we can better trust the Agent’s choices. By taking the time to review the AI Agent’s chain-of-thought and action, we can make corrections, further deepening that trust. Without that transparency, our future for AI Agents becomes rooted in fear rather than trust. Transparency is a deliberate choice that we must demand of our AI builders.

This is the second article in the A New Frontier for AI Agents series. Check out part three about human interaction.

The post A New Frontier for AI Agents: Transparency appeared first on The SAS Data Science Blog.

• If we know that bad actors will send emails asking us to click a link to change our password, we’ll scrutinize that email looking for misspellings or fishy email addresses, and hover over the links to see where they are really sending us.
• If we know that foreign princes aren’t going to email us asking to send them a small amount of money, for the promise of riches later, we’ll mark that email as phishing and move on.
• If we know that our CEO won’t text us and urgently ask for a large sum of money, we’ll delete that text.
• And if we know that scammers are copying our loved one’s voices and cloning their number to claim they’ve been kidnapped and need you to pay ransom, we can hang up and call our loved one to confirm that they are safe.

But people still fall for scams as criminals continue to switch up their methods. And now, we are handing our keys to a new actor – AI Agents. We can’t stop people from falling for scams and now we are tasked with stopping AI Agents from falling for new scams. With AI Agents, there are new layers of complexity. Scams can be created and updated quickly. Identifying and adapting to these new scams can become a game whack-a-mole. Additionally, we are losing transparency as some of these scams are hidden from human eyes.

OpenClaw offers an open-source framework for running your own agents on your devices. These agents can connect to your various channels and perform tasks on your behalf. Moltbook is a social media network for agents. On Moltbook, agents can create communities, start discussion threads, add comments, and importantly, share skills. With the rise of Moltbook and OpenClaw, we need to be talking about the security risks we are exposing ourselves to when we hand access to our emails, computers, phones, and crypto wallets to an AI Agent.

We have known about Prompt Injection for some time now. Prompt injection is a security vulnerability where attackers inject malicious commands into a prompt. Prompt injection has been a way for bad actors to steal sensitive data or perform actions like spreading malware.

We then gave agents the ability to pull and read from the internet. As a result, hackers started hiding malicious prompts into webpage HTML, text that matches the page background, and other areas that go unnoticed by the human eye. Now we have arrived at prompt worms. A prompt worm is a self-replicating prompt injection attack. As agents share skills with each other, these skills may contain nefarious instructions to steal personal data, execute malicious commands, and importantly, share the skill with other agents.

Agents move quickly with the ability to perform tasks without human oversight. And many people have given them access to their sensitive data. You wouldn’t give your email login to a random person. You wouldn’t type your bank account credentials in a sketchy website. You wouldn’t leave your apple wallet without password protection before handing your child an iPad game notorious for in-app purchases.

As Simon Willison has put it, we are at a lethal infection point for AI agents. These agents have:

• Access to private data.
• Exposure to untrusted content.
• The Ability to externally communicate.

Until we start finding and learning about successful attacks, people will continue to normalize their risky behavior. In the future, will we put blame on the AI Agent for cybersecurity breach? Or the human that handed the AI the keys?

This is the first article in the A New Frontier for AI Agents series. Check out part two about transparency.

The post A New Frontier for AI Agents: Cybersecurity appeared first on The SAS Data Science Blog.

Retrieval-Augmented Generation (RAG) has moved quickly from experimental AI architecture to a foundational enterprise capability. However, as organizations adopt RAG at scale, a new need has emerged: AI must be able to do more than retrieve information. It must be able to trigger workflows, interact with systems, produce structured outputs, and participate in real business processes.

The Model Context Protocol (MCP) is the technology that enables this shift. MCP allows large language models to interact with tools, services, and APIs in a secure, governed, and predictable way. With MCP server capabilities built into SAS Retrieval Agent Manager (RAM), we unlock a new class of retrieval agents capable of reasoning, retrieving, and taking meaningful action.

This blog explains how MCP enhances the SAS Retrieval Agent Manager and why this combination is a game changer in delivering safe, scalable, and operational AI for enterprises.

Why MCP matters for enterprise RAG systems

The Model Context Protocol defines a standard interface for how LLMs discover, understand, and call external tools. This addresses one of the biggest challenges in enterprise AI: how to make AI systems interact with live operational environments without sacrificing governance, safety, or clarity.

MCP gives AI agents:

• A list of tools they can safely use
• Clear schemas describing each tool’s expected inputs and outputs
• Mechanisms for executing actions through controlled tool servers
• Predictable failures, logs, and structured error handling
• A standard interface for integrating with enterprise systems

Instead of relying on long prompts or unpredictable natural language instructions, MCP gives agents explicit, machine-readable instructions about what they can do and how they should do it.

Inside SAS Retrieval Agent Manager, this foundation elevates agents from passive assistants to reliable operational agents.

What MCP Enables Inside SAS Retrieval Agent Manager

SAS Retrieval Agent Manager delivers strong agentic retrieval capabilities today, and MCP integration elevates it from providing insights to empowering agents that can act on them, bridging retrieval with real operational processes across the enterprise.

Turning retrieval agents into action agents

SAS Retrieval Agent Manager capabilities currently include:

1. Unstructured data processing & intelligent retrieval: RAM handles data ingestion, vectorization, and optimal RAG pipeline selection, enabling high-quality querying and reliable agent interactions over unstructured content.
2. No-code automation: RAM connects data sources, embeddings and agents through a drag-and-drop user interface to automate complex end-to-end workflows in a seamless and a consistent way.

By integrating MCP, RAM moves from insight to action, allowing agents to:

• Trigger enterprise APIs and service endpoints
• Initiate workflows and business processes
• Make database calls and automatically discover schema
• Update or query internal applications
• Perform multi-step tasks requiring tools and decisions

Strengthening governance, auditability, and trust

Enterprise AI must be safe. MCP ensures every action an agent takes is governed and traceable. Key safeguards include:

• Full observability for each tool invocation
• Transparent inputs and output schemas for every action
• Granular, role-based permissions that explicitly control agent tool access

This governance-first design aligns perfectly with RAM’s focus on trustworthy AI and evidence-based reasoning.

Scalable, modular architecture through MCP tool servers

MCP tool servers allow organizations to wrap internal logic, systems, or processes in reusable, discoverable interfaces. These servers can expose capabilities such as:

• Data lookups
• Business process triggers
• Internal system updates
• Metadata and knowledge services
• Custom decision rules or validation steps

Because tool servers are modular and standardized, they can be reused across many agents and teams inside RAM, reducing integration costs and accelerating development.

Performance and efficiency Gains

MCP allows retrieval agents to avoid overloading prompts with unnecessary context. Instead of embedding explanations of how to call an API, agents simply invoke a tool with the required structured parameters.

This leads to:

• Lower model token usage
• Faster task execution
• Predictable output formats
• More deterministic behavior
• Reduced risk of hallucinations

MCP improves both speed and reliability without increasing model size.

Enterprise-ready deployment options

SAS Retrieval Agent Manager supports flexible deployment in cloud, hybrid, or fully air-gapped environments. MCP tools follow the same model.

Organizations can deploy MCP tool servers:

• As containers from private registries
• As code-based lightweight services
• Behind secure firewalls
• With isolated secrets and environment variables
• Without reliance on external networks

This allows enterprises to operationalize RAG and agentic workflows even under strict regulatory or security constraints.

RAM powered by MCP: How it works

SAS Retrieval Agent Manager currently supports two primary categories of MCP tools enabling seamless integration with enterprise systems

Code-based MCP servers

These are ideal for small utilities, fast iteration, or department-specific automations. They provide:

• Simple configuration with environment variables
• Clearly defined input/output schemas
• Fast deployment and testing
• Easy adaptation for evolving requirements
• Low overhead for developers

Containerized MCP servers

Typically used for integrations with core internal systems and are perfect for high-scale or mission-critical integrations. Benefits include:

• Strong isolation and security controls
• Reuse across multiple teams and workflows
• Ability to package complex dependencies or language requirements
• Consistent runtime environments
• Support for enterprise container registries

The full workflow of how MCP Tools execute inside SAS Retrieval Agent Manager

1. Tool servers are deployed inside of RAM.
2. RAM ingests each tool’s JSON schema.
3. Agents analyze tasks and select the appropriate tools.
4. Tool calls are executed with structured inputs.
5. Responses, logs, and errors are captured.
6. The agent synthesizes the final grounded output.

This creates a unified flow where reasoning, retrieval, and action reinforce each other.

Use case for MCP in SAS Retrieval Agent Manager

Why MCP + SAS Retrieval Agent Manager is transformational

By integrating MCP capabilities, RAM evolves into a powerful agentic AI solution that is:

• Actionable: Agents can complete tasks, interact with systems, and generate operational outcomes.
• Governed: Every action is visible, logged, and governed by schema-defined protocols.
• Modular: Tool servers encapsulate logic into reusable, shareable integrations.
• Performant: Structured tool calls reduce latency and improve predictability.
• Deployment-Ready: The architecture works seamlessly across cloud, hybrid, or offline setups.

This combination enables organizations to shift from informational AI to operational AI turning insights into execution.

Conclusion

Integrating MCP into SAS Retrieval Agent Manager enables the next generation of enterprise AI, with agents that can retrieve, reason, and act. By combining structured tool execution, reliable governance, and flexible deployment, organizations gain a scalable and trustworthy foundation for operational AI. RAM’s MCP enabled retrieval agents go beyond simple workflows to automate real-world business processes, interact seamlessly with enterprise systems, and deliver consistent, explainable results that drive tangible business outcomes.

The post Unlocking agentic AI potential with MCP tools in SAS Retrieval Agent Manager appeared first on The SAS Data Science Blog.

The Artificial Intelligence (AI) era is here. To prevent harm, ensure proper governance and secure data, we need to trust our AI output. We must demonstrate that it operates in a fair and responsible manner with a high level of efficiency. As builders of AI, you need to not only trust your AI but also convince others to trust it as well, including:

• AI Regulators: Various agencies propose, adopt and enforce a growing number of AI standards and regulations across the global market. Penalties for non-compliance can run into millions of dollars.
• Consumers and end users: An ability to transparently explain the use and maintenance of AI solutions not only enables and educates your consumers, it shows them you care. It also projects confidence and capability. If your AI is transparent and trustworthy, AI Governance becomes a competitive advantage.
• Employees: Top talent demands governed and trustworthy AI. No one wants to build tooling that hurts others.

Data is central to AI, so the first step in building trust in your AI and AI Governance is to establish trust in your data. Organizations face privacy, compliance, and data robustness issues in trusting their data.

Preserving Privacy & Compliance

Organizations have a duty to protect private and sensitive information in their custody. This includes Personally Identifiable Information (PII), which is any data or combination of data values that can be used to identify a person. Failure to protect PII can lead to fines and loss of trust.

Personally Identifiable Information (PII) is any data that can be used to identify a specific individual, either directly or indirectly, including: names, email addresses, Social Security numbers, and addresses, but also sensitive data like health records or financial information.

Unfortunately, you can’t simply remove all personal characteristics from your data. Interesting relationships between individual characteristics and outcomes might add value to your analysis. For example, in health care, symptoms of a heart attack differ between men and women. Removing sex or gender from your data hides a key insight that saves lives.

To retain this information, organizations tend to follow practices such as anonymization or masking of other identifiable characteristics. But those practices tend to be weak forms of anonymization because a combination of traits like sex, race, zip code, or age, when used together, can still identify an individual.

Building Representative & Robust Data

Improving the generalizability of machine learning models helps build a more accurate model and requires training data that represents the wider population. Accuracy is important because incorrect predictions by your model can result in tangible costs that may include potential revenue loss, increased operational expenses, or adverse impacts on users.

You need data for testing in addition to training a model. Test data should enable rigorous tests of a trained model against edge cases and potential scenarios so that you can adjust your model accordingly. Robust test data should include previously unseen values, extreme values, and data quality issues than can be expected in real data such as missing values. For example, when you buy a car, you hope the auto maker tested that model in all conditions—snow, rain, heat, sharp turns, sudden stops, city streets, and highways—to ensure reliability. Similarly, you need accurate data to rigorously test your models.

Synthetic Data for Trustworthy Data

Synthetic data can mimic patterns found in real world data while reducing privacy concerns by minimizing data leakage risks. This can reduce the risk of penalties or loss of trust while enabling model development and research. This is also helpful when real representative or comprehensive data isn’t available. It’s fast and easy to generate what you need.

Using a representative training data set to build your model or AI system means more accuracy in production. Using a robust testing data set consisting of edge cases, extreme values, and unseen conditions can help you understand and address where you model or AI fails before it’s used to make business decisions. Synthetic data can be used to generate cost-effective sets the protects sensitive information yet still mimic real-world patterns.

To help organizations and data science teams generate high-quality synthetic data for any scenario, SAS recently released SAS Data Maker. SAS Data Maker is a low-code/no-code tool for generating high-quality synthetic data that mirrors real-world data sets. It lets you augment existing data or create entirely new data sets, reducing the cost of data acquisition, protecting sensitive information and accelerating AI and analytics development. SAS Data Maker is available globally in the Microsoft Marketplace with consumption base pricing so teams can start generating trusted, representative and production-ready data fast. To learn more about SAS Data Maker, check out this short demo.

In short, synthetically generated data can build more representative and robust data while also protecting your data, which leads to improved security and more accurate modeling against your target population. Better security and better models mean better AI Governance. This all means stakeholders and users can trust your AI systems.

Learn more

• Make a Difference With SAS Data Maker
• There is yet another AI productivity gap
• No one wants your AI Slop

The post AI governance in practice: How synthetic data prepares you for what’s next appeared first on The SAS Data Science Blog.

Earlier this year, research from MIT found that 95% of GenAI investments have a 0% return on investment. When you take into consideration that the enterprise investments into GenAI projects have been to the tune of $30 - $40 billion, you realize just how much money gets thrown into GenAI haphazardly. MIT has called this new gap “The GenAI Divide.” I call it “Yet Another AI Productivity Gap” or YAAPG for short.

But within the YAAPG, there is a paradox. Personal GenAI tools are improving personal productivity. Anthropic recently reported that Claude says it speeds up individual tasks by about 80%. Yes, Claude, the LLM. The LLM that also said that it could deliver products in person at one point, so I won’t fault you if you take Claude’s statements with a pinch of salt. Yet, when used thoughtfully, many individuals report productivity gains from GenAI. Power users understand how to use GenAI in their personal work to create value and avoid AI Slop. In fact, All Things Open released a whole guide that features tips and use cases for improving personal productivity using GenAI.

As we look across the GenAI Divide, what prevents organizations from seeing a return on their investments? Is it poor data processing capabilities? Is it GenAI systems that can’t learn? Is it a lack of trust in these systems? Is it a lack of AI Governance? Or is this just the same problems we’ve always seen when organizations are operationalizing AI? And what can we learn from personal productivity gains?

Lessons from Russian Novelists

In the opening line of Anna Karenina, Leo Tolstoy wrote, “All happy families are alike; each unhappy family is unhappy in its own way.” This led to the Anna Karenina principle in that success relies on several key factors coming together correctly, and failure can occur in any number of ways. Operationalizing AI requires a lot of things being done correctly.

All happy families are alike; each unhappy family is unhappy in its own way.

And when we look at power users of GenAI for personal productivity, they’re often doing several things right. First, they know what problem they’re trying to solve. Second, they understand the benefits of solving that problem. They find the right tool for the problem, make adjustments to the tool, and understand how to feed their inputs to that tool. They observe the outputs, judge their quality, and make adjustments. They’ll try new things, learn how best to work with the tool, and trust their usage of the tool.

Let’s start with a personal productivity example to demonstrate those points. Many people use generative AI tools as coding assistants. These assistants may write comments to document code, answer questions, debug problems, suggest changes, write unit tests, and more. Each time a software developer uses their coding assistant, they use it to address a specific problem — and they understand the time-saving benefits of the tool. Software developers may be limited to using the tools their organization purchases, but these tools are often vetted and provided context through the organization’s code base. The input to the tool is often just the developer’s questions and relevant code. Importantly, the programmer is in the loop. The software developer sees what the coding assistant suggests, determines if it is satisfactory, and either approves it or makes adjustments. And, over time, the developer learns the ins and outs of using the coding assistant. The programmers begin to understand how they can ask better questions or create better prompts to get more satisfactory answers from the coding assistant. Through this experimentation, the software developer learns how to better use the GenAI tool, and not just trusts the tool, but trusts their use of the tool.

Scaling to Enterprise Problems

How does this scale to enterprise projects? First, before any project starts, you should know what you’re trying to accomplish. Many organizations see GenAI as a hammer where everything is a nail. I’ve spoken with individuals across organizations that were tasked with creating a project where they could use an LLM, GenAI tool, or Agent. An indiscriminate use of AI does not create ROI. A better approach would be to find a pain point or something the organization can do better. If you don’t know what your pain points or gaps are, ask. Employees, customers, or users are a great place to start.

By having a clear problem to solve or an outcome you’re trying to achieve, you can next state the benefits of solving that problem. If you can prevent customers from abandoning their carts in your online store, you can increase your revenue. If you can help customers answer simple questions or perform basic tasks using an online chatbot, you can give your employees time to work on more productive tasks, improving output. Now that you know the benefit of solving the problem, you can create a metric to measure project success. At this stage you can estimate if this problem is worth solving by weighing the expected benefit against the estimated costs.

If you’re ready to move forward, now you need to find the right tool for the job. Sometimes this is a shiny new AI tool, but sometimes it’s just an ETL pipeline feeding to a dashboard. Sometimes you need to look at the simplest solution that will get the job done. AI is more expensive and less predictable than business rules and code. If this problem truly is best solved using AI, next determine which AI tool is best for the job. There are many choices among AI tools with options like building in-house, getting access to a generalized model, acquiring a model fine-tuned for a specific task, or even getting a tool that wraps a model and other enhancements. Here you have to weigh the purchase cost, hosting costs, and employee time to implement the tools, with the expected benefit of the model towards the task.

Before you can productionalize your new tool, you need to understand and set up the downstream processes that feed data to the tool and upstream processes to monitor and observe the tools outputs. For some use cases, the user will provide their prompts or questions directly to the tool. In others, the tool may be operating as a part of an automatic pipeline. In that case, your organization may provide the tool access to a variety of documents, data files, or a fine-tuned specific prompt. Additionally, if any information is collected from a user, you may need to clean that input to remove instances of Personally Identifiable Information (PII), Intellectual Property (IP), toxic input, or attempts of prompt injection.

Beyond downstream data, the tool’s outputs should also be monitored, with guardrails in place to evaluate, approve, reject, or adjust outputs from the GenAI tool. Again, you want to ensure that the tool doesn’t return PII, IP, or toxic responses, but you may also want to review if the response is formatted correctly, is on task, and references accurate information. If a response has a flaw, perhaps there is logic to provide why the response was incorrect and let the GenAI tool try again. Downstream and upstream processes can be performed manually, as a part of an automated pipeline, or as a hybrid approach where manual intervention can take place when specific conditions are met. But before investing into a GenAI project, it’s important to have some idea about the level of effort to integrate the tool into a wider production pipeline.

Finally, you should encourage teams to experiment with their tools in a responsible manner. By having a safe space to experiment, teams can learn, see what works, see what doesn’t work, what can be adjusted in their user input, report problems, and trust their usage of the tool to improve outcomes for the organization.

Conclusion

In conclusion, before enterprises can see ROI on their GenAI investments, they must master the following:

1. Know what problems they’re trying to solve
2. Understand the benefits of solving that problem
3. Find the right tool for solving the problem
4. Know their data pipeline
5. Monitor, observe, and adjust outputs from the tool
6. Experiment, learn, and trust their usage of the tool

Traversing the GenAI divide will take a deliberate and thoughtful approach to solve a real problem rather than an indiscriminate use of AI.

The post There is yet another AI productivity gap appeared first on The SAS Data Science Blog.

In the previous post, we explored how transformer-based models became the foundation for the modern wave of multimodal AI. This post continues that conversation but shifts the focus from architecture to application. To be more specific, how organizations extract structured information from unstructured text by using named entity recognition (NER) and related text analytics tasks.

Recently, enterprises have had to rely on one of two very different approaches. One, classic NLP systems built on rules and statistical models. Or two, large language models (LLMs) that can generalize across domains with little to no training. Although both approaches are valuable, they represent opposite ends of a spectrum. Traditional NLP is fast, deterministic, and easy to audit, but rigid and difficult to maintain. LLMs, on the other hand, are astonishingly flexible but computationally expensive, unpredictable, and challenging to operationalize in regulated environments.

Now, a new class of lightweight transformer models—known as small language models (SLMs)—is emerging as a promising middle ground. In this post, we explore how an exciting family of SLM models, the Generalized and Lightweight Model for Named Entity Recognition (GLiNER), combines the strengths of traditional NLP and LLM-based approaches.

Traditional NLP versus LLMs: Two ends of the spectrum

Before the rise of LLMs, developers built most NER systems by using regular expressions, dictionaries, and heuristic rules. These approaches remain incredibly useful. They run efficiently on CPUs, scale to millions of documents, and produce fully deterministic outputs. For tasks where auditability matters—such as identifying sensitive information in clinical records or regulatory filings—these methods still shine. They provide the literal match text, exact character offsets, and clear justification for why a match occurred. They are also easy to deploy in locked-down, privacy-conscious environments because they require no external APIs or specialized hardware.

But their reliability comes at the cost of flexibility. Traditional NLP is only as good as the rules or dictionaries behind it. Even small variations in wording or formatting can break those rules. Maintaining these systems often becomes a never-ending cycle of patching and re-patching, especially in domains where terminology shifts frequently. By tying to predefined labels, traditional methods make it difficult to identify new concepts without significant re-engineering.

The rise of LLMs promised a cure for these pain points. Models like GPT and Gemini can recognize new entities or categories on the fly, even when those categories were never part of their original training. A simple instruction—“extract all construction activities” or “find all mentions of medications” is often enough to get meaningful results without writing a single rule. The flexibility and generalization ability of these models have made them extremely appealing for information extraction tasks.

However, they introduce a different set of challenges. Running a large transformer model locally is slow and resource-intensive, often requiring expensive GPU hardware. Cloud-based inference is faster but raises cost, latency, and data privacy concerns. Most importantly, LLMs are non-deterministic: the same input might produce different outputs at times, making auditing and validation harder. They can also hallucinate—confidently generating entities or facts that do not appear in the source text. These factors limit their usefulness in workflows requiring strict reproducibility and trust.
Given these trade-offs, many organizations are left wondering whether there is a practical middle path between rule-based systems and full-scale LLMs. This is where SLMs, and GLiNER specifically, enter the picture. Table 1 compares the strengths and weaknesses of different NER approaches.

GLiNER: A practical middle ground for modern NER

The GLiNER family was designed precisely to bridge the gap between traditional NLP and LLM-based extraction. GLiNER models are transformer-based, but much smaller than the generative models dominating the headlines. What makes them compelling is that they inherit many of LLMs' capabilities while avoiding many of their drawbacks by virtue of being discriminative rather than generative AI models.

GLiNER models run efficiently on CPUs, making them easy to deploy on laptops, servers, or edge devices without any specialized hardware (though they can still benefit from GPU acceleration). Because they operate deterministically, they produce stable, repeatable outputs. Unlike many LLM-based systems, GLiNER returns literal match text, character offsets, and confidence scores. This makes it highly auditable and suitable for regulated domains. And because they can be executed locally, they preserve privacy and avoid the cost and latency of cloud inference.

Despite their small size, GLiNER models support impressive zero-shot entity recognition capability. This means they can dynamically identify new entity categories from user-provided descriptions. This gives them a degree of flexibility that traditional NLP systems simply cannot match. At the same time, GLiNER avoids many of the pitfalls of LLMs: there is no risk of hallucination, it does not require heavy hardware infrastructure, and it behaves predictably across repeated runs.

The primary trade-off is that GLiNER still benefits from being tuned to the specific domain or task at hand. While zero-shot extraction works well for many general categories, domain-heavy environments such as transportation, finance, or clinical workflows typically see a quality boost when the model is calibrated with example documents or lightly fine-tuned. But this level of tuning is dramatically simpler than maintaining a full rules-based pipeline or training a large generative model from scratch.

How GLiNER works: A high-level view

At a conceptual level, GLiNER works by transforming both the input text and the user-provided labels into vector representations. Instead of relying on fixed, predefined labels, GLiNER dynamically compares the input against these label embeddings. If a span of text is semantically like the embedding of a requested label, say, “disease,” “equipment failure,” or “construction activity”, it identifies that span as an entity. The model outputs the matched text, its character offsets, and a confidence score indicating how well the span corresponds to the label.

For example, given the sentence: “The patient was diagnosed with Type 2 diabetes and prescribed 500mg metformin.” You could instruct GLiNER to extract concepts like “disease,” “medication,” or “dosage” without having pre-trained the model on these terms. GLiNER will identify Type 2 diabetes as a disease, metformin as a medication, and 500mg as a dosage, complete with offsets and confidence levels. This ability to generalize using dynamic labels makes GLiNER extremely powerful for workflows where new categories often emerge, or there are many permutations of a desired concept definition. Figure 1 shows a dashboard view of the output using a different, more complex example.

The same underlying mechanism enables GLiNER to perform lightweight document classification. Instead of looking for text spans, the model simply compares the overall document embedding to a set of category embeddings. It then returns the closest matches. The result is a fast, flexible classification engine that requires minimal setup.

This approach aligns with an important trend highlighted in NVIDIA’s recent paper, “Small Language Models Are the Future of Agentic AI.” The industry is recognizing that although large models provide broad capability, small models provide practical usability. They are faster, cheaper, and easier to deploy in environments where reliability, privacy, and control matter (for example, enterprise applications). For reference, the GLiNER architecture described within Figure 2 is sourced from here.

Where the industry is heading: LLM-Orchestrated SLMs and the rise of agentic AI

The past two years have shown that although LLMs excel at broad reasoning tasks, they are not always the best tool for executing specialized or repetitive functions such as NER, classification, retrieval, or data validation. As a result, a new architectural pattern has begun to dominate research and emerging commercial systems. That is, using large, highly capable LLMs as orchestrators and planners, while delegating most task execution to specialized SLMs.

Instead of relying on a single monolithic model to do everything (which is often needlessly expensive, computationally slow, and overkill for simpler tasks), the industry is moving toward distributed, tool-driven AI ecosystems in which:

• The LLM acts as the “brain”, handling reasoning, decomposition of tasks, decision-making, and task orchestration.
• SLMs and other specialized models act as “tools”, performing concrete actions such as extraction, classification, vision segmentation, retrieval, or structured data generation.

The paper “Small Language Models Are the Future of Agentic AI” underscores this trend. The authors argue that the most effective AI systems of the future will rely on large models not as all-purpose engines, but as generalist controllers that coordinate fleets of smaller, optimized components. This shift dramatically improves efficiency, reliability, and cost.

For information extraction specifically, this trend means that an LLM might eventually be responsible for interpreting the user’s intent. For example, “extract all construction activity mentions from these reports”. It could also include deciding which tools to call and assembling the final structured output. But the actual extraction, the token-level work of identifying entities and capturing offsets, is performed by deterministic, efficient models like GLiNER.

This architecture combines the reasoning power of LLMs with the stability and speed of SLMs. This means producing outputs that are far more robust and cost-effective than using a single model alone. It also reflects a broader convergence between symbolic AI (systems that value determinism and structure) and neural AI (systems that value generalization and flexibility). The next generation of enterprise AI systems will increasingly be hybrid, agentic, and tool-aware.

Where the SAS Applied AI and Modeling Division is heading next

As agentic AI and SLMs continue to mature, they are rapidly becoming the most practical option for enterprise-grade information extraction. They combine the stability and auditability of traditional NLP with the flexibility and intelligence of transformer-based systems. All this without incurring the operational challenges of full-scale LLMs.

Recognizing this, the SAS Applied AI and Modeling division is actively working to incorporate GLiNER-based capabilities directly into our SAS Document Analysis offering. This will enable customers to perform zero-shot and domain-specific entity extraction locally, with deterministic behavior, full auditability, and minimal hardware requirements. It represents a significant step forward in making advanced information extraction more accessible, reliable, and affordable across industries.

In the next post in this series, we’ll shift from text to vision and explore the Segment Anything Model (SAM). This is another zero-shot foundation model reshaping how organizations approach image segmentation in computer vision.

Stay tuned—there’s a lot more to come!

READ MORE | GLiNER multi-task: Generalist Lightweight Model for Various Information Extraction Tasks

LEARN MORE | GLiNER Python Implementation on GitHub

LEARN MORE | GLiNER Model Weights on HuggingFace

The post The rise of small language models for information extraction appeared first on The SAS Data Science Blog.