From the State Government edition of October 27, 2026
Oregon publishes a disclosure card for its generative AI chatbot on Medicaid work rules: information only, no eligibility decisions, PII stripped before the model, chats kept one year, retested on policy or model changes
Oregon Department of Human Services (ODHS); Oregon Health Authority (OHA); Oregon Enterprise Information Services (EIS) · State Medicaid and benefits administration; public-facing generative AI chatbot transparency · Oregon, U.S.
- Publisher
- Oregon Department of Human Services
- Original publication
- 2026-09-16 (disclosure card last review date); discussed by Oregon's Chief AI Officer in a Lawfare podcast released 2026-10-27
- Source retrieved
- 2026-10-28
What happened
ODHS and OHA run a generative AI chatbot that answers questions about federal Medicaid work or activity rules for the Oregon Health Plan, which take effect Jan. 1, 2027. The card states the chatbot provides information only and does not decide eligibility or coverage. Deloitte built and supports it under contract; it uses Anthropic models including Claude Sonnet. It is designed to use only Level 1 or Level 2 information, to detect and remove personal or health information before it reaches the model, and to keep data in the United States; conversations are not used for model training. Prompts, answers and session IDs are kept for one year and may be public records. Testing covers accuracy against approved information, fairness, privacy, security and resource use, and is repeated after major policy, model or instruction changes or a rise in reported problems. The chatbot is English-only and can be turned off at any time. EIS requires such cards for public-facing AI chatbots.
Why it matters
Why now: Oregon's Chief AI Officer discussed this chatbot and its disclosure card in a Lawfare Scaling Laws episode released Oct 27, and Medicaid work rules start in about two months, so states are standing up resident-facing AI help on a tight timeline. Not in our archive. It is a rare published, state-mandated description of a live benefits chatbot's data limits, retention, testing triggers and vendor, which other states can compare against their own.
Evidence and measured results
Official agency disclosure card opened in full; Lawfare episode page opened (description only; audio not reviewed). The card describes design and testing categories but reports no accuracy rates, usage volumes, launch date or cost.
Limitations and uncertainty
Self-description by the agency, not an independent evaluation; no performance metrics published. English-only at time of review. Podcast audio not reviewed, so Chief AI Officer statements are not cited.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-27; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Medicaid agencies must explain new federal work rules to many enrollees before Jan. 1, 2027, and want AI help without letting a chatbot appear to make eligibility decisions.
- Stakeholders
- State Medicaid director
- Human services eligibility operations lead
- State chief AI officer or EIS
- Agency privacy officer
- Integrator or vendor contract manager
- Discovery questions
- Does the state require public disclosure for resident-facing AI chatbots?
- What content source is the chatbot grounded in, and who approves it?
- What triggers retesting when federal guidance changes?
- How will non-English speakers get equivalent help?
- Value hypothesis
- Interpretation: a published disclosure and test regime could build trust and speed approval of a resident-facing chatbot; Oregon reports no measured effect yet.
- Potential engagement
- Bounded readiness review for one benefits chatbot: draft a disclosure card, define a regression test set and retesting triggers, and set a feedback review process.
- Unsupported claims
- No accuracy, usage or call-deflection figures published
- No evidence the chatbot reduces coverage loss
- Chief AI Officer podcast remarks not reviewed
Pre-sales engineering
Role takeaway
- Fit
- Public-facing information chatbots on benefits rules where answers must match approved policy and must not imply eligibility decisions.
- Architecture and integration
- Pre-model PII and health-data filter; grounding in approved policy content; U.S.-resident storage of prompts, answers and logs; feedback capture per answer; administrative off switch; channels include portal, mobile app and phone center.
- Prerequisites
- Approved policy content source
- Data classification scheme (Oregon uses Levels 1-4)
- PII detection tested against realistic inputs
- Retention schedule for prompts and answers
- Constraints
- Federal work-rule guidance still evolving
- English-only in Oregon at review time
- Prompts may be public records
- Vendor-built under an existing eligibility contract
- Security
- Block PII, HIPAA, FERPA, CJIS and FTI from the model; monitor for attacks and misuse; keep one-year retention bounded and disclosed.
- Proof of value
- Run a regression set of approved policy questions and measure answer agreement before and after each policy update
- Test the PII filter with seeded personal data and measure leakage
- Compare answer consistency across portal, app and phone channels
Delivery
Role takeaway
- Work
- Stand up governance for a benefits chatbot: disclosure card, content approval workflow, regression testing, feedback review, retesting triggers and language-access paths.
- Dependencies
- Federal guidance timing
- Contractor change capacity
- Policy staff to approve content
- Language access services
- Ownership
- ODHS owns the chatbot; Deloitte builds and supports it under the Oregon Eligibility Partnership contract.
- Skills and adoption
- Call center and eligibility staff need to know what the chatbot says and route users who need decisions or other languages to people.
- Governance checkpoints
- Disclosure card published before launch
- Quarterly card review
- Retest after policy, model or instruction changes
- Retest when reported problems increase
- Acceptance criteria
- Proposed: regression agreement with approved answers above an agreed threshold before each release
- Proposed: zero PII passes the filter in seeded tests
- Proposed: feedback reviewed at a set interval with fixes logged
- Risks
- Wrong answers about exemptions lead to lost coverage
- Residents treat answers as decisions
- Retained prompts expose personal data entered by mistake
- Non-English speakers underserved
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?
The design is a retrieval-style information assistant with a pre-model PII filter, U.S. data residency, no training on user data, feedback buttons reviewed by a team, and a kill switch. Access spans the ONE Online account, mobile app and phone customer service center, so answer consistency across channels matters.
Governance
Who approves, reviews and stays accountable for outcomes?
A statewide EIS rule requires disclosure cards for public-facing AI chatbots; this card is reviewed quarterly and names retesting triggers. Interpretation: retesting on federal policy changes is critical because work-rule guidance is still evolving.
Security and privacy
What data, permissions and controls need testing?
The state does not send PII, HIPAA, FERPA, CJIS or federal tax information to the model, but keeps user prompts for one year as possible public records, and warns users not to enter personal information.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
English-only chatbot, with other-language help available through other channels; card offered in other languages, large print and braille on request.
Procurement
What should contracts, pricing and exit terms secure?
Built and supported by Deloitte under an existing eligibility contract. Interpretation: disclosure-card content (model, data limits, retention, testing) is a useful checklist for chatbot contract terms.
Operating model
Which teams own the service once it runs?
A central EIS requirement sets disclosure for all agencies, while each agency owns its chatbot and testing; the Chief AI Officer role sits above both.
Publication history
- 2026-10-27State Government · Issue 503 resources
Stable resource ID: oregon-odhs-oha-medicaid-work-rules-chatbot-ai-disclosure-card-20260916