The demo is on Thursday. A business unit has built something genuinely useful with an AI tool, the sponsor is delighted, and your name is on the approval line. You have four days, no documentation, and a codebase nobody on your team has read.
That situation is now routine across the GCC, and it is not going away. So the useful question is no longer whether to allow AI-generated software into production — that argument is settled by the calendar — but what a competent gate looks like when you have days rather than months.
Why the approval gate moved onto your desk
For most of the last decade, a CTO in Dubai or Riyadh approved software that a supplier had built and warranted. The supplier carried the professional liability, and the review was largely commercial.
Both halves of that arrangement have weakened. Software now arrives from inside the business as often as from outside it, and when it does arrive from a supplier it was frequently produced with the same generation tools your own team uses. Nobody is warranting the parts nobody wrote.
Which puts the technical judgement back where it used to be, on the person who signs.
I have never been persuaded that this is a bad development. It is closer to how engineering leadership ought to work. But it does mean you need a gate that fits into four days and still catches what matters.
The four-gate audit framework
An audit gate is a question the codebase must answer with evidence rather than assurance. Four of them, in this order, because each one makes the next cheaper to check.
Gate one: residency and data flow
Ask where the primary database, every backup, every log stream and every third-party integration physically stores data. Not the intended answer — the actual region string in the configuration.
For anything touching Saudi personal data, in-Kingdom processing is the default expectation under the framework administered by SDAIA, and UAE obligations sit alongside it under the federal regime overseen through the Telecommunications and Digital Government Regulatory Authority. A residency claim that covers the database but not the log aggregator is not a residency claim.
A Sharjah manufacturer's procurement portal came to us three days before a scheduled go-live, and the residency answer was confident and wrong in an interesting way. The database was correctly hosted in a UAE region — somebody had thought about it. But the application sent every uploaded supplier document to an optical character recognition service in another continent, and emailed every purchase order through a provider whose default region was Ireland. Two integrations, four lines of code, and a residency position that would not have survived the first question from their largest customer. Residency is a property of every pipeline, not of the database you remember choosing.
Gate two: authorisation, checked per request
Take the most sensitive endpoint in the application and call it with a valid session belonging to a user who should not have access. Then call it with no session at all. What comes back is your finding.
Generated code routinely implements authorisation in the interface — hiding a menu item, disabling a button — and omits it in the API underneath. Broken Object Level Authorization sits at the top of the OWASP API Security project's ranking precisely because it is this common and this easy to exploit.
Gate three: limits and abuse
Every public endpoint needs a rate limit, and login, password reset and any endpoint that costs money — an AI model call, an SMS, a payment attempt — needs a stricter one. Check that the application can actually return HTTP 429, standardised in RFC 6585, and that something is watching when it does. A limit nobody is alerted on is a speed bump rather than a control.
Gate four: ownership and paper
Confirm that your entity owns the repositories, the cloud accounts and the domain, and that every contributor signed an assignment. This is the gate technical people skip and lawyers ask about first.
Two days of work, honestly done. The CycloneDX format handles the software bill of materials in the fifth row, and the questionnaires published by the Cloud Security Alliance are a reasonable template if your organisation needs something more formal to file.
| Scan the built bundle, not the repository. A secret can be absent from source control and still be compiled into the JavaScript your users download, because the build step inlined an environment variable. Grep the deployed artefact — that is what an attacker reads. |
What does zero-trust authorisation mean for an AI-generated app?
Zero-trust authorisation means every request is authorised on the server against the specific object it touches, with no request trusted because of where it came from or because the user is already signed in. In practice it means the API checks ownership of record 4471 before returning it, every time, rather than relying on the interface to have hidden the link.
The reference definition is NIST Special Publication 800-207, published in August 2020, and the gap between it and a generated codebase is almost always the same: authentication is done well, authorisation is done in the user interface, and nothing checks the object.
Fair counterargument, and it deserves a hearing: for an internal tool on a private network, with fifteen users who all have the same role, per-object authorisation is over-engineering that slows a useful thing down. I agree in that narrow case. But the fifteen-user internal tool is exactly what gets promoted to a customer-facing service eighteen months later without anybody revisiting the assumption, so I would still write down that the check is missing and why you accepted it.
Do I need an IP assignment deed for AI-written code in the UAE?
Yes. Under UAE Federal Decree-Law No. 38 of 2021 on copyright and neighbouring rights, software is protected as a copyrighted work and economic rights transfer only through a written assignment. That obligation applies to human contributors regardless of how much of the code an AI tool produced, so freelancers, agencies and departing co-founders all need signed assignments.
The practical trap is the contributor nobody remembers. A designer who wrote some front-end components, a consultant who built the data import script, an intern from two summers ago. The World Intellectual Property Organization maintains the reference texts, and if your engagement is governed by Dubai International Financial Centre law rather than federal law, check which regime your contract actually names before you assume.
| An audit is not a search for everything wrong. It is a search for the things that would change your decision — and there are usually fewer than six. |
A worked audit, and the finding that changed the deployment
The most useful audit I have been part of took eleven working hours and produced a single-page result. A regional healthcare group had a patient-referral tool built internally with an AI assistant, working well in a pilot with two clinics, and a plan to roll it out to nineteen.
Gates one, three, four and five came back clean or nearly so. Gate two did not. Any authenticated clinician could retrieve any referral by changing a number in the URL — across clinics, across specialities, including psychiatric records that the clinic's own access policy restricted to a named list of four people. Nothing had been breached, because only trusted staff had accounts. The exposure was the rollout: nineteen clinics meant several hundred accounts, and the policy the organisation believed it was enforcing existed only in a dropdown menu.
They deployed five weeks later than planned. The fix took six days; the other four weeks went on re-running the clinical governance approval, which had been granted on the basis of an access model that turned out not to exist. That ratio is worth remembering — the engineering repair is rarely the long pole, and the governance rework almost always is.
Here is the concession I owe the other side of this argument. Audits do delay things, and a delayed internal tool has a real cost that nobody puts in a slide: the clinics waited five more weeks with a worse process. That cost is genuine. I would still make the same call, because the alternative was nineteen clinics discovering the gap in production — but I would not pretend the choice was free, and I have more respect for the CTOs who name that trade-off out loud than the ones who present security as costless.
Your first week with this checklist
Do not start by auditing anything. Start by finding out what exists.
- Monday: ask for the list. Every application in the business built outside the software team. Offer amnesty and mean it, or the list will be wrong in the direction that hurts.
- Tuesday: sort by data, not by size. Rank what you find by the most sensitive data each system can reach. A small tool touching payroll outranks a large one touching the canteen menu.
- Wednesday and Thursday: run the four gates on the top three. Two days, three systems, evidence written down rather than remembered.
- Friday: publish the standard. One page, the six rows of the table above, and a named person who signs. A checklist nobody has seen is not a gate.
The mistake I would most like you to avoid is one I made myself, on the other side of the table. We once ran an audit for a client and delivered a thorough report with 43 findings ranked by severity — genuinely good work, and completely unusable. The CTO had four days and a board meeting; what he needed was three findings and a recommendation. Capping a first-pass report at the five things that would change the deployment decision is now how NICGULF writes them, with everything else in an appendix nobody is required to read. Rankings are for engineers. Decisions need a shortlist.
So here is what I would like you to take into your next leadership meeting, and I would genuinely like to know the answer: of the applications running in your business right now, how many were built outside your software team, and which one holds the most sensitive data? If you cannot name that system today, it is the first thing to find — and I would rather you found it than a regulator did.
Frequently asked questions
How long should a CTO's audit of an AI-generated codebase take?
Two working days for a first pass on a single application, covering residency, authorisation, secrets, rate limiting, dependencies and ownership. That timescale is enough to produce a deployment decision with evidence behind it. Deeper work — formal penetration testing, threat modelling, compliance certification — is a separate engagement and should be scoped separately.
What is the most common serious finding in AI-generated business applications?
Authorisation enforced only in the user interface. The application hides menu items and disables buttons for users who lack permission, while the API underneath returns any record to any authenticated caller. It requires no exploit tooling to find, and it is the flaw that turns a small pilot into a large exposure at rollout.
Does an internal tool need the same audit as a customer-facing system?
It needs the same gates applied with different depth. Data sensitivity sets the bar, not the audience — an internal tool reading payroll or patient records deserves more scrutiny than a public page showing opening hours. Internal tools also get promoted to customer-facing systems later, usually without anyone revisiting the original assumptions.
