A county benefits bot uses multi-tenant SaaS LLM features without reviewing tenant data isolation guarantees. What should architecture evaluation demand?
Select an answer to reveal the explanation.
Short Explanation
Multi-tenant SaaS is a shared apartment building — ask for the locks between units before you move benefits case files in. Demand isolation evidence and contracts, not hopeful marketing slides. One citywide API key is the opposite of separation.
Full Explanation
Multi-tenant SaaS LLM features may process many customers on shared infrastructure, so a county benefits bot must evaluate tenant isolation guarantees before placing resident benefits data on the platform. Architecture evaluation should demand evidence of tenant isolation, data-path separation (including logs, fine-tuning opt-outs, embeddings stores, and subprocessors), and contractual controls that match municipal privacy and records expectations. Trust is earned through technical artifacts and enforceable terms, not marketing claims about "enterprise AI."
Assuming all SaaS GenAI vendors isolate tenants perfectly by default fails due diligence and ignores shared-fate and noisy-neighbor risks on multi-tenant platforms. Disabling encryption so cross-tenant debugging is easier directly undermines confidentiality of eligibility and benefits content. Sharing one API key across all county agencies to simplify billing collapses accountability, complicates revocation, and expands blast radius if that single key leaks.
Exam caveat: contractual "will not train on your data" clauses and technical isolation are related but distinct—verify both before benefits workloads go live. Operational check: collect vendor isolation whitepapers, SOC reports, and DPAs; confirm benefits data paths and retention; issue agency-scoped keys; and reject platforms that cannot evidence separation for sensitive eligibility content.