Seven. One developer says he rebuilt seven Adobe products in Rust with help from Claude Opus 5.5, and gave them away as open source. One report counts more than 42,000 GitHub stars across the repositories inside eight days.
I read the story twice. The second time I was not thinking about Photoshop at all. I was thinking about how many audit files I have signed where nobody on my team ever opened the system’s source code, which in IS audit is normal practice. We test around the code and trust the vendor for the rest, and that trust just became much cheaper to manufacture.
What was released, and what was only claimed
The developer is Brandon Thomas, who runs ArtCraft. PhotoCraft for Photoshop, VectorCraft for Illustrator, FilmCraft for Premiere Pro, LightCraft for Lightroom, EffectCraft for After Effects, DesignCraft for InDesign, PrintCraft (since renamed PdfCraft) for Acrobat Pro. Native Rust, plus WebAssembly versions that run in the browser.
He calls them early alpha builds himself, and he is relying on community bug reports to make them stable. The “clean-room” description is disputed. Classic clean-room work keeps two teams apart: one studies the original, the other writes code without ever seeing it. Here it was one developer and a model trained on a huge body of public code.
The developer says his team, which builds software for filmmakers, is funding the work, and the repositories carry test files. One report notes that no automated workflow yet runs those tests on pull requests. I have not verified the funding independently, and I have not installed the apps. So please read this as an auditor’s note on assurance. As a software review it would be useless.
In Coimbatore, nobody buys a mixer-grinder after reading the brochure. You ask the neighbour whether hers survived the Deepavali murukku rush. That is due diligence, Coimbatore style, and it has beaten a few vendor-assessment questionnaires I have read.
The bargain we never wrote down
Auditing any software has two layers. You test what you can reach. For what you cannot reach, you borrow confidence: the vendor’s name, years in market, a SOC 2 or ISAE 3402 report, a few customer references.
Borrowing worked because good software was slow and expensive to build. The cost itself was a filter. A vendor who had spent five years and a large team on a product had a reputation to protect, and that reputation stood in for evidence we could not collect ourselves.
Picture an ordinary ITGC walkthrough. The client shows the tester a user-access list on screen. The tester notes it, ticks the step, moves on. Nobody exports the list, and nobody asks about the vendor support account that still has admin rights. The control passes on paper. Most of us have sat through some version of that afternoon.
That filter is getting thin. When one experienced engineer with a model can ship seven polished applications, polish tells you very little about discipline. The maker’s name, which we used as evidence, is now one more claim to test.
What moves in the audit file
ISO/IEC 27001:2022 Annex A covers all of this already: secure development life cycle (A.8.25), secure coding (A.8.28), security testing in development and acceptance (A.8.29), outsourced development (A.8.30) and change management (A.8.32). The controls were always there. What has changed is who must evidence them, and how often the honest answer will be “we never asked.”
For me, the most useful detail in the whole story is the test suite, and whether anything runs it. A regression suite is the closest thing software has to a control that still works on an ordinary Tuesday. If I could ask any maker of any system for one artefact, I would ask for the last run.
A first version and a reliable version cost different money
Finance leaders should keep two numbers separate. One is the cost of getting a working version. The other is the cost of knowing it is reliable, secure, supportable and legally clean.
AI has cut the first number hard. The second has hardly moved, because it was never mostly about writing code. It is testing, ownership, patching, documentation, and a person who picks up the phone when the system is wrong.
That is why “alpha” is the word I would underline in the coverage. An alpha build can impress and still be unfit for a payroll run, a tax filing or a client file. The risky stretch is the middle, when a tool is good enough for a department to adopt and not yet good enough to survive an audit. That is usually where shadow IT starts, quietly, in a team that has never raised a change ticket.
Singapore adds a twist. In many corridor groups, the regional office in Singapore holds the software budget for the Jakarta and Indian subsidiaries. A tool swap decided in one office becomes a control change in two other jurisdictions, each with its own reporting standard and its own regulator. The evidence has to travel with the decision, and too often it stays behind in Singapore.
What “free” costs on the ledger
Downloading costs nothing. Owning brings four lines onto the P&L: hosting and support, security patching, staff time, and in this case the optional paid AI credits that the project itself sells. The subscription saving is real, but total cost of ownership is a different sum, and I have not yet seen anyone work it out for these tools.
Then the accounting question. If your team builds on such tools and wants to capitalise the cost, IAS 38.57 asks you to show all six development-phase criteria:
technical feasibility
intention to complete
ability to use or sell
how the asset will earn probable future benefits
adequate resources
reliable measurement of the spend
Ind AS 38 carries the same paragraph for Indian entities, and Indonesian entities should check against their local standard. AI shortens the build without thinning the documentation file.
For Jakarta, one more line. Under UU PDP (Law 27 of 2022), the data controller must secure the personal data it processes (Article 35) and supervise everyone involved in processing under its control (Article 37). An employee who uploads client files into an unvetted free tool does not hand that duty to whoever wrote the code.
The assessors have arrived
The same week, the other half of this story arrived by press release. On 14 October 2026, BSI launched three new assessment and certification schemes for AI. AI assurance has stopped being a conference topic. It is now a service line with a scope letter.
Each scheme covers a different layer of the AI stack:
All three sit on top of BSI’s existing ISO/IEC 42001 certification and training. BSI states it was the first body accredited for 42001 certification by ANAB, RvA and UKAS. Its managing director for AI and digital solutions, Omkar Joshi, framed the aim as helping organisations “assure the AI stack end-to-end.”
Two numbers in the release belong in every audit committee pack. A FocalData survey cited by BSI found that 67% of business leaders would trust AI tools more if an external body had validated them. BSI’s own research last year found only about a quarter of leaders had a formal AI governance programme, and only 28% knew which data sources trained or ran their models.
Put plainly: demand for assurance is high, and the evidence to support it mostly does not exist yet.
One caution, in the spirit of this essay. BSI is a certifier launching products, and both surveys are cited by the seller. The direction is credible. The percentages deserve the same scrutiny we give any vendor statistic.
Where the profession goes
This is where the Adobe story and the BSI story meet. Building software is getting cheaper, and assurance over it is turning into a formal, standards-based market. That market needs people who already think in controls, evidence and independence. Three shifts follow, and none of them is “fewer auditors.”
Assurance moves to behaviour. We will spend less time certifying who built a system and more time testing what it does when it changes.
Provenance becomes something we test. Phrases like “clean-room”, “no third-party code” and “AI-assisted” will start appearing in management representation letters. Someone has to decide what evidence sits behind each one, and that someone should be the auditor.
Finance becomes the build-or-buy referee. For two decades the Indonesia–India–Singapore corridor has bought build capacity from Indian IT. That price is being reset in public. Whoever can model replacement cost, control cost and the capitalisation effect together will be the most useful person in the CFO’s office.
New avenues for audit and finance practices
ISO/IEC 42001 readiness. Gap assessments, AI policy design, AI system inventories, and internal audit of the AI management system before the certification body arrives.
AI risk assessment. NIST AI RMF and ISO/IEC 23894 applied with the discipline of an ERM review: model risk, data provenance, human oversight.
Independent assurance on AI controls. ISAE 3000 (Revised) already gives us a framework for assurance over non-financial subject matter. AI controls fit it naturally.
EU AI Act readiness for exporters. Indonesian and Indian firms selling AI-enabled products into the EU will likely meet these requirements through customer contracts well before any local rule forces them.
Data lineage audits. If only 28% of leaders know their model data sources, the work is already scoped: trace it, document it, test it.
One boundary deserves respect. BSI’s own impartiality policy bars its certification arm from certifying a management system that another part of the group advised on.
The same logic binds us. For each client, decide whether you are the adviser or the assurer on that system. Doing both is how a promising practice line ends in an independence finding.
What the industry gets wrong
The question the profession keeps asking is whether AI will replace junior audit hours. It will change them, certainly. My worry sits somewhere else. A large part of our comfort about software was borrowed from the maker’s reputation, and a reputation is far easier to borrow than to check.
Most “AI strategy” decks I am shown are procurement decks with a robot on the cover. They compare licence prices and never ask what evidence you will hold when the system is wrong.
Software used to be expensive to build, so we audited the vendor and called it assurance. Now a first working version costs a fraction of that, and the vendor’s name proves nothing. The profession that survives is the one that stops certifying who built the system and starts testing whether it behaves. Provenance is a claim. Testing is evidence.
Buckle up: what clients need before the assessor calls
Customers, insurers and regulators will start asking for AI evidence the way they now ask for an ISO 27001 certificate. Boards should have three things ready before that letter lands.
An AI register. Every model, tool and AI feature in use, with its owner, its purpose, and whether it processes personal data.
A risk classification. Anything sold into the EU mapped to the EU AI Act risk tiers now. Everything else rated against NIST AI RMF or ISO/IEC 23894, so the method can be defended.
Data lineage for material models. Where the training and operating data came from, who approved it, and how it is refreshed.
The Monday test
Pull your software subscription register. For the five largest annual lines, find the assurance you actually hold: the report, its period, and whether anyone read the exceptions. If no report is on file, the brand is your only evidence.
Ask your head of IT one question. Which production code in the last quarter was written or changed with AI assistance? Ask for the change ticket where someone other than the author approved it, and for the last regression run. Test the approval against ISO/IEC 27001:2022 A.8.32 and the regression run against A.8.29. If the reply is nanti dulu (later, first), you have your finding.
Take one internal build you plan to capitalise. Ask for dated evidence against each of the six IAS 38.57 criteria. Where the evidence is a slide deck, expense it and say so.
Close
In the end, our job is the neighbour’s job back in Coimbatore: to say, from evidence, whether the thing survived Deepavali. Building got cheap. That job did not, and now it has a market. Reply and tell me the one AI tool in your stack you could not defend in front of an assessor.
Lift as you Rise.
Timely comments on the AI role in the software related to audit and assurance sector.