A transit agency plans to host an agentic system on GKE integrated with sensitive SCADA controls for rail signaling, and infrastructure policy requires that no scenario training or inference data leave agency-owned infrastructure. Which consideration most directly narrows which language models the architect can even evaluate for this agent?
Select an answer to reveal the explanation.
Short Explanation
Think of self-hosting requirements like needing a car you can actually pop the hood on: a SaaS-only model is more like a rental you can drive but never service yourself. When data can't leave the building, the agency needs a model it can deploy on its own infrastructure - that's an open-source, self-hostable model, not a proprietary SaaS API. Everything else - prompting style, fine-tuning, console integration - is a nice-to-have layered on top of that first filter.
Full Explanation
Self-hosting requirements act as a gate, not a preference: when a data-residency or infrastructure policy says agent workloads and their data cannot leave agency-owned infrastructure, that policy eliminates every SaaS-only proprietary model before cost, accuracy, or fine-tuning ever enter the conversation. An open-source model that can be packaged as a container and run on GKE is the only category of candidate that satisfies the constraint, because only that category can be deployed and served entirely inside the agency's own environment. Few-shot prompting support describes how a model is instructed, not where it runs, so it says nothing about deployment location. A model fine-tuned for transit scheduling might be an excellent fit on capability grounds, but if it's SaaS-only it still fails the residency requirement regardless of how well it performs. Low-code console integration with Gemini Enterprise describes a build-time convenience for configuring agent behavior, not an infrastructure-hosting property, and conflating the two mixes up the low-code tooling layer with the model-deployment layer. The scope caveat: self-hosting shifts operational burden - patching, scaling, GPU capacity - onto the agency, so the architect should confirm the team can actually operate that infrastructure before committing. A concrete check: review the model's license and deployment artifacts to confirm it can be containerized and served on GKE without a SaaS dependency for inference calls.