Alpha
This is a prototype. Answers cite UK public sector AI guidance from incorporated sources.
Guidance map
Curator view of how incorporated sources work together: documented tensions,
unanswered questions, and FAQs where multiple sources agree without contrast.
The Playbook states a categorical rule not to enter unpublished official information into public AI applications. AI Insights emphasises organisation policies and provider reuse of data. Knowledge Hub how-tos add that department policy must be followed, personal/identifiable content should not go into tools, and paid enterprise tools may handle sensitive data under DPAs — creating scope tension across public vs assured tools.
Navigate: Treat the Playbook ban as the baseline for public/unassured tools. For assured departmental tools, follow department guidance and DPAs. Do not assume a public chatbot is covered by enterprise advice.
Playbook(Public AI applications and web services)
— You must not enter official information into public AI applications unless it has been published or is cleared for publication.
AI Insights(Public generative AI applications and web endpoints)
— You must follow your organisation’s policies; free services may use information you provide.
Knowledge Hub(Using AI in government)
— Paid enterprise tools with data protection agreements can often handle personal and sensitive information safely — check departmental guidance.
AI Insights: LLMs Bias states bias in LLMs is fundamentally unavoidable. The Playbook describes bias risks and tells practitioners to consider all sources of bias across the lifecycle, without saying bias cannot be eliminated.
Navigate: Read together: treat inherited bias as expected, not as a one-off filterable defect, and still run continuous bias management across the lifecycle (Playbook) with MLOps gates (Insights).
Playbook(Principle 2: You use AI lawfully, ethically and responsibly)
— Consider all potential sources of bias throughout the development life cycle, including unrepresentative datasets and unfair deployment impacts.
AI Insights(Sources of bias in LLMs)
— Bias in LLMs is fundamentally unavoidable because models learn from human-written text that embeds societal biases.
The Playbook says generative models fundamentally cannot distinguish user prompts from system instructions. AI Insights: Prompt Risks notes most vendor solutions are quite resilient to prompt-leaking style vulnerabilities, while also requiring continuous vigilance and defences that do not rely on secret prompt structure.
Navigate: Do not treat vendor resilience as removing the architectural risk. Assume prompts can subvert instructions, add filtering/logging/HITL, and re-test as models and pipelines change.
Playbook(Prompt injection)
— A generative AI model cannot distinguish between the user prompt and system instructions; attackers can craft prompts that circumvent instructions.
AI Insights(Prompt injection)
— Most vendor solutions are quite resilient to these vulnerabilities, but organisations remain responsible for protection and must not rely on secret prompt positioning.
The Playbook tells organisers to state that third-party meeting transcription tools are not allowed, citing data-leakage risk. Knowledge Hub Using AI at work says ask for consent before using AI to transcribe, summarise, or process a discussion — without restating a categorical ban.
Navigate: Treat the Playbook ban on unassured third-party joiners as the default for risk. Consent is additional, not a substitute. Prefer department-approved transcription where available, and still get participant consent.
Playbook(Embedded AI applications)
— Organisers should verify attendees and state up front that third-party meeting transcription tools are not allowed.
Knowledge Hub(AI content and Freedom of Information)
— Ask for consent from participants before using AI to transcribe, summarise, or process the discussion.
Guidelines for AI procurement (Crown copyright 2020) list routes such as G-Cloud, DOS, Spark DPS, GovTech Catalyst, Innovation Partnerships and the CCS AI DPS. Knowledge Hub Procuring AI (draft) instead organises routes as Exchange schemes, Pro-bono pilot competitions, Competitive Flexible Procedure, Framework call-off and Standard procurement under the Procurement Act 2023 mindset.
Navigate: Use Knowledge Hub Procuring AI for current route framing and legal baseline. Use Guidelines for enduring method (problem statements, data assessment, explainability, evaluation criteria, lifecycle clauses). Confirm live CCS frameworks and commercial advice before choosing a vehicle.
AI procurement(Procurement approach and vehicle)
— Consider frameworks (G-Cloud, DOS, Spark DPS), innovation contests (e.g. GovTech Catalyst), Innovation Partnerships, and the CCS AI Dynamic Purchasing System.
Knowledge Hub(Choose your procurement route)
— Choose among Exchange schemes, Pro-bono pilot competitions, Competitive Flexible Procedure, Framework call-off, or Standard procurement — and still follow the Procurement Act 2023.
The Technology Code of Practice says consider public cloud solutions first under Cloud First policy. The AI Playbook emphasises privately hosted models so organisational data never leaves an environment you own — creating tension for high-sensitivity AI workloads.
Navigate: Start from Cloud First, but choose private or private-cloud patterns when data sensitivity, sovereignty or model-control needs justify it. Document the decision for spend control / assurance.
TCoP(5. Use cloud first)
— Consider using public cloud solutions first as stated in the Cloud First policy.
Playbook(Privately hosted AI models)
— By running a model in your own private cloud infrastructure, you ensure that data never leaves an environment that you own.
The Code of Practice for the Cyber Security of AI is voluntary industry baseline guidance (shall/should within that voluntary frame). Cross-government sources such as the AI Playbook and Service Manual require Secure by Design / consulting security professionals for government services — a different obligation level and audience.
Navigate: For government services, treat Playbook / Service Manual / Secure by Design as the mandatory baseline. Use the AI Cyber Security CoP as detailed supply-chain and lifecycle practice to strengthen that baseline, not as optional opt-out.
AI Cyber CoP(Introduction / Terminology)
— Voluntary code and addendum to the Software Code of Practice; shall indicates a requirement for the voluntary Code.
Service Manual(Involve cyber security professionals)
— You must consult a security professional to make sure users’ data is protected and the service stays secure.
The Service Manual says users do not always need to know what technology is used to access a service, but if AI is used you must explain how it affects their data and outcomes — and chatbots must disclose non-human, possibly inaccurate answers plus a human contact route. This is more specific than Playbook transparency framing and can feel in tension with “users need not know the stack”.
Navigate: Do not hide AI where it affects data or outcomes. For chatbots, follow Service Manual disclosure rules. Use ATRS / Playbook openness for organisational transparency obligations.
Service Manual(Tell users when AI is being used)
— Users do not always need to know what technology is used; however if you use AI you must make clear how it affects data and outcomes; chatbots must disclose non-human answers and how to contact a human.
Playbook(Principle 7 / ATRS and openness)
— Be open with the public about how and where AI systems are being used (including ATRS where required).
The Ethics, Transparency and Accountability Framework for Automated Decision-Making works on a presumption of publication for algorithms that enable ADM, with plain-English explanations (exceptions need legal advice before ministerial authorisation). The Service Manual says users do not always need to know what technology is used to access a service, while still requiring disclosure where AI affects data or outcomes.
Navigate: For ADM, start from presumption of publication and ATRS. For service UX, follow Service Manual disclosure for effects on data/outcomes. Do not hide AI where it affects outcomes.
ADM framework(5. Help users and citizens understand how it impacts them)
— Presumption of publication for algorithms that enable automated decision-making, with plain-English explanations.
Service Manual(Tell users when AI is being used)
— Users do not always need to know what technology is used; if AI is used you must make clear how it affects data and outcomes.
Introduction to AI assurance states all systems using personal data must carry out a DPIA. ICO AI guidance says the vast majority of AI uses are high risk and therefore trigger a DPIA, but you still assess case by case and document how you concluded a use is not high risk.
Navigate: Treat DPIA as the default for AI involving personal data. If you think a use is not high risk, document that assessment carefully and take DPO/legal advice.
AI assurance(5.3 Assuring data, models, systems and governance in practice)
— All systems using personal data must carry out a DPIA.
ICO AI(What do we need to consider when undertaking data protection impact assessments for AI?)
— Vast majority of AI use is high risk and triggers a DPIA; assess case by case and document if you conclude it is not.
The Data and AI Ethics Framework treats publishing DPIA and EIA as good practice. The LGA Responsibly buying AI guide suggests integrating DPIA with EqIA or into an Algorithmic Impact Assessment to streamline, provided all DPIA and PSED requirements are still met.
Navigate: Meet all DPIA and PSED substance either way. Merging documents is fine if nothing required is lost; publishing remains good practice for transparency.
Public generative AI: absolute ban vs organisation policy framing
The Playbook states a categorical rule not to enter unpublished official information into public AI applications. AI Insights emphasises organisation policies and provider reuse of data. Knowledge Hub how-tos add that department policy must be followed, personal/identifiable content should not go into tools, and paid enterprise tools may handle sensitive data under DPAs — creating scope tension across public vs assured tools.
Navigate: Treat the Playbook ban as the baseline for public/unassured tools. For assured departmental tools, follow department guidance and DPAs. Do not assume a public chatbot is covered by enterprise advice.
Playbook(Public AI applications and web services)
— You must not enter official information into public AI applications unless it has been published or is cleared for publication.
AI Insights(Public generative AI applications and web endpoints)
— You must follow your organisation’s policies; free services may use information you provide.
Knowledge Hub(Using AI in government)
— Paid enterprise tools with data protection agreements can often handle personal and sensitive information safely — check departmental guidance.
LLM bias: fundamentally unavoidable vs lifecycle management framing
AI Insights: LLMs Bias states bias in LLMs is fundamentally unavoidable. The Playbook describes bias risks and tells practitioners to consider all sources of bias across the lifecycle, without saying bias cannot be eliminated.
Navigate: Read together: treat inherited bias as expected, not as a one-off filterable defect, and still run continuous bias management across the lifecycle (Playbook) with MLOps gates (Insights).
Playbook(Principle 2: You use AI lawfully, ethically and responsibly)
— Consider all potential sources of bias throughout the development life cycle, including unrepresentative datasets and unfair deployment impacts.
AI Insights(Sources of bias in LLMs)
— Bias in LLMs is fundamentally unavoidable because models learn from human-written text that embeds societal biases.
Prompt injection: architectural inability vs vendor resilience
The Playbook says generative models fundamentally cannot distinguish user prompts from system instructions. AI Insights: Prompt Risks notes most vendor solutions are quite resilient to prompt-leaking style vulnerabilities, while also requiring continuous vigilance and defences that do not rely on secret prompt structure.
Navigate: Do not treat vendor resilience as removing the architectural risk. Assume prompts can subvert instructions, add filtering/logging/HITL, and re-test as models and pipelines change.
Playbook(Prompt injection)
— A generative AI model cannot distinguish between the user prompt and system instructions; attackers can craft prompts that circumvent instructions.
AI Insights(Prompt injection)
— Most vendor solutions are quite resilient to these vulnerabilities, but organisations remain responsible for protection and must not rely on secret prompt positioning.
Meeting transcription: ban third-party tools vs ask for consent
The Playbook tells organisers to state that third-party meeting transcription tools are not allowed, citing data-leakage risk. Knowledge Hub Using AI at work says ask for consent before using AI to transcribe, summarise, or process a discussion — without restating a categorical ban.
Navigate: Treat the Playbook ban on unassured third-party joiners as the default for risk. Consent is additional, not a substitute. Prefer department-approved transcription where available, and still get participant consent.
Playbook(Embedded AI applications)
— Organisers should verify attendees and state up front that third-party meeting transcription tools are not allowed.
Knowledge Hub(AI content and Freedom of Information)
— Ask for consent from participants before using AI to transcribe, summarise, or process the discussion.
AI procurement routes: 2020 Guidelines vs Knowledge Hub how-to
Guidelines for AI procurement (Crown copyright 2020) list routes such as G-Cloud, DOS, Spark DPS, GovTech Catalyst, Innovation Partnerships and the CCS AI DPS. Knowledge Hub Procuring AI (draft) instead organises routes as Exchange schemes, Pro-bono pilot competitions, Competitive Flexible Procedure, Framework call-off and Standard procurement under the Procurement Act 2023 mindset.
Navigate: Use Knowledge Hub Procuring AI for current route framing and legal baseline. Use Guidelines for enduring method (problem statements, data assessment, explainability, evaluation criteria, lifecycle clauses). Confirm live CCS frameworks and commercial advice before choosing a vehicle.
AI procurement(Procurement approach and vehicle)
— Consider frameworks (G-Cloud, DOS, Spark DPS), innovation contests (e.g. GovTech Catalyst), Innovation Partnerships, and the CCS AI Dynamic Purchasing System.
Knowledge Hub(Choose your procurement route)
— Choose among Exchange schemes, Pro-bono pilot competitions, Competitive Flexible Procedure, Framework call-off, or Standard procurement — and still follow the Procurement Act 2023.
Cloud First (TCoP) vs privately hosted AI for data control
The Technology Code of Practice says consider public cloud solutions first under Cloud First policy. The AI Playbook emphasises privately hosted models so organisational data never leaves an environment you own — creating tension for high-sensitivity AI workloads.
Navigate: Start from Cloud First, but choose private or private-cloud patterns when data sensitivity, sovereignty or model-control needs justify it. Document the decision for spend control / assurance.
TCoP(5. Use cloud first)
— Consider using public cloud solutions first as stated in the Cloud First policy.
Playbook(Privately hosted AI models)
— By running a model in your own private cloud infrastructure, you ensure that data never leaves an environment that you own.
Voluntary AI Cyber Security CoP vs mandatory government security practice
The Code of Practice for the Cyber Security of AI is voluntary industry baseline guidance (shall/should within that voluntary frame). Cross-government sources such as the AI Playbook and Service Manual require Secure by Design / consulting security professionals for government services — a different obligation level and audience.
Navigate: For government services, treat Playbook / Service Manual / Secure by Design as the mandatory baseline. Use the AI Cyber Security CoP as detailed supply-chain and lifecycle practice to strengthen that baseline, not as optional opt-out.
AI Cyber CoP(Introduction / Terminology)
— Voluntary code and addendum to the Software Code of Practice; shall indicates a requirement for the voluntary Code.
Service Manual(Involve cyber security professionals)
— You must consult a security professional to make sure users’ data is protected and the service stays secure.
The Service Manual says users do not always need to know what technology is used to access a service, but if AI is used you must explain how it affects their data and outcomes — and chatbots must disclose non-human, possibly inaccurate answers plus a human contact route. This is more specific than Playbook transparency framing and can feel in tension with “users need not know the stack”.
Navigate: Do not hide AI where it affects data or outcomes. For chatbots, follow Service Manual disclosure rules. Use ATRS / Playbook openness for organisational transparency obligations.
Service Manual(Tell users when AI is being used)
— Users do not always need to know what technology is used; however if you use AI you must make clear how it affects data and outcomes; chatbots must disclose non-human answers and how to contact a human.
Playbook(Principle 7 / ATRS and openness)
— Be open with the public about how and where AI systems are being used (including ATRS where required).
ADM presumption of publication vs users need not know the stack
The Ethics, Transparency and Accountability Framework for Automated Decision-Making works on a presumption of publication for algorithms that enable ADM, with plain-English explanations (exceptions need legal advice before ministerial authorisation). The Service Manual says users do not always need to know what technology is used to access a service, while still requiring disclosure where AI affects data or outcomes.
Navigate: For ADM, start from presumption of publication and ATRS. For service UX, follow Service Manual disclosure for effects on data/outcomes. Do not hide AI where it affects outcomes.
ADM framework(5. Help users and citizens understand how it impacts them)
— Presumption of publication for algorithms that enable automated decision-making, with plain-English explanations.
Service Manual(Tell users when AI is being used)
— Users do not always need to know what technology is used; if AI is used you must make clear how it affects data and outcomes.
DPIA for all personal-data AI vs high-risk case-by-case
Introduction to AI assurance states all systems using personal data must carry out a DPIA. ICO AI guidance says the vast majority of AI uses are high risk and therefore trigger a DPIA, but you still assess case by case and document how you concluded a use is not high risk.
Navigate: Treat DPIA as the default for AI involving personal data. If you think a use is not high risk, document that assessment carefully and take DPO/legal advice.
AI assurance(5.3 Assuring data, models, systems and governance in practice)
— All systems using personal data must carry out a DPIA.
ICO AI(What do we need to consider when undertaking data protection impact assessments for AI?)
— Vast majority of AI use is high risk and triggers a DPIA; assess case by case and document if you conclude it is not.
Separate DPIA/EIA publications vs merged assessments
The Data and AI Ethics Framework treats publishing DPIA and EIA as good practice. The LGA Responsibly buying AI guide suggests integrating DPIA with EqIA or into an Algorithmic Impact Assessment to streamline, provided all DPIA and PSED requirements are still met.
Navigate: Meet all DPIA and PSED substance either way. Merging documents is fine if nothing required is lost; publishing remains good practice for transparency.
Data & AI Ethics(Data protection-related transparency / Fairness-related transparency)
— Good practice to publish completed DPIA and EIA.
LGA buying AI(What does data protection law require?)
— Consider integrating DPIA with EqIA or into an AIA if all DPIA and PSED requirements are met.
Gaps
Questions marked as gap or partial — dangerous holes in the body of guidance.
No FAQ items are currently marked gap or partial.
When curators flag unanswered or thinly covered questions that way, they will
appear here as problem areas to fill.
Where guidance aligns
Questions where two or more sources agree without a contrasting mark.
Primary is the how-to source; normative sources state can, must or should.
Alignment is best-effort from FAQ citations (two or more sources on the same
question, none marked contrasting). Conflicts come from the curated conflict
register. Gaps are FAQ items marked gap or partial.