AI workshops for banks in Hong Kong: the prototype trap

Somebody in your bank already has a prototype. It was built in a workshop, it looked good on the screen at four o'clock, and it is now in a folder waiting on a security review that nobody has scheduled.

This is the default shape of an AI workshop for banks in Hong Kong right now. Get a cross-functional group in a room for a day, pick a high-value use case, build something before everyone goes home. The demo at the end is usually genuine. The question worth asking before you sign is what the room produces on the Tuesday three weeks later.

The demo is real. The path to production is not.

A working prototype built in a day still has to clear the same gates as anything else your institution runs. Information security review. A data-flow assessment if it touches customer records. Vendor onboarding if it calls an outside model. Model risk sign-off. Then it needs a place on an engineering roadmap that was already full the week before the workshop.

None of that is obstruction. It is what a regulated institution in Hong Kong is obliged to do, and the people running those reviews are right to run them. But the arithmetic is unkind: the build takes six hours, the review cycle takes months, and by the time an answer comes back the volunteers who built the thing have rotated to other priorities and nobody owns it.

I spent thirteen years inside a bank watching this from the other side. The internal ideas that died were rarely the bad ones. They died because the build happened before anyone was named to carry it, and enthusiasm is not a delivery plan.

The eighty people who never touch the prototype

Here is the part that gets missed. A prototyping day takes ten or twelve people out of a floor of several hundred. Those twelve have a good day. The rest of the building has the same week it had before.

Your bank does not need another prototype. It needs the eighty people who will never touch the prototype to stop losing their Thursdays.

Think about what those eighty actually do. The credit paper rewritten four times because the first draft was structured wrong. The meeting prep that starts at nine at night. The client debrief that never gets written at all. The quarterly deck rebuilt from scratch every single quarter because last quarter's version is buried in somebody's inbox. The pipeline update polished at ten so it looks right on tomorrow's internal call.

Not one of those needs a prototype. Every one of them shortens by half when the person doing it knows four or five things they currently do not know. That is a training problem, and it is a much less exciting thing to sell than a demo.

What to ask before you buy an AI workshop for banks in Hong Kong

Four questions, and the answers tell you which product you are actually being sold.

• Who is in the room? Volunteers from six departments who will never work together again, or the eight people on one desk who share the same work queue? Fluency spreads along working relationships. It does not spread along an attendee list.
• What do we work on? A use case chosen for the demo, or the documents my team will open on Monday morning? If confidentiality blocks the real files, ask whether they can run on realistic samples. Most serious providers can.
• What leaves the room? A built thing that needs a dev team, or a way of working that needs nobody? Both are legitimate. They are not the same purchase, and they should not carry the same price.
• Who rebuilds it in March? If the answer is the provider, you have bought a dependency. If the answer is a named person on your own team, you have bought capability.

There is a fifth question nobody asks, and it is the one that decides the whole thing: what happens in week three? Most corporate AI training dies there, quietly, when the novelty has gone and the old habit is still the fastest path to a deliverable. Anything without an answer for week three is a day out, not a change.

The two formats, side by side

When the prototyping day is the right call

It genuinely is, sometimes, and I would rather say so than pretend otherwise.

If you have a funded digital or product team with real capacity, a decision that needs de-risking before you commit budget to it, an engineering owner named before the workshop rather than volunteered during it, and someone senior whose job it is to walk the thing through review, then a day of building beats three months of committee. That is a good use of a day and a good use of an outside team.

If those four things are not in place, you are buying a demo. An expensive one, and one that tends to make the next AI proposal harder to fund, because the last one produced nothing anybody could point at.

Measure the Tuesday, not the demo

The honest test of any AI training for professionals is not what the room produced on the day. It is what a person does differently three weeks later, without being asked.

So set the measure before you book. Pick four tasks your team does every week, write down what each one costs today in hours, and check the same four in a month. If the credit summary now takes twenty minutes instead of two hours, that is the number that justifies the next session. If nothing moved, you learned something cheap and you should stop buying the format that did not work.

Two caveats, because this cuts both ways. Some work genuinely should not speed up: anything where the thinking is the product, and anything where a wrong answer reaches a client. And none of this clears the data question. Before any of it, your team needs to know which tools are approved and what may never be pasted into them, which is a separate conversation covered in whether ChatGPT is safe for work data.

I run these sessions myself, with your team, on your own material, usually two to ten people at a time. No associates, no prototype to hand over, nothing that needs a dev team afterwards. If that is the version you want, the corporate AI training page sets out how it runs, or start with the free prompt library and see how far your team gets on their own. Either answer is a fine one.