AI-Augmented Development for Public Sector and GDS

This guide is a public-sector spoke of the AI-augmented development pillar guide. It is written for GDS-fluent delivery leads, public-sector CTOs, procurement category managers, and Crown Commercial Service framework suppliers. The Service Standard, Technology Code of Practice, and GOV.UK Design System are the reference points throughout.

It builds on two existing guides. Using AI to meet the GDS Service Standard covers the encoding of Service Standard principles into agent rules and skills. GDS Service Standard for private sector covers private-sector adoption of the same principles. This guide is the buyer-facing summary that links them together.

How does AI-augmented delivery map to the GDS Service Standard?

The GDS Service Standard is 14 principles, written to be applied across the service lifecycle. It is principles-based, not a tick-box checklist, and it is silent on tooling. AI-augmented delivery is consistent with the Standard when the practice keeps users at the centre and the team multidisciplinary.

Five points gain measurably from AI:

• Point 5 (Make sure everyone can use the service). Automated accessibility checks in CI, agent rules requiring Design System component references, and pull-request linting against WCAG 2.2 AA. AI accelerates the evidence without softening the standard.
• Point 8 (Iterate and improve frequently). Pull-request-size rules, rollback runbook generation, and shorter feedback cycles. Smaller, more frequent changes are easier to roll back.
• Point 9 (Create a secure service). Secret-scan rules, licence-scan rules, agent rules requiring authentication patterns. ISO 27001 and Cyber Essentials Plus controls are easier to evidence when the rules are encoded.
• Point 13 (Use and contribute to open standards, common components and patterns). Rules that require a GOV.UK Design System reference on every UI change, or a documented exception. Skills that scaffold Design System forms, error summaries, and validation patterns.
• Point 14 (Operate a reliable service). Runbook-generation skills, structured-log rules, agent triage of alerts. The operate phase becomes evidence-rich rather than memory-led.

Two points are partially supported:

• Point 1 (Understand users and their needs). AI helps with transcription, story drafting, and synthesis. The research itself, including the trust and judgement parts, stays human-led.
• Point 4 (Use the agile way of working). AI tooling does not change the practice. The artefacts (sprint plans, retros, demos) become richer.

Seven points are largely unchanged:

• Point 2 (Solve a whole problem for users). Service design, journey mapping, and prototype testing remain human work.
• Point 3 (Provide a joined-up experience across all channels). Service architecture and channel integration. Engineering judgement.
• Point 6 (Have a multidisciplinary team). Team composition is a leadership decision, not a tooling one.
• Point 7 (Use agile ways of working). Practice, not tools.
• Point 10 (Define what success looks like and publish performance data). Performance frameworks are policy and leadership decisions.
• Point 11 (Choose the right tools and technology). Tool choice is a judgement supported by Architecture Decision Records. AI helps draft them; humans choose.
• Point 12 (Make new source code open). Open sourcing decision is a policy one.

The pattern is clear. AI accelerates the artefacts and evidence around the Service Standard. It does not substitute for the human practices that the Standard exists to encode.

Which Service Standard points does AI not help with?

The Service Standard exists because some practices cannot be automated away. AI does not change this list.

• User research. AI transcribes interviews, drafts user stories, and synthesises notes. It does not interview users, build trust, or read the room.
• Service assessment. AI does not sit on a panel. A senior delivery lead does.
• Multidisciplinary team formation. AI cannot resolve a missing designer or a missing researcher.
• Stakeholder negotiation. Cross-departmental delivery, especially in government, requires human authority. AI drafts the brief.
• Incident communication. When a service is degraded, communications with affected users are human, signed, and accountable.

A delivery plan that pretends otherwise is the most common risk pattern in AI-augmented public-sector work. Senior team time should concentrate here, not on the artefact work AI already accelerates.

What does the Technology Code of Practice say about AI?

The Technology Code of Practice (TCoP) is the central-government standard for technology in the public sector. It is consistent with the Service Standard and overlaps in several places. The 12 TCoP points cover user needs, accessibility, open standards, security, sustainability, common platforms, integration, business continuity, lifecycle, AI governance, and value for money.

For AI-augmented suppliers, the most direct touchpoints are:

• Make things accessible and inclusive. AI tooling that automates accessibility checks supports this.
• Be open and use open source. Open standards rules in the repository, plus disclosure of AI tool usage.
• Make use of common platforms. GOV.UK Design System, the cross-government Notify and Pay platforms.
• Integrate and adapt technology. Reflects the integration-heavy nature of public-sector delivery.
• Make better use of data. Data residency and AI training-data exclusion in supplier contracts.

The TCoP has a dedicated point on AI governance. Suppliers should be able to articulate which AI tools they use, on what licence tier, with which data classes, and how the outputs are governed. The risks of AI-augmented development guide covers the controls underpinning this.

How does the EU AI Act apply to UK public-sector projects?

The EU AI Act (Regulation EU 2024/1689) applies to public-sector services with EU exposure. Brexit does not create an exemption.

Most UK public-sector services are not high-risk under Annex III. The high-risk public-sector use cases are specific:

• Critical infrastructure (energy, transport, water).
• Employment and worker management (where the public body acts as employer).
• Access to essential services (some benefits and migration determinations).
• Law enforcement (predictive policing, evidence assessment).
• Migration, asylum, and border control.
• Administration of justice.
• Democratic processes.

For services in these categories, the Act’s obligations are substantial. The provider (the body placing the system on the market) carries the heavier obligations: risk management, dataset governance, logging, human oversight, accuracy and robustness, transparency, post-market monitoring. The deployer (the body operating the system) has lighter duties but must run a fundamental rights impact assessment in some contexts.

For most other public-sector services, the obligations are limited to transparency (where AI interaction is not obvious to users) and AI literacy for the team. The 2 August 2026 high-risk milestone is the date by which most high-risk obligations become enforceable under the current legal timetable.

The EU AI Act guide covers the provider versus deployer distinction in detail and includes the contract clauses that allocate responsibilities cleanly.

What about G-Cloud and the Crown Commercial Service?

The G-Cloud framework lists suppliers across IaaS, PaaS, SaaS, and specialist cloud services. Talk Think Do is listed on the framework. The framework’s requirements are well-understood: ISO 27001, Cyber Essentials Plus, clear service definitions, transparent pricing.

The framework does not require AI-specific certifications in 2026. Buyers running mini-competitions inside the framework increasingly ask AI questions in their specification:

• Which AI tools does the supplier use?
• How is AI-generated code reviewed and attributed?
• What data classes pass through the AI tools, and where are they processed?
• How does the supplier handle the EU AI Act provider versus deployer question?
• What is the supplier’s approach to user research (where AI does not substitute)?

Suppliers whose responses are vague on these points consistently score badly. Suppliers who can produce concrete evidence (agent rules, skills, attribution metadata, ISO 27001 scope statements covering AI tools) consistently score well. The asymmetry will widen as the framework iteration cycle continues.

What should a public-sector buyer ask an AI-augmented supplier?

Seven questions, taken from current procurement panels we have advised on:

1. Ask to see the supplier’s agent rules and skills repository. Not a slide. The actual files.
2. Ask which of their rules map to which Service Standard points. A real practice has done this mapping.
3. Ask who reviews and updates the rulepack, and how often. A real practice has an owner and a cadence.
4. Ask how they prevent AI-generated code from bypassing the rules. CI status checks, not goodwill.
5. Ask how they handle user research. AI does not substitute. A supplier who claims otherwise is the warning sign.
6. Ask for a sample evidence pack from a recent delivery. Rules, a completed pull request, a senior review record.
7. Ask which tools they have dropped. A supplier with a real practice has stopped using tools that did not work.

A supplier who can answer these clearly is an AI advantage. A supplier who cannot is an AI risk.

How is AI-generated code attributed for an assessment panel?

Assessment panels do not need to see every line of AI-generated code. They need to see that the practice is structural, the gates work, and the evidence is reconstructible.

The artefacts a clean evidence pack contains:

• Agent rules. Repository files showing the standards encoded into AI context.
• Skill definitions. Reusable workflows for recurring tasks.
• Pull request samples. A handful of recent merged pull requests showing AI contribution and senior engineer review.
• CI configuration. The status checks that gate AI output.
• Attribution metadata. Commit and pull request fields recording AI tool, model, and reviewer.
• ISO 27001 scope statement. Showing AI tools are inside the ISMS.

The AI Code Attribution and Procurement guide covers this in depth, including the CycloneDX and SPDX 3.0 SBOM extensions that carry AI provenance.

Where to start

Three steps for a public-sector buyer or supplier:

1. Read the existing GDS Service Standard guides. Using AI to meet the GDS Service Standard for the encoding detail. GDS Service Standard for private sector for the cross-sector view.
2. Map your own programme against the Service Standard points. Identify which points AI accelerates and which require senior human time.
3. Update procurement specifications. Add the seven questions above to your standard mini-competition template.

For the broader context, the AI-augmented development pillar guide sets out the definition. The risks of AI-augmented development guide covers the governance picture.

Book a consultation to talk through your specific programme, or explore our Enterprise Software Development service for mission-critical and compliance-led engagements, and our AI Development and Implementation service for AI components.