Short answer. No single function should hold the whole AI budget in a bank. The funding split that scales has three parts: a joint IT and finance budget for shared platform infrastructure, a business unit budget for the use case that inherits the KPI, and a small central fund, typically 5% to 10% of total AI spend, for pilots with a fixed exit date. Ableneo’s 2025 portfolio shows roughly 4 of 5 funded projects reaching production under a version of this split, against an industry pattern where AI pilots funded solely by IT rarely find a business sponsor willing to inherit the ongoing cost.
Budget ownership decides whether an AI use case survives contact with a P&L. In most banks, the argument is not about the size of the AI budget. It is about which line absorbs it once a pilot leaves the lab. A workable structure splits AI spend into three distinct budgets, each with a different owner and a different question it has to answer before it releases money.
The platform budget, funded jointly by IT and finance, covers the shared layer: the LLM gateway, the vector store, the MLOps pipeline, and the model risk tooling that every use case reuses. The business unit budget covers the use case itself, the fraud model, the underwriting copilot, the collections triage tool, and it is owned by whichever P&L leader inherits the KPI the model is supposed to move. The experimentation fund, typically 5% to 10% of total AI spend, sits with a central AI steering group and funds proofs of concept against a fixed entry and exit date, so an idea that does not clear its gate gets closed on schedule instead of drifting on IT’s budget indefinitely.
Under DORA (Regulation (EU) 2022/2554), which has applied to EU financial entities since 17 January 2025, the management body has to approve and own the ICT risk management framework, budget included. An AI system with an ICT budget line that nobody in the business can name is a governance gap an auditor will flag, because DORA ties accountability to a named function, not to a cost center. When the budget for an AI system sits entirely inside IT with no business owner, the DORA control that asks who is accountable for this system’s risk has no clean answer.
The EU AI Act adds a second pressure point. Article 26 requires deployers of high-risk AI systems, which includes most credit scoring, creditworthiness, and fraud models banks run, to allocate the human oversight and monitoring resources the system needs for as long as it runs. That is an ongoing cost, not a one-time project line. If a bank’s only AI budget is the initial project budget and nothing survives into the operating budget, the bank drifts out of compliance with Article 26 the day the project team disbands, whether the model still works or not.
Split AI spend into three swimlanes: a joint IT and finance platform budget, a business unit budget owned by the P&L leader, and a 5% to 10% experimentation fund with a fixed exit date.
The three-swimlane model separates AI spend by the question each euro has to answer, not by the team that requested it. The platform swimlane answers whether spend reduces duplicate infrastructure cost. The business unit swimlane answers whether the use case moves a number a named P&L owner is accountable for; if no owner will claim the outcome, the use case is not ready for this swimlane yet. The experimentation swimlane answers whether an idea is worth a bounded bet; it funds discovery, not production, with a calendar date on which a steering committee decides to scale, extend, or kill.
Banks that run this model often cap the experimentation swimlane at 5% to 10% of total annual AI spend, refreshed quarterly, so pilots do not crowd out the operating budget of use cases already in production. The platform swimlane is usually the largest of the three in year one, then shrinks as a share of total spend as more use cases reuse the same infrastructure.
The experimentation fund pays, not the business unit that hosted the pilot. That is the point of ring-fencing 5% to 10% of AI spend into a separate line: it lets a business unit try a use case without putting its annual budget at risk if the pilot does not clear its exit gate. If pilot costs land on the business unit’s regular budget instead, unit heads rationally stop proposing pilots, and the bank’s AI program stalls for a reason that has nothing to do with the technology. Write the failure cost off against the experimentation fund, log the reason it failed, and let the business unit propose the next idea without a budget scar attached to its name.
Put one name against every workload’s ongoing cost, not one department. The recurring fight is rarely about the size of the bill, it is about who owns the number when it moves. A cost allocation model that charges inference and monitoring cost back to the business unit that owns the use case, with IT publishing a transparent unit cost per query, removes the ambiguity. IT stops absorbing blame for a bill it does not control the volume of, and the business unit stops treating AI as a free shared service, the same discipline FinOps brought to cloud spend, applied now to inference cost.
The budget moves from the experimentation fund to the business unit’s operating budget, permanently. This is the step banks most often skip, and it is why production AI systems quietly degrade: the project budget that paid for the build runs out, nobody has budgeted the ongoing cost of inference, monitoring, retraining, and the human oversight the EU AI Act requires, and the system keeps running until it breaks or an auditor asks who owns it. The handoff should be a formal, dated step inside the same steering process that approved the pilot, not an assumption.
Both, at different points. The CIO signs off on the platform swimlane, because that is shared technical infrastructure. The business unit’s own budget owner, not the CIO, signs off on the use case swimlane, because that is where the P&L accountability sits. The CFO, or a central AI steering committee often chaired jointly by the CFO and CIO in banks that have formalized one, signs off on the experimentation fund, because that pool of money is designed to absorb write-offs. A single sign-off chain covering all three swimlanes quietly recreates the ownership ambiguity the model exists to remove.
Ableneo sets up this funding split as part of the governance work that precedes a bank’s first production AI deployment, drawing on financial services relationships that include ČSOB, Erste Group, and UNIQA. Across Ableneo’s 2025 portfolio, 34 production AI projects across 4 countries and 7 industries, the use cases that reached production shared one trait: a named business owner held the budget for the outcome from day one, not just the model. That pattern sits behind Ableneo’s roughly 4 of 5 delivery rate, well above the industry norm of pilots that stall once the project budget runs out. The Ableneo AI transformation FAQ covers the governance and cost questions that follow, from DORA vendor risk to production monitoring.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.