Software, design and content teams increasingly use AI-assisted tools. A client does not need to prohibit them by default or accept them without scrutiny.

The relevant questions concern outcomes, data, intellectual property, security, quality, accountability and commercial terms. “Do you use AI?” produces a yes or no. It does not explain where the tool enters delivery or which risks the agency still owns.

Treat AI use as part of the supplier’s delivery system.

Ask where and for what purpose

AI may support research, meeting summaries, code completion, test generation, image ideation, content drafting or internal search. These uses have different consequences.

Ask the agency to describe material uses by work type. Focus on tools that process client information, contribute directly to deliverables, make automated decisions or affect assurance.

A supplier should be able to explain the task, the human review, the information involved and the benefit. It need not disclose every minor productivity feature or proprietary method. The contract should define which uses require notification or approval.

Avoid vague labels such as “AI-powered delivery”. Map the real workflow.

Understand what data enters the tool

Determine whether prompts or uploads can include source code, credentials, personal data, client documents, strategy, analytics or confidential communications.

Ask which providers process the information, where processing occurs, whether prompts or outputs are retained, whether they train models, and which account controls are enabled. Consumer and enterprise versions of the same product may have different terms.

The agency should have an approved-tool process, access controls and guidance that prevents staff pasting sensitive information into unapproved services. It should also manage subcontractors and plugins that can receive data.

If personal data is involved, establish roles and instructions under applicable data-protection law. The ICO’s AI and data protection guidance is relevant for UK processing.

Clarify intellectual-property treatment

AI-assisted work raises several IP questions without producing one universal answer.

Ask how the supplier checks that deliverables do not reproduce restricted material, how tool terms affect input and output, and what warranties or indemnities apply. Determine whether client assets may be used to improve internal tools or reusable systems.

The client should know what it will own, what the agency retains, which third-party components are included and what licence obligations follow. This applies to generated code, images, copy and designs.

Do not accept an assurance that AI output is automatically original. Equally, do not assume every assisted deliverable is unusable. The contractual and factual details matter, and legal advice may be needed.

Keep accountability with the supplier

An agency should not use a model error as an explanation that reduces its responsibility.

The supplier remains accountable for meeting the specification, professional standard, security requirements and acceptance criteria. Human review must be performed by people with the competence and time to identify relevant problems.

Ask how AI-assisted code is tested, reviewed and scanned. Ask how factual content is sourced and verified. For design, ask how accessibility, brand accuracy and rights are checked. For data work, ask how bias, drift and exception handling are assessed where relevant.

“Human in the loop” is not a control description. Identify the person, evidence, standard and decision.

Review security and software supply chain

AI coding tools can accelerate useful work and insecure work.

The agency should maintain secure development practices independent of how code was produced: peer review, automated testing, dependency controls, secret scanning, vulnerability management and traceable releases.

Ask whether agents can execute commands, access repositories or deploy environments. Apply least privilege, environment separation and approval controls. Determine what logs are kept and how incidents are investigated.

Generated dependencies and snippets need the same provenance and licence scrutiny as manually selected components.

The client’s security requirements should appear in acceptance and operation, not only a supplier questionnaire.

Discuss quality and maintainability

Faster production does not guarantee a maintainable service.

Ask the agency to show how it prevents duplicated, inconsistent or poorly understood code. Require documentation and tests appropriate to the consequence. Ensure the team can explain important architectural decisions without referring to the tool as the source of authority.

For content, look for generic structure, invented evidence and loss of author voice. For design, look for inaccessible variants and inconsistency with the system. AI can amplify whichever editorial and engineering standards surround it.

Review representative work rather than relying on a policy document.

Make commercial effects visible

AI may reduce effort for some tasks and increase assurance work elsewhere. The value depends on the commercial model.

Under time-based billing, efficiency could reduce hours if scope and quality stay constant. Under fixed price, the supplier may retain the productivity gain while carrying delivery risk. An outcome-based model raises different measurement questions.

There is no automatic rule that every saving belongs to the client. Ask how AI use affects price, schedule, capacity, change and risk. Compare the overall value and responsibilities.

Do not reward unverified speed. A lower estimate should explain which work changed and which assurance remains.

Agree disclosure thresholds

Requiring approval for every assisted sentence or code suggestion is unlikely to be workable. Requiring no disclosure can be unsafe.

Set material thresholds. Notification or approval may be required when a tool processes confidential or personal data, creates a client-facing artefact with limited review, makes or supports consequential decisions, accesses production systems, or introduces unusual IP or supplier dependency.

Require the agency to maintain an internal record sufficient to investigate incidents and explain material outputs. Define how changes in tools or providers are handled during the project.

Put the questions into governance

Include AI use in procurement, contracts, delivery reviews and security assurance.

A concise schedule can cover approved purposes, prohibited data, providers, subprocessors, retention, training use, IP, review, testing, incident reporting, audit evidence and exit. Tailor it to the project rather than copying a universal clause.

Use the NIST AI Risk Management Framework as one source for structuring governance and risk conversations. It does not replace contract, legal, security or technical judgement.

Review the arrangement when scope, data or tools change.

Ask for evidence, then judge the service

A capable agency should be able to describe how AI improves its delivery and how it controls the resulting risks. Openness does not require exposing trade secrets. It requires enough evidence for the client to make an informed decision.

I've written separately about the fragility of digital foundations, and this connects directly. Your CMS, your platform, your custom-built tools - they're only as valuable as your ability to evolve them. If AI-assisted development produces something that works today but creates a maintenance nightmare in eighteen months, you haven't saved money. You've deferred cost and added interest.

Our Fragility of Digital Foundations scorecard is a quick self-assessment that helps you benchmark the health of your platform foundations - worth ten minutes if you're not sure whether the systems you're building on are as solid as you think.

And if you're reading this thinking "I should probably have a conversation with our current agency about this" - yes. You probably should. The partners worth keeping will welcome it. The ones who get defensive are telling you something too.