AI in your editor, or AI in their platform

A question that now arrives early in procurement: you use AI, so what do we have to assess? It is a reasonable question with two completely different answers, and which one applies depends on something the conversation usually skips.

"AI in integration work" names two things. In one of them a model helps build the integration and never leaves the workshop. In the other a model runs inside the platform that gets handed over. The engineering overlaps. The obligations do not, and neither does who carries them.

Scope one: the model is in the editor

Two systems have to exchange data. A model is given both schemas and a sample of real records, and it proposes which field corresponds to which. It drafts the transformation. It reads the legacy component nobody documented and explains what the code appears to do. Every one of those outputs is a proposed change that a person reads, corrects and commits.

Nothing about that reaches production. The delivered integration contains transformation logic, tests and a contract; it does not contain a model, and it will behave identically next year whether or not the tool that helped write it still exists. The customer has no AI system here, in the same way that nobody inventories the compiler.

Scope two: the model is in the platform

Now the model is part of what runs. It groups the failed messages in the queue each morning and tells an operator that four hundred failures are five causes. It explains a rejection in a sentence rather than a stack trace. It proposes a mapping to the person maintaining an interface, months after delivery, when nobody from the original project is in the room.

That is an AI system in the customer's estate. It needs a named owner in operations, a risk classification recorded by somebody, oversight that can actually intervene rather than merely observe, logging that answers questions afterwards, and measurement that continues after go-live. None of those follow from the model being good. They follow from it being there.

What it costs to blur them

Both directions are expensive. A customer who applies scope-two governance to scope-one work ends up assessing a development tool: risk assessments for something that ships nothing, review boards for a drafting aid, and a delivery that runs slower with no risk removed. We have been asked to complete AI system questionnaires for work where the answer to "what AI is in the deliverable" is: none.

The other direction is worse. A customer who buys scope two believing it is scope one discovers after go-live that they own a production AI system with no owner, no logging worth the name and no answer for an auditor. That is not a procurement error so much as a specification that never distinguished the two.

The question is not whether AI was involved. It is whether any of it is still running when we leave.

The one thing both scopes share

There is a single decision that behaves the same way on both sides of the line, and it is the mapping. A rejected message is loud: it stops, it sits where somebody can see it, and nothing downstream is wrong yet. A wrong mapping is quiet. It succeeds, the receiving system accepts it because the value looks entirely reasonable, and it happens again on every message that follows. It surfaces when the numbers stop adding up, and by then the question is not how to fix the mapping but how far the bad values have spread.

So a person commits the mapping. In scope one that is an ordinary code review before the change is merged. In scope two it is a review point built into the platform, with the proposal held until somebody approves it. Different mechanisms, same rule, and the reason is the same in both cases: this is the one decision whose errors are silent, and silence removes the chance to catch it.

How to settle it in writing

• State which scope the engagement is. One sentence in the statement of work: whether any model is present in the delivered system, or only in its construction.
• For scope one, say what the deliverable contains. Transformation logic, tests, a contract, and no model at runtime is a clear answer to an assessment questionnaire, and it is the honest one.
• For scope two, name the owner before go-live. An AI feature handed over without somebody in operations accountable for it is the most common way a working system quietly stops being one.
• Do not let the tender ask only whether AI was used. The useful question is what remains running afterwards, and the two have different answers.

Which one to start from

Most integration work should start as scope one and stay there. The mapping and the failure explanations are genuinely faster with a model in the editor, the obligation stays where it already was, and the delivered platform is no harder to operate in five years than it would have been. Scope two earns its place when the people maintaining the interfaces are not the people who built them, and there is a queue somebody has to work every morning without the context the project had. That is a real problem and worth solving. It is also a decision to put an AI system into production, and it should be made as one.

We use AI to help build software. Does our customer have to assess it?

Not for the tooling itself, where the output is a change a person reviews and commits and nothing model-shaped ships. The delivered system contains code, tests and contracts. What is worth stating explicitly, in writing, is that the deliverable contains no model at runtime, because that is the answer an assessment questionnaire is actually looking for.

At what point does it become an AI system the customer owns?

When a model is still running after handover. That is the line: a model that shaped the code is a development tool, and a model that reads their data or advises their operators is part of their estate. The practical test is whether the system behaves differently next year if the model is switched off.

Does AI make an integration project faster?

It compresses the typing and not the agreeing. Drafting a transformation, reading an undocumented component and explaining a rejection all get quicker. Deciding what a field means to the business, and getting two system owners to agree on it, is where integration projects actually spend their time, and no model shortens that.

Who decides the risk classification if we deliver scope two?

The organisation deploying it, because classification follows from the use rather than from the technology, and the same component can land differently in two different processes. We can supply what the determination needs — what the system does, what it may act on, what is logged — but the recorded decision and its owner sit with the deployer. Where a case is genuinely borderline, that is worth legal advice on the specific use.

Can a model propose mappings in production without a person approving them?

It can, and it should not. A wrong mapping raises no error and writes a plausible value into every downstream system until somebody notices the totals are off. Read-only work — grouping failures, explaining a rejection — is safe to run unattended, because a wrong explanation is noticed and discarded. Anything that changes a contract between two systems needs a person at the commit point.