A municipal developer treats an LLM API as a trusted database of parcel facts for fee calculations. What misconception should platform security correct?
Select an answer to reveal the explanation.
Short Explanation
An LLM is a really fluent guesser, not the county parcel database with ACID guarantees. Wiring fee math to model prose is how you invent tax bills. Pull authoritative facts from systems of record; let the model explain, not own, the numbers.
Full Explanation
LLMs are generative predictors that produce likely token sequences; they are not authoritative structured databases of parcel facts for fee calculations. Treating an LLM API as a trusted system of record for municipal fees invites hallucination, silent drift, and non-reproducible amounts. Platform security must correct that misconception: parcel attributes and fee schedules belong in governed data stores, with the LLM—if used at all—limited to explanation or UI assistance around verified values.
Claiming LLMs cannot be called over HTTPS from city networks is false; municipal apps routinely call LLM APIs over TLS. Saying LLMs only return binary yes/no answers ignores their free-text generative nature. Requiring physical serial consoles inside the data center confuses out-of-band server administration with how cloud or data-center model APIs are consumed.
Exam caveat: tool-calling architectures that force the model to query a parcel database can be safe if the numeric fee is taken from the tool result, not from free generation. The anti-pattern is trusting unconstrained generated numbers. Also distinguish deterministic code calculating fees from an LLM "estimating" fees in prose.
Operational check: bind fee calculation to authoritative services; validate schemas; prohibit generative amounts in financial paths; add regression tests comparing bot-stated fees to the fee engine; and audit prompts for parcel-PII minimization. Developers should treat LLM outputs as untrusted until verified against municipal systems of record.