The beautiful tip of the iceberg
Most of what we build you'll never see. This is the part you can.
- Below the surfaceSaaS platforms, cloud systems and the engineering businesses run on.
- Above itA small glimpse of our UI/UX craft — ten real product interfaces.
AI-Assisted Development
How we use AI engineering tools — the productivity without the risk, under the same controls as all our development.
At a glance
| Do you use AI tools in development, and is our data protected? | Yes Approved tools only, under commercial terms that do not permit training on your material; secrets and client personal data never enter prompts without agreement |
| Is AI-generated code reviewed before it reaches us? | Yes Every AI-assisted change is reviewed by a named engineer before merge — the same gate as all our code |
| Can we restrict or exclude AI-assisted development on our engagement? | Yes A written opt-out or restriction is agreed in the engagement terms and honoured in practice |
Our position
AI-assisted engineering tools are part of how modern software is built, and Assemblysoft uses them deliberately — as an accelerant inside our existing engineering controls, never as a substitute for them. Accountability is never delegated to a tool: a named Assemblysoft engineer directs the work, reviews and understands the code, tests it, and stands behind it professionally. AI output is treated as a first draft from a capable but fallible assistant, reviewed with the same scepticism as any unreviewed code.
This page summarises our AI-Assisted Development Policy, which sits alongside our Secure Development & Change Management statement. The full policy is part of our compliance pack, available on request.
Approved tools only
AI development tools are used only from an approved set, assessed before first use against a written bar:
- Terms we have read — the service tier in use must be under commercial terms that do not grant the provider the right to train generative models on our inputs or our clients' material, re-checked at annual review.
- Provider standing — an established provider with a published security and privacy posture, assessed under our Third-Party Supplier Management process and recorded in our supplier register.
- Account control — company-controlled accounts with multi-factor authentication, on devices within our Cyber Essentials certification scope.
Our current approved tooling is Anthropic's Claude (including Claude Code) and Microsoft Copilot (including GitHub Copilot in our development tooling), each used on the commercial tier whose terms exclude our inputs from model training. Any other tool requires approval against the same criteria before any use.
What never enters a prompt
An AI tool is a third-party service: anything placed in a prompt leaves our environment. So:
- Secrets and credentials never enter prompts — connection strings, keys, and tokens live in Azure Key Vault, just as they never enter source control.
- Client personal data is not submitted to AI tools without the client's agreement. Development and test use synthetic or anonymised data by default, so on most engagements there is no client personal data on our systems to submit in the first place.
- Client source code and project material is shared only with an approved tool, within the engagement's confidentiality obligations, and limited to what the task needs.
- Where a solution we build deliberately processes personal data through an AI service, the provider is engaged as a documented sub-processor — agreed with the client in writing, with UK GDPR Article 28 obligations flowed down and the provider recorded in our sub-processor register.
Human review, same gates
- Same lifecycle, no exceptions — AI-assisted changes are made on branches and merged via pull requests, reviewed by an engineer before merge, exactly as all our code is.
- Review for understanding — the responsible engineer must be able to explain what the code does and why it is correct. Code nobody on the team understands is not merged, whoever or whatever wrote it.
- Tested before release, with secure-coding practice (OWASP awareness, input validation, secure defaults) checked in review rather than assumed from the suggestion.
- Dependency provenance — packages suggested by an AI tool are verified before adoption: genuinely on the official registry, reputable and maintained, with a compatible licence. This guards against hallucinated or typo-squatted package names.
Agentic tools & least privilege
Where AI tools act as agents — running commands and editing files rather than just suggesting text — they operate supervised, with permission controls enabled, on devices within our Cyber Essentials scope. Agents are given no production credentials and no standing access to client environments, and prompt injection is treated as a real attack surface: where an agent reads untrusted content, its output and actions are reviewed with that in mind before they take effect anywhere that matters.
Your IP, your choice
- Intellectual property in deliverables is governed by your engagement terms, not by the tooling — our use of AI tools does not grant any third party rights over your deliverables. See Data Ownership & Portability.
- Licence hygiene — review includes watching for substantial verbatim reproduction of identifiable third-party code; where provenance is in doubt, the code is rewritten or the source identified and its licence honoured.
- A written opt-out is yours to take — you may restrict or exclude AI-assisted development for your engagement. Any restriction is agreed in writing as part of the engagement terms and honoured for all work on that engagement.
The full policy
The complete AI-Assisted Development Policy — including the risks-and-controls summary our assessors use — is part of our compliance document pack, provided to customers and prospective customers on request. Contact hello@assemblysoft.com.
Start a meaningful conversation with us today.
Assemblysoft are Your Safe Pair of Hands
Azure
Azure DevOps
