AI RACI: Why I Meet Your IT Team Before We Build

An AI RACI is the matrix that says, for each part of an AI system, who does the work, who is accountable for it, who is consulted and who is informed. The useful version is not drawn by the AI supplier alone. I draw it in a first meeting with your IT organisation and your ICT partner, before anyone writes code, because almost every delay I have seen in a mid-sized AI project came from the landscape around the model.

This is written for the IT manager, IT director, informatiemanager or CIO of an organisation of 250 to 5,000 people that already has an ICT partner or an internal IT team and is about to bring in a specialist AI supplier. I run one of those specialists. We do not run your infrastructure, your service desk or your network, and we have no wish to. That is exactly why the first meeting I ask for is not with your board. It is with the people who do.

Why do AI projects get delayed in IT rather than in the model?

In first conversations, buyers worry about the model: which one, how accurate, whether it will make things up. Those are fair questions, and they have answers we can test against your own cases within a week or two. The projects that slip usually slip somewhere else, and the pattern is boringly consistent.

• An app registration or service account that has to be requested through a queue, by a supplier who is not on the list of people allowed to request it.
• An egress proxy that blocks the model provider's endpoint, discovered on the day the first integration test runs.
• A change window that opens once a fortnight, against a build plan that assumed we could deploy when ready.
• Logs that must land in the SIEM the ICT partner runs, in a format nobody agreed on.
• A cloud subscription owned by the ICT partner, so every new resource needs their hands, and their hours were never budgeted.

None of these is hard. Every one of them is someone else's job, in someone else's process, at someone else's pace. A specialist who finds them in week six has to wait. A specialist who finds them in week zero can design around them, or put the request in the queue on the first day. The difference between a project that lands on schedule and one that runs months late is often nothing more than when these questions were asked.

There is also a quieter reason. An ICT partner that meets an AI system for the first time at handover is being asked to support something it had no say in. Its rational response is to slow down, ask for documentation and attach conditions. If I were the ICT partner, I would do the same.

What did Dutch construction learn about bringing the builder in early?

The Dutch building sector has a word for the fix: the bouwteam. In a bouwteam the client, its advisers and a contractor work on the design together, so that the party that will actually build it contributes its knowledge of execution, planning and cost while the drawing can still change. Bouwend Nederland describes it in those terms. The alternative is the traditional route, in which the client has a design and a bestek drawn up and contractors price what they are handed.

What struck me, reading about the model contracts, is how they changed. For almost thirty years bouwteams were usually recorded in the VGBouw model of 1992, written for a time when the contractor mostly came to the table to advise on buildability and cost. On 14 May 2020 Duurzaam Gebouwd launched the Modelovereenkomst Bouwteam DG 2020, and in 2021 Bouwend Nederland followed with a successor to the 1992 model. The DG 2020 model added a separate article on attitude and behaviour: how the parties are expected to work with each other, written into the contract. Three decades of practice had taught the sector that a description of roles is not enough on its own.

The analogy travels further than I expected, and I should be honest about where it stops. A contractor in a bouwteam usually hopes to win the execution contract afterwards. Your ICT partner is not bidding to build the AI system, and I am not bidding to run your network. That makes the AI version easier rather than harder, because nobody at the table is competing for the other's work. A note for Flemish readers: the bouwteam and the model contracts named here are Dutch practice. Belgian construction has its own traditions, and I would not assume these names mean anything in Antwerp.

The lesson I take is simple. Bring the party that will live with the system into the design while the design can still move. For an AI system in an organisation of your size, that party is your IT organisation and your ICT partner.

Which rows does a generic RACI matrix miss for an AI system?

Most IT organisations already have a RACI template, and many cloud teams borrowed theirs from a framework. Microsoft's Cloud Adoption Framework publishes example RACI matrices for cloud teams, with columns that include solution delivery, change management, solution operations, governance and platform operations. It is a perfectly good page. It has no row for what a model says.

A small detail I enjoy: the Dutch version of that page is a machine translation, and its description lists the parties as verantwoordelijke, verantwoordelijke, geraadpleegde en geïnformeerde. Responsible and Accountable both came out as the same word. That is the whole failure mode of a RACI in a single word. When R and A collapse into one person, or into nobody, the matrix looks complete and decides nothing. Dutch teams who use the VERI-matrix avoid it with the word eindverantwoordelijk, and I would insist on that word in your version.

These are the rows I add for an AI system. Each one gets exactly one eindverantwoordelijke.

• Identity: the app registration or service principal the system runs under, who requests it, who approves its permissions and who reviews them.
• Network: which endpoints the system may reach, the model provider's included, and who changes the egress rules.
• Data access: which sources the system may read, at which classification, and who signs that off for each source.
• Model and prompt changes: who may change a model version or a prompt in production, and through which change route.
• The evaluation set: who owns the questions that define a correct answer, and who runs them before every change.

• Logging and retention: where prompts, outputs and retrieved context are stored, for how long, and who may read them.
• Cost: who receives the alert when the token bill doubles, and who may switch the system off.
• Decommissioning: who removes the identity, the keys and the index when the system is retired.

Who gets paged when the system gives a wrong answer at two in the morning is a row too, and an important one, but it deserves its own conversation. I wrote it up in who gets paged when an AI system breaks. The rows above are the ones that decide whether the system can be built at all.

What should you ask the ICT partner before an AI project starts?

For that first meeting I aim for ninety minutes. I ask the IT manager to chair it, not me, because it is their landscape and their suppliers. I bring a one-page sketch of the system: what it reads, what it writes, where it runs and what it calls. Then I ask questions rather than present.

• Which identity model do you want this system to use, and how long does a new app registration take from request to approval?
• Is outbound traffic proxied, and what does it take to allow a new endpoint?
• When are your change windows, and which of our changes would you want to see in them?
• Where must logs go, and in what format?
• Who owns the subscription or tenant this will live in, and do you want it inside or outside your existing landing zone?
• Which data classification applies to each source we plan to read, and who in your organisation decides that?
• What would make you refuse to support this system later?

The last question is the one that matters. It sounds confrontational. In practice it is the most relieving question in the meeting, because it gives the ICT partner a legitimate place to say no early rather than a reason to stall later. The answers are nearly always reasonable: no shared admin accounts, no secrets in code, nothing outside the landing zone, no system they cannot switch off themselves. Those are buildability requirements, exactly the kind of knowledge a contractor brings to a bouwteam. I write them into the design and they stop being objections.

Why does the ICT partner hesitate, and what makes it easier?

If you are the reader this essay is for, you probably know this already, but it is worth saying plainly. An ICT partner's fear is owning something it cannot support. Its contract, its staff and its monitoring were built for infrastructure and applications that behave the same way twice. An AI system does not, and the partner knows it.

Three things help, in my experience.

• A written list of what is not theirs. The ICT partner does not own answer quality, the evaluation set or prompt changes. Those belong with you, as I argued in what IT should keep in-house with an AI supplier. Saying so out loud removes most of the resistance in the room.
• A veto where it is legitimate. On identity, network and the landing zone their requirements are binding, and I say so before they have to ask.
• Their hours in the budget, which deserves its own section.

What does not help is going around them. A specialist who builds in a separate subscription to avoid the queue gains a few weeks and creates a system nobody in IT will agree to run. When that happens, the usual ending is a rebuild inside the estate or a quiet shutdown, and both cost more than the queue would have.

Who pays for the ICT partner's time in an AI project?

This is the question nobody asks, and it causes more friction than any technical one. The ICT partner's time in the design phase is real work: reviewing a sketch, creating an identity, opening a route, adding a log source. Under many managed-service contracts that sits outside the fixed fee and is billed by the hour, or it competes with tickets from the rest of your organisation.

If nobody budgets it, the work still happens, only slower and with some resentment. My advice is unexciting. Ask the ICT partner for an estimate of its hours in the first meeting, put it in the project budget as a line of its own, and treat it as part of what the AI system costs rather than as overhead.

The bouwteam is instructive here as well. Bouwend Nederland notes that the traditional reward for a contractor's design-phase work was the prospect of being the first and only party allowed to price the execution. Your ICT partner gets no such prospect from an AI build. So pay for the hours instead, and you will find the queue moves.

When is the three-party meeting overkill?

Not every AI change needs it. If the work happens entirely inside a platform your ICT partner already runs, as with a Copilot Studio agent built by your own people in your own tenant, the existing RACI usually covers it. If the AI supplier hosts everything as a service and the only touchpoint is single sign-on, a short call about identity and data processing is enough.

The meeting earns its ninety minutes when three conditions meet: a specialist supplier is building, the system reads from or writes into systems your ICT partner manages, and it will run inside your estate. That describes most of the work we do for organisations of your size, which is why I ask for it by default.

What I would change in your next kickoff

If you are about to start an AI project with a specialist supplier, move one meeting forward. Put the ICT partner at the table before the design is fixed. Ask them what would make them refuse. Draw the RACI with the AI rows above and one eindverantwoordelijke per row. Budget their hours as a line of its own.

None of this is clever. It is what the Dutch building sector wrote into its contracts after thirty years of learning it the slow way. Our page on AI implementation in the Netherlands describes how we run a build around that meeting, and applied AI for mid-sized businesses shows where it fits in a larger programme. If you are earlier than that, and still deciding whether the project should start at all, how I know a project will fail before it starts is the better read.

Frequently asked questions