From the Red Hat edition of October 29, 2026
University of North Carolina builds human-centered AI assistant (SARHAchat) on Red Hat OpenShift AI
University of North Carolina at Chapel Hill (School of Nursing, Computer Science, RENCI) · Higher education / public health information · Chapel Hill, North Carolina, U.S.
- Publisher
- Red Hat
- Original publication
- Red Hat customer case study, Sept. 16, 2026
- Source retrieved
- 2026-10-30
What happened
Vendor claim: UNC's School of Nursing, Computer Science department and RENCI moved SARHAchat, a sexual and reproductive health assistant for 18 to 25-year-olds, from a general-purpose LLM prototype built over 2 years to Red Hat OpenShift AI. Working with Red Hat pre-sales, the team built a prototype in 2 weeks. It reports smooth switching between informational and consultative modes, safety checks for basic health screening, and a move from a model of more than 500 billion parameters to a 20-billion-parameter model, which the team says gives faster responses on less infrastructure. The system and data are hosted on premises on NVIDIA hardware. Public testing and interviews are still under way, and the long-term aim is handoff to non-profit organizations.
Why it matters
A public university case of on-premises generative AI for sensitive health information. It is relevant to university research IT, academic medical centers and state public-health agencies weighing self-hosted, smaller models for sensitive-topic assistants. The planned handoff to non-profits highlights sustainability and maintainability questions that SLED programs face after grant-funded pilots.
Evidence and measured results
Read the web case study (datePublished 2026-09-16) and the linked PDF. All metrics come from vendor marketing with customer quotes: a prototype in 2 weeks and a 500B-to-20B model reduction. No user outcomes, accuracy, safety evaluation results, cost figures or usage numbers are reported. The assistant is still being tested with members of the public, so this is a pre-production result.
Limitations and uncertainty
Vendor-published case study, pre-production, with no independent evaluation or quantitative outcomes beyond model size and prototype speed. No event date is given for the migration.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Institutions want trustworthy, private AI assistants for sensitive topics without depending on large third-party models whose behavior changes with upgrades.
- Stakeholders
- Academic or clinical program lead
- Research computing (e.g., RENCI-like groups)
- University CIO/CISO
- IRB or clinical safety reviewers
- Discovery questions
- What sensitive domain would the assistant serve, and who reviews its safety?
- Do you have on-premises GPU capacity?
- Who will operate the service after the pilot or grant ends?
- How will you measure accuracy and user benefit?
- Value hypothesis
- Right-sized, self-hosted models on OpenShift AI may lower serving infrastructure needs and provide more stable behavior than general-purpose hosted models.
- Potential engagement
- Model right-sizing and evaluation pilot on OpenShift AI for one sensitive-domain assistant.
- Unsupported claims
- Any health outcome or user benefit
- Cost savings amounts
- That the assistant is safe for clinical use
Pre-sales engineering
Role takeaway
- Fit
- Fits institutions with on-premises GPUs and OpenShift that need data control for sensitive conversational AI.
- Architecture and integration
- OpenShift AI model evaluation, fine-tuning and serving on NVIDIA hardware; application-level safety screening and dual-mode conversation design.
- Prerequisites
- On-premises GPU capacity
- OpenShift AI subscription
- Domain-expert evaluation datasets
- Constraints
- No published accuracy or safety evaluation
- Pre-production status
- Vendor-only metrics
- Security
- Keep conversation data on premises with defined logging, retention and access controls; the case study does not describe these.
- Proof of value
- Compare candidate models on a domain evaluation set before selection
- Measure response latency and GPU use for the chosen model
- Run a safety review of screening logic with clinicians
Delivery
Role takeaway
- Work
- Prototype, evaluate and harden a sensitive-domain assistant, then define its operating and handoff model.
- Dependencies
- Clinical and ethics review
- GPU availability
- Operator for long-term support
- Ownership
- Academic program owns content and safety; research computing owns platform operations.
- Skills and adoption
- Train program staff on model evaluation and the operating team on OpenShift AI serving.
- Governance checkpoints
- Safety and ethics review before public testing
- Accessibility review of new interfaces
- Handoff readiness review
- Acceptance criteria
- Proposed: documented accuracy and safety evaluation results
- Proposed: defined retention policy for conversations
- Proposed: named operator and support model before scale-up
- Risks
- Unsafe or inaccurate health guidance
- Sustainability gap after pilot funding
- Privacy exposure from conversation logs
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
On-premises OpenShift AI on NVIDIA hardware with model swapping (the team is exploring Google Gemma 4). Right-sizing to a 20B model reduces GPU requirements for serving.
Governance
Who approves, reviews and stays accountable for outcomes?
On-premises hosting is cited as giving control that helps align with CDC guidelines. Clinical safety governance for a health assistant is described only qualitatively.
Security and privacy
What data, permissions and controls need testing?
Sensitive reproductive-health conversations stay on university infrastructure, but the case study gives no detail on logging, retention or access controls.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
The team plans voice and video features to reach a wider audience and stresses that operating the system must be manageable for organizations without in-house AI expertise.
Procurement
What should contracts, pricing and exit terms secure?
The work was done with vendor pre-sales help. Institutions should budget for post-pilot support and subscriptions if a non-profit or other operator takes it over.
Operating model
Which teams own the service once it runs?
Shows a university-built service intended for transfer to external operators, which needs a clear support and maintenance model.
Publication history
- 2026-10-29Red Hat · Issue 018 resources
Stable resource ID: unc-sarhachat-openshift-ai-case-study-20260916