We have an IT team but no AI specialist: how the work gets divided

Month two, Thursday afternoon, a message in the project group: "the bot answered nonsense to a customer". IT checks and can prove the flow ran end to end, without a single exception, exactly as it was written. The answer was still wrong, and the conversation stalls right there, because nobody defined before starting who takes charge of that kind of question.

The dividing line that prevents that Thursday is not about what is technical or what is hard: it is about whether the correct answer is known in advance. Your IT team keeps everything that has a known and verifiable answer —access, infrastructure, security, integrations, the deployment window—. The specialist keeps the one thing that cannot be validated by reading code: the behavior of the model.

Split this way, IT is not left as a spectator, because it keeps the veto over production and over the data, and it is not a bottleneck either, because it does not have to learn to write prompts or to evaluate answers for the project to move forward. Below is the table with the twelve concrete decisions, who decides and who executes each one, the three kinds of access you have to grant and the one you never grant, and the three-question test for classifying decision thirteen: Thursday's, the one that is not in the table.

The dividing line is deterministic versus probabilistic, not technical versus non-technical

The classic mistake is to divide by technical knowledge: "this is hard, the outsider does it". That criterion divides nothing, because your IT team almost always understands your operation better than any newly arrived provider.

The criterion that does divide is the nature of the answer. Your team knows how to answer why the 3 in the morning process failed: it reads the log, finds the error, fixes it. There is a correct answer and it is written down. Nobody answers in the same way why the bot replied that to that customer, because there is no log that says it. The flow ran perfectly, returned a 200, there was no exception, and the answer was still wrong. What sits behind it is a prompt, a set of documents, a way of retrieving them and a model that can answer differently next week without anyone having touched anything.

That is the border. Everything that is verified by reading code or looking at an error dashboard belongs to IT. Everything that is only verified by reading a hundred real conversations belongs to the specialist. Dividing along that line prevents the outcome nobody signed up for: IT left as the formal owner of something it has no way to audit.

The table: twelve decisions, who decides and who executes

This is what has to be filled in before the first technical meeting. Put a first and last name in every cell, not departments.

Three things that read wrong at first glance and are the ones that make the table work.

IT decides five of the twelve and executes four. It is not a supporting role: it is the only one that can stop a deployment. If your head of IT looks at this table and does not see real power, check whether you took away the veto over production, because that is where it lives.

The business decides six and proposes a seventh. Almost every decision that determines whether the project is useful —what gets answered, what does not, when a person steps in, what gets measured— is not technical. When those cells are left empty or say "IT", the project ends up being a demo nobody uses.

The specialist executes eight and decides one single thing: which model is used and with what configuration. That is deliberate. A provider who also decides which questions your bot refuses is making commercial decisions without your context.

The table is sent already filled in before the first meeting, it is not presented inside it: a split creates resentment when it is discovered halfway through, never when it is announced beforehand. Three things have to be said when you send it, and none of them needs more than one line. That the five IT rows are not touched without their approval, veto over production included. That the prompt, the documents and the evaluation of the answers will not be added to their workload. And that what you need back are definitions with a date —which environment, with which user, who from their team joins the weekly meeting—, not a report.

The three kinds of access to grant and the one to never grant

IT will have to grant access to your own data. What gets negotiated is not whether it is granted: it is the form.

• A named service user, with an expiry date. Dedicated to the flow, with a 90-day cutoff date, renewable. If the project stops or the provider changes, the access dies on its own.
• Read access on a view or a replica, not on production. With the fields the flow actually uses. A bot that answers stock and price questions does not need to see margin or purchase cost. Defining that list takes ten minutes and it is what prevents the argument later on, when somebody discovers the model had the cost in plain sight.
• A test environment with anonymized data for the first two weeks, which is when things break the most.

The one you do not grant: administrator on production. If that is the provider's initial request, it is not a sign that they know a lot, it is a sign that they are in a hurry.

Decision thirteen: the three-question test

The table covers the twelve decisions you can anticipate. The one that breaks the split is the thirteenth, and it does not arrive in a meeting: it arrives on a Tuesday as a stray four-word message, "the bot answered nonsense", that somebody has to forward somewhere. If that classification is done on intuition, in two weeks you are back to the criterion that divides nothing: this looks hard, send it to the outsider.

Three questions in order. The first one that gives a yes closes the case, and whoever receives the message can apply them in thirty seconds, without knowing anything about AI.

1. Is there a correct answer written down somewhere beforehand? A current price list, an opening time, a permission, a limit on the provider's account. If it exists and somebody can open it and read it, the case belongs to IT, no matter that the symptom arrived talking about the bot.

2. Was an error left anywhere? A timeout, an exception, an execution that shows as failed, a message that never went out. If the failure left a trace it belongs to IT, and it gets fixed the way anything else gets fixed. If the trace does not exist —as far as the system is concerned nothing strange happened and what is wrong is the content— it belongs to the specialist, and it is worth saying out loud in the kickoff meeting: that case will never be flagged by an error dashboard, so if nobody is assigned to read, it does not get detected.

3. To know whether it turned out well, do you have to read? If verification means opening the conversation and judging whether that answer was useful, the specialist executes and the business decides, because "useful" is a commercial definition. IT cannot sign off on that, and asking them to sign off is what leaves them responsible for something they have no way to audit.

Four cases that arrive looking the same and get divided differently:

• "The bot did not answer five messages yesterday afternoon." IT. There are failed executions, a service down or an account limit: the trace exists and so does the correct answer.
• "The bot gave a price that no longer exists." IT first, and it almost always ends there: the number came out of a table that syncs every so often and arrived late. Only if the data was right at the source and the model still said something else does the case cross over to the specialist. It is the same symptom with two possible owners, and what decides which one is a query to the database, not an opinion.
• "The bot made up a returns policy we do not have." Specialist and business. Question 1 gives a no: that document does not exist, and that is why the model filled the gap. The fix is not technical, it is writing the policy that was never written and putting it in the corpus.
• "It offered a customer a discount." The business decides, the specialist executes. It looks like a system error and it is a commercial decision nobody made: what the assistant can promise and what it has to escalate. If IT solves this on its own, your discount policy ended up being written by whoever configured the prompt.

The case where two people apply the test and get different results is the only one that deserves to go to the weekly meeting. The rest get forwarded and that is it, which is all you ask of a split.

The two ways this breaks

The queue. IT says yes, the project starts, and access to the database ends up behind the ERP migration and the month-end close. There is something specific about AI projects that makes this worse: the first request to IT is not a task but a definition —which environment, on what data, with which user—, and a definition has no ticket type and no estimate, so it floats around as "pending a chat". It is solved by asking for a committed date for those three definitions in the kickoff meeting, not by asking for urgency.

The surprise go-live. The assistant goes to production and IT finds out when a query saturates the database on day 3, right in the middle of the close. It is solved with a single rule: the deployment window is set by IT, always, even if the flow touches nothing of theirs.

The three capabilities that cannot be divided because they do not exist yet

A division of tasks assigns work that somebody already knows how to do. The table solves coexistence, which is the month-one problem, and it works while there is one assistant or two or three flows in production and the answers can be reviewed by eye.

There are three capabilities that no cell of the table contains, because they are not tasks but crafts your company does not have in-house yet, and that is why adding more names does not make them appear:

1. When you have to decide whether the answers are good enough. Dividing tasks does not create the ability to build a set of test cases, run it every time the prompt or the model changes, and know whether it got worse. That is a permanent process, not a meeting.
2. When the model changes on its own. Providers update and retire versions. An assistant that was answering well can start answering differently without anyone in your company having touched anything. Here reading one conversation is not even enough: read on its own, the new answer looks reasonable. It only shows up against the earlier answers, and that requires having saved them.
3. When you go from one flow to five. That is when the question no split answers appears: why did this customer get two messages, which of the five flows sent them, and in what order do they run.

That is the real limit: the table sorts out who does what with what you already know how to do. What cannot be divided is the part nobody on the team knows how to do yet, and it is exactly the part that keeps the assistant useful in month eight.

In one line

Fill in the table this week and use the three-question test on the first "answered nonsense" that arrives. If your IT team keeps the veto over the deployment window and does not carry the evaluation of the answers, the split holds up on its own.

And schedule a second thing, the one almost nobody schedules: in sixty days, half an hour to run the same three questions again on the same saved conversations. If the answers changed and nobody in your company touched anything, you stopped arguing point 2 in the abstract and started having the proof inside your own operation. That half hour is worth more than the kickoff meeting, and it is the only task in the whole table you cannot delegate to IT or to the provider, because the one who decides whether an answer is acceptable is the owner of the process.

Two neighboring decisions this table does not answer and are better kept separate from it: whether it is worth putting someone inside instead of bringing in a specialist comes down to hours and money, and the 12-month calculation is in hiring or outsourcing; what has to be settled in writing before signing is in the 12 questions to ask a provider.

Once the table is filled in, send it to info@striqtech.com. What can be read there is not which tool you chose: it is how many of the twelve rows ended up with the same name in both columns.