Utah has permitted Nolla Health to begin a pilot in which an AI system can assess acne, review a facial image and issue prescriptions for a limited set of topical treatments. The important shift is not that software can identify a skin condition. It is that a regulated workflow is moving from “AI recommends” toward “AI acts,” with human oversight changing by stage.
In practical terms, the product combines computer vision for facial assessment with natural language processing for patient intake. That makes this news relevant beyond healthcare. It is a case study in how founders can automate decisions that affect health, money, access or safety without treating the model as the whole product.
The central question is simple: can the surrounding system contain errors, document decisions and escalate cases it should not handle?
What Utah’s pilot changes about AI prescribing
According to the SiliconANGLE report, a patient using Nolla Derm completes an intake, describes the condition, uploads a facial scan and receives a treatment decision from a physician-approved shortlist of topical acne medicines. Prescriptions may be collected at a local pharmacy or delivered, while progress is monitored through recurring skin scans.
The system is not permitted to prescribe every acne treatment. The reported pilot excludes isotretinoin and oral medications, and requests outside its defined limits are sent to a licensed physician. That restriction is not a minor product detail. It is the mechanism that makes the decision space narrow enough to test.
The pilot is structured in three stages. Initially, two physicians review every AI-generated prescription. After at least 100 patients, and if serious problems do not emerge, the next stage may allow the system to issue prescriptions directly while physicians review decisions afterward. That stage is planned to cover 500 patients. A later stage would involve physician review of at least 10% of automated prescriptions each month.
Figures mentioned are indicative of the pilot design reported by SiliconANGLE and may change depending on eligibility, assessment, pilot progress and regulatory conditions.
The product is not merely an AI doctor. It is a permission system whose authority expands only when the workflow produces evidence.
Why the hard problem is permission design, not model quality
Many teams approach automation as a model-quality exercise: improve the benchmark, reduce latency and ship a polished interface. In a high-consequence workflow, the harder product decision is permission design.
What may the system decide? What must it reject? Which signals trigger review? What evidence is retained when a patient, clinician or regulator challenges the decision? Those questions determine whether automation is deployable.
The pattern is familiar from banking. Automated teller machines did not make banking safe merely by digitising a teller interaction. They worked because transactions were constrained by account rules, fraud checks, authentication and exception handling. Routine activity followed one path; unusual activity moved to another.
Nolla’s acne pilot follows the same logic. Facial assessment is only one input. The intake process, treatment shortlist, exclusion rules, pharmacy handoff, monitoring process and physician escalation path determine the system’s actual risk profile.
The effect chain for founders is direct:
- A bounded decision becomes easier to automate when inputs, treatments and exclusions are explicit.
- Once the decision moves into software, monitoring, audit trails and exception handling become core product capabilities.
- As more routine decisions become software-mediated, control layers may become as valuable as the underlying model.
The overlooked opportunity is therefore not to build a general-purpose digital doctor. It is to build the machinery that makes a narrow automated decision reviewable, reversible and accountable.
A practical framework for high-consequence automation
Before automating a decision that affects health, money, safety or access, use this checklist:
- Define the decision boundary: document exactly what the system can decide and what it must reject or escalate.
- Constrain the action space: select from an approved set of treatments, products or outcomes rather than allowing unrestricted generation.
- Stage permissions: start with review before action. Consider post-decision review only after collecting evidence that is relevant to the specific workflow.
- Measure failure modes: track unsuitable approvals, unnecessary escalations, incomplete inputs, manipulated submissions and performance changes across user groups.
- Preserve an audit trail: record the inputs, model version, rules applied, decision and reviewer response.
- Design the handoff: escalation needs clear ownership, response expectations and a way to resolve the case.
A common mistake is defining success as agreement with historical clinician decisions. Historical decisions can contain inconsistency, missing context or bias. A stronger evaluation asks whether the full workflow catches unsuitable cases, produces acceptable outcomes and gives a human enough information to intervene.
Another mistake is treating a sandbox as market endorsement. The report says Nolla’s pilot is being conducted through Utah’s AI Learning Lab sandbox. The state’s published pilot language says participation does not mean the state has approved, certified or vouched for the product. Permission to test is not evidence that the product works at scale.
What technical teams should build around the model
The next layer is operational rather than theatrical. A serious system needs versioned clinical rules, structured intake, image-quality checks, monitoring for distribution shifts and a reliable review queue. It should also be tested against misleading inputs, not only clean examples.
Prompt engineering may help make model instructions more consistent, but prompts should not carry the most consequential constraints. Hard validation rules, treatment allowlists and escalation logic should enforce the boundaries.
Teams evaluating ai agents should distinguish between generating information and taking an external action. An agent that drafts a recommendation has a different risk profile from one that issues a prescription, changes a record or places an order.
What is penetration testing in an AI workflow?
Penetration testing is a structured attempt to find security and abuse weaknesses before launch. For a workflow like this, testing should include prompt injection, manipulated images, identity misuse, incomplete medical histories and attempts to push the system beyond its approved treatment scope.
Reinforcement learning can be relevant when systems improve through feedback, but feedback is not automatically safe. In a patient-facing workflow, outcome data needs careful review before it influences future decisions. Learning from unreviewed or poorly labelled outcomes could reinforce the wrong behaviour.
Looking for “ci cd pipeline”? The relevant answer is a controlled release process for models, rules and clinical content. Every change should be versioned, tested, approved and reversible, because a small configuration update can alter the behaviour of the entire decision workflow.
For more practical analysis on AI systems, product decisions and automation, explore the Yanisa Execution blog. The same discipline applies beyond healthcare: automate the repeatable path, preserve an exception path and make every consequential action explainable after the fact.
What founders should take from the Nolla Health pilot
Utah’s Nolla pilot matters because it tests a business model as much as a technology. A narrow service may reduce friction for some patients, but it also creates obligations around clinical boundaries, evidence, privacy, monitoring and human accountability. Those obligations do not disappear when a model performs well.
Founders should copy the structure, not the surface. Start with a decision that is narrow, observable and reversible. Define prohibited cases before designing the user experience. Establish the evidence plan before expanding the action set. Then treat every increase in system authority as a product decision that requires new monitoring and review.
The next generation of regulated software will not be won by models alone. It will be won by teams that know when software may act, when it must stop and how the organisation can prove the difference.
If you are assessing an automation opportunity, compare the decision boundary, evidence plan and escalation design before comparing model features. You can also speak with the Yanisa Execution team about structuring that assessment for your product.
Frequently Asked Questions
What did Utah allow Nolla Health to do?
Utah allowed Nolla Health to run a pilot in which an AI system can assess acne and issue prescriptions for a limited set of topical treatments. The pilot includes defined exclusions and staged physician oversight.
Can Nolla Health’s AI prescribe any acne medication?
No. The reported pilot limits the system to physician-approved topical treatments and excludes isotretinoin and oral medications. Cases outside the defined boundaries are referred to a licensed physician.
Does Utah’s AI sandbox mean Nolla Health is government-approved?
No. The published sandbox language says participation does not mean the state has approved, certified or endorsed the product. It is permission to test under specified conditions, not a general product endorsement.
Why was acne chosen for an AI prescription pilot?
Acne can be assessed remotely in some cases, and the pilot can constrain treatment choices while excluding higher-risk medications. That makes it a narrower test case than conditions requiring complex diagnosis or high-risk treatment.
What should founders learn from the Nolla Health pilot?
Founders should define strict decision boundaries, use staged permissions, measure failure modes and preserve a clear human escalation path. A successful pilot in one narrow workflow would not automatically justify expansion to other medical conditions.