A municipal AI steering committee asks for a prioritized backlog of platform security epics derived from threat-model severity. What planning output meets that request?
Select an answer to reveal the explanation.
Short Explanation
Steering wants a roadmap ordered by how bad the modeled threats are—not cool features, vague sticky notes, or booth size. Severity-tied security epics across years are the deliverable.
Full Explanation
A municipal AI steering committee that asks for a prioritized backlog of platform security epics derived from threat-model severity needs a severity-ordered, multi-year backlog of GenAI platform security epics tied to those findings. Typical epics include tenant isolation, inference telemetry, evaluation and promotion gates, RAG ACL hardening, abuse and prompt-injection monitoring, secrets management for tools, vendor exit/portability, and incident feedback into ERM—each ordered by modeled impact and likelihood, with owners and target horizons. That planning output converts threat modeling into fundable, sequenced work the committee can govern against residual-risk appetite.
A random list of cool chatbot features with no link to threats is a product wishlist, not a security backlog, and will not reduce modeled risk. A single sticky note that says “secure AI somehow” with no owners or dates is not actionable planning and fails any audit of roadmap quality. A backlog sorted only by which vendor offers the largest conference booth prioritizes marketing influence over resident risk and municipal fiduciary duty.
Exam caveat: severity ordering can incorporate dependencies, regulatory deadlines, and quick wins, but traceability from epic to threat-model finding is what steering requested. Pure feature popularity is not a severity method. Operational check: deliver a backlog where each epic references threat-model finding IDs, severity, owner, and planned year or quarter; review it with the steering committee; and adjust order when residual risk or new findings change priorities.