NCA-GENL - Trustworthy AI (10% of the exam) - Section 5.1
Develop safe, effective, and scalable generative AI solutions.
Design generative AI solutions that balance capability with safety by applying output filtering, content moderation, and rate limiting alongside scalable serving infrastructure. Recognise the engineering considerations - latency, throughput, cost, and guardrails - that distinguish a prototype from a production-ready generative AI system.
Practice question for this objective
lock_openFree sampleTrustworthy AImedium
An engineering team must raise the throughput of a customer-facing LLM service on a fixed GPU budget without weakening its trustworthiness guarantees. Which measures let them serve more concurrent users while preserving the safety behaviour the service already passes? Select THREE.
ABatch concurrent requests for generation while still running the input and output guardrails on every individual request in the batch.check_circle Correct
BRe-run the model's safety evaluation suite after applying any efficiency change, such as quantisation, before promoting it to production.check_circle Correct
CCache responses only for identical, non-personalised prompts and bypass the cache for any request containing user-specific or sensitive content.check_circle Correct
DDisable the output guardrail during peak load so the safety check stops adding latency when the service is busiest.
EShorten the maximum context window so the model processes fewer tokens, accepting that some retrieved safety context may be truncated.
Scale throughput safely by batching with per-request guardrails, re-testing safety after efficiency changes, and caching only non-personalised prompts. Higher throughput on fixed hardware comes from better utilisation, not from removing controls. Batching and selective caching cut cost while keeping every request screened, and re-running the safety suite after optimisations such as quantisation verifies the cheaper model still upholds the trustworthiness guarantees.
Why A is correct: Batching raises GPU utilisation and throughput, and keeping per-request guardrails means each user is still screened, so efficiency does not bypass safety.
Why B is correct: Efficiency changes can silently degrade safety-critical behaviour, so re-testing the safety suite confirms the optimised model still meets the trustworthiness bar.
Why C is correct: Caching repeated public answers cuts compute, while excluding personalised prompts prevents one user's sensitive output being served to another.
Why D is wrong: Dropping the output filter does cut latency, but it removes protection exactly when traffic and risk are highest, which is when enforcement matters most.
Why E is wrong: A smaller window saves compute, but truncating retrieved grounding or policy context can weaken factual and safety behaviour the service relied on.
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-GENL bank for this domain.
Reward hacking, where the policy exploits a flaw in the reward model to score highly without satisfying the intended objective.
errorWhy it is wrong: Reward hacking is tempting because the model has clearly changed behaviour to chase reward, but reward hacking means gaming a metric loophole for high reward, not becoming broadly over-cautious, so it does not fit.
Hard-code the blocklist and refusal rules into each replica's container image so the safety logic ships immutably with the binary.
errorWhy it is wrong: Baking rules into the image looks safe and reproducible, but a policy change then needs a full rebuild and redeploy, so replicas drift until every one is rebuilt.
Demographic parity, which requires the overall selection rate to be identical across groups regardless of each applicant's qualifications.
errorWhy it is wrong: Demographic parity is a well-known group-fairness metric and is tempting, but it ignores whether applicants are qualified and so does not measure equal selection among qualified applicants specifically.