Lifecycle certification for tools that advise users
Certifying a tool by what its output can affect, and holding it to that claim for as long as it runs: monitoring for drift, checking for bias, renewing rather than expiring. A tool that drifts after approval is caught by the monitoring instead of keeping a certification it no longer meets.
The impact of agents
Some of the tools and agents users use give advice that changes their lives: what benefit they are owed, whether a plan will be approved, what their legal rights are. A tool like that needs to be held to its claim not once but for as long as it is in use, because its accuracy can drift as data, rules, and models change.
What must be verified
Government needs assurance that scales with consequence and lasts: certification has to impose ongoing obligations for the higher-consequence tools, and it is treated as a standing commitment rather than a one-time stamp. The tool's operator, or the certifying body overseeing it, must meet those ongoing obligations.
Protecting access
Lifecycle obligations fall hardest on the smallest builders, who have no regulatory-affairs team for continuous monitoring. Duties pitched at the medical-device level are unworkable for volunteer-built civic tools, so builders exit rather than comply. Users who relied on those tools are left without the tool, or without a signal about it.
Keeping the path open
- Scale the obligation to risk: a low-consequence tool should face almost none, and the demanding lifecycle duties are reserved for the high-consequence tools that warrant them.
- Offer small builders shared monitoring infrastructure rather than demanding it of them.
- Make the classification intake work for a builder using a screen reader, or the step that sets every tool's obligations excludes some builders before it even asks a risk question.
Response surface
A tool's obligations are set by what it claims to do and the consequence of getting it wrong, not by whether it contains AI.
What is the tool’s intended purpose?
Your answer sets the certification tier. Whether the tool uses AI does not matter.
Select the tool’s role to see its tier.
Higher tiers keep their obligations after approval. Monitoring on live use continues after launch.
Maturity
- Established
As a medical-device regime.
- Frontier Headline
As a lifecycle-certification model adapted for civic technology, which has no working precedent.
Precedents
FDA AI/ML software as a medical device (US). The FDA's public database lists over 1,250 authorized AI-enabled medical devices, up from 950 the year before. Draft guidance recommends lifecycle management covering post-market performance monitoring, algorithmic bias assessment, and transparency. A rule incorporating ISO 13485 by reference replaced the earlier quality-system regulation.
FDA premarket cybersecurity guidance. The guidance sets a secure-by-design objective, defining a device 'designed from the outset to be secure within its system and/or network of use throughout the device lifecycle', and expects a software bill of materials. Security is assessed as part of premarket review, and not as a separate compliance exercise afterward.
TGA AI and medical device software (Australia). The Therapeutic Goods Administration published its final report on AI in healthcare and followed it with guidance on when AI-based software as a medical device is regulated. The framework is technology-agnostic and risk-based: regulation is triggered by the manufacturer's intended purpose, and not by the presence of AI features.
What carries over to agent use
High for principles; moderate for direct adoption. Transferable principles: risk-proportionate classification (not all tools need the same scrutiny); lifecycle management (certification is ongoing, not one-time); intended-purpose triggers (regulate by what the tool claims to do, not the technology it uses); SBOM and "secure by design" as baseline. The TGA's technology-agnostic, risk-based approach is especially relevant: it avoids regulating "AI" as a category and focuses on the consequences of outputs.
The main limitation is scale. Medical device certification is resource-intensive and assumes a commercial manufacturer with regulatory-affairs capacity, which volunteer-built civic tools cannot match.
Where things go wrong
A medical-device-style regime would classify an automated decision tool as high-consequence and require lifecycle monitoring and accuracy validation against reference data, exactly the scrutiny a high-stakes calculation often never receives. A tool can game the classification by understating its own intended purpose, describing a benefits calculator as merely informational to stay in a lower tier and dodge the lifecycle monitoring a decision-support classification would trigger. Catching that means checking what the tool does against its declared purpose, not taking the declaration at its word.
Sources
5 references
The instrument, the operating deployment, or the official record itself.
- FDA AI/ML Software as a Medical Device
- FDA — Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (3 February 2026)
- TGA AI and Medical Device Software
- TGA consultation report — clarifying and strengthening regulation of medical device software including AI
Writing about the subject rather than the framework itself, including vendor commentary.