Most suppliers now use these tools in some form, so asking whether your agency uses AI no longer separates anybody. A supplier who says they do not should be able to explain why, and some have client, sector or confidentiality reasons that are entirely legitimate.
The questions that do separate suppliers are narrower and more useful. Where does your code go. Who reviews what comes back. And does anything about their accountability change because a tool was involved.
We are a supplier writing about supplier behaviour, so this article is deliberately structured as questions you can put to anyone, including us. Two siblings cover the neighbouring ground: whether these tools can replace an agency, and what fast-built software costs later.
The question is the plan, not the tool
Vendor terms differ substantially between consumer and business tiers of the same product, so the plan a supplier is on matters more than which tool they chose.
Vendor terms differ substantially between consumer and business tiers of the same product [1][2][3]. Whether inputs are used for training, how long data is retained, and what indemnities apply can all differ between plans that share a product name. A claim that is entirely true of an enterprise tier can be false of a free one.
So "which tools do you use" is close to a useless question. "Which tools, on which plan" is the one that carries information, and it is specific enough that a supplier either knows the answer or reveals that individual developers chose their own tooling.
That second outcome is not rare and it is not necessarily disqualifying. It is worth knowing before you sign rather than after.
Confidentiality, and where your code actually goes
Ask directly: does our code leave your environment, and if so, where does it go and under what terms.
The answers you want are specific. Which tools. Which tier. Whether code is submitted to a third party at all. What the vendor's terms say about training and retention under that specific plan. And what is excluded, because good answers often include limits, such as certain client work never going through certain tools.
The signal is specificity and stated limits. Reassurance is not a signal. "We are careful with client code" is not checkable, and neither is "we only use it for boilerplate" unless the supplier can say how that boundary is enforced.
Get the answer in writing rather than in a meeting. Not because a meeting answer is dishonest, but because the person in the room may not be the person who chose the tooling, and a written reply tends to get checked internally before it is sent.
Intellectual property, where the ground is genuinely moving
Ownership and infringement risk are two different questions that get conflated constantly.
The first is ownership, and your position should come from your contract rather than from a theory about tooling. UAE law requires a written assignment with specific particulars for rights to transfer, which our code ownership guide sets out in detail. That requirement does not change because a tool was involved. What you want is an assignment covering all delivered work however it was produced, drafted by a lawyer.
The second is the risk of generated code reproducing licensed material. Some vendors publish indemnity commitments for their business tiers covering claims of that kind [1][2]. The existence of those commitments tells you the vendors consider the risk real enough to insure against, which is itself informative.
Now the caveat that matters more than the commitments. The conditions attached to them change. We found one major vendor's consumer-facing material describing a condition that the same company's enterprise documentation indicates was removed earlier in 2026 [1]. We are not naming a single permanent condition for anybody's indemnity, because the honest position is that these terms move and a summary written today may be wrong next quarter.
The practical conclusion: ask your supplier to confirm the current position in writing, at the time you engage them, rather than relying on any article including this one.
One more thing worth being clear about, because it is misunderstood. A vendor indemnity runs between the vendor and their customer, which is your supplier, not you. Your protection comes from your contract with your supplier. Treat a vendor indemnity as useful context about their exposure rather than as cover for yours.
Review, and what the word should mean
Vendor documentation itself states that output requires human review [1][2][3], which is a helpful thing to be able to point at in a supplier conversation.
The question to ask is who reviews, against what, and whether anything ships without a named person having read it.
There is a harder version of this question that is worth asking anyway. A reviewer who could not have written the code is not really reviewing it. They are approving it, and those look identical in a workflow while catching entirely different things. So ask what level of person does the reviewing, and be a little sceptical of an answer that describes a process without describing a person.
Automated checks are worth having and they are not a substitute. If generated code is reviewed by a generated reviewer, there is no person who understood the decision, which matters at the point you need to explain a failure to a customer, a bank, or a regulator.
Accountability, which should not move at all
Here is the position we would suggest you hold firmly: a supplier is accountable for what they deliver, regardless of how it was produced.
That means their warranty should apply identically to AI-assisted work. If a supplier proposes a carve-out for it, they are moving a risk they chose to take onto you, and that is a fair thing to question directly. Ask: does your warranty apply the same way to code produced with these tools?
Three things worth having in the contract, described as things to look for rather than as wording, because drafting belongs with a qualified UAE lawyer:
- The supplier warrants the work regardless of how it was produced
- IP assignment covers all delivered code, however generated
- Confidentiality obligations extend to any tools they use with your material
And one more, easy to miss: ask whether those obligations flow through to subcontractors. A subcontractor working on a consumer plan can quietly undo whatever arrangement your supplier has made, and your supplier should be able to answer for anyone they engage.
Data protection, stated the same way we always state it
If your product handles personal data and real data is used during development, this is engaged.
The general consent principle in the UAE data protection law applies to processing regardless of which tool performs it [4]. Our PDPL guide sets out our position carefully, including the parts we could not confirm, and we are not adding anything to it here. No notification deadline, no penalty figure, no expanded rights list, because none of those are established on the sources we could verify.
What we would say practically, independent of any legal question: development and testing should use synthetic or anonymised data wherever possible. That is good practice regardless of tooling, and the AI dimension simply sharpens it, because submitting real personal data to a third-party service is a processing decision that should never be made casually mid-task by whoever happens to be working on it.
A pattern we see. A supplier has a sensible policy at company level. An individual developer, working late on something awkward, pastes a chunk of real data into a tool on their personal account to get unstuck. Nobody is being reckless, and the policy was never designed to survive that moment. This is why the useful question is not what the policy says but how it is enforced when somebody is stuck.
What good governance looks like from the outside
Five observable things separate a supplier with a real process from one improvising: they can name the tier, they have a stated exclusion, two different people give the same answer, they volunteer a limitation, and they already have it written down.
They can name the tier, not just the tool. This is the single strongest signal, because it means somebody made a purchasing decision rather than each developer signing up individually.
They have a stated exclusion. Something like certain categories of client work never passing through certain tools. Exclusions require somebody to have thought about edges, and a process with no exclusions has usually not been designed.
The answer is the same from two different people. Ask your account contact and, separately, whoever is actually writing the code. Matching answers indicate a policy. Divergent ones indicate a preference held by one person.
They volunteer a limitation. A supplier who tells you unprompted where their process is weaker is describing something real. Uniformly reassuring answers describe a sales position.
They already have it written down. If a supplier can send you an existing document rather than composing one in reply to your email, the practice predates your asking, which is the point.
None of that is proof, and it is not meant to be. It is the difference between a supplier who has decided how they work and one who will decide when something goes wrong.
On price, where we will not give you a number
You may be told that AI tooling has reduced development costs by a specific percentage. We are not repeating any such figure, because no credible source publishes one and every version we traced came from a vendor or a self-selected survey. We would also note, for consistency, that we have made a version of that claim ourselves in an older article without a source behind it, and we are not treating our own unsourced claim as evidence.
What is worth asking a supplier is more specific: what got cheaper. Where savings occur they tend to sit in execution rather than in judgement, and judgement was always the expensive half.
Also worth accepting: a supplier delivering faster at the same price is not necessarily overcharging you. You are buying a working product and somebody accountable for it, not a quantity of hours. The saving can legitimately show up as a lower price, a faster delivery, or a better margin for them, and any of those can be a fair outcome depending on what you agreed.
Do not ban it
The instinct to prohibit these tools contractually is understandable and we would advise against it.
It is largely unenforceable, so what you get is not compliance but silence, and silence is worse than a policy because you lose the ability to ask questions. It also deprives you of genuine benefits while leaving accountability exactly where it was.
Governing the practice works better than banning it. A supplier who has agreed a written position with you has something to lose by departing from it, which is more protection than a clause nobody can verify.
The subcontractor gap, which is where policies leak
A subcontractor working on a consumer plan can undo whatever arrangement your supplier agreed with you, and this is the most common way a good arrangement quietly stops applying.
Your supplier agrees a sensible position with you. They then engage a freelancer for a fortnight to handle a specialist piece of work. That person uses whatever they already have, on whatever plan they already pay for, because nobody told them otherwise and the engagement was short.
Nothing about that is malicious and it happens constantly. The arrangement you negotiated covers your supplier and stops at their boundary unless somebody deliberately extended it.
Two questions close the gap. Do you subcontract any part of this work, and if so, do the same obligations apply to them in writing? A supplier who subcontracts regularly will have an answer, because they will have had to think about confidentiality generally rather than only about AI.
It is also worth asking who is accountable if a subcontractor departs from the agreed position. The answer you want is that your supplier is, without qualification, because that is what a prime contractor relationship means and it keeps the question simple.
This connects to a broader point our code ownership guide makes about assignment chains: your supplier can only pass on rights and obligations they actually hold from everyone who touched the work.
The five questions, in the order to ask them
- Does our code leave your environment, and if so, where does it go and on what plan?
- Who reviews the output, and could that person have written it?
- Does your warranty apply identically to AI-assisted work?
- Does your IP assignment cover all delivered code however it was produced?
- Do these obligations flow through to anyone you subcontract to?
Ask for written answers. How a supplier responds to being asked is itself the most informative part: a thoughtful one treats it as reasonable procurement and quite often thanks you for the prompt, because it is a question they have been meaning to formalise.
If a supplier has not thought about any of it, that is a reason to ask them to come back with answers rather than a reason to walk away. The lag between adopting these tools and writing policies about them is normal, and it is closing.
Put these questions to us as well, and hold us to whatever we put in writing. That is the only basis on which any of this is worth anything.
One last framing worth carrying into the conversation. None of these questions are really about artificial intelligence. They are the questions you should already be asking about confidentiality, subcontracting, review and accountability, applied to a new category of tool. A supplier with good answers here almost always has good answers about the rest, and a supplier who has never considered any of it has told you something useful that extends well beyond their tooling.
If you are commissioning software and would like these questions answered in writing before you decide anything, contact us.
References
[1] GitHub, Copilot documentation, trust centre and plan terms. docs.github.com
[2] Anthropic, Claude documentation and commercial terms. docs.claude.com
[3] Google, Gemini Code Assist documentation and terms. cloud.google.com
[4] The Official Portal of the UAE Government, Data protection laws. u.ae
