Who runs the AI after it goes live?

Nexus describes building the first procedure with the customer and staying to improve it. Relevance AI describes an embedded deployment team followed by training. WRITER describes transformation leads and deployment engineers.^1,2,3,4

Turn those offers into a list of jobs with a name beside each. Who maps the process, arranges source access, builds connections, configures the agent, tests it, trains colleagues, provides support and makes changes? For each job, name both the person doing it and the person accepting it. “The vendor helps” leaves too much open. Your internal platform team should agree to its responsibilities before the proposal quietly assigns them.

Use a hypothetical account-review pilot as an example. The business owner defines an acceptable draft. System owners authorize access. The delivery team builds the workflow, a reviewer accepts results and an operator handles incidents. A person may hold several roles, but none of the jobs should vanish. Before accepting handover, have the receiving team change a rule, rerun the checks and show how it recovers from a problem.

Glean says source permissions apply to reads and writes. Microsoft documents knowledge access under the user’s account. Relevance AI describes conditional approvals and approval rules for individual tools.^5,6,7,8

Use controlled test accounts with different permissions. Let one account read a source and deny another, then change the permission and repeat the request. Try an allowed read, a forbidden change and an action that must wait for approval. Look at the resulting records as well as the chat. An answer saying access was refused does not prove that nothing was written elsewhere. Your team needs to check both.^5,6,7,8

Keep this exercise in a test environment with approved sample records. Include a source document containing instructions that conflict with the agreed task, and check that it cannot authorize an extra action. Have the security owner write the expected result before running it. In the account review, information belonging to another customer team must stay out of both the draft and its supporting material. These are proposed checks, not tests Ledgerline has performed.

Relevance AI says evaluations rerun before changes are published. Microsoft describes release pipelines and approval gates.^9,10

Build trial cases from ordinary work and the problems colleagues already recognize. Include missing information, an unavailable connected service, the same event arriving twice and a request with more than one plausible meaning. Decide what should happen in each: stop, ask a person, retry or save the work for later. Agree those expected results before giving the cases to the supplier so everyone is judging the same behavior.

After a failed run, ask the operator to explain what happened using the records. Make a controlled change and repeat the affected cases. Keep the input, expected result, actual result and version together. For the account review, a duplicate event must not cause an unintended second external action. A missing source should be shown to the reviewer instead of replaced with a plausible guess. The record should make both outcomes easy to check.^9,10

Before giving more people access, agree who owns the service, how they get support and what makes them pause the workflow. Track accepted work, difficult cases, review effort and operating costs using definitions everyone shares. A generated draft is not automatically completed work. Keep a way to return to the existing process until the business owner accepts the new one, including the jobs people will do around it.

Nexus separately quotes a timetable for the first agent within a proof of concept. That is a company statement, not a delivery result measured by Ledgerline.¹¹

A delivery date is one milestone. The evidence, permissions, operating owner and commercial terms also need to be in place. Finish the pilot with a record of passing cases, unresolved defects, agreed responsibilities and the decision to expand, revise or stop. A trial can be useful because it uncovers a requirement the proposal cannot yet meet. Keep that finding in the decision record, even if the launch announcement would be simpler without it.