A government entity in Dubai renews the contract for its citizen-services portal and brings in a new vendor. The new team asks for documentation and receives a repository, a folder of screenshots and a warm handshake. Nobody in the room can explain why one eligibility rule treats residents differently from visitors, and the engineers who built it have already moved to another project.
I have spent many years building and maintaining software for clients in India and across the Gulf through IndiaNIC and NICGulf, and I have seen this handover meeting many times, long before AI coding tools existed. In 2026, AI-generated code in government projects makes that meeting both more common and more costly.
The code will usually be fine. The knowledge will not.
Three myths about AI-generated code in government projects
Myth 1: If it passed testing and UAT, it is safe
Fair point first. Tests and user acceptance testing catch a lot, and Gulf entities often run thorough acceptance cycles. That is true, and it is the reason most entities feel comfortable signing off.
However, tests prove the system works today. They do not prove anybody knows why it works. A public system lives for ten or fifteen years through policy changes, new regulations and new integrations. Every one of those changes needs someone who understands the original rules, not someone who can confirm the old tests still pass.
Myth 2: The contract protects us, the vendor owns the risk
Contracts protect money. They rarely protect understanding. A penalty clause does not help when a service is down on the first working day of a new policy and the only people who understood the module now work for a different company in a different country.
One handover we inherited in the region, years before AI assistants, came with complete source code and excellent test coverage. The previous vendor had delivered everything the contract asked for. It took our team several weeks just to learn why a fee calculation behaved differently at month end, because that decision existed only in the memory of one engineer who had left. That was with human-written code. With AI-generated code, that engineer may never have held the reason in the first place.
Myth 3: AI will maintain what AI wrote, so understanding does not matter
This is the strongest argument, and I take it seriously. AI assistants are very good at reading unfamiliar code and suggesting fixes, and that is one reason many entities are relaxed about knowledge loss.
But an assistant can explain what code does. It cannot tell you why a ministry decided a rule, what an official promised a stakeholder, or which exception exists because of a court ruling. That context was never in the code. Government systems carry more of this unwritten context than almost any other kind of software.
The principles that actually protect long-lived public systems
Lost knowledge is the gap between the systems an entity owns and the understanding its people hold about why those systems behave as they do. Four principles close that gap.
First, knowledge is a deliverable. It should be specified, delivered and accepted like any other item in the contract.
Second, sovereignty includes knowledge. The UAE has been clear on data: Federal Decree-Law No. 45 of 2021 on personal data protection sets firm rules on how personal data is handled. Yet a system can keep every record inside the country while the understanding of that system leaves on a flight with the vendor team. Data sovereignty without knowledge sovereignty is half the job.
Third, humans remain in command. The UAE Public Prosecution's 2045 vision keeps AI supporting prosecutors, not replacing them. The same thinking should apply to software: an AI can write the code, but a named person must own it.
Fourth, speed raises the stakes. Gulf News reported this week that Abu Dhabi is working towards an AI-native government by 2027. More services, built faster, means more code entering public systems every month. According to the 2024 DORA report from Google, every 25% increase in AI adoption came with an estimated 7.2% drop in delivery stability. Speed without understanding shows up later as instability.
| A government can own every line of its code and still not own its system. |
What should government entities put in AI-era software contracts?
Government entities should add clauses that make understanding measurable: disclosure of where AI tools were used, decision records stored in the repository, a named human owner for each module, explain-back sessions where in-house staff present the system to the vendor, and a handover rehearsal in which the entity's own team makes a real change before the contract ends.
In practice, I recommend this sequence.
- Require AI usage disclosure at module level, so reviewers know where to ask harder questions.
- Specify decision records as a deliverable. A short note for every important rule: what was decided, by whom and why.
- Name a human owner on the vendor side and a counterpart on the government side for each module.
- Pair in-house engineers with the vendor team from the first sprint. The Dubai Government is already recruiting UAE nationals for AI and engineering roles, with more than 750 positions across 34 entities offered at Ru'ya Careers UAE 2026. Put that talent inside delivery, not only in oversight.
- Run a handover rehearsal three months before contract end. The in-house team explains the system back and completes one real change alone.
- Accept the handover only when the rehearsal passes.
| The costly mistake. Signing off a handover because the source code, credentials and documents were all received. Receiving the code is easy; being able to change it without the vendor is the real test. |
A view from the vendor side of the table
Here is what nobody tells you from the vendor side. Most vendors would welcome these clauses. Good delivery teams want to hand over systems cleanly, because a messy handover damages their reputation in a region where word travels fast. The clauses give them permission to spend time on knowledge work that clients often push back on as "documentation overhead".
The ambition in the region is real and, in my view, admirable. Omar Sultan Al Olama, the UAE Minister of State for Artificial Intelligence, recently shared the UAE's experience building agentic AI-powered government. At the same time, a survey reported by Gulf News found 80% of UAE CIOs had encountered an AI agent that violated business intent. Both facts are true together. Fast adoption and weak control usually arrive as a pair.
In our own Gulf work, the change I push hardest now is small. In every steering meeting, one module is picked at random, and someone from the client side explains it to the room. In the early weeks it feels awkward. Within a few months, the client team starts asking the vendor far sharper questions, and that is exactly what a long-lived public system needs.
Where this conversation should go next
Gulf governments have shown that they can move quickly and set standards others follow. Knowledge sovereignty is the next standard worth setting. If you lead a digital programme, start a conversation with your procurement and legal teams about adding one handover rehearsal clause to your next software contract.
For the broader argument on why lost knowledge, not AI code, is the real maintenance crisis, read my personal essay on AI-generated code and lost knowledge.
Frequently asked questions
Is AI-generated code allowed in UAE government projects?
The UAE actively encourages AI across government, and AI-assisted development is part of that direction. The practical question for an entity is control: whether the vendor discloses AI use, whether a named human owns each module, and whether in-house staff can explain the system after handover. Contracts should make those three things explicit.
What is knowledge sovereignty in government software?
Knowledge sovereignty in government software is the ability of a public entity to understand, change and run its own systems without depending on one vendor. It complements data sovereignty. Data can stay inside the country while the understanding of the system leaves with the vendor team, and that second loss is harder to recover.
How can a government entity test a vendor handover before accepting it?
A government entity can test a vendor handover by asking its own engineers to explain the system back to the vendor, then make one small real change without vendor help. If the in-house team cannot explain key rules or complete the change, the handover is not finished, regardless of what the code and documents show.
