You can run AI governance in Confluence and Jira. Here is where it breaks.

Almost every organisation starts governing AI the same way, and it is a sensible start. The policy lives in Confluence. The work moves through Jira. Somewhere there is a spreadsheet called "AI register" with a tab per business unit. The tools are already paid for, everyone knows how to use them, and you can stand the whole thing up in an afternoon.

I have built exactly this, more than once, in insurance, telco and government. For a while it holds. Then one of two things happens, and it stops holding fast.

The first is a demand for evidence, and it is rarely a calm, scheduled audit. It tends to arrive on the worst day.

Picture a telco that loses Triple Zero for three hours. Within days the chief executive is in front of the cameras and a Senate committee, and the scrutiny does not stop at the network. Every automated system that touches customers is suddenly in scope, including the AI ones, and the questions are specific. Or picture an executive asked, on the record, to show how the organisation's automated decisions treated vulnerable customers: the ones in hardship, in a disaster zone, at their most exposed. Or, more quietly, a board that wants to know after an incident how one particular AI decision was made, and who was accountable for it.

In every version the question is the same, and it is never "do you have a policy". It is "show me". Show me, for this use case, what risk tier it was, who approved it, what the human could override, and where the evidence is. In a wiki and a ticket board, answering that is a scavenger hunt: a Confluence page here, a Jira ticket there, a spreadsheet row that may or may not still be accurate, and a lot of "let me get back to you". That is a poor answer in a routine audit. In a public hearing, it is a career-defining one.

The second reason has nothing to do with regulators at all. It is scale. You cross thirty or forty use cases and realise you can no longer see the portfolio. Which ones are high risk. Which are stuck. Which are quietly burning budget with no path to production. A Jira board tells you the status of a ticket. It does not tell you whether the thing is worth continuing.

The three things a wiki and a ticket board cannot be

General-purpose tools are brilliant at what they were built for. The problem is that AI governance asks them to be three things they structurally are not.

A risk tier that actually changes the process. Proportionate governance means a low-risk use case flies through and a high-risk one gets full scrutiny, automatically. In Jira, every ticket is a ticket. You can add a "risk" label, but it is just a word. Nothing about that label changes what has to happen next. You end up policing proportionality by hand, which means it quietly stops happening.

A rule the tool will enforce. Real governance has hard lines. This use case cannot go live until every required forum has approved it. If there is no lawful basis for the data, it halts, full stop. A wiki cannot enforce a rule. An approval in a ticket is a field, and a field can be changed by anyone with edit rights, at 5pm on a Friday, with no one the wiser. The rule is only as real as the discipline of the person clicking the button.

A record you can actually stand behind. This one is subtle, so it is worth being precise. Jira and Confluence do keep a proper change history: who changed what, and when, timestamped and easy to navigate. For most questions, that is genuinely enough. What they do not give you is tamper-evidence. The history tells you what the tool recorded; it does not, on its own, prove the record was never altered, because it lives in a database administrators control, records can be deleted, and there is no cryptographic check that the history itself is intact. Purpose-built governance keeps an append-only, hash-chained trail, where any change breaks the chain and becomes detectable. That matters most at the top end, a serious dispute or an investigation, where the question shifts from "what does the log say" to "prove this was not changed".

There is a fourth gap worth naming: portfolio economics. Deciding which use cases to fund, which to watch, and which to stop is not something a status board does. It needs value against risk, payback, and the nerve to kill the ones that will not pay off. A spreadsheet can hold those numbers. It will not keep them honest.

To be fair to the generic tools

None of this makes Confluence or Jira bad. They win, decisively, on the things they were built for: they are mature, they are already there, they cost almost nothing at the margin, IT trusts them, and Jira in particular is excellent at queues, notifications and service-level tracking. They have enterprise-grade sign-on and an enormous integration ecosystem. A purpose-built newcomer does not match any of that, and should not pretend to.

So if you have a handful of low-stakes AI use cases and nobody is ever going to ask, the wiki-and-tickets approach may genuinely be enough. Do not over-engineer a problem you do not have yet.

But notice the threshold is not "are you heavily regulated". It is simpler and broader than that. If your AI touches customers, money or reputation, or you are simply running enough of it to lose track, you are already past the point a wiki and a spreadsheet can answer for. Regulators are only the most predictable of the people who will ask. Boards, customers, journalists, partners running due diligence, and your own incident reviews all ask the same question, and they rarely give you notice.

And it is worth saying this is not only about surviving the bad day. The same discipline that assembles the evidence is what lets you move faster on the use cases that are safe, and put your budget behind the ones that will actually pay off. Proportionate governance is not a brake you bolt on for the regulator. It is how you scale AI with your eyes open. The evidence is the byproduct, not the point.

Pair, do not replace

The answer is not to rip out the tools your teams already live in. Delivery should stay in Jira. Documents should stay in Confluence. What you add is a governance layer that sits above them: it tiers each use case by risk, routes it through the right approvals, enforces the hard rules, and assembles the evidence, on demand, in a form you can hand to a regulator.

The analogy I use with executives: you can run the company's finances in a spreadsheet, right up until you need audited accounts, real controls, and to answer an auditor. Then you want purpose-built. AI governance in a regulated business has reached that same threshold. The spreadsheet got you started. It will not get you through the audit.

This is the gap GatedFlow was built to close: the AI governance operating system that runs the whole lifecycle and produces the proof, while pairing with the GRC, delivery and security tooling you already run. We are honest about being early, and about what is still on our roadmap. But the shape of the problem is not in doubt. The question worth sitting with is simple:

For one live AI use case in your organisation right now, could you show exactly how it was governed, without a week of manual assembly?

If the honest answer is no, that is not a discipline problem. It is a tooling one.