Who answers when the AI workflow breaks?

Imagine a new employee asking for access to a project. The assistant explains the process, search finds the policy, an agent prepares a request and another system grants access. If the person never receives it, “the chatbot worked” is no answer. Begin the delivery plan with the person responsible for the final business result. That person does not need to administer every product, but must be able to bring the right colleagues together.

For this example, the service owner might be the manager responsible for employee access requests. The identity team owns account rules, a project owner approves membership, and the support team handles unresolved cases. Use real roles from your organization. Do not assign responsibilities to a supplier without agreement, or assume the employee who built the first demonstration will remain available indefinitely.

Dust separates what an agent can access from who may use it, and syncs identity-provider groups through SCIM. Glean describes applying source permissions on every read and write. Google’s enterprise editions list identity management and source access controls.^1,2,3,4

Make a row for each step in the access request: employee sign-in, policy lookup, approval, membership change and confirmation. Beside it, record the account doing the work and who maintains it. The employee’s account and a connection’s service account may differ. Ask the builder to explain which permissions actually govern the change, then have the identity team check that answer.

Rehearse a leaver and a transferred employee using approved test accounts. Remove access in the source system and check what the workflow can still read or change. Look for another group that might restore permission. The acceptance condition should describe the visible result: no restricted policy content disclosed, no unauthorized membership change, and an unresolved request routed to the right team.

Nexus describes an engineer building with the customer, while the team using an agent remains accountable for it. WRITER offers embedded transformation leads and deployment engineers. Microsoft documents maker tools and release approval gates.^5,6,7,8,9

Put four responsibilities in the plan: build the workflow, approve its release, operate it and change it. Give each a named customer owner and, where agreed, a supplier contact. For the access-request example, the builder can prepare the connection, but the identity owner should decide its permissions. The process owner decides whether an unresolved case is acceptable. These decisions should survive the end of an implementation engagement.

Ask the supplier to hand over the task description, connected accounts, approval rules, known failures and recovery steps. Have a colleague who did not build the first version follow those instructions. They should be able to find a failed request, stop further changes and contact the right person. A presentation about the architecture is not a substitute for that exercise.

Dust documents audit logs distinguishing human from agent actions, available on Enterprise. Microsoft documents maker audit logs in Purview. Google lists Cloud Audit Logs for enterprise editions.^10,11,12,13

These records may answer different questions. A maker log can explain who changed the agent without showing whether a particular access request succeeded. Agree how your team links the original request, its approval, the attempted change and the result in the identity system. Ask each owner to show the same request from their side. Keep sensitive details with the people who need them; a shared incident note can point to restricted logs.

Try an awkward case before launch: the membership change succeeds, but the final confirmation fails. The support team should check the identity system before repeating the change. Record whether the task is complete, failed without a change, or still uncertain. Assign someone to resolve that uncertainty. Otherwise, each product team can report success while the employee remains stuck.

The finished handover can be one page with links: task, business owner, product owners, accounts, approval rules, evidence locations, stop procedure and support contacts. Add the change that requires another review, such as a new connection or wider group access. Keep the map with the operating instructions so it follows the service when people move roles.